SPKE向けにAIを活用して制作したオリジナルのコンセプトイラストです。枝は再利用と有効期限切れを表しており、性能の測定結果ではありません。
まず、実際のワークロードを見る
あるアプリケーションが、同じ文書について十の質問を処理します。開発者はキャッシュ済み入力の安い単価を見て、請求額も同じくらい大きく減ると期待します。しかし、その期待には重要な確認が抜けています。再利用できるプレフィックスは実際にキャッシュへ書き込まれたのか。各リクエストはそれに一致したのか。有効期限が切れる前に再利用できたのか。
私たちの結論は、最も大きく宣伝されているキャッシュ割引率ではなく、現実的なリクエスト間隔のもとで、品質基準を満たしたタスクにかかる費用を比較すべきだ、というものです。本稿は、日付の記載がなく随時更新される公式ドキュメントを2026年10月22日に確認したうえでの分析であり、計算例は明示的に仮定を置いたものです。SPKEはプロバイダー間のベンチマークを実施していません。ドキュメントは随時更新されており、確認日は資料の公開日、発表日、適用開始日を意味しません。
中国と米国のAPIを、役立つ軸で比較する
米国のOpenAIとAnthropic、中国のDeepSeekでは、利用者が制御できる項目が異なります。プロバイダーの出身国だけでは、アプリケーションに合う設定は分かりません。具体的なモデル、API、キャッシュの有効期間、ワークロードを比較してください。
OpenAIの現行ガイドは、GPT-5.6以降とそれ以前のモデルを区別しています。新しいモデルには割増のキャッシュ書き込み料金があり、キャッシュ照合の対象となる境界が定められています。「OpenAIのキャッシュ書き込みには追加料金がかからない」という従来の一律の理解は、もはや安全ではありません。OpenAIのガイド
Anthropicはキャッシュの有効期間が5分の場合と1時間の場合で異なる書き込み料金を示しており、読み出し料金もモデルによって異なります。そのため、プロバイダー全体に一つの割引率を当てはめるだけでは予算を組めません。Anthropicの料金
DeepSeekの例では、A+Bに続くA+Cはキャッシュにヒットせず、その後、保存された共通部分Aを使ってA+Dに応答できるようになります。同じテキストが繰り返されるだけでは十分ではありません。DeepSeekのキャッシュ
こうした違いを踏まえると、調達時に問うべきなのは「どちらの国のAIが安いか」よりも、「必要な品質を保ちながら、私たちの実際のリクエストを確実に再利用できる実装はどれか」です。これはエンジニアリング上の比較であり、国ごとの技術力の順位づけではありません。
単価の割引率と請求額の削減率は違う
以下は単純化した計算例であり、実際の価格見積もりではありません。キャッシュの対象となる、完全に同一のプレフィックス一つだけを考えます。初回の書き込みを含むリクエスト総数をn、通常の入力料金に対する書き込み料金の倍率をw、読み出し料金の倍率をrとします。書き込みは1回、その後のn−1回はすべてプレフィックス全体の読み出しに成功し、有効期限切れや再書き込みはないと仮定します。
費用を正規化した単位で表すと、キャッシュなしの費用はn、キャッシュありの費用はw + (n−1) × rです。0 ≤ r < 1の場合、n > (w−r)/(1−r)であればキャッシュのほうが安くなります。
仮にw = 1.25、r = 0.1とすると、10回のリクエストの費用は10単位ではなく2.15単位になります。読み出し1回あたりは90%安くても、プレフィックス全体の費用削減率は78.5%です。w = 2、r = 0.1なら、節約には合計3回以上のリクエストが必要です。w = 1.25なら2回で足ります。
これは理想的な条件における、プレフィックス部分だけの損益分岐点です。動的な入力、生成された出力、ツール、再試行、繰り返しの書き込みによって、タスク全体の結果は変わります。プレフィックスの費用を下げても、追加の修正作業が必要になる設定では、全体として割高になるかもしれません。予算を組む前に、仮定の倍率を、利用するモデルの現行料金に置き換えてください。
再利用には三つの形がある
一つ目は、保持された履歴にやり取りを追加していく逐次的な会話です。二つ目は、共通の文書から独立した質問が枝分かれする形です。三つ目は、再利用できるキャッシュがまだ準備できていない状態で並列バッチを開始する形です。繰り返し使うトークンの量が同じでも、これらは同じワークロードではありません。
Anthropicでは、最初のレスポンスが始まってからキャッシュが利用可能になり、5分間のキャッシュの有効期間はリクエスト開始時点から数えられます。そのため、リクエストを送るタイミングや回答の長さが重要になります。Anthropicのキャッシュ
設計上の推奨事項は、固定の参照資料と毎回変わる質問を分離し、境界を一定に保ち、実際のリクエスト順序で検証することです。影響を確かめずに、固定コンテンツの前にタイムスタンプやリクエストIDを挿入しないでください。ウォームアップ用の呼び出しも無条件に追加すべきではありません。それ自体がリソースを消費し、利用者が後続のリクエストを送るとは限らないからです。
本番導入前の受け入れ検証計画
品質基準を満たすことを確認した同一のタスク群を、コールドスタート、ウォーム状態での再利用、実際にあり得る待ち時間、同時リクエストの四つの条件で使います。これは提案する検証計画であり、私たちが実施した実験ではありません。
- モデルとバージョン、API、リクエスト構造、キャッシュ設定、サービス階層を記録します。内容と品質基準は比較可能な状態にそろえます。
- プロバイダーの使用量フィールドを、通常入力、キャッシュ書き込み、キャッシュ読み出しに整理します。合計する前に各フィールドの範囲を確認し、二重計上を避けます。入力のヒット／ミスだけを示すプロバイダーについては、別建ての書き込み料金を推測で設けないでください。
- 品質基準を満たしたタスク1件あたりの総費用を、失敗した試行、出力、ツールも含めて算出します。不合格となったタスクも報告し、安い失敗が見かけの成績を良くしないようにします。
- 最初のトークンまでの時間と処理全体の所要時間を測定し、p95などの遅い側の値も含めます。コールド状態とウォーム状態の結果は分けて報告します。
- プレフィックスの境界、待ち時間、同時実行数など、変更する要因は一度に一つにします。比較の基準を残し、キャッシュミスの理由を記録します。
何を選び、何を結論づけないか
品質とレイテンシーの要件を満たす設定の中から、実測のタスク費用が最も低いものを選びます。高いヒット率だけでは成功とはいえません。必要以上に大きいプロンプトを繰り返せば、ヒット率を上げながら、すべてのタスクを無駄に高くすることもできてしまいます。
中国と米国のAPIを比較するチームにとって、ほかの比較にも活用できる資産は、再現可能なワークロードと共通の基準で整理した費用台帳です。キャッシュ済みトークンの安い単価も、キャッシュヒットも、回答の品質が高い証拠にはなりません。本稿が示すのは意思決定の方法であり、勝者となるプロバイダーではありません。