用途別ベスト LLM（2026 年版）：チャット、RAG、エージェントのコスト比較

TL;DR — 「ベスト」な LLM は、ベンチマークの順位だけでは決まりません。提供するものが チャットボット、RAG／バッチ API、AI エージェントのどれかによって変わります。用途ごとに prompt の構造、hit rate、TTL との相性、許容できる latency が異なるため、最適なモデルと caching 戦略の組み合わせも異なります。本ガイドでは、パート 3 の実測値をもとに選び方を整理します。gateway も OpenAI SDK も同じままで、呼び出しごとに model フィールドを差し替えるだけです。

シリーズ：全 5 回のパート 4 · 前回：パート 1 — caching の原則 · パート 2 — provider の比較と評価 · パート 3 — 実装チュートリアル · 次回：パート 5 — LangChain との統合

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. hit rate を上げる → prompt の構造を見直し、トラフィック間隔に TTL を合わせる。
3. cache discount 係数を下げる → caching の割引率が高い provider を選ぶ。
4. cached prefill が速い provider を選ぶ → UX では latency も重要になる。

以下では、用途ごとに異なる組み合わせでこれらを調整します。

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

トラフィック特性

• 各リクエストは、長い system prompt（persona、knowledge、rules）、複数ターンの history、新しい user message で構成される。
• 平均 context は 4K～20K tokens。
• ユーザーは time-to-first-token に非常に敏感で、2 秒を超えると故障したように感じる。
• 同じ session 内のリクエスト間隔は数秒から数分。どの provider の cache TTL にも十分収まる。

チャットではほぼ自動的に cache が効く

チャットは、最も cache と相性のよい workload です。同じ session 内では次のようになります。

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 ────────↑

message 間隔が TTL 未満なら、どの provider でも数分は猶予があります。特別な対策をしなくても、system prompt 部分の hit rate は 90% 以上になります。keep-alive は不要です。

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

* 7,300-token の固定 system prompt に対する実測値。並列負荷なしの単一 sequential run。パート 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
        ],
    )

これだけです。上記の全モデルで caching は自動的に働くため、marker は不要です。開発中は resp.usage.prompt_tokens_details.cached_tokens を確認して、hit していることを検証してください。

チャットボットで陥りやすい問題

• ❌ 現在時刻を system prompt に埋め込まないでください（"Today is 2026-05-25 14:30:25"）。秒単位の値が変わるため、毎回 cache が無効になります。
• ❌ ターンごとに history を組み直さないでください。message array の順序を byte 単位で同一に保ち、追記だけにします。
• ✅ ユーザー固有の persona データは system prompt ではなく、最初の user message に置きます。ユーザーごとの差分が共有 prefix を壊さなくなります。
• ✅ session が TTL を超えて idle になる場合は、次の user message が届く前に 1-token の keep-alive ping を送ります。実装は パート 3 §8.2 を参照してください。

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

トラフィック特性

• RAG Q&A：input は、固定 system、リクエストごとに変わる retrieved docs、query で構成される。
• コンテンツ生成（marketing copy、code、translation）：template は固定で、data が変わる。
• バッチ処理（document classification、data cleaning）：同一 task を大量に処理する。
• latency は二次的で、1 call あたりのコストが最優先になる。

難所：retrieval によって prefix の順序が変わる

RAG の caching で最も難しいのは、呼び出すたびに retrieved docs が変わり、prompt の途中で prefix が一致しなくなることです。

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 — retrieved docs は前方ではなく後方に置く。

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 tokens が cache されます。呼び出すたびに miss するのは、user 向けの部分だけです。大半の本番 RAG はこれで十分です。gpt-5.4-mini でこの pattern を測定したところ、system tokens の hit rate は 80% 以上でした。

対策 B — retrieval の順序を deterministic にする。 retrieved chunks を relevance score ではなく、安定した key（doc_id の昇順）で sort します。頻繁に取得される chunk の位置が一定になり、prefix が一致しやすくなります。ranker の精度はわずかに下がりますが、通常は影響しません。

対策 C — vendor の SDK を直接使い、native の explicit-cache marker を指定する。 Anthropic Claude を直接利用する場合、この gateway を経由しなければ、複数の cache_control を使って「変更されない」「まれに変わる」「task ごとに変わる」部分を個別の breakpoint として cache できます。SDK を 1 つ追加できるなら、複雑な RAG に非常に有効です。

API workload での TTL

• 連続トラフィック（24 時間稼働の RAG endpoint）：5-min TTL で問題ありません。window 内に必ず次のリクエストが来ます。
• burst／cron（毎日 09:00 の batch）：TTL が長い provider を使います。実測対象では deepseek-v4-flash が最長でした。あるいは実行時間中、TTL/2 ごとに 1-token の keep-alive を送ります。pattern は パート 3 §8.2 にあります。

task 別の推奨モデル

† Claude の複数 cache_control marker は、階層化された RAG で他にない強みがあります。gateway に向けた anthropic SDK を使ってください。詳細は パート 3 §2 を参照してください。

RAG のコスト試算（1 日 100K queries）

3K system、5K retrieved docs、200-token query、300-token output を想定します。数値は パート 3 §6 の single-call 実測コストをもとに換算しています。single-tenant、並列負荷なしです。自分の workload では、LLM コスト計算ツール で料金を見積もり、モデル料金比較 で最新価格を確認してください。

桁感をつかむための概算です。実際の本番環境では並列呼び出しや burst があり、特に retrieved-doc の長さの分布が計算結果を大きく左右します。

RAG／API で陥りやすい問題

• ❌ retrieved chunks を 動的な relevance score で sort しないでください。リクエストごとに固有の prefix ができます。
• ❌ streaming 時に usage log を捨てないでください。コストの attribution ができなくなります。stream_options={"include_usage": True} を渡し、prompt_tokens_details.cached_tokens と usage.cost を保存します。
• ✅ batch task では、caching に加えて vendor の Batch API（OpenAI Batch、Anthropic Message Batches）を使うと、さらに約 50% 削減できます。この gateway の外から provider を直接呼び出します。

ユースケース 3：AI エージェント（複数ステップの reasoning、tool use、長い chain）

トラフィック特性

• 1 つのエージェント task で LLM を何度も呼び出し、その間に tool result が入る。
• context は非常に長く、system、tools、蓄積された history を合わせると、step 10 の時点で通常 30K～100K tokens になる。
• prompt は高度に構造化され、長い固定 prefix と短い可変 tail で構成される。
• latency とコストの両方が重要になる。prefill が 1 秒増えるだけでも待ち時間として見え、15-step agent ではそれが 15 倍になる。

エージェントでは caching が必須になる理由

各 step では、前の step の tool call と result を追記します。caching がなければ、step ごとに数万 tokens 分の prefill コストを払い直すことになります。

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 ────↑

絶対条件：tool call と result は、step 間で追記だけを行い、byte 単位で同一に保つ必要があります。書き換えたり並べ替えたりすると、その位置以降の cache が無効になります。エージェントで最も多い不具合は、「再送前に tool result を整形した」結果、cache rate がゼロになり、コストと latency が何倍にもなることです。

TTL との相性が特に重要な用途

一般的なエージェント task は 10～60 秒で完了するため、1 つの task 内では既定の 5-min TTL で十分です。ただし、「この plan を確認して返答してください」のように人間の承認を待つエージェントは、数分間 idle になることがあります。人間が 10 分離席し、その間に cache が cold になると、次の step で 50K tokens 分の prefill コストが再発生します。このような workflow では、次のどちらかを選びます。

• TTL が長い provider を使う。実測対象では deepseek-v4-flash が最長。
• 待機中に TTL/2 間隔で keep-alive ping を送る。詳細は パート 3 §8.2 を参照。

エージェント向け推奨モデル

エージェントには reasoning 能力が必要です。まず品質で選び、その後にコストを最適化します。

† Claude の 4-cache_control-marker pattern は、エージェントの caching で今も最も強力です。10 steps 以上にわたって、累積 prefix に割引を適用できます。gateway に向けた anthropic SDK を使ってください。正確な payload shape と TTL option は パート 3 §2 にあります。

実コスト試算：15-step のエージェント task

5K system、3K tools、step ごとに約 3K を追記し、合計 15 steps とします。パート 3 §6 の 1 call あたりのコストを、このエージェント構成に合わせて換算しました。

これも概算です。最大の変数は、step 間で prefix を本当に byte 単位で同一に保てるかどうかです。

エージェントで陥りやすい問題

• ❌ step ごとに messages list を再構築しないでください。array は byte 単位で同一に保ち、追記だけにします。
• ❌ tool result を短縮したり再整形したりしないでください。1 byte でも変わると、それ以降の cache が無効になります。
• ❌ 並行動作するエージェント instance 間で cache key を共有しないでください。step の順序が分岐し、互いに cache を汚染します。
• ✅ task ごとに cache_creation_tokens : cache_read_tokens を監視します。step 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 早見表

この gateway がすること、しないこと

期待値を正確に合わせるため、機能範囲を整理します。

右側の機能が今すぐ必要なら、application layer で実装するか、vendor SDK を直接使ってください。この gateway は pricing layer を備えた thin proxy です。caching に関する処理は、すべて upstream の model layer で行われます。

まとめ

シリーズ全体は、次の 4 行に集約できます。

caching の利点は 1 つではなく 2 つです。 コストと latency の両方が下がります。 固定部分を先頭に、変動部分を末尾に置きます。 prefix の規律に費用はかかりません。すべての実装で徹底してください。 用途に合わせて model と cache の特性を選びます。 チャット ≠ RAG ≠ エージェントです。 自分のトラフィックで測定します。 single-run benchmark は出発点であり、答えではありません。

ここから最短で進めるなら、上のマトリクスから自分の用途に最も近いものを選びます。固定部分を先頭に置く prefix、deterministic な retrieval、byte 単位で同一の agent state を適用してください。そのうえで cached_tokens と usage.cost を 1 週間記録し、改めて評価します。

FAQ

中国語チャットボットで最も安い LLM はどれですか？ 実測対象では、deepseek-v4-flash と qwen3.5-flash は、中国語テキストに対して英語向けモデルより 1 桁安価です。一般的なチャット workload では、品質も gpt-5.4-mini と同等でした。

2026 年に RAG で最も適した LLM はどれですか？ 英語では、gpt-5.4-mini と対策 A の prompt layout、つまり system tokens を先頭、references を末尾に置く構成を組み合わせると、固定部分で 80% 以上の hit rate が得られます。中国語なら deepseek-v4-flash です。非常に長い文書を頻繁に query する場合は、1M+ token context を native に扱える gemini-2.5-pro が向いています。

エージェントには GPT と Claude のどちらを使うべきですか？ どちらも高性能です。選択基準は、cache の最適化にどこまで取り組むかです。gateway 経由で anthropic SDK を使う Claude の 4-cache_control-marker pattern は、累積する agent prefix に特に強力です。prefix が warm になれば、10 steps 以上にわたって input cost を約 90% 削減できます。OpenAI 互換 client をそのまま使い、marker なしで約 50% の cache 削減を得たいなら、gpt-5.4-mini または gpt-5.5-pro のほうが導入しやすい選択です。

LLM の使い方を「素朴な実装」から「最適化済み」に変えると、実際にどれくらい節約できますか？ 本シリーズの実測では、同じモデルでコストを 50～88% 削減し、TTFT を 30～60% 短縮できました。効果の大半は、別のモデルを選ぶことではなく、hit rate を 80% 以上に上げることから得られます。

どこから始めればよいですか？ マトリクスから、自分の用途に最も近いものを選びます。prompt の構造を変更し、1 週間分の本番トラフィックで cached_tokens と usage.cost を測定してください。モデルの切り替えを検討するのは、その後です。

provider 間で LLM API の料金を比較するにはどうすればよいですか？ Synthorai のモデル一覧ページでは、最新料金を比較できます。provider で filter し、100 万 tokens あたりの input または output 料金で sort できます。gateway の実際の定価と常に同期しています。上のマトリクスで用途に合うモデルの種類を選び、モデル一覧ページで現在の料金を確認してください。

出典と検証：パート 3 §6 の実測値、2026-05-25 時点の https://synthorai.io/v1、openai SDK 2.38.0。vendor の料金ページ：OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian。

← ブログに戻る