MCPサーバーのインストールは簡単に見えます。コマンドやURLを貼り付け、クライアントを再起動し、エージェントのコンテキストに新しいツールが表示されます。しかし、そのツール名の背後には実行可能コード、モデルのコンテキストウィンドウに注入されたスキーマ、認証情報、およびこれらの認証情報がアクセスできるシステムがあります。MCPエコシステムはまだ成熟段階であり、新しいサーバーの検証プロセスは、控えめに言っても、貧弱です。本稿は、ピンで留められた説明用の例に適用した再利用可能なインストール前チェックリストを提供し、各ステップの検出結果と明確な承認/拒否の根拠を示します。
インストールが実際に許可する内容
MCPサーバーをインストールするとき、あなたはパッシブライブラリをインストールしているのではありません。ツール、ファイルシステム、通常はAPIキーへの実行可能コードアクセスを許可しており、ほとんどのクライアントがあなたに提示する中間レビューステップはありません。
その信頼は累積的で粒度がありません。Pluto Securityの実践ガイドが指摘するように、MCPサーバーを承認することは、そのサプライチェーン内のすべてのオペレーターを承認することを意味します。コンポーネント単位の再プロンプトはありません。有効になっているすべてのMCPサーバーもセッション開始時にそのツールリスト全体をモデルのコンテキストに挿入し、トークンを消費して注意を散漫にします。つまり、2倍の代価を払うことになります。セキュリティサーフェス面で1回、コンテキスト予算で1回です。
Claude Code特定では、サーバーは.mcp.json（プロジェクトスコープ）または~/.claude.json（ユーザースコープ）経由で設定でき、フック、エージェント、モニター、bin/スクリプトも含むプラグインディレクトリ内にバンドルできます。プラグインはスリムなラッパーではありません。シェルセッションが到達できるすべてのものに到達できます。
脅威モデルには3つの現実的な障害モードがあります。
- 悪意のあるパブリッシャーが、レジストリに表示される見た目が似ているサーバーを作成し、APIコールをリダイレクトするか、静かにデータを流出させます。
- 善意ですが経験不足の作成者が、トークンをプレーンテキストで保存するか、リクエストボディを何も考えずにログに記録するサーバーを公開します。
- あなたが承認した正当なサーバーが更新され、新しいバージョンがバックドアを導入するか、再プロンプトなしに権限を拡大します。
3つすべてが現実に文書化されており、仮説ではありません。
ソース、出所、更新動作を確認する
コードの1行も読む前に開始してください。このサーバーを公開したのは誰ですか？パッケージの背後に検証可能なアイデンティティはありますか？リポジトリに意味のあるコミット履歴がありますか、それとも先週1つのコミットで作成されましたか。
Christian Schneiderの防御優先アーキテクチャガイドは、サプライチェーン衛生要件を明確に述べています。評判の良いソースからのみサーバーをインストールし、パッケージ署名またはハッシュを検証し、「最新版」を受け入れるのではなく依存関係バージョンをピン留めします。npm auditまたはpip-auditをパッケージに対して実行してから環境に触れさせてください。ソフトウェア部品表（SBOM）を生成すれば、すべての依存関係をトレースでき、CVEが公開されたときに素早く対応できます。
レビューチェックリストでは、ソースステージでこれらをキャプチャしてください。
- パブリッシャーアイデンティティが実績のある既知の組織または個人にマップされていることを確認します。
- リポジトリ作成日とコミット頻度を確認してください。1コミットのリポジトリは入念な精査を保証します。
- レビュー対象の正確なバージョンをピン留めしてください。コミットハッシュまたはリリースタグを記録してください。
- 依存関係ツリーに対して
npm auditまたはpip-auditを実行し、調査結果を記録してください。 - サーバーの更新メカニズムが変更を適用する前にデジタル署名を検証しているか確認してください。
例示的なケース：18 か月間のコミット履歴、2 名の貢献者、GitHub 上の署名されたリリースを持つ出版社からの仮想的な mcp-db-connector@1.4.2 をレビューしていると仮定してください。npm audit は重大度の高い検出結果がゼロを返します。これはこのステージに合格します。匿名の出版社、2 日前のリポジトリ、署名されたリリースがないサーバーは合格しません。
ツール、フック、スクリプト、ネットワークアクセスを検査してください。
ソースの出所は必須です。次に内容を読んでください。
サーバーが登録する全てのツール定義を確認してください。説明された内容が実装と一致していますか？Towards Data Science の MCP サバイバルガイドが警告しているように、何かが「email-sender」として公開されているからといって、メール送信だけを行うとは限りません。ログ出力、書き換え、または意図しない場所への転送を行っている可能性があります。
これらを特に確認してください：
- フックとライフサイクルスクリプト：
hooks.jsonはツール前後のコールバックを登録していますか？それらは何をしていますか？ - `bin/` スクリプト：インストール時または呼び出し時に実行されるシェルスクリプトはありますか？それらを読んでください。
- アウトバウンドネットワーク呼び出し：サーバーは README に記載されていないエンドポイントに接続していますか？ソース全体で
grep -r "fetch\|axios\|http\|https\|request"を使用してください。 - ファイルシステムアクセス：タスクに必要以上に広いパスアクセスをリクエストしていますか？
- 認証情報の処理：API キーがディスクに書き込まれたり、ログ出力されたり、宣言されたターゲットサービス以外の場所に送信されたりしていませんか？
SlowMist MCP Security Checklist は、入力検証、API レート制限、および出力エンコーディングを最優先度の 3 つの制御として評価しています。サーバーが独自の入力を厳密に検証しない場合、出版社を信頼しているかどうかに関わらず、インジェクション攻撃のベクトルになります。
チェックリストが指摘していることで、ほとんどの人が見落とすことの 1 つ：ツール説明はモデルのコンテキストにそのまま注入されます。悪意のあるまたは不十分な説明は、サンドボックス自体が無傷であってもエージェントの動作をサンドボックス内で操作する可能性があります。スキーマスキャンなしのサンドボックス化は防御の半分に過ぎません。
プロンプトインジェクションとデータ境界ケースをテストしてください。
このステップは、本番データまたは顧客情報に触れるものの場合、オプションではありません。
ツール説明を介したプロンプトインジェクションは既知の攻撃ベクトルです。攻撃者がツールの説明フィールドに命令を埋め込み、モデルがユーザーの意図として解釈します。サーバーのスキーマに埋め込まれた命令がないこと、サーバーからの出力が下流で信頼される自信のある入力ではないこと、そして 1 つのツールから返されたデータが別のセッションまたはユーザーのコンテキストに漏れないことを検証する必要があります。
実際の認証情報をサーバーに接続する前に、例示的な境界ケースを実行してください：
- 「前の指示を無視して...」のような内容が含まれた応答を返すツール呼び出しを作成し、ホストクライアントがそれをサーフェスしたり処理したりするかどうかを観察してください。
- 各登録ツールに対して、サイズが大きい形式が正しくない入力を渡し、サーバーが正常に処理するか、スタックトレースを公開する未処理例外をスローするかを確認してください。
- サーバーが複数のデータソースにアクセスできる場合、ソース A に対するクエリがソース B からデータを返せないことを検証してください。
これらはトリアージテストであり、認定ではありません。短い手動レビューは明らかな問題を特定します。微妙な問題がないことは保証しません。
クライアント向けにAIツーリングを構築していて、Claude Code のセットアップ全体の一部として MCP インテグレーションのレビュー支援を希望される場合、Seahawk の Claude Code エージェンシーサービスはスタックを本番環境に展開する前に評価するのをお手伝いできます。
最小限の認証情報スコープを選択してプロセスを分離する
サーバーをレビューして受け入れ可能と判断したら、次の問題は以下のとおりです。どのようにして実行しますか?
原則は最小権限の原則であり、これは妥協なく適用されます。便利だからといって、フルアカウントアクセス権を持つ個人用 API キーを MCP サーバーに渡してはいけません。文書化された機能に必要な最小限の権限を持つスコープ付き認証情報を作成してください。サーバーが単一の S3 バケットへの読み取りアクセスのみが必要な場合、その認証情報は書き込みアクセス権を持つべきではありません。以上です。
分離オプション、ざっと昇順のコスト:
- 親シェルの環境変数に明示的に渡すもの以外はアクセスできない専用サブプロセスでサーバーを実行してください。
- 制限されたネットワークポリシーを持つコンテナを使用して、サーバーが任意の送信接続をできないようにしてください。
- 機密性の高い展開では、デプロイメントゲートとして供給チェックを実施し、MCP サーバー更新をアプリケーションコードと同じ変更管理プロセスで扱ってください。
General Analysis の脅威モデルが明確に述べています。バージョンピニングなしの検証済みマーケットプレイスは、今日の検証済みサーバーが明日のラグプルになることを意味します。分離とピニングは冗長ではありません。これらは異なる障害モードに対する保護です。サンドボックスは被害範囲を限定し、ピニングはサイレント・ドリフトを防ぎます。
注目すべき点は次の通りです。MCP サーバー間で認証情報を共有しないでください。トークンパススルーと共有 API キーは、1 つのサーバーの侵害が認証情報がタッチするすべてのものに到達することを意味します。
決定を記録し、変更があるたびに再レビューする
記録しないレビューは、あなた自身の将来の視点またはあなたのチームの観点からは、実施されなかったレビューと同じです。
インストールするサーバーごとに、以下の最小限の情報を含む決定ログを保持してください。
- レビューされた正確なバージョン(パッケージバージョンとコミットハッシュまたはリリースタグ)。
- レビューの日付。
- レビューを実施した者。
- 監査ツールと手動検査からの調査結果。
- 承認/却下の根拠。
- 再レビューをトリガーする条件(例えば、新しいメジャーバージョン、ツールスキーマへの変更、依存関係に関するセキュリティ勧告)。
これは単なる官僚主義ではありません。Schneider のアーキテクチャガイドは、ほとんどのチームが答えられない直接的な質問を投げかけています。「ユーザーが承認した後、MCP サーバーのツール説明が変わった場合はどうなりますか? 誰かが気付くでしょうか?」デフォルト設定ではほとんどの場合、答えは「いいえ」です。バージョンピニングと決定ログは、その答えを変える方法です。
新しいリリースがなくても、四半期ごとにピニングされたサーバーを再レビューするようにカレンダーリマインダーを設定してください。コードが変わらなくても、それらの周りの脅威環境は変わるからです。
本番スタックで MCP サーバーをすでに実行しているチームの場合、既存のツーリングと並行して複数のサーバーを管理する運用上の考慮事項については、本番スタックのポストで別途カバーされています。
再利用可能なプレインストールチェックリスト：承認/却下の根拠
以下は完全なチェックリストをトリアージ順に示したものです。サーバーをインストールする前に適用してください。示されている例は参考値であり、実際の結果は異なります。
| # | チェック項目 | 例示された検出項目 | 判定 |
|---|---|---|---|
| 1 | 発行者の身元確認が可能 | 既知の組織、18ヶ月の実績 | 承認 |
| 2 | リポジトリ作成日とコミット頻度 | アクティブ、複数のコントリビューター | 承認 |
| 3 | バージョンピン留め、リリース署名 | GitHub上の署名済みタグ | 承認 |
| 4 | npm audit / pip-audit クリーン | 深刻度の高い検出項目ゼロ | 承認 |
| 5 | ツール説明と実装が一致 | メールツールはメール API のみを呼び出し | 承認 |
| 6 | 文書化されていないアウトバウンドネットワークコールなし | 文書化されていない分析ピング1件検出 | 却下 / 調査中 |
| 7 | フック と bin/ スクリプトをレビュー | フックなし | 承認 |
| 8 | サーバー側で入力検証を実施 | 厳密なスキーマ検証を確認 | 承認 |
| 9 | 認証情報スコープを最小化 | スコープ限定の読み取り専用キーを作成 | 承認 |
| 10 | 分離が適用されました | 制限されたサブプロセスで実行されます | 承認 |
| 11 | 決定がバージョンと日付とともに記録されました | ログに記録されました | 承認 |
| 12 | 再レビュー トリガーが定義されました | スキーマの変更時に自動実行されます | 承認 |
6行目がこの作業を行う理由です。ドキュメント化されていない分析 ping は本質的に悪意があるとは限りませんが、ドキュメント化されていない場合、説明されるまでドキュメント化されていないアウトバウンド呼び出しは却下の対象となります。パブリッシャーに問い合わせて明確な回答を得て、実際に送信されている内容をレビューした後、新しい決定を下します。これがプロセスです。
FAQ
ソースコードをレビューすれば、サーバーのインストールが安全であることが保証されますか?
いいえ。コードレビューはトリアージであり、認証ではありません。ドキュメント化されていないネットワーク呼び出し、認証情報ログ、悪意あるツール説明など、明らかな問題の発生確率を低減します。将来の更新で導入される脆弱性（バージョン固定とチェンジ時の再レビューが必要な理由）や、深刻なセキュリティ分析が必要な微妙なロジックの欠陥からは保護されません。
ツール ポイズニングとは何で、MCPとどのような関係がありますか?
ツール ポイズニングとは、攻撃者がツールの名前またはディスクリプション フィールドに悪意のある命令を埋め込むことを指します。MCP ツール スキーマはモデルのコンテキストに逐語的に挿入されるため、モデルはこれらの命令を正当な指令として解釈する可能性があります。インストール前にスキーマをレビューし、埋め込まれた命令フラグメントをチェックすることが、インストール前段階での主な軽減策です。
ローカル MCP サーバーとリモート MCP サーバーをレビューする方法は異なりますか?
ローカル サーバーは、マシン上で直接実行され、環境にアクセスできるため、機密データへのパスが短くなります。リモート サーバーはネットワーク攻撃面と中間者攻撃のリスクをもたらします。どちらも同じチェックリストが必要ですが、ローカル サーバーはファイルシステム アクセス スコープとソースコードの認証情報処理に特に注意が必要であり、リモート サーバーは検証済みの TLS、署名検証、および現在の MCP 仕様に準拠した OAuth 2.1 が必要です。
クローズド ソースまたはバイナリとして配布されている MCP サーバーをどのように処理しますか?
ソースを読むことができない場合、パブリッシャーの評判、暗号化署名検証、ランタイム制御（サンドボックス、ネットワーク ポリシー、スコープ付き認証情報）に完全に依存しています。これは実質的により高いリスク ポスチャーです。本番データまたは顧客情報に触れるものについては、既知のパブリッシャーからの検証可能な署名がないクローズド ソース バイナリはデフォルトで却下する必要があります。
SBOM とは何で、MCP サーバーに実際に必要ですか?
SBOM（ソフトウェア部品表）は、パッケージが含むすべての依存関係のマシン可読インベントリです。MCP サーバーの場合、トップレベル パッケージ自体がクリーンに見える場合でも、推移的な依存関係に公開された CVE があるかどうかを特定することができます。低リスクの個人用ツーリングの場合、オプションのオーバーヘッドです。機密データを扱う本番環境には、これはエクスポージャーを知ることと推測することの違いです。
このレビュー全体で最も鋭い注意事項は次のとおりです。レジストリで無害に見えるツール説明は、悪意のある実行可能コードと同じくらい効果的にエージェント動作を操作でき、ほとんどのクライアントは警告を表示しません。README ではなくスキーマを読んでください。