トップ > AIエージェント > MCP × OAuth、結局どうすればいい？― 取りうる選択肢と過渡期における落とし穴

MCP × OAuth、結局どうすればいい？― 取りうる選択肢と過渡期における落とし穴

AIエージェント AI活用 社内システム 認証・認可 生成AI MCP
記事タイトルとURLをコピーする

はじめに

「自社でMCPサーバーを立てて、自社のIdPで認証したユーザーにのみ接続させたいけど、どうすればいいかわからない」という相談を受けたことがあります。 この相談を受けて、案外、説明が難しいなということに改めて思い至りました。

そもそも認証認可にはどういう選択肢がありえて、有力な選択肢であるOAuthにはMCPに関連してどのようなオプション・拡張機能があって、インテグレーションを想定するクライアントツールやIdP次第で何が使えるのか/使えないのか・・・etc。

こういった話を一気通貫で筋道立てて説明をしてくれている既成の資料・ブログ記事があまり見当たらなかったからです。

本記事はそのような全体の見取り図を自分なりに整理した結果を記したものとなります。

特に多くの現場で業務効率化の主要ツールになっている「既成のIDE経由で利用するCoding Agentツール・Desktop型のチャットツール」、言い換えれば「人が操作に介在するツールの中でも、非Webアプリ型の既成ツール」に限って少し事情が込み入っています。

そのため、特にそれらがクライアントの場合の注意事項を少し多めに書きました。

だいぶ長めの記事になってしまったので、手っ取り早く結論を知りたい方は以下目次のうち「9.まとめ」にいきなり飛んでいただき、納得のいかない箇所・詳細を知りたい箇所について適宜関連しそうな章に立ち入るような読み方をしていただくことをおすすめします。

MCPの歩みを振り返る

本題に入る前に、MCPの登場からこれまでの歩みを簡単に概観したいと思います。

2024年11月にAnthropicがModel Context Protocol（MCP）を発表してから約1年半。

MCPの普及は目覚ましい勢いで進み、OpenAI・Google DeepMind・Microsoftといった主要プレイヤーもMCPの採用を進め、Python/TypeScript SDKの月間ダウンロード数は約9,700万回に達しています。

2025年12月にはAnthropicがMCPをLinux Foundation傘下のAgentic AI Foundationに寄贈するに至りました*1。

「生成AIソリューションのために外部接続を円滑化するためのプロトコル」は、他にも種類はあるものの、それらと比較しても一定の地位を築いたといっても良さそうな状況に見えます。

トランスポート層においても状況は大きく変わりました。当初はローカルプロセスとの通信を担うstdio式の利用しか選択肢にありませんでしたが、2025年3月のMCP仕様（2025-03-26）でStreamable HTTPトランスポートが導入され、リモートMCPサーバーの構築がプロトコルレベルで標準化されました。

これにより、MCPサーバー側のプログラムやSaaS・APIの操作に必要なクレデンシャルを各メンバーのローカル環境で個別に管理する必要がなくなり、MCPサーバーを組織で集中管理して複数のメンバーが共有・活用するための基盤が整ったと言えるでしょう。

クライアント側も多様化が進んでいます。

様々なクライアントがMCPをサポートするようになり、Claude Code・Kiro・Cursor・VS Codeなど、開発者が日常的に使うCoding Agent・IDEからの活用はもちろんのこと、非エンジニアがClaude DesktopやChatGPTといったDesktop型のツールでMCPと連携しつつ作業を行うことは徐々に当たり前のワークフローになりつつあります。

こうした普及が進む中で、次に求められていくのはMCPに関するワークロードのセキュア化であろうと考えています。

基幹系のシステムなど業務のコアになるようなシステムに対する接続・操作需要が高まるにつれて、MCPサーバーへのアクセスはフリーに行わせるのではなく何らかの形で制限することは当然として、サーバーの接続用のクレデンシャル管理を適切に行うことは重要な考慮事項になってくるでしょう。

また、クライアントの種別/ユーザーの属性に応じたきめ細かいアクセス制御を行いたいとか、モニタリングのレベルを高めたいといった需要も出てくるはずです。

生成AIソリューションとOAuth

OAuthの基本コンセプト

上述のような要件を満たす上でキーファクターになりうるのがOAuthです。 この節では、認証・認可の世界に馴染みの薄い読者のために、ごく簡潔にその概要を述べておきたいと思います。

OAuthは、あるサービスが保持するユーザーのリソースに対して、ユーザー自身のパスワードを共有することなく、第三者のアプリケーションにアクセス権を委譲するためのプロトコルです。

登場人物は主に以下の4者で構成されます。

  • ユーザー（リソースオーナー） ：保護されたリソースに関する利用権限を持つ者であり、後述のクライアントへのアクセス権の委譲を承認する人物です。MCPの文脈では、Claude CodeやKiroなどのツールを実際に操作する開発者がこれにあたります。
  • クライアント：ユーザーに代わってリソースサーバーにアクセスするアプリケーションです。MCPの文脈では、Claude CodeやKiroなどのCoding Agentがこれにあたります。
  • 認可サーバー：ユーザーを認証し、アクセストークンを発行するサーバーです。多くの場合、IdP（Auth0・Okta・Entra IDなど）がこの役割を果たします。
  • リソースサーバー：保護されたリソース（データやAPI）を提供するサーバーです。MCPの文脈ではMCPサーバーがこの役割を担います。

OAuthの基本フロー（Authorization Code Grant）の大まかな流れは以下の通りです

  • クライアントがそもそもアプリの操作権があるかどうか確かめるために認可サーバーで認証を行う
  • 認証が無事成功した場合、認可サーバーからクライアントに対して委譲する権限の内容について確認を求められるため、同意を行う
  • 認可サーバーはユーザーをリダイレクトさせることを通じて、認可コード（同意の証拠）をクライアントに届ける
  • クライアントはリソースサーバーへリクエストを行い、認可コードと引き換えにリソースサーバーに対するアクセストークンを得る
  • その後、クライアントはリソースサーバーに対してリクエストを行う
    • この際、利用するアクセストークンには、scopeという許可される操作の範囲を示す情報のほかに、emailやroleなどの個人の属性値を含めることができ、リソースサーバーはそれらの内容を参考に処理を制御できる

OAuthのごく簡潔なイメージ

OAuthが必要とされる理由

この方式はHTTPヘッダーにAPIキーなどの固定値のクレデンシャルを乗せてリクエストするような素朴な認証認可方式と比べると以下のような利点があります。

観点 OAuth (client credentials flowを除く) APIキー直接利用
ユーザー個別トークンの払い出し 認証・同意を経てユーザー単位のトークンをシステムが発行 手動発行・管理が必要
非エンジニアの利用ハードル IdPのWebUIで認証するだけでよい（鍵の管理不要・既存登録ユーザーを利用可） 安全な取得・保管を各ユーザーが行う必要がある
権限制御の粒度 scope により細かい付与を行いうる。
またトークン内容にユーザー毎の属性値を付与しうるのでそれらを用いた細かい処理制御も行える 		SaaSの仕様次第では全権限付与など粗目になる
クレデンシャルの有効期限・露出リスク アクセストークンは短命・スコープ限定で漏洩時の影響範囲が小さい APIキー漏洩は全権限・無期限の侵害につながるリスクがある
監査・ログの粒度 ユーザー×セッション単位でアクセス追跡が容易 複数人が同一キーを共有するケースがある
その場合キー単位のログになるため個人への追跡が困難になりやすい

上記はあくまでOAuthの有利な側面だけを取り上げたもので、APIキーによる認証認可も要件次第では立派な選択肢になり得ます。

例えば、チームや課等の限られたメンバーが利用するMCPサーバーであったり、プロトタイピング用のMCPサーバーであったりする場合は全くこのような認証認可で問題ないでしょう。

ただし、ある程度の規模感の組織において各利用者が多種多様なAPI・SaaS操作用のMCPにアクセスするためのクレデンシャルを、それぞれ逐一払い出して管理して利用するのは利便性の面からもセキュリティの面からも敬遠されるケースは往々にしてあるのではないでしょうか。

そのようなケースでは、非エンジニアも含むユーザーが慣れ親しんだWebUIによる認証で各ツールの接続・利用を開始できて、かつ意識せずともある程度セキュアにクレデンシャルを管理できるOAuthが選ばれる余地は大きいものがあります*2*3

AI Agent全盛時代に新たに起こり得るボトルネック

しかしMCPとの相性を考えた場合に、ユースケース次第では運用面で無視できなくなるであろう問題がOAuthには存在していました。

それはOAuthのワークロードを開始するにあたって、クライアントを認可サーバーに事前に登録して、client_id を取得・把握しておく必要が基本的にはあるという点です。

生成AIソリューション・MCPが流行するまでは、このことは大した問題ではありませんでした。

単純な話で、従来のクライアントといえばWebアプリケーションやモバイルアプリだったのですが、これらについて短期間の間に新規の連携・導入が発生する個数は限定的で、IdPの管理コンソールで逐次クライアントを手動登録する形でも管理可能な規模だったからです。

この状況はMCPの普及によって変わる可能性があります。なぜなら 「生産性のボトルネック」の所在が変わる可能性があるからです。

本来、MCPは各リソースサーバー（SaaS/API）ごとに個別のプログラム実装を強いていた「N対N」の接続問題を解決し、インターフェースを共通化することで「N対1」へと集約する画期的なソリューションでした。

MCPが解決する課題のイメージ

しかし、これはあくまで純粋な「通信規格」だけで考えた場合の話であり、認証認可（OAuth）の話を併せて考えた場合にはまた事情が変わってきます。 OAuthが要求する「事前のクライアント登録」という静的な仕組みは、MCPの持つ動的な拡張性とは少し折り合いが悪いのです。

具体的には、特定のクライアントが新しいMCPサーバーを利用しようとするたびに、その組み合わせごとに手動の登録作業が発生します。

MCPがインターフェースの壁を壊して接続を「N対1」に簡略化した一方で、OAuthを組み込もうと思うと登録作業に関する「N対N」問題が発生してしまうということですね。

MCPにOAuthを組み込もうと思った際に発生しうる問題のイメージ

生成AIによる開発効率の向上によって、エージェントやブラウザ拡張・CLIツール・社内向けWebアプリ等のクライアントが量産され、MCPサーバーの開発もナレッジが普及したことで同様に量産しやすくなってきています。

そして生成AIを組み込んだAgenticなツール・Agentツールに、MCPサーバーを組み込む手間自体は非常に軽いわけですから、1クライアントで複数個利用したりあれこれ試したりというハードルは低いですよね。

こうした「クライアントとMCPサーバーの組み合わせ」のパターンが増えやすくなっている現状を考えた場合、必須のクライアント登録が逐一手動でまごついて生産性が損なわれてしまうという事態が起こり得るという話になるのです*4。

以降はこのような課題を解決するために編み出されたOAuthの拡張機能の変遷の話をしていきます。

DCR（Dynamic Client Registration）について

DCRの概要

実は上述の課題は、MCPサーバーをリモートサーバー化する検討をしていた段階である程度事前に織り込まれていたことでした。 MCPの初期仕様（2025年3月版）の段階で用意された解決策がDCR（Dynamic Client Registration、RFC 7591）です。

DCRの考え方はシンプルで、クライアントが認可サーバーの登録エンドポイントに対してHTTP POSTでメタデータ（アプリ名、リダイレクトURI、grant typeなど）を送信すると、認可サーバーが動的にclient_idを発行して返すという仕組みです。

これにより、OAuthクライアントは事前に人間が管理コンソールで登録する必要なく、クライアント自身がセルフ登録できます。MCPの初期仕様ではこのDCRが必須のクライアント登録方式とされていました。

DCRで発生した問題

しかしながら、DCRについては実運用が進むにつれて以下のような問題が浮上しました。

  • セキュリティ上の問題: DCRの登録エンドポイントは誰でもクライアントを登録できてしまいます。悪意のあるクライアントが正規のクライアント名（例：「Cursor」「Claude Desktop」）を名乗って登録し、フィッシングに利用するリスクがありました。client_nameは自己申告であるため、サーバー側でクライアントの真正性を検証する手段が欠如していました。
  • スケーラビリティの問題: 登録されたクライアントの情報は認可サーバー側に永続的に保存されます。MCP環境のように大量のエフェメラルなクライアントが次々と登録される場合、認可サーバー上のクライアントデータベースが際限なく膨らみます。ライフサイクル管理（いつ再登録すべきか、古い登録をいつ削除すべきか）については明確なルールがなく、運用負荷が高くなります。

こうした問題の蓄積により、MCP仕様は次なるクライアント登録方式の模索を余儀なくされました。

CIMD（Client ID Metadata Documents）について

CIMDの概要と設計思想

2025年11月のMCP仕様アップデート（2025-11-25）で、DCRに代わるクライアント登録のデフォルトとして導入されたのがCIMD（Client ID Metadata Documents）です。CIMDはIETFで議論中のドラフト仕様に基づいており、MCP仕様ではSEP-991にて提案・採用されました。

CIMDの基本的な考え方は、「クライアントがサーバーに登録情報を送り込む」という従来の方式を逆転させ、「クライアントが自身のメタデータをURLで公開し、サーバーが必要なときに取りに行く」方式への転換です。具体的には以下のように動作します。

  1. MCPクライアントは、自身のメタデータ（クライアント名、リダイレクトURI、grant type、認証方式など）を記述したJSONドキュメントを、自身が管理するHTTPS URLに公開します。例：https://claude.ai/oauth/client.json
  2. そのURL自体がclient_idとして機能します。クライアントは認可リクエスト時にこのURLをclient_idパラメータとして送信します。
  3. 認可サーバーはそのURLからJSONドキュメントをフェッチし、メタデータを検証した上でOAuthフローを進行します。クライアント情報をサーバー側のデータベースに永続化する必要はありません

例えばClaude Codeの場合、2026年4月1日現在以下のようなJSONを公開しています

{
  "client_id": "https://claude.ai/oauth/claude-code-client-metadata",
  "client_name": "Claude Code",
  "client_uri": "https://claude.ai",
  "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

DCRとCIMDの比較

CIMDがDCRの問題点を解決する点を整理すると以下のようになります。

こう並べてみると、CIMDは（これ単体ではカバーしきれなそうな問題はあるとはいえ）なかなか筋が良さそうな機能なように思えますね。

比較項目 DCR CIMD
クライアントの真正性検証 client_nameが自己申告のため、正規クライアントを装った偽装やフィッシングのリスクがある。 メタデータのホストドメインとリダイレクトURIのオリジンを照合でき、ドメイン所有権に基づいた検証が可能。
サーバー側の状態管理 登録されたクライアント情報を認可サーバーのデータベースに永続的に保存する必要がある。 メタデータをURLからオンデマンドでフェッチするため、サーバー側での永続的なレコード保持が不要。
スケーラビリティ エフェメラル（一時的）なクライアントが増えるほどDBが肥大化し、ライフサイクル管理の負荷が高い。 大量のリサーチ・CLIインスタンスが存在しても、共通のメタデータURLを共有するだけで済むため効率的。
設計思想の転換 サーバー側の登録エンドポイントに情報を「登録」する。 クライアント側が情報を公開し、サーバーがそれを「参照」する（責務の反転）。

OAuthクライアントの事前登録についての再論

最新の拡張機能に追随する必要があるのかどうかを冷静に考える

ここまでDCRとCIMDという「不特定多数のクライアントを動的に扱う」ための仕組みを見てきましたが、一歩引いて考えると、全てのMCPサーバーがこうした動的登録メカニズムを必要とするわけではありません。

むしろ、必要なケースは以下のように限定的なのではないかと筆者としては考えています（よく考えればもう少しパターンはあるかもしれません）。

  • SaaS / パブリックAPI事業者として外部にMCPサーバーを公開する場合：自社サービスのMCPサーバーを広く第三者に開放する際、事前にすべてのクライアントを把握・登録することは不可能であるためこのようなメカニズムに頼りたくなるのは無理はないでしょう
  • 生成AIタスクフォース・ラボのような先進領域に関するR&D部署・組織：MCPクライアントとなりうる各種ツール・アプリ（各社のIDE拡張、CLIツール、AIエージェント等）を精力的に導入・試用・開発するような環境下では、生産性重視での採用はあり得るかもしれません

上述のケースに当てはまらない場合、特に自組織内に閉じた利用であれば、従来通りOAuthクライアントの事前登録方式で本来的には対応すべきケースが多々あると考えます*5。

  • 保護したいMCPサーバーが社内向けである
  • MCPサーバーを利用するクライアントツール（生成AIソリューション）のバリエーション・増加ペースが限定的である
    • 仮に利用するクライアントツール（生成AIソリューション）のバリエーションが限定できずとも、クライアント登録のフローを完全手動の状態からいくらか効率化して管理工数上許容できる内容にできれば、事前登録方式は有力な選択肢になるとは考えます
  • セキュリティポリシー上、オープンなクライアント登録を許容できない*6

CIMDのようなものはMCP向けの最新の拡張機能であるからといって採用が必須ではないということに留意しましょう。

MCPの公式ドキュメント上においても、ところどころでこの方式に留意した記述が見られます。*7

Coding AgentやIdPの実装状況の整理

以上に関する言及だけで議論をまとめられれば正直楽だったのですが、組織への実際の適用・展開を考えた場合、上述のオプション群に対して自組織のクライアントツールやIdPがどの程度対応しているか/していないかによって取りうる選択肢は変わってくることにも留意する必要があります。

実は、本来であればクライアントの事前登録方式を採用したりCIMDを採用したりしたいケースでも、過渡期の今日ではその他の手段を余儀なくされる可能性があり得る状況になっているのです。

自分たちがスクラッチで開発しているツールであれば改修するまでなのですが、現場の主力ツールは得てしてClaude CodeだったりChatGPTだったり既製品であるところに難しさがあります。

以降の節では具体的なIdPやクライアントツールの現況を通じてどのような注意点があるかを確認していきたいと思います。

なお、いずれも 2026年4月1日時点 の情報であることには留意してお読みいただければと思います（機能の進化が早い領域ですので、少し日にちが経つと記述が古くなってしまう可能性は大いにありえます）

IdPのMCP with OAuthに関するオプション対応状況

まず、IdPについて見ていきましょう。

DCRに関しては対応状況がまばらです。

  • そもそも機能を一切サポートしていない（ex.Microsoft Entra ID、Google Workspace、Amazon Cognito）
  • 独自仕様（DCRのフローに独自のAPIキーを要求する仕組みを採用している等）を採用しており標準的なDCRフローとの互換性が低く利用において工夫が必要（ex.Okta）
  • デフォルトでは無効であるほか、有効化した場合にテナント全体で機能が有効化されるため運用上留意が必要（ex.Auth0）

CIMDについても、メジャーなエンタープライズ向けIdPでは対応しているものはほぼなく、WorkOS AuthKitやScalekitといったごく一部の新興系のIdPに対応が限られる状況です。

もっとも、オープンなDCRエンドポイントは悪意あるクライアントの登録を許容するリスクがあり、エンタープライズ向けIdPが実装に慎重であるという可能性は多いにあります。CIMDについてもIETFドラフト段階であり、まだ標準として成熟していないと判断されている可能性はありこのような状況は致し方ない側面もあるのかもしれません。

ローカルクライアントツールのエフェメラルポート問題

また、従来型のクライアントの事前登録方式であれば、どのIdPでも万全に対応できるかというとそういうわけではありません。

ローカルで起動・利用される生成AIソリューション特有の問題を考慮する必要があります。

OAuthでは、クライアントアプリは「ユーザーの認証・同意結果を受け付けるインタフェース」を起動して結果を待ち受けることになっていますが、認可サーバーがユーザーのブラウザをリダイレクトする形で結果を届ける形になるため、そのインタフェースの待ち受けURLをredirect_uriと呼びます。

ローカルで起動するタイプのアプリの多くはlocalhostや127.0.0.1での待ち受けを行います（ex.http://localhost:51234/callback）。

アプリのつくり次第ではありますが、この際のポート番号が起動の都度変動するケースが往々にして発生します。

このような場合、RFCや0Auth2.1の想定上は、運用上のトラブルを防ぐためにlocalhostより127.0.0.1のほうが好ましいという議論はありつつも、どのようなポート番号でも認可サーバー・IdP側は許容すべきである（「MUST allow any port」）ということには一応なっています。

ただ、現実問題としてはいくつかのIdPが依然この規定をフォローしておらず、明示的にポート番号まで含めて事前設定・指定しなくてはいけない仕様になっている場合があります。

そのため、自社で利用しているIdPが「MUST allow any port」でのlocalhost・127.0.0.1へのリダイレクトを許可していない場合は、クライアントツール側でエフェメラルポートを固定する処置を講ぜざるをえない状況にあります。

なお、少し細かい話になるのですが、従来型のクライアントの事前登録方式に限らず、DCRやCIMDでもredirect_uriは使われる = 同じ問題が起きうることに注意が必要です*8*9。

Coding AgentのMCP with OAuthに関するオプション対応状況

次に上述のredirect_uriポートの話も含めて主要なCoding Agentツールについてみていきましょう。

こちらについては、自社内外で利用実績が多数ある三種について簡単な比較表を作成してみました*10。

機能 Claude Code Kiro Copilot(VSCode拡張)
DCR ✅ 対応 ✅ 対応 ✅ 対応
CIMD ✅ 対応 ❌ 未対応 ✅ 対応
clientの事前登録対応 ⚠️ 注意*11 ❌ 未対応*12 ✅ 対応*13
redirect_uriのポート固定 ✅ 対応 ✅ 対応 ✅ 対応(33418)

このように日進月歩のCoding Agentの世界においても各ツールの対応状況はまばらで「MCPの初期の推奨オプションだったDCRしかサポートしていない」とか「クライアント事前登録方式を想定していなかったり不備があったり」といったケースが十分にありえるのです。

FastMCPのOAuth Proxy / OIDC Proxy実装

以上の話を踏まえて考えた場合、自組織で利用しているクライアントツールの仕様（クライアントの事前登録方式を想定しているか、redirect_uriのエフェメラルポートを指定できるか）や、IdPの仕様（localhostをredirect_uriに指定した場合にいかなるポート番号も許容するような設定を少工数で行える仕様か）によっては、消極的にDCRやCIMDを検討せざるをえないケースが生じるということになります。

さらに、そのようなケースで、自社のIdPがDCRやCIMDにも対応していないというケースは残念ながら十分にあり得ます。

仮にそうしたケースに当てはまった場合はOAuthの採用を諦めなければならないかというと、そうとは限りません。

例えば、主要IdPのDCR・CIMD未対応を補うソリューションとして利用できるものの一例として、FastMCPが提供するOAuthProxy・OIDCProxyという機能があります

この機能は、MCPクライアントに対してはDCRおよびCIMD準拠のインターフェースを提示しつつ、バックエンドでは事前登録済みのOAuthクライアント情報を使用してIdPと通信する「翻訳レイヤー」として機能してくれるというものです。

例えば「クライアントの事前登録はできないもののDCRはサポートしているクライアントツールで、DCRをサポートしていないリソースサーバーを利用したOAuthのワークロードを処理する」ことが可能になるということですね。 （本当はオーソドックな事前登録でいいケースなのに、DCRやCIMDをむりくり使わなきゃいけないというのも変な話ですが・・・）

Proxy機能の概観図

この機能に関する詳細な解説・具体実装内容の紹介については、ワークアラウンドの一例をお示しするために本ブログの姉妹版的な位置付けの記事として近日中に公開したいと思います。

まとめ

本記事では、MCPサーバーにOAuthを組み込む際に関わってくる各種クライアント登録方式（事前登録・DCR・CIMD）の変遷と、クライアントツールやIdPの対応状況が生む現実的な制約について整理してきました。

最後に、これまでの話を踏まえた上で自組織での導入を検討する上での考え方の一例を示しておきたいと思います。

まずMCPにOAuthを組み込むことを考える際に、技術要素に何を採用するかの具体フローチャートは2026年4月1日時点では以下のような形になるのではないかと考えています。

技術要素の選択フローチャート

文章でもおさらいしていきましょう。

そもそもOAuthが必要かを判断する

以下のような事項にいくつか当てはまる場合は、オーバーエンジニアリングを避けるためにOAuth以外のより簡易的な手段でアクセス制御を済ますのは十分合理的と考えます。

  • 利用者の規模が少人数である場合
  • プロトタイピングやPoC段階にある場合
  • 利用者が全員エンジニアであり、クレデンシャルの安全な取り扱いを期待できる場合
  • MCPサーバーを通じて操作・参照するリソースの機密性が低い場合
  • MCPサーバーの処理が、ユーザーの属性やクライアントのスコープを重視せず、どのような主体に対しても一律である場合

逆に以下のいくつかの事項に該当する場合は、OAuthの導入を積極的に検討する価値があるといえるでしょう。

  • 利用者の人数がある程度の規模に達しており、各利用者へのクレデンシャルの個別払い出し・管理が現実的でない、あるいは煩雑である
  • 非エンジニアを含む利用者がMCPサーバーを利用する想定がある
  • ユーザー属性に応じたきめ細かいアクセス制御（スコープ制御やユーザー単位の権限管理）が求められる
  • 監査・コンプライアンスの観点から、ユーザー単位でのアクセスログの取得やトークンの即時失効といった運用要件がある
  • MCPサーバーが機密性の高いリソースにアクセスする

DCR・CIMDが本当に必要かを見極める

OAuthを導入した方がいいかもしれない、と考えた時に 最初に問うべきは「自組織のMCPサーバーに関して、不特定多数のクライアントからの動的な登録を受け入れる必要があるか」です。

この問いに対して「Yes」となるユースケースは、SaaS・パブリックAPI用のMCPサーバーを提供する場合など、そう多くないパターンに限られるでしょう。

「必要」と判断した場合：IdPのCIMD対応状況を確認する

動的なクライアント登録が必要だと判断した場合、現時点ではCIMDがMCP仕様上のデフォルトとなっています。

しかし本稿で述べたとおり、CIMDはIETFドラフト段階にあり、メジャーなIdP（Entra ID・Okta・Auth0・Amazon Cognito等）では対応が進んでいない状況です。

自社で従来利用しているIdPがCIMDに対応していないからといって、組織全体のIdPを切り替えるのは現実的ではないケースが多いかと思います。

その代わりに、対外公開用のMCPサーバーやR&D部署のsandbox環境向けにWorkOS AuthKitやScalekitのようなCIMD対応のIdPを別途導入し、既存のIdPとは棲み分けて運用する方針は検討に値するでしょう。

なお、新規実装を行う場合で、DCRのみを敢えて採用すべきケースはあまりないと考えますが、DCRしか採用していないクライアント（結構多いです）に対するフォールバックとして採用することは脚注7に記載した通り今日においてもあり得ます。

多くのユーザーに使ってほしいSaaS・API事業者の立場として、幅広いタイプのクライアントをケアするという意味で両方をケアする形で実装を行うことは考慮してもいいでしょう。

「不要」と判断した場合：事前登録方式の実現可能性を精査する

動的なクライアント登録が不要であれば、クライアントの事前登録方式が本命の選択肢となります。

ただし、本稿で述べてきたように、この方式を円滑に運用するためにはクライアントツール側とIdP側の双方について以下の点を確認する必要があります*14。

  • クライアントツールのredirect_uriがlocalhostなのか127.0.0.1なのかを確認してください。
  • クライアントツール側については、そのツールがOAuthのクライアント事前登録方式を前提としたフローに対応しているかを確認してください
    • IdP側が「localhostもしくは127.0.0.1をredirect_uriに指定した際にいかなるポート番号でも許容する設定」をサポートしていない場合は「redirect_uriのエフェメラルポートを固定する手段が提供されているか」も確認の対象となります
  • IdP側については、localhostもしくは127.0.0.1をredirect_uriに指定した際にいかなるポート番号でも許容するような仕様になっているかを確認してください

事前登録方式の条件が整わない場合

自組織で利用するクライアントツールやIdPの仕様上、クライアントの事前登録方式を採用するための条件が何らかの形で整っていないと判明した場合で、OAuthを是非とも組み込みたい場合にはFastMCPのOAuth Proxy / OIDC Proxy機能などを採用したMCP基盤を構築することでワークアラウンドとすることが考えられます。

なお、IdPと比べれば、Coding Agentツール・Desktop型の既成チャットツールの方が比較的修正・機能追加が早くなされる傾向にあります。

フローチャート上は表現していませんが、クライアントツール側の機能不足のみが問題なのであればissueを出すなどして改善を要望する・改善を待つ（あるいは機能が一通り揃っているツールを採用し直す）のも一つの選択肢かもしれません。

おわりに

「決定版」と言えるほどの出来栄えではありませんが、MCP × OAuthの導入にあたって現状を把握・導入方針を整理するための「叩き台」程度のものは作れたかなと思います。

多々記述が至らない点はあると思いますので、修正すべき点・不足点があれば、ぜひご意見をお寄せいただけると幸いです。

脚注

*1:https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation の記事を参照のこと

*2:紙幅の都合上、詳述はしませんが、OAuthにはclient credentials flowと呼ばれるフロー種別があります。OAuth × MCPの実装サンプルは（おそらくは準備のハードルが低い等の理由から） AWSがサンプルとして提示している実装をはじめとしてclient credentials flowに依ったものが多いです。

client credentials flowとは「人が介在しない『あらかじめ信頼されているシステム』同士での通信に使われることを前提にして色々端折った認証認可を行う方式」です。

この方式の場合、APIキーによる認証の場合と似て、サーバーアクセス用の一時トークンの要求に常時使える固定値のクレデンシャルをクライアント内で保持・利用する必要があります。

生成AI Agent・Botソリューションのようなものだけでなく、人が介在して操作するCoding AgentにおいてProxyのようなものを設定した上でこのclient credentials flowによりMCPサーバーへのリクエストに先だってトークンを取得して対MCPサーバーへのリクエストに用いるような実装をすることも可能です。

ただし、その場合APIキー方式と同様にサーバーアクセス用のクレデンシャルを自PCで何かしらの形で管理することになる可能性が高いことには留意してください。言い換えればクレデンシャルの運用面において上述の比較表における「APIキー直接利用」と似た課題が生じてくるということです

*3:APIキー式とOAuth式の中間解として、例えば以下のような方式もAWS環境では時折みらられます。

・MCPサーバー側ではリクエスト時にSigV4の署名(IAM認証)を求めるようにして
・クライアント側ではmcp-proxy-for-awsのようなものを利用してユーザーが意識せずとも必要とされる署名を行い
・署名用のクレデンシャルについては旧来のIAMアクセスキーではなくIAM Identity Centerに関連するProfileを用いて失効期限のあるSTSトークンを利用する

この方式の場合、リクエストを行ったユーザーの属性・クライアントのスコープは把握できません。従って大雑把に言えば、一定のセキュア性は保ちたいが、ユーザーごとの処理制御・分岐を必要としないユースケースに適していると言えそうです

*4:この新たなN対Nの解決手段の一つとして、Amazon Bedrock AgentCore Gateway のようなサービスを使って各3rd Partyが提供するMCPツールを単一ないしごく少数のエンドポイントで集約する、つまりはMCPサーバー数を減らすというアイデアがあります。

しかし、単純に1エンドポイントに多量のツールを集約しただけでは、そこにtools/listしただけで相当量のコンテキストをクライアント側が消費してしまいます。

この点に関して、AgentCore Gatewayが 必要なツールの情報だけを取得できるような機能を提供していることは注目に値する点です。ただ、気軽にユーザーが機能をいじりづらい既成ツールを使うことを考えた場合に、それらがこのような機能の活用を前提としていないフローであり参照するオプションもないものが現状はほとんどであることが歯がゆい点です。

もう1つのアプローチとしては、interceptorsのような機能を用いてクライアントのスコープやユーザーの属性（所属部署や職位等）に応じて必要最小限のツール群だけを参照できるようにするというアプローチも考えられます。この方法を用いるにあたっては今回のブログで取り上げているようなOAuth・JWTによる認証の採用が前提になります

*5:OAuthのクライアントの事前登録の手間は「ユースケース次第では」問題になると書きましたが、これは実は外部のMCPサーバー=それぞれ独自のIdPで保護されたMCPサーバーを複数利用することを念頭に置いたコメントでした。

OAuthの仕組み上、リソースサーバー（MCPサーバー）が複数あってもそれらが同じ組織の同一IdPで管理・保護されるものであれば、クライアントの登録作業はサーバーの個数に関わらずクライアントツール1つにつき1回で済む可能性があります

*6:DCRやCIMDを採用した時点で、組織内外の全てのクライアントに動的な登録を許すことになるわけではなく、送信元IP制限などの制限を施すことは可能です

*7:2026年4月1日時点の公式ドキュメントでは現状のすべてのクライアント登録オプションをサポートした場合のオプションの優先度として、第一は事前登録形式、その次点にCIMD・次々点にDCRをそれぞれ位置付けています(DCRはCIMDのフォールバック・多くのオプションをサポートしていないクライアントのフォローアップ用としての位置付けです)。

そして、第四として脚注13で記してあるようなGithub Copilotの方式のように「ユーザーにClientに関する情報の入力を促すフォールバック」を施すことを推奨しています。この第四の方式についても事前に登録したクライアント情報の入力を促す意図のものです

*8:自社のSaaS・APIを公開するためのMCP用のIdPを新規に選定する上では、単にCIMDをサポートしているか否かということだけではなく、このany port問題もフォローアップしているものも選んだ方が良いかもしれません。本記事執筆時点では悉皆調査ができていないのですが、少なくともWorkOS AuthKitについてはこのany port問題もフォローアップしています

*9:DCRについてはクライアントの実装次第ではあるのですが、仕様上はポートが変わるたびにクライアント情報を登録し直す実装をしうるので、any portが許容されない環境下でもCIMDはダメだがDCRならクリアできるという場合はあるかもしれません

*10:IdPの比較表についてはドキュメントだけでは判断できないところが大きい・各製品の検証環境をサクッと用意するということもしづらいのでご容赦いただければと思います

*11:機能としてはあるのですが、設定が無視される場合があるというissueが報告されています。筆者が認可サーバーをOneLoginにして検証した際は問題なく機能しましたが、特定ケースでうまく動かないような事象は起こりうるかもしれません

*12:issueは立っている状態です。このissue内容を見る限り現状でも仮にclient_idを「Q DEV CLI」の固定値で登録できるのであれば対応できるのかもしれませんが、OAuthクライアントのIDを自動払い出し以外のものにできるかどうかはIdPの仕様によりけりです

*13:対向のMCPがDCRやCIMDをサポートしていない場合に、フォールバックとしてclient_idの入力欄を提示してくれる方式です。

*14:別の箇所でも触れましたが、このことが専ら問題になるのは業務上重要なクライアントツールが「IDE経由で利用するCoding Agentツール・Desktop型の既成チャットツール」つまりは「人が操作に介在するツールの中でも、非Webアプリ型の既成ツール」である場合です。自作ソリューションであれば事前登録方式に適合するように開発・修正すればよいだけのことです

田斉 省吾 (記事一覧)

アプリケーションサービス部

2016年新卒入社。筆無精で入社以降一切ブログを書いてこなかったのですが、色々ありごく稀に書くことにしました（群馬から真心をこめてお届けします）