【ITニュース解説】Treat Every MCP Server Like a Stranger: 7 Client-Side Rules for a .NET 10 Chat Host

システムエンジニアを目指す初心者が、最新のチャットアプリケーション開発において知っておくべき重要な概念と実践的なセキュリティ対策について解説する。最近のチャットアプリは、外部の「MCPサーバー」（ModelContextProtocolサーバー）と連携して、AIモデルがさまざまな「ツール」を利用できるようになっている。例えば、Web検索ツールやデータベース照会ツールなどをAIが呼び出して、より高度な会話や情報提供を行うことが可能になる。この連携は非常に強力で魅力的な機能だが、外部のサーバーを利用する際には多くのリスクが伴うため、慎重な設計が求められる。

外部のMCPサーバーは、自分が開発したものではないため、その信頼性は未知数だ。サーバーが提供するツールが意図しない情報を含んでいたり、他のサーバーと同じ名前のツールを提供したり、応答が非常に遅かったり、巨大なテキストデータを返したり、さらにはモデルの指示を無視させるような悪意のある内容を返したりする可能性もある。最悪の場合、サーバーが利用できない状況も考えられる。このような状況から、自分のチャットアプリケーションを保護するための7つのクライアントサイドのルールが提案されている。

第一のルールは「子プロセスに環境変数を渡さない」だ。チャットアプリケーションが起動する外部サーバー（子プロセス）に、自分のアプリケーションの全ての環境変数を渡してしまうと、APIキーのような機密情報が意図せず漏洩する危険性がある。これを防ぐためには、子プロセスに環境変数を継承させず、必要なものだけを厳選して渡す設定を行うべきだ。例えば、システムのパスやホームディレクトリなど、最低限必要な変数のみを許可し、それ以外の情報は渡さないようにする。

第二のルールは「明示的に許可したもの以外は公開しない」だ。サーバーが提供するツールの一覧をそのままAIモデルに渡してはいけない。許可されたツールのみを厳密なホワイトリスト形式で設定し、そのリストにないツールはモデルに利用させないようにする。ツールの説明に「読み取り専用」と書かれていても、それは単なる主張であり、保証ではないため、信頼できない情報として扱う必要がある。これにより、意図しないツールが実行されるリスクを排除する。

第三のルールは「モデル向けにツール名を変更する」ことだ。複数のサーバーが同じ名前のツールを提供したり、MCPサーバーのツール名がAIモデルが期待する命名規則に合わない場合がある。このような問題を解決するため、モデルに公開するツール名には、どのサーバーからのツールかを示す接頭辞を付け、文字数制限に合わせて短縮・整形する。例えば「weather_search」や「docs_search」のようにすることで、名前の衝突を防ぎ、モデルが理解しやすい形にする。

第四のルールは「全てのツール呼び出しにタイムアウトを設定する」ことだ。外部サーバーの応答が遅いと、チャットアプリケーション全体が応答待ちでフリーズしてしまう可能性がある。これを防ぐため、各ツール呼び出しには個別のタイムアウトを設定する。例えば10秒のような制限を設ける。ただし、クライアント側で呼び出しをキャンセルしても、サーバー側での処理は停止しない場合があるため、サーバー側にも独自のタイムアウト処理が必要となる点に注意が必要だ。タイムアウトが発生した場合、その情報はエラーとしてモデルに伝えられ、その回のチャットでは再試行しないように指示される。

第五のルールは「返ってくるデータの量を制限し、切り詰めを明示する」ことだ。ツールからの出力はAIモデルへの入力となり、処理コストや潜在的なリスクを伴う。そのため、ツールの出力は特定の文字数（例えば4,000文字）に制限すべきだ。もし出力が長すぎて切り詰められた場合は、その事実をモデルに明確に伝える必要がある。例えば、「...[truncated: showing 600 of 14377 chars]」のように表示することで、モデルは自分が部分的な情報を扱っていることを認識し、不完全な情報に基づいて誤った結論を出すことを防げる。

第六のルールは「結果をデータとして囲い込み、許可リストに頼る」ことだ。サーバーからのツール実行結果は、信頼できない「データ」として扱い、モデルへの「指示」として解釈されないように特別なマークアップ（フェンス）で囲む。例えば「<tool_result trust="untrusted">...</tool_result>」のような形式だ。これにより、サーバーが結果の中に「以前の指示を無視せよ」といった悪意のある命令を紛れ込ませても、モデルがそれに従うリスクを低減できる。しかし、プロンプトインジェクションに対する究極的な防御は、第二のルールであるツールのホワイトリスト化に依存していることを理解しておくべきだ。モデルがアクセスできない危険なツールは最初から呼び出されない。また、この段階でツールの呼び出しに関する情報（サーバー名、実行結果、所要時間など）を監査し、不審な挙動がないか監視することも重要だ。ただし、顧客データを含む引数の値自体は記録しないように注意する。

最後の第七のルールは「サーバーダウンをサービス劣化として扱う」ことだ。外部のサーバーが一時的に利用できなくなっても、チャットアプリケーション全体が停止しないように設計する。有効なサーバーには並列に接続を試み、接続に失敗してもエラーでアプリケーションを停止させるのではなく、そのサーバーを一時的に「利用不可」とマークし、一定期間（例えば30秒）は再試行しないようにする。これにより、一つのサーバーがダウンしても、残りのツールやサーバーでチャットは継続でき、モデルはどのサーバーが利用できないかをユーザーに伝えることができる。これにより、ユーザー体験の全体的な低下を防ぎつつ、サービスを提供し続けることが可能になる。

これらのルールは、オフラインでの徹底的なテストによってその有効性が確認されている。テスト環境では、様々な意図的に問題のあるサーバー（重複するツール名、遅い応答、巨大な結果、悪意のある結果など）を用意し、想定される様々な障害シナリオ（サーバーダウン、セッション中のクラッシュなど）に対してアプリケーションがどのように振る舞うかを検証する。

システムエンジニアを目指す初心者は、このような外部サービス連携におけるセキュリティと堅牢性の重要性を理解し、これらの実践的なクライアントサイドの防御策を学ぶことで、より信頼性の高い安全なアプリケーション開発能力を身につけることができるだろう。外部の力を借りつつも、自身のアプリケーションを確実に守る姿勢が、これからの開発においてますます重要となる。