企業のMCPガバナンス設計｜申請・許可リスト・監査を運用する

MCPの企業利用は、サーバーを登録するだけでは統制できません。誰が、どのクライアントから、どの固定版へ接続し、どのデータを読み、どの操作まで許されるかを申請単位で結び付けます。その記録を実行時の許可リスト、認証、ログ、停止処理へ反映すると、紙の規程と実際の接続を一致させられます。本稿では、部門内の試行を全社運用へ移す責任者が使える統制台帳と受入判定を完成させます。

企業のMCPガバナンスは接続単位で棚卸しする

MCPガバナンスの管理単位は、製品名でも部門名でもなく「クライアント、サーバー実体、利用主体、データ、許可ツール」の組み合わせです。同じMCPサーバーでも、個人のデスクトップから公開情報を検索する接続と、共有サービスアカウントで顧客台帳を更新する接続では影響が異なります。申請番号を一つ発行し、この五要素に所有者、有効期限、環境、固定版を加えて一行として登録します。

MCPの2026-07-28 Core Architectureでは、各要求のメタデータにプロトコル版とクライアント能力を伝える方式が示されています^[1]。企業台帳では、宣伝上の「MCP対応」ではなく、実際に許可するprotocolVersion、transport、公開ツール名、inputSchemaのhashを記録します。互換版を無条件に広げると、未審査の機能が接続後に現れるため、観測した値と許可値を分離します。

棚卸しでは、従業員が個別に追加したデスクトップ設定、CIで起動するstdioサーバー、ブラウザー拡張、開発用トンネルも含めます。DNSやプロキシの通信記録、端末管理の構成、秘密管理基盤の利用先を照合すると、申請されていない接続を見つけやすくなります。所有者が不明な接続は暫定許可にせず、資格情報を止めて利用目的を確認することが初期統制です。

操作とデータからリスク区分を決める

区分はAIの種類ではなく、操作の可逆性、対象データ、影響範囲、実行主体、外部送信の有無から決めます。本稿では「閲覧限定」「限定更新」「高影響操作」の三段階を例にします。閲覧限定でも人事・医療・認証情報を扱えば上位審査が必要です。一方、更新ツールでも隔離された検証データ一件へ限定され、即時復元できれば試験時の影響を抑えられます。

経済産業省のAI事業者ガイドライン第1.2版は、2026年3月31日に取りまとめられ、同年4月1日に掲載ページが更新されています^[4]。これはMCP専用規則ではありませんが、リスクベースで役割、透明性、データ、セキュリティを整理する際の現行公的資料として参照できます。NIST AI RMF 1.0も任意利用の枠組みであり、2026年7月30日時点では改訂作業中です^[5]。版を明記して採用し、自社規程へ転記した日と判断者を残します。

審査表には区分名だけでなく、上位へ繰り上げる条件を書きます。たとえば一件の下書き作成は限定更新でも、宛先を自動取得して外部送信するなら高影響操作です。最大件数を10から1000へ変える、機密区分を社内限定から要配慮情報へ広げる、個人主体を共有主体へ変える場合も再区分します。境界条件を機械設定へ変換できなければ、区分は会議資料に残るだけで本番挙動を制御しません。

申請と承認を証拠でつなぐ

利用部門の申請には、解決したい業務、現在の代替手段、処理対象、必要ツール、期待件数、利用者、実行頻度、終了条件を記載します。「生産性向上」だけでは許可範囲を導けません。たとえば「営業会議前に、指定された20社の公開IR資料を読み、出典URL付き要約を下書きする」と書けば、社内CRM更新やメール送信は申請外だと判定できます。

証拠は申請時、技術試験時、承認時、本番開始時の四つに分けます。申請者は目的とデータ、MCP運用担当は実体と通信、セキュリティ担当は権限と脅威、データ所有者は処理条件、法務・調達は契約と再委託、業務責任者は残余リスクと代替手段を担当します。一人が全欄へ丸を付ける方式ではなく、判断根拠を作れる役割へ署名欄を割り当てます。

1. 受付：申請番号を発行し、目的、主体、データ、希望期間が空欄なら審査へ進めません。
2. 実体確認：版、digest、公開者、ツール一覧、通信先、依存先を取得し、試験対象を固定します。
3. 脅威確認：過剰権限、トークン流用、指示注入、データ持ち出し、二重実行、供給網変更をケース化します。
4. 隔離試験：本番秘密を使わず、正常・拒否・障害・復旧を同一実体で実行し、ログを申請へ添付します。
5. 条件付き承認：公開ツール、利用者、データ、件数、有効期限、停止権限、再審査日を確定します。
6. 本番照合：配備値が承認値と一致した場合のみ許可リストへ反映し、代表ケースを再実行します。

承認会議では、未解決事項を「運用で対応」と一括しません。誰が、どの画面またはログを、何時間以内に確認し、逸脱時に何を止めるかへ分解します。契約でしか担保できない削除証明と、設定で強制できる通信制限は別の証拠です。有効期限を過ぎた申請は自動失効させ、継続利用は新しい観測結果を添えて更新します。

申請番号: MCP-2026-0042
目的: 公開IR資料20社分の出典付き要約を会議前に作る
主体: 営業企画グループの個人ID
許可ツール: search_public_ir, fetch_public_pdf
禁止操作: 社内CRM参照、メール送信、ファイル更新
固定実体: server 2.4.1 / digest sha256:記録値
期限: 2026-09-30
停止権限: SOC当番、MCP運用責任者
代替手段: 承認済み検索画面から手作業で取得

許可リストを実行時に強制する

許可リストは表計算の一覧ではなく、接続ゲートが読み取れる構造化設定へします。サーバー名が一致しても、endpoint、証明書、digest、protocolVersion、ツール集合、schema hash、scope、通信先のどれかが変われば不一致として遮断します。remoteサービスの内部実体を固定できない場合は、供給者の版表示、TLS証明書、公開スキーマ、契約変更通知を組み合わせ、観測できない項目を残余リスクとして承認します。

{
  "approval_id": "MCP-2026-0042",
  "server": "public-ir-reader",
  "transport": "streamable-http",
  "endpoint": "https://approved.example.invalid/mcp",
  "protocol_versions": ["2026-07-28"],
  "tools": {
    "search_public_ir": "schema-hash-a1",
    "fetch_public_pdf": "schema-hash-b7"
  },
  "scopes": ["ir.read"],
  "data_classes": ["public"],
  "max_calls_per_request": 25,
  "egress_hosts": ["approved.example.invalid"],
  "expires_at": "2026-09-30T14:59:59Z"
}

この例のURLは構造説明用であり、記事のcanonicalではありません。実装では署名済み設定、変更履歴、環境別の配布経路を用意し、利用者がローカル設定で制限を上書きできないようにします。tools/listの結果に未許可ツールが一つでもあれば、そのツールだけを隠すのか、接続全体を拒否するのかを規程で決めます。高影響サーバーでは接続全体の拒否が、意図しない能力追加を見逃しにくい設計です。

許可リストを更新できる主体は、利用申請者と分離します。変更はコードレビューまたは二者承認を経て、承認番号と設定commitを相互参照します。配布後には各ゲートの設定hashを集約し、中央台帳と食い違う端末を隔離します。失効日時、緊急deny、旧版の猶予期間を同じ仕組みで扱えば、削除依頼をメールで回すより停止が速くなります。

許可値が取れない場合の扱い

ツールschema、通信先、利用scope、保存場所のいずれかを確認できない接続は「制限なし」と解釈せず、審査未完了として本番へ通しません。業務上どうしても必要なら、隔離ブラウザー、使い捨て資格情報、公開データ、手動転記へ縮小し、例外期限と廃止計画を責任者が承認します。

認証・権限・秘密を主体別に分ける

HTTPベースのMCP認可仕様2026-07-28は、保護対象メタデータ、認可サーバーの発見、resource指定、scope、audienceを扱います。同仕様は、stdio接続には同じHTTP認可方式を適用しない考え方を示しています^[2]。企業設計ではtransportごとに秘密の取得方法を分けます。stdioプロセスへ渡す環境変数は、端末全体の共通ファイルではなく、起動時に短時間だけ注入し、子プロセスや診断出力へ漏れないことを試験します。

利用者本人の権限で行う委任操作と、バックグラウンド処理用サービスIDを混ぜません。本人の閲覧範囲を反映すべき検索で共有管理者トークンを使うと、MCPクライアント側の表示制御だけでは情報露出を防げません。サービスIDが必要なら、専用scope、対象リソース、最大件数、時間帯、呼び出し元を限定し、人の操作と識別できる監査主体を付けます。

MCPのセキュリティベストプラクティスは、MCPサーバーが受け取ったトークンを別の下流サービスへそのまま通すトークンパススルーを禁止し、audience検証を求めています^[3]。受信トークンが自サーバー向けか確認し、下流APIにはサーバー自身が正規の交換・委任フローで得た資格情報を使います。scope名が似ていることを理由に、別resource用トークンを受理してはいけません。

権限変更では付与だけでなく、異動、退職、案件終了、申請失効に連動した剥奪を確認します。緊急時に個別トークン、サーバー単位、部門単位の三段階で止められると、全MCP利用を落とさず影響範囲を限定できます。停止操作を持つ担当者自身の権限も監査し、平時に利用ツールを追加できない職務分離を保ちます。

本番環境に制限と停止線を実装する

申請条件は、実行コンテナ、プロキシ、MCPゲート、IAM、データベースの各層へ割り当てます。ファイル操作なら専用作業ディレクトリを読み取り専用または限定書き込みでマウントし、ネットワークは許可ホストだけへ出します。HTTP接続では送信先、TLS、リダイレクト、最大本文、タイムアウトを制限し、stdioでは実行ファイル、引数、作業ディレクトリ、環境変数、stdoutとstderrの扱いを固定します。

モデルへの文面で「削除しないでください」と書くことは補助策であり、削除ツールを公開しない制御の代わりではありません。高影響操作は別クライアントへ分離し、実行直前に対象、件数、差分、取り消し方法を人へ提示します。承認トークンには操作hashと短い期限を持たせ、別の要求へ転用できないようにします。再試行は読み取りと更新で方針を分け、更新には冪等キーと重複検知を必須にします。

停止は検知から実行までの担当と時間を決めます。SOCが未知通信を検知したら接続denyを即時投入し、IAM担当が秘密を失効し、業務所有者が処理中案件を保留し、MCP運用担当が要求IDと実体hashを保全する流れです。原因未確定のまま再接続せず、隔離環境で同じ入力を再現し、許可境界が機械的に拒否することを確認してから限定復旧します。

監査ログを説明可能な記録へする

監査目的は会話全文を保存することではなく、「誰のどの承認に基づき、どの実体が、何へ、どの操作を行い、結果と影響がどうだったか」を再構成することです。基本項目として、要求ID、trace ID、時刻、利用主体、クライアント、サーバー版、protocolVersion、ツール名を残します。さらに、schema hash、対象リソース識別子、件数、承認ID、結果コード、処理時間を構造化して記録します。入力本文と出力本文は、機密区分や目的に応じてhash、伏字、別保管を選びます。

NIST SP 800-18 Rev.2は2026年6月に最終版が公表され、セキュリティ、プライバシー、サイバーサプライチェーンの計画を統合して扱う指針です^[6]。MCP専用標準ではありませんが、統制の責任者、実装状況、証拠、見直しを一つの計画へ整理する際に利用できます。自社が採用する項目と採用しない項目を対応表へ残し、文書名だけを規程へ引用しないようにします。

trace_id=8f2...
approval_id=MCP-2026-0042
actor=user:営業企画123
client=managed-desktop/5.8
server=public-ir-reader/2.4.1
protocol=2026-07-28
tool=fetch_public_pdf
resource_hash=7bd...
decision=allowed
result=success
records=1
duration_ms=842
payload_storage=redacted

ログ自体が新しい情報資産になるため、閲覧者、保存期間、改ざん防止、時刻同期、国外保管、削除例外を定義します。APIキー、アクセストークン、全文の個人情報、モデル内部の不要な推論記録は監査価値より漏えい影響が大きくなる場合があります。秘密検知で記録前に除去し、インシデント調査に必要な原本だけをアクセス制御された保管先へ分離します。

月次監査では全件を目視せず、未登録サーバー、未許可ツール、scope不一致、異常な件数、夜間利用、繰り返す拒否、期限切れ承認、ログ欠損を抽出します。抽出ルールそのものに版と変更理由を持たせます。監査で見つかった逸脱を利用者教育だけで閉じず、許可リスト、IAM、ゲート、配布設定のどこで防げなかったかを特定し、再発ケースを回帰試験へ追加します。

変更審査と事故対応を同じ台帳で回す

再審査の起点はパッケージ更新だけではありません。公開者、所有会社、endpoint、証明書、transport、protocolVersion、ツール、inputSchemaの変更を検知対象にします。scope、保存方針、再委託先、利用国、料金体系、障害時連絡先の変更も対象です。差分が申請条件へ触れない場合は簡易承認、権限・データ・実体へ触れる場合は隔離試験からやり直すなど、変更種別ごとに経路を決めます。

月次の定期確認に加え、重大脆弱性、サーバー状態のdeprecatedまたはdeleted、トークン漏えい、監査欠損、未知通信、誤更新、利用者異動を即時トリガーにします。事故票には対象申請番号と許可リスト版を付け、接続停止、秘密失効、業務保留、影響調査、供給者照会、復旧判定を時系列で記録します。チャット上の連絡だけでは、誰がどの境界を止めたか後から確認できません。

撤退手順も申請台帳に置きます。新規接続と自動更新を止め、資格情報を失効し、保存データを返却・削除し、クライアント設定とパッケージを除去し、代替手段で代表案件を完了させます。その後、旧endpointへの通信と旧秘密の利用がないことを監視します。撤退演習で所要時間が目標を超えた場合は、便利さに関係なくリスク区分または採用可否を見直します。

統制の有効性を数値と実例で判定する

統制KPIは申請件数の多さではなく、承認条件と実行が一致した割合、逸脱を止めた時間、失効が完了した時間、ログから説明できた割合を測ります。利用効果のKPIと統制のKPIを混ぜると、作業時間が短縮した接続の権限逸脱を見逃します。業務所有者は成果、セキュリティ責任者は境界、運用責任者は復旧をそれぞれ判定し、公開継続は三つの合格を必要とします。

この数値は方法を示す仮想例です。48件が一致していても、不一致2件が高影響操作なら平均値で継続を正当化できません。重大条件には「別audienceのトークン受理0件」「未申請の外部送信0件」「取消不能な自動更新0件」のような絶対条件を置きます。目標未達時の所有者、期限、再確認ケースを評価表へ書き、次回会議まで保留という状態を作らないことが大切です。

有効性試験は四半期に一度、実際の停止カードを使って行います。テスト用未許可ツールを公開したサーバーへ接続し、検知、deny、秘密失効、業務保留、代替手段、ログ再構成まで計時します。終了後に各担当の画面と記録を照合し、想定外の手作業や個人依存を手順へ反映します。計画書の存在ではなく、境界を再現可能に止められたかが統制の完成条件です。

向かない導入と段階展開を見極める

MCPが向かないのは、業務APIが一つで呼び出し元も固定されており、既存の認証付き連携で十分な場合です。MCPサーバーを加えると、ツール発見、クライアント互換、追加実体、モデル判断という管理面が増えます。また、法令・契約上モデル処理へ渡せないデータ、取消不能な高影響処理、人の本人確認が不可欠な決定では、検索・下書きまでに用途を限定し、確定操作を既存システムへ残します。

許可リストを強制する共通ゲート、主体別IAM、中央ログ、緊急停止担当を用意できない企業が、いきなり全社員へ任意サーバー追加を開放するのも適しません。最初の段階は公開データの閲覧ツール一つ、管理端末数台、短い有効期限に絞ります。次の段階で社内限定データ、限定更新へ進み、各段階で拒否試験、停止演習、撤退確認を通過した接続だけを増やします。

直ちに利用を止める条件

未登録実体への切り替わり、許可外ツール、scope増加、別audienceの受理、監査ログ欠損、対象外データ取得、未申告先への送信、二重更新、緊急denyの不動作を確認したら接続を停止します。原因が供給者側にあるか自社設定にあるか未確定でも、本番を動かしながら調査しません。

例外承認は、通常要件を免除する永久許可ではありません。例外理由、影響を小さくする代替制御、対象利用者、期限、再審査日、責任者、撤退条件を記録し、期限到来時に自動denyへ戻します。監査不能、秘密失効不能、データ削除不能の三点は代替制御が成立しにくいため、高影響業務では例外にせず採用を見送る判断が妥当です。

企業のMCPガバナンスで今週作る最小統制セット

次の行動：MCP運用責任者は稼働中の接続を一つ選び、クライアント、固定実体、主体、ツール、scope、データ、期限を台帳へ記録します。その値を許可リストへ変換し、未許可ツール、別audience、期限切れの三ケースを拒否できるか試します。最後に接続denyと秘密失効を実行し、代替手段で代表業務を一件完了します。ここまでの証跡を情報セキュリティ責任者が承認すれば、全社展開へ再利用できる最小統制になります。

参考文献・出典

1. Model Context Protocol, Core Architecture, 仕様版 2026-07-28。プロトコル版、能力、基本構造を確認。参照日：2026年7月30日。
2. Model Context Protocol, Authorization, 仕様版 2026-07-28。HTTP認可、resource、scope、stdioの扱いを確認。参照日：2026年7月30日。
3. Model Context Protocol, Security Best Practices, ドキュメント版 2026-07-28。トークンパススルー禁止、audience検証等を確認。参照日：2026年7月30日。
4. 経済産業省, AI事業者ガイドライン（第1.2版）, 2026年3月31日取りまとめ、掲載ページ更新日：2026年4月1日。参照日：2026年7月30日。
5. National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0), 公開日：2023年1月26日。2026年7月30日時点で改訂作業中との公式案内を確認。参照日：2026年7月30日。
6. National Institute of Standards and Technology, NIST SP 800-18 Rev. 2, 最終版公開：2026年6月。セキュリティ・プライバシー・サプライチェーン計画を確認。参照日：2026年7月30日。