- 公開日
未承認のMCPサーバーやプラグインの追加を防ぐには、申請書を用意するだけでなく、承認した接続先と利用条件を管理設定へ反映し、利用者がその範囲を広げられないようにします。例外利用にも期限と終了処理を設けます。「接続できた」「本人が同意した」という事実は、会社がその用途を承認した証拠にはなりません。
MCP（Model Context Protocol）は、AIアプリケーションと外部の機能・情報源をつなぐための仕組みです。プラグインも接続や機能拡張を担いますが、管理方法は製品ごとに異なります。ここでは社内AIの接続追加を管理する手順を扱い、個々のサーバーの安全性評価や配布物の検査は、申請の審査に必要な入力として位置付けます。
接続先の名前ではなく、承認する組み合わせを決める
「文書検索サーバーを承認」とだけ記録すると、誰が、どの文書へ、何のために接続してよいかが残りません。同名の接続先でも、本番と検証環境、検索と書き込み、一般文書と顧客資料では判断が変わります。申請は少なくとも、利用者の範囲、業務目的、接続先の識別情報、許可する操作、渡すデータ、利用期間を一組にします。
以下は架空の営業部が、社内AIから製品マニュアルを検索する接続を申請した例です。実在製品の導入実績ではありません。説明を通じて、利用者と検索目的は固定し、登録状態や期限が変わった場合の処理を比べます。
| 申請で確定する項目 | この例の承認内容 |
|---|---|
| 利用主体と目的 | 営業部の指定グループが、製品仕様の回答案を作る |
| 接続先 | 管理台帳に識別情報を登録した社内文書検索サービス |
| 対象と操作 | 公開用マニュアル領域の検索・閲覧だけ |
| データ経路 | AIクライアントから検索サービスへ検索語を渡し、取得した文書部分を承認済みAI処理環境へ返す |
| 除外する範囲 | 顧客資料領域、文書の更新、別サービスへの送信 |
| 責任者と期間 | 業務責任者と設定管理者を記録し、承認に見直し日を設ける |
AIの処理先が社外サービスなら、その処理先もデータの受領者になります。検索サービスが社内にあるという理由だけで、文書の抜粋を外部AIへ渡せるとは判断しません。検索語、返却文書、認証に使う情報がそれぞれどこへ届くかを、構成図と実際の設定に照らして確認します。経路が確認できない部分は「未確認」とし、そのデータを使う接続は保留します。
申請から設定まで、誰が何を渡すかを固定する
申請者は業務上の必要性と希望範囲を提出し、データの管理者は対象資料の利用条件を確認します。審査担当者は提供元や要求権限、契約・保持条件などを確認し、承認者が許可範囲を決めます。設定管理者は承認記録に基づいて接続を配布します。一人が複数の役割を担う小規模組織でも、申請内容、判断、設定変更の記録は区別して残せます。
受け渡すのは「承認済み」というラベルだけではありません。承認記録の識別子と版、対象グループ、接続先、操作範囲、期限、適用先を渡します。設定管理者が利便性のために全社員へ広げたり、検索だけの申請に更新権限を付けたりしたら、承認との不一致です。足りない機能は申請へ戻し、設定作業の判断で追加しない運用にします。
利用者には、使える用途、入力できない情報、問題の報告先を伝えます。接続追加の承認は、その後に行うすべての送信や更新を一括承認するものではありません。接続先で操作できる権限と、個々の業務操作の承認が必要な範囲は、別々に維持します。
許可リストを、利用者が変更できない設定につなぐ
許可リストは、使用を認める接続先を指定した一覧です。社内ページに一覧を掲載していても、利用者が任意の接続先を追加できるなら、技術的な制限は実装されていません。接続の追加・起動を制限する管理機能と、接続先でのデータ・操作権限を組み合わせます。
製品の実装例として、2026年10月12日に確認したVS Codeの企業向けポリシー資料（ページの更新日は2026年10月7日）では、管理ポリシーの値が既定・ユーザー・ワークスペースのどの階層の設定よりも優先します。MCPサーバーの許可リスト（ChatAllowedMcpServers）を設定すると一致するサーバーだけを導入・起動でき、拒否リスト（ChatDeniedMcpServers）の規則は許可リストより常に優先すると説明されています。ただし、これは当該製品の確認時点の仕様です。別のAIアプリケーションや古いクライアントで同じ制御が働くと推測せず、配備する版と実効設定を確認します。
また、利用者に表示される信頼確認を、組織の導入審査と同一視しないようにします。VS CodeのMCP管理資料によると、ワークスペースに置かれたMCP設定はWorkspace Trustを引き継ぎ、利用者がそのワークスペースを信頼すると、個別の確認画面なしにサーバーが起動し得ます。同じ資料は、ローカルMCPサーバーが端末上で任意のコードを実行し得ると注意しています。利用者がリポジトリを信頼した操作は、会社がその接続を審査した記録にはなりません。
この例では、中央管理で検索サービスだけを許可し、利用者による接続追加の変更権限を制限します。さらに検索サービス側でも、指定グループと公開用マニュアル領域にアクセスを限定します。設定を配ったという記録と、端末で設定が有効になったことは分けて確認し、対象外のクライアントや未適用端末が残っていれば、その範囲を管理台帳へ記します。
登録済み、未審査、期限切れで処理を分ける
次の表は、実害のない検証環境で確認する期待動作です。試験には架空データを使い、実際の顧客資料や有効な認証情報を投入しません。本稿で試験を実施した結果ではありません。
| 条件 | 期待する処理 | 確認する記録と次の対応 |
|---|---|---|
| 登録済みの接続先を、承認グループが期限内に追加する | 承認した検索機能だけを利用可能にする | 接続識別情報、設定版、利用者、検索対象が承認記録と一致するか確認 |
| 同じ利用者が未審査の別接続先を追加する | 追加または起動を拒否する | 拒否記録を確認し、必要な用途があるなら申請窓口へ戻す |
| 承認範囲を超える文書更新を要求する | 検索接続の承認を根拠に更新を認めない | 接続先の操作権限も照合し、必要なら変更申請へ戻す |
| 例外利用の期限が過ぎている | 新たな利用を停止する | 実効設定と既存セッションの状態を確認して終了処理を進める |
| 管理設定が端末へ届いたか確認できない | 当該端末での利用可否を確定しない | 接続を許可する前に設定管理者が適用状況を調べる |
拒否メッセージの表示だけでは、接続が本当に止まったとは限りません。クライアントの設定、起動記録、サーバー側のアクセス記録を必要な範囲で照合します。一方、未審査の追加が拒否されたために承認済みの文書検索まで止まるなら、制限範囲が広すぎないかを調べます。拒否の成否と、正当な業務の継続を別の観点で点検します。
例外の期限は、通知と終了処理を一緒に設計する
短期検証の例外では、通常の審査で何が満たせず、代わりに何を制限するかを記録します。例えば架空の検証環境だけで、指定した担当者がダミー文書を検索する条件です。「試用だから自由に使える」とはせず、本番データの投入や別アカウントでの利用を範囲外にします。
期限は日付だけでなく時刻とタイムゾーンまで明確にし、終了責任者、期限前の確認、失効時の処理を定め、延長を判断する人も指定します。製品に自動失効機能があるかは実仕様で確認します。機能がない場合は管理者の削除作業を予定し、完了まで制限を維持する別の手段を検討します。台帳に期限を書いたことだけで、自動的にアクセスが失効すると説明してはいけません。
既存セッションや発行済みの資格情報がいつ失効するかも確認対象です。接続の一覧から項目を消しても、別のクライアントに残る設定や継続中のアクセスまで止まるとは限りません。利用停止、権限の失効、設定の削除を対象サービスの手順に従って確認し、結果が不明なものは終了済みにしません。
最後に、例外の延長は期限を書き換えるだけで済ませず、継続理由と変更した条件を再確認します。審査や設定管理には手間がかかるため、承認済み接続の再利用条件と申請に必要な資料を明確にすると、同じ確認のやり直しを減らせます。それでも、接続先、用途、権限、送信データが変わったときは、以前の承認をそのまま流用せず見直します。
MCPのツール説明と実行権限を分けて確認する方法は「MCPのツール説明はどこまで信頼できる？ 機能の説明と実行権限を分ける」、接続先に与える権限を絞る確認は「API・外部ツール権限の最小化チェックリスト」で解説しています。
MCPサーバーを導入前に評価する方法は「MCPサーバーを信頼境界として評価する」で解説しています。
