Skip to Content
Docs05. 運用レイテンシ最適化
中級latency-optimizationstreaming更新: 2026-07-05この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

レイテンシ最適化

この記事の目的

Agent の応答時間を「LLM 呼び出し × 回数 + ツール実行」に分解して計測し、支配項から順に削る判断ができるようになります。体感品質の改善(ストリーミングと Agent の UX 実装パターン)とは別の、実レイテンシそのものを下げる技術を扱います。

対象読者

前提知識

本文

概要: 分解して計測してから削る

Agent の総レイテンシは次の和です。

総レイテンシ = Σ LLM 呼び出し時間 + Σ ツール実行時間 + オーバーヘッド

そして LLM 呼び出し 1 回の時間は、最初のトークンが出るまでの時間(TTFT)+ 出力トークン数 × 1 トークンあたりの生成時間で近似できます。つまりレバーは「呼び出し回数」「出力の長さ」「TTFT」「ツールの速さ」の 4 つしかありません。

最初にやることは最適化ではなく計測です。トレース(可観測性とトレーシング)から遅いタスクの内訳を見て、どの項が支配的かを確かめます。LLM が支配的だと思い込んでいたら実は 1 本の社内 API が 20 秒かかっていた、はよくある話です。

詳細: レバー 1 — ステップ数を減らす(最大のレバー)

ループ 1 周には LLM 呼び出しが 1 回入るため、ステップ数の削減はそのまま倍数で効きます。

  • ツールを「1 往復で足りる」形に設計します — 呼び出し側が 3 回に分けて取りに来る細かいツール群より、よくある用途に対して必要な情報をまとめて返すツールが速くなります(ツール定義の設計 の粒度設計)
  • 独立なツール呼び出しを並列にします — 1 ターンで複数のツール呼び出しが要求されたとき、依存関係がなければ並列実行します。直列実行しか実装していないシステムは、それだけで数倍遅いことがあります
  • 毎回考えさせない — 手順が実質固定の部分は Workflow として固定し、Agent には判断が必要な部分だけを残します(Workflow 型 vs Agent 型の使い分け)。「自律性はコストとレイテンシで買う」という原点に立ち返る判断です

詳細: レバー 2 — 出力を短くする

生成時間は出力トークン数にほぼ比例します。中間ステップの出力に長い説明文を書かせているなら、それは毎ステップ課金される遅延です。

詳細: レバー 3 — TTFT とモデル選択

詳細: レバー 4 — ツール側の最適化

ツールの実行時間はそのまま総レイテンシに加算されます。遅い外部 API・重いクエリはツール側で最適化し、タイムアウトを必ず設定します(エラー処理・リトライ・フォールバック設計)。タイムアウトのないツールが 1 つあるだけで、レイテンシの上限は事実上なくなります。

設計判断: 三すくみの優先順位と「要件を外す」選択

品質・コスト・レイテンシは三すくみです。どれを優先するかをタスクごとに明示的に決めます(すべて最優先は成立しません)。

そして最も効く「最適化」は、レイテンシ要件そのものを外すことです。数分かかってよいタスクなら、非同期ジョブ型(ストリーミングと Agent の UX 実装パターン のパターン 4)に切り替えれば、残る要件は「妥当な時間内に完了通知が来ること」だけになります。同期応答の SLO と戦う前に、本当に同期である必要があるかを確認してください。

実務での注意点

アンチパターン

  • 計測せずに推測で最適化する → 支配項でない部分をいじって効果が出ず、時間だけ失う → トレースの内訳(LLM・ツール・回数)から支配項を特定してから着手する
  • 中間ステップに長文を書かせたまま高速化を探す → 生成時間は出力長に比例し、最大級のレバーを放置している → 中間出力を構造化・短文化する(品質評価とセットで)
  • 独立なツール呼び出しを直列実行する → 並列化だけで数倍改善する余地を見逃す → ツール実行系を並列対応にする
  • モデルだけ高速なものに変えて品質を測らない → 速くなったが成功率が下がり、再試行で結局遅くなる → 評価スイートで品質・コスト・レイテンシを同時に見る

チェックリスト

  • 遅いタスクのレイテンシ内訳(LLM・ツール・ステップ数)をトレースから出せる
  • 独立なツール呼び出しが並列実行される
  • 中間ステップの出力が短い形式(構造化出力等)に絞られている
  • プロンプトキャッシュが有効になっている
  • すべてのツールにタイムアウトがある
  • タスクごとに品質・コスト・レイテンシの優先順位が決まっている
  • 同期応答が本当に必要か(非同期ジョブ型にできないか)を検討した

関連トピック

参考資料

TODO・未確認事項

コスト管理バージョニング・デプロイ・モデル更新追従