Microsoft Entra ID を IdP としたまま Model Context Protocol（MCP）対応を進めようとすると、必ず話題になるのが Dynamic Client Registration（DCR）の有無です。本記事では、2025年末時点の公式情報を踏まえつつ、Entra ID に DCR がない前提で現実的な設計パターンを整理します。
Entra ID は Dynamic Client Registration をサポートしているか
先に結論から整理します。
- 現時点（2025年末）で、Microsoft Entra ID に RFC 7591 準拠の Dynamic Client Registration（DCR）機能はありません。
- 少なくとも公開情報の範囲では、DCR をネイティブ実装するロードマップも示されていません。
根拠となる主な情報源は次のとおりです。
- 2023 年の Microsoft Q&A「Does Azure AD supports Dynamic Client Registration?」で、「Azure AD は OpenID Connect Dynamic Client Registration をサポートしておらず、今後のサポート予定もない」と回答。
- 2025 年 8 月の Microsoft Q&A「Does EntraID has a plan to introduce Dynamic Client Registration Feature」で、「現在 DCR 機能はなく、現時点のロードマップにも含まれていない」と明言。
- Azure App Service の公式ドキュメント（MCP サーバーの認証設定）で、「Dynamic Client Registration をサポートしない IdP の代表例として Microsoft Entra ID が挙げられている」。
- Microsoft 公式の「Microsoft MCP Server for Enterprise」リポジトリでも、「Dynamic Client Registration (DCR) はサポートされない」と明記されている。
- サードパーティの検証記事でも、「Microsoft Entra ID は RFC 7591（DCR）を実装しておらず、今後も実装予定はない」と整理されています。
上記をまとめると、「Entra ID をそのまま OAuth / OIDC の認可サーバーとして使う限り、標準仕様通りの DCR エンドポイントは存在しない」と考えて差し支えありません。
時系列で見る Entra ID と DCR の位置づけ
| 時点 | 情報源 | 要約 |
|---|---|---|
| 2020 年 | Azure AD / ADFS 向け Q&A | RFC 7591（DCR）を ADFS / Azure AD に実装する予定はないと回答。 |
| 2023 年 7 月 | Q&A「Does Azure AD supports Dynamic Client Registration?」 | Azure AD は OIDC DCR をサポートしておらず、計画もないことを再度説明。 |
| 2025 年 8 月 | Q&A「Does EntraID has a plan to introduce Dynamic Client Registration Feature」 | Entra ID に DCR はなく、当面のロードマップにも含まれていないと公式回答。 |
| 2025 年 11 月 | Azure App Service MCP ドキュメント | 「多くの IdP は DCR をサポートしておらず、その中に Microsoft Entra ID も含まれる」と記載。 |
また、機能要望の公式ルートは Azure フィードバック ポータル に集約されており、プロダクトチーム（PM）がモニタリングしている旨が案内されています。
したがって、「Entra ID に DCR を前提とした MCP 認証基盤をそのまま乗せる」ことは現状不可能であり、何らかのワークアラウンドを前提に設計する必要があります。
そもそも Dynamic Client Registration（DCR）とは何か
DCR は、OAuth 2.0 / OpenID Connect の拡張仕様で、クライアント（アプリケーション）を API 経由で動的に登録・更新・削除するための標準プロトコルです。
- RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol – クライアント登録エンドポイントとリクエスト形式を定義。
- RFC 7592: Dynamic Client Registration Management – 登録済みクライアントの更新・削除 API を定義。
これにより、以下のようなシナリオが人手なしで回せるようになります。
- SaaS プラットフォームで、テナントごとに OAuth クライアントを自動発行
- モデル実行系（MCP クライアント）が初回接続時に、自身の client_id / redirect_uri を含むメタデータを送信して自動登録
- クライアントの秘密鍵・証明書を API からローテーション
こうした性質から、MCP のような「AI クライアントとツールサーバーがダイナミックにつながる世界」との相性が良く、MCP 認可仕様でも DCR が利用可能であることが強く意識されています。
MCP 認可仕様での DCR の立ち位置（最新ドラフト）
MCP 認可仕様は 2025 年にかけて大きく改訂され、クライアント登録の手段が 3 つ並列に定義される形になりました。
| 方式 | 概要 | MCP 仕様での扱い |
|---|---|---|
| 事前登録（Pre-registration） | 管理者が手動・スクリプトでクライアントを作成し、client_id 等をクライアントに配布する。 | MCP クライアントはサポートすべきオプションとして推奨。 |
| Client ID Metadata Document（CIMD） | client_id 自体を HTTPS URL とし、その URL でクライアントメタデータ JSON をホストする新しい方式。 | MCP クライアント／認可サーバーはSHOULD サポートとされる。 |
| Dynamic Client Registration（DCR） | RFC 7591 に基づき、/register エンドポイントなどからクライアントを API で登録。 | MAY サポート（後方互換と特定要件向け）。必須ではない。 |
重要なのは、最新版の MCP 認可仕様では「DCR は必須ではない」という点です。DCR はあくまで選択肢のひとつであり、
- 事前登録（固定クライアント）
- Client ID Metadata Document（CIMD）
のいずれか、もしくは両方を組み合わせることで、DCR を使わなくても MCP 準拠のエコシステムを構築できます。
つまり「最新仕様により DCR が絶対必須」というより、
- 一部の MCP クライアント実装（特に初期のもの）が DCR を前提にしている
- だが、仕様としては今後 CIMD + 事前登録を第一候補にし、DCR はバックアップ扱い
という状況に変わりつつある、という整理が実務的です。
Entra ID で取り得る 5 つの代替策（ワークアラウンド）
ここからは、「Entra ID に DCR はない」ことを前提に、どう MCP 認証を設計するかを見ていきます。
| アプローチ | キーワード | 主な対象シナリオ |
|---|---|---|
| 1. Graph API でアプリ登録を自動化 | スクリプト / CI/CD / 管理バックエンド | 自社サービスや限定されたパートナー向け MCP |
| 2. 固定クライアント（プリプロビジョニング） | 1 クライアント ID を共有 | 社内利用、少数のテナント |
| 3. DCR プロキシ / ファサード自前実装 | DCR 互換エンドポイント + Graph | DCR を必須とする MCP クライアントをどうしても動かしたい |
| 4. マルチテナント アプリ + 管理者同意 | admin consent / サービス プリンシパル | SaaS 的なマルチテナント MCP |
| 5. DCR 対応 IdP を手前に立てる | Auth0 / Okta / Ping / tsidp 等 | Entra だけでは要件を満たせない場合 |
1. Microsoft Graph API によるアプリ登録の自動化
もっとも「王道で地味」だが現実的なのが、Entra ID のアプリ登録を Microsoft Graph API で自動化するパターンです。Microsoft Graph では次の API でアプリ登録を作成できます。
POST /applications– アプリ登録（アプリケーション オブジェクト）を作成POST /servicePrincipals– 必要に応じてサービス プリンシパルを作成POST /servicePrincipals/{id}/addKeyなど – シークレット・証明書の追加 / ローテーション
典型的なフロー例
1. 管理者用バックエンド（あるいは CI/CD）が、プラットフォーム側の API を受け付ける
2. バックエンドが Graph API に対して /applications を呼び出し、新しいアプリ登録を作成
3. 必要に応じて /servicePrincipals を作成（テナント内で使う SP）
4. アプリに必要な API パーミッションやリダイレクト URI を設定
5. 生成された client_id / クライアントシークレットを、MCP クライアントに安全に連携このときバックエンドには少なくとも Application.ReadWrite.All などの権限が必要になり、テナント全体に強い権限を持つことになります。
利点
- Entra ID の標準機能だけで完結する（追加製品が不要）
- Graph の公式サポート範囲に収まるため、将来の互換性も比較的高い
- 「セルフサービス・セルフオンボーディング」フローを、UI + バックエンド API として自由にデザインできる
注意点
- バックエンドに強力な権限を与えるため、厳格な RBAC / 承認フロー / 監査ログ設計が必須
- アプリと SP の削除、シークレット有効期限管理など、ライフサイクル管理も自前で実装する必要がある
- MCP クライアント側から見ると「ただの事前登録」であり、DCR 仕様とは別物（→ 後述の DCR プロキシと組み合わせることで DCR 互換にできる）
2. 固定クライアント（プリプロビジョニング）方式
次にシンプルなのが、クライアント ID をあらかじめ 1～数個だけ発行し、すべての MCP クライアントで共有する方式です。
- Entra ID 上で 1 つのマルチテナント アプリ（あるいはシングルテナント）を作成
client_idと必要に応じてclient_secretを MCP クライアントに組み込む、もしくは設定ファイルで配布- テナントごとの差別化はスコープ・ロール・リソース URI 側で実施
利点
- 実装がもっとも単純で、追加のバックエンドや DCR プロキシが不要
- 社内利用や限られたパートナー向けなど、「クライアント数が少なく、信頼関係がある」環境では十分実用的
欠点
- 大規模マルチテナント SaaS では、クライアント単位での隔離が弱くなる
- 1 つの client_id に多くの権限が集約されるため、「Confused Deputy（権限の取り違え）」リスクや監査の粒度が粗くなりがち
- MCP の「クライアントごとのメタデータ」を細かく扱いにくい
ただし、MCP 認可仕様自体も「事前登録クライアント」は正式なオプションとして定義しており、特に社内向け MCP サーバーでは、この方式がもっとも現実的な落としどころになるケースが多いでしょう。
3. DCR プロキシ / ファサードを自前実装する
「どうしても MCP クライアント側は DCR を前提に作られている」「仕様的にも DCR を使いたい」という場合の王道路線が、DCR 互換エンドポイントを自社で実装し、裏側で Graph API を呼び出すプロキシ / ファサード方式です。
実際、Mulesoft や IBM、Tailscale などが提供するソリューションは、根本的にはこのパターンを採用しています。
基本アイデア
MCP クライアント
↓ (RFC 7591 に従う /register への POST)
DCR プロキシ（自社実装）
↓ (Microsoft Graph /applications, /servicePrincipals 等)
Microsoft Entra IDDCR プロキシ側では以下を実装します。
POST /register– クライアント登録リクエストを受け取り、Graph でアプリ登録を作成GET/PUT/DELETE /register/{client_id}– クライアント情報の参照・更新・削除（必要な範囲で）- クライアントに返すレスポンスは RFC 7591 / 7592 に準拠させる
設計上のポイント
| 観点 | 考慮事項 |
|---|---|
| 認可・レート制御 | DCR プロキシに誰でも登録できるようにすると「アプリ乱立」「権限のスパム登録」につながる。呼び出し元の認証（API キー / mTLS / IP 制限など）とスロットリングが必須。 |
| アプリライフサイクル | 未使用アプリの整理・削除タイミング、client_secret / 証明書のローテーション、テナントあたりの上限などをルール化して自動化する。 |
| 監査・可観測性 | 「誰が・いつ・どの MCP クライアントに対応するアプリを作成 / 更新 / 削除したか」をログとして残し、SIEM などに連携できるようにしておく。 |
| 障害時の挙動 | Graph 側でエラーが出たときに、クライアントへどのようなエラーを返すか（RFC 7591 準拠のエラーコード）を明確にする。 |
実装コストはそれなりにかかりますが、クライアントから見ると「完全に標準 DCR に見える」のが最大のメリットです。GitHub 上には、同様のギャップを埋める .NET 実装のサンプルも公開されています。
4. マルチテナント アプリ + 管理者同意モデル
Entra ID の「マルチテナント アプリ + admin consent（管理者同意）」モデルをうまく利用すると、DCR なしでも「半自動的なオンボーディング」を実現できるケースがあります。
- 1 つのマルチテナント アプリ登録を作成（例:
supportedAccountTypes = Any organizational directory） - 各テナントの管理者が、専用の URL からサインインして admin consent を実行
- これにより各テナントにサービス プリンシパルが自動作成され、必要な Graph などの権限が付与される
MCP の観点では、
- client_id は全テナントで共通
- テナントごとの差別化は「サインインしているユーザー」と「テナント ID」で行う
という形になります。Microsoft の Enterprise MCP Server for Enterprise も、この管理者同意モデルを前提に、PowerShell コマンドで MCP クライアントに対するスコープを登録する仕組みになっています。
この方式が向いているケース
- 「SaaS ベンダー（自社）」 vs 「導入企業（多数テナント）」という関係で、すべての導入企業が同じ MCP クライアントを使う
- テナントごとに別 client_id を持つ必要はなく、「どのテナントからのアクセスか」が分かれば十分
向いていないケース
- MCP クライアントごとに厳密にクライアントを分離したい（例: 監査上、クライアント単位で ID を分ける必要がある）
- 「クライアントの登録・削除」を API ベースで完全自動化したい
5. DCR 対応の外部 IdP を併用する
最後の手段として、DCR に対応した外部 IdP を Entra ID の「前段」に置く構成があります。
- Auth0 / Okta / PingFederate / Keycloak など、DCR を実装している IdP に MCP クライアントが接続
- その IdP と Entra ID を OIDC / SAML / Federation で接続し、最終的には Entra ID のユーザーが認証される
- あるいは Tailscale tsidp や Duende IdentityServer など、「DCR ゲートウェイ」として機能するプロダクトを利用する
利点
- Entra ID を直接変えずに、DCR や RFC 8707 など MCP が要求するモダン OAuth 機能を揃えやすい
- 一部プロダクトは MCP 用のテンプレートやコンソール UI を提供しており、実装負荷が低い
デメリット
- 構成が複雑になり、障害点も増える
- 外部ベンダーへのロックイン・コスト増を慎重に検討する必要
- 監査・コンプライアンス的に「認可サーバーが複数になる」ことへの説明が必要になる場合がある
実装・運用時に押さえておきたいポイント
権限と監査（Graph 経由の自動登録）
Graph API でアプリ登録を操作するバックエンドは、しばしば Application.ReadWrite.All や Directory.ReadWrite.All に近い、非常に強力な権限を持ちます。
- 最小権限設計 – 必要な API のみに限定し、管理者権限を持つアカウントを極力減らす
- 承認ワークフロー – 新規クライアント作成や高権限スコープの付与時には、人の承認（あるいは二段階承認）を挟む
- 監査ログ・アラート – 「短時間に大量のアプリ登録」「高権限スコープの不自然な追加」などを検知する仕組みを用意する
ライフサイクル管理
Entra ID 側では、クライアントシークレットや証明書の更新を Graph API 経由で自動化できますが、次のような運用ルールがないとすぐ破綻します。
- 有効期限が近いシークレットを検出し、自動ローテーションするジョブ（＋通知）
- 一定期間トラフィックのない MCP クライアントは、自動的に無効化 / 削除する
- アプリ登録・サービス プリンシパルの命名規則とタグ付け（例:
mcp-<tenant>-<env>-<client>）
仕様との整合性（MCP 側要件の再確認）
MCP 認可仕様は、最新のドラフトでは次のように整理されています。
- クライアント登録は「事前登録」「Client ID Metadata Document」「DCR」のいずれかでよい
- DCR は MAY（オプション）であり、必須ではない
- むしろ Client ID Metadata Document が第一候補になりつつある
したがって、「自分たちがサポートしたい MCP クライアントが、本当に DCR を必須としているのか」を改めて確認することが重要です。
- VS Code の MCP クライアントのように、静的クライアント ID への対応が進んでいるものもあります。
- 逆に、Claude や一部のプラットフォームは依然として DCR を前提としているため、プロキシや外部 IdP が事実上必須になる場合があります。
セキュリティ基準（DCR プロキシ / CIMD を導入する場合）
DCR あるいは CIMD（Client ID Metadata Document）を扱うサーバー側では、次のような攻撃ベクトルに注意が必要と指摘されています。
- 大量のクライアント登録によるリソース枯渇（DoS）
- 悪意あるクライアントによる無制限なスコープ要求
- CIMD で指定された URL への SSRF（サーバーサイドリクエストフォージェリ）
- localhost や社内 IP 範囲を悪用したリダイレクト URI 登録
これらを踏まえ、
- 登録可能なリダイレクト URI のパターンをホワイトリスト化
- 特定ドメイン（例: 自社管理ドメイン）以外の CIMD URL を拒否
- ユーザーあたり / テナントあたりのクライアント数上限を設ける
といった防御策を検討する必要があります。
ケース別：どのアプローチを選ぶべきか
| ユースケース | 規模・特徴 | おすすめ構成 |
|---|---|---|
| 社内向け MCP サーバー | クライアントは社内数十台程度。テナントは 1 つ。 | 固定クライアント（プリプロビジョニング）＋必要なら Graph による登録自動化。 |
| 大企業グループ内の複数テナント | テナント数は多いが、グループ内で統制された環境。 | マルチテナント アプリ + 管理者同意モデル。必要に応じて Graph で権限を自動付与。 |
| 外部顧客向け SaaS + MCP | 不特定多数の顧客テナント。セルフオンボーディングを重視。 | Graph でのアプリ登録自動化 ＋ DCR プロキシ実装、または DCR 対応 IdP を前段に置く構成。 |
| DCR 必須の MCP クライアントと連携 | クライアント側を改修できない。 | Entra ID の前に DCR プロキシを立てるか、DCR 対応の外部 IdP とのフェデレーションを検討。 |
次に取るべき現実的なアクション
- 要件の粒度を確定する
・「本当に DCR（RFC 7591）が MUST なのか、あくまで SHOULD / BEST なのか」を整理します。
・MCP クライアントごとに「固定クライアント ID で動作可能か」「CIMD に対応しているか」を棚卸ししましょう。 - PoC で Graph ベースの登録フローを検証
・小規模なテストテナントで、Graph を用いたアプリ登録 → 管理者同意 → シークレットローテーション → 削除までを一通り自動化してみます。 - DCR プロキシ / 外部 IdP 案を比較検討
・将来の MCP クライアント拡大を見据えて、「自前 DCR プロキシ」と「DCR 対応 IdP（商用 or OSS）」のトレードオフを評価します。
・既に Anypoint Platform や IBM MCP Gateway、tsidp などの事例があるため、それらのアーキテクチャを参考にすると設計のヒントになります。 - 公式フィードバックの登録
・自社ユースケースの規模（テナント数・クライアント数・想定ユーザー数）と、DCR 非対応がビジネスに与える影響を整理し、Azure フィードバック ポータル経由で要望を投げておくことを推奨します。
まとめ
- 2025 年末時点で、Microsoft Entra ID は RFC 7591 準拠の Dynamic Client Registration をネイティブにはサポートしておらず、ロードマップにも掲載されていません。
- 一方、MCP 認可仕様の最新版では、クライアント登録は「事前登録」「Client ID Metadata Document」「DCR」の 3 方式のいずれかでよく、DCR は必須ではありません。
- 実務的には、Graph API によるアプリ登録の自動化、固定クライアント、DCR プロキシ、マルチテナント アプリ + 管理者同意、DCR 対応外部 IdP の併用の 5 パターンを組み合わせることで、Entra ID を中核にしたまま MCP 要件に近づけることができます。
- どのアプローチを選ぶかは、「クライアント数・テナント数」「社内 / SaaS」「セキュリティ・監査要件」「運用チームのスキルセット」といった軸で決まります。
- いずれにしても、権限管理・監査・ライフサイクル管理の設計を先に固めることが、後戻りを減らす最大のポイントになります。
Entra ID に DCR がないこと自体は「仕様上の致命傷」ではありません。むしろ、MCP と最新 OAuth エコシステムの考え方（CIMD や RFC 9728 など）を取り入れながら、自社のガバナンスに合ったクライアント登録モデルをどう設計するかが、これからの ID 基盤アーキテクトに求められる視点と言えるでしょう。
コメント