MCPプロンプトキャッシュでエージェントコスト90%削減 2026 — Anthropic公式仕様と実装の落とし穴

なぜMCP統合はトークンを焼くのか

MCPサーバーを本番運用しているチームの請求書を見ると、ある違和感に気づく。ユーザーが何も入力していないのに、入力トークン数が膨らんでいる。原因は単純で、MCPツール定義(name・description・inputSchema・annotations)は、ユーザーメッセージの前にプロンプト先頭に毎リクエスト含めて送信されているからだ。

公開されている調査では、MCPサーバー5本・58ツールで55,000トークン以上がユーザー入力前に消費される。Jiraなど追加統合を入れると100,000トークン超のコンテキスト窓がツール定義だけで埋まる ✅(Merge CTO・GitHub MCP実測の検証はこちら)。これがエージェント運用コストの「見えない床」を作っている。

Anthropic公式仕様 — cache_write と cache_read の経済

Anthropic公式ドキュメントによる仕様を整理する ✅。

• cache_read(キャッシュにヒットした入力トークン)= 通常入力トークンの0.1倍、つまり90%削減。
• cache_write(キャッシュを初めて書き込むトークン)— 5分TTLでは1.25倍、1時間TTLでは2倍のコスト。
• cache_write は次回以降のリクエストでヒットしたときに回収される。5分TTL(1.25x)は2回目の読み込みで損益分岐、1時間TTL(2.0x)は3回目以降で損益分岐 ✅。
• 最小キャッシュ可能トークン数はモデル依存:Sonnet/Opus = 1,024トークン、Haiku = 2,048トークン。それ未満はキャッシュ対象にならず通常価格 ✅。

計算例を一つ。Opusで100Kトークンの固定プレフィックスを毎リクエスト送るエージェントを考える。キャッシュなしなら毎回フルプライスで100K入力。5分TTLキャッシュを入れると、初回だけ100K × 1.25 = 125K相当の入力コスト、以降のキャッシュヒット時は100K × 0.1 = 10K相当に圧縮される。2回目以降の入力コストは10%——これが「最大90%削減」の正体だ ✅。

cache_control をどこに置くか — tools → system → messages

Anthropicはプロンプトを tools → system → messages の順序でキャッシュキーを構築する ✅。これは決定的に重要だ——前から順にキーが組み上がり、途中で動的トークンが混入するとそこから後ろは全てキャッシュミスになる。

MCP統合では、最後のツール定義に cache_control: {type: "ephemeral"} を付与する。これでツール定義全体が1ブロックとしてキャッシュされる。

// Anthropic Messages API — cache_control を最後のツールに付与
const response = await anthropic.messages.create({
  model: "claude-opus-4-7",
  max_tokens: 4096,
  tools: [
    { name: "tool_a", description: "...", input_schema: {...} },
    { name: "tool_b", description: "...", input_schema: {...} },
    // ... 58個のツール ...
    {
      name: "tool_last",
      description: "...",
      input_schema: {...},
      cache_control: { type: "ephemeral" }  // ← ここでツール全体をキャッシュ
    }
  ],
  system: [
    {
      type: "text",
      text: "長い指示プロンプト...",
      cache_control: { type: "ephemeral" }  // ← systemもキャッシュ対象に
    }
  ],
  messages: [{ role: "user", content: "..." }]
});

// レスポンスでヒット率を確認
console.log(response.usage);
// {
//   input_tokens: 320,                      ← 非キャッシュ入力
//   cache_creation_input_tokens: 55200,     ← 初回書き込み
//   cache_read_input_tokens: 0,             ← 2回目以降は反転
//   output_tokens: 250
// }

原則は「変化しない部分を後ろから順にマークする」。プロンプトの先頭から順にキャッシュキーが構築されるため、cache_control を付けた地点までが1ブロックでキャッシュされる。MCP統合では tools が最も大きく安定しているため、tools の末尾に cache_control を置くのが標準。長いsystem指示があるならその末尾にも追加する。

動的な値(タイムスタンプ・セッションID・ユーザー名)はキャッシュ可能領域の後ろ、つまり messages 側に置く。プレフィックスに動的トークンを埋め込むとそこから先は全てキャッシュミスになる。

プロンプトキャッシュが逆効果になる4つのケース

「最大90%削減」は理想ケース。実運用では以下の4パターンで逆にコストが増える。

ヒット率の計測と最適化ループ

キャッシュは「設定して終わり」ではない。ヒット率を継続計測し、ミスの原因を特定するループが要る。

Anthropic APIのレスポンスには usage オブジェクトが含まれ、cache_creation_input_tokens(書き込み)と cache_read_input_tokens(読み出し)が分離してカウントされる ✅。ヒット率の式は単純だ:

hit_rate = cache_read_input_tokens
         / (cache_read_input_tokens + input_tokens + cache_creation_input_tokens)

// 例: { input_tokens: 320, cache_creation: 0, cache_read: 55200, output: 250 }
//   → hit_rate = 55200 / (55200 + 320 + 0) = 99.4% (理想)

// 例: { input_tokens: 320, cache_creation: 55200, cache_read: 0, output: 250 }
//   → hit_rate = 0% (キャッシュミス。プレフィックスが毎回変わっている)

公開ケーススタディでは、安定したエージェントワークロードで74-84%のヒット率が再現性ある目標水準として報告されている ✅。これに届かないなら、上の表の上から順に診断する。

いくら削減できるのか — 現実的なシミュレーション

仮にOpus 4.7で1日10,000リクエスト、各リクエストの固定プレフィックス(MCPツール定義+system) = 80,000トークン、ユーザー入力 = 500トークン、出力 = 1,000トークンとする。プロンプトキャッシュなし、5分TTLキャッシュあり、1時間TTLキャッシュあり、の3シナリオを比較する(Opus価格は公式ドキュメント基準 ✅)。

これは入力トークン部分の試算であり、出力トークンには適用されない。それでもエージェント運用は入力寄りのワークロードがほとんどで、固定プレフィックスが大きいほどキャッシュの効きは強い。

FAQ

Anthropicのプロンプトキャッシュで本当に90%コスト削減できますか？

公式仕様上は「キャッシュにヒットした入力トークンに対して」最大90%です。cache_read は通常入力の0.1倍 ✅。ただし全体削減率はヒット率に依存し、安定エージェントでは74-84%程度の実測ヒット率が報告されています。出力トークンには適用されません。

MCPサーバーを使うとなぜトークン消費が膨らむのですか？

MCPツール定義(name・description・inputSchema・annotations)がユーザー入力前にプロンプト先頭に毎リクエスト送信されるためです。5サーバー58ツールで55,000トークン以上、Jiraなど追加で100,000トークン超がユーザー入力前に消費されると報告されています ✅。

cache_controlはどこに置けばよいですか？

Anthropicは tools → system → messages の順でキャッシュキーを構築します ✅。最後のツール定義に cache_control: {type: "ephemeral"} を付与すると、ツール定義全体が1ブロックでキャッシュされます。systemにも長い指示があるならその末尾にも追加します。原則は「変化しない部分を後ろから順にマーク」。

プロンプトキャッシュが逆効果になるケースはありますか？

(1)1回しか読まれないプレフィックスをキャッシュした、(2)最小キャッシュ可能トークン(Sonnet/Opus 1024、Haiku 2048)未満、(3)プレフィックスに動的トークン(タイムスタンプ等)を混入、(4)ツール配列の順序が不安定——の4ケースで逆効果になります。

キャッシュヒット率はどう計測すればよいですか？

Anthropic APIレスポンスの usage オブジェクトに cache_creation_input_tokens と cache_read_input_tokens が含まれ、ヒット率は cache_read / (cache_read + input + cache_creation) で算出 ✅。Datadog・Helicone・Langfuse等の観測ツールが自動可視化します。80%超なら適切、60%未満は要改善。