LLM プロンプトキャッシュ #4：チャット・RAG・エージェントの最適モデル

TL;DR —— 「最適な」LLM を選ぶことは、単一のベンチマークの問題ではありません。それは、あなたが提供するのがチャットボットなのか、RAG/バッチ API なのか、AI エージェントなのかによって変わります。それぞれの形態は、プロンプト構造、ヒット率のプロファイル、TTL の適合性、レイテンシ許容度が異なり、モデル + キャッシュ戦略の最適な組み合わせも違ってきます。本ガイドは Part 3 で実測した数値を基にしています——同じゲートウェイ、同じ OpenAI SDK、呼び出しごとに model フィールドを切り替えるだけです。

シリーズ：全 4 部の Part 4 · 前回まで：Part 1 — キャッシュの原理 · Part 2 — プロバイダー比較と評価 · Part 3 — 実践コードチュートリアル

0. 普遍的なコスト公式

ユースケースに入る前に、すべての選択が最適化すべき方程式を示します。

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

4 つのレバー：

1. 単価を下げる（P_in / P_out）→ より安価なモデルを選ぶ。
2. ヒット率を上げる→ プロンプトを再構成し、TTL をトラフィックのリズムに合わせる。
3. キャッシュ割引係数を下げる→ キャッシュ性能の強いプロバイダーを選ぶ。
4. キャッシュ済みプリフィルが最速のプロバイダーを選ぶ→ UX においてレイテンシは重要。

以下の各ユースケースは、これらのレバーを異なる形で引きます。

ユースケース 1：チャットボット、カスタマーサポート、アシスタント

トラフィックのプロファイル

• 各リクエスト = 長いシステムプロンプト（ペルソナ + 知識 + ルール）+ マルチターン履歴 + 新しいユーザーメッセージ。
• 平均コンテキスト：4K〜20K トークン。
• ユーザーは最初のトークンまでの時間に極めて敏感（2 秒超で「壊れた」と感じる）。
• セッション内では、リクエストは数秒〜数分間隔で届く——どのプロバイダーのキャッシュ TTL にも十分収まる。

なぜチャットはほぼ自動でキャッシュされるのか

チャットは最もキャッシュ向きのワークロードです。単一セッション内では：

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

メッセージ間の間隔が TTL 以内（どのプロバイダーでも数分）に収まれば、システムプロンプト部分は努力なしに 90%+ のヒット率を達成します。キープアライブは不要です。

モデル推奨（実測：2026-05）

* 7,300 トークンの安定したシステムプロンプトに対して計測、単一の逐次実行、並行負荷なし。全表は Part 3 §6 を参照。

最小限の本番コード

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

これだけです。上記のすべてのモデルでキャッシュは自動的に効きます。マーカーは不要です。開発中は resp.usage.prompt_tokens_details.cached_tokens を読んでヒットを確認してください。

チャットボットの落とし穴

• ❌ 現在のタイムスタンプをシステムプロンプトに埋め込まないこと（"Today is 2026-05-25 14:30:25"）。秒単位の精度は毎回キャッシュを無効化します。
• ❌ 毎ターン履歴を再構築しないこと——メッセージ配列の順序をバイト単位で同一に保ち、追記のみにすること。
• ✅ ユーザーのペルソナデータは最初のユーザーメッセージに置き、システムプロンプトには置かないこと——そうすればユーザーごとの差異が共有プレフィックスを汚染しません。
• ✅ TTL を過ぎて冷えたセッションには、ユーザーの次のメッセージが届く前に 1 トークンのキープアライブ ping を送ること（Part 3 §8.2 を参照）。

ユースケース 2：API ワークロード（RAG、コンテンツ生成、バッチ処理）

トラフィックのプロファイル

• RAG Q&A：入力 = 安定したシステム + 可変の検索ドキュメント + 可変のクエリ。
• コンテンツ生成（マーケティング文章、コード、翻訳）：安定したテンプレート、変化するデータ。
• バッチ処理（ドキュメント分類、データクレンジング）：大量の同一タスク。
• レイテンシは二次的；呼び出しごとのコストが支配的。

難問：検索がプレフィックスを並べ替える

RAG の中心的なキャッシュ問題：検索されたドキュメントが呼び出しごとに変化し、プロンプトの中間でプレフィックスを壊す。

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

複雑さの増す 3 つの対策：

対策 A —— 検索ドキュメントを前ではなく後ろに置く。

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

結果：system 部分全体（安定した約 3.5K トークン）がキャッシュされます。各呼び出しでミスするのはユーザー向けの部分だけです。これでほとんどの本番 RAG には十分です。gpt-5.4-mini でこのパターンを実測したヒット率：システムトークンで 80%+。

対策 B —— 決定論的な検索順序。 検索チャンクを関連度スコアではなく安定したキー（doc_id の昇順）でソートします。高頻度のチャンクが一貫した位置に留まり、プレフィックスがより頻繁に一致します。ランカーの精度をわずかに損ないますが、通常は問題になりません。

対策 C —— ベンダー純正 SDK によるネイティブな明示的キャッシュマーカー。 Anthropic Claude を（このゲートウェイ経由ではなく）直接使っている場合、複数の cache_control パターンにより「決して変わらない」+「めったに変わらない」+「タスクごとに変わる」を別々のブレークポイントとしてキャッシュできます。SDK をもう 1 つ持ち込める場合、複雑な RAG に最適です。

API ワークロードの TTL に関する考慮

• 継続的トラフィック（24/7 の RAG エンドポイント）：5 分の TTL で十分——ウィンドウ内に常に次のリクエストがあります。
• バースト / cron（毎日 09:00 のバッチ）：長 TTL のプロバイダー（deepseek-v4-flash は計測セット中で最も長寿命）を使うか、実行ウィンドウ中に TTL/2 ごとに 1 トークンのキープアライブを送ります。パターンは Part 3 §8.2。

タスク別のモデル推奨

† Claude の複数 cache_control マーカーは階層型 RAG において他に類を見ません——ゲートウェイを指す anthropic SDK を使用、Part 3 §2 を参照。

RAG コストの概算（10 万クエリ/日）

3K システム + 5K 検索ドキュメント + 200 トークンのクエリ + 300 トークンの出力。数値は Part 3 §6 で実測した単一呼び出しコストからスケールしたもの——シングルテナント、並行負荷なし。

桁感として扱ってください。実際の本番には並行呼び出しやバーストがあり、検索ドキュメントの長さ分布が計算を支配します。

RAG / API の落とし穴

• ❌ 検索チャンクを動的な関連度スコアでソートしないこと——リクエストごとに固有のプレフィックスになります。
• ❌ ストリーミング時に使用量ログを捨てないこと——コスト按分が崩壊します。stream_options={"include_usage": True} を渡し、prompt_tokens_details.cached_tokens と usage.cost を保存してください。
• ✅ バッチタスクでは、キャッシュの上にベンダーの Batch API（OpenAI Batch、Anthropic Message Batches）を重ねてさらに約 50% 削減——これはこのゲートウェイの外で、プロバイダーを直接呼んで行います。

ユースケース 3：AI エージェント（複数ステップの推論、ツール使用、長いチェーン）

トラフィックのプロファイル

• 1 つのエージェントタスク = 多数の LLM 呼び出しが、ツール結果と交互に挟まれる。
• 非常に長いコンテキスト（システム + ツール + 蓄積された履歴）：ステップ 10 までに通常 30K〜100K トークン。
• 高度に構造化されたプロンプト：長く安定したプレフィックス、小さく可変な末尾。
• レイテンシとコストの両方が重要——プリフィルが 1 秒増えるごとに目に見える待ち時間が加わり、15 ステップのエージェントではそれが 15 倍になります。

なぜエージェントはキャッシュに依存するのか

各ステップは前ステップのツール呼び出しと結果に追記します。キャッシュがなければ、各ステップは数万トークンのプリフィルを再支払いします。

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

重要なルール：ツール呼び出しと結果は、ステップ間で追記のみかつバイト単位で同一でなければなりません。書き換えや並べ替えがあると、その時点以降のキャッシュが壊れます。最もよくあるエージェントのバグは「再送する前にツール結果を整形した」→ キャッシュ率がゼロに落ちる → コストとレイテンシが何倍にもなる、というものです。

TTL の適合 —— それが重要になる唯一のユースケース

典型的なエージェントタスクは 10〜60 秒で完了します。単一タスク内ではデフォルトの 5 分 TTL で問題ありません。しかし人間の承認を待つエージェント（「この計画をレビューして返答してください」）は数分間アイドルになり得ます。人間が 10 分間止まり、キャッシュが冷えてしまうと、後続ステップは 50K トークンのプリフィルを再支払いします。そうしたワークフローでは、次のいずれかを行います：

• より長い TTL のプロバイダーを使う（deepseek-v4-flash は計測セット中で最も長寿命）、または
• 待機中に TTL/2 ごとにキープアライブ ping を送る（Part 3 §8.2 を参照）。

エージェントのモデル推奨

エージェントは推論能力を要求します——まず品質で選び、次にコストを最適化します。

† Claude の 4 つの cache_control マーカーパターンは、エージェントキャッシュにおいて依然として最強の構成です（10+ ステップにわたる累積プレフィックス割引）。ゲートウェイを指す anthropic SDK を使用——正確なペイロード形状と TTL オプションは Part 3 §2 を参照。

実コスト見積もり：15 ステップのエージェントタスク

5K システム + 3K ツール + ステップごとに約 3K 追記、合計 15 ステップを想定。Part 3 §6 の呼び出しごとコストをエージェント形状にスケール：

ここでも概算値です。支配的な変数は、あなたが実際にプレフィックスをステップ間でバイト単位で同一に保つかどうかです。

エージェントの落とし穴

• ❌ 毎ステップでメッセージリストを再構築しないこと——配列をバイト単位で同一に保ち、追記のみにすること。
• ❌ ツール結果をトリミングしたり再整形したりしないこと——どんなバイトの変化も下流のキャッシュを無効化します。
• ❌ 並行するエージェントインスタンス間でキャッシュキーを共有しないこと——ステップ順序が分岐し、互いを汚染します。
• ✅ タスクごとに cache_creation_tokens : cache_read_tokens を監視すること——ステップ 10 までに健全な比率は 1:50 以上です。

マスター意思決定マトリクス

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

ユースケース別 TTL クイックリファレンス

このゲートウェイがすること・しないこと

正直に期待値を設定するために：

右側の項目のいずれかが今日必要であれば、アプリケーション層で、またはベンダー SDK を直接使って実装してください。このゲートウェイは薄いプロキシに価格レイヤーを足したものです。キャッシュに関するすべては上流のモデル層で起こります。

最終的な要点

全 4 部のシリーズは 4 行に凝縮されます。

キャッシュは 1 つではなく 2 つの勝利。 コストとレイテンシの両方。 安定したコンテンツを先に、変動するコンテンツを後に。 プレフィックスの規律は無料、どこでも実践を。 モデル + キャッシュ挙動をユースケースに合わせる。 チャット ≠ RAG ≠ エージェント。 自分自身のトラフィックで計測する。 単一実行のベンチマークは出発点であって答えではない。

ここからの最速の道：上のマトリクスから自分に最も近いユースケースを選び、構造的な変更（安定優先のプレフィックス、決定論的検索、バイト単位で同一のエージェント状態）を適用し、cached_tokens と usage.cost を 1 週間記録してから、再評価してください。

FAQ

中国語チャットボットに最も安い LLM は？ 私たちの計測セットでは、deepseek-v4-flash と qwen3.5-flash は中国語テキストにおいて英語チューニングのモデルより 1 桁安く、典型的なチャットワークロードの品質では gpt-5.4-mini に匹敵します。

2026 年の RAG に最適な LLM は？ 英語：gpt-5.4-mini を対策 A のプロンプト配置（システムトークンを前に、参照を下に）で使うと、安定部分で 80%+ のヒット率が得られます。中国語：deepseek-v4-flash。頻繁にクエリされる非常に長いドキュメント：gemini-2.5-pro（1M+ トークンのコンテキストをネイティブに処理）。

エージェントには GPT と Claude のどちらを使うべき？ どちらも強力です。選択は、どれだけのキャッシュ規律に投資したいかによります。Claude の 4 つの cache_control マーカーパターン（ゲートウェイに対する anthropic SDK 経由）は、累積的なエージェントプレフィックスに対して比類なく強力です——プレフィックスが温まれば、10+ ステップにわたって入力コストを約 90% 削減できます。OpenAI 形状のクライアントに留まり、マーカーなしで約 50% のキャッシュ節約を受け入れたいなら、gpt-5.4-mini または gpt-5.5-pro が摩擦の少ない選択です。

「素朴な」LLM 利用から「最適化された」利用に切り替えると、現実的にどれだけ節約できる？ このシリーズの計測実行では：同じモデルで 50〜88% のコスト削減と 30〜60% の TTFT 削減。利益の大半は、別のモデルを選ぶことではなく、ヒット率を 80% 以上に引き上げることから得られます。

どこから始めるべき？ マトリクスから自分に最も近いユースケースを選びます。構造的なプロンプト変更を適用します。1 週間の本番トラフィックで cached_tokens と usage.cost を計測します。それから初めてモデルの切り替えを検討してください。

出典と検証：実測数値は Part 3 §6 より、https://synthorai.io/v1、2026-05-25 時点、openai SDK 2.38.0。ベンダー価格ページ：OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian。

← ブログに戻る