A6：MCP連携の判断基準と段階制
MCPは価値もリスクも最大の領域です。GitHub・Slack・Google Drive・社内API等と接続できる一方、社内コードが外部MCPに渡る、プロンプトインジェクションを受ける、退職者・委託先の接続管理が漏れる、といったデータ流出経路になり得ます。
| 審査観点 | 見るところ |
|---|---|
| 提供元 | ベンダー公式か、コミュニティ製か、出所不明か。第三者製はソースコードを確認できるもの以外は原則不可 |
| 認証方式 | OAuthベースでスコープを絞れるか。長期有効の静的トークンを要求するものは要注意 |
| データ行き先 | MCPサーバー自体がデータを保持・転送しないか。機密区分と整合するか |
| 権限の非対称性 | まず読み取り専用で始め、書き込み権限は必要性が立証されてから付与 |
| 監査可能性 | 利用状況をログで把握できるか |
| 注入耐性 | 外部コンテンツは「信頼できない入力」として扱い、埋め込まれた指示に従わない構成（ガードレール＋denyルール） |
- 段階制：初期PoCは原則禁止 → 必要最小限のみ許可 → 許可リスト（
allowedMcpServers）で承認制 → 全社展開は承認済みカタログ＋管理者配布構成 - 承認台帳は作った瞬間から陳腐化 —— ネットワーク側の可視化（未承認AI・MCP通信の検知）を組み合わせる
完璧な基準を作ってから始めるより、「公式MCP＋読み取り専用」から始めて基準を運用の中で育てる