AI を組み込んだ業務システムをリリースしたあと、現場から最初に返ってくる声で多いのが「遅い」です。ところが、この「遅い」をそのまま開発側に伝えても、たいてい話は前に進みません。どこが遅いのかが特定されていないまま、より高速なモデルへの乗り換えだけが検討される、というのがよくある展開です。
実際には、利用者が感じる速さは複数の要素の積み重ねで決まります。モデルの性能はそのうちの一部にすぎません。この記事では、AI 応答の「体感の速さ」を 3 つの要素に分解し、どこから手を入れると費用対効果が高いのかを整理します。発注する側・社内で仕様を決める側が、開発会社と同じ土俵で会話できるようになることを目指します。
「遅い」を 3 つの時間に分解する
まず前提として、AI の文章生成はトークン（単語や文字を細かく区切った処理単位。日本語では 1 文字が 1 トークン前後になることが多い）を 1 つずつ順番に吐き出していく仕組みです。この性質から、応答時間は次のように分けられます。
| 要素 | 内容 | 利用者から見た現れ方 |
|---|---|---|
| ① 最初の 1 文字が出るまで | 入力の受け取り、検索、プロンプト組み立て、モデルの初期処理 | ボタンを押してから画面が無反応な時間 |
| ② 文章が出きるまで | トークンを 1 つずつ生成する時間 × 出力量 | 文字が流れていく速さ |
| ③ 待っている間の体験 | 進捗表示、操作の継続可否、再開のしやすさ | 「待たされている」というストレスの大きさ |
①は業界では TTFT（Time To First Token、最初のトークンが返るまでの時間）と呼ばれます。体感への影響が最も大きいのはこの①で、次が③、意外にも②は後回しでよいケースが少なくありません。順に見ていきます。
要素 1：最初の反応までの時間を削る
人は、画面が無反応な時間に対して非常に敏感です。合計 10 秒かかる処理でも、1 秒後に何かが動き始めるのと、7 秒間まったく動かないのとでは、受け取られ方がまるで違います。
TTFT が伸びる典型的な原因
- 入力プロンプトが長すぎる：モデルは出力する前に入力全体を読み込みます。マニュアル全文を毎回貼り付けるような設計だと、読む段階で時間を使います。
- 前処理が直列になっている：社内データベースへの問い合わせ、ファイル読み込み、別 API の呼び出しなどを順番に実行している。並列化できるものが直列のまま残っているケースは非常に多いです。
- 検索（RAG）の設計：RAG（Retrieval-Augmented Generation、社内文書などを検索してその内容をもとに回答させる方式）では、検索の精度を上げようとして候補を取りすぎ、結果としてプロンプトが肥大していることがあります。
- ネットワーク経路：海外リージョンのエンドポイントを使っている、プロキシを何段も経由している、といった構成上の問題。
効きやすい対策
- プロンプトキャッシュの活用：主要な AI サービスでは、繰り返し使う長い前置き（システムプロンプトや固定の参照資料）をキャッシュして再利用する機能が提供されています。固定部分を前方に、可変部分を後方に置く構成にしておくと効果が出やすい設計です。利用条件や課金の扱いは提供元によって異なるため、採用時に公式ドキュメントで確認してください。
- 前処理の並列化：検索とユーザー情報の取得など、互いに依存しない処理は同時に走らせます。
- 渡す情報の絞り込み：検索結果の上位 20 件を全部渡すのではなく、再ランキングして 3〜5 件に絞る。精度と速度が同時に改善することもあります。
要素 2：出力の量と生成速度
②の時間は、おおよそ「出力トークン数 ÷ 1 秒あたりの生成トークン数」で決まります。つまり、速くする道は 2 つしかありません。短くするか、速いモデルにするかです。
見落とされがちなのが前者です。たとえば次のような場面を想像してください。問い合わせメールの下書きを生成する機能で、毎回「ご丁寧にお問い合わせいただき誠にありがとうございます」から始まる定型の挨拶文を AI に生成させている。この部分はテンプレートで固定し、AI には可変部分だけを書かせれば、出力量は大きく減ります。
モデル選択については、同じ提供元でも用途別に複数のモデルが用意されているのが一般的です。考え方としては次の通りです。
| 用途 | 適したモデルの傾向 |
|---|---|
| 分類、要約、定型項目の抽出 | 軽量・高速モデル。精度差が出にくく、速度の恩恵が大きい |
| 複雑な判断、長文の起案、コード生成 | 高性能モデル。遅さを許容し、代わりに待ち時間の見せ方で補う |
| 1 つの画面に複数の処理が混在 | 処理ごとにモデルを使い分ける。全部を最上位モデルで通さない |
近年は、内部で手順を考えてから答える推論型のモデルも増えています。これらは精度が高い反面、考えている間は出力が出ないため TTFT が長くなる傾向があります。全社の業務画面にそのまま載せる前に、用途を絞って試すことをおすすめします。
要素 3：待たせ方の設計で体感は変わる
実測値を 1 秒縮めるより、見せ方を変えるほうが安く早く効くことがあります。
- ストリーミング表示：生成された文字を逐次表示する方式。完成を待ってから一括表示するのに比べ、体感待ち時間を大幅に短縮できます。まだ実装していないなら、最優先の改善候補です。
- 進捗の具体化：単なる回転アイコンではなく「社内規程を検索しています」「3 件の文書を確認しています」のように、今どの段階かを示す。処理が何をしているか分かると、待つ心理的負担が下がります。
- 先に出せるものを先に出す：検索でヒットした文書名を先に表示し、要約は後から追記する、といった段階的表示。
- 非同期化：数十秒以上かかる処理は、画面に張り付かせない設計にします。実行を予約して、完了したら通知やメールで知らせる。月次レポート生成のようなバッチ的な用途では、むしろこちらが自然です。
- 楽観的な先行処理：入力途中で検索だけ先に走らせておく、といった工夫。ただし無駄な API 呼び出しがコストに直結するため、費用とのバランスを見てください。
優先順位の付け方と、実装で詰まりやすい箇所
着手順の目安
- 計測する：前処理・モデル呼び出し・後処理のそれぞれに、どれだけ時間がかかっているかをログに残す。これをやらずに改善を始めると、ほぼ確実に見当違いの場所を直すことになります。
- ストリーミングと進捗表示：改修コストが比較的小さく、効果が見えやすい。
- プロンプトの圧縮とキャッシュ：入力量の削減は、速度とコストの両方に効きます。
- 前処理の並列化：設計変更を伴うため、ここから工数が上がります。
- モデルの変更：出力品質の再検証が必要になるため、最後に検討します。
詰まりやすいポイント
- ストリーミングと社内インフラの相性：一部のロードバランサやプロキシ、WAF が応答をバッファリングしてしまい、逐次表示が機能しないことがあります。開発環境では動いたのに本番で固まる、という典型パターンです。
- タイムアウト設定の不整合：Web サーバ、アプリケーション、AI サービス側の制限時間がバラバラで、長い生成の途中で切断される。
- レート制限：同時アクセスが増えた時間帯だけ遅くなる場合、モデルの速度ではなく API の利用上限に当たっている可能性があります。リトライと待機の設計が必要です。
- キャッシュと機密情報の扱い：応答をキャッシュして高速化する場合、ユーザーごとに閲覧権限が異なるデータが混ざらないか確認が必要です。個人情報を含む場合は個人情報保護法の観点、外部サービスへのデータ送信については経済産業省・総務省が公表しているAI 事業者ガイドラインなども参照しながら、社内の取り扱い方針を整理しておくことをおすすめします。
- 速度とコストのトレードポイント：並列化や先行処理は API 呼び出し回数を増やします。月額費用の上振れを織り込んでおきましょう。
まとめ
AI 応答の体感速度は、①最初の反応までの時間、②出力の量と生成速度、③待ち時間の見せ方、の 3 つで決まります。そして改善の費用対効果が高い順は、多くの場合 ③ → ① → ② です。「モデルを変えれば速くなる」という発想から入ると、品質検証のやり直しという重い作業を最初に背負い込むことになりがちです。
まずやるべきことは計測です。どの工程に何秒かかっているかを可視化すれば、議論は「遅い気がする」から「検索に 2.8 秒かかっている」という具体に変わります。開発会社とのやり取りでも、この数字があるかどうかで進み方がまったく違います。
すでに稼働中のシステムで「遅い」という声が上がっているなら、改修の見積もりを取る前に、現状の処理時間の内訳を出してもらうところから始めてみてください。それだけで、手を入れるべき場所がかなり絞り込めるはずです。