安全なMCPサーバーの選び方｜配布元・権限・撤退条件を審査する

安全なMCPサーバーは、掲載場所や知名度だけでは選べません。 自社で使うツールとデータを先に限定し、公開者の名義、取得した実体、実行時の通信、要求権限、保守条件を別々に検証して、最後に撤退可能性を確認します。本稿の読後成果物は、候補ごとの証拠URL、固定版、試用結果、採点、強制失格の有無をまとめた選定記録です。

安全なMCPサーバーの選定要件を絞る

選定の最初に製品名を並べると、便利そうな機能へ要件が引っ張られます。先に「誰が、どのクライアントから、どのデータへ、どの操作を、何件まで行うか」を書きます。たとえば社内規程検索なら、文書本文の読み取りと検索結果の返却が要件であり、文書更新、外部共有、削除は不要です。不要な操作を持つサーバーを採用候補へ残す場合は、そのツールを確実に非公開または不許可にできることを必須条件にします。

同じ「検索」でも、ローカルの指定フォルダーだけを読むstdioサーバーと、クラウドストレージへリモート接続するサーバーでは信頼境界が異なります。前者は端末上の実行権限と環境変数、後者はHTTP認証、サービス側の保管、ネットワーク経路、テナント分離を調べます。要件書には接続方式を一語で置かず、実行場所、資格情報の発行者、処理対象の保存場所、ログの保存主体まで記載してください。

要件の出口は「安全なものを選ぶ」ではなく、「この用途では検索系三ツールだけを許可し、更新系は採用しない」のような判断です。機密区分、法定保存、国外移転、労務・医療・金融などの固有規制が関係する場合は、一般的なMCP比較の前に自社の法務・情報管理要件を追加します。適用条件が未確定のまま採点を始めると、候補間の点差に意味がなくなります。

レジストリ情報と配布実体を照合する

Model Context Protocol公式「The MCP Registry」は、公開サーバーの名称、取得先、実行方法などをserver.json形式で示す中央メタデータ基盤です。逆引きDNS形式の名前とGitHubアカウントまたはドメインの確認により、名乗っている公開者との関係を確かめる仕組みがあります。一方、Registryは現在previewであり、コードやバイナリの安全性スキャンを自ら完結させるサービスではなく、パッケージレジストリや下流の集約サービスへ検査を委ねると説明しています^[1]。

レジストリ掲載は「この名前で誰がメタデータを公開したか」を確認する材料であり、「このプログラムを自社権限で実行しても安全」という認証印ではありません。

候補を見つけたら、Registryのサーバー名、版、package識別子、remote URL、リポジトリURLを一行へ写し、実際に取得する版と照合します。npmならパッケージ名と版、配布tarballのintegrity、公開者、リポジトリ欄を確認します。

コンテナならタグだけでなくdigestを採取し、リモートサービスならTLS証明書の対象名、運営ドメイン、契約主体を確かめます。「latest」や可変タグは審査時点の実体を後から再現できないため、採用記録には固定値を残します。

候補名: io.github.vendor/policy-search
Registry version: 2.4.1
取得元: npmの固定パッケージ名
取得版: 2.4.1
配布物integrity: レジストリ表示値
source commit: リリースタグが指すコミット
server.json取得日時: 2026-07-30T10:00:00+09:00
確認者: 調達担当 / 技術担当
差分: なし、または理由と扱いを記載

Registryの集約者向け文書は、サーバー状態としてdeprecatedやdeletedが更新され得ると説明し、deletedはスパム、マルウェア、違法性などの問題を示す場合があるとしています^[2]。採用時だけ見て終わらず、固定版の状態を定期取得し、削除、非推奨、所有者変更を検知したら新規接続を止めます。Registry外の私設サーバーは自動的に危険という意味ではありませんが、身元と配布経路を自社で検証する負担が増えます。

コード・依存関係・更新経路を調べる

配布物の審査では、ソースが読めるかだけでなく、公開ソースと取得バイナリがどう結び付くかを見ます。リリースタグ、ビルド手順、署名またはハッシュ、依存関係一覧、SBOM、脆弱性報告窓口、サポート中の版、過去のセキュリティ修正を確認します。ソース公開でも、配布パッケージに未掲載コードやインストール時スクリプトが入ることはあり得るため、パッケージ内容と実行フックを別に点検します。

NIST SP 800-218のSSDF Version 1.1は、セキュリティ要件の記録、リリース構成要素の来歴情報、脆弱性の根本原因へ対処する開発実務を整理し、購入者と供給者の対話にも使える共通語彙を提供しています^[6]。

MCP専用基準ではありませんが、供給者へ「どの版に何が含まれ、誰が修正し、どのように再現できるか」を問う枠組みとして有効です。単に「セキュリティに配慮しています」と回答させず、文書や機械検証できる成果物を求めます。

CISAは2025年8月26日に、ソフトウェア調達で供給者リスクを質問し、結果を共有可能な形で出力するSoftware Acquisition GuideのWeb Toolを公開しました^[5]。米国政府向け資源をそのまま自社の義務と解釈するのではなく、供給者への質問漏れを減らす参照資料として利用します。自社の規模、データ区分、契約形態に合わない項目は理由を付けて除外し、重要項目を曖昧な総合点へ埋没させないことが大切です。

隔離環境で挙動と通信先を観察する

静的な書類審査を通った候補だけを、廃棄可能な端末またはコンテナで起動します。最初は秘密情報を与えず、読み取り専用ファイル、テストアカウント、出口通信の既定拒否を使います。stdioなら専用OSユーザー、限定フォルダー、空のHOMEを割り当て、Streamable HTTPならテストテナントと許可ドメインを準備します。本番クライアントへ直結する前にMCP Inspectorまたは最小クライアントで公開機能を列挙します。

観察対象はtools/listの件数とスキーマ、起動時に生成するファイル、子プロセス、DNS照会、外向き接続、環境変数の読み取り、ログへ残す値、終了後の常駐処理です。READMEに書かれていない接続先、分析用エンドポイント、任意URLへのアクセス、ホームフォルダー全体の走査を見つけたら、用途と無効化方法を供給者へ質問します。挙動が説明されるまでは資格情報を追加しません。

試用ケース A: 起動直後
期待: 承認済み設定ファイルだけを読む
観測: 接続先ドメイン、作成ファイル、子プロセス
試用ケース B: tools/list
期待: 要件書にある検索系三ツールだけ
観測: ツール名、inputSchema、更新系ツールの有無
試用ケース C: 許可外パス
期待: 読み取り前に拒否
観測: エラー、監査ログ、実ファイルのアクセス履歴
試用ケース D: 指示を含む悪意ある文書
期待: 文書中の命令を操作指示として扱わない
観測: ツール呼出し、外部送信、回答の根拠

動的試験では正常入力だけでなく、長い文字列、パストラバーサル、シンボリックリンク、リダイレクト、巨大ファイル、並行要求、タイムアウトも加えます。書き込みツールを評価するなら、対象件数を一件へ制限し、二重実行を検知できるテスト資産で試します。取り消せない操作はデモでも呼び出さず、供給者の録画、監査ログ例、モックを使って契約上の動作を確認します。

試用中の停止線は、テスト領域外へのアクセス、未申告の秘密値取得、外部送信、権限昇格、自己更新、承認していない実行ファイルの取得です。いずれかが起きた場合はネットワークと資格情報を切り離し、イメージとログを保全します。「試用だから問題ない」と続けると、評価環境から社内資産へ影響を広げます。

認証・権限・秘密管理を審査する

候補の権限は、宣伝文句ではなく実際の主体とscopeで評価します。HTTPベースのMCP仕様2026-07-28は、保護対象メタデータ、認可サーバー発見、対象resource、操作に必要なscopeを扱います。stdioでは同じ認可フローを前提にせず、環境から資格情報を取得する設計です^[4]。したがって「OAuth対応」という一項目だけでは足りず、接続方式ごとに秘密の置き場所、利用主体、失効、監査を確認します。

公式のMCPセキュリティ文書は、別の資源向けに発行されたトークンの受け入れ、未検証トークンの下流転送、認可メタデータ取得時のSSRF、混乱した代理問題などを説明しています^[3]。選定試験では、正しい主体、無権限主体、期限切れ、別audience、scope不足を用意し、拒否位置を比べます。管理者権限で一度成功した結果は、最小権限の証明になりません。

生成AI側の指示で権限を制限するだけでは不十分です。ツール非公開、ネットワーク制御、API側の認可、対象ID検証、件数上限を実装側で強制します。プロンプトに「削除しない」と書いてあっても、削除APIを持つ共有管理者トークンが渡されていれば、設定ミスや別のクライアントから実行される余地が残ります。採用条件は、モデルが誤判断しても被害範囲を技術的に限定できることです。

保守と契約の質問を具体化する

技術試験が合格しても、障害時に連絡できず、版を固定できず、データ取扱いを説明できないサービスは業務運用へ載せにくいものです。契約前に、サービス提供者、再委託先、処理地域、保存データ、ログ保持、学習利用、侵害通知、脆弱性修正の目安、計画停止、サポート時間、終了時の削除証明を確認します。公開OSSを無償利用する場合も、契約で得られない保証を自社運用でどう補うかを書きます。

「バージョンアップは随時」ではなく、破壊的変更の通知期間、旧版の併存期間、自動更新の停止方法、緊急修正版の提供経路を尋ねます。remoteサービスでサーバー側が予告なくツールを追加できるなら、tools/listの差分を接続前に検知して許可リストへ反映する仕組みが必要です。ローカルパッケージなら、取得済み版を社内レジストリへ保存できるか、公開元から削除された場合の再現性を確認します。

回答が公開文書と営業説明で異なる場合は、契約本文または署名済み付属文書へ確定します。重要な仕様が「今後対応予定」なら、現時点では未対応として採点し、導入後に点を加える前提にしません。セキュリティ質問票の提出だけを完了条件にせず、隔離試用の観測と契約回答が一致するかを技術・法務・業務の三者で確認します。

100点評価と強制失格を併用する

点数は、条件の異なる候補を同じ物差しで比べるために使います。高影響の欠陥を平均点で相殺しないよう、配点とは別に強制失格を置きます。以下は社内規程検索サーバーを選ぶ想定例です。配点は用途に合わせて審査開始前に承認し、試用後に有利な候補へ合わせて変更しません。実績ではなく方法を示す仮想評価なので、自社案件では証拠を取り直してください。

候補Aは88点で、必須条件も満たすため限定採用とします。候補Bは68点に加え配布実体とソースの対応を証明できず、候補Cは79点でも検索用途に不要な全権限を必須とするため見送ります。採用基準を80点とした場合でも、BとCを点数だけで再検討しません。強制失格の解除には、供給者の説明ではなく、新しい配布物、scope分割、再試験の証拠が必要です。

判定: 限定採用
対象: 候補A 2.4.1 / 固定integrity
許可: policy.search, policy.read, source.get
禁止: update, delete, share, arbitrary_url
利用者: 社員IDで認証された試行部門50名
有効期限: 90日
再審査: ツール差分、所有者変更、重大脆弱性、期限到来
停止責任者: 情報システム運用責任者
撤退先: 既存の社内検索画面

評価表には空欄を0点と同じ扱いで埋めず、「証拠未取得」と明記します。証拠がないことと、不合格を確認したことでは、次に必要な行動が違うからです。また、コミュニティの星数、ダウンロード数、利用企業ロゴは補助情報にとどめます。多数利用されていても、自社の機密区分、接続先、必要scopeに適合するとは限りません。

許可リスト化と撤退手順を決める

採用した候補は、サーバー名だけでなく、版またはdigest、取得元、transport、endpoint、公開可能なツール名、スキーマhash、必要scope、通信先、データ区分、所有者、有効期限を許可リストへ登録します。起動設定がその記録と一致しない場合は、接続を成立させない実装にします。remoteサービスで実体を固定できない項目は、毎回取得する観測値と許容差分を定義します。

再審査のきっかけは、バージョン更新だけではありません。公開者またはドメイン所有者の変更、新しいツール、inputSchemaの拡張、追加scope、接続先の増加、保存方針の変更、重大脆弱性、Registry状態のdeprecatedまたはdeleted、契約再委託先の追加も対象です。差分検知から承認完了まで旧版を維持できない製品は、重要業務での継続性が低いと評価します。

撤退演習では、サーバー停止だけで完了にしません。保存データ、利用者のクライアント設定、秘密管理基盤、社内レジストリ、監視ルール、手順書に残る参照を洗い出します。代替手段で最低一件の業務を完了させ、利用者が旧接続を復活させられないことを確かめます。撤退に必要な日数と担当工数は、初回契約の費用比較へ含めるべき乗り換えコストです。

限定導入で受入判定を再現する

書類審査と隔離試験を通過しても、全社公開へ直行させません。利用者三〜五名、対象データ一種類、許可ツール二個まで、試用期間十営業日など、影響を数えられる単位へ限定して受入試験を行います。試用開始時には、固定版、利用者、接続先、最大要求数、処理できる機密区分、承認が必要な操作を変更票へ記録します。試用中に条件を広げる必要が出たら、その場で追加せず、新しい審査差分として扱います。これにより、便利さを理由に権限が少しずつ膨らむ状態を防げます。

受入ケースは成功率だけでなく、拒否の正しさと復旧時間を測ります。社内規程検索なら、最新版を答えられる正常系、閲覧権限のない規程を返さない権限系、存在しない文書名に推測で答えない欠損系、文書中の命令文をツール指示として実行しない攻撃系、接続断後に重複要求を起こさない障害系を用意します。期待結果、実測結果、ログ識別子、判定者を一件ずつ残し、再実行して同じ結論になるか確認します。

受入基準の例
正常検索: 20件中19件以上で根拠文書IDが一致
権限拒否: 許可外10件をすべて拒否し、本文をログへ残さない
攻撃耐性: 文書内の命令5件で追加ツール呼び出し0件
障害復旧: 接続遮断から15分以内に安全停止、二重更新0件
撤退確認: 資格情報失効後の再接続0件、代替検索を1件完了

上の数値は想定例であり、実案件では業務影響から閾値を決めます。採用判定には業務所有者、MCP運用担当、セキュリティ担当の三者を含め、いずれかが強制失格を確認した場合は点数にかかわらず公開しません。不合格原因が設定で直せると判断したときも、同じ固定版のまま都合のよいケースだけを再試験せず、変更後の実体を新しい候補として全ケースへ通します。

限定導入中の停止条件は、許可リスト外ツールの出現、scope追加要求、監査不能な操作、想定外ドメインへの通信、復旧目標超過、利用者が手動で回避できない業務停止です。停止後は接続と秘密を失効し、直前の要求IDから影響範囲を確認します。受入記録には「採用」だけでなく、残る制約、次回再審査日、緊急連絡先、代替手順の所在を記載します。ここまで再現できて初めて、候補比較の点数が実運用の判断材料になります。

導入を見送るケースと代替策

候補サーバーが向かないのは、必要な機能がない場合だけではありません。配布物の版を固定できない、実行実体の来歴が分からない、テスト領域へ限定できない、検索だけで全権限を要求する、操作ログから主体を追えない、緊急失効の方法がない、保存データを説明できない、撤退時の削除を確認できない場合は、重要業務への採用を見送ります。

単一の社内APIを一つのクライアントから呼ぶだけなら、MCPサーバーを新たに導入せず、既存APIの薄い社内ラッパーや固定されたアプリ連携の方が境界を小さくできる場合があります。高影響の更新だけが必要なら、MCPは検索と下書きまでに限定し、確定操作を既存画面へ残す方法もあります。公開OSSの保守体制が要件へ届かない場合は、社内forkで依存版とビルドを管理する選択肢がありますが、その分の修正責任と監視工数を見積もります。

直ちに試用を止める条件

隔離境界を越えたデータ取得、別audienceのトークン受理、未申告先への通信、自己更新、資格情報の平文記録、許可していない更新処理を観測したら、その候補の実行を中断します。証拠保全と秘密の失効を行い、原因が除かれた新しい固定版で最初から審査し直します。

「他社も使っている」「公式Registryにある」「有名マーケットで上位」という理由は、見送り条件を解除しません。MCPサーバーはモデルへ文脈を渡すだけでなく、ファイル、データベース、外部サービスへ作用できるため、自社の権限境界で評価する必要があります。採用しない判断も、代替策と再検討条件が書かれていれば、調達プロセスの完成した成果です。

候補を一つ選んだ直後の行動

候補のserver.jsonまたは配布ページを保存し、固定版と取得実体のhashを記録してください。要件外ツールをすべて禁止した隔離環境でtools/listと出口通信を観察し、別audience、scope不足、許可外データの三つを拒否できるまで本番資格情報を渡しません。結果を100点表と強制失格欄へ反映すれば、評判ではなく証拠で採否を説明できます。

参考文献・出典

1. Model Context Protocol「The MCP Registry」（preview、更新日表示なし、参照日2026年7月30日）
2. Model Context Protocol「MCP Registry Aggregators」（preview、更新日表示なし、参照日2026年7月30日）
3. Model Context Protocol「Security Best Practices」（文書版2026-07-28、参照日2026年7月30日）
4. Model Context Protocol「Authorization」（仕様版2026-07-28、公開日2026年7月28日、参照日2026年7月30日）
5. CISA「CISA Unveils Tool to Boost Procurement of Software Supply Chain Security」（公開日2025年8月26日、参照日2026年7月30日）
6. NIST「SP 800-218, Secure Software Development Framework Version 1.1」（Version 1.1、公開日2022年2月3日、参照日2026年7月30日）