価格表の「入力単価」だけでは、エージェントの請求額は読めない。 GPT-5.6世代を評価する際に重要なのは、通常入力、キャッシュ済み入力、出力、そして待ち時間を許容する処理の経路を分けて見ることです。
Sol / Terra / Lunaという世代内の選択肢を含め、モデル名や提供条件は変わり得ます。本稿は特定のモデルの金額を転載して固定化するのではなく、OpenAIの公式料金ページに示されるCached Input の通常入力比90%割引、Flex処理、Batch APIという価格構造を、エージェント運用の意思決定へ翻訳します。
研究要旨（要約、直接引用ではありません）
“Don’t Break the Cache” は、500超のエージェントセッションを対象にOpenAI・Anthropic・Googleのプロンプトキャッシュを比較し、APIコストを41〜80%、Time to First Token（TTFT）を13〜31%改善したと報告しています。一方、動的なツール結果を無造作に含めるフルコンテキストキャッシュは、かえってレイテンシを悪化させる場合があり、変動部分を後方へ置くなどのキャッシュ境界設計が重要だと示しています。
※arXiv:2601.06007のAbstractを、引用ではなく要約したものです。
出典 arXiv:2601.06007（研究内容の参照先）。
1. まず確認したい事実：価格改定は「モデル単価表」ではない
APIの請求は、入力と出力の量だけで決まりません。共通プレフィックスがプロバイダーの条件を満たして再利用されたか、即時実行を要求したか、非同期の一括処理に回せたかで、同じ業務でも異なる経路になります。Cached Input 90%割引は、通常入力単価を P としたとき、キャッシュヒットした入力を概ね 0.1P として扱う構造です。これは「全入力が9割安い」という約束ではありません。
| 費目 | 見るべき条件 | 運用上の意味 |
|---|---|---|
| 通常入力 | 新規に計算するトークン | プロンプト設計・検索結果・ツール出力の増分が効く |
| Cached Input | 共通プレフィックスとキャッシュ条件の充足 | ヒット率を実測しなければ予算には使えない |
| 出力 | 生成長・思考過程を含む提供仕様 | 入力割引だけでは抑えられない。上限設計が要る |
| Flex / Batch | 遅延許容、各サービスの受付・完了条件 | 緊急性の低い仕事を即時経路から外す選択肢 |
GPT-5.6の標準価格――キャッシュ読取は通常入力の10分の1
OpenAIの公式料金ページが2026年8月25日時点で示す短文脈・Standardモードの価格は、次のとおりです（USD / 100万トークン）。FlexとBatchでは各費目がStandardの50%となり、待ち時間を許容できる処理にはもう一段の削減余地があります。なお、Solの表示価格は少なくとも2026年11月21日までのプロモーション価格と注記されています。
| モデル | Input | Cached Input | Cache Write | Output |
|---|---|---|---|---|
| GPT-5.6 Sol | $4.00 | $0.40 | $5.00 | $20.00 |
| GPT-5.6 Terra | $2.00 | $0.20 | $2.50 | $12.00 |
| GPT-5.6 Luna | $0.20 | $0.02 | $0.25 | $1.20 |
2. KVキャッシュは何を省き、何を消費するのか
Transformerは入力をトークンごとに処理する際、各層のKeyとValueを次トークン用に保持します。これがKVキャッシュです。同一の先頭部分を持つ後続リクエストでは、その部分の再計算を避けられるため、長いシステム指示、固定のツール定義、共通知識を含む入力ほど効果が出ます。
ただし「キャッシュ」は無料の魔法ではありません。保持にはGPUメモリまたはそれに準じる資源が必要で、キャッシュの寿命、最小プレフィックス長、完全一致が求められる範囲、並列リクエストへの扱いはプロバイダーごとに異なります。可変の日時、ユーザーごとに順序が変わるツール定義、毎ターン全文を差し替える履歴は、ヒットを壊しやすい要因です。
- 不変のシステム指示・安全方針・ツール定義を先頭に固定する
- 顧客データ、検索結果、今回の指示など変動部分は後ろへ寄せる
- キャッシュの可否ではなく、実際の cached / uncached input token をログで分けて観測する
- キャッシュ共有の可否とデータ保持条件を、性能要件とは別にセキュリティ審査する
3. エージェントの実効コストは「ヒット率×反復回数」で決まる
実効入力単価は、通常入力比率を 1 − h、キャッシュヒット率を h、キャッシュ価格比を c と置けば、おおまかに P × ((1 − h) + c × h) と表せます。90%割引なら c = 0.1 です。しかしエージェントでは、この入力単価にターン数、各ターンで追加されるツール結果、出力、失敗した再試行が掛かります。
したがって、9割のキャッシュ割引を前提に予算を組むより、まずキャッシュ非ヒットでも成立する上限を設ける方が安全です。ターン上限、ツール出力の要約、重複検索の除去、失敗時の指数バックオフ、タスク単位のトークン予算を同時に導入します。割引は達成できたときの改善分として扱います。
4. 主要3社を比較する際は、価格表ではなく適用単位をそろえる
OpenAI、Anthropic、Googleはいずれも、長い共通コンテキストや非同期処理に対応する仕組みを公開しています。しかし、キャッシュの作成方式、TTLや課金、BatchのSLA、モデル別の対応範囲は同一ではありません。「1Mトークンあたり」の数字だけを横並びにすると、条件の違う割引を比較してしまいます。
| 観点 | OpenAI | Anthropic | |
|---|---|---|---|
| 共通入力の最適化 | Cached Input の適用条件を公式仕様で確認 | Prompt Caching の作成・読取条件を確認 | Context Caching の保存・利用条件を確認 |
| 遅延許容処理 | Flex / Batch の対象と完了条件を確認 | Message Batches の対象と期限を確認 | Batch の対象サービスと期限を確認 |
| 比較の単位 | モデルID・通常/キャッシュ/出力を分離 | 書き込み・読み取りを分離 | キャッシュ保存・利用と生成を分離 |
5. ワークロードごとに選ぶ：即時、再利用、後処理を混ぜない
顧客対応のように応答時間が価値そのものになる処理は、品質・レイテンシ・データ境界を優先して即時経路へ置きます。長い共通ルールの下で多数の問い合わせを扱う処理は、プレフィックスを安定させ、キャッシュの観測値をもとに最適化します。評価、再要約、タグ付け、夜間レポートのように待てる仕事は、BatchやFlexを候補にします。
一つのエージェント内でも、分類は軽量モデル、難所の判断は高性能モデル、実行ログの要約はバッチ処理へ分けられます。こうした経路選択を各アプリケーションに散在させず、利用モデル、データ区分、予算、監査ログを一元化するゲートウェイ層で制御すると、価格改定時にも差し替えと検証を行いやすくなります。RiN Gatewayのような共通ゲートウェイを検討する場合も、最初に必要なのは特定ベンダーへの固定ではなく、実測可能なルーティング方針です。
図3中央の試算は、GPT-5.6 SolのStandard・短文コンテキストで、100万トークンの固定プレフィックスを計4回送る単純化した例です。すべて通常入力なら $4.00 × 4 = $16.00、初回をCache Write、後続3回をCached Inputとすると $5.00 + $0.40 × 3 = $6.20 です（61.25%減）。出力トークンと各リクエストの変動部分は含みません。
6. まとめ：キャッシュ割引を「設計の余白」として使う
GPT-5.6世代の価値を、モデル名や単価だけで測るべきではありません。Cached Input 90%割引は、共通プレフィックスを安定させられる仕事では大きな余白になります。一方で、ツール結果が積み重なるエージェントでは、ヒット率と反復回数を測らなければ実効コストを見誤ります。即時処理、キャッシュ前提の反復処理、遅延許容の一括処理を分離し、複数プロバイダーを同じ計測単位で比較すること。それが価格改定に振り回されないマルチLLM推論の出発点です。
よくある質問
Cached Input 90%割引なら、入力コストは常に10分の1ですか？
いいえ。割引はキャッシュ条件を満たして再利用された入力部分に限られます。通常入力、出力、キャッシュ対象外の変動部分、再試行は別に発生します。請求・利用ログで cached input tokens を分けて確認し、非ヒット時でも予算内に収まる設計にしてください。
KVキャッシュを効かせるために、全会話履歴を毎回送るべきですか？
必ずしもそうではありません。長い履歴は出力品質に必要な文脈を含む一方、メモリ、入力、ターン数を増やします。不変部分を固定し、古い履歴やツール出力は要約・削除し、必要資料だけを取得する設計が有効です。実測した品質、ヒット率、総トークンで判断します。
OpenAI、Anthropic、Googleのどれを選べば最も安くなりますか？
一律の答えはありません。モデルの品質、出力長、キャッシュの作成・読取条件、遅延許容度、データ処理条件で結果が変わります。同じ代表タスクを用意し、通常入力・キャッシュ済み入力・出力・所要時間・失敗率を分けて比較してください。単価ではなくタスク完了あたりのコストで評価することが重要です。
参照した一次情報
OpenAI
- OpenAI API Documentation, “Pricing.”（GPT-5.6 Sol / Terra / Luna、Standard / Batch / Flex料金） https://developers.openai.com/api/docs/pricing
- OpenAI, “Advancing the price-performance frontier with GPT-5.6,” July 30, 2026. https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/
- OpenAI API Documentation, “Batch API.” https://developers.openai.com/api/docs/guides/batch
- OpenAI API Documentation, “Flex processing.” https://developers.openai.com/api/docs/guides/flex-processing
arXiv
- arXiv, “arXiv:2601.06007.”（本文では内容を要約して参照） https://arxiv.org/abs/2601.06007
Anthropic
- Anthropic Documentation, “Prompt caching.” https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Anthropic Documentation, “Message Batches.” https://platform.claude.com/docs/en/build-with-claude/batch-processing
Google Cloud
- Google Cloud Documentation, “Context caching overview.” https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/context-cache/context-cache-overview
- Google Cloud Documentation, “Batch inference.” https://docs.cloud.google.com/gemini-enterprise-agent-platform/reference/models/batch-prediction-api
記事情報
| 執筆 | 久坂 祐介（株式会社Metelix 代表取締役CEO / CAIO） |
|---|---|
| 技術監修 | 株式会社Metelix エンジニアリングチーム |
| 公開日 | |
| 最終更新日 | |
| 分類 | 技術解説・インフラ試算 |
| 利害関係 | 本記事は、AIゲートウェイ製品であるRiN Gatewayを提供する株式会社Metelixが執筆しています。本文の各社資料は、それぞれの組織が公開した一次情報を参照しています。 |
| 評価時点 | 2026年8月25日。料金、対応モデル、キャッシュ・Flex・Batchの適用条件は変更される場合があります。購入・実装時は各社の最新の公式文書および契約条件をご確認ください。 |
関連記事
- 2026.08.17｜解説DeepSeek最大1,100%値上げの真相――エージェント時代における「KVキャッシュ頼み」の終焉と現場の生存戦略
- 2026.08.03｜解説MCP最大の改訂は「認可」だった——社内SaaSをすべてRAGに入れてはいけない理由
- 2026.08.25｜解説【富士通PHOTONの衝撃と真実】「最大475倍」は何を変えるのか？――トランスフォーマーのKVキャッシュ限界に挑む国産階層型AI
改訂履歴
| 初版公開 |