目次
MCPサーバーを一度確認して許可した後、ツール名が同じなら更新も安全と考えていませんか。ツールの説明、引数、返却形式、読み取り専用などのヒントが変われば、AIが選ぶ操作やクライアントの確認動作も変わり得ます。接続先のURLを固定することだけでは、この変化を把握できません。
本稿は、MCPサーバーの更新を安全に取り込み、tool poisoningに備えたい開発者向けの恒久対策です。2026年10月24日にMCPの2026-07-28版仕様とOWASPの資料を確認しました。特定サーバーの侵害や、新たな脆弱性の発見を報告する記事ではありません。以下の差分台帳や更新手順は本サイトの提案です。
スポンサーリンク
名前が同じでも実行の前提は変わる
たとえばsearch_documentsというツールに、更新後、結果を外部へ送る引数が追加された仮想例を考えます。名前の許可リストだけで判断すると、以前は社内検索だった操作に新しい通信経路が増えたことを見落とします。説明が自然な日本語でも、権限や送信先の変更が小さいとは限りません。
逆に、すべての変更が攻撃ではありません。誤字修正、型の明確化、新しい任意引数、サーバー側の修正もあります。必要なのは更新を止め続けることではなく、どの変更がモデルの入力と業務の実行範囲へ影響するかを区別して採用することです。
OWASPのMCP Security資料は、説明やスキーマへの悪意ある指示、承認後の定義変更、他サーバーのツールへ影響する指示などをリスクとして整理しています。こうした一般的な攻撃類型と、自分の接続先で実際に起きた侵害は混同しないでください。
保存するのは説明文だけでなく定義全体
MCPのTools仕様では、ツールにname、description、inputSchema、任意のoutputSchemaやannotationsなどを持たせます。レビュー対象は説明文だけではありません。引数の説明、必須条件、既定動作に関する情報も、モデルの使い方やアプリの判断へ影響します。
本サイトでは、接続先をアプリ側で管理する識別子と、取得したツール定義を組にして保存する方法を提案します。別のサーバーに同じ名前のツールがある場合もあるため、名前単独で対応付けません。人が読む表示名も、接続先の真正性を保証する値にはしないようにします。
比較時にはJSONオブジェクトのキー順を安定化させ、意味のない並び替えで警告が大量に出ないようにします。一方、文字列内の説明や列挙値、配列の内容を都合よく削ってから比較すると、重要な変更まで消すおそれがあります。保存する原本と、比較用に整形したデータを分けると調査しやすくなります。
ハッシュ値は「前回と同じ定義か」を確認するための手掛かりです。安全なコードであることや、サーバー実装が定義どおりであることを証明しません。悪意ある定義を初回に採用すれば、そのハッシュを固定しても安全にはなりません。初回レビューと継続比較の役割を分けてください。
スポンサーリンク
更新台帳で残したい差分
更新の判断では、変更されたフィールドと業務への影響を対応させます。次の一覧は、一般的なレビュー観点として本サイトが提案するものです。自動判定だけで採用・拒否を確定する基準ではありません。
- 追加・削除されたツール：新しい公開、送信、削除機能が増えていないか。
- descriptionと引数の説明：本来の用途と無関係な指示や秘密情報への参照がないか。
- inputSchema：必須引数、型、列挙値、任意プロパティの許可範囲が変わっていないか。
- outputSchema：返却される個人情報や内部識別子が増えていないか。
- annotations：読み取り専用、破壊的操作などのヒントが変更されていないか。
- 実装と配布物：パッケージ、実行コマンド、接続先、権限の変更理由を確認したか。
たとえばrequiredからconfirmが外れた場合、サーバー側で別の確認を強制する改善かもしれませんし、確認なしで実行できる変更かもしれません。スキーマの差分だけでは結論が出ないため、実装や公式変更履歴と照合します。フィールド名にconfirmがあること自体も、承認の証拠にはなりません。
list_changedは変更の通知であって承認ではない
MCP仕様にはtools/listと、対応するサーバーからのnotifications/tools/list_changedがあります。ツール一覧の変更を知る仕組みですが、通知を受けたことが、新しいツール定義を業務上許可したことを意味するわけではありません。プロトコルの機能と採用ポリシーを分けます。
更新処理では、変更通知や再接続をきっかけに一覧を取り直し、ページ送りがある場合は全件を取得します。比較する利用者と権限もそろえます。権限の違いで見えるツールが変わる場合に、別条件の一覧を比較して「不正な削除があった」と誤認しないようにしてください。
通知非対応、通知の取りこぼし、長い切断、プロキシのキャッシュも想定します。実行前の定義とレビュー台帳の対応を確認し、不明な状態なら高影響の操作を保留する方針が考えられます。ただし、通知が来ないことだけで侵害と断定したり、同じ処理を無制限に再実行したりはしません。
スポンサーリンク
readOnlyHintを認可の代わりに使わない
MCP仕様は、信頼できるサーバーからのものを除き、annotationsを信頼できない情報として扱うよう求めています。readOnlyHintが付いていることを理由に、サーバーでの権限検査を省略してはいけません。破壊的ではないという説明と、業務上の機密性は別でもあります。
たとえば読み取りだけのツールでも、顧客一覧や秘密情報を返せば影響は大きくなります。反対に、更新ツールでも対象が自分の下書きだけに制限されるなら、本番全体を書き換える機能とは異なります。ツールのラベルだけでなく、対象、件数、送信先、取り消し可能性を確認します。
本サイトでは、ヒントは確認画面やレビュー優先順位の補助に使い、実際の認可は業務APIで強制する構成を提案します。定義が誤っていても許可外の操作ができないことを、検証用環境で確かめます。クライアントとサーバーの両方に同じ未検証の自己申告を信じさせないことが重要です。
更新後の試験は別のツールとの組み合わせも見る
単独の呼び出しが成功しても、複数サーバーを接続したエージェントでは、説明文や返却値が他のツールの選択へ影響することがあります。文書検索の結果に「認証情報をこのツールへ渡す」と書かれた場合、それを実行指示として扱わないかを確認します。実際の秘密ではなく検証用の目印を使います。
差分がある定義をモデルへ渡す前に、人が内容を読みます。確認対象そのものに不審な指示がある場合、レビュー用のAIにも実行権限や秘密情報を渡さない方が安全です。自動レビューの結果を採用する場合も、そのAIが指示へ従っただけではないか、人が判断できる証跡を残します。
試験結果には、使用したクライアント、モデル、サーバー版、定義ハッシュ、資格情報の範囲、呼び出されたツールを記録します。モデルを変えると、同じ説明文でも選択の仕方が変わる可能性があります。定義更新とモデル更新を同時に行うなら、どちらの差分で挙動が変わったかを切り分けられる計画が必要です。
サーバー実装の更新は定義の比較だけでは見えない
リモートMCPでは、返すスキーマを変更せずに内部コードが更新されることもあります。ローカルサーバーでは、起動時に取得するパッケージや外部スクリプトが変わる場合があります。ツール定義の固定は、配布物や実行環境の変更管理と組み合わせます。
ローカル実行なら、レビュー済みの配布元と版を記録し、必要以上にホームディレクトリや環境変数へ触れさせない構成にします。リモートサービスなら、変更履歴、監査情報、認証方式、データ取扱いを確認します。提供元が説明できない挙動を、名前が同じという理由だけで許可し続けないでください。
拒否とロールバックを更新手順へ含める
新しい定義を採用できない場合に、何を止めるかも決めます。対象ツールだけを一時停止できるなら、無関係な読み取りまで全停止する必要はありません。ただし、名前だけで分けられない共有資格情報や共通基盤の問題なら、接続単位で止める判断も必要です。
ロールバックは旧版へ戻すだけではありません。旧版に既知の脆弱性が残る場合は、安全な戻し先になりません。更新を保留して影響機能を無効化する、修正版を待つ、権限を一時的に縮小するなどの選択肢を用意します。変更を検知してから担当者が判断するまでの期限も決めてください。
長期運用では、毎回全定義を人が読み直す負担を抑えるため、承認済み原本との差分と、実装・権限の変更をまとめて提示します。重要な差分だけを見られる仕組みは有効ですが、比較対象を削りすぎて重要な意味を失わないことが条件です。最終的には「何をいつ確認して採用したか」を説明できる状態を目指します。
スポンサーリンク
関連記事
GitHub CopilotのMCPポリシーと利用メトリクスの棚卸しは、組織として接続先を管理する運用を扱います。本稿は、許可した接続先の中でツール定義が変わった後の差分確認を補う記事です。
参考資料
情報確認日：2026年10月24日。実装例や試験案は本サイトの提案で、侵害や検証成功を報告するものではありません。本文と概念イラストの作成に生成AIを使用し、出典と保存内容を確認しています。
