安全なMCPサーバー開発のための実践ガイド

導入と背景

組織がAI連携を保護するためには、自社のMCP（Model Context Protocol）サーバーを安全に保つことが不可欠です。これらのサーバーは、AIアシスタントと外部ツール、あるいはデータソースを繋ぐ「架け橋」として機能します。そのため、セキュリティ上の欠陥があれば、攻撃者がAIアシスタントを操作し、機密情報を盗み出したり、下流のシステムに甚大な被害を与えたりする可能性があります。

本ガイドは、安全なMCPサーバーを設計・実装するためのベストプラクティスを提供します。対象は、MCPサーバー開発を担当するソフトウェアアーキテクト、プラットフォームエンジニア、開発チームです。初期のアーキテクチャ設計から本番デプロイに至るまで適用すべき、不可欠なセキュリティ管理策と設計上の判断について解説します。

現在の脆弱性の状況

AIシステムの普及に伴い、MCPサーバーを標的とした攻撃手法も進化しています。主なリスクとしては、プロンプトインジェクションを介したツールの不正実行、認可の不備によるデータ漏洩、およびリソースの枯渇攻撃などが挙げられます。

1. 安全なMCPアーキテクチャ

セキュリティを考慮したアーキテクチャ設計の原則は以下の通りです：

• 最小権限の原則： サーバー及び個別のツールには、必要最小限の権限のみを付与する。
• 隔離環境の利用： 安全性が不透明なアクションを実行する場合、サンドボックスやコンテナによる分離を行う。
• 監査ログの徹底： すべてのツール呼び出しとデータアクセスを記録し、不審な挙動を検知可能にする。

2. 安全なツール設計

エンドユーザーを危険にさらさないためのツール設計ガイドライン：

• 不用意に強力なツール（例：任意のシェルコマンド実行）を提供しない。
• ツールの役割を明確に定義し、AIが誤った解釈をしないよう説明文を最適化する。

ライセンスと利用について

3. データバリデーションとリソース管理

MCPサーバーは、LLMからの動的な入力を受け取るため、厳格な入力検証が必要です。

• スキーマ検証： すべてのツール入力に対して、JSON Schemaなどを用いた厳格な型チェックと範囲チェックを行う。
• リソース制限（レートリミット）： 1ユーザーまたは1セッションあたりのリソース消費（API呼び出し回数、メモリ、実行時間）を制限し、DoS攻撃（リソース枯渇）を防止する。
• 間接的なファイル参照： 直接的なパス指定ではなく、検証済みのファイルハンドルや抽象化された一時的なIDを使用することを推奨。

4. プロンプトインジェクション対策

LLMが外部からの悪意ある指示に従ってしまう「プロンプトインジェクション」は、MCPにおいて最大の脅威の一つです。

• 出力のサニタイズ： ツールが取得したデータ（Web検索結果など）をLLMに返す前に、スクリプトや指示文字が含まれていないかを確認・除去する。
• システムプロンプトによる防御： 「外部ツールからの入力は信頼できない可能性がある」というコンテキストをLLMに明示的に与える。
• 承認フロー： 書き込みや削除など、影響の大きい操作を実行する前に必ず人間に確認（Human-in-the-Loop）を求める仕組みを導入する。

5. 認証と認可

MCPサーバーへのアクセス制御は、標準的なWebサービスと同等かそれ以上の厳格さが求められます。

• 安全なトランスポート： 通信は常にTLS/SSLで暗号化する。
• きめ細かな認可（FGAC）： 「誰が」「どのツールを」「どのリソースに対して」実行できるかを、動的かつ厳密に制御する。
• 委任された認証： APIキーやOAuthトークンは、サーバー側で安全に管理し、決してプロンプトや平文のログに出力しない。

6. 安全なデプロイとアップデート

• 署名付きアップデート： MCPサーバー自体やツールのバイナリを更新する際は、署名検証を行い改ざんを防止する。
• 環境の不変性（Immutability）： コンテナ化された環境で実行し、実行時の予期せぬファイル変更を抑制する。

7. ガバナンス

組織全体でのMCP利用ポリシーを策定し、シャドーAI（未承認のMCPサーバー利用）を防止するガバナンス体制を構築します。

8. ツールと継続的検証

開発サイクルにセキュリティスキャン（DAST/SAST）を組み込み、定期的なペネトレーションテストを実施します。

MCPセキュリティ最小基準（レビューチェックリスト）