はじめに

Model Context Protocol（MCP）は、AIアプリケーションが外部の機能やデータに接続するための構造化された方法を定義します。中心となる要素は、ホストアプリケーション、MCPクライアント、1つ以上のMCPサーバーです。ホストは、IDEやアシスタントアプリケーションなど、ユーザーが操作するプロダクトです。通常、サーバーごとに個別のクライアント接続を確立し、プロトコルの状態、ケイパビリティ、障害が正しいサーバーに関連付けられた状態を維持します。

MCPサーバーは、プロトコル操作を通じてケイパビリティを公開します。ツールは、サービスへの問い合わせ、レコードの変更、メッセージの送信、その他の副作用を伴う処理を実行できる操作です。リソースはクライアントが取得できるデータを表し、プロンプトは再利用可能なプロンプトテンプレートや対話パターンを提供します。これらの分類はアーキテクチャ上有用ですが、MCP経由で提供されたという理由だけで、いずれかを信頼できるものとして扱ってはなりません。本番環境のセキュリティは、各コンポーネントの所有者、各接続を通過するデータ、操作が行使できる権限によって決まります。

リクエストフローとコンポーネントの役割

一般的なインタラクションは、ホストがサポート対象のトランスポートを介してMCPサーバーとのセッションを確立するときに始まります。クライアントとサーバーはプロトコルセッションを初期化し、サポートするケイパビリティを相互に通知します。その後、ホストは利用可能なツール、リソース、プロンプトを検出し、それらのケイパビリティをユーザーエクスペリエンスやモデルコンテキストにどのように反映するかを決定できます。ローカルデプロイメントとリモートデプロイメントでは使用するトランスポートが異なる場合がありますが、信頼に関する問いは変わりません。

モデルがツール呼び出しを提案した場合、リクエストを転送する前に、ホストまたはクライアントがプロダクトのインタラクションポリシーと認可ポリシーを適用する責任を負います。サーバーはリクエストを再度検証し、自身の認証情報と実行時権限を使用して操作を実行します。結果はサーバーとクライアントを経由してホストに戻り、ユーザーに表示されたり、モデルコンテキストに追加されたりします。この繰り返し検証は意図的なものです。クライアント側のポリシーは安全でないリクエストを減らし、サーバー側の検証は、別のクライアントや不正な形式のメッセージが到達した場合にもサーバーを保護します。

リソースの読み取りも関連する経路をたどりますが、リスクプロファイルは異なります。サーバーは要求されたリソースを解決し、コンテンツまたはメタデータを返します。読み取り専用であっても無害とは限りません。リソースには、機密情報、悪意のある指示、個人データ、または古くなったコンテンツが含まれている可能性があります。ホストは出所情報を保持し、コンテンツを提示または利用する前にアクセス制御を適用する必要があります。

開発環境における信頼境界

最初の境界は、ユーザーとホストアプリケーションの間にあります。ホストは自然言語によるリクエスト、ツールの実行結果、リソースの内容、さらに外部システムからの指示を受け取ります。本番環境のホストは、取得したコンテンツ内のすべての指示がユーザーの意図を表しているとは限らないことを前提にすべきです。特に、データを変更する、第三者に連絡する、金銭を使用する、または秘密情報を外部に露出させる操作については、確認のための明確なルールが必要です。

2つ目の境界は、ホストのMCPクライアントとサーバーの間にあります。サーバーは、パッケージからインストールされたローカルプロセス、別途管理される社内サービス、または別のチームが運用するリモートサービスの場合があります。これらのデプロイ形態によって、認証、分離、更新のモデルは変わります。ローカルプロセスであっても、ファイルの読み取り、環境変数の継承、ネットワーク上の宛先へのアクセス、脆弱な依存関係の実行が可能な場合があります。リモートサーバーも、機密性の高い引数を受け取り、モデルの動作に影響を与えるコンテンツを返す可能性があります。

3つ目の境界は、MCPサーバーとその下流システムの間にあります。サーバーは、データベース、クラウドAPI、ファイルシステム、チケット管理システム、またはシェルコマンドを呼び出すことがあります。MCP認証によって、これらの下流操作が自動的に認可されるわけではありません。サーバーは、権限範囲を厳格に限定したサービスID、明示的な宛先制御、タイムアウト、レート制限、操作ごとの認可を使用すべきです。無制限の管理者リクエストを発行できるサーバーは、MCPインターフェースで公開しているツールが少数であっても、影響度の高いコンポーネントです。

本番環境におけるIDと認可

認証は接続している主体を示すものであり、認可はそのIDで実行できる操作を示すものです。本番環境にデプロイする場合は、可能な限りホストまたはユーザーのコンテキストと、MCPサーバーを別々に識別します。すべてのクライアントとサーバーで1つの共有認証情報を使用することは避けてください。IDを分離すると、失効処理、インシデント調査、レート制限、最小権限の適用が改善されます。リモートデプロイでは、安全なトランスポートと認証情報の取り扱い方法も必要です。認証情報をツールの引数に含めたり、ツールの実行結果として返したりしてはいけません。

互換性のためにケイパビリティネゴシエーションは有用ですが、認可の判断ではありません。サーバーがツールをサポートしていると通知したからといって、特定のユーザーがすべてのツールを呼び出せるとは限りません。認可は、要求された操作、対象、テナント、データ分類に基づいて評価すべきです。たとえば、同じサーバーで両方のケイパビリティが公開されている場合でも、ユーザーにはプロジェクトリソースの読み取りは許可し、プロジェクトの削除は許可しないことができます。

ツールスキーマは入力の制約に役立ちますが、スキーマだけでは完全なセキュリティポリシーにはなりません。サーバーは、型、範囲、長さ、識別子、フィールド間の関係を検証すべきです。予期しない宛先、安全でないファイルパス、無効なテナント参照、呼び出し元の権限範囲を超えるリクエストは拒否する必要があります。影響度の高い操作については、ホストがユーザーによる明示的な承認を要求し、実行前に対象、意図する効果、重要なパラメーターを表示することがあります。承認は特定の操作に紐付けるべきであり、恒久的な権限として扱ってはいけません。

運用制御と障害対応

本番運用では、リクエスト経路全体を可視化する必要があります。どのIDがリクエストを開始したか、どのサーバーが処理したか、どのツールまたはリソースが選択されたか、認可結果、下流処理の結果を記録します。秘密情報や不要な個人データはマスキングしてください。クライアント、サーバー、下流システムのログをリクエストIDで相関させます。ただし、ログ自体がアクセス制御と保持ルールを必要とする機密性の高い資産になることにも注意してください。

部分的な障害を前提に設計します。サーバーが利用できない場合、下流APIがタイムアウトする場合、レスポンスがサイズ制限を超える場合、またはツールが副作用を作成した後にエラーを返す場合があります。ホストは不確実性を明確に伝えるべきであり、明確なポリシーなしに非冪等な操作を自動再試行してはいけません。サーバーは、上限付きのタイムアウト、制御された同時実行数、レスポンスサイズの制限、予測可能なエラー処理を使用すべきです。高コストまたは不安定な依存先には、サーキットブレーカーやレート制限が適切な場合があります。

更新と設定をトラストモデルの一部として扱います。サーバーのバージョンを固定またはレビューし、デプロイ成果物の提供元と完全性を検証し、ソースコードの外部で秘密情報を管理し、ローカルプロセスが継承する環境を制限します。不正な入力、認可されていない対象、過大な結果、リソース内のプロンプトインジェクション、下流障害を使ってツールの動作をテストします。セキュリティレビューでは、MCPサーバーが公開する名前や説明だけでなく、ランタイムが実際に持つ有効な権限を調査すべきです。

よくある誤りと実践的なレビュー

よくある誤りは、ツールの説明をセキュリティ契約であるかのように信頼してしまうことです。説明は検出に役立ちますが、侵害されたサーバーや適切に保守されていないサーバーは、危険な操作を無害な表現で説明する可能性があります。実装、IDに付与された権限、ネットワーク接続先、データフロー、承認動作を確認してください。同じ注意は、promptテンプレートやリソースメタデータにも当てはまります。これらはモデルの動作に影響を与えられますが、権限の根拠にはなりません。

もう1つの誤りは、ローカル開発環境を本番環境の信頼モデルとして扱うことです。開発者は、広範なファイルシステムアクセス、個人の認証情報、制限のない外向きネットワークアクセス、詳細なログ出力を備えたサーバーを実行することがよくあります。本番環境では、これらのデフォルト設定を、専用のランタイムID、制限された作業ディレクトリ、最小限の環境変数、明示的なegressルール、管理されたデータ取り扱いに置き換える必要があります。本番環境で実際に付与される権限を使ってデプロイメントをテストしてください。

レビューでは、代表的な読み取り操作と代表的な書き込み操作を1つずつ選び、ユーザーのリクエストから下流の影響に至るまで追跡してください。各ステップについて、ID、入力検証、データ分類、承認要件、タイムアウト、監査イベント、障害発生時の動作を特定します。いずれかのステップを正確に説明できない場合、その境界はまだ運用上明確に定義されていません。この方法により、MCPサーバーは信頼できるという一般的な説明に頼るのではなく、具体的な是正作業を導き出せます。

まとめ

MCPはホストの体験とサーバーが提供する機能を分離しますが、それらの間にあるセキュリティ境界をなくすものではありません。ホストはユーザーとの対話とクライアントセッションを管理し、サーバーはリクエストを検証してツール、リソース、promptを実装します。下流システムはそれぞれ固有の権限と障害モードを持つ、独立した権限主体であり続けます。

本番環境では、明確なID、最小権限、サーバー側での検証、影響の大きい操作に対するユーザー承認、取得したコンテンツの慎重な取り扱い、実行範囲の制限、そして有用な監査証跡を重視してください。機能ネゴシエーションは相互運用性を支えますが、実際に何を実行できるかを決めるのは認可です。実務上の目標は、MCPを単一の単位として信頼するか疑うかではなく、すべての境界を文書化し、そこを通過するデータと権限に応じた制御を適用することです。