OpenAI と Claude のプロンプトキャッシュの違い——仕組み・TTL・料金・効かない原因と確かめ方

プロンプトキャッシュとは、前のリクエストと先頭が同じ部分（プレフィックス）の計算結果を使い回し、その分の入力を安く・速く処理する仕組みです。OpenAI の API にも Claude の API にもありますが、有効にする方法、保持される時間、書き込みにかかる料金、効いているかの確かめ方が2社でかなり違います。同じ感覚で設計すると、片方では効いているのにもう片方では毎回書き込み料金だけを払っている、ということが起きます。

この記事では、OpenAI の「Prompt caching」「Prompt cache diagnostics」「Pricing」と、Anthropic の「Prompt caching」「Cache diagnostics」「Pricing」「Rate limits」の各ドキュメントの原文をもとに、2社の仕様の違いと、効かせ方・効いているかの確かめ方を整理します。数字はすべて2026年10月3日に原文で確かめたものです。API の料金を下げる方法の全体像（モデル選び・バッチ・出力の管理など）は、別の記事「AIの使用料を節約する方法」にまとめています。

1. プロンプトキャッシュとは——先頭が同じ部分を使い回す

言語モデルは入力を読むたびに、各トークンの途中の計算結果（KV、キーとバリューと呼ばれる値）を作ります。プロンプトキャッシュは、この計算結果をプロンプトの先頭から一定の位置まで保存しておき、次のリクエストの先頭がまったく同じなら計算を省く仕組みです。OpenAI のガイドは、保存しているのはトークンそのものではなく KV の値だと説明しています。

大事なのは「先頭から」一致している部分しか使えないことです。たとえば次の2つのリクエストでは、使い回せるのは指示文の部分だけです。

リクエスト1: [指示文 5,000トークン][資料 20,000トークン][質問A]
リクエスト2: [指示文 5,000トークン][資料 20,000トークン][質問B]
            └──────── ここまでが同じ ────────┘ └ 違う ┘
→ 指示文＋資料の25,000トークンを使い回せる

リクエスト3: [今日の日付][指示文 5,000トークン][資料 20,000トークン][質問C]
            └ 先頭が違う ┘
→ 後ろが同じでも、1トークンも使い回せない

両社のドキュメントとも、キャッシュは出力の中身を変えないと書いています。同じ答えを保存して返す仕組みではなく、入力を読む計算を省くだけです。だから、質問が毎回違うチャットや、毎回違う資料を読ませるエージェントでも、先頭の共通部分（指示文・ツールの定義・会話の履歴）があれば効きます。

2. OpenAI と Claude の違いを表で比べる

OpenAI は2026年9月22日に GPT-6 向けのキャッシュの改良を発表し、GPT-5.6 以降のモデルで仕組みが変わりました（30分の保持・明示の区切り・書き込みの有料化など）。下の表の OpenAI 側は GPT-5.6 以降の仕様です。GPT-5.5 以前の違いは表の後に書きます。

出典: OpenAI「Prompt caching」「Prompt cache diagnostics」、Anthropic「Prompt caching」「Cache diagnostics」「Rate limits」（2026年10月3日確認）

GPT-5.5 以前のモデルは、区切りが自動で一定間隔に置かれる暗黙のキャッシュだけで、書き込みの追加料金はありません。保持時間は prompt_cache_retention で選び、in_memory は「使われない状態で5〜10分ほど、長くて1時間」、24h は「たいてい30分ほど、長くて24時間」とガイドは書いています。GPT-5.6 以降へ移るときは、この設定を prompt_cache_options.ttl に置き換えます。

モデルごとの1トークンあたりの単価そのものは、料金比較の記事「Claude と ChatGPT の料金比較」で扱っています。GPT-6 の各モデル（Astra・Sol・Luna）の特徴は「GPT-6 Sol・Luna の記事」、各社の現行モデルの一覧は「AIモデルの知識カットオフ一覧」にあります。

3. キャッシュが効く条件——先頭・最小長・保持時間・分ける単位

先頭の共通部分と、並べる順番

どちらも、キャッシュが効くのは区切りまでのプレフィックスが完全に一致したときだけです。Claude は tools → system → messages の順に並べたものを先頭から見るので、ツールの定義を1つ変えるとその後ろの system と会話の履歴のキャッシュもすべて無効になります。OpenAI も、ツールの定義・出力形式（text.format）・推論の強さ（reasoning.effort）などがプレフィックスに入ると説明しています。

実際の並べ方は2社で同じで、変わらないもの（ツールの定義・指示文・資料）を先頭に、毎回変わるもの（日付・ユーザーごとの情報・質問）を後ろに置きます。会話は履歴を書き換えず、後ろに足していきます。

区切りの置き方——自動に任せるか、自分で置くか

OpenAI（GPT-5.6 以降）の暗黙モードは、直近の対象メッセージ（ユーザーのメッセージ、連続したツール結果の最後など）の末尾に区切りを置きます。明示のみのモードでは、自分で prompt_cache_breakpoint を付けた位置だけが区切りになり、1つも付けなければキャッシュは使われず、書き込み料金もかかりません。

Claude の自動キャッシュは、最上位に "cache_control": {"type": "ephemeral"} を1つ付けると、最後のキャッシュできるブロックに区切りを置き、会話が伸びるたびに区切りを後ろへ動かします。ブロックごとに cache_control を付ければ、区切りを自分で決められます。

// Claude：変わらない system の最後に区切りを置く（明示の区切り）
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "長い指示文と資料……",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "今日の質問……" }]
}

// OpenAI（Responses API）：変わらない指示文の後ろに区切りを置き、明示のみにする
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "長い指示文と資料……",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "今日の質問……" }
  ]
}

最小の長さ——短い前置きはキャッシュされない

OpenAI の GPT-5.6 以降は、見える入力で1,024トークンが最小です（OpenAI が裏で足す非公開の指示は数えない）。Claude はモデルによって違います。

出典: Anthropic「Prompt caching」Cache limitations（2026年10月3日確認）。Bedrock は AWS 側のドキュメントの値に従う。

Claude で最小に届かないと、cache_control を付けていてもエラーにならず、黙ってキャッシュされません。このとき usage の cache_creation_input_tokens と cache_read_input_tokens が両方0になります。モデルを替えたら最小も変わるので、前のモデルで効いていた前置きが効かなくなることがあります（OpenAI のガイドも同じ注意を書いています）。

保持時間——数え始めの位置に注意

OpenAI（GPT-5.6 以降）は「最後の書き込みか再利用から少なくとも30分、それより長く残ることもある」です。Claude は既定が5分で、1時間を選ぶと書き込みが入力の2倍になります。どちらも、使われるたびに追加料金なしで延長されます。

Claude には1つ落とし穴があります。保持時間はそのリクエストの開始から数え、応答の終わりからではありません。ドキュメントの例では、応答の生成に4分かかると、次のリクエストはその応答が終わってから約1分以内に始めないと5分のキャッシュに当たりません。長い出力を生成するエージェントでは、5分は見た目より短くなります。

分ける単位と、置かれる場所

OpenAI のキャッシュは組織ごとで、処理リージョン（データの所在地の指定）をまたいでは使えません。さらに、キャッシュは個々のマシンの上にあり、1分あたり15リクエストを超えると別のマシンへ振り分けられることがあるとガイドは書いています。GPT-5.6 以降は振り分けを OpenAI が自動で行い、prompt_cache_key はヒット率のためではなく、顧客ごとにキャッシュの集計を分けるための任意の設定になりました（GPT-5.5 以前では、同じキーを付けて同じマシンへ寄せることが重要でした）。

Claude API はワークスペースごとに分かれます。同じ組織でもワークスペースが違えば、同じプロンプトでもキャッシュは共有されません。Bedrock と Google Cloud では組織ごとです。また、キャッシュが使えるようになるのは最初の応答が始まってからなので、同じ前置きのリクエストを一斉に並列で送ると、最初の1本が書き込む前にほかも書き込みになります。

4. 料金と損益分岐——何回読めば得になるか

キャッシュは書き込みが入力より高いので、書いたきり読まれなければ、キャッシュを使わないより高くつきます。何回読めば元が取れるかは、書き込み倍率を w、読み取り倍率を r、書いた後に読む回数を n とすると、次の式で決まります。

キャッシュあり ＝ w ＋ n × r
キャッシュなし ＝ 1 ＋ n          （同じ前置きを n＋1 回そのまま送る）
得になる条件 ： n ＞ (w − 1) ÷ (1 − r)

入力単価を1とした倍率。倍率は OpenAI「Prompt caching」「Pricing」、Anthropic「Pricing」（2026年10月3日確認）から計算。前置き部分だけの比較で、出力と毎回変わる質問の部分は含まない。

OpenAI のガイドにも同じ計算があり、0.1倍のモデルで「1回書いて1回読むと1.35倍、キャッシュなしで2回処理すると2倍」と書かれています。Anthropic の料金ページも「5分は1回、1時間は2回の読み取りで元が取れる」と書いています。読み取りがどれだけ安くても、1時間のキャッシュは1回の読み取りでは元が取れないのは、書き込みの2倍が重いからです。

同じ入力単価のモデルで比べる——リクエストの間隔で結果が逆転する

GPT-6.1 Sol と Claude Sonnet 5.5 は、2026年10月3日時点の公式価格で入力の単価がどちらも100万トークンあたり $2、書き込み（5分）も $2.50 で同じです。違うのは読み取り（Sol $0.10・Sonnet 5.5 $0.20）と保持時間です。10万トークンの前置きを10回送るときの、前置き部分の費用を間隔ごとに計算しました。

単価は OpenAI「Pricing」の Standard・272K 以下、Anthropic「Pricing」（いずれも2026年10月3日確認）。10万トークン＝0.1（100万トークン単位）。当たるときは1回目が書き込み・残り9回が読み取り、外れるときは10回とも書き込みと仮定。OpenAI はマシンの振り分けなどで外れることもあるので、当たる行は条件がそろったときの値。

計算の中身は、たとえば GPT-6.1 Sol の3分ごとが「0.1 × $2.50（書き込み1回）＋ 0.1 × $0.10 × 9回 ＝ $0.25 ＋ $0.09 ＝ $0.34」です。この表から読み取れることは3つです。

• 間隔が5分以内なら、2社の差は小さい（$0.34 と $0.43）。差は読み取りの単価だけで決まる。
• 5〜30分の間隔では、OpenAI の30分が効く。Claude は5分のままだと毎回書き込みになり、キャッシュなしより高い $2.50 になる。1時間に切り替えれば $0.58 まで下がる。
• 間隔が保持時間より長いと、キャッシュは損になる。2時間ごとならキャッシュなしの $2.00 がいちばん安い。Claude なら cache_control を付けない、OpenAI の GPT-5.6 以降なら明示のみのモードで区切りを置かない、とすれば書き込み料金を払わずに済む。

特に OpenAI の GPT-5.6 以降は既定でキャッシュが有効なので、暗黙モードのままだと、二度と使わない入力にも書き込み料金がかかり得ます。1回きりの長い入力が多い使い方なら、usage の cache_write_tokens を見て、明示のみのモードに切り替えるかを判断します。

ほかの料金との組み合わせ

• バッチ：OpenAI の料金表には Batch・Flex にもキャッシュの入力と書き込みの単価がある（GPT-6.1 Sol の Batch は入力 $1・読み取り $0.05・書き込み $1.25）。Anthropic は、キャッシュの倍率がバッチの50%引きと重なると書いているが、バッチは順不同に並列で処理されるので、ヒットは「ベストエフォート」としている。
• 長い入力：OpenAI は入力が272Kトークンを超えると、入力・読み取り・書き込みの単価がそれぞれ2倍になる（倍率の関係は同じ）。Anthropic は Claude 4.6 以降のモデルで100万トークンまで同じ単価。
• プリウォーム：どちらも、事前に書き込んだ分は通常の書き込み料金がかかる。Claude の max_tokens: 0 は出力の料金がかからない。

5. キャッシュが効かない主な原因

2社のドキュメントの「つまずきやすい点」と、診断機能が返す理由の一覧を合わせると、効かない原因はおおむね次の3つに分かれます。

OpenAI で起きやすいこと

• 共通の前置きの後ろに区切りが無い：暗黙モードは最新のメッセージの末尾に区切りを置くので、「固定の指示文＋毎回違うユーザーのメッセージ」の形では、毎回違う部分まで含めて書き込まれ、次のリクエストで当たらない。固定部分の直後に明示の区切りを置く。
• 途中で明示のみのモードに切り替えた：明示のみのモードは自分の付けた区切りしか探さないので、暗黙モードで書いたキャッシュに当たらない。
• 同じメッセージを後ろに書き足した：「内容A」で終わっていたメッセージを「内容A＋内容B」にすると、前の区切りがメッセージの途中になり、当たらない。新しいメッセージとして足す。
• 推論の強さを途中で変えた：GPT-6 のモデルでは、リクエストの reasoning.effort は変えずに、入力の後ろに configuration_update を足すと、キャッシュを壊さずに強さを変えられる。
• コンパクション（文脈の圧縮）をかけた：先頭が変わるのでヒット率は下がる。ただしガイドは、入力が減って総額は下がることもあるので、総額で比べるよう書いている。

Claude で起きやすいこと

• 毎回変わるブロックに区切りを付けている：書き込みは区切りの位置にしか起きず、読み取りは前に書かれた位置を後ろ向きに探すだけ。毎回変わるブロックに区切りがあると、毎回書き込み料金だけを払って一度も当たらない。自動キャッシュも最後のブロックに区切りを置くので同じ罠にはまる。最後の変わらないブロックに明示の区切りを置く。
• 1ターンで20ブロック以上増えた：前の書き込みを探すのは区切りから20か所まで。会話が一気に伸びると前の書き込みが範囲の外に出る。手前にもう1つ区切りを置いておく。
• system を途中で書き換えた：対応するモデルでは、最上位の system を変えずに、messages の中に "role": "system" のメッセージを足すと、キャッシュを壊さずに指示を追加できる。
• Fast モード（speed: "fast"）と通常を切り替えた：system と会話のキャッシュが無効になる。

6. 効いているかの確かめ方——usage と診断機能

まず usage を見る——input_tokens の意味が2社で違う

どちらも、応答の usage にキャッシュから読んだ量と書き込んだ量が出ます。注意したいのは、input_tokens の意味が2社で逆なことです。

出典: OpenAI「Prompt caching」Monitor cache performance、Anthropic「Prompt caching」Tracking cache performance（2026年10月3日確認）

Claude の input_tokens を「入力の合計」と思って割り算すると、ヒット率も費用も大きく狂います。両社の数字を同じダッシュボードに並べるときは、上の式で合計をそろえてから比べます。OpenAI のガイドは、キャッシュから読んだトークンの合計を入力トークンの合計で割った値を「トークンのヒット率」として、ユーザー・日などの単位で集計するよう勧めています。

費用は、OpenAI なら「（入力 − 読み取り − 書き込み）× 単価 ＋ 読み取り × 単価 × 0.1 ＋ 書き込み × 単価 × 1.25」、Claude なら「input_tokens × 単価 ＋ 読み取り × 単価 × 0.1 ＋ 書き込み × 単価 × 1.25（1時間の分は2）」で計算できます（読み取りの倍率はモデルにより0.05などに置き換える）。OpenAI には利用状況の画面に「Prompt Caching Dashboard」があり、Anthropic も Rate limits のドキュメントで、Usage の画面でキャッシュのヒット率を見るよう書いています。

読み取りが0のときに見る順番

1. 書き込みも0か：Claude で両方0なら、最小の長さに届いていないか、cache_control が付いていない。OpenAI の明示のみのモードで区切りを置いていない場合も書き込みは起きない。
2. 書き込みだけが毎回出るか：区切りが毎回変わる位置にあるか、先頭のどこかが毎回変わっている。次の診断機能で、どこが変わったかを確かめる。
3. 前回との間隔：Claude の5分（応答の生成時間を含む）、OpenAI の30分を過ぎていないか。

OpenAI の診断——prompt_cache_diagnostics

OpenAI の Responses API では、GPT-5.6 以降の対応モデルで、prompt_cache_options.comparison_response_id に前のレスポンスの IDを渡すと、今回のリクエストとの違いを比べた結果が prompt_cache_diagnostics に入ります。追加料金はかからず、レート制限にも別に数えないとドキュメントは書いています。

// 2回目のリクエストに比較対象を付ける
{
  "model": "gpt-6.1-sol",
  "input": [ …1回目と同じ前置き…, { "role": "user", "content": "次の質問" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_（1回目のレスポンスの ID）" }
}

// 外れたときに返る例（ドキュメントの例：ツールの名前を変えた場合）
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

type は cache_hit・cache_miss・comparison_response_not_found（比較の記録が無いか期限切れ）・unavailable（結論が出ない）の4つです。外れたときの reason は次の9つです。

出典: OpenAI「Prompt cache diagnostics」Fix a cache miss（2026年10月3日確認）

Claude の診断——diagnostics

Claude API では、毎回のリクエストに diagnostics の項目を付けておく必要があります。この項目を付けたリクエストについてだけ、API が比較用の指紋（ハッシュとトークン数の推定値）を保存するからです。最初のターンは "previous_message_id": null、次からは前の応答の id を渡します。

// 2ターン目以降
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_（前の応答の id）" },
  "system": "…",
  "messages": [ … ]
}

応答の diagnostics が null なら違いは見つからなかった（または比較していない）、{"cache_miss_reason": null} なら比較がまだ終わっていない、理由が入っていれば最初に食い違った場所です。理由の種類は model_changed・system_changed・tools_changed・messages_changed・previous_message_not_found・unavailable の6つで、*_changed には失った量の目安 cache_missed_input_tokens が付きます。

Claude のドキュメントは、診断と cache_read_input_tokens を組み合わせて読むよう書いています。

出典: Anthropic「Cache diagnostics」Reading diagnostics alongside usage（2026年10月3日確認）

2社の診断には共通点が多く、どちらも「最初に見つかった違い」しか返さないので、直したらもう一度比べます。違う点は、Claude の診断が Claude API だけ（Amazon Bedrock・Google Cloud・Claude Platform on AWS・Microsoft Foundry では使えない）で、比べる相手も同じワークスペースのリクエストに限られることです。OpenAI のドキュメントには、比べられる側の前のリクエストに何かを付けておく手順は書かれていません。Claude は前のリクエストにも diagnostics を付けておかないと previous_message_not_found になります。

7. ヒット率の数字——ベンダーの例と第三者の集計

キャッシュのヒット率について出回っている数字は、どこが・どの条件で出したかで意味が大きく違います。分けて並べます。

ベンダーが出している数字

• OpenAI のガイドの例：1回きりの判定（LLM を採点役に使う処理）で、固定の採点基準の後ろに明示の区切りを置いた例が「トークンのヒット率 約70%」、ツールを何度も呼ぶエージェントの例が「90%超」。ガイドは、これは起こりうる結果の一例で、上限は使い方による、と断っている。
• OpenAI の発表（2026年9月22日）に載った顧客のコメント：Manus のチームは、区切りの置き方を見直して1週間足らずで OpenAI のモデルのヒット率が「約85%から常に90%超」になったと述べている。GitHub Copilot についてのコメントでは、この数か月で、新たに処理し直す入力の割合を以前の基準より50%超減らしたと述べている。いずれも OpenAI が自社のページに載せた顧客の声で、独立した測定ではない。
• Anthropic：ドキュメントにヒット率の実例の数字は無い。Rate limits のページに「ヒット率80%なら、入力の制限200万トークン／分で実質1,000万トークン／分を処理できる」という計算例があるが、これは仮定の算数で、測定値ではない。

第三者の集計——そのまま2社の優劣にはならない

AI の API をまとめて中継するサービスの Requesty は、自社の中継を通ったリクエストを集計し、2026年4月のヒット率を Anthropic 直接 77%（表では77.50%）、OpenAI 36%（36.40%）と公開しています（「Prompt-cache hit rate per provider, April 2026」、5月9日更新）。数字だけ見ると Claude のほうが倍以上当たっているように見えますが、この記事の比較には使えない理由が4つあります。

1. OpenAI の仕組みが変わる前の数字：OpenAI が30分の保持や明示の区切りを入れたのは9月22日で、4月の集計はそれより前のもの。
2. 使い方が違う：中継を通る利用者のアプリが、それぞれ違うプロンプトを違う間隔で送った結果で、同じプロンプトを2社に送って比べたものではない。Claude は利用者が自分で cache_control を付けた分だけが数に入る。
3. 割り算の分母：ページは「cached_tokens ÷ input_tokens」と書いているが、6章のとおり Claude の input_tokens はキャッシュ分を含まない。どう換算したかはページに書かれていない。
4. ページ内で数字が食い違う：同じページの中で、Google Cloud（Vertex）経由の Claude が24%とされる箇所と14%とされる箇所がある。

2社のキャッシュを同じ条件で比べた第三者の測定は、2026年10月3日に調べた範囲では見つかりませんでした。結局のところ、自分のアプリで当たっているかは、自分の usage で測るしかありません。6章の式でヒット率と費用を出し、外れていれば診断機能で理由を確かめます。

まとめ

OpenAI と Claude のプロンプトキャッシュは、先頭が同じ部分を使い回し、読み取りを入力の0.1倍前後にするという基本は同じです。違うのは、OpenAI（GPT-5.6 以降）が既定で有効・保持30分以上・書き込み1.25倍なのに対し、Claude は cache_control を付けたときだけ有効・保持5分（1時間も選べる）・書き込み1.25倍（1時間は2倍）なことです。

料金は、書き込みが有料なので1回も読まれなければ損になります。5分・30分のキャッシュは1回、Claude の1時間は2回読めば元が取れます。リクエストの間隔が5〜30分なら OpenAI の30分が有利で、Claude では1時間を選ぶと逆転を避けられます。間隔が保持時間より長い使い方では、キャッシュを使わないほうが安くなります。

効いているかは、usage の読み取りと書き込みの量で確かめます。Claude の input_tokens は区切りの後ろの分だけなので、合計を出してからヒット率を計算します。外れたときは、OpenAI の prompt_cache_diagnostics、Claude の diagnostics が、前のリクエストとどこが違ったかを教えてくれます。費用を下げるほかの方法は「AIの使用料を節約する方法」を参照してください。

FAQ

Q. OpenAI のプロンプトキャッシュの TTL（保持時間）はどれくらいですか？

A. GPT-5.6 以降は、最後の書き込みか再利用から少なくとも30分です。設定の prompt_cache_options.ttl は "30m" だけで、それより長く残ることもあるとガイドは書いています。GPT-5.5 以前は prompt_cache_retention で選び、in_memory は使われない状態で5〜10分ほど（長くて1時間）、24h は長くて24時間です。

Q. Claude のプロンプトキャッシュの TTL は延ばせますか？

A. "cache_control": {"type": "ephemeral", "ttl": "1h"} で1時間にできます。書き込みは入力の2倍になるので、2回以上読まれないと元が取れません。5分以内の間隔で使い続けるなら、5分のままで読まれるたびに無料で延長されます。どちらもリクエストの開始から数えるので、長い応答の生成時間も保持時間に含まれます。

Q. キャッシュを使うと答えの内容は変わりますか？

A. 変わりません。両社のドキュメントとも、キャッシュは出力の生成に影響しないと書いています。保存しているのは入力を読んだ途中の計算結果で、答えそのものではありません。同じ入力でも毎回同じ答えになるとは限らないのも、キャッシュが無いときと同じです。

Q. キャッシュを手動で消せますか？

A. どちらも消せません。OpenAI は保持時間と設定に従って期限が切れると書き、Anthropic も最短5分（1時間を選んだ場合は1時間）使われなければ自動で消えると書いています。プロンプトの中身を差し替えたいときは、先頭を変えれば次のリクエストは新しく書き込まれます。

出典

• OpenAI API ドキュメント：Prompt caching
• OpenAI API ドキュメント：Prompt cache diagnostics
• OpenAI API ドキュメント：Pricing
• OpenAI：Better prompt caching for GPT-6（2026年9月22日）
• Claude Platform ドキュメント：Prompt caching
• Claude Platform ドキュメント：Cache diagnostics
• Claude Platform ドキュメント：Pricing
• Claude Platform ドキュメント：Rate limits
• Requesty：Prompt-cache hit rate per provider, April 2026

いずれも2026年10月3日に原文を確認しました。料金・保持時間・最小の長さはモデルの追加とともに変わることがあるので、使う前に各社の料金ページで確かめてください。この記事の料金の計算は公式の単価からの算数で、筆者が API を呼んで測ったものではありません。