AIエージェントを活用した連携が広がるエコシステムにおいて、アクセスの安全性を確保することは、「あれば望ましいもの」ではなく、前提条件です。AIエージェントと外部ツールをつなぐ標準ルールのModel Context Protocol（MCP：AIモデルと外部システムがやり取りする際の共通ルールを定めたプロトコル）」には現在、認証および認可の正式な仕組みを備えていますが、特に企業での導入に関する運用や適用方法については、引き続き最適化と整備が進められています。今後、企業での本格活用に向けた運用モデルやベストプラクティスが形成されていくと言えるでしょう。
本記事では、MCPの最新仕様をひも解きながら、その中で定義されている標準的な考え方を解説します。あわせて、企業で広く使われている「Keycloak」「Okta」「Microsoft Entra ID」といったエンタープライズ向けIdP（Identity Provider：社内外のユーザー認証を一元管理する基盤）を活用した参照アーキテクチャも紹介するとともに、個々のMCPサーバーを設定する際の運用上の負担についても触れていきます。最後に、これらが具体的にどう連携して動くのか、全体の流れを解説します。
なぜMCPにおいて「認証」が重要なのか
MCPは、AIエージェントにとって「万能なコンセント」のようなものです。家にあるコンセントが、冷蔵庫や掃除機など、どんな家電にも電気を供給できるように、MCPはAIエージェントがさまざまな業務ツールに接続して利用できるようにするための窓口となります。しかし、もし家中のコンセントがすべて同じ形で、「誰が差し込んだのか」「どれだけの電力を使っているか」を確認する方法がまったくないとしたらどうでしょうか。それは非常に危険な状態です。トースターが原因で家全体がショート してしまうかもしれませんし、最悪の場合、電力を盗む不正な機器が接続されるリスクすらあります。MCPにおける認証・認可の重要性は、まさにこの例えと同じです。
エージェントが自由につながれるからこそ、「誰が」「何に」「どこまでアクセスできるのか」を管理する仕組みがなければ、企業システムとしては成り立たない、という点が本質だといえます。
「認証（本人確認）」のないMCPは、先ほどの例でいえば「鍵のついていないコンセント」と同じです。 認証があることで、初めて正しい家電ーここでは「正当なエージェント」だけが、適切な条件のもとで接続できるようになります。これはセキュリティ（信頼）の土台そのものです。サーバー側が「正規の業務フローとして動いているエージェントなのか」、それとも「データを盗もうとしている不正なエージェントなのか」を判断するための仕組みとなります。この土台がなければ、どんなに高度なセキュリティ対策を重ねても意味がなくなってしまいます。
技術的な面では、MCPの認証には「OAuth 2.1」という仕組みが使われています。これは、スマートフォンのアプリやWebサービスなどで安全にアクセス権限を管理するために世界中で広く使われているフレームワークです。現在ではエージェントを含む業務フローにも適用されるようになっています。2025年6月版の最新仕様では、サーバー側が認証に関する信頼判断を既存のIdPに委ねることが義務付けられました。これは、「鍵を自作するのではなく、世界で最も実績のある仕組みを使いなさい」というメッセージだと言えます。
最新のMCP認証モデル
2025年6月のMCP仕様では、認証方式として「PKCE（Proof Key for Code Exchange：認可コードの不正利用を防ぐための仕組み）対応のOAuth 2.1認可コードフロー」が正式に採用されました。難しそうな用語ですが、ホテルの宿泊を例に考えると、その仕組みを簡単に理解することができます。まず、ホテルの部屋に入るには「予約システム」で予約を確認し、「ルームキー」を受け取る必要があります。この「予約システム」が、企業で使われているEntra IDやKeycloakといった「認証サーバー（IdP）」にあたります。そして受け取った「ルームキー」が、ツールを利用するための「アクセストークン」です。ルームキーは予約が正しく確認できた場合にのみ発行され、さらに予約した特定の部屋（リソース）以外では使うことができません。もし別の部屋に入ろうとしても、鍵は開かないーこの制御が重要なポイントです。
これをMCPに置き換えると、AIエージェント（宿泊客）がMCPサーバー（ホテルのフロント）に対して、ツール（ホテルの客室）を使いたいとリクエストを送る形になります。このとき、正しいトークン（ルームキー）が提示されない限り、サーバーはアクセスを許可しません。そのトークンは、信頼された認可サーバー（IdP）によって発行されたものである必要があります。
さらにMCPでは（Resource Indicators（RFC 8707)が必須とされており、トークンは特定のMCPサーバー専用として発行されます。つまり、あるサーバー向けに発行されたトークンを、別のサーバーで使い回すことはできません。これは、ホテルのルームキーが予約した部屋にしか使えないのと同じ考え方です。
さらに詳しく解説すると、MCPクライアント（AIエージェント）が鍵を持たずにサーバーを呼び出すと、サーバーは単に拒否するだけでなく「401 Unauthorized」というメッセージと共に「保護されたリソースメタデータ（PRM）」（この認証システムに行って、この種類の鍵をもらってきてくださいという案内）を返します。これには、どの認証サーバーを使えばよいか、そのツールを使うために必要な利用権限の範囲や求められるトークンの種類など、許可を得るための手順が記されています。これを受け取ったクライアントは、暗号技術を使った安全な手順（PKCE）で認証プロセスを始め、最終的にそのサーバー専用のアクセストークンを取得します。このトークンを添えて再度リクエストを送ることで、サーバー側で処理が行われるようになります。
このように「トークンを発行する役割をIdPが担い、MCPサーバーは受け取ったトークンを検証するだけ」という役割分担は、大規模な導入において非常に重要です。この構造によって、企業はすべてのMCPサーバーに独自の認証ロジックを組み込む必要がなくなります。すでにAPIや業務アプリで利用している中央集約型の認証基盤をそのまま活用できるため、運用負荷を抑えつつ、エンタープライズ規模での展開が可能になります。
OAuthの始まりとMCPに適している理由
OAuthがなぜMCPに適しているのかを理解するには、その成り立ちを知ることが一番の近道です。OAuthが誕生した2007年、ある切実な課題から生まれました。それは、「あるサービスが、別のサービス上のユーザーデータにアクセスする際、パスワードを渡さずに権限だけを付与するにはどうすればよいか」という課題です。きっかけはTwitterと、当時存在していたMa.gnoliaという写真共有サイトの連携でした。当時、外部アプリからTwitterに写真を投稿するには、そのアプリに直接Twitterのパスワードを教える必要があり、これが大きなセキュリティリスクとなっていました。
そこで生まれたのが、「パスワード（認証情報）」を共有する代わりに、特定の操作だけを許可する「トークン（利用許可証）」を発行するという仕組みです。このトークンには、「できることの範囲（スコープ）」が決められており、必要なくなればユーザーはいつでもその権限を「取り消す」ことができます。その後、OAuthはGoogleのAPIから銀行システムに至るまで、世界中のあらゆる場所で使われる委任型アクセスの業界標準となりました。現在では「OAuth 2.0」が主流となり、さらに最新の「OAuth 2.1」では、さらに安全性を高めるためにPKCEが標準装備されています。
このOAuthの仕組みは、MCPの設計思想と驚くほど一致しています。。そもそもMCPは、AIエージェントがユーザーや企業に代わってツールやAPIを呼び出すことを前提としています。まさにそれは、OAuthが最初から想定していたユースケースそのものです。かつてOAuthがアプリ間でパスワードを使いまわす危険を防いだように、MCPでもエージェントがツールを利用する際にキュリティの壁を越えないように守る必要があります。OAuthのトークンを使えば、MCPサーバーに対して「期限内に、必要な範囲だけ」の権限を、履歴が残る形（追跡可能な形）で安全に与えることができます。そして、IdPを活用することで、認証やポリシー管理を中央集約的にコントロールすることが可能になります。つまりOAuthは、MCPに後付けで採用された技術ではありません。「代理で操作する」という前提を、安全に成立させるための仕組みとして、最初から極めて相性のよい基盤だといえるのです。
エンタープライズIdPとMCPの連携
ここで一度、全体像を「入国管理のある都市」としてイメージしてみましょう。MCPサーバーは、機密性の高いツールが集まった建物です。IdPは中央集権型のパスポート発行機関であり、たとえば Keycloak、Okta、Microsoft Entra ID がその役割を担います。AIエージェントは、建物に入って仕事をする「市民」だと考えてください。正しいパスポートと、その建物に入るための「入国許可（ビザ）」がなければ、中に入ることはできません。
これを技術的に見ると、次のような構成になります。企業はまず、自社のIdPをOAuthの認可サーバーとして設定します。これにより、IdPは「どのエージェント（MCPクライアント）が存在するのか」と「どのMCPサーバーが保護対象のリソースなのか」を把握するようになります。
それぞれのMCPサーバーは、Resource Server（保護されたリソース）として登録され、固有の識別子（audience）と、許可される操作内容を表す権限範囲を持ちます。つまり、どのサーバーに対して、どこまでの操作を認めるのかが、あらかじめ定義されている状態です。
エージェントがツールを呼び出そうとすると、MCPサーバーはすぐに処理を受け付けるのではなく、PRM（Protected Resource Metadata）を返してIdPを案内します。エージェントはそれを受け取り、OAuth 2.1の認可コードフロー（PKCE付き）を実行して、必要な権限を持つトークンを取得します。そのトークンを添えて再度リクエストを送ることで、初めて処理が進みます。
MCPサーバー側では、受け取ったトークンについて、署名が正しいか、対象のサーバー向けに発行されたものか、許可された操作範囲に収まっているか、有効期限が切れていないかといった点を検証します。これらすべてが満たされていれば、リクエストは正当なものとして受け入れられます。
この仕組みは、エンタープライズITで長年培われてきたベストプラクティスと完全に一致しています。
認証基盤は中央で管理し、信頼は委任し、アクセス権限は必要最小限のトークンで制御する。
MCPがエンタープライズIdPとの連携を前提にしているのは、エージェント活用を一時的な実験で終わらせず、企業システムとして安全に運用するための、極めて現実的な選択だといえるでしょう。
すべてのMCPサーバーを個別に設定するという課題
この状況は空港に例えると分かりやすくなります。空港に乗り入れる航空会社が、それぞれ独自にパスポートコントロールを設置しているわけではありません。入国審査や税関は空港として一元的に提供されているからこそ、運用が成り立っています。もし、航空会社ごとに異なる審査カウンターやルールが存在したら、利用者は混乱し、セキュリティ水準もばらつき、全体の仕組みはすぐに破綻してしまうでしょう。
MCPも、これと非常によく似た課題を抱えています。現在の仕様では、認証情報を持たないクライアント（AIエージェント）がアクセスした際、すべてのMCPサーバーがPRM（Protected Resource Metadata）を返すことが求められています。そのPRMには、利用すべき認可サーバー、必要な権限の範囲、対応するトークン形式といった情報を正確に含めなければなりません。つまり、各MCPサーバーが自分自身のセキュリティポリシーを理解し、それを正しく外部に伝える設定を持つ必要がある、ということです。
この設計は企業環境では2つの大きな問題を引き起こします。1つ目は、運用負荷が非常に高い点です。既存のAPIやツールをMCPサーバーとしてラップしたものが何百と存在するような企業では、それぞれに対して認証メタデータを設定し、テストし、継続的に保守するのは現実的とはいえません。設定ミスや仕様変更への追従だけでも、大きなコストになります。2つ目に、信頼性の問題があります。すべてのMCPサーバー実装が最新の認証仕様に対応しているとは限りませんし、対応していたとしても、設定のばらつきによって運用ルールに抜け漏れが生じる可能性があります。セキュリティは常に「最も弱い部分」が突破口になります。たった一つ設定が甘いサーバーが、全体の侵入口になってしまうリスクがあるのです。
この課題に対する答えは、負担を各MCPサーバーに押し付けることではありません。むしろ、認証をプラットフォーム層に集約し、ゲートウェイとして機能させることが現実的な解決策となります。そのようなプラットフォームは、エージェントとMCPサーバーの間に位置し、未認証のリクエストを受け止め、OAuthフローを処理し、正しいトークンを付与したうえでバックエンドのMCPサーバーにリクエストを転送します。
この構成であれば、エージェント側から見た利用体験はシンプルなままです。一方、企業側から見れば、ポリシーは一貫して適用され、ログや監査も集約され、各サーバーの開発チームが認証フローの専門家になる必要もなくなります。この考え方は、REST APIやgRPCでAPIゲートウェイやサービスメッシュがセキュリティを集中管理してきた流れと、まったく同じだといえるでしょう。
具体例：営業データアシスタントのケース
Acme社が、営業チームを支援するために、社内の安全なデータベースタを要約する「AIアシスタント」を開発したとします。このデータベースはSalesDataMCPというMCPサーバーの背後に配置されており、会社全体では認証基盤としてKeycloakを利用しています。
アシスタントが起動すると、最初に SalesDataMCP に対して generate_summary を呼び出そうとします。しかし、この時点では有効な認証情報を持っていないため、サーバーはリクエストを拒否し、PRM（Protected Resource Metadata）を返します。その中には、「認証はKeycloakを使う必要がある」という情報が含まれています。これを受け取ったAIエージェントは、「このリクエストが途中で盗み見されたり、なりすましに使われないこと」を証明するための一時的な確認情報を作成し、それを使ってKeycloakの認可処理へ進みます。
今回は人ではなくマシンエージェントのため、Keycloakはクライアント認証情報とPKCEを組み合わせた形でエージェントを認証し、認可コードを発行します。エージェントはそのコードとコードベリファイアをKeycloakのトークンエンドポイントに送信し、SalesDataMCP向けに発行されたアクセストークンを受け取ります。このトークンには、「sales-data.mcp.acme.com」を対象とし、営業データの参照や要約生成が許可されている、という利用範囲が明示されています。
トークンを取得したエージェントは、改めて SalesDataMCP を呼び出します。今度はHTTPヘッダーにBearerトークンを付与してリクエストを送信します。SalesDataMCP側では、Keycloakが公開している鍵を使ってトークンの署名を検証し、対象が自分自身であることを確認し、許可された操作範囲に収まっているか、有効期限が切れていないかをチェックします。すべて問題なければ、リクエストは正当なものとして処理され、アシスタントは営業サマリーを生成します。
この一連の流れの中で、トークンの発行履歴とツールの呼び出し履歴は、KeycloakとMCPサーバーの双方に記録されます。そのため、後から「誰が、いつ、どのデータにアクセスしたのか」を監査することも可能です。
外から見れば、アシスタントは何事もなかったかのように自然に動いているだけに見えます。しかし内部では、PKCEによる暗号学的な検証から、権限範囲の確認に至るまで、すべてのステップが積み重なっています。正しいエージェントが、正しい権限のもとでのみツールを呼び出せることを保証するための仕組みが、裏側で確実に機能しているのです。
MCPの今後の課題と期待
MCPがOAuthを採用したことは大きな前進ですが、企業利用の観点では、使用面で今後さらに整理が期待される部分も残されています。例えばクリスチャン・ポスタ氏や多くの専門家が指摘している通り、現在の仕様ではリソースサーバー（実際のツールやデータを提供し、リクエストを処理する側）と、認可サーバー（本人確認や利用権限の判断を行い、トークンを発行する側）の役割の境界がやや分かりにくく、実装が必要以上に複雑になる可能性があります。この役割分担をより明確にすることで相互運用性が向上し、企業環境への導入もよりスムーズになるでしょう。
IdPエンドポイントの発見方法の標準化も改善が期待される領域です。現在は、各MCPサーバーがPRMを返すことで認可サーバーの情報を伝える方式が採用されていますが、大規模な環境では、標準化されたメタデータディスカバリー（認証に必要な接続先やルールを、あらかじめ決められた場所から自動的に取得できる仕組み）を組み合わせることで、エージェントは個別設定をしなくても、利用先のMCPサーバーに応じて、正しい認証基盤や必要な権限を自動的に判断できるようになります。
さらに、Resource Indicatorsの扱いやトークンの権限範囲の定義、そして SPIFFE / SPIRE のようなマシン向け認証モデルについても、仕様としての要件を強化すべき段階に来ています。これにより、人間以外のエージェントも安全に認証できるようになり、トークンの不適切な利用を防ぐことが可能になります。
そして重要なのは、プラットフォーム側も仕様に準拠するだけでなく、より高いセキュリティ運用を実装していく必要がある点です。有効期間をあえて短く設定したトークンの利用を徹底し、スコープや実行時コンテキストを評価するポリシーエンジンの導入、エンタープライズ向けの条件付きアクセス制御との連携など、実運用を前提とした対策が求められます。
認証とは単に「鍵を付けること」ではありません。いつ、なぜ、どのような条件で鍵が開くのかというルール全体を設計・運用することこそが、本質だといえるでしょう。
おわりに
MCPが目指すのは、AIエージェントが企業のシステムと安全にやり取りするための「世界共通のインターフェース」になることです。その実現に欠かせない土台こそが「認証」の仕組みです。OAuth 2.1やPKCEといったすでに世界中で実績のある仕組みを採用したことで、MCPは高い安全性を実現しました。一方で、仕様面では今後さらに整理や強化が期待される部分もあり、企業側にも、それを現実の運用として定着させるための適切な運用管理が求められます。
もしこれらを適切に実装できれば、エージェントは明確な責任範囲のもとで正確に行動し、各種ツールやデータは強固なアイデンティティの境界で守られ、企業はセキュリティを犠牲にすることなくエージェント型AIを活用できる世界が実現します。MCPは接続のための共通基盤を提供し、OAuthは安全にアクセスを制御する仕組みを提供します。そしてゲートウェイは、すべての通信の流れを一貫したルールで管理する「入国審査」の役割を果たします。あとは、それらを信頼性と安全性を備えた形で連携させ、拡張可能な仕組みとして構築していくことが求められています。
BoomiがどのようにMCPを企業レベルで導入・活用しやすくしているか、その詳細についてはboomi.com/ja/mcpをご覧ください。
本記事はAIのサポートを受けて執筆されました。