MCPのプロンプトキャッシュ：ツール一覧でキャッシュが外れる原因とMCPトークン費用の抑え方【2026年版・計算例つき】

最終更新：2026年10月18日 ／ 対象：Claude APIのプロンプトキャッシュ（Claude 5.5の料金）、defer_loading によるツール検索、MCP仕様 2026-07-28（Tools）、Claude Codeの list_changed の扱い

MCPでどうしても送らなければならないツール定義を安く済ませる一番の方法が、プロンプトキャッシュです。ただし効くのは、ツール一覧がリクエスト間で1バイトも変わらない場合だけです。この記事では、MCPのトークン消費（MCP token usage）とプロンプトキャッシュの関係、気づかないうちにキャッシュを外してしまうサーバー側・クライアント側の原因、5分キャッシュと1時間キャッシュの費用計算、そして実際のヒット率の測り方を解説します。

結論（30秒で読める要約）

• プロンプトキャッシュを使うと、毎回同じツール一覧は安い単価で課金されます。Claude Sonnet 5.5とOpus 5.5では、キャッシュ読み取りが通常の入力単価の0.05倍、5分キャッシュの書き込みが1.25倍です（Anthropic料金ページ、2026年10月時点）。
• 筆者の計算では、ツール定義とシステムプロンプトを合わせた30,000トークンを1セッションで20回送る場合、Sonnet 5.5でキャッシュなしは1.20ドル、書き込み1回＋ヒット19回なら0.132ドルで、89%安くなります。
• 毎回外れるキャッシュは、キャッシュなしより高くつきます。プレフィックスが毎回変わると、毎回1.25倍の書き込み料金がかかり、同じ例で1.20ドルが1.50ドル（25%増）になります。
• ツール定義はプレフィックスの先頭にあります。Anthropicのドキュメントは、ツール定義の変更が「キャッシュ全体を無効にする」と書いています。tools・system・messagesのすべてです。MCPツールの並び順や説明文が1つ変わるだけで、会話部分のキャッシュも失われます。
• MCPでよくあるキャッシュ破壊の原因は、ツール順が毎回違う、説明文に時刻や件数が入っている、説明文がリクエストごとに変わる、サーバーの接続順が変わる、セッション途中の list_changed の5つです。
• ツール検索はキャッシュを壊しません。遅延読み込みのツールはプレフィックスから外され、見つかったツールは会話の中に tool_reference として追加されるため、「プロンプトキャッシュは維持される」とされています。
• ヒット率は計測できます。cache_read_input_tokens ÷（cache_read_input_tokens ＋ cache_creation_input_tokens ＋ input_tokens）です。

目次

1. MCPのプロンプトキャッシュとは
2. ツール定義はキャッシュでどう課金されるか
3. キャッシュあり・なしのMCPトークン費用（計算例）
4. MCP環境でキャッシュが外れる原因
5. 3種類のキャッシュ：tools/list・プロンプト・ゲートウェイ
6. ツール検索・遅延読み込み・途中でのツール追加
7. 設定方法（Claude APIの例）
8. キャッシュが効きやすいMCPサーバーの作り方
9. キャッシュヒット率の測り方
10. チェックリスト
11. よくあるハマりどころ
12. NodeFlareならこう解決できる
13. よくある質問

1. MCPのプロンプトキャッシュとは

MCPのプロンプトキャッシュとは、プロンプトの先頭部分（MCPではその大半がツール定義）をLLMの提供元が処理済みのまま再利用し、毎回の定価課金を避ける仕組みのことです。MCPの仕様自体にプロンプトキャッシュの定義はありません。MCPクライアントが呼び出すモデルAPI（Anthropic、OpenAIなど）の機能です。

Claude APIでは、プロンプトキャッシュは「tools、system、messagesの順で、cache_control を付けたブロックまでのプロンプト全体」を対象にします。toolsが先頭なので、MCPサーバーが返すツール一覧が、すべてのキャッシュの土台になります。

MCPのツール定義は大きく、しかも毎回送られます。MCPのトークン消費の全体像と削減方法では58ツールで約55Kトークンを計測しました。遅延読み込みしない限り、このトークンはターンごとに再送されます。

注：ここでの「トークン」はLLMのトークン（コンテキストと課金の単位）のことで、APIキーやOAuthのアクセストークンではありません。

2. ツール定義はキャッシュでどう課金されるか

キャッシュの書き込みは通常の入力より少し高く、読み取りはずっと安くなります。得をするのは、同じプレフィックスが期限内に十分な回数読まれたときだけです。

モデル（Claude API、2026年10月）	通常入力	5分キャッシュ書き込み	1時間キャッシュ書き込み	キャッシュ読み取り	出力
Claude Opus 5.5	$4 / 100万トークン	$5	$8	$0.20	$20
Claude Sonnet 5.5	$2 / 100万トークン	$2.50	$4	$0.10	$10
Claude Haiku 5.5（10万トークン以下）	$0.10 / 100万トークン	$0.125	$0.20	$0.01	$0.50

出典：Anthropic料金ページ。MCPのツール一覧に関係するルールは次のとおりです。

ルール	値	MCPでの意味
書き込み倍率	1.25倍（5分）、2倍（1時間）	外れ続けるキャッシュはキャッシュなしより高い
読み取り倍率	Opus 5.5・Sonnet 5.5は0.05倍、他の多くのモデルは0.1倍	毎回同じツール一覧が安くなる
キャッシュできる最小長	Opus 5.5・Sonnet 5.5・Haiku 5.5は512トークン	小さいサーバーのツール一覧だけでは足りないことがある。ツール＋システムプロンプトなら通常は超える
既定のTTL	5分。使うたびに無料で延長	ユーザーが5分以上手を止めるとキャッシュが切れる
明示的なブレークポイント	最大4つ	ツールの末尾に1つ置く
さかのぼり範囲	1ブレークポイントにつき最大20か所	長いエージェントループでは自動キャッシュでブレークポイントを動かす
プレフィックスの順序	tools → system → messages	ツールが変わると、それ以降がすべて無効になる

最小長に満たないプロンプトは cache_control を付けてもキャッシュされず、エラーも返りません。思い込まずにusageの値で確認してください。

3. キャッシュあり・なしのMCPトークン費用（計算例）

筆者の計算では、1セッションで書き込み1回・ヒット19回なら、Sonnet 5.5でもOpus 5.5でもプレフィックスの費用は89%減りました。途中で1回外れると削減幅は6ポイント縮み、毎回外れるとキャッシュなしより25%高くなります。

前提（筆者の計算）：プレフィックス（MCPツール定義＋システムプロンプト）は30,000トークン、1セッション20リクエスト、特記がない限りすべてTTL内。計算対象はプレフィックスだけで、その後ろで増えていく会話は含めていません。そのため実際の削減額も、キャッシュが外れたときの損失も、この表より大きくなります。

計算式：費用 ＝（書き込み回数 × プレフィックス × 書き込み単価 ＋ 読み取り回数 × プレフィックス × 読み取り単価）÷ 1,000,000。例：Sonnet 5.5で5分キャッシュの書き込み1回なら、（1 × 30,000 × 2.50ドル ＋ 19 × 30,000 × 0.10ドル）÷ 100万 ＝ 0.075ドル ＋ 0.057ドル ＝ 0.132ドル。

シナリオ（30Kトークン、20リクエスト）	Sonnet 5.5	Opus 5.5	キャッシュなし比
キャッシュなし	$1.20	$2.40	—
5分キャッシュ、書き込み1回＋ヒット19回	$0.132	$0.264	−89%
5分キャッシュ、途中でツール一覧が1回変わる（書き込み2回＋ヒット18回）	$0.204	$0.408	−83%
1時間キャッシュ、書き込み1回＋ヒット19回	$0.177	$0.354	−85%
毎回プレフィックスが変わる（書き込み20回）	$1.50	$3.00	+25%

割合はプレフィックスの大きさに左右されません。Sonnet 5.5の場合、10,000トークンならキャッシュなし0.40ドル・書き込み1回で0.044ドル、55,000トークンなら2.20ドルと0.242ドルです。

TTLごとの損益分岐は、Opus/Sonnet 5.5の読み取り単価（0.05倍）で次のようになります。

• 5分キャッシュ：2リクエストで 1.25 ＋ 0.05 ＝ 1.30、キャッシュなしは 2.00。ヒット1回で元が取れます。
• 1時間キャッシュ：ヒット1回では 2.00 ＋ 0.05 ＝ 2.05 で、キャッシュなしの 2.00 よりわずかに高くなります。ヒット2回なら 2.10 対 3.00。2回以上のヒットが必要です。

1時間TTLが勝つのは、リクエストの間隔が5分を超える場合です。5分キャッシュは間に切れてしまい、毎回書き込み料金がかかります。同じ30Kトークン・Sonnet 5.5で8分おきに20リクエストすると、5分キャッシュは1.50ドル（書き込み20回）、1時間キャッシュは0.177ドル（書き込み1回＋ヒット19回）です。TTLは「キャッシュを書き込む、または読むリクエストの開始時点から」数えられ、ヒットのたびに延長されます。

4. MCP環境でキャッシュが外れる原因

ツール部分が少しでも変わると、キャッシュ全体が無効になります。Anthropicの無効化の一覧では、「ツール定義の変更（名前、説明、パラメータ）」でtools・system・messagesのキャッシュがまとめて外れるとされています。MCPでは次のような形で、誰も気づかないうちにそれが起きます。

キャッシュを壊す原因	どこで起きるか	無効になる範囲	対処
ツールの並び順がリクエストごとに違う	サーバーがハッシュマップ・非同期の探索・Promise.all の完了順で一覧を作る。クライアントが接続順にサーバーを結合する	全部	固定の順で返す。MCP仕様もサーバーは「決定的な順序」で返すべき（SHOULD）としている
説明文に時刻・件数・バージョン	「最終同期 12:03」「未対応インシデント3件」、ビルドID	全部	説明文は固定にし、変わる情報はツールの結果で返す
リクエストごとに変わる文言	ユーザー名・ロケール・残りクォータを説明文に入れる	全部	ユーザーごとの情報はキャッシュの後ろ（messages）に置く
セッション途中でツールが増減する	機能フラグ、デプロイ、notifications/tools/list_changed	その時点から全部	ツールの変更はまとめて出す。遅延読み込みか途中追加の仕組みを使う（6章）
サーバーの接続完了順が毎回違う	複数サーバーをまとめるクライアントやゲートウェイ	全部	結合後のツールを決まった順に並べる、名前空間を付ける
tool_choice や disable_parallel_tool_use を変える	クライアントがターンごとにモードを切り替える	messagesのみ	固定するか、切り替える位置の手前にブレークポイントを置く
Web検索・引用のオンオフ	クライアントの機能切り替え	systemとmessages	セッション中は固定する
thinkingやeffortの設定を変える	推論レベルの切り替え	messages。モデルによってはtools・systemも	セッション中は固定する

MCP仕様（2026-07-28）は、決定的な順序が必要な理由をはっきり書いています。決定的な順序は「クライアントがツール一覧を確実にキャッシュできるようにし、ツールがモデルのコンテキストに含まれる場合にLLMのプロンプトキャッシュのヒット率を上げる」ためです。

仕様は同時に、ツール一覧は「接続ごとに、または他のリクエストの副作用として変わってはならない（MUST NOT）」が、「リクエストで提示された認可によって変わってもよい（MAY）」としています。スコープで絞った一覧は正当な使い方です。その場合は一覧ごとに別のキャッシュになるので、資格情報ごとの一覧を安定させておくことが大切です。

デプロイ時のツール変更は、セッション途中でキャッシュが外れるよくある原因です。クライアントを壊さずにツールの変更を出す方法はMCPサーバーの無停止デプロイで解説しています。

5. 3種類のキャッシュ：tools/list・プロンプト・ゲートウェイ

MCPの構成で「キャッシュ」と言うとき、3つの別物を指すことがあります。LLMのトークン費用を下げるのは、このうち1つだけです。

キャッシュ	持ち主	節約するもの	制御方法
tools/listのキャッシュ	MCPクライアント（とゲートウェイ）	サーバーへの通信	tools/list 結果の ttlMs と cacheScope（MCP 2026-07-28のキャッシュ機能）
プロンプトキャッシュ	LLMの提供元	繰り返し送るプレフィックスの入力費用と待ち時間	cache_control（Anthropic）、自動のプレフィックスキャッシュ（OpenAI）
ゲートウェイ／プロキシのキャッシュ	自前のゲートウェイ	上流への重複呼び出し	ゲートウェイの設定

ttlMs を長くしても、プロンプトキャッシュが当たるようにはなりません。クライアントがサーバーに一覧を取りに行かなくなるだけです。プロンプトキャッシュに必要なのは、クライアントがその一覧を毎回同じ形でリクエストに入れることです。

6. ツール検索・遅延読み込み・途中でのツール追加

Claude APIでは、ツール検索とプロンプトキャッシュは両立します。ドキュメントによれば、APIは遅延読み込みのツールをシステムプロンプトのプレフィックスから除外し、ツール検索で見つかったツールは tool_reference ブロックとして会話の中に追加します。「プレフィックスには手が入らないため、プロンプトキャッシュは維持される」とされています。

実務上のポイントは次のとおりです。

• 最初から読み込む少数のツールをキャッシュする。よく使うツールをいくつか遅延なしにして、その最後にブレークポイントを置きます。defer_loading: true のツールに cache_control を付けると400エラーになります。
• 定義は全部送り続ける。遅延読み込みのツールも含め、tools 配列には毎回すべての定義を入れます。課金されるのは読み込まれたときだけですが、こちらも安定させておく必要があります。
• セッション途中でツールを追加する。ベータヘッダー inline-tools-2026-09-15 を付けると、会話途中のsystemメッセージで tool_addition ブロックを送り、tools を変えずにツールを追加・変更できます。ただし、遅延なしのツールが1つもない tools 配列では、最初の追加時に1回だけキャッシュ全体が外れると注記されています。
• MCPコネクタのツールセット。mcp_toolset の中のツール順は自分で制御できないため、ブレークポイントは mcp_toolset のエントリ自体に置きます。APIが展開後の最後のツールに適用します。

Claude Codeは list_changed を受け取ると一覧を取り直します。対話セッションでは「そのサーバーから更新後の一覧を取得するので、再接続は不要」です。Claude Codeではツール検索が既定で有効です。取り直した一覧がLLM側のキャッシュにどう影響するかはクライアントの組み立て方次第なので、サーバー更新後はusageの値を確認してください（9章）。

OpenAIのAPIは1,024トークンを超えるプロンプトのプレフィックスを自動でキャッシュします。Cookbookでも、プレフィックスに含めるにはツール定義と並び順が同一である必要があると書かれています。決定的な順序のルールはここでも同じです。

7. 設定方法（Claude APIの例）

MCPツールの末尾にブレークポイントを1つ置いてツール一覧全体をキャッシュし、もう1つは自動キャッシュで会話に合わせて動かします。

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "tools": [
    { "name": "github_list_issues", "description": "...", "input_schema": { "type": "object" } },
    { "name": "github_create_issue", "description": "...", "input_schema": { "type": "object" } },
    {
      "name": "slack_post_message",
      "description": "...",
      "input_schema": { "type": "object" },
      "cache_control": { "type": "ephemeral", "ttl": "1h" }
    }
  ],
  "system": "あなたはサポート担当のエージェントです…",
  "messages": [{ "role": "user", "content": "今日の未対応P1課題を要約して" }]
}

• 最後のツールの cache_control で、ツール定義のプレフィックスがキャッシュされます。Anthropicも「tools 配列の最後のツールに付ける」よう案内しています。
• トップレベルの cache_control は自動キャッシュを有効にします。最後のキャッシュ可能なブロックにブレークポイントを置き、会話が伸びるにつれて前に進めてくれます。4つの枠のうち1つを使います。
• 1時間のエントリは5分のエントリより前に置く必要があります。この例では1時間をツールに、自動の5分をその後ろにしているので正しい順です。1時間TTLは、ユーザーが5分以上手を止めることが多い場合だけ使います（3章）。

Claude CodeやCursorなど多くのMCPクライアントは、キャッシュを自前で管理しています。その場合にサーバー側でできることは、ツール一覧を安定させることです。

8. キャッシュが効きやすいMCPサーバーの作り方

キャッシュに優しいMCPサーバーとは、ツールが本当に変わるまで tools/list が同じバイト列を返し続けるサーバーです。次の4つで大半はカバーできます。

1. ツールを決まった順で登録する。非同期処理の完了順で一覧を作らない。動的に見つけるツールは名前順に並べる。
2. 説明文を固定にする。日付・件数・環境名・ビルドハッシュを入れない。変わる状態はツールの結果で返す。
3. ツールの変更はまとめて出す。新しいツールを1つずつ出すのではなく、計画したリリースで出す。長いセッションでも外れるのは最大1回にする。
4. スコープで絞る場合は、資格情報ごとに一覧を安定させる。認可による出し分けは仕様で認められていますが、ばらつきは認められていません。

1と2は、一覧を何回か取得してハッシュを比べる短いスクリプトで確認できます。MCPのTypeScript SDKのクライアントを使っています。正確なAPIはお使いのSDKのバージョンで確認してください。

// check-tools-stable.mjs — 使い方: node check-tools-stable.mjs https://your-server/mcp
import { createHash } from "node:crypto";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const url = new URL(process.argv[2]);
const hashes = new Set();
for (let i = 0; i < 5; i++) {
  const client = new Client({ name: "cache-check", version: "1.0.0" });
  await client.connect(new StreamableHTTPClientTransport(url));
  const { tools } = await client.listTools();
  const h = createHash("sha256").update(JSON.stringify(tools)).digest("hex").slice(0, 12);
  console.log(`run ${i + 1}: ${tools.length} tools, ${h}`);
  hashes.add(h);
  await client.close();
}
console.log(hashes.size === 1 ? "stable: OK" : "UNSTABLE: 実行ごとにツール一覧が違います");

ハッシュが変わったら、2回分の結果を差分で比べてください。順序が違えば1、文言が違えば2が原因です。キャッシュされる中身そのものを小さくしたい場合は、ツール定義のトークン棚卸しと削減を参照してください。プレフィックスが小さいほど、書き込みも読み取りも安くなります。

9. キャッシュヒット率の測り方

Claude APIの各レスポンスから3つの値を読み、セッション単位で合計します。

フィールド	意味
cache_creation_input_tokens	キャッシュに書き込まれたトークン（1.25倍または2倍で課金）
cache_read_input_tokens	キャッシュから読まれたトークン（Opus/Sonnet 5.5では0.05倍）
input_tokens	最後のブレークポイントより後ろの、キャッシュ対象外のトークン
cache_creation.ephemeral_5m_input_tokens / ephemeral_1h_input_tokens	TTL別の書き込み内訳

入力の合計 ＝ cache_read_input_tokens ＋ cache_creation_input_tokens ＋ input_tokens（Anthropicのドキュメント）。

ヒット率（この記事での定義）＝ cache_read_input_tokens ÷ 入力の合計。健全なセッションでは、最初のリクエストはほぼ書き込みで、以降はほぼ読み取りと新しいターンの分になります。

注意すべきサインは次のとおりです。

• 毎回 cache_creation_input_tokens が大きい：プレフィックスが変わっています。8章のスクリプトで確認します。
• cache_read_input_tokens がずっと0：最小長に足りない、ブレークポイントがない、またはリクエスト間隔が5分を超えています。
• 1時間TTLしか使っていないのに5分の書き込みがある：サーバーツールを使うと、APIがサーバーツールの結果に自動でブレークポイントを置き、それは常に既定の5分TTLになります。

10. チェックリスト

• [ ] tools/list が何回取得しても同じバイト列を返す（ハッシュで確認）
• [ ] ツール説明文に時刻・件数・ビルドID・ユーザーごとの文言がない
• [ ] 複数サーバーのツールを決まった順に並べ、名前空間を付けている
• [ ] 最初から読み込む最後のツール（または mcp_toolset エントリ）にブレークポイントがある
• [ ] ツール＋システムプロンプトがモデルの最小キャッシュ長を超えている（Claude 5.5系は512トークン）
• [ ] TTLが使われ方に合っている（作業中は5分、長く手を止めるなら1時間）
• [ ] tool_choice・Web検索・thinking・effortをセッション中に変えていない
• [ ] ツールの変更はリリース単位でまとめ、途中追加は遅延読み込みか tool_addition を使う
• [ ] usageの値からセッションごとのヒット率を記録している

11. よくあるハマりどころ

症状	原因	対処
キャッシュを有効にしたのに請求が増えた	プレフィックスが毎回変わり、毎回書き込み料金を払っている	ハッシュ比較で変わる部分を見つける
手元では当たるのに本番で外れる	本番ではサーバーの接続順やツールの登録順が違う	ツールを並べ替え、サーバーごとに名前空間を付ける
デプロイのたびにキャッシュがリセットされる	デプロイで説明文や順序が変わり、list_changed が出る	ツールの変更をまとめ、リリース間は定義を固定する
小さいサーバーで cache_read_input_tokens が0	プレフィックスが最小長に届かない	ツールとシステムプロンプトをまとめてキャッシュし、モデルの最小長を確認する
休憩後にキャッシュが外れる	5分のTTLが切れた	そういうセッションには1時間TTLを使う
遅延ツールのキャッシュ設定で400エラー	defer_loading: true のツールに cache_control を付けた	遅延なしのツールにブレークポイントを置く
ツールを強制指定するとキャッシュが落ちる	tool_choice を変えた	切り替え位置の手前にブレークポイントを置く

12. NodeFlareならこう解決できる

NodeFlareはMCPサーバーをホスティングし、プロキシ側でサーバーごとのトークン設定を提供しています。どれもサーバーのコード変更は不要です。キャッシュを壊しているのが自分で直せない他社製サーバーのツール一覧である場合に、この点が効いてきます。上で挙げた課題ごとに対応する設定は次のとおりです。

課題：ツールのカタログが変わり続け、キャッシュされるプレフィックスも変わり続ける（4章）。 → tool_search_mode を有効にします。ツール一覧全体が search_tools(query) と call_tool(name, args) の2つのメタツールに置き換わるため、カタログの大きさに関係なく最初のトークン消費はほぼ一定です。クライアントが最初に送る一覧はこの2つの定義で、実際のカタログには検索でたどり着きます。検索は既定では字句検索で、GEMINI_API_KEY を設定すると埋め込みによる意味検索になります。意味検索が失敗しても字句検索に切り替わり、リクエストが止まることはありません。

課題：キャッシュの後ろの会話が、ツールの生の結果でどんどん膨らむ。 → Code Execution（tool_code_mode）を有効にします。サーバーは run_code と search_tools を公開し、モデルは tools.* を呼ぶJavaScriptを書きます。コードはサンドボックスで実行され、複数のツール呼び出しが1回の実行にまとまるので、途中の結果が会話のキャッシュ対象外の部分に積み上がりません。サンドボックスはプロキシとは別のDenoサービスで、ファイルシステム・環境変数・プロセス起動は使えず、通信先はプロキシのツール呼び出し用エンドポイントだけです。既定値はタイムアウト600秒、1回の実行で最大50回のツール呼び出し、V8ヒープ128MBです。

課題：キャッシュしても、大きなプレフィックスは書き込みのたびに1.25倍または2倍で課金される。 → tool_schema_slim を有効にします。500文字を超えるツール説明文をUTF-8を壊さずに切り詰めます。ツール名と入力スキーマはそのままです。プレフィックスが小さくなるほど、書き込みも読み取りも安くなります。

課題：1つのサーバーを複数のエージェントで共有し、それぞれ必要なツールが違う（4章）。 → tool_list_filter_by_scope を有効にします。tools/list には呼び出し元の資格情報で実行できるツールだけが、同じスキーマのまま表示されます。キャッシュキーに呼び出し元の識別子が含まれるため、絞り込んだ一覧が資格情報の間で混ざることはありません。各資格情報は全カタログではなく、自分用の小さい一覧を受け取ります。

NodeFlareは固定の削減率を公表していません。9章のusageの値を使い、有効化の前後でヒット率と費用を計測してください。

最小の始め方：

1. nodeflare.tech にサインインし、MCPサーバーのGitHub URLを入力します。ランタイム・トランスポート・起動コマンドは自動で入力されます。
2. デプロイしたら、サーバー設定で tool_search_mode か tool_code_mode を有効にします。
3. サーバーのURLとAPIキーをMCPクライアントに追加します。

1サーバーまで無料で試せます（Freeプラン：1サーバー、月30GB時間のコンピュート）。→ nodeflare.techで始める

13. よくある質問

MCPのツールでプロンプトキャッシュは使えますか？

使えます。MCPのツール定義は tools 配列に入り、Claude APIではそこがキャッシュされるプレフィックスの先頭になります。クライアントが毎回同じツールを同じ順で送っていれば、キャッシュは効きます。

MCPのツール定義はキャッシュの対象になりますか？

キャッシュされたプレフィックスの中にあれば対象になります。Claude Sonnet 5.5では、キャッシュ読み取りは100万トークンあたり2ドルではなく0.10ドルで、最初の書き込みは2.50ドルです。ブレークポイントがない場合や一覧が変わる場合は、通常の入力として課金されます。

MCPでプロンプトキャッシュが外れる原因は？

ツールの名前・説明文・パラメータ・並び順のどれかが変わることです。Anthropicはツール定義の変更が「キャッシュ全体を無効にする」としており、システムプロンプトと会話も含まれます。よくあるのは、ツール順のばらつき、説明文の時刻、セッション途中のツール追加です。

notifications/tools/list_changed でキャッシュは無効になりますか？

通知そのものでは無効になりませんが、変わったツール一覧をクライアントがモデルに送った時点で、たいていは外れます。ツールの変更はリリース単位でまとめるか、遅延読み込みを使って新しいツールを会話の中で読み込むようにします。

ツール検索を使うとプロンプトキャッシュは壊れますか？

Claude APIでは壊れません。遅延読み込みのツールはプレフィックスから除外され、見つかったツールは tool_reference として会話の中に追加されるため、ドキュメントでも「プロンプトキャッシュは維持される」とされています。ただし遅延ツール自体に cache_control は付けられません。

プロンプトキャッシュでMCPのトークン費用はどれくらい下がりますか？

筆者の計算では、30,000トークンのプレフィックスを20回送る場合、Sonnet 5.5でもOpus 5.5でも、書き込み1回・ヒット19回で89%下がります。毎回プレフィックスが変わると、毎回書き込み料金がかかるため、キャッシュなしより25%高くなります。

TTLは5分と1時間のどちらにすべきですか？

作業中のセッションなら5分です。ヒット1回で元が取れます。リクエストの間隔が5分を超えることが多いなら1時間です。書き込みが2倍なので、元を取るには2回以上のヒットが必要です。どちらもヒットのたびに期限が延びます。

cache_read_input_tokens がずっと0なのはなぜですか？

多いのは、プレフィックスが最小長（Claude 5.5系は512トークン）に届かない、cache_control のブレークポイントがない、リクエストごとにプレフィックスが変わる、リクエスト間隔が5分を超える、のいずれかです。最小長に満たないプロンプトはエラーなしでキャッシュされずに処理されます。

MCPツールの並び順はキャッシュに影響しますか？

影響します。キャッシュは完全に一致するプレフィックスで照合されるため、同じツールでも順序が違えば外れます。MCP仕様も、プロンプトキャッシュのヒット率が上がるという理由で、サーバーは決定的な順序でツールを返すべき（SHOULD）としています。

tools/listのキャッシュ（ttlMs）とプロンプトキャッシュは同じですか？

違います。ttlMs と cacheScope は、MCPクライアントがサーバーに再問い合わせせずにツール一覧を使い回せる期間を示します。プロンプトキャッシュはLLMの提供元で行われ、入力トークンの費用を下げます。ttlMs を長くしてもプロンプトキャッシュが当たるとは限りません。

ここでの「MCP Token」はAPIトークンのことですか？

違います。この記事が扱うのは、MCPのツール定義が消費するLLMのトークンとその費用です。MCPサーバーのAPIキーやOAuthのアクセストークンはセキュリティの話題です。

まとめ

プロンプトキャッシュを使えば、ツール定義という固定のMCPトークン費用を、リクエストごとの小さな負担に変えられます。ただし条件は、ツール一覧が毎回まったく同じであることです。ツールは決まった順で返し、説明文は固定にし、ツールの変更はまとめて出し、ツールの後ろにブレークポイントを置き、ユーザーの手の止め方に合わせてTTLを選び、cache_creation_input_tokens で変わり続けるプレフィックスを見張ってください。毎回外れるキャッシュは、キャッシュなしより高くつきます。

参考資料

• Claude Docs: Prompt caching
• Claude Docs: Tool use with prompt caching
• Claude Docs: Tool search tool
• Claude Docs: Pricing
• MCP仕様 2026-07-28: Tools
• Claude Code Docs: MCP
• OpenAI Cookbook: Prompt Caching 101
• NodeFlare Docs ／ NodeFlare 料金