MCPサーバーを社内導入する前のセキュリティ設計 ― AIとツールをつなぐ9つの統制チェック
AIエージェントを社内システムやSaaSにつなぐ標準として、MCP（Model Context Protocol）の採用が広がっています。便利さの裏で、MCPサーバーは「AIに社内の道具箱の鍵を渡す」仕組みでもあります。つなぐ前に押さえるべき統制を、導入担当者が判断できる粒度で9点に整理しました。
背景 ― MCPは「AIと道具」をつなぐ配管
MCPは、AIモデルが外部のツールやデータソースを呼び出すための共通規格です。ファイル読み取り、社内DB検索、チケット起票、コード実行といった機能を「MCPサーバー」として提供し、AI側が必要に応じて呼び出します。従来は各ツールごとに個別連携を書いていましたが、MCPで標準化されたことで接続コストが大きく下がりました。裏返せば、一つのMCPサーバーが複数の重要システムへの入口になり、AIの判断で自動実行される経路が生まれます。ここに統制がないと、プロンプトインジェクションで乗っ取られたAIが、そのまま社内の道具を操作します。
リスクの全体像 ― 過剰な権限と監査不能が二大論点
MCPサーバー特有のリスクは主に三方向です。第一に権限。AIエージェントは「与えられた道具は使ってよい」と解釈するため、MCPサーバーに広い権限を持たせると被害範囲がそのまま広がります。第二に入力汚染。外部から読み込んだ文書やメールに埋め込まれた指示（間接プロンプトインジェクション）が、MCP経由の実行を誘発します。第三に監査。どのエージェントが、いつ、どのツールを、どんな引数で呼んだかを記録していないと、事故後に何が起きたかを再構成できません。規制当局と監査法人は2026年、この「判断トレース」の有無を見始めています。
導入前チェックリスト9項目
- 各MCPサーバーに与える権限を「読み取り専用」から始め、書き込み・削除・実行は個別に承認しているか
- 認証情報をエージェントのコンテキストに直接埋め込まず、サーバー側で秘匿・注入しているか
- ツール呼び出しの引数を検証し、危険なコマンド・パス・クエリを遮断するガードを置いているか
- 外部データ由来のテキストを「命令」ではなく「データ」として扱う分離設計になっているか
- 誰が・いつ・どのツールを・どんな引数で呼んだかを、後から追える形で記録しているか
- 破壊的操作（削除・送金・外部送信・本番デプロイ）に人間の承認ステップを挟んでいるか
- MCPサーバーの提供元と依存パッケージの出所を確認し、野良サーバーを無審査で接続していないか
- 1エージェント＝1目的に絞り、無関係なツールへの到達を既定で遮断しているか
- 接続するツールの一覧（何につながっているか）を台帳化し、棚卸しできる状態にしているか
打ち手 ― 最小権限とサンドボックスから
優先順位は明確です。まず全MCPサーバーを読み取り専用で立ち上げ、業務が回ることを確認してから書き込み権限を個別に開けます。次に破壊的操作へ人間の承認を必須化し、コード実行系は隔離環境（サンドボックス）に閉じ込めます。最後にツール呼び出しの全ログを一箇所に集約し、異常な引数や連続実行を検知できるようにします。派手な検知基盤より、権限を絞ることの効果が先に効きます。
AIに鍵を渡すなら、開く扉は一つずつにする。
あわせて読みたい
Omamori AI の結論
- 事実: MCPは接続コストを下げる一方、一台のサーバーが複数の重要システムへの入口になり、AIの判断で自動実行される経路を生む。
- 判断軸: 「便利だから全部つなぐ」ではなく「最小権限＋破壊的操作は人間承認」を既定にする。読み取り専用から段階的に開ける。
- 打ち手: 権限を絞り、外部データと命令を分離し、ツール呼び出しを全量記録して判断トレースを残す。
経営者視点で考えるべきこと
MCP導入は現場の生産性施策として始まりますが、統制なしに広げると、AIエージェントが社内システムを操作した結果の責任が誰にあるのかが曖昧になります。特に破壊的操作（データ削除・外部送信・決済）を人間の承認なしにAIへ委ねる設計は、事故時に説明責任を果たせません。取締役会として問うべきは「どのエージェントが、どこまでの権限を、誰の承認で持っているか」を一覧で答えられるかどうかです。判断トレースの記録は監査対応のためだけでなく、事業を止めずにAI活用を進めるための保険でもあります。全面禁止でも全面開放でもなく、権限台帳と承認フローを持ったうえで広げる、という中間の設計を経営レベルで承認しておくことが、実務と統制の両立につながります。
