結論：追加するtoolの境界を決め、beta headerとtool一覧を一組で記録する
会話の途中でClaude APIへtoolを追加したい場合は、inline toolsのbeta headerとtool_addition blockの仕様を確認し、tool名・schema・許可理由を同じ実行記録へ残します。2026年9月22日の公式更新では、mid-conversation system messageからtoolを追加・変更・削除する仕組みが案内されています。MCP connectorを併用する場合は、別のMCP beta headerと、取得したtool一覧を記録するmcp_tool_listing blockの扱いも分けて設計します。
便利なのは、会話開始時にすべてのtool定義を固定しなくても、承認された段階で新しいtoolを渡せる点です。しかし、追加のたびに権限境界、prompt cache、応答の再現性が変わります。動的に増やせることを「自動で安全」と読み替えず、toolの追加を変更管理のイベントとして扱ってください。
一次情報はClaude Platform公式リリースノートとtool use公式ドキュメントです。既存のClaude Codeのmanaged MCP運用ガイドがCLIの組織配布を扱うのに対し、この記事はAPIリクエスト中の定義変更に絞ります。
inline toolsとMCP tool listingを比較する
| 機能 | 主な役割 | 先に固定する判断 |
|---|---|---|
| inline tools | 会話途中にtool定義を追加・変更・削除 | 誰が、どのturnで、どのschemaを許可するか |
| MCP connector | MCP serverのtoolを取得して使う | server、認証、tool名、到達先、更新責任者 |
| mcp_tool_listing | 取得したtool一覧を後続会話の証跡にする | 一覧を固定する期間と再取得の条件 |
inline toolsにはinline-tools-2026-09-15 beta header、MCP connectorにはmcp-client-2026-09-15 beta headerが関係します。公式更新にある名前をそのまま採用しても、SDKがそのblockを正しくシリアライズするとは限りません。SDK、直接HTTP、Gatewayの各層で送信内容と応答をreadbackします。tool choiceの制御も、利用可能なtoolの変更と混ぜないでください。
安全に導入する8手順
- 検索・操作を分ける。read-only toolと副作用のあるtoolを分類し、最初の検証は前者だけにします。
- 追加条件を一文にする。「請求確認が必要なturnで、承認済みの照会toolだけを追加」のように業務条件を書きます。
- schemaを版管理する。tool名、引数、必須値、エラー、タイムアウト、所有者をcommitへ紐付けます。
- beta headerを限定する。検証tenantとservice accountを決め、全体の共通clientへ一度に広げません。
- MCP一覧を記録する。serverから取得したtool名と取得時刻、認証scope、変更前後の差分を残します。
- cacheの影響を測る。system messageやtool定義の変化でprompt cacheの再利用条件が変わるため、診断値とusageを比較します。
- 失敗を試す。追加拒否、schema不正、server停止、tool削除、承認期限切れをfixtureで確認します。
- ロールバックする。追加したtoolを参照しない経路へ戻し、以前のtool listingと会話を再現できることを確認してから展開します。
実装レビューのチェックリスト
- inline toolsとMCP connectorのbeta headerを混同していない。
- tool追加の発生元、承認者、対象tenantをログへ残す。
- tool schemaに秘密情報や過剰な権限を含めていない。
- MCP tool listingの取得時刻とserverの識別子がある。
- 追加前・追加後でsystem message、cache、usageを比較した。
- 副作用toolは人間承認、dry-run、idempotencyを確認した。
- server更新でtool一覧が変わった時の停止条件を決めた。
実務では、toolの動的追加より先に「追加しないと何が困るか」を定義します。支払い照会のような読み取りだけなら固定toolを使い、会話の状況に応じてschemaを追加する必要がある時だけinline toolsを候補にします。動的なtool定義は、利用者の入力をそのままschemaや説明へ連結する設計にしないでください。攻撃者がtoolの説明を経由してポリシーを上書きする可能性があるため、許可済みのテンプレートとenumを用意します。
MCPでは、一覧を記録したから安全になるわけでもありません。server側でtoolが差し替わる、認証scopeが広がる、到達先が変わる場合は、listingの差分を変更イベントとして扱います。tool結果の内容を保存する必要がない監査では、名前・schemaのhash・結果の分類だけを残し、本文や個人情報はログへ複製しない方針も検討します。
テストは正常系一つで終えず、同じ会話でtoolを二度追加する場合、追加後に削除する場合、MCP serverが空の一覧を返す場合まで含めます。toolの追加を行うsystem messageが途中で失敗した時、モデルが古い一覧を使い続けるのか、処理を停止するのかを確かめます。失敗時に人間へ返すメッセージには、tool名やschemaの秘密情報を含めず、再試行可能か、承認が必要かを明示します。
監査担当が後から追えるように、会話ID、tool定義のhash、MCP serverの識別子、取得時刻、承認の結果を一つの変更イベントへ束ねます。tool結果の全文を保存しない場合でも、成功・拒否・timeout・副作用実行の分類は残します。さらに、serverの更新でlistingが変わった時に自動展開しない仕組みを置き、schemaのレビュー、代表タスクの再実行、担当者の承認を順番に通してから利用範囲を戻します。
よくある質問と次の行動
toolを会話途中で追加すると、最初のcacheは使えなくなりますか？
tool定義やsystem messageが変わるため、同じcache条件とは限りません。cache diagnostics、usage、latencyを同じfixtureで比較し、断定を避けます。
MCP一覧は毎回再取得すべきですか？
業務のリスクとserver更新頻度で決めます。再取得しない期間、強制再取得の条件、差分発生時の停止を先に定義してください。
導入判断を社内で説明できません。
toolごとに業務価値、権限、失敗時の停止条件を一枚にすると判断しやすくなります。必要なら無料診断で棚卸しできます。
APIのcache診断はcache diagnosticsのGA移行ガイド、モデル選定はClaude APIのモデル一覧ガイド、企業の権限整理は企業利用のセキュリティチェックリストも参照してください。Miraigentの無料診断では、動的toolを使う業務と固定運用で足りる業務を切り分けます。