AIエージェントの提案で、近頃よく出てくるのがMCP（Model Context Protocol）である。MCPは、AIエージェントを外部のツールやデータソースへ接続するための共通の仕組みで、これを使うとエージェントが扱える範囲が大きく広がる。社内の文書、業務システム、外部のサービスなどへつなげられる。便利な反面、接続先が増えるほど、管理すべき範囲とリスクも広がる。
本記事は、MCPをはじめとする外部ツール接続を、どうガバナンスするかを発注者の視点で整理する。読者として想定しているのは、エージェントに業務システムや社内データをつなぐ提案を受けている経営者、DX担当、情報システム担当である。データの境界についてはデータアクセス境界の設計も参考になる。
結論：つなぐ先を管理し、権限を最小にし、出力を疑う
外部ツール接続のガバナンスの要点は、「接続先を管理台帳で把握し、権限を最小限にし、外部からの入力を無条件に信頼しない」ことである。GXOがこの設計で重視するのは、次の3点である。
- どのツール・データソースへ接続するかを一覧で管理する
- 各接続に与える権限を、必要最小限に絞る
- 認証情報を安全に扱い、外部からの出力を検証してから使う
MCPは「つなぎやすさ」が利点だが、つなぎやすいからこそ、何につながっているかを管理しないと、把握できない接続が増えてしまう。
なぜMCP・外部ツール接続はガバナンスが要るのか
外部ツール接続は業務の幅を広げるが、次の理由でリスクの管理が必要になる。
- 接続先が増えやすい：MCPはつなぎやすいため、管理しないまま接続が増え、全体像が見えなくなる
- 権限が過剰になりやすい：とりあえず広い権限で接続すると、必要以上のデータや操作に手が届く
- 認証情報が広がる：各接続のキーやトークンを安全に扱わないと、漏れたときの影響が大きい
- 外部の出力が信頼できるとは限らない：接続先から返る内容に、エージェントを誤らせる指示が混じることがある
- どこへ何が送られたか追えない：接続のログがないと、情報がどこへ流れたかを後から確認できない
このため、「つなげば便利」で終わらせず、何に、どの権限で、どう接続するかを設計する必要がある。セキュリティ全般の論点はセキュリティとプライバシーの確認も参考になる。
接続を分解して管理する
外部ツール接続を検討するときは、次の区分で整理すると、管理の漏れを防げる。
| 区分 | 確認すること |
|---|---|
| 接続先 | どのツール・データソースへつなぐか |
| 用途 | その接続で何をするか（読み取り・操作） |
| 権限 | 与える権限の範囲（最小限か） |
| 認証情報 | キー・トークンの保管と更新の方法 |
| ログ | 何を、どこへ送ったかの記録 |
| 出力の扱い | 接続先からの内容をどう検証して使うか |
この区分で接続を一覧化すると、過剰な権限や、管理されていない接続が見えやすくなる。ツール呼び出しの設計はAPI・ツール呼び出しの設計も土台になる。
権限と認証情報を最小・安全に保つ
外部ツール接続で被害が大きくなりやすいのが、過剰な権限と、認証情報の扱いの甘さである。次の観点を設計しておきたい。
- 権限の最小化：各接続に、業務に必要な最小限の権限だけを与える
- 読み取りと操作の分離：参照だけで済むなら、更新・削除の権限は与えない
- 認証情報の安全な保管：キーやトークンをコードに直接書かず、安全な仕組みで管理する
- 更新と失効：キーを定期的に更新し、不要になった接続は速やかに失効させる
権限が広いほど、エージェントが誤ったときや、接続が乗っ取られたときの影響が大きくなる。最小限から始め、必要に応じて広げるのが基本である。
外部からの出力を無条件に信頼しない
見落とされやすいのが、接続先から返ってくる内容の扱いである。外部のデータや文書には、エージェントを誤った動作に導く指示（プロンプトインジェクションと呼ばれる）が混じることがある。次の点を設計しておきたい。
- 出力を検証する：接続先から得た内容を、そのまま指示として実行しない
- 重要な操作には承認を挟む：外部の情報をきっかけに行う重要な操作には、人の確認を入れる
- 信頼の境界を意識する：社内の管理されたデータと、外部の信頼できないデータを区別して扱う
- 想定外の挙動を検知する：通常と異なる動きを検知し、止める・通知する
「便利につながる」ことと「安全につながる」ことは別である。外部の出力を疑う設計があるかどうかで、接続の安全性が大きく変わる。重要な操作に承認を挟む考え方は人の承認を挟む設計も参考になる。
つなぐ前に「つなぐべきか」を問う
MCPは多くのツールへ簡単につなげるが、つなげられることと、つなぐべきことは別である。発注前に、次の問いを立てておきたい。
- その接続は本当に必要か：業務に必要な接続か、あれば便利という程度か。
- 読み取りだけで足りないか：操作の権限まで与える必要が本当にあるか。
- 段階的に広げられるか：最初は最小限の接続で始め、効果を見てから広げられないか。
接続は増やすほど便利になる一方、管理すべき範囲も広がる。まずは業務に不可欠な接続だけに絞り、効果と運用負担を見ながら広げるほうが、リスクを抑えられる。接続の妥当性は、PoCの段階で検証しておきたい。
導入前チェックリスト
- 接続するツール・データソースを一覧で把握したか
- 各接続の用途と、必要な権限を明確にしたか
- 権限を必要最小限に絞ったか（読み取りと操作を分けたか）
- 認証情報（キー・トークン）の保管・更新の方法を決めたか
- 何を、どこへ送ったかのログを残す設計にしたか
- 接続先からの出力を検証してから使う設計にしたか
- 外部の情報をきっかけにする重要操作に承認を挟むか決めたか
- そもそもその接続が必要かを検討したか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| どのツールへ、何の目的で接続しますか | 接続の必然性 |
| 各接続の権限は最小限ですか | 過剰権限の有無 |
| 認証情報はどう安全に管理しますか | 情報漏れの防止 |
| 接続のログは追えますか | 流れの追跡 |
| 外部からの出力はどう検証しますか | 不正入力への対策 |
接続の目的を説明でき、権限の最小化や出力の検証まで設計に含められる会社が望ましい。「とりあえず広くつなぐ」提案には注意したい。
GXOに相談する前に整理するとよい情報
- エージェントにつなぎたいツール・データソースと、その用途
- 各接続で、読み取りだけで足りるか、操作まで必要か
- 扱うデータに個人情報や機微な情報が含まれるか
- 社内の認証・キー管理の仕組みや制約
- すでに受け取っているMCP・ツール接続の提案があれば、その内容
これらが整理されていなくても相談は可能である。つなぎたいツールと用途が見えていれば、必要な接続と権限の範囲を一緒に整理できる。
参考にした外部観点
- NIST AI Risk Management Framework（AI RMF 1.0） — AIシステムのリスクを設計・運用の各段階で管理する枠組み。外部接続に伴うリスクの整理に役立つ。
- OWASP — アプリケーションのセキュリティに関する国際的なコミュニティ。プロンプトインジェクションや入力検証など、外部入力を扱う際の考え方の参考になる。
- IPA（情報処理推進機構） — システムのセキュリティ・運用に関する公的な情報源。認証情報の管理や接続のリスク評価の参考になる。
関連記事
- AIエージェント導入前チェックリスト｜データアクセス境界の設計
- AIエージェント導入前チェックリスト｜セキュリティとプライバシーの確認
- AIエージェント導入前チェックリスト｜API・ツール呼び出しの設計
よくある質問
Q1. MCPとは何ですか
MCP（Model Context Protocol）は、AIエージェントを外部のツールやデータソースへ接続するための共通の仕組みである。これを使うと、エージェントが社内文書や業務システムなど、扱える範囲を広げられる。
Q2. つなぎやすいMCPは、危険なのですか
MCP自体が危険なわけではない。つなぎやすいために管理されない接続が増えたり、過剰な権限を与えたりすると、リスクが広がる。接続先を一覧で管理し、権限を最小にすれば、利点を安全に活かせる。
Q3. 外部から返ってきた内容を、そのまま使ってよいですか
そのまま指示として実行するのは避けたい。外部のデータには、エージェントを誤らせる指示が混じることがある。検証してから使い、重要な操作には人の確認を挟むのが安全である。
Q4. 認証情報はどう扱えばよいですか
キーやトークンをコードに直接書かず、安全な仕組みで保管し、定期的に更新する。不要になった接続は速やかに失効させる。漏れたときの影響を抑えるためにも、扱いの方針を発注前に確認しておきたい。
AIエージェント導入前に、権限・ログ・運用リスクを整理しませんか
GXOでは、AIエージェントやAIチャットボットを業務システムへ接続する前に、業務範囲、権限設計、監査ログ、承認フロー、停止条件、セキュリティ、運用体制を整理し、PoCから本番運用までの現実的な進め方をご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。