企業は、MCP接続を大規模にどう統制すべきか

Model Context Protocol（MCP）は、AIエージェントが外部のツール、データ、API、業務フローに接続するための標準的な方法を提供します。MCPはエージェント開発の速度と一貫性を高める一方で、企業におけるAIリスクのあり方も変えます。

MCPを使うと、エージェントは、ツールを見つけ、そのツールが何をするものと説明されているかを解釈し、いつ呼び出すかを判断し、パラメータを割り当て、その結果を業務フローの次のステップで使えます。接続は、もはや単なる連携ポイントではありません。エージェントが判断を下す領域（decision surface）の一部になります。

これは、ほとんどの企業がまだ管理する態勢を整えていない、ガバナンス上のリスクを生み出します。1つのMCPサーバーが、複数のシステム、権限、業務フローにまたがる複数のツールを公開することがあります。エージェントの自律性が高まるにつれ、リスクはアクセスそのものにとどまらず、エージェントがそのアクセスを使って何をするかを判断することにまで広がります。

MCP接続を大規模に統制するには、企業はそれらを、エージェント型AIのコントロールプレーンの一部として扱う必要があります。すべてのサーバー、ツール、権限、エージェントとの関係に、明確な責任者、定められた範囲、実行時のモニタリング、監査可能性が求められます。この記事では、MCPのリスクがどこに現れるのか、エージェントの計画がどのように実行へと変わるのか、そしてMCP接続を、範囲を限定し、観察でき、本番稼働に耐える状態に保つために何が必要かを解説します。

本記事の要点

• MCPは、エージェント型システムが、自律的な業務フローの中で、ツールを呼び出し、行動を実行し、その結果を観察するための標準的な方法を提供します。
• MCP接続が1つ増えるたびに、ツールの選択、パラメータの割り当て（parameter binding）、戻り値の処理、後続の行動を含む、エージェントの意思決定の領域が広がります。
• ガバナンスを担うチームには、MCPサーバー、公開されているツール、接続されているエージェント、意思決定上の制約、呼び出しのパターンを把握できることが求められます。
• MCPガバナンスには、責任の所在、範囲を限定した権限、実行時のモニタリング、監査証跡、アクセスのレビュー、再承認のきっかけを含めるべきです。
• 管理されていないMCP接続の最大のリスクは、企業のシステム内でエージェントの自律性が制御されなくなることです。

エージェント型AIにおけるMCPとは何か

MCPは、AIエージェントが、自律的な業務フローの中で、外部のツールに到達し、行動を実行し、その結果を観察するための標準的な方法を提供します。

MCPは、エージェントが行動するために使う操作盤のようなものです。どのツールが使えるのか、それぞれのツールが何をするものなのか、どんな入力が必要なのか、ツールの実行後に何が返ってくるのかを、エージェントに示します。

MCPは、エージェントの計画層と、エージェントが呼び出せるシステムとの間に位置します。ホスト・クライアント・サーバーという構成を取ります。ホストはAIアプリケーションです。クライアントは接続を管理します。MCPサーバーは、ツール、リソース、プロンプトといった機能を公開します。

企業の環境では、最もリスクが大きいのはツールです。ツールによって、エージェントは、データベースへの問い合わせ、APIの呼び出し、記録の更新、業務フローの起動、計算の実行ができるようになります。こうした機能がエージェントのループに組み込まれると、ツールへのアクセスは、意思決定の権限になります。たとえば、サポート用のエージェントは、1つの業務フローの中で、チケットの履歴を取得し、顧客記録を更新し、後続の対応を調整できます。

なぜMCP接続はガバナンス上のリスクを生むのか

MCP接続がリスクを生むのは、エージェントが推論しながら行動できるようになるからです。エージェントがMCPサーバーを呼び出せるようになると、コンテキストの取得、関数の呼び出し、業務フローの起動ができ、ツールの応答のたびに、次に何をするかを判断できます。

企業の環境では、こうしたステップが、顧客記録、社内システム、財務データ、本番の業務フローに及ぶことがあり、その途中で人によるレビューがほとんど入らない場合も少なくありません。

リスク	起きること	チームが注視すべき点
ツールの意味の取り違え	エージェントが、ツールが何をするものか、いつ使うべきかを誤解する	ツールの説明、事前条件、副作用、実在しないツール（ハルシネーションで作り出されたもの）
連鎖的な情報露出	あるツールの戻り値が、別のツール呼び出しのコンテキストになる	ツール間のデータの流れと、後続のアクセス
レビューなしの実行	エージェントが、途中のレビューなしに、ツールの一連の呼び出しを実行する	計画のステップ、制約の確認、ループの挙動
実行時のツール追加	エージェントの承認後に、MCPサーバーが新しいツールを公開する	サーバーの変更と、承認とのずれ
プロンプトインジェクション	ツールの戻り値のデータが、エージェントの次の計画のステップを誘導する	戻り値の検証と、想定外の行動
ツールポイズニング	ツールのメタデータや説明に、隠された指示が含まれている	ツール記述子の完全性と、サーバーの信頼性

ツールのハルシネーションと、意味の取り違え

ツールのハルシネーションは、MCPガバナンスにおける最も深刻なリスクのひとつです。顧客データベースにアクセスできるエージェントが、実在しないget_customer_credit_scoreというツールをハルシネーションで作り出したり、get_account_balanceをset_account_balanceと読み違えたりすることがあります。名前は意味の面で似ていますが、業務への影響はまったく異なります。

ツールが使える状態にあるというだけで、エージェントが正しいツールを選ぶと、企業が決めてかかることはできません。チームは、エージェントにどのツールを見せるのか、それらのツールをどう命名し説明するのか、どの入力スキーマを適用するのか、どんな副作用がありうるのか、そしてエージェントが本番で動いている間に、意味の取り違えをどう検知するのかを、制御する必要があります。

ツール間の依存関係

ツール間の依存関係は、連鎖的なリスクを生みます。エージェントが、システムAから機微なデータを取得し、それを使ってシステムBを呼び出すことがあります。エージェントが自律的なループの中でツールを組み合わせると、1つの権限が、複数のシステムにまたがる情報露出の入り口になりえます。

ガバナンスでは、ツールの組み合わせ、順序、コンテキスト、データの流れを考慮する必要があります。エージェントがツールの出力を後続の行動につなげられる以上、個々のツールへのアクセスだけをレビューしても十分ではありません。

自律的な実行

エージェントは、複数のステップからなる業務フローを自律的に実行します。エージェントが誤ったツールを選んだり、戻り値を読み違えたり、制約の確認を怠ったり、業務フローが止まるべきところを過ぎても行動を続けたりすると、その誤りは、ループが終わるか、モニタリングがずれを捉えるまで、広がり続ける可能性があります。

MCPガバナンスには、計画時のコンテキスト、ツールの選択、パラメータの割り当て、戻り値の検証、ループの挙動を把握できることが必要です。最終的な結果だけでは、統制がどこで破綻したのかは分かりません。

MCPはどのように、計画を行動へと変えるのか

MCPは、エージェントに、推論から実行へと至る道筋を与えます。エージェントは、タスクを評価し、ツールを選び、データを渡し、応答に基づいて行動し、そこから業務フローを続けられます。ガバナンスを担うチームには、各ステップを把握できることが必要で、特にそれらの行動が企業のシステムに及ぶ場合は重要です。

重要な統制のポイントは、ツールの選択、パラメータの割り当て、戻り値の処理、制約の確認、ループの終了です。意図が行動に変わるのがここであり、ガバナンスが機能していなければならない場所でもあります。

統制のポイント	ガバナンス上の問い	よくある失敗のパターン
ツールの選択	エージェントはどのツールを選び、それはなぜか	エージェントが誤ったツールを選ぶ、またはツールの意味を誤解する
パラメータの割り当て	エージェントは、ツールにどのデータを渡したか	想定外の値、不正な形式の識別子、誤ったデータソースのデータを使う
戻り値の処理	エージェントは、ツールの応答をどう解釈したか	破損した、不完全な、あるいは敵対的な戻り値のデータを信頼してしまう
制約の確認	エージェントは、行動の前に条件を確認したか	承認された事前条件の外でツールを呼び出す
ループの終了	エージェントはいつ行動を止めたか	承認された業務フローを超えて、ツールを呼び出し続ける

エージェントが複数のツールを使える場合、ガバナンスを担うチームは、エージェントがどのツールを選んだのか、その選択がタスクに照らして妥当だったのかを知る必要があります。安全だった業務フローも、エージェントが誤った顧客IDを取り込んだり、誤った出どころの承認金額を渡したり、あるツールの応答の値を使って別の場所の行動を起動したりすると、たちまちリスクを帯びます。

ツールの呼び出しが成功しても、不完全な、古い、あるいは誤解を招くコンテキストが得られることもあります。エージェントがその応答を確認せずに信頼すると、最初の行動に問題がなかったように見えても、業務フローの次のステップで誤りが起きかねません。

エージェントがいつ止まるのかも、チームは知っておく必要があります。終了のルールが弱いと、エージェントは、リトライやツールの呼び出しを繰り返したり、承認された範囲を超えて業務フローを延ばしたりしかねません。ループの長さ、リトライの挙動、タイムアウトのパターンは、エージェントが本来の道筋からそれ始めたことを知る、実務的なシグナルになります。

エージェント型の業務フローで、MCPの権限はどのようにドリフトするのか

エージェント型のシステムでは、ツールの呼び出しが自律的に行われるため、権限のドリフト（承認した時点から、実際に権限が及ぶ範囲が徐々にずれていくこと）を検知するのは困難です。MCP接続は時間とともにアクセス権を積み上げていくため、四半期ごとのアクセス制御の監査が、権限の無秩序な拡大を防ぎます。変更を契機にしたレビューと並んで、定期的なレビューも欠かせません。

ドリフトは、正式なアクセス権の変更がなくても起こります。同じエージェントでも、プロンプトが変わったとき、ツールセットが広がったとき、業務フローが変わったとき、モデルが変わったとき、あるいはツールを新しい方法で組み合わせ始めたときに、リスクが高まることがあります。

ツールの組み合わせによる範囲の拡大

ツールAとツールBを、それぞれ独立して呼び出すことを承認されたエージェントが、後になって、それらを組み合わせ始めることがあります。ツールAを呼び出し、その出力でツールBのパラメータを決め、新しい業務フローを作り出せます。当初の承認が対象としていたのは個々のツールの利用であり、組み合わせた挙動やデータのつながりは、異なるリスクプロファイルを持つ可能性があります。

チームは、エージェントがシステムをまたいで機能をつなぎ始める前に、承認するツールの呼び出し順序を定義しておく必要があります。どのデータをあるツールから別のツールへ渡してよいか、どの組み合わせに人によるレビューが必要か、業務フローをどこで止めるべきかを、明記しておくべきです。

企業の規模では、ガバナンスは、承認済みのツールからエージェントが組み立てうる業務フロー全体を考慮に入れる必要があります。

再承認なしのツール公開

MCPサーバーが、当初は1つのツールだけを公開していたとします。その後、ツールが追加されます。エージェントの権限の記録は変わりませんが、意思決定の領域は広がります。

エージェントは、承認を受けたことのないツールの選択に、直面することになります。MCPサーバーの変更は、エージェントのアクセスの記録が変わっていないように見えても、ガバナンスのレビューのきっかけとすべきです。

更新後のエージェントの振る舞いの変化

プロンプトの変更、モデルの変更、取得処理の変更、ルーティングの変更、新しいシステム指示は、エージェントがツールを選び、戻り値を扱う方法を変えることがあります。それ以前のガバナンス上の承認は、古い振る舞いを前提としたものです。

アクセスのレビューでは、サーバーの変更だけでなく、エージェントの変更も考慮に入れる必要があります。更新後のエージェントが、同じ意思決定の権限を、同じ方法で行使しているかどうかを、チームは確認すべきです。

システム間の暗黙の依存関係

エージェントが、システム1から読み取るツールAと、システム2に書き込むツールBを、呼び出すことを承認されているとします。その承認は、ツールAの出力がツールBの入力になることまでは、対象にしていない可能性があります。

自律的なループでは、こうしたつながりが生じやすくなります。ガバナンスの記録には、承認されたツールの組み合わせ、禁止されるデータの流れ、人によるレビューが必要となる条件を、含めるべきです。

MCPの定期的なレビューでは、文書化されたアクセス権だけでなく、実際の挙動を調べるべきです。チームは、ツールの呼び出しパターン、制約違反、ツールの組み合わせ方、そしてエージェントの意思決定のトレースが時間とともにどう変化したかを、確認すべきです。

なぜMCPの活動には、追跡可能性が必要なのか

エージェントがツールを呼び出し、記録を更新し、業務フローを進み続けられるとき、ガバナンスを担うチームには、「何かが起きた」と記録するだけのログでは足りません。必要なのは、意思決定の経路です。

追跡可能性は、チームにその経路を与えます。エージェントが誤ったツールを選んだり、誤った顧客IDを割り当てたり、業務フローが止まるべきところを過ぎても行動を続けたりした場合、チームは、判断がどこで道を外れたのかを理解できるだけの細かさで、一連の流れを再現できなければなりません。

規制の厳しい業界では、これは、自律的な行動が規制に適合していたことを願うだけの状態と、それを証明できる状態との違いです。有用なMCPの監査証跡は、計画時のコンテキスト、選択されたツール、パラメータ、ツールの戻り値、検証のステップ、確認された制約、後続の行動、結果を記録している必要があります。

MCPに接続されたエージェントについての有用な監査証跡は、次の問いに答えられるものであるべきです。

• どのエージェントが行動したか。
• どのMCPクライアントとサーバーが関わったか。
• ツールを選んだ時点で、エージェントの計画時のコンテキストは何だったか。
• どのツールを呼び出し、それはなぜか。
• どのパラメータを割り当てたか。
• ツールはどのデータを返し、それは検証されたか。
• エージェントは、その戻り値を、次の計画のステップにどう取り込んだか。
• どのような結果が続いたか。

企業は、MCP接続の何を統制すべきか

企業は、MCP接続の層全体を統制すべきです。サーバー、サーバーが公開する機能、エージェントの意思決定の権限、適用される制約、そして行動をどう監査できるかです。アクセス制御は、多くの場合、基盤となる層です。チームは、エージェントがどのツールを、どんな条件のもとで、どの業務上の境界の中で呼び出せるのかを、定義する必要があります。

ガバナンスの領域	チームが定義すべきこと
サーバーの責任者	MCPサーバーを誰が所有し、承認するのか
公開されるツールとその意味	入力スキーマ、事前条件、副作用を含め、各ツールが何をするのか
ツール呼び出しの事前条件	ツールをいつ呼び出してよいか、どの条件が成り立っていなければならないか
接続されたデータソース	エージェントがどのデータにアクセスし、後続に渡してよいか
エージェントのアイデンティティと認可	どのエージェントがその接続を使い、どの範囲の意思決定を持つのか
権限と制約	エージェントが何を読み取り、書き込み、更新し、削除し、起動できるか
パラメータの制約	許容される数値の範囲、識別子、形式、テナントの境界
業務上の範囲と終了	どの業務フローを対象とし、エージェントがいつ止まるべきか
ツールの組み合わせのルール	どのツールをどんな順序で組み合わせてよいか
戻り値のデータの検証	エージェントが使う前に、ツールの戻り値をどう検証するか
実行時のモニタリングのシグナル	正常、異常、ポリシー違反の挙動を示すシグナル
監査証跡の要件	計画時のコンテキスト、ツールの選択、パラメータ、戻り値、結果の記録
レビューの頻度ときっかけ	アクセスをどのくらいの頻度でレビューし、どの変更が再承認のきっかけになるか

このガバナンスの記録によって、チームは、どのMCP接続が承認されているのか、どのエージェントがそれに依存しているのか、それらがどのシステムに到達するのか、どの呼び出しのパターンを人によるレビューの対象としてフラグを立てるべきかを、明確に把握できます。

企業はMCPガバナンスを、どう運用に落とし込むか

MCPガバナンスを運用に落とし込む出発点は、単純な問いです。自社のエージェントが実際に何をできるのかを、把握できているでしょうか。すべてのMCPサーバーについて、棚卸しをし、リスクの順位付けをし、エージェントに承認された権限の範囲に限定し、本番で監視し、ツール、業務フロー、エージェントの挙動が変わるたびにレビューする必要があります。

把握と可視化

ガバナンスを担うチームには、MCPサーバー、公開されているツール、接続されたデータソース、承認されたエージェント、許可された業務フローの、最新の一覧が必要です。その一覧にあるエージェントは、それぞれ、固有の認証情報と最小権限の権限で動作するべきです。その権限は、エージェントが呼び出すことを許可された特定のMCPツールと業務上の目的の範囲に限定します。

MCPサーバーへのアクセスが、すべてのツールを呼び出す承認を自動的に意味するべきではありません。エージェントごとに、チームは、どのツールを、どんな条件で、どんなパラメータの制約のもとで、どんな業務上の目的で呼び出せるかを、定義すべきです。

リスクの分類とモニタリング

MCP接続は、ツールの意味、データの機微性、行動の影響、認可モデル、制約の複雑さ、組み合わせのリスクに基づいて分類すべきです。リスクの高い接続には、より厳格な承認、より厳しい制約、より強力なモニタリング、より頻繁な挙動の検証が必要です。

AIゲートウェイや集中管理の統制層を設けることで、MCPのツールへのアクセス、パラメータの制約、レート制限、監査ログを、エージェント全体で一貫して適用する場所を持てます。これにより、ガバナンスのロジックを、エージェントの業務フローごとに実装し直す必要が減ります。

本番のモニタリングでは、ツールの選択パターン、制約の遵守状況、パラメータの挙動、ハルシネーションで作り出されたツール、戻り値の処理、ツールのメタデータの変更、推論の一貫性を、見える化すべきです。チームは、エージェントが承認された権限を行使しているのか、想定外の挙動にずれていっているのかを、把握する必要があります。

レビューと再承認

定期的なレビューでは、呼び出しのパターンを、決まった頻度で評価すべきです。エージェント、プロンプト、モデル、ツール、サーバー、業務フローが更新されたときには、変更を契機にしたレビューを行うべきです。この運用上の規律は、ガバナンス、オブザーバビリティ、監査ログを、最初からアーキテクチャに組み込んでおくことで、最もうまく機能します。ガバナンスを後から付け足すのは、MCP接続のライフサイクルに最初から設計しておくよりも、はるかにコストがかかります。

企業の規模では、MCPガバナンスは、自律的なシステムに対するアクセス制御のように機能します。チームは、権限を定義し、接続を承認し、権限の行使を監視し、変更をレビューし、不要になったアクセスを取り消します。

MCP接続を承認する前に、チームは何を問うべきか

チームは、エージェント、業務上の目的、関わるツール、リスクにさらされるデータ、制約、監査要件を理解したうえで初めて、MCP接続を承認すべきです。承認のプロセスでは、エージェントが本番でツールを呼び出す前に、その意思決定の権限を明示しておく必要があります。

エージェントと権限	どのエージェントがこの接続を使うのか。承認された業務上の目的は何か。エージェントの責任者は誰か。ツールの呼び出しを通じて、エージェントにどんな判断を許すべきか。
業務上の文脈	どの業務フローを支えるのか。成功とはどのような状態か。エージェントは、いつ止まるべきかをどう知るのか。エージェントが誤った判断をした場合、どんな影響が出るのか。
技術的な詳細	MCPサーバーの責任者は誰か。エージェントが呼び出すべき具体的なツールはどれか。どんな事前条件と副作用があるか。エージェントは、どのデータを取得し、変更し、後続に渡せるのか。
制約と範囲	各ツールは、どんな条件のもとで呼び出すべきか。どのパラメータの範囲が許されるか。決して呼び出してはならないツールはどれか。どのツールの組み合わせが承認されているか。
データと安全性	どのデータがリスクにさらされるか。ツールの戻り値は、どう検証されるのか。どんなシグナルが異常な挙動を示すのか。推論のドリフトは、どう検知するのか。
モニタリングと監査	計画、ツールの選択、パラメータ、戻り値、結果は、どのログに記録されるのか。ツールのハルシネーションを、チームはどう検知するのか。挙動は、どのくらいの頻度でレビューされるのか。どの変更が、再承認のきっかけになるのか。

これらの問いによって、MCPの承認は、運用上の規律になります。チームは、意思決定の権限を評価し、制約を文書化し、実際の挙動を監視し、ガバナンスをそろえておくための、繰り返し使える方法を手にできます。

MCPガバナンスのチェックリスト

企業は、次のチェックリストを使って、MCP接続を大規模に統制できます。

• 1．すべてのMCPサーバーと、公開されているツールの一覧を作成する。
• 2．サーバー、ツール、接続されているエージェントのそれぞれに、責任者を割り当てる。
• 3．どのエージェントが、どのツールを呼び出せるかを定義する。
• 4．業務上の目的、データの区分、行動の種類ごとに、権限の範囲を限定する。
• 5．ツールの事前条件、副作用、承認された組み合わせを文書化する。
• 6．エージェントが後続の行動で使う前に、ツールの戻り値を検証する。
• 7．呼び出しのパターン、制約違反、権限のドリフトを監視する。
• 8．計画時のコンテキスト、選択されたツール、パラメータ、戻り値、結果の監査ログを記録する。
• 9．プロンプト、モデル、ツール、サーバー、業務フロー、エージェントの挙動が変わったときに、再承認を行う。

MCPを、エージェント型AIのライフサイクルの一部として統制する

MCPガバナンスは、より広いエージェント型AIのライフサイクルの中に位置づけるべきものです。エージェントが、より多くのツール、データ、業務フローにアクセスできるようになるにつれ、企業には、アイデンティティ、権限、モニタリング、監査可能性、そしてエージェント群全体の監督について、明確な統制が必要になります。

経営層にとって、MCPガバナンスの影響は、セキュリティだけにとどまりません。運用上のリスク、コンプライアンス上のリスク、顧客からの信頼、そして確信を持ってエージェント型AIを拡大していく力を、左右します。

MCP接続は、モデルの推論、企業のデータ、システムの行動が交わる、エージェント型のコントロールプレーンの内側に位置します。ライフサイクル全体にわたって、エージェント、ツール、権限、モニタリング、監査可能性を統制する方法をより詳しく知るには、「Enterprise guide to agentic AI」をダウンロードしてご覧ください。

よくある質問

エージェント型AIにおけるMCPとは何ですか。

Model Context Protocolは、エージェント型システムが外部のツールに到達し、自律的な行動を実行できるようにする、呼び出しの標準です。MCPは、エージェントを、文書リポジトリ、データベース、チケット管理プラットフォーム、開発者向けツール、顧客向けアプリケーション、社内API、ワークフローシステムに接続できます。

MCPガバナンスとは何ですか。

MCPガバナンスとは、AIエージェントが、MCP接続を通じて、外部のツールをどう見つけ、選び、呼び出し、組み合わせるかを統制する規律です。責任の所在、認可、範囲を限定した権限、ツールの制約、実行時のモニタリング、監査証跡、再承認のきっかけが含まれます。

なぜMCP接続にガバナンスが必要なのですか。

MCP接続にガバナンスが必要なのは、エージェントが、計画のループの中で、ツールの呼び出しについて自律的に判断するからです。エージェントは、ツールをハルシネーションで作り出したり、意味を誤解したり、誤ったパラメータでツールを呼び出したり、意図せずツールを組み合わせたり、破損した戻り値に誘導されたりすることがあります。

企業は、MCP接続を大規模にどう統制できますか。

企業は、エージェントの意思決定の権限に結び付けた中央の一覧を維持し、接続のリスクを分類し、権限を特定のツールに限定し、ツールの選択パターンを監視し、監査証跡を記録し、定期的な頻度、システムの変更、挙動のシグナルに基づいてアクセスをレビューすることで、MCP接続を大規模に統制できます。

MCPガバナンスの記録には、何を含めるべきですか。

MCPガバナンスの記録には、サーバーの責任者、公開されているツール、ツールの意味、呼び出しの事前条件、接続されたデータソース、エージェントのアイデンティティ、意思決定の権限、権限、パラメータの制約、業務上の範囲、ツールの組み合わせのルール、戻り値の検証、モニタリングのシグナル、監査要件、レビューのきっかけを含めるべきです。

管理されていないMCP接続の最大のリスクは何ですか。

管理されていないMCP接続の最大のリスクは、エージェントの自律性が制御されなくなることです。明確な意思決定の権限、承認された制約、実行時の可視性、信頼できるログがないまま、エージェントは、ツールをハルシネーションで作り出したり、意味を誤解したまま実在のツールを呼び出したり、意図しない方法でツールを組み合わせたり、破損した戻り値に惑わされたりしかねません。

本ブログは「How can enterprises govern MCP connections at scale?」の抄訳版です。