イントロダクション：なぜ今、「機能」以外の話が必要なのか
「AIの回答精度は90%を超えました。ハルシネーション（幻覚）も抑制できています。でも、現場からは『使い物にならない』と突き返されてしまいました」
最近、こうした「機能要件は満たしているのにプロジェクトが失敗している」ケースが増えています。多くのDX推進担当者や事業責任者の方は、AI、特に大規模言語モデル（LLM）を導入する際、「どんなことができるか（機能要件）」には熱心に議論を重ねます。しかし、「どのくらいの速さで、どれくらいの人数が同時に使っても大丈夫か（非機能要件）」については、「まあ、今のWebシステムくらいには動くだろう」と、無意識に楽観視してしまう傾向があるのです。
これが、AI導入プロジェクトにおける最大の「隠れた死因」です。
PoC（概念実証）では数人でテストするため問題になりませんが、全社展開した途端にレスポンスが数十秒かかり、画面がフリーズしたように見える。これでは、どんなに賢いAIでも誰も使ってはくれません。ユーザー体験（UX）において、「待たされる」ストレスは致命的だからです。
今回は、エンジニアではないビジネスサイドの方々に向けて、「精度は高いのに使われない悲劇」を避けるための要諦をお話しします。
技術的な細かい話よりも、「発注側として何を決めておくべきか」「どこにリスクが潜んでいるか」という視点で、現場のリアルな実態を論理的かつ体系的に解き明かしていきましょう。
Q1: 現場で起きている「ユーザー離脱」のリアルな実態
――まずは単刀直入にお聞きします。「AIが遅い」というのは、ビジネスにおいてどれほどのインパクトがあるのでしょうか？
結論から言うと、「遅いAI」は「壊れたAI」と同義だと捉えるべきです。これは決して大げさな表現ではありません。
Web業界には昔から「3秒の壁」という言葉があります。Webページの読み込みに3秒以上かかると、約40%のユーザーが離脱してしまうというデータです。実はこれ、AIチャットボットや社内ツールにおいては、さらにシビアな問題となります。
――もっとシビア、ですか？ 社内ツールなら業務命令で使わざるを得ないから、多少遅くても我慢してもらえるのでは？
それが大きな誤解です。確かに業務命令なら使うでしょう。しかし、「使っているフリ」をして、実際には従来のやり方（詳しい人に電話で聞く、マニュアルを自分で検索する）に戻ってしまうケースが非常に多いのです。
例えば、コールセンターでの一般的なシナリオを想像してみてください。オペレーター支援のために、顧客の会話内容からおすすめの商品をリアルタイムで提案するAIを導入したとします。精度は高いものの、AIが回答を生成するのに平均で8秒かかっていた場合どうなるでしょうか。顧客と電話がつながっている最中の8秒間、オペレーターは無言で待つことはできません。
結局、オペレーターたちはAIの回答が出る前に自分の知識で対応を進めてしまい、AIの画面は見向きもされなくなるでしょう。多額のコストをかけて開発したシステムが、わずか数秒の遅延のために無価値になる可能性も否定できません。
――なるほど、リアルタイム性が求められる現場では致命的ですね。
ええ。それに、ChatGPTなどのコンシューマー向けAIサービスの進化が、ユーザーの期待値を劇的に引き上げている影響も見逃せません。
複数の公式情報（2026年1月時点）によると、ChatGPTではGPT-4oやGPT-4.1などの旧モデルが2026年2月に廃止され、より高速で高度なGPT-5.2（InstantおよびThinking）が新たな主力モデルとして移行しています。この新モデルでは、長い文脈の理解や複雑なツール実行の精度が向上しただけでなく、応答速度もさらに改善されました。
また、テキスト処理能力の飛躍的な向上にとどまらず、指示に対する追従性が高まったVoice機能の強化や、リアルタイムでの画像理解といったマルチモーダル機能も標準化しています。ユーザーは、まるで人間と会話しているかのような、遅延を感じさせないサクサクとした応答速度や、高度な汎用知能にすっかり慣れてしまっているのです。
「プライベートで使うAIは瞬時に、しかも高度な推論を返してくれるのに、なぜ会社のAIはこんなに遅いのか？」
このギャップは以前よりも深刻です。ユーザーの「待てる時間」の基準、つまり期待値のベースラインが上がってしまっている以上、この速度差を埋められないシステムは、どれだけ高尚な業務改革を掲げても、現場の信頼を勝ち取ることは難しいでしょう。
さらに言えば、企業側も社内AIシステムを運用する際、旧モデルに依存したままではいけません。レガシーモデルの廃止や新モデルへの移行といったプラットフォームの進化に追従し、代替手段を確保しながら常にユーザー体験をアップデートしていく計画的なアプローチが求められています。
Q2: なぜ「非機能要件」の定義は漏れてしまうのか？
――なぜ、これほど重要な「速度」や「レスポンス」の話が、要件定義の段階で抜け落ちてしまうのでしょうか？
理由は大きく分けて2つあります。一つは「発注側の思い込み」、もう一つは「LLM特有の不確実性と進化の速さ」です。
まず発注側の心理として、「システムなんだから、速く動くのは当たり前」という前提があります。従来のデータベース検索や定型的な業務システムであれば、その前提は概ね正しかったと言えます。しかし、生成AIは違います。あれはデータを検索しているのではなく、毎回ゼロから計算して答えを作り出している「演算の塊」なのです。
――検索と生成の違い、ですね。
そうです。そして厄介なのが2つ目の「LLM特有の不確実性と進化の速さ」です。
従来のシステム開発では、サーバーのスペックを上げれば処理速度も比例して上がることが多かった。しかし、LLMの場合、入力されるプロンプト（指示文）の長さや、生成させる文章量によって、処理時間が大きく変動します。
例えば、「要約して」という指示でも、100文字で返す場合と1000文字で返す場合では、処理時間は単純に10倍近く変わることもあります。さらに、クラウド経由でAPIを利用している場合、プラットフォーム側の混雑状況や、利用するモデルの世代交代にも左右されます。
実際、OpenAIなどの主要プロバイダーではモデルの更新サイクルが非常に速く、最新世代のモデルが登場すると、旧世代のモデルが順次廃止されます。例えば2026年2月には、ChatGPTにおいてGPT-4oなどのレガシーモデルが提供終了となり、既存のチャットは自動的にGPT-5.2へと移行されました（APIの提供は継続されています）。GPT-5.2のような新しいモデルは、100万トークン級のコンテキスト処理や高度な推論ルーティングなど能力が飛躍的に向上している反面、処理特性が異なります。そのため、「以前のモデルではスムーズだったが、モデルが切り替わってからレスポンスの体感が変わった」という事態も起こり得るのです。影響を最小限に抑えるには、移行の際にプロンプトを新しいモデルで再テストするなど、適切な運用プロセスを組み込む必要があります。
――ベンダー側も「やってみないと分からない」と言いたくなるわけですね。
まさにその通りです。ベンダーのエンジニアとしても、「3秒以内で返します」と約束（コミット）して、もしAPI側の都合やモデル変更の影響で遅延したら責任を問われるわけですから、SLA（サービスレベル合意）に具体的な秒数を書きたがりません。
その結果、RFP（提案依頼書）にも要件定義書にも、「レスポンスタイム」に関する明確な数字が記載されず、「実用的な速度であること」といった曖昧な表現でお茶を濁してしまう。これが、後のトラブルの火種になります。
一般的に、ベンダーから「LLMの仕様上、速度保証はできません」と回答されるケースは珍しくありません。しかし、そこで諦めるのではなく、「保証はできなくても、目標値（SLO）と、それを下回った場合の対策は合意しましょう」と交渉し、アーキテクチャを見直すアプローチを取ることが、プロジェクトを成功させるための重要なポイントになります。
Q3: 成功事例に見る、レスポンス遅延を「UX」でカバーする技術
――技術的に高速化することには限界があるようですが、どうすればユーザーを満足させられるのでしょうか？
ここで重要になるのが、「物理的な時間を短縮する」ことと、「体感時間を短縮する」ことを分けて考える視点です。エンジニアは前者を追求しますが、プロジェクトマネージャーやビジネスサイドが注力すべきは後者、つまりUX（ユーザー体験）デザインです。
成功事例として、一般的な社内ナレッジ検索システムの改修事例を考えてみましょう。このシステムは、回答生成に平均15秒かかっていました。15秒間、画面に「処理中...」とグルグル回るアイコンが出ているだけだと、ユーザーは「フリーズしたかな？」と思ってブラウザを閉じてしまうかもしれません。
そこで導入されたのは、「ストリーミング表示（Streaming）」と「プログレッシブな開示」という手法です。
――ChatGPTのように、文字がパラパラと表示されるあれですか？
その通りです。実はあれ、単なる演出ではありません。技術的には「First Token Latency（最初のトークンが表示されるまでの時間）」と呼ばれる指標が重要になります。
全体の回答が終わるのに15秒かかったとしても、最初の1文字目が1秒後に出始めれば、ユーザーは「お、動いているな、考えてくれているな」と認識して、安心して待つことができます。実際にこの改修を行っただけで、システム全体の処理時間は変わっていないのに、ユーザーアンケートでの「速度への不満」は激減したという事例もあります。
――面白いですね。速くしたわけではないのに、速く感じさせる。
人間の心理とはそういうものです。他にも、「AIが思考しているプロセスを可視化する」という手もあります。「関連ドキュメントを検索中...」「情報を要約中...」「回答を生成中...」といったステータスを細かく表示するのです。
これにより、ユーザーは待ち時間を「無駄な時間」ではなく、「自分のためにAIが働いてくれている必要な時間」と解釈し直してくれます。これは、テーマパークの待ち行列で、途中に飽きさせない仕掛けがあるのと同じ理屈ですね。
非機能要件というと、サーバー増強やモデルの軽量化（量子化）といったハードな技術論になりがちですが、実はこうした「見せ方」の工夫一つで、プロジェクトの成否が分かれることも多いのです。
Q4: 明日から使える「非機能要件」チェックリスト
――これからベンダー選定や要件定義を行う読者のために、具体的なアドバイスをお願いします。
わかりました。エンジニアに丸投げせず、ビジネスサイドの責任者が必ず確認すべきチェックリストを挙げましょう。
まず、ベンダー選定時や社内エンジニアとのキックオフで、以下の3つの質問を投げかけてみてください。
- 「First Token Latency（最初の文字が出る時間）の目標値は何秒ですか？」
- 全体の完了時間よりも、まずここを握ります。一般的には2〜3秒以内が望ましいです。
- 「ユーザー数がピーク時に達した際、スロットリング（速度制限）はどう回避しますか？」
- APIの制限（Rate Limit）を考慮しているかを確認します。ここが抜けていると、全社員が一斉に使った瞬間にシステムが落ちる可能性があります。
- 「回答生成に時間がかかりすぎた場合の『フォールバック（代替策）』はありますか？」
- 例えば30秒経っても答えが出ない場合、エラーで落とすのか、それとも「あとでメールで通知します」と切り替えるのか。この挙動を決めるのはビジネス側の責任です。
――非常に実践的ですね。特に3点目は見落としがちです。
そうなんです。エラー画面がいきなり出るのが一番のUX毀損ですからね。
また、SLA（サービスレベル合意）についても、「平均応答時間」だけでなく、「95パーセンタイル値（95%のユーザーが体験する速度）」を意識してください。平均が速くても、20回に1回極端に遅いと、ユーザーの信頼は損なわれる可能性があります。
「100点満点の速度」を目指す必要はありません。しかし、「ユーザーが離脱しない最低ライン」はどこなのか、それは業務フローの中で許容できる待機時間から逆算して決める必要があります。これをエンジニア任せにせず、ビジネスの言葉で定義してあげることが、AI導入を成功させるために重要です。
編集後記：AIは魔法ではなく、工業製品である
今回の記事を通じて改めてお伝えしたいのは、AI導入プロジェクトにおける「非機能要件」とは、システムの話である以前に、「ユーザーへの思いやり」の設計だということです。
どれだけ高精度な頭脳を持っていても、コミュニケーションのテンポが悪ければ信頼関係は築けません。それは人間同士も、人間とAIの関係も同じです。
AIを「魔法の杖」だと思っていると、機能（何ができるか）ばかりに目が向きます。しかし、AIを「業務を支える工業製品」として捉え直せば、耐久性、応答速度、使い勝手といった品質（どう動くか）がいかに重要かが見えてくるはずです。
現在進めている、あるいはこれから計画するプロジェクトにおいて、この「非機能要件」という視点が、ROI最大化と実用的なAI導入の成功への助けとなることを願っています。
コメント