Claude APIが会話の途中でツールセットを変えられるようになった──プロンプトキャッシュを保ったまま

2026年8月27日、Claude Developer Platform公式リリースノート（platform.claude.com）を実際に開いて確認した内容です。 2026年7月24日のエントリに、次の1文があります（原文と訳）。

"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. Include the mid-conversation-tool-changes-2026-07-01 beta header in your requests."

（訳：会話の途中でのツール変更が、Claude Fable 5・Claude Mythos 5・Claude Opus 4.8・Claude Opus 5でベータ提供開始。会話のターンの合間にツールを追加・削除でき、その間プロンプトキャッシュは維持される。リクエストにmid-conversation-tool-changes-2026-07-01ベータヘッダーを含めること）

この日のリリースノートには、同じ日に発表されたClaude Opus 5本体の情報と並んで、この機能が1項目として記載されています。

3行まとめ

• Claude API上で、会話のターンとターンの間にツールを追加・削除できる「Mid-conversation Tool Changes」がベータ提供開始（2026年7月24日、Claude Opus 5の発表と同日）
• 対象はClaude Fable 5・Claude Mythos 5・Claude Opus 4.8・Claude Opus 5の4モデル。利用にはmid-conversation-tool-changes-2026-07-01というベータヘッダーが必要
• この機能の核は「プロンプトキャッシュを維持したまま」ツールセットを変更できる点。従来はツールセットを変えるとキャッシュのプレフィックスが崩れるのが一般的な制約だった

なぜ「プロンプトキャッシュを保ったまま」が重要なのか

多くのLLM APIのプロンプトキャッシュは、リクエストの先頭からどこまでが直前のリクエストと同一かで判定する「プレフィックス一致」方式を採っています。ツールの定義は通常リクエストの先頭付近（システムプロンプトに近い位置）に置かれるため、会話の途中でツールセットを変更すると、そのツール定義が含まれる部分から後ろのキャッシュが丸ごと無効になりやすい、という制約が一般的にあります。

Anthropicのこの機能が「preserving the prompt cache（プロンプトキャッシュを維持したまま）」と明記しているのは、この制約を回避する設計だということを示しています。長時間稼働するエージェント（例えば、序盤は調査系ツールだけを持たせ、途中からファイル編集ツールを解禁する、といった段階的な権限付与を行うエージェント）にとっては、ツールセットの変更のたびにキャッシュがリセットされてコストが跳ね上がる、という事態を避けられることになります。

Kimi K3の「Dynamic Tool Loading」との違い

同時期に、Moonshot AIのKimi K3にも似た課題に対する機能があります。Kimi K3の「Dynamic Tool Loading」という記事で確認した通り、Kimi側は「ツールを最初から全部渡さず、systemメッセージのtoolsフィールドとして会話の途中に追記する」という設計で、既存のプレフィックスキャッシュを壊さないようにしています。

一方、AnthropicのMid-conversation Tool Changesは、リリースノートの1文だけでは「ツールを追加できる」だけでなく「削除できる」とも明記されている点が異なります。Kimi側のドキュメントでは、ツールの動的な「追加」は扱われていますが、既に注入したツールを取り消す「削除」の仕組みについては、当サイトが確認した範囲のページには記載がありませんでした。この「削除」機能がどのようにキャッシュとの整合性を保っているのか（削除したツールの定義がキャッシュ済みプレフィックスに含まれていた場合にどうなるのか）は、今回確認したAnthropic公式リリースノートの1文だけでは分かりません。

使うにはベータヘッダーが必要

公式リリースノートの記載によれば、この機能を使うにはmid-conversation-tool-changes-2026-07-01というベータヘッダーをリクエストに含める必要があります。Anthropicのベータ機能は、こうした専用ヘッダーの送信によってオプトインする方式が一般的で、当サイトが別記事で扱ったFiles API・Agent Skills APIの正式版化でも、正式版になるとこのヘッダーが不要になる（送っても後方互換で動く）という経緯が確認できています。Mid-conversation Tool Changesは本記事の確認時点（2026年8月27日）でまだベータの位置づけであり、正式版化の予定については公式リリースノートに記載がありませんでした。

対象モデルの確認

対象として明記されている4モデル──Claude Fable 5・Claude Mythos 5・Claude Opus 4.8・Claude Opus 5──を見ると、Claude Sonnet 5が含まれていません。専用ガイドページ「Mid-conversation system messages and tool changes」（platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages）を確認すると、この点は明記されていました。

"Mid-conversation tool changes are in beta and require the mid-conversation-tool-changes-2026-07-01 beta header. They are available on Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, and Claude Opus 5, on the Claude API, Amazon Bedrock, and Google Cloud. They are not available on Claude Sonnet 5."

（訳：Mid-conversation tool changesはベータ提供で、mid-conversation-tool-changes-2026-07-01ベータヘッダーが必要。Claude API・Amazon Bedrock・Google Cloud上のClaude Fable 5・Claude Mythos 5・Claude Opus 4.8・Claude Opus 5で利用可能。Claude Sonnet 5では利用できない）

リリースノートの1文だけでは「単に記載漏れなのか」判断できませんでしたが、専用ガイドページで明示的に「not available on Claude Sonnet 5」と書かれているのを確認できたため、Sonnet 5がこのベータの対象外であることは事実として確定できます。あわせて、Amazon BedrockとGoogle Cloud上のClaude APIでも同じ4モデルで使えることも、このページで初めて確認できました（release notesの1文にはBedrock/Google Cloudへの言及がありませんでした）。

実際の構文：tools配列は変えず、systemメッセージ内のtool_addition/tool_removalで操作する

専用ガイドページには、具体的なリクエスト構文も記載されていました。直感に反する設計で、「会話の途中でツールセットを変える」といっても、リクエストのtools配列そのものを書き換えるわけではありません。

"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."

（訳：toolsにツールセット全体を最初に宣言しておき、そこからtool_additionとtool_removalブロックを使って、会話の特定の時点からモデルにツールを提供したり取り下げたりする。tools配列そのものは変化しないため、キャッシュされたプレフィックスはそのまま保たれる）

つまり仕組みはこうです。

• tool_addition / tool_removalは、role: "system"のメッセージのcontent配列に入れるコンテンツブロックであり、textブロックと混在させられる
• 各ブロックのtoolフィールドは、ツールを新たに定義するのではなく{"type": "tool_reference", "name": "..."}の形でtools配列内の既存ツールを名前で参照する。MCPコネクタ経由のツールはmcp_tool_reference（server_name+name）で個別に、mcp_toolset_reference（server_name）でサーバー単位まとめて参照できる
• tools配列で宣言されていない名前を参照すると400エラーになる
• ツールはdefer_loading: trueを付けて宣言しない限り会話の最初から提供される。defer_loading: trueを付けたツールは、tool_additionで表面化させるまで隠しておける
• tool_additionは、直前のtool_removalで取り下げたツールを再び提供し直すのにも使える

この設計により、記事執筆時点で残っていた「ツール定義自体が書き換わるならキャッシュが壊れるのでは」という疑問は解けました。tools配列は最初の宣言のまま固定し、あとから追加・削除する情報は別チャネル（systemメッセージ）に載せる、という構造そのものがキャッシュ維持の根拠になっています。

Mid-conversation system messagesとの違い

このガイドページは、実は「Mid-conversation tool changes」単体のページではなく、2026年7月15日にリリースされた別機能「Mid-conversation system messages」（systemフィールドの内容を会話途中で追記できる機能）と同じページで解説されていました。両者は同じrole: "system"メッセージという土台を共有しつつ、対象が異なります。

出典: platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages（2026年8月27日確認）

Mid-conversation system messagesの方は2026年7月15日リリース時点でベータヘッダー不要と案内されており、リリースノートには「This corrects earlier availability notes.（これは以前の提供状況に関する記載を訂正するものです）」という一文も添えられていました。ツール変更機能は7月24日にOpus 5と同時公開された、より新しい機能という位置づけです。

配置ルールと「途中に挟めない場所」

ガイドページの「Limitations」節には、systemメッセージ（＝tool_addition/tool_removalもこれに含まれる）を置ける場所の制約も書かれています。

"A system message cannot be the first entry in messages. [...] A system message must immediately follow a user turn (including a user turn that carries tool_result blocks) or an assistant turn ending in a server tool result, and must precede an assistant turn or end the array. It cannot sit between a tool_use block and its tool_result. Placing it elsewhere returns a 400 error."

（訳：systemメッセージをmessagesの先頭には置けない。systemメッセージはuserのターン（tool_resultブロックを含むものも可）か、サーバー側ツールの結果で終わるassistantのターンの直後に置く必要があり、assistantのターンの前か配列の末尾に来る必要がある。tool_useブロックとそのtool_resultの間には置けない。それ以外の場所に置くと400エラーになる）

つまり、モデルがツールを呼び出して（tool_use）、その結果（tool_result）が返ってくる一往復の途中にツール変更を割り込ませることはできず、そのやり取りが完結した後でなければtool_addition/tool_removalを挟めません。

tool_addition／tool_removal付きリクエストは自分では送っていない

専用ガイドページを読むことで、当初「わからなかった」としていた具体的な構文・Sonnet 5の非対応・Bedrock/Google Cloudでの提供状況は確認できました。一方で、次の点は本記事の情報源（release notesとガイドページのテキスト）だけでは確認できていません。

• 実際にAPIキーを使ってtool_addition/tool_removal付きリクエストを送り、レスポンスやキャッシュ使用量（cache_read_input_tokens等）がドキュメント通りになるかは、本記事の執筆時点で自分では検証していません
• defer_loading: trueを付けたツールをモデルが実際にどう扱うか（例えばツール一覧に見えない状態でモデルがそのツールを呼ぼうとした場合の挙動）は、ガイドページに具体的な記述がなく確認できていません
• Kimi K3の「Dynamic Tool Loading」が同じ問題をどんな内部実装で解決しているかはMoonshot AI側のドキュメントに技術的な詳細がなく、両者のキャッシュ維持の仕組みを実装レベルで比較することはできていません
• この機能がベータから正式版になる時期は、今回確認した情報源のいずれにも記載がありませんでした

関連記事

• Kimi K3の「Dynamic Tool Loading」
• Claude APIの「computer use」がベータを卒業
• Claude APIが2026年8月に踏んだ変更点まとめ