第3章 パフォーマンスとコストの最適化

学習目標

• 1件のリクエストのレイテンシを区間ごとに分解し、最も効果が大きい改善箇所を選ぶ。
• ストリーミングイベントを正しく処理し、ストリーミングが減らすものと減らさないものを区別する。
• キャッシュヒット率が上がるようにプロンプトを配置し、キャッシュの損益分岐点を計算する。
• バッチAPIと処理グレードに適したタスクを選び、結果を安全に回収する。
• モデルのグレードによるルーティングと上位モデルへの切り替え条件を設計し、レイテンシとコストのトレードオフを業務1件当たりのコストで判断する。

はじめに

あるチームは「応答が遅い」という不満を受け、最も高価なモデルに替えました。応答はさらに遅くなり、請求額は3倍になりました。別のチームはコストを減らそうとプロンプトを半分に削りましたが、品質は落ち、レイテンシはほぼ変わりませんでした。両チームの共通点は、測定前に手を加えたことです。レイテンシとコストはいくつもの区間や項目の合計であり、何が大きいかは測らなければわかりません。

本章は測定から始めます。レイテンシを区間に分ける方法とOpenAIがまとめた短縮の原則を先に確認し、体感の待ち時間を減らすストリーミング、繰り返す入力を再利用するプロンプトキャッシュ、急がない仕事を安く処理するバッチAPIと処理グレード、リクエストごとに適切なモデルを選ぶルーティングへと進みます。最後に、それらを業務1件当たりのコストという共通の尺度で比較します。

重要な概念

レイテンシを区間に分けます

ユーザーが感じる待ち時間は、複数区間の合計です。アプリケーションのキュー、入力の前処理、モデル処理、ツール実行、後処理、ネットワーク転送が順に続きます。モデル処理も、入力全体を読む段階と出力トークンを1つずつ生成する段階に分かれます。そのため、測る指標も3つに分けます。

ユーザーの立場では、「使える最初の結果」がいつ届くかも見る必要があります。最初の断片が早くても、構造化された結果の完成を待たないと画面を描画できなければ、体感の待ち時間は全体の応答時間に近くなります。ユーザーの不満はテールレイテンシ（遅延分布の遅い側の裾）で生じるため、平均よりp95（遅い側の5%との境界値）を見ます。

レイテンシを減らす7つの原則

OpenAIのレイテンシ最適化ガイドは、7つの原則を示します。ベンダーに関係なく通用する整理です。

出力がレイテンシを最も大きく左右する点が核心です。質問を繰り返す前置き、長い結び、不要な全文の書き直しは、レイテンシとコストの両方を増やします。

ストリーミングの動作

ストリーミングは、応答をサーバー送信イベント（SSE）で少しずつ受け取る方式です。荷物の発送通知が来ても到着時刻は変わらないように、ストリーミングは最初の内容を早く見せるだけで、生成するトークンの量やコストを減らしません。

Anthropicのストリームは、定められた順でイベントを送ります。message_start→ブロックごとのcontent_block_start、content_block_delta（複数回）、content_block_stop→message_delta→message_stopで、途中にpingが混じることがあります。処理時の注意点は次のとおりです。

• stop_reasonはmessage_startではnullで、message_deltaで確定します。
• message_deltaのusageは累積値です。イベントごとに加算すると過大計上になります。
• HTTP 200の後でもerrorイベント（例：overloaded_error）が届くことがあります。エラー処理をHTTPステータスコードの判定だけに依存させると、見逃してしまいます。
• イベントを直接扱う必要がなければ、SDKの集約ヘルパー（Pythonのget_final_message()、TypeScriptのfinalMessage()）で完成したメッセージを受け取ります。

OpenAI Responses APIは、response.created、response.output_text.delta、response.completed、errorなど意味ごとのイベントを送り、GeminiはSDKのストリームオプションかRESTのalt=sseでストリーミングします。

ストリーミングの経路全体を設計します

APIでストリーミングを有効にしても、ユーザーには空の画面が見える場合があります。中間層が応答をまとめてから一度に渡すと、効果が消えるためです。経路全体を点検します。

1. SSEの経路で、リバースプロキシとAPIゲートウェイの応答バッファリングを無効にする。圧縮の設定が断片をためる場合もある。
2. サーバーは受け取った断片をすぐに流す一方、画面更新は適切な単位（文、100ms）にまとめ、ブラウザーの負担を減らす。
3. ユーザーがウィンドウを閉じるかキャンセルしたら、HTTPクライアントのキャンセル信号（例：AbortController）で上流へのリクエストもキャンセルする。誰も見ない出力を最後まで生成すると費用だけが発生する。
4. 後処理が必要な結果は、断片単位で処理できるかを検討する。OpenAIは、ストリーミングによって出力内容のモデレーション（moderation）が難しくなると警告している。応答全体の確認後にのみ公開すべき内容か、先に決める。
5. ツール引数やJSONは断片を連結するが、実行と保存は完成後に検証を通ってから行う（第2章）。

プロンプトキャッシュの原理

会議のたびに同じ資料集を最初から読み直す代わりに、読んだ箇所に印を付け、新しく追加されたページだけを読むと考えてください。プロンプトキャッシュは、リクエストの先頭部分（prefix）を処理した結果を保存し、次のリクエストで再利用します。そのため、先頭部分が1文字でも異なれば、その地点からは再利用できません。

キャッシュは、出力を保存して返す機能ではありません。応答は毎回新しく生成され、OpenAIも、キャッシュが出力トークンの生成方法を変えるものではないと明記しています。この点で、以前の回答をそのまま再利用する応答キャッシュと根本的に異なります（「さらに深く」）。効果は2つです。キャッシュから読み出された入力には割引料金が適用され、入力処理の時間が減って最初のトークンが早くなります。

ベンダーごとのキャッシュ比較

Anthropicでキャッシュを使うと、input_tokensは最後のブレークポイント以降のトークンだけを表します。総入力は3つの値を合計します。

総入力トークン = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Geminiは、Interactions APIとGemini 4 Argon以降のモデルでは暗黙的キャッシュのみをサポートします。自分でキャッシュを作って管理する明示的キャッシュは、対応する以前のモデルで、generateContent APIからのみ使えます。

キャッシュヒット率を上げるプロンプト配置

3社共通の原則は1つです。変わらないものを前に、変わるものを後ろに置きます。先頭に現在時刻が1行あるだけでも、その後の数千トークンがすべてキャッシュミスになります。

1. 順序を固定する。Anthropicはtools→system→messagesの順で先頭部分を作る。ツール定義、固定指示、参考資料、例を前に置き、時刻・ユーザー情報・質問を最後に置く。
2. ブレークポイントは固定部分の末尾に置く。毎回変わるブロックに付けると、書き込みだけが繰り返される。
3. シリアライズを安定させる。ツール一覧やJSONキーの順序、空白が毎回違えば、同じ内容でも先頭部分は異なる。集合やハッシュマップからツール一覧を作ると、順序が揺れる。
4. キャッシュを無効にする変更を把握する。Anthropicでは、ツール定義の変更は全キャッシュを、tool_choiceの変更や画像の追加・削除はメッセージ部分を無効にする。最上位のeffortやoutput_config.formatの変更も無効化する。
5. 最小の長さを確認する。先頭部分がモデルの最小の長さに満たなければ、指定してもエラーなしでキャッシュされない。
6. 測定する。デプロイ前後でキャッシュ読み取りの割合を比べ、Anthropicのキャッシュ診断のように、連続するリクエストの先頭部分がどこで違ったかを示すツールを使う。

OpenAIでは、ツール一覧を維持して呼び出せる範囲だけを変えるallowed_toolsがキャッシュ維持に有利です。prompt_cache_keyは、以前のモデルではルーティングだけに影響し、GPT-5.6以降では主に顧客別のキャッシュ使用量集計に使われます。GPT-5.6以降のモデルは、既定で最新メッセージの末尾にブレークポイントを置くため、末尾が毎回変わるなら固定部分の末尾にprompt_cache_breakpointを入れる必要があります。Anthropicのキャッシュは組織間で共有されず、Claude APIではワークスペースごとにも分離されています。

キャッシュの損益分岐点

キャッシュの書き込みは通常の入力より高いため、十分に再利用して初めて得になります。先頭部分の処理コストを1とし、Anthropicの倍率で計算します。

読み取り0.1倍なら、保持時間内で5分キャッシュは2回目、1時間キャッシュは3回目から得になります（読み取り倍率がさらに低いモデルでは利点が大きくなります）。逆に、リクエストの間隔が保持時間より長いと毎回書き込みだけになり、キャッシュなしより5分キャッシュは25%、1時間キャッシュは100%高くなります。その場合は、より長い保持時間を選ぶか、キャッシュを無効にするほうが適切です。保持時間はリクエストの開始時点から数えるため、応答の生成に時間がかかると、その分残り時間が減ることも計算に入れます。スループット上の利点もあります。Anthropicの大半のモデルでは、キャッシュ読み取りトークンをITPMの制限枠に算入しないため、ヒット率が高ければ同じ上限でより多くの入力を処理できます。

バッチAPI

当日配達が不要な荷物は、安い普通郵便で送ります。バッチAPIは、即時の応答が不要な大量リクエストをまとめて非同期処理し、料金を割り引きます。

OpenAIとAnthropicは結果の順序が入力と異なることがあると明記しているため、必ず識別子で対応付けます。GeminiのAPIリファレンスは入力順に結果が来ると明記しますが、ベンダーを替えても同じコードが動くよう、キーで対応付けるほうが安全です。Anthropicはリクエストを非同期で検証するため、バッチ完了まで形式のエラーがわかりません。まず同じ形式の1件をMessages APIで試すことを勧めています。失敗したリクエストへの課金も違います。Anthropicでは、エラー・キャンセル・期限切れのリクエストは課金されず、OpenAIでは期限切れ時に未完了のリクエストがキャンセルされ、完了分だけが課金されます。キャッシュとの併用も可能ですが、Anthropicはバッチ内のキャッシュヒットはベストエフォートであり、共通コンテキストには1時間キャッシュを勧めています。Geminiのバッチの説明では、ヒットした分にコンテキストキャッシュの料金が適用されるため、実際の単価はモデルごとの料金表で確認します。バッチの上限は、同期APIの上限と別に管理されます。

処理グレードを選びます

同じモデルでも、リクエストをどのグレードで処理するか選べます。

グレードの選択は、時間の価値の問題です。評価の実行やデータ拡充など数分遅れてもよい処理は安いグレードに送り、顧客が待つ経路のうちレイテンシ目標を超える部分だけを速いグレードに送ります。速いグレードを使うなら、応答に示された実際の処理グレードを記録し、降格率を監視します。

モデルのグレードによるルーティングと上位への切り替え

すべてのリクエストを最大のモデルへ送るのは、近所へのお使いに大型トラックを使うようなものです。ルーティングとは、リクエストの性質に応じて異なるモデルへ振り分けることです。エスカレーション（escalation）とは、小さいモデルの結果が基準を満たさないときに、上位モデルで処理し直す手法です。

モデルが自ら示す確信度に、切り替えの判断を任せません。確信と正解は常に一致するわけではないためです。検証できる信号（スキーマに合格、必須の事実を含む、禁止表現がない）で判断し、経路ごとの品質・レイテンシ・コストを評価セットで別々に測ります。推論モデルなら、推論の強度も同じ方式でルーティングします。

レイテンシとコストのトレードオフを判断します

手段ごとに、得るものと差し出すものが違います。

比較の尺度は、呼び出し1回当たりではなく、業務1件当たりのコストです。

業務1件当たりのコスト = （全呼び出しのコスト + リトライ・上位への切り替えコスト + 人による確認コスト）÷ 品質基準を通った業務の件数

呼び出し単価が半分のモデルでも、リトライと人の修正が3倍になれば損です。応答期限と失敗のコストを先に決め、その範囲内で業務1件当たりのコストが最も低い組み合わせを選びます。

さらに深く

応答キャッシュはいつ危険ですか

応答キャッシュは、以前に生成した答えをそのまま返します。同じ質問が多ければ、レイテンシとコストをほぼなくせます。質問文が少し違っても、意味が似ていれば同じ答えを返す方式をセマンティックキャッシュと呼び、埋め込みの類似度で以前の質問を探します。強力な分、危険も明確です。

1. パーソナライズと権限。 答えにユーザーごとの情報が混じると、別の人に渡る可能性があります。キャッシュキーに組織、権限、言語、資料のバージョンを含めるか、パーソナライズした答えには使いません。
2. 最新性。 根拠文書が変わると、キャッシュされた答えは誤答になります。文書のバージョンをキーに含め、改訂時に該当項目を無効にします。
3. 類似度の閾値。 閾値が低いと、「返金できる期間」と「交換できる期間」のように似ていても違う質問に同じ答えを返します。閾値は誤ヒットの事例を集めた評価セットで決めます。
4. 状態を変更する操作。 ツール実行が必要なリクエストはキャッシュしません。

プロンプトキャッシュには、このような危険はありません。毎回新しく出力を作るためです。両者は競合するのではなく、層が違います。確定した情報の案内など答えが決まる一部の質問には応答キャッシュを、それ以外の会話全般にはプロンプトキャッシュを使います。

最適化実験を公平に比較する方法

最適化の効果を読み違える典型例があります。第1に、キャッシュの状態を混ぜて測ることです。最初のリクエストはキャッシュが空で、遅く高価です。空の状態と埋まった状態は別々に測ります。第2に、品質を同時に測らないことです。出力削減や小さいモデルへの変更はレイテンシとコストを減らす一方、品質を落とす可能性があります。同じ評価セットと合格基準を固定します。第3に、負荷を無視することです。同時リクエスト数でレイテンシ分布が変わるため、実際のピークに近い同時実行数でp95を測ります。第4に、一度に複数の変更を行うことです。モデル、プロンプト、キャッシュ配置を同時に変えると何が効いたかわかりません。変更1つに測定1つを原則とし、結果は業務1件当たりのコストとp95で記録します。

実務の場面

波の峰語学教室：空の画面が14秒続く理由

オンライン語学教室「波の峰語学教室」は、受講者の英作文を添削します。提出後、結果が表示されるまで平均14秒かかり、その間は画面に何も表示されない状態が続きます。運用チームは上位モデルへの変更を提案しましたが、開発者のタクさんは先に区間ごとに測りました。

API側のストリーミングは、すでに有効でした。しかし、社内APIゲートウェイがバッファリングを有効にしたままSSEを中継し、ブラウザーは完了まで何も受け取れませんでした。そして、レイテンシの大半は出力の生成でした。モデルが作文全体を修正して書き直し、その後に長い修正理由を付けていたのです。

タクさんは2点を変えました。ゲートウェイのSSE経路でバッファリングを無効にし、応答形式を「修正が必要な文、修正後の文、理由1行」の一覧にしました。全文の書き直しは、受講者が希望する場合だけ別途要求する形にしました。平均出力は950から340トークンに減りました。最初の添削項目が出るまで2.1秒、全体の完了は5.6秒となり、コストは60%減りました。評価セットでの添削の正確性は変わりませんでした。

却下した案もあります。上位モデルは出力速度がより遅かったのです。プロンプトの例を減らす案は、入力が2,000トークンほどなのでほぼ効果がないと考え、試しませんでした。

野原流通：レビューへの返信を3経路に分けます

農産物オンラインショップ「野原流通」は、1日約9,000件の商品レビューに返信案を作ります。すべてを同期APIと上位モデルで処理し、コストが増えていました。会社の方針は、通常のレビューには48時間以内、星1～2の不満レビューには30分以内の返信です。

プラットフォームエンジニアのウィさんは、応答期限で経路を分けました。

1. 不満レビュー（約11%）は同期経路へ送ります。小さいモデルが案を作り、検証器が必須要素（謝罪、対応の案内）と禁止要素（補償額の約束、未確認の原因の断定）を検査します。失敗したら中間モデルへ切り替えます。最初の週の切り替え率は14%でした。
2. 通常レビューは、毎日2回バッチAPIに投入します。レビューIDをcustom_idに入れて結果を対応付け、期限切れやエラーのものだけ次のバッチへ再投入します。
3. 返信の指針と口調の例（約3,000トークン）はプロンプトの先頭に固定し、レビュー本文と商品情報は末尾に置きます。

チームは業務1件当たりのコストで結果を比較しました。人が修正した案の確認時間も含めると、すべてを小さいモデルで処理する案は、呼び出し単価こそ最低でも、不満レビューの修正時間が増え、業務1件当たりではかえって高くなりました。最終構成のコストは、以前の31%でした。似たレビューに以前の返信を再利用する応答キャッシュも検討しましたが、注文履歴や商品状態で返信が変わるため採用しませんでした。

間違えやすいポイント

• ストリーミングはコストを減らします。 減らすのは体感の待ち時間だけで、生成トークンとコストは同じです。
• プロンプトを半分にすればレイテンシも半分です。 レイテンシは出力の長さに左右されます。入力削減の効果は通常小さいものです。
• キャッシュ保持時間を延ばせばヒット率が上がります。 先頭部分が毎回違えば、保持時間に関係なくヒットしません。順序とシリアライズから直します。
• cache_controlを付ければキャッシュされます。 モデルごとの最小の長さに満たなければ、エラーなしでキャッシュされません。使用量のフィールドで確認します。
• バッチ結果は入力順に、数時間以内で届きます。 OpenAIとAnthropicは順序を保証せず、どのベンダーでも時間は約束された範囲（最大24時間など）内でしか定まりません。識別子で対応付け、期限切れに備えます。
• キャッシュ読み取りはどこでもレート制限に数えません。 Anthropicの大半のモデルではITPMに数えませんが、OpenAIはキャッシュ入力もTPMに含めます。
• 小さいモデルから使えば常に安くなります。 上位への切り替え、リトライ、人の修正も加えた業務1件当たりのコストで判断します。

ひと目でわかるまとめ

• レイテンシはTTFT、出力速度、全体時間に分けてp95で測る。出力の長さが最大の変数である。
• ストリーミングは体感の待ち時間を減らすもの。ゲートウェイのバッファリング、キャンセル伝播、モデレーションの時点まで経路全体を見る。
• Anthropicのストリーム：stop_reasonはmessage_deltaで確定、使用量は累積値、200の後でもerrorイベントが来る。
• キャッシュは先頭部分の再利用。固定内容を前、変動内容を後ろにし、シリアライズを固定して最小の長さを確認する。
• Anthropicの5分キャッシュは2回目、1時間キャッシュは3回目から得になる（読み取り0.1倍）。間隔が保持時間より長ければ損になる。
• バッチは3社とも50%割引。OpenAI・Anthropicは順序を保証しない。識別子で対応付け、期限切れに備える。
• 処理グレード：安いグレードでは遅さ、速いグレードでは割増と降格管理が代償となる。
• ルーティングでの上位への切り替えは検証可能な信号を使い、比較は業務1件当たりのコストで行う。

公式ドキュメントで確認する

• OpenAI — Latency optimization：レイテンシ短縮の7原則と事例を読む。
• Anthropic — Streaming messages：イベントの流れ、累積使用量、エラーイベント、復旧方法を読む。
• Anthropic — Prompt caching：先頭部分の順序、保持時間、料金倍率、最小の長さ、無効化の表を確認する。
• OpenAI — Prompt caching：既定での有効化、保持ポリシー、prompt_cache_key、使用量フィールドを読む。
• Google — Gemini API context caching：暗黙的キャッシュの条件と最小トークン数を確認する。
• OpenAI — Batch API、Anthropic — Batch processing、Google — Batch API：上限、期限切れ、結果の対応付けを比較する。

セルフチェック

3-1. 1件のリクエストのレイテンシを測る際に区別する3指標を定義し、平均の代わりにp95を見る理由を書いてください。

3-2. APIでストリーミングを有効にしてもユーザーの画面に何も表示されない原因を2つ挙げ、経路上で点検する項目を書いてください。

3-3. Anthropicの1時間キャッシュ（書き込み2倍、読み取り0.1倍）で、同じ先頭部分を保持時間内に何回使えば得になるか計算し、5分キャッシュ（書き込み1.25倍）と比較してください。

3-4. プロンプトキャッシュと応答キャッシュが、それぞれ何を再利用するかを書き、ユーザー別の情報が混じる回答に応答キャッシュを使う危険と対策を説明してください。

3-5. モデルのグレードによるルーティングで、上位への切り替え条件としてモデル自身の確信度の代わりに使う信号を3つ挙げ、切り替え率が業務1件当たりのコストに与える影響を説明してください。

3-6. 応答期限が即時、4時間、3日の3業務について、処理経路（同期、処理グレード、バッチ）とモデルのグレードを選ぶ決定表を作り、各選択の根拠を書いてください。

実習課題