MCPのセキュリティとは？企業利用で押さえたい権限・承認・接続境界

MCP で何が増え、どこが新しい境界になるのか

MCP は「AI が外部とつながる入口」を標準化するぶん、境界の置き方が重要になります

MCP のセキュリティを考えるうえで最初に押さえたいのは、MCP が単なる API 呼び出しの省力化ではないことです。Model Context Protocol の仕様では、ホスト、クライアント、サーバーが役割分担を持つ構造が明示されており、どこで接続を許可し、どこで承認し、どこでログを持つかが security model に直結します。つまり、道具が増えるというより、境界が増えると理解した方が実務に近いです。

特に企業利用では、MCP サーバーが外部 API や社内データへつながるため、AI が何に触れられるかの判断が、接続先ごとに必要になります。一般的な AI 利用ガイドラインだけでは、この接続境界の話まで落ちてきません。だからこそ、MCP を enterprise governance の話として扱う必要があります。

MCP の architecture 仕様では、ホストがクライアント接続やユーザー承認を統制する役割として描かれています。ここから分かるのは、MCP の安全性はサーバー単体ではなく、ホスト側でどれだけ承認と境界を設計できるかに左右されるということです。サーバーが安全でも、ホストが何でもつなげてしまえば全体は安全になりません。

既存のプロンプトインジェクションの基礎が入力側の誘導リスクを扱うのに対し、この記事で主役にしたいのは接続後にどの道具と権限が使えるかです。MCP では、入力の安全性だけでなく、接続後に何が起き得るかを別に見ないといけません。

第三者サーバー、ローカルサーバー、HTTP transport は同じ重さで見ない方が安全です

MCP を一つの仕組みとしてひとまとめに見ると、確認項目がぼやけます。実務では、第三者サーバー、ローカルサーバー、HTTP transport を使う接続を分けた方が分かりやすくなります。第三者サーバーは権限とデータ送信先の審査が重くなり、ローカルサーバーは実行コマンドや端末権限が重くなり、HTTP transport は認証やセッションの扱いが重くなります。

MCP の authorization 仕様でも、HTTP ベース transport での認可と、stdio での扱いは分けて説明されています。つまり、どの transport を使うかで確認すべき論点が変わるのです。これを一律の「MCP 利用可否」だけで判断すると、見落としが増えます。

たとえば、第三者サーバーでは接続先 URL や OAuth スコープの広さが主な論点になりますが、ローカルサーバーでは端末のファイル権限や起動コマンド、永続プロセス化の有無が重くなります。同じ MCP という名前でも、管理すべき境界は実装形態ごとにかなり違うため、申請やレビューのテンプレートも分ける方が実務では楽になります。

企業利用で最初に確認すべき 3 つの境界

接続境界、権限境界、監査境界を分けて見ると整理しやすくなります

MCP を企業で使う時は、細かな仕様を覚える前に、接続境界、権限境界、監査境界の 3 つへ分けて考えると整理しやすくなります。接続境界はどこへつなぐか、権限境界は何をさせるか、監査境界は何が起きたかを誰が追えるかです。3 つを一つの設定で片付けようとすると、どれも中途半端になります。

人手承認を全部にかけるより、どこへ残すかを決めた方が運用しやすくなります

MCP セキュリティの議論でよくあるのは、「危ないなら全部人手承認にすべきだ」という考え方です。しかし、すべてのツール呼び出しへ同じ承認を入れると、現場はすぐに bypass を探し始めます。大切なのは、人手承認を残す場所を明示することです。外部送信、更新系、管理操作、高機密データ参照など、影響の大きいレーンへ重点的に残した方が回りやすくなります。

一方で、読取中心の低リスク操作まで同じ承認へ載せると、重要な承認の重みが薄れます。MCP ではツールごとの差が大きいため、権限の粒度を粗くしないことが実務上かなり重要です。道具ごとの危険度が違う以上、承認レーンも複数持つ方が自然です。

既存のAIエージェントの過剰権限でも触れている通り、危ないのは「AI がある」ことではなく、必要以上の権限が一つの通路へ集まることです。MCP では、その通路が接続設定として増えるため、承認の粒度が特に重要になります。

そのため、承認設計では「どのツールを呼んだか」だけでなく、「どのデータ分類に触れるか」「外部へ書き込むのか」「人手承認を飛ばせる抜け道がないか」まで含めて見た方が安全です。AI の使い勝手を落としすぎずに統制するには、低リスクの自動化と高リスクの手動承認を分ける設計が現実的です。

ここで効くのは、ツールの危険度を単純な名前で判断しないことです。たとえば「一覧表示」でも高機密データを横断できるなら影響は大きくなりますし、「更新」でも限定範囲の設定変更なら人手承認を簡略化できることがあります。データの重さ、外部送信の有無、復旧可能性の 3 つで見ると、承認レーンを決めやすくなります。

見落としやすい失敗例と運用上の落とし穴

一番危ないのは「安全なサーバーを選べば終わり」と思うことです

MCP セキュリティで避けたい誤解は、「有名なサーバーを選べば安全」という発想です。実際には、同じサーバーでも、どのスコープで接続したか、どのツールを許可したか、どのデータを流したかでリスクは変わります。接続先の評判だけでなく、自社がどの条件で使うかを見なければ判断できません。

MCP の security best practices では、confused deputy、SSRF、session hijack、local server compromise など、接続後に起きる具体的な失敗パターンが整理されています。ここから分かるのは、プロトコルの便利さが、そのまま新しい攻撃経路にもなるということです。便利さと危険性が同じ場所に出るため、運用ルールが必要になります。

特に第三者サーバーでは、「何を読めるか」よりも「何を代理で実行できるか」を重く見る方が安全です。ツールの一覧が整っていても、権限が広すぎれば、正規の道具を使った過剰操作が起きます。これはプロンプトインジェクションとは別のリスクです。

もう一つ見落としやすいのは、セッションやアクセストークンの保管場所です。第三者サーバー側に保持されるのか、ホスト側で短命に扱うのか、再認可の条件は何かを曖昧にすると、接続停止時にどこを無効化すべきかが分からなくなります。停止手順は導入後ではなく、接続前のレビューに入れておく方が安全です。

また、モデルへの入力と MCP ツール呼び出しを同じ監視粒度で見ない方が実務的です。入力の問題はプロンプトインジェクションや情報混入の管理に寄りますが、ツール呼び出しの問題は代理実行、過剰権限、外部送信に寄ります。どちらも AI 由来のリスクですが、検知指標と停止条件は別々に持つ方が効果的です。

ローカルサーバーは便利な反面、端末権限と実行コマンドの確認が重くなります

ローカル MCP サーバーは、端末上のファイルや開発環境とつなぎやすいため便利ですが、その分だけ実行コマンド、ファイルアクセス、環境変数、長期起動の論点が増えます。第三者の Web サービスと違い、端末権限に近いところで動くため、審査項目を分けないと危険です。

OWASP の MCP 関連ガイドでも、第三者サーバー利用時の認証、認可、クライアント sandbox、停止条件が強調されています。つまり、サーバーの種類ごとに確認項目を固定するのが実務的です。ローカルと第三者を同じチェックリストで済ませると、どちらかの論点が抜けやすくなります。

ローカルサーバーを扱う開発部門では、利便性のために一度許可した設定が長く残りやすい傾向があります。そこで、本番向けの MCP 接続と個人検証向けの接続を分け、本番へ持ち込める設定の条件を明確にしておくと、便利さを保ちながら持ち込みリスクを減らせます。

承認と監査を入れても、公開面の確認は別で残ります

MCP の承認と監査を整えたあとに忘れやすいのが、関連する管理画面や API の公開面です。AI が安全に接続していても、外から見える管理画面や古い API が残っていれば、別の入口から同じ業務系統へ近づける可能性があります。MCP の統制は inside-out、公開面の確認は outside-in と分けて扱う方が安全です。

MCP を企業運用へ載せるときの進め方

接続前チェックを固定し、例外審査の往復を減らします

MCP を本番運用へ載せる時に効くのは、個別判断のたびにゼロから考えることではなく、接続前チェックを固定することです。第三者サーバーなら認証方式、スコープ、データ送信先、ログ、停止手順、ローカルサーバーなら実行コマンド、権限、保管場所、更新方法を固定項目にすると、例外審査の往復が減ります。

また、ホスト側で接続レーンを分けると運用しやすくなります。開発検証向け、本番読取向け、本番更新向け、とレーンを分けると、同じ MCP でも承認強度を変えやすくなるからです。すべて同じ強度で扱うより、現場と管理側の両方が納得しやすくなります。

停止条件を先に決めておくと、本番利用の説明責任が取りやすくなります

MCP の導入時に見落としやすいのは、つなぎ方より止め方です。誰が停止を判断するのか、どのログを見れば止める根拠になるのか、関連する認証トークンや接続情報をどう失効させるのかを決めておくと、便利さを優先しながらも、戻れる運用を作りやすくなります。

既存のAIコーディングツールの企業導入でも触れた通り、導入判断では「何ができるか」より「何が起きたら止めるか」の方が重要な場面があります。MCP は特に接続先が増えるため、停止条件と承認条件をペアで持つ方が現実的です。

さらに、第三者サーバーを利用する場合は契約やレビューの論点も増えます。ベンダーが何をログに残すのか、どの範囲のデータを保持するのか、サーバーの更新で何が変わるのかを確認しておくと、技術審査と購買審査を別々にやり直す状態を減らせます。MCP の運用は、開発部門だけで閉じず、情シスやセキュリティとの役割分担を先に置く方が安定します。

監査の観点では、接続先一覧、許可済みスコープ、承認レーン、停止条件、インシデント時の連絡先を一つの runbook にまとめると、運用担当が変わっても判断品質をそろえやすくなります。MCP の議論は抽象化しやすい反面、誰が何を止めるかが曖昧になると急に危うくなります。運用文書まで含めて設計する方が、本番利用には向いています。

企業導入では、接続申請の入口を一本化しておくことも重要です。開発部門ごとに別々の申請ルートがあると、同じ第三者サーバーへ異なるスコープで重複接続が作られ、誰がどの接続を責任持っているのかが曖昧になります。利用目的、接続先、認証方式、データ分類、停止条件を同じ様式にそろえるだけでも、統制の質はかなり上がります。

さらに、接続を許可した後の棚卸し日も最初に決めておくと、導入だけ進んで見直しが追いつかない状態を避けやすくなります。MCP は便利な接続ほど残りやすいため、許可時点で次の見直し日を置く運用にすると、接続の増え方と権限の増え方を追いやすくなります。

こうした棚卸しまで含めて設計すると、MCP の導入は「AI を便利にする設定」ではなく、接続境界を管理できる業務基盤として扱いやすくなります。

結果として、承認、監査、停止条件が文書と運用に落ちているかどうかが、企業利用の分かれ目になります。

MCP の統制を整えた後に ASM診断 PRO を使うなら

MCP の権限、承認、監査を整えると、AI がどの道具へどうつながるかは見えやすくなります。一方で、外から見える管理画面、古い API、運用サブドメインが残っていないかは、MCP の設定だけでは分かりません。AI の接続統制と、外部公開面の確認は対象が違うからです。

ASM診断 PRO は MCP の権限管理を置き換える製品ではありませんが、AI 連携導入後に外から実際に見えている入口が残っていないかを確認する流れとは相性があります。MCP の審査を inside-out で整えたあとに、outside-in で公開面を見直すと、どこが別の初期侵入経路になるかを説明しやすくなります。

特に、第三者 MCP サーバーが社内システムや管理用 API とつながる場合は、接続そのものが安全でも、関連する管理ホストや古い公開導線が残っていれば安心できません。AI 側の統制が整ったあとも、外部から見える資産の棚卸しを別で閉じる方が全体として安全です。

もし今、MCP の企業利用を進めているなら、完了条件に「接続先の承認」「権限の分離」だけでなく、「関連する公開面の確認」も加えてください。MCP の境界と公開面の境界を両方見られるようになると、AI 連携の議論を設定だけで終わらせず、露出管理までつなげやすくなります。

よくある質問（FAQ）

MCP は便利なので、信頼できるサーバーだけ選べば十分ですか？

十分ではありません。同じサーバーでも、どの権限で接続するか、どのツールを許可するか、どのデータを流すかでリスクは変わります。

第三者サーバーとローカルサーバーは同じチェックで審査してよいですか？

同じにしない方が安全です。第三者サーバーは認証やデータ送信先、ローカルサーバーは実行コマンドや端末権限が重くなるため、確認項目を分けるべきです。

人手承認は多いほど安全ですか？

一律に増やすと、重要な承認の重みが薄れます。更新系、外部送信系、管理系など影響の大きいレーンへ重点的に残す方が実務では回ります。

MCP の監査ログがあれば、他の確認は不要ですか？

不要ではありません。監査ログは重要ですが、どの接続を許可するか、どこで停止するか、公開面が残っていないかは別に確認が必要です。

MCP の統制ができていれば、外部公開面の確認は不要ですか？

不要ではありません。AI 連携の統制と、外から見える管理画面や API の確認は別の管理なので、両方そろえた方が安全です。

まとめ

MCP のセキュリティで重要なのは、プロトコルの名前や仕組みを覚えることではなく、どこが新しい境界になるのかを先に決めることです。ホスト、クライアント、サーバー、外部ツールの間に境界が増えるため、接続先、権限、承認、監査を一つの設定で済ませようとすると、どれも中途半端になりやすくなります。接続境界、権限境界、監査境界の 3 つへ分けるだけでも、実務上の整理はかなり進みます。

また、第三者サーバー、ローカルサーバー、HTTP transport を同じ重さで扱わないことも重要です。第三者サーバーはスコープやデータ送信先、ローカルサーバーは実行コマンドや端末権限、HTTP transport は認証やセッションが重くなります。サーバーの評判だけで安全を判断するのではなく、自社がどの条件でどう使うかを見た方が、現実のリスクに近づきます。

さらに、MCP の承認や監査が整っても、外から見える管理画面や API の確認は別に残ります。AI の接続統制は inside-out、公開面の確認は outside-in の作業です。両方を完了条件へ入れると、AI 連携の議論を設定画面だけで終わらせず、実際の露出管理までつなげやすくなります。MCP を安全に使うとは、便利な道具を止めることではなく、境界と停止条件を説明できる状態にすることです。