Claude APIが会話途中のツール変更をベータ解禁｜MCPのキャッシュは壊れない

「ツールを動的に出し入れするとプレフィックスが変わって、キャッシュが丸ごと無効化する」。Qiitaでツールスキーマのトークン数を実測した中村啓氏は、一見スマートに見えるこの最適化が「逆に高くつくことがある」と書いている（Qiita, 2026年6月17日）。エージェントを実運用に載せたことがある開発者なら、この罠を踏んだ記憶があるはずだ。

2026年7月24日、Anthropicがそのトレードオフを解消するベータを公開した。公式リリースノートにはこうある。「Mid-conversation tool changes are now in beta on Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, and Claude Opus 5: add or remove tools between turns of a conversation while preserving the prompt cache.」（Claude Platform release notes）。会話の途中でツールを足しても消しても、プロンプトキャッシュが生き残る。

なぜツール変更がキャッシュを壊すのか

まず従来の挙動を確認する。Anthropic公式ドキュメントは、キャッシュが tools → system → messages というプレフィックス階層に従うと明記している。上流が変われば、そこから下が全部飛ぶ。

ここでいうプレフィックスとは、リクエストの先頭から連続する塊のことだ。キャッシュヒットの条件は「直近のリクエストとプレフィックスがバイト単位で完全一致すること」であり、1バイトでも違えば別物として扱われる。

変更した箇所	無効化される範囲
ツール定義の変更	キャッシュ全体（tools, system, messages）
web検索・引用の切り替え	systemとmessagesのキャッシュ
tool_choice の変更	messagesのキャッシュ
画像の有無の切り替え	messagesのキャッシュ
thinkingパラメータの変更	messagesのキャッシュ（モデルによってはtools/systemも）

出典はTool use with prompt caching。ツール定義はプレフィックスの最上流にある。だからツールを1個足しただけで、何万トークンあろうと会話履歴ごと全部が書き込み価格で再計算される。MCPサーバーをセッション中に接続・切断したときにキャッシュが消えるのも、公式ドキュメントのこの表がそのまま効いている結果だ。

なお、キャッシュはリクエストに cache_control を含めて初めて有効になる。トップレベルの自動キャッシュ指定か、コンテンツブロックへの明示的なブレークポイント設置のどちらかが必要で、指定がなければ何もキャッシュされない（Mid-conversation system messages and tool changes）。

mid-conversation tool changesの使い方と対応モデル

今回のベータは、この最上流の変更をキャッシュ破壊なしに扱えるようにするものだ。公式ドキュメントの説明はこうだ。「Instead of fixing the tool list for the lifetime of the conversation, you change which tools are offered to the model between turns: declare the full tool set in tools up front, then use tool_addition and tool_removal blocks to offer a tool to the model, or withdraw it, from a specific point in the conversation onward. The tools array itself never changes, so the cached prefix stays intact.」

実装の要点は3つある。

1. ツールは全て最初から tools 配列に宣言する。 配列そのものは会話中いっさい書き換えない。だからプレフィックスのハッシュが変わらない。
2. 最初は隠しておきたいツールに defer_loading: true を付ける。 これを付けたツールはモデルに提示されず、tool_addition ブロックが登場するまで待機する。
3. 出し入れは role: "system" メッセージの中で指示する。 content 配列に tool_addition / tool_removal ブロックを入れ、tool フィールドで既存ツールを名前参照する。宣言していない名前を参照すると400エラーになる。

Python SDKでの最小例は次のようになる。ヘッダーは betas 引数で渡す。

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    betas=["mid-conversation-tool-changes-2026-07-01"],
    # tools配列は会話を通じて一切変更しない。だからプレフィックスが保たれる
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a location.",
            "input_schema": {
                "type": "object",
                "properties": {"location": {"type": "string"}},
                "required": ["location"],
            },
        },
    ],
    messages=[
        {"role": "user", "content": "Say OK."},
        # この地点以降 get_weather を引っ込める。tools本体は無傷なのでキャッシュはヒットする
        {
            "role": "system",
            "content": [
                {
                    "type": "tool_removal",
                    "tool": {"type": "tool_reference", "name": "get_weather"},
                },
            ],
        },
    ],
)

MCPコネクタ経由のツールも扱える。個別に指定する場合は mcp_tool_reference（server_name と name）、サーバー単位でまとめて扱う場合は mcp_toolset_reference（server_name）を使う。MCPサーバーを丸ごと出し入れしたい運用では後者が実用的だ。

置き場所には制約がある。system メッセージは messages の先頭には置けず、user ターン（tool_result ブロックを運ぶ user ターンを含む）の直後に置き、その後は assistant ターンが続くか配列の末尾で終わる必要がある。tool_use ブロックとそれに対応する tool_result の間に挟むと400エラーになる。エージェントループに組み込むなら、ツール結果を返した直後が定位置だ。

対応モデルはClaude Fable 5、Claude Mythos 5、Claude Opus 4.8、Claude Opus 5の4つ。提供経路はClaude API、Amazon Bedrock、Google Cloudの3つ。ただしClaude Mythos 5はProject Glasswing参加者向けの限定提供モデルなので、一般の開発者が実際に選べるのは残り3つと考えたほうがいい。

料金への影響を試算する

金額の話をする。公式の料金倍率は次の通りだ（Prompt caching）。Claude Opus 5の基本入力価格$5・出力$25は7月24日のリリースノートに明記されている。

種別	基本入力価格に対する倍率	Opus 5での実額（1Mトークンあたり）
通常の入力トークン	1倍	$5
キャッシュ書き込み（5分TTL）	1.25倍	$6.25
キャッシュ書き込み（1時間TTL）	2倍	$10
キャッシュ読み出し	0.1倍	$0.50

※米ドル建て・税別のリスト価格。

書き込みと読み出しの差は12.5倍。ここに、ツール定義がどれだけ嵩むかを重ねる。

中村氏の実測では、代表的なMCPツール6個のスキーマが合計846トークン、1ツールあたり平均141トークンだった。「50ツールなら1リクエストあたり約7,050トークン」という換算になる（Qiita）。氏の表現を借りれば「ツール定義は人間向けの注釈じゃなくて、まるごと課金対象の入力トークン」だ。

実運用ではもっと膨らむ。GitHub公式MCPサーバーはツール定義だけで約42,000トークンをコンテキストから持っていくと計測記事が報告しており、同記事にはより新しい計測として93ツール定義で約55,000トークンという数字も併記されている（getunblocked.com）。この規模のプレフィックスがターンごとに書き込み価格で再送されるか、読み出し価格で済むかで、桁が動く。

ツール定義2万トークン、1会話あたり5回ツールを差し替える構成を想定する。従来は差し替えのたびキャッシュが飛ぶので、5回分がキャッシュ書き込み価格になる。

	単価	5回分（10万トークン）
従来（毎回キャッシュ書き込み）	$6.25 / Mトークン	約$0.63
ベータ適用後（キャッシュ読み出し）	$0.50 / Mトークン	約$0.05
差額		約$0.58

1会話あたり約0.58ドル。1日1,000会話走るサービスなら日次約$575の差になる。フリーランスが個人で回すエージェントでも、1日50会話なら日次約$29、月あたり約$860の計算だ。エージェントのコスト構造では、この手のプレフィックス再計算が地味に効く。

MCPツール肥大化で実際に踏まれてきた罠

この機能が刺さる理由は、開発者が実際に痛い目を見てきたからだ。

MCP課金で驚いたいばらき氏（NCDC） は、MCP連携チャットアプリを作った際、開発中でほぼ自分しか使っていないのに生成AIの利用量がやたら高いことに気づいた。数千円かかるアプリではコスパが悪すぎる、というのが率直な感想だったという。

原因を追うと、1リクエストのレスポンスに "input_tokens":21786 と出ていた。Box MCPサーバーのツール1個で約1,000文字の定義データ、それが10個以上あるサーバーを複数接続していた結果、ユーザーが「こんにちは」と5文字打つたびに10万文字級のデータが飛んでいた（Zenn, 2025年6月23日）。

プロンプトキャッシュ導入後は入力519トークン＋キャッシュ読み出し21,097トークンとなり、キャッシュ利用率97.5%まで改善したと報告している。

100ツール運用の@yureki_lab氏 は、別方向から同じ問題に取り組んだ。100個超のツールを持つ構成で、全ツールをフルスキーマで渡す方式から名前だけ＋遅延ロード方式に切り替えたところ、「初期プロンプトのトークン数がおおよそ1/10〜1/20まで下がる」と報告している（Qiita, 2026年7月24日）。

ただし副作用も正直に書かれている。曖昧な検索クエリだと20件以上ヒットして意味がない、検索コストが毎回かかる、OAuth認証が必要なツールはヘッドレス環境で解決できない。銀の弾丸ではない。

トークン実測の中村氏 が指摘するもうひとつの論点が、キャッシュでは解決しない部分だ。「キャッシュは料金を薄めるだけで、コンテキスト窓は普通に食う。7,000トークンのツールカタログは、窓が200kあろうと、使える長さをその分そのまま削る」。ここは今回のベータでも変わらない。

キャッシュのTTL短縮騒動を含む前史についてはClaude Codeのキャッシュを1時間に戻す方法で詳しく扱った。MCPそのものの設計思想はMCP実践ガイドにまとめてある。

メリットと4つの注意点

良い面ははっきりしている。フェーズごとにツールを絞る設計から、キャッシュ全損というペナルティが外れる。調査フェーズでは検索系ツールだけ、実装フェーズではファイル操作系だけ、という制御は精度面でも効く。ツールが多すぎるとモデルの選択精度が落ちる問題は以前から指摘されてきた（DEV Community）。これまではその対策が「キャッシュを毎回捨てる」代償とセットだった。

一方で、割り引いて考えるべき点が4つある。

ベータであること。 ヘッダー名に 2026-07-01 という日付が入っている通り、これはバージョン付きベータだ。仕様変更や、GA時点で挙動が変わる可能性は織り込んでおくべきだ。本番の課金クリティカルなパスに載せるなら、フォールバック経路を用意しておきたい。

コンテキスト窓は節約されない。 キャッシュはあくまで課金を薄める仕組みだ。defer_loading で初期プロンプトから外れたツールも、tool_addition で呼び出せばそこからはコンテキストに載る。窓を空けたいなら、そもそもツール数を減らす設計が要る。

削減率の公式数値がない。 Anthropicは「キャッシュを維持する」としか言っておらず、何%安くなるとは公表していない。効果はツール定義のサイズと差し替え頻度で大きく変わる。導入前後で cache_creation_input_tokens と cache_read_input_tokens を比較するのが、最も確実な確認手段になる。どちらもAPIレスポンスの usage オブジェクトに入っている。

ツール検索との住み分けが必要。 公式ドキュメントは defer_loading によるツール検索でもキャッシュが保たれると説明している。「Deferred tools are not included in the system-prompt prefix」であり、発見されたツールは会話履歴に tool_reference ブロックとして追記されるため、プレフィックスが無傷で済む仕組みだ（Tool use with prompt caching）。今回のベータとは主導権の所在が違う。ツール検索は「モデルが選ぶ」、mid-conversation tool changesは「アプリが決める」。

自分（電脳狐影）ならこうする

PMとしてAPIコストを見る立場からの判断を書く。技術の内部実装まで踏み込める人間ではないので、あくまで使う側の運用設計の話だ。

まず測る。 導入検討の前に、自分のエージェントが1会話あたり何回キャッシュ書き込みを起こしているかをログから出す。APIレスポンスの usage.cache_creation_input_tokens が毎ターン発生しているなら改善余地がある。逆に既に読み出し中心なら、このベータを入れても体感は変わらない。測らずに入れる判断はしない。

採用するならフェーズ制御とセットで。 ヘッダーを足すだけでは何も起きない。価値が出るのは、ツールを実際に出し入れする設計に踏み込んだときだけだ。ワークフローを2〜3フェーズに割り、フェーズごとの必要ツールを定義するところから始める。

大量ツールを抱えているならツール検索が先。 100個超のツールを常時ぶら下げている構成なら、まず defer_loading で初期プロンプトを軽くするほうが効果が大きい。@yureki_lab氏の1/10〜1/20という数字は、そちらの改善幅を示している。mid-conversation tool changesはその後の細かい最適化として位置づける。

本番投入は段階的に。 ベータヘッダーを本番の全トラフィックに一斉適用はしない。まず内部ツールか一部エンドポイントで1〜2週間走らせ、請求額とレスポンス品質の両方を見る。

関連記事

• Claude Codeのキャッシュを1時間に戻す方法：プロンプトキャッシュのTTLとコスト計算の基礎
• MCP実践ガイド：MCPの設計思想と導入手順
• Claude Agent SDK完全ガイド：エージェントを自作する際の全体像
• Claude Opus 5完全ガイド：今回の対応モデルの仕様とeffort制御

---

免責事項: 本記事のAPI仕様および料金は2026年7月26日時点の公開情報に基づきます。mid-conversation tool changesはベータ機能であり、仕様・提供条件・対応モデルは予告なく変更される可能性があります。記載の料金は米ドル建て・税別のリスト価格であり、実際の請求は各プロバイダの最新ドキュメントとご自身の利用ログでご確認ください。試算値は特定の前提に基づく概算であり、削減効果を保証するものではありません。本記事の情報に基づく判断・行動によって生じた損害について、当サイトは責任を負いかねます。

商標・著作権注記: Claude、Anthropicは Anthropic PBC の商標です。その他記載の製品名・サービス名は各社の商標または登録商標です。引用した記事の著作権は各著者および運営者に帰属します。