生成AIの入力費をキャッシュで抑える：3層設計と損益分岐点の計算方法

リード文: 長いシステム指示や社内文書を毎回モデルに読み直させず、「応答・プロンプト・検索」の3層で再利用し、品質を落とさず入力トークン費を減らす設計と測定方法を持ち帰れます。

📌 まず30秒で理解する：生成AIのキャッシュとは

生成AIのキャッシュとは、一度得た回答、検索結果、またはモデルが長い入力を読み込んだ途中状態を再利用する仕組みだ。毎朝同じ分厚い業務マニュアルを新人に最初から読ませるのではなく、付箋を挟み、前回の理解から仕事を再開してもらうイメージに近い。

できることは大きく3つある。完全に同じ質問なら完成済みの回答を返す「応答キャッシュ」、似た質問なら近い回答を探す「セマンティックキャッシュ」、毎回共通する長い入力だけモデル側で再利用する「プロンプトキャッシュ」だ。この記事では、誤回答の影響が小さい順に導入し、最後に1件あたり実効費用で効果を判定する。

なぜキャッシュで費用が下がるのか

モデルの請求は、食堂の会計に例えると理解しやすい。入力トークンは材料費、出力トークンは調理費だ。キャッシュが主に減らすのは材料費であり、回答の長さまで自動で短くなるわけではない。

OpenAIは、共通するプロンプト先頭部分の処理状態を再利用すると説明している。Anthropicも、ツール定義、システム指示、会話の順でキャッシュ地点までの接頭辞全体を対象にする。Gemini APIの暗黙キャッシュも、大きな共通内容を先頭へ置き、近い時間に似た接頭辞を送ることを推奨している。つまりベンダーが違っても設計原則は同じだ。

重要なのは、安くなる範囲を勘違いしないことだ。たとえば20ページの規約をキャッシュしても、毎回答を2,000トークン出せば出力費は残る。キャッシュは魔法の割引券ではなく、同じ下ごしらえを省く調理器具なのである。

🔄 3層をどう使い分けるか：安全側から積み上げる

いきなり「似た質問なら同じ答えでよし」とするのは危ない。まず完全一致の応答キャッシュ、次にベンダーのプロンプトキャッシュ、最後に十分な評価データを用意してセマンティックキャッシュ、という順が扱いやすい。

厳密なFAQなら、正規化した質問、モデル名、プロンプト版、ナレッジ版、権限スコープを組み合わせてキーにする。単に質問文だけをキーにすると、モデルを更新しても古い文体が残り、部署Aの回答が部署Bへ漏れる。冷蔵庫の容器に日付も名前も書かない運用は、家庭でも本番環境でもだいたい悲劇を生む。

セマンティックキャッシュは、問い合わせ文の埋め込みベクトル（文章の意味を数値の並びで表したもの）を比較する。便利だが、医療・法務・価格・在庫のように一語の差が結論を変える領域では、閾値だけに任せず対象外ルールや再検証を入れたい。

検証：まず「同じ接頭辞」を作れるか

プロンプトキャッシュの成否は、モデル選定より先に入力の並べ方で決まる。固定のシステム指示、ツール定義、共有文書を前へ、ユーザーID、現在時刻、今回の質問を後ろへ置く。前半に現在時刻を差し込むと、毎回違う本の1ページ目を渡すようなもので、後ろに何万トークン同じ文章があっても再利用しにくい。

もう一つの境界条件は長さだ。各社・各モデルにはキャッシュ可能な最小入力長があり、OpenAIの現行ガイドはGPT-5.6以降で可視入力1,024トークン、Gemini APIの現行ガイドはモデルにより2,048または4,096トークンを示している。AnthropicとAmazon Bedrockもモデルごとに下限が異なる。短い定型文を水増ししてまでキャッシュするのではなく、短いものは応答キャッシュ、長い共通知識はプロンプトキャッシュへ振り分けよう。

結果の見方：割引率より「損益分岐点」を計算する

「キャッシュ入力が90%引き」という数字だけでは導入判断はできない。書き込みが通常入力より高い場合があり、さらに明示キャッシュには保存費が付くサービスもあるからだ。必要なのは、同じ内容がTTL（Time To Live、キャッシュが有効な時間）内に何回読まれるかである。

キャッシュ対象を通常処理した費用を U、書き込み倍率を W、読み出し倍率を R、総リクエスト数を N とすると、単純化した比較は次の通りだ。

キャッシュなし = N × U
キャッシュあり = W × U + (N - 1) × R × U + 保存費

たとえば W=1.25、R=0.10、保存費なしなら、2回使うだけで 2U に対して 1.35U となる。一方、1回しか使わなければ 1.25U で逆に高い。これはOpenAIとAnthropicの現行ドキュメントにある5分キャッシュの代表的な倍率と整合するが、料金と対応モデルは変わるため、本番では必ず利用モデルの料金表を代入してほしい。

測定ではヒット率だけでなく、cache_read_tokens、cache_write_tokens、未キャッシュ入力、出力、保存時間を分ける。名称はサービスごとに異なり、OpenAIはレスポンスの利用量内にキャッシュ済みトークンを、Anthropicは作成・読み出しトークンを、Bedrockは cacheReadInputTokens と cacheWriteInputTokens を返す。メーターを見ずに最適化するのは、目隠しで家計簿をつけるようなものだ。

💡 活用事例：どの仕事から始めると効くか

最初の候補は、「長い共通部分があり、短時間に何度も使い、回答自体は毎回変えたい」仕事だ。社内規約への質問、コードベースを読むエージェント、長い文字起こしの分析、固定ツール群を持つカスタマーサポートは、この条件に合いやすい。

たとえば同じ就業規則へ部署ごとに異なる質問を投げる場合、回答全体を使い回すと危険だが、規則を読んだ途中状態なら安全に再利用しやすい。Google CloudのVertex AIも暗黙・明示の両方式を提供し、明示キャッシュでは有効期限を管理できる。Amazon Bedrockも暗黙・明示を区別し、明示方式ではモデル固有のチェックポイントを置く。クラウドをまたいでも、「共通部分を先頭へ」「ヒットを利用量で確認」という習慣は持ち運べる。

🔥 ハマりポイント：安くしたつもりが高くなる4つの罠

キャッシュは置けば終わりではない。むしろ、古い回答を速く配る装置にもなれるため、無効化の設計が本体と言ってよい。

並列実行にも注意したい。Anthropicは、最初の応答が始まるまで新しいキャッシュ項目を後続要求が利用できないとしている。同じ巨大プロンプトを100並列で一斉に投げれば、初回の1件だけが書き込み役になるとは限らない。ウォームアップを1件完了させてからファンアウトする、同一キーの同時生成をまとめる、といった制御が効く。

また、キャッシュには機密情報が入り得る。TTLを短くすれば認可が不要になるわけではない。保持場所、データ保持方針、地域境界、削除手段をサービスの公式文書で確認し、アプリ側の応答キャッシュは暗号化とアクセス制御の対象にする。

🚀 取り込み方：今日・今週・今月の3段階

最初から全APIをキャッシュ化する必要はない。費用上位の1フローだけを選び、「読んだ量」と「再利用した量」が観測できる状態を先に作ろう。

実装前には、利用中のサービスに対応する公式ガイドを開く。OpenAIなら Prompt caching、Anthropicなら Prompt caching、Gemini APIなら Context caching、Bedrockなら Prompt caching が出発点だ。モデルごとに最小トークン数、TTL、書き込み倍率が異なるため、コードより先にこの4項目を表へ写そう。

評価指標は次のように揃えると、単なる「割引された気がする」から卒業できる。

cache_hit_rate        = cache_read_tokens / cache_eligible_tokens
effective_cost        = input_cost + cache_write_cost + cache_read_cost
                        + output_cost + storage_cost
cost_per_good_answer  = effective_cost / 品質基準を満たした回答数

最後の cost_per_good_answer が肝だ。セマンティックキャッシュで誤回答が増え、人手確認が倍になれば、API代だけ下がっても事業の費用は下がっていない。

✅ まとめ：キャッシュは「安い記憶」ではなく「再利用の設計」

キャッシュ費用の最適化は、割引機能をオンにする作業ではない。何を同一とみなすか、いつ古くなるか、誰が読めるかを決める設計である。

これを読んだあなたは、生成AIの処理を応答・セマンティック・プロンプトの3層に分け、再利用回数から損益分岐点を計算し、費用を下げても品質と認可を壊さない小規模な検証を始められる。まず今日、最も長い共通プロンプトを1本だけ見つけよう。

参考文献

1. OpenAI Developers, “Prompt caching”（2026年9月27日閲覧）
2. Anthropic, “Prompt caching”（2026年9月27日閲覧）
3. Google AI for Developers, “Context caching”（2026年9月27日閲覧）
4. Google Cloud, “Context caching overview”（2026年9月27日閲覧）
5. Amazon Web Services, “Prompt caching for faster model inference”（2026年9月27日閲覧）
6. Microsoft Learn, “Prompt caching”（2026年9月27日閲覧）