TTFTとは、ユーザーが指示文を送信してからAIが最初の1文字（1トークン）を画面に返すまでにかかる待機時間のことです。チャット画面で質問を送信したあと、画面にカーソルが点滅したまま待たされる感覚に悩んだ経験はありませんか。

API経由で大規模言語モデル（LLM）を動かす際、全体の処理時間だけを見ていても体感速度は改善しません。人が「待たされている」と認識するストレスの大半は、この最初の1文字が出るまでの間隔に集中するためです。チャットボットや検索アシスタントの離脱を防ぐなら、真っ先に向き合うべき数値指標が存在します。

この指標の正体と、数値を押し上げるボトルネック、現場で実装できる短縮手法を順を追って解説します。

TTFTとはどのような指標？

TTFTとはどのような指標？

TTFTとは、クライアントが推論サーバーへリクエストを送り、サーバーから最初の出力トークンが届くまでの物理的な経過時間です。英語の「Time to First Token」の頭文字を取った略称で、大規模言語モデルの応答性を測る指標として業界標準で用いられます。

文字のかたまりを1つずつ順番に出力していく自己回帰型のAIモデルにおいて、最初の応答が届く瞬間はユーザー体験の快適さを大きく左右します。人間は最初の文字が表示された時点で「システムが応答を始めた」と認識するためです。文字が流れ始めてしまえば、多少生成スピードが遅くても読書速度と同期するためストレスを感じにくくなります。

Web APIの文脈で使われるTTFB（Time to First Byte）を、言語モデルのトークン生成プロセス向けに特化させた指標と捉えると構造が掴みやすくなります。

ユーザー送信
    │
    ▼ (1) ネットワーク到達時間
[推論サーバー到着]
    │
    ▼ (2) 実行待ちキュー待機時間
[GPUメモリへ展開]
    │
    ▼ (3) プロンプト全文の並列計算（プリフィル）
[最初の1トークン生成]
    │
    ▼ 最初のトークン返送
クライアント受信（ここまでがTTFT）

画面全体の生成が終わるまでの総時間（E2Eレイテンシ）が同じ3秒であっても、TTFTが300msのシステムと2.8秒のシステムでは、利用者の受ける印象がまったく異なります。

TTFTとTPSやITLの違いはどこにある？

TTFTとTPSやITLの違いはどこにある？

推論速度を評価する指標には、TTFTのほかにTPS（Tokens Per Second）とITL（Inter-Token Latency）が存在します。それぞれの役割と測定対象の違いを整理します。

TPSは1秒間に何個のトークンを生成できるかを表すスループットの指標です。一方、ITLは2文字目以降のトークンが1つ出力されてから次のトークンが出力されるまでの平均間隔時間を指します。

指標名測定対象単位利用者が体感する影響最適化の主戦場
TTFTリクエスト送信から最初の1トークン受信までミリ秒（ms）「応答が始まった」と感じるまでの待ち時間プロンプト長削減、キャッシュ、キュー最適化
ITLトークンとトークンの間の出力間隔ミリ秒（ms）文章がスムーズに流れているかの滑らかさメモリ帯域幅、バッチサイズ、量子化
TPS1秒間あたりに生成されるトークン総数トークン/秒全文が完成するまでの総合的な速度ハードウェア性能、GPU並列数、モデル軽量化

3つの指標はそれぞれ測定しているフェーズが独立しています。

たとえば、TTFTが200msと俊敏であっても、ITLが150msまで跳ね上がると文字の表示が目に見えてガタつきます。逆に、TPSが100 tokens/sを誇る高速エンジンであっても、TTFTが3秒かかればユーザーはフリーズしたと誤認して画面をリロードします。

対話型のチャットや音声エージェントを構築するなら、まずはTTFTを200〜400ms以下に抑え込み、次いで人間の読書速度（秒間15〜20トークン程度）を満たすITLを確保する設計が基本線となります。

TTFTを決定づける3つの遅延要因

推論サーバーの内部において、TTFTは単一の処理時間ではありません。具体的には以下の数式で定義される3要素の足し算で成り立っています。

$$TTFT = T_{net} + T_{queue} + T_{prefill}$$

各要素がどのようなメカニズムで遅延を生み出しているのかを分解します。

[クライアント] ──(T_net: 往復通信)──> [推論基盤]
                                          │
                                    (T_queue: 待機列)
                                          │
                                    (T_prefill: 計算)
                                          │
                                          ▼
                                    最初の1文字を出力

1. ネットワーク遅延（T_net）

クライアントと推論サーバーが設置されている物理的な距離によって生じる伝送時間です。東京の端末から米国オレゴン州やバージニア州のデータセンターにあるAPIへ通信を送るだけで、光ファイバーの物理限界により往復100〜180ms前後の時間が自動的に加算されます。

TLSハンドシェイクの往復や、プロンプトのデータ転送サイズに応じた遅延もここに含まれます。

2. キュー待機遅延（T_queue）

推論サーバーにリクエストが到達してから、GPUの計算コアが空いて実際に処理が開始されるまでの待ち時間です。クラウドAPIでアクセスが集中している時間帯や、セルフホスト環境で同時リクエスト数がGPUのキャパシティを超えている場合に膨張します。

特にサーバーレス推論環境では、待機状態のマシンが起動するコールドスタートが重なると、この待ち時間が数秒から数十秒に達するケースがあります。

3. プリフィル処理遅延（T_prefill）

モデルが入力された指示文（コンテキスト）の全体を読み込み、TransformerのAttention機構で並列計算を行って最初のトークンを予測する計算時間です。プロンプトのトークン数が長くなればなるほど、計算量は二乗または線形に増大します。

システムプロンプトに大量の社内マニュアルを詰め込んだり、過去の会話履歴を10往復分そのまま送信したりすると、GPUが計算を終えるまでに時間がかかり、TTFTの急激な悪化を招きます。

今週のAIニュースを週1回メールで受け取る無料

毎週月曜の朝に、今週のAIの主なニュース・新しく載ったツール・よく読まれた記事をまとめて届けます。登録特典は「AIツール選定チェックリスト 2026」。

確認メールのボタンを押すと登録が完了します。配信はいつでも解除できます。

プロンプト長とプリフィル時間の相関関係

プリフィル処理の所要時間は、入力するプロンプトのトークン数に直接比例して増大します。LLMが最初の文字を生成するためには、入力されたすべての単語同士の関連性を計算（自己注意機構の行列積）しなければならないためです。

入力トークン数:  500 tokens ───> プリフィル時間: 35ms
入力トークン数: 2,000 tokens ───> プリフィル時間: 130ms
入力トークン数: 8,000 tokens ───> プリフィル時間: 580ms
入力トークン数: 32,000 tokens ──> プリフィル時間: 2,400ms

文字数が少ない単純な質疑応答であれば、GPUの並列計算コアによってプリフィルは数十ミリ秒で完了します。長大な社内文書をプロンプトに添付するRAG（社内資料を読ませて答えさせる仕組み）環境では、プリフィルだけで1秒以上の時間を消費することも珍しくありません。

入力長がTTFTに与えるインパクトを甘く見てはいけません。出力文字数を「短く答えてください」と指示しても、入力側のテキストが膨大であれば最初の1文字が出るまでの時間は1ミリ秒も縮まらないためです。

TTFTを短縮するプロンプトキャッシュの仕組み

プリフィル処理の遅延を抑え込むための最も強力な対抗策が、プロンプトキャッシュ（KVキャッシュの再利用）です。

通常の推論では、リクエストが届くたびに入力プロンプト全体のKey-ValueベクトルをGPUメモリ上で計算し直します。プロンプトキャッシュを有効化すると、一度計算した共通のプロンプト部分（システムプロンプトや前提文書など）の計算結果がメモリ上に保存され、2回目以降のリクエストでは計算そのものをスキップできます。

【通常の推論】
リクエスト ──> [システム文の再計算 + 質問の計算] ──> 最初のトークン
              (プリフィル時間: 450ms)

【プロンプトキャッシュ適用時】
リクエスト ──> [キャッシュから読込 + 質問の計算] ──> 最初のトークン
              (プリフィル時間: 40ms)

主要なクラウドAPIプロバイダ各社もプロンプトキャッシュ機能の標準提供を進めています。キャッシュがヒットした場合、TTFTが最大で80〜90%削減されるだけでなく、入力トークン料金が半額から数分の一に割引される設計が一般的です。

キャッシュを効かせるためには、プロンプトの構造設計に規律が求められます。変化しない固定テキスト（役割定義、出力フォーマットのルール、参照ドキュメント）をプロンプトの先頭に配置し、ユーザーごとの可変な入力文を末尾に置く構成を徹底します。先頭の文字列が1文字でも狂うと、それ以降のキャッシュが無効化されて再計算が走る仕様となっているためです。

投機的デコーディングはTTFTに影響する？

推論高速化の手法として名前の挙がりやすい投機的デコーディング（Speculative Decoding）ですが、この技術が効果を発揮する対象を見誤ってはいけません。

投機的デコーディングとは、小型で高速なドラフトモデルが大まかな予測トークンをまとめて数個生成し、大型のターゲットモデルが一括でその正確性を検証する推論手法です。検証処理を並列で行えるため、2文字目以降を生成するITLの短縮やTPSの向上には絶大な威力を発揮します。

小型モデル: トークンA, B, C をすばやく推測生成
    │
    ▼ 並列検証
大型モデル: トークンA(OK), B(OK), C(NG・再修正)

この技術は最初の1トークンが出力された「後」の生成ステップを高速化するアルゴリズムです。最初のトークンを決定するためのプリフィル計算そのものをスキップするわけではありません。

ドラフトモデル自体の初期化や検証ステップのオーバーヘッドが乗ることで、環境によってはTTFTがわずかに数ミリ秒悪化するケースすら存在します。全体の処理完了時間を縮める目的には役立ちますが、TTFT単体の改善策として導入するのは的外れとなります。

TTFT短縮のためのアーキテクチャ設計手法

アプリケーション全体の設計を見直すことで、TTFTを劇的につぶし込むアプローチを紹介します。コードの書き方や通信プロトコルの選定で削り取れるミリ秒は無数に存在します。

[クライアント]
  │
  ├─ 1. HTTP/2 or HTTP/3 (接続の使い回し)
  ├─ 2. Server-Sent Events (ストリーミング返却)
  ▼
[エッジプロキシ / リージョン配置] (地理的距離の短縮)
  │
  ▼
[推論バックエンド]
  ├─ プレフィックスのキャッシュ固定化
  └─ コンテキスト圧縮によるトークン間引き

1. ストリーミング返送（Server-Sent Events）の採用

生成結果を全文まとめてJSONで受け取るバッチ方式を直ちにやめ、Server-Sent Events（SSE）によるストリーミングレスポンスへ切り替えます。

バッチ方式を採用していると、モデルが1文字目を生成していても、最後の文末トークンが出力されるまでクライアントへデータが送信されません。この場合、クライアントから観測されるTTFTは全文生成時間と完全に一致してしまいます。ストリーミングを有効化して初めて、生成された1文字目が即座にネットワークを流れて画面に届きます。

2. エッジプロキシと接続プーリング

推論APIとの通信接続（TCPコネクションおよびTLSセッション）をリクエストのたびに切断して再確立すると、それだけで数十ミリ秒を失います。コネクションプールを維持し、HTTP/2やHTTP/3を介して既存の接続を再利用します。

また、Cloudflare Workersなどのエッジサーバーから直接推論エンドポイントへ通信を中継させることで、クライアント端末とのハンドシェイク時間を最小化する構成も有効です。

3. リージョン近接配置

推論サーバーの設置拠点を、利用者の物理的な位置に近づけます。日本国内のユーザー向けにサービスを展開する場合、モデル提供プロバイダの東京リージョンやアジア近隣リージョンを選択するのが定石です。

アメリカリージョンとの通信で発生する往復150msのオーバヘッドを、同一国内であれば10〜20ms台まで圧縮できます。

主要モデル別のTTFT傾向と推論速度比較

モデルの規模やアーキテクチャによって、初期応答にかかる負荷の大きさは異なります。一般的なパラメーター規模別のレイテンシ傾向を整理します。

軽量なモデルは計算量が少ないためプリフィルが高速で、TTFTも極めて短く収まります。一方、複雑な思考プロセスを挟む推論特化型モデルでは、ユーザーに見える文字が出力される前に「思考用トークン」の生成が裏で走るため、TTFTの数値が跳ね上がる構造を持ちます。

モデル規模・系統代表的な特性平均的なTTFT目安（小プロンプト時）プリフィルの負荷感度主な適用領域
超軽量（1B〜8Bクラス）極めて俊敏、省メモリ80〜180ms鈍感（長文でも詰まりにくい）オートコンプリート、リアルタイム検索
中規模（14B〜70Bクラス）精度と速度のバランス型200〜450ms中程度一般チャット、社内アシスタント
巨大モデル（フロンティア級）高度な論理展開、膨大な並列計算500〜1,200ms敏感（長文で遅延が顕著化）難度の高い分析、要約タスク
推論モデル（思考プロセス型）思考チェーンを先行出力1,500〜4,000ms+極めて敏感複雑な数学、多段階コーディング

用途に応じた適切なモデル選びが、小手先のチューニング以上にレイテンシを左右します。

一般的な対話型チャットボットであれば、軽量〜中規模の汎用モデルを採用するのが無難です。高度なタスクをAIエージェントに任せる場面では、最初の応答を急ぐ案内役と、裏でじっくり推論を行う担当役でモデルを分担させるパイプライン設計が力を発揮します。

コード補完や入力支援のような即応性が命となる用途では、AIコーディング向けに特化した軽量モデルを迷わず選び取ってください。

TTFTを正確に測定・モニタリングする手法

推論速度の最適化に着手する前に、現状の正確なTTFTを計測できる環境を整えます。外部のベンチマーク数値を眺めるのではなく、自社の通信経路とプロンプトで実測値を把握することが出発点です。

最も原始的かつ確実な測定法は、curl コマンドを使ったネットワークタイミングの分解です。

curl -N -s -w "\n--- Latency Details ---
DNS Lookup: %{time_namelookup}s
TCP Connect: %{time_connect}s
TLS Handshake: %{time_appconnect}s
Pre-Transfer: %{time_pretransfer}s
Time to First Byte: %{time_starttransfer}s
Total Time: %{time_total}s\n" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $API_KEY" \
-d '{"model":"model-name","messages":[{"role":"user","content":"Hi"}],"stream":true}' \
$API_ENDPOINT

ストリーミングフラグ（"stream": true）を付与した状態でリクエストを発行し、time_starttransfer（最初の1バイトを受信した時間）を記録します。この値がクライアント視点でのTTFTにほぼ合致する数値となります。

商用環境の監視では、OpenTelemetry等のトレーシングツールを導入し、サーバー着信時刻、推論エンジン呼び出し時刻、初弾チャンク送信時刻をスパンとして計測するパイプラインを組むのが堅実です。

RAGシステムでTTFTが悪化する原因と対策

社内文書を検索してプロンプトに注入するRAG環境は、最もTTFTが悪化しやすい典型例です。検索結果のテキストを無防備にプロンプトへ追加することで、入力トークン数が一気に数千から数万へ跳ね上がるためです。

【悪化パターン】
質問受付 ──> ベクトル検索 ──> 関連文書10件（12,000トークン）を一括注入
                                        │
                                        ▼ 膨大なプリフィル計算
                              最初の文字が出るまで 2.8秒待機

この遅延を抑え込むには、次の3つのアプローチを組み合わせます。

  1. 検索チャンクの絞り込み（リランキング）
    関連度の低い文書までコンテキストに含めるのをやめ、Cross-Encoderなどでスコアリングした上位2〜3件のみをプロンプトに渡します。入力トークン数を3,000トークン以下に抑えるだけで、プリフィル遅延は目に見えて改善します。

  2. コンテキスト配置の固定化
    プロンプトの先頭にシステム指示を置き、その直後にキャッシュ対象となりやすい固定ルールを配置します。可変の検索結果はその下へ並べ、キャッシュのヒット率を最大化させます。

  3. 段階的なUIフィードバック
    LLMの応答を待つ間に、フロントエンド側で「関連資料を検索中...」「回答を生成中...」といった進捗ステータスを即座に表示します。バックエンドの物理的なTTFTを削る工夫と並行して、ユーザーの心理的な体感待ち時間を紛らわせるUI設計が不可欠です。

本番環境でレイテンシ予算（SLO）をどう設計する？

プロダクション環境でLLMを運用するなら、TTFTのサービスレベル目標（SLO）を感覚値ではなく具体的な数値バジェットとして定義しておく必要があります。

対話型システムにおけるレイテンシバジェットの設計例を以下に提示します。

[全体のTTFT許容上限: 500ms (P95)]
  ├── ネットワーク往復 (T_net): 60ms
  ├── プロキシ・認証処理: 20ms
  ├── 推論エンジン待機列 (T_queue): 100ms
  └── プリフィル計算時間 (T_prefill): 320ms

平均値（P50）だけで性能を判断するのは禁物です。アクセス集中時や長文プロンプトが流入した際に数値が跳ね上がるため、P95やP99のパーセンタイル値を監視対象に設定します。

P95でTTFTが800msを超える状態が続くなら、モデルの軽量化やGPUインスタンスのオートスケール発火閾値の引き下げを検討するシグナルとなります。全体の設計指針を固める際は、AI開発ツール比較でも取り上げているような統合基盤の遅延管理機能を参考にすると全体像が掴みやすくなります。

自前ホスティング環境でTTFTを削るチューニング

クラウドAPIではなく、vLLMやTGI（Text Generation Inference）などを用いてオープンウェイトモデルを自前運用する場合、推論エンジンのパラメータ調整でTTFTを大幅に短縮できます。

チャンクド・プリフィル（Chunked Prefill）

長いプロンプトのプリフィル計算を一括で行わず、小さなチャンクに分割してデコード処理の合間に挟み込む技術です。長文リクエストが飛び込んできた際にGPUが占有され、後続の別リクエストのキュー待機時間（T_queue）が跳ね上がる現象を劇的に抑制します。

テンソル並列とKVキャッシュメモリ管理

モデルを複数のGPUへ分割配置するテンソル並列（TP）を活用し、プリフィル時の行列計算を分散処理させます。あわせてPagedAttentionなどの仕組みでGPUのVRAM断片化を防ぎ、メモリ確保の遅延を抑え込みます。

自社インフラでモデルを動かすハードルや役割分担については、Hugging Face vs Devinの比較記事でも触れている通り、基盤の保守コストと得られるレイテンシ制御の自由度を天秤にかけて判断する必要があります。

あわせて見たいツール・カテゴリ

LLMの応答速度やシステム基盤の選定を深掘りしたい場合、以下のカテゴリや専門ツール情報が参考になります。

AI PICKS編集部の判定

TTFTの短縮において、最も費用対効果が高い手法は「プロンプトキャッシュの徹底」と「Server-Sent Eventsによるストリーミング実装」の組み合わせです。この2つを正しく組み込むだけで、追加のインフラコストを1円もかけずに初期応答を半分以下へ削り取れます。

現場でありがちな失敗は、プロンプトの記述量を削らずに高価な巨大モデルへそのまま長文を流し込み、推論サーバーのスペック不足を疑ってしまうケースです。遅延のボトルネックは大半がプリフィル処理とネットワーク往復にあります。まずはプロンプトを整理して文字数を間引き、共通プロンプトを先頭へ寄せてキャッシュを効かせる運用が一択です。

自前ホスティングによる極限のチューニングは魅力的に見えますが、保守運用やGPUの調達コストを考慮すると、多くのユースケースでは既存の商用APIで東京リージョンとプロンプトキャッシュを活用する構成が圧倒的に合理的です。

よくある質問（FAQ）

Q. TTFTの理想的な目標値は何ミリ秒ですか？

対話型のチャット画面であれば、P95で300ms〜500ms以内を目指すのが現実的な水準です。これを超えて1秒以上に達すると、人間は明らかに待たされている感覚を抱きます。一方で、バックグラウンドで動くバッチ処理や非同期の要約タスクであれば、TTFTを意識する必要は薄く、数秒かかっても問題ありません。

Q. プロンプトを英語にするとTTFTは短くなりますか？

短縮される傾向にあります。多くのLLMのトークナイザーは英語を効率よくトークン化できるように作られており、日本語の同じ文章と比較して英語のほうがトークン数が半分程度で済むケースが多いためです。トークン数が減ればプリフィル計算の負荷が減るため、結果としてTTFTの抑制につながります。

Q. 量子化（AWQやGPTQなど）はTTFTに好影響を与えますか？

モデルの重みサイズが縮小するため、GPUメモリからの読み出し帯域が節約され、基本的にはTTFTの改善に寄与します。ただし、プリフィル処理はメモリ帯域よりもGPUの計算コア性能に依存する比重が大きいため、2文字目以降を出すITLの改善幅に比べると、TTFTへの効果はやや控えめとなります。

Q. モバイル回線でTTFTが極端に悪化するのはなぜですか？

モバイル通信特有の無線区間レイテンシと、基地局とのハンドシェイク待ち時間が原因です。有線光回線に比べて物理的な往復時間（RTT）が30〜80msほど長くなり、パケットの再送制御も発生しやすくなります。クライアント端末と近接したエッジプロキシを挟むことで、初期接続の確立時間をある程度緩和できます。

Q. TTFTがどれだけ速くてもユーザー体験が悪くなるケースはありますか？

TTFTが短くても、その後のITLが不安定で文字の出力がカクつく場合は体験が悪化します。また、最初の1トークンが出た後にモデルが長時間考え込むような出力制御になっている場合も、利用者に混乱を与えます。TTFTだけでなく、後続のトークンが滑らかに継続して届いているかをセットで監視することが欠かせません。

ゲーム開発などのシビアなリアルタイム描画とLLM連携を両立させたい場合は、AI×ゲーム開発ツール5選をあわせて確認すると、インタラクティブな高速応答設計の具体例が掴めます。

参考にした一次情報

記事の事実関係は、次の公式ページで確認しています。仕様や料金は変わることがあるため、最新の内容は各ページで確かめてください。