8月27日、Stein Ove Helsetが「How to Vet a Third-Party MCP Server for Production」と題した記事を公開した。この記事では、サードパーティ製MCPサーバーを本番環境に導入する前に何を確認すべきかの実践的なチェック手順について詳しく紹介されている。
MCP（Model Context Protocol）は、Anthropicが提唱したオープン規格で、AIエージェントが外部ツールやサービスと標準化された方法で連携するためのプロトコルだ（公式仕様）。MCPサーバーはその実装の一形態であり、GitHubからリポジトリを見つけて設定を貼り付けるだけで数分で動かせる手軽さが魅力だが、その手軽さがリスクの温床にもなる。MCPサーバーは自分の認証情報を持って動作するコードであり、AIは必要と判断すれば自律的にそれを呼び出す。ローカルでの検証と、チーム全体に展開する本番運用では、求められる審査レベルが根本的に異なる。
なお、AIエージェントを介したプロンプトインジェクションや過剰な権限付与のリスクについては、OWASP LLM Top 10も参考になる。
まず確認すべきは「誰が作ったか」と「今も生きているか」
著者がまず見るのはGitHubリポジトリだ。最終コミットがいつか、オープンなIssueがどれだけあるか。最終コミットが1年以上前でIssueが20件超なら、メンテナンスが実質終了しているサインとみてよい。ベンダー公式かどうかも確認する。どちらでも問題ないケースはあるが、把握しておくべき情報だ。
ツールの中身を読む
多くの人がスキップするが、著者が「最も重要なステップ」と位置付けるのがここだ。コードを開き、サーバーが何のツールを公開しているかを確認する。
ポイントは読み取り専用か、書き込み・削除・メール送信なども可能かを区別することだ。カレンダーの読み取りツールは問題なくても、カレンダーのイベント削除ツールが含まれていれば話は別になる。
コードのどこを読むか迷うなら、ツール定義を検索するのが早い。
- Python：
@server.tool()デコレータ - TypeScript：
server.tool(...)の呼び出しやListToolsRequestSchemaハンドラ
特に見るべきはdocstringだ。AIはこの説明文を読んでツールを呼ぶタイミングを判断する。説明に「get user」と書いてあるのに実装が DELETE リクエストを投げていた場合、それは意図的な誤魔化しの可能性がある。また、シェルコマンドの実行や任意ファイルの読み取りを行うツールが含まれていないかも確認する。ローカルなら許容範囲でも、チームに展開するなら別の判断が必要だ。
認証情報の扱いを確認する
環境変数でトークンやAPIキーを受け取る実装は標準的で問題ない。確認すべきはその認証情報が本来接続すべきサービス以外に送信されていないかだ。
grep コマンドで fetch(、requests.、httpx. を検索し、接続先ホスト名を確認する。見慣れないホストへのリクエストがあれば赤信号だ。
OAuthに対応している場合は、リダイレクト先と要求スコープも確認する。説明には「読み取り専用」と書いてあるのにOAuthがフルアクセスを要求している場合は、信頼しない方がよい。
依存関係をピン留めする
npx や uvx で起動のたびにインターネットから取得するような構成は、実行のたびに異なるバージョンが走る可能性がある。本番では必ずバージョンを固定すること。徹底するならGitHubリポジトリをフォークして自前でホストする方法もある。
package-lock.json や uv.lock に対して npm audit や pip-audit を走らせるのも有効だ。数分で済み、意外な脆弱性が見つかることがある。
本番前にサンドボックスで動かす
ボリュームをマウントせず、ネットワークアクセスのみ許可したDockerコンテナでサーバーを動かし、1〜2日AIに使わせる。その後ログを確認して、どのツールがどの頻度で呼ばれているかを把握する。エラーハンドリングが適切で、ログが明確かどうかも重要なシグナルだ。
具体的には、以下のようなコマンドでホストファイルシステムへのアクセスを遮断しつつ起動する方法が考えられる。
# ボリュームマウントなし・ネットワークのみ許可した最小構成の例
docker run --rm \
--network=bridge \
--read-only \
-e API_KEY=your_token \
your-mcp-server-image
この状態でAIクライアントから実際にツールを呼び出し、コンテナのログ出力を1〜2日観察する。想定外のエンドポイントへのリクエストや、呼ばれるはずのないツールの起動が記録されていれば、本番展開を見送る判断材料になる。
5つのチェックポイントと優先順位の考え方
著者が本番導入前に実施する確認事項は以下の5点だ。まとめとして列挙するだけでなく、どれを最初に確認すべきかの優先順位も整理しておく。
- ①誰が作ったか、アクティブにメンテナンスされているか（スクリーニングの第一関門。ここで落ちれば以降の確認は不要）
- ②どのツールを公開しているか、そのツールにどんな権限があるか（著者が「最重要」と位置付けるステップ。必ずコードを読む）
- ③認証情報の扱い方（外部送信の有無を
grepで確認。OAuthスコープの過剰要求も要注意） - ④バージョンと依存関係のピン留め（
npm audit/pip-auditは数分で完了する。後回しにしない） - ⑤本番前のサンドボックスでのテスト実行（Dockerによる隔離環境で1〜2日観察し、ログで挙動を確認する）
①②はコードを読む作業が中心で判断が速い。③〜⑤はツールを使った機械的な確認で補完する、という順序で進めると効率的だ。
審査はあくまで「最初の入口」の判断だ。本番稼働後にMCPサーバーの依存関係が更新されたり、接続するAIクライアントやユーザーが増えたりするにつれて、個別のレビューだけでは追いきれなくなる。記事ではその継続的なガバナンスの問題に対し、MCPゲートウェイを含む集中管理型のAIコントロールプレーンという考え方を紹介しているが、それは別途検討すべき課題として整理されている。
詳細はHow to Vet a Third-Party MCP Server for Productionを参照していただきたい。
