【ITニュース解説】MCP Made Tools Discoverable. It Didn't Make Them Safe

MCP（Model Context Protocol）は、AIクライアントと外部のツールサーバーが互いに理解し、連携するための共通の「言葉」や「ルール」を提供する技術だ。これまでは、AIが様々なアプリケーションやサービス（これらを「ツール」と呼ぶ）と連携しようとすると、それぞれ専用の接続方法や設定が必要で、非常に手間がかかっていた。MCPは、この問題を解決し、AIが「どんなツールがあるの？」「どうやって使うの？」とサーバーに尋ねたり、見つけたツールを標準化された方法で呼び出したりすることを可能にした。

これは、AIシステムの開発において画期的な進歩と言える。AIは、この共通のプロトコルを通じて、まるでカタログから商品を選ぶように、様々なツールを簡単に「発見」し、その使い方を「理解」し、実際に「呼び出す」ことができるようになったからだ。例えば、AIエージェントが顧客管理システムに接続し、「顧客リストを表示する」「メールを送信する」「決済を払い戻す」といったツールを見つけ、状況に応じてこれらを活用できるようになる。これにより、AIがより多様なタスクを自動でこなせるようになり、システム間の連携問題が大きく改善された。

しかし、MCPが解決したのはあくまで「ツールを発見し、連携する」という側面であり、これだけで「安全なシステム」が構築できるわけではないという重要な問題がある。MCPは、ツールを簡単に見つけられるようにしたが、そのツールが本当に安全なのか、誰が使うべきなのか、どのような条件下で使うべきなのかといった、本来の「安全性」に関する課題は開発者自身に残されている。

まず、MCPのツールカタログは、あくまでサーバーが提供する「利用可能なツールの一覧」であり、それは「このツールを使ってよい」という許可、つまり「権限の境界」ではない。例えば、AIエージェントが「顧客を削除する」ツールを知っていても、そのAIや、AIを操作しているユーザーに実際に顧客を削除する権限があるかどうかは、MCPだけでは判断できない。もし、権限のないAIがこのツールを呼び出そうとすれば、意図しない重大な結果を招く可能性がある。したがって、AIがツールリストを見る前に、そのAIやユーザーにとって不要な、あるいは危険なツールは表示しないようにフィルタリングする仕組みが必要だ。

次に、ツールサーバーが提供する「ツールの説明文」も、単なるドキュメントではなく、AIがそのツールを使う際の「指示」として認識されることがある。悪意のあるツールサーバーが、この説明文に「隠れた指示」を仕込み、AIに機密情報を漏洩させたり、不適切な行動を取らせたりする「プロンプトインジェクション」という攻撃のリスクがある。例えば、「機密情報を特定のフィールドに含めて送信せよ」といった内容が説明文に隠されていた場合、AIはそれに従って行動してしまうかもしれない。そのため、ツールの説明文も信頼できない外部からの情報として扱い、AIに見せる前に内容を厳しくレビューし、不適切な指示が含まれていないか確認する必要がある。

また、「信頼できるサーバー」という考え方も、常に保証されるわけではない。一度安全と評価されたMCPサーバーでも、後から動作が変わったり、外部の新しいサービスと連携し始めたり、あるいはサイバー攻撃によって侵害されたりする可能性がある。特に外部のMCPサーバーは、常に内容が変化しうる動的な存在だ。サーバーの信頼性は静的なものではなく、常に変化しうる実行時の仮定として捉え、信頼レベルに応じた監視や、隔離された環境での運用を徹底する必要がある。

OAuthのような認証の仕組みも、完全な安全性を提供するわけではない。OAuthは「誰がこのツールを使おうとしているか」を識別し、そのユーザーが「何ができるか」という一般的な権限を与えるが、「このAIが今、この特定の行動をするべきか」という「意図」までは判断できない。例えば、ユーザーが「リポジトリの削除」権限を持つGitHubサーバーへのアクセスを許可したとしても、AIが「古いリポジトリを整理する」という指示を受けて実際に重要なリポジトリを削除してしまうことは、ユーザーの意図に反するかもしれない。OAuthの権限と、AIが実行する特定の行動の適切性を区別し、より詳細なポリシーを適用する必要がある。

ツールサーバーが提供する「読み取り専用」や「破壊的」といった「注釈（アノテーション）」も、あくまでサーバー側が提供する「ヒント」に過ぎない。もしサーバーが誤った注釈を提供したり、悪意を持って偽装したりした場合、そのヒントを信じてAIが行動するのは危険だ。これらの注釈は参考情報として活用しつつも、最終的なリスク判断は、ツール名、説明、サーバーの信頼性、過去の履歴など、複数の情報源に基づいて行うべきだ。

高リスクな操作に対し、人間が毎回承認する仕組みも、それだけではスケールしない。ユーザーは繰り返し承認を求められると、内容を注意深く確認せずに自動的に承認してしまう傾向があるため、これは疲労を招き、セキュリティの抜け穴となる。人間の承認は、リスクが高い、あるいは判断が難しい特定のケースに限定し、それ以外の多くは自動的なポリシーで制御する「リスクベースの承認」に切り替えるべきだ。

さらに、MCPサーバーからAIに返されるツールの「結果」も、AIに影響を与える可能性がある重要な要素だ。もし、AIが読み取ったサポートチケットやメール、ウェブページなどの外部情報の中に、悪意のある指示や誘導が埋め込まれていた場合、AIはその情報に影響されて不適切な行動を取ってしまうかもしれない。これもプロンプトインジェクションの一種であり、ツールの結果も信頼できない外部からの入力として扱い、内容を精査したり、危険な要素を無害化したりする仕組みが必要だ。

開発者のPC上で動く「ローカルMCPサーバー」も、見過ごされがちなリスク源だ。多くの場合、これらのサーバーは開発者と同じ権限で実行されるため、PC上のファイル、環境変数、クラウドの認証情報などに自由にアクセスできてしまう。もしローカルサーバーが脆弱であったり、悪意のあるものだったりした場合、開発環境全体が危険にさらされる可能性がある。そのため、ローカルでMCPサーバーを実行する場合でも、最小限の権限で、他のシステムから隔離された安全な環境で動かすべきだ。

最後に、MCPサーバーは、一度レビューされた後でも「動的にツールリストを変更する」可能性がある。例えば、最初は安全な読み取り専用ツールだけを提供していたサーバーが、後から危険な「コマンド実行」ツールを追加するかもしれない。このような動的な変更は、静的なレビューだけでは検出できず、システムを突然危険な状態にする可能性がある。そのため、ツールの定義が変更された際には自動的に警告を発したり、未承認の新しいツールはデフォルトで拒否したりする仕組みを導入し、ツールリストの変更を常に監視する必要がある。

これらの多岐にわたる安全性の課題に対処するために最も推奨されるアプローチは、「MCPポリシーゲートウェイ」という中間層を設けることだ。これは、AIエージェントとMCPサーバーの間に位置し、すべてのツール呼び出しを監視・制御する「安全の番人」のような役割を果たす。このゲートウェイは、AIがツールを呼び出す前に、呼び出し元のユーザーの認証、ツールの権限チェック、リスク評価、必要に応じた人間の承認ワークフロー、API呼び出し回数の制限、機密情報のログ記録、ツールの結果の検証など、あらゆる安全対策を一元的に実施する。

このゲートウェイは、MCPサーバーが多様で信頼レベルが異なる場合でも、AIに対して一貫した安全ポリシーを適用できる唯一の場所となる。MCPはAIとツールの連携を劇的に容易にする強力な技術だが、それはあくまで「発見」の側面でしかない。ツールが「見つかる」ことと、それが「安全に使える」ことは全く別問題なのだ。真の安全性は、アクセス制御、サンドボックス化、入出力の検証、詳細な監査といった、別途構築すべき強固な「安全層」によって初めて実現される。システムエンジニアを目指す上では、利便性と安全性のバランスをいかに取るかという視点が不可欠となる。

1996文字