CIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年9月時点】

CIMD（Client ID Metadata Documents）は、OAuthクライアントが自分のメタデータをHTTPS上のJSONファイルとして公開し、そのURL自体を client_id として使う識別方式です。認可サーバーは認可リクエストを受け取った時点でそのURLを取得し、中身を検証してクライアントを識別します。事前登録も動的クライアント登録も要りません。2025年11月25日版のMCP（Model Context Protocol）仕様で既に第一候補の座を降りていた動的クライアント登録（DCR）は、2026年7月28日版で正式に非推奨となり、新規実装の第一選択がCIMDへ移りました。仕様本体はIETFのWG草案 draft-ietf-oauth-client-id-metadata-document-02（2026年7月6日発行）で、RFC化前の段階にあります。

まとめ：CIMDの要点と2026年7月28日仕様での位置づけ

CIMDは、クライアントが自分の素性をWeb上に置き、認可サーバーがその場で取りに行く方式です。置き場所がドメインである以上、ドメインの管理権がそのままクライアントの身元になります。

• client_idはHTTPS URL。JSONの client_id 値と取得URLが単純文字列比較で完全一致することが必須
• MCP 2026-07-28仕様でDCRは非推奨。CIMD非対応の認可サーバー向けの後方互換としてのみ残る
• 認可サーバーは200 OK以外をエラー扱いし、リダイレクトを自動追跡してはならない
• 共有シークレット前提の認証方式は使えない。機密クライアント化は private_key_jwt と jwks_uri で行う
• 読み取りサイズの推奨上限は5キロバイト。特殊用途IPアドレスへの取得はSSRF対策として禁止
• Keycloakは26.6以降で実験的機能として実装済み。--features=cimd で有効化する

以降では、URLの要件と検証手順、DCRとの使い分け、JSONの書き方、実装で事故になりやすい箇所、そしてKeycloakでの具体的な有効化手順を順に見ていきます。

CIMDの仕組み：client_idにHTTPS URLを使う識別方式

従来のOAuthでは、クライアントは認可サーバーごとに事前登録して client_id を発行してもらう必要がありました。CIMDはこの向きを反転させ、クライアント側がメタデータを公開し、認可サーバーが必要になった時点で取りに行きます。この発想自体は新しくありません。draft-02の謝辞は、IndieAuth・Solid-OIDC・OpenID Federationが同様の考え方を先に規定していたこと、特にSolid-OIDCの「参照可能なClient Identifier Document」に強く影響を受けたことを明記しています。Blueskyが動かすAT Protocolも、client_idを公開クライアントメタデータのURLとする同じ系譜の設計です（AT Protocol公式のOAuth仕様）。

Client Identifier URLの要件：https・パス必須・フラグメント禁止

draft-02の第3節は、client_id に使えるURL（Client Identifier URL）の条件を細かく定めています。httpsスキームが必須、userinfo部分は禁止、パス要素が必須、シングルドットとダブルドットのパス要素は禁止、フラグメントは禁止、クエリは非推奨、ポートは任意です。

特に注意が要るのが比較方法です。URLはRFC3986の単純文字列比較で照合するため、https://example.com/client と https://example.com:443/client は同一とみなされません。httpsの既定ポートであっても正規化されないので、ドキュメント内に書く値とクライアントが送る値は一文字単位で揃える必要があります。

短縮URLサービスも使えません。短縮URLはHTTPリダイレクトで動作しますが、認可サーバーはリダイレクトを自動追跡してはならないと決まっているためです。またパスを / だけにする書き方は非推奨とされています。ドメイン直下に配信すると既存コンテンツと衝突するためで、/oauth/client.json のように専用パスを切るのが実務上の既定解です。

認可サーバー側の取得手順：200 OK必須・リダイレクト追跡の禁止

認可サーバーは client_id がURL形式であることを検知したら、そのURLへHTTPS GETを投げてJSONを取得します。draft-02の第5節が定める処理は明確です。応答は200 OKでなければならず、それ以外のステータスはすべてエラーとして扱います。HTTPリダイレクトの自動追跡は禁止です。取得に失敗した場合、認可サーバーは認可リクエストを中止すべきとされています。

取得したメタデータのキャッシュは認められており、RFC9111のキャッシュヘッダーを尊重したうえで認可サーバー独自の上限や下限を設けることもできます。ただしエラー応答と、妥当でないドキュメントや形式の壊れたドキュメントはキャッシュしてはなりません。ここを緩めると、一時的な障害で壊れた内容を掴んだ認可サーバーが復旧後も古い値を使い続けます。

DCR・事前登録との違いと使い分けの判断基準

MCPが定義するクライアント登録方式は3つです。CIMDが「事前に関係がない相手同士」の既定手段、事前登録が「既に関係がある相手」の手段、DCRが後方互換のための手段という整理になっています。

3方式の比較：client_idの発行元・身元の裏づけ・MCPでの扱い

MCP仕様は、3方式すべてを実装したクライアントに優先順位まで示しています。手元に事前登録済みの情報があればそれを使い、無ければ認可サーバーメタデータの client_id_metadata_document_supported を見てCIMDを使い、それも無ければ registration_endpoint のあるDCRへ落とし、いずれも使えなければユーザーに情報の入力を促す、という順番です。

MCP 2026-07-28仕様でDCRが非推奨になった経緯

CIMDのMCPへの導入は、2025年7月17日に起票され同年11月14日にクローズされたSEP-991（URLベースのクライアント登録）が起点です。この提案が2025年11月25日版の仕様に入り、CIMDは認可サーバーとMCPクライアントの双方がSHOULDで対応する方式として登場しました。この時点ではDCRに非推奨の記載はありません。実際、2025-11-25版の認可仕様本文にdeprecatedの語は一度も出てきません。

変化は2026年7月28日版で起きました。クライアント登録のページにDCRの警告ブロックが追加され、「動的クライアント登録は非推奨です。新規実装はClient ID Metadata Documentsを使用してください」と明記されます。同日の公式ブログはさらに踏み込み、DCRは後方互換のために動き続けるが将来のバージョンで削除されると述べています。MCPは同じ更新で最低12か月の非推奨期間を定めた廃止ポリシーも導入したため、DCRを使い続ける既存実装が即座に壊れることはありません。それでも、いま新規に組むなら選択肢は実質CIMD一択です。MCPそのものの位置づけはMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説で整理しています。

メタデータドキュメントの記述項目と、MCPとIETFドラフトで食い違う必須項目

ここが実装で最初につまずく箇所です。「CIMDの必須項目」は参照している文書によって答えが違います。

最小構成のJSONと必須項目の差

IETFのdraft-02が必須と定めているのは client_id ひとつだけです。第4節は「Client ID Metadata Documentはclient_idプロパティを含まなければならず、その値はClient Identifier URLと一致し、かつ認可サーバーが取得に使ったURLとも一致しなければならない」と規定します。それ以外のプロパティはRFC7591のクライアントメタデータ登録簿にある値を使えるという定義で、個別の必須指定はありません。

一方、MCP 2026-07-28仕様は独自に上乗せしています。「メタデータドキュメントは少なくとも client_id、client_name、redirect_uris を含まなければならない」と書かれており、必須が3つに増えます。draft-02もこの上乗せ自体は想定しており、他の仕様が受け入れ条件を追加してよいと明記しています。

MCPクライアントとして配布するなら、MCP側の3項目を満たす次の形が最小構成です。MCP仕様が掲載している例そのもので、これをひな形にできます。

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

参照先のズレはドキュメント上の細かい話に見えて、実装では表面化します。MCP 2026-07-28仕様が規範として参照しているのはdraft-00ですが、IETF側の現行はdraft-02です。実際、Better Authが提供する @better-auth/cimd プラグインはdraft-02準拠で実装したうえで、MCP用に metadataProfile: "mcp-2026-07-28" という明示プロファイルを別に用意しています。MCPが要求する client_name と redirect_uris の必須化を、汎用のdraft-02クライアントには押し付けないための切り分けです。認可サーバーを作る側は「どの版のどのプロファイルに従って検証するか」を先に決めてください。

client_secretを置けない制約とprivate_key_jwtでの機密クライアント化

メタデータドキュメントは誰でも読めるURLに置かれます。したがって共有シークレットを事前に取り決める余地がなく、draft-02の第4.1節は3つの禁止を課しています。token_endpoint_auth_method に client_secret_post、client_secret_basic、client_secret_jwt をはじめとする対称鍵ベースの方式を含めてはならないこと。client_secret と client_secret_expires_at を使ってはならないこと。秘密鍵そのものを書いてはならず、jwks や jwks_uri で公開する公開鍵だけが許されることです。

では機密クライアントにできないかというと、そうではありません。公開鍵を載せて private_key_jwt を宣言すれば、そのクライアントは機密クライアントとして扱われます。

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "redirect_uris": ["https://app.example.com/callback"],
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://app.example.com/jwks.json"
}

この宣言を受けた認可サーバーは、RFC7523の第2.2節に従い、メタデータドキュメントから取得した鍵でクライアント認証を要求しなければなりません。秘密鍵をどう管理するかは仕様の範囲外ですが、draft-02は属性ベースクライアント認証やSPIFFEクライアント認証を組み合わせる例、モバイルアプリがバックエンドからJWTを受け取って認証に使う構成を挙げています。なお認可サーバーが鍵の変更を検知した場合、発行済みトークンやユーザー同意を失効させる判断が認められている点は運用設計に効きます。

認可リクエストからトークン発行までの流れ

実際のやり取りは、通常の認可コードフローの手前にメタデータ取得が1回挟まるだけです。クライアントは client_id に自分のメタデータURLを入れて認可リクエストを送ります。

GET /authorize
  ?client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json
  &redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback
  &response_type=code
  &state=xyz
  &resource=https%3A%2F%2Fmcp.example.com
  &code_challenge=...
  &code_challenge_method=S256

CIMDが置き換えるのはクライアント識別の部分だけなので、MCPが別途MUSTで求めている要素はそのまま必要です。RFC8707の resource パラメータは認可リクエストとトークンリクエストの両方に含めなければならず、認可応答の iss はRFC9207に従って検証してから認可コードを引き換える必要があります。上の例に resource を入れているのはこのためです。

認可サーバーは client_id がURL形式であることを検知し、そのURLへGETしてJSONを取得します。取得後に検証するのは、ドキュメント内の client_id が取得URLと完全一致すること、認可リクエストの redirect_uri がドキュメントの redirect_uris に完全一致で含まれること、JSONとして妥当で必須項目が揃っていること、そして必要なら信頼ドメインのポリシーに合致することです。RFC9700が認可サーバーにリダイレクトURLの登録と完全一致照合を求めているため、CIMDではこの「登録」がドキュメント取得の瞬間に成立する扱いになります。

検証を通過すると同意画面が表示され、ここで client_name や logo_uri がユーザーに提示されます。あとは認可コードの受け取り、トークンエンドポイントでの交換という通常どおりの流れです。トークン交換時も client_id にはメタデータURLをそのまま送ります。認可コードグラント以外、たとえばクライアントクレデンシャルグラントのようにリダイレクトを使わないグラントでも、クライアント識別とメタデータ探索の仕組みはそのまま適用できます。

認可サーバー実装で事故になりやすい4点：SSRF・5KB・localhost・キャッシュ

CIMDは「攻撃者が指定したURLを、認可サーバーに取得させる」仕組みでもあります。素直に実装すると外部からの任意リクエスト発火装置になるため、draft-02の第8節は具体的な防御を並べています。

第一にSSRFです。認可サーバーは、RFC6890が定める特殊用途IPアドレスへ解決されるClient Identifier URL、およびドキュメント内に含まれるURLを取得してはなりません。ループバックアドレスの例外は、認可サーバー自身もループバック上で動いている開発・テスト用途に限られ、本番環境で適用してはならないと明示されています。取得するURIスキームを既知のものだけに限定することも推奨されており、javascript: のようなスキームがメタデータに紛れ込む経路を塞ぐ狙いです。

第二に読み取りサイズです。ドキュメントのサイズはクライアント側が握っているため、認可サーバーは自分が読み込む量を制限すべきとされ、推奨される上限は5キロバイトです。draft-02の改訂履歴には「この上限はファイルサイズではなく認可サーバーが読む量への指針である」と明確化した旨が記録されています。上限に達したらエラー扱いにして読み込みを打ち切ります。

第三にlocalhostの扱いです。MCP仕様のセキュリティ考慮事項は「CIMDだけではlocalhost URLのなりすましを防げない」と率直に書いています。デスクトップやCLIのMCPクライアントは http://localhost:3000/callback のようなリダイレクトURIを使いますが、これは誰でも同じ値を宣言できます。そのため認可サーバーはlocalhostのみのリダイレクトURIに追加の警告を表示すべきとされ、リダイレクトURIのホスト名を必ず明示することが求められます。追加のアテステーションを要求することも認められています。

第四にキャッシュとプライバシーです。認可リクエストのたびにメタデータを取得する実装は、ユーザーがいつどの認可サーバーを使ったかというタイミング情報を、ドキュメントをホストする側に漏らします。draft-02はこれを「認可サーバーの取得サイドチャネル」として整理し、キャッシュヘッダーの尊重による取得頻度の削減を推奨しています。logo_uri についても、リンクせずに事前取得してキャッシュすることでクロスドメイン追跡と画像すり替えの両方を抑えられる、としています。

KeycloakでCIMDを有効化する手順（26.6以降の実験的機能）

自前の認可サーバーでCIMDを試すなら、現時点で最も手が届きやすいのはKeycloak（メリット・デメリットとAuth0・Okta・Cognito比較）です。26.6.0のリリースノートでCIMDが実験的機能として追加され、MCPの認可サーバーとして使う道が開きました。ソースコードの Profile.java でも CIMD は Type.EXPERIMENTAL として定義されています。プレビュー機能への昇格は26.8のマイルストーンに積まれた未完了課題であり、2026年9月時点の最新版26.7.3でも位置づけは実験的なままです。破壊的変更が入る前提で扱ってください。

有効化はフィーチャーフラグです。

bin/kc.sh start --features=cimd

フラグを立てただけでは動きません。KeycloakはCIMDをクライアントポリシーの仕組みに載せており、プロファイルとポリシーの2つを管理コンソールで作る必要があります。プロファイル側では client-id-metadata-document エグゼキューターを追加し、次の項目を設定します。

• Allow http scheme：httpスキームの許可。開発環境限定で、本番はオフ必須
• Trusted domains：受け入れるドメインのワイルドカードパターン。空にすると全ドメインが拒否される
• Restrict same domain：client_id URL・リダイレクトURI・メタデータ内のURL群を同一の信頼ドメイン配下に強制する
• Required properties：ドキュメントに必須とするプロパティの一覧。欠けていればリクエストを拒否する
• Only Allow Confidential Client：jwksまたはjwks_uriを持ちprivate_key_jwtかtls_client_authを使う機密クライアントのみ受理する

ポリシー側では client-id-uri コンディションを追加し、照合するURIスキーム（本番はhttpsのみ）と信頼ドメインを指定して、先に作ったプロファイルを紐づけます。ここでも信頼ドメインを空欄にすると、条件は常に偽と評価されて何も通りません。Trusted domainsの空欄が「全許可」ではなく「全拒否」に倒れている設計は、他の設定画面の直感と逆なので取り違えやすい箇所です。

管理コンソールに出ない設定も3つあります。キャッシュ時間の下限 min-cache-time（既定300秒）、上限 max-cache-time（既定259200秒＝3日）、そして受け入れるドキュメントの最大バイト数 upper-limit-metadata-bytes（既定5000＝5KB）です。draft-02が推奨する5キロバイトがそのまま既定値になっています。変更は起動オプションで行います。

bin/kc.sh start --features=cimd \
  --spi-client-policy-executor--client-id-metadata-document--upper-limit-metadata-bytes=10000

仕様の推奨を実装が強制に格上げしている箇所もあります。draft-02はクエリ文字列を含めるべきでないと述べるにとどまりますが、Keycloakは公式ガイドで「これを厳格な要件として強制し、クエリ文字列を含む client_id URLはすべて拒否する」と明言しています。仕様のSHOULD NOTを実装がMUST NOTとして扱う典型例で、他の認可サーバーで通ったURLがKeycloakで弾かれる原因になります。

制約も正確に押さえてください。KeycloakのMCP適合表は、2026-07-28版・2025-11-25版のいずれについても「Resource Indicators for OAuth 2.0 を欠いた部分的サポート」と記載しています。ガイド本文も resource パラメータを認識できないと明記し、対応が完了するまでは scope パラメータで代替するよう案内しています。MCPがクライアントに resource の送信をMUSTで求めている以上、現時点のKeycloakは仕様を完全には満たしません。ドキュメントに書かれたSSRF対策が未実装であるというissue（#50531・未解決）も残っており、本番投入の判断はこれらを織り込んで行ってください。

KeycloakのCIMD実装は、日立製作所OSSソリューションセンタの乗松隆志氏（Takashi Norimatsu）の貢献としてリリースノートに記載されています。同氏は2021年10月にKeycloakのメンテナーへ就任した人物です。なおリリースノートはdraft-01を参照しており、draft-01への追随（#47766）とdraft-02への追随（#50718）、プレビュー機能への昇格（#47765）はいずれも26.8のマイルストーンで未解決のままです。同じくOSSの認可サーバーであるOry Hydra（OAuth2.0/OIDC認可サーバーの仕組みとDocker構築）はCIMD対応issue（#4061）が2026年1月の起票以来オープンのままで、この領域ではKeycloakが先行しています。

商用の認可サーバーではAuth0が対応済みです。テナント設定の Settings から Advanced を開き、Client ID Metadata Document Registration のトグルを有効にすると、認可サーバーメタデータにCIMD対応が出ます。加えてAuth0は、テナント管理者がCIMD URLをインポートして登録する「手動CIMD登録」を用意しており、こちらはサードパーティアプリケーションに限定されます。リクエストのたびに取得するKeycloak型に対し、draft-02の第7.2節が認めている事前登録型に寄せた実装で、受け入れるクライアントを企業テナント側で明示的に絞りたい場合に向きます。AIエージェント向けの認可機能についてはAuth0 for AI Agents（GA後の4機能とCIBA・Token Vault実装・料金）で扱っています。

クライアントとフレームワークの対応状況・開発時の検証方法

仕様が固まっても、対応状況は製品ごとに大きく差があります。2026年9月8日時点で公式ドキュメントとソースコードから確認できた範囲を整理します。

製品別のCIMD対応状況（2026年9月8日時点）

主要クライアントは出そろっています。押さえるべきなのは対応の有無ではなく、CIMDが選ばれる条件がベンダーごとに違うことです。OpenAIはChatGPTとCodexを「OpenAIホスト」としてまとめてCIMD対応を公開しており、認可サーバーが client_id_metadata_document_supported を true にしていればCIMDを優先します。トークン交換は none と private_key_jwt の両方を受け付け、CIMDとDCRが両方使える場合はプラグイン開発者側がDCRを選ぶこともできます。

Anthropicは oauth_cimd を「そのままサポート」と明記していますが、選択条件がひとつ多いので注意してください。認可サーバーメタデータが client_id_metadata_document_supported の true と、token_endpoint_auth_methods_supported の none の両方を広告していなければCIMDは選ばれず、DCRへ落ちます。ClaudeのCIMDクライアントがトークンエンドポイントでパブリッククライアントとして認証するためです。実物も公開されており、https://claude.ai/oauth/claude-code-client-metadata を取得するとClaude Codeのドキュメントがそのまま読めます。ここでのリダイレクトURIは http://localhost/callback と http://127.0.0.1/callback で、ポート番号が書かれていません。Claude Codeは毎回異なるエフェメラルポートで待ち受けるため、認可サーバー側にポートを無視した照合が求められます。

なおMCP公式の拡張サポートマトリクスは対応表の代わりになりません。あのページが扱うのは拡張機能だけで、DCRとCIMDはコア機能として別枠で追跡すると注記されています。

ローカル開発での回し方と検証コマンド

CIMDは公開HTTPS URLを前提とするため、開発初期に必ず「localhostで開発しているのにどこへJSONを置くのか」という壁に当たります。draft-02はこの問題を第8.10節と付録Aで扱い、認可サーバーが開発者向けにClient Identifier URLを払い出す「CIMDサービス」というパターンを非規範的に示しています。リダイレクトURIに制限を課す認可サーバーは、その制限を免除したCIMDサービスを最低1つ提供することが推奨されています。ただしCIMDサービス経由のクライアントは、自前でドキュメントを公開しているクライアントと同等の信頼を与えるべきではない、という条件付きです。

自前で置く場合、ホスティング要件は単純です。HTTPS配信、ルート直下ではないパス、公開アクセス可能、client_id と配信URLの完全一致。静的ファイルを配れる場所であれば足ります。FastMCP（PythonでMCPサーバーを最速構築するフレームワーク）は3.0.0でCIMDに対応し、ドキュメントの生成と検証をCLIで用意しています。

fastmcp auth cimd create \
  --name "My Application" \
  --redirect-uri "http://localhost:*/callback" \
  --client-id "https://myapp.example.com/oauth/client.json"

fastmcp auth cimd validate https://myapp.example.com/oauth/client.json

validate はURLの妥当性、JSONがCIMDスキーマに適合しているか、client_id が取得元URLと一致しているかを実際に取得して確認します。公開前の自己点検はこれで足ります。ここで使った create と validate、および各オプションはfastmcp 4.0.3のパッケージ内で実在を確認しました。

ローカルの可変ポートをどう宣言するかは流儀が2つに割れています。http://localhost:*/callback のワイルドカードはFastMCP側の拡張で、draft-02が定める挙動ではありません。もう一方がClaude Code方式で、ポートを書かない http://localhost/callback を宣言し、認可サーバーにポートを無視した照合を求めます。RFC8252の第7.3節がIPリテラル形式について要求している扱いを、Anthropicはlocalhostにも広げる形です。どちらを解釈できるかは認可サーバーの実装次第なので、接続先の仕様を先に確認してください。

よくある質問

CIMDとDCRはどちらを実装すべきですか？

新規実装ならCIMDです。MCP 2026-07-28仕様がDCRを非推奨とし、公式ブログも将来のバージョンでDCRを削除すると述べています。ただし削除まで最低12か月の期間が保証されているため、既存のDCR実装を今すぐ捨てる必要はありません。現実的な構成は、CIMDを既定にしつつ、認可サーバーが client_id_metadata_document_supported を返さない場合にDCRへ落とす二段構えです。

ClaudeやChatGPTはCIMDに対応していますか？

どちらも対応しています。ChatGPTとCodexは、認可サーバーが client_id_metadata_document_supported を true にしていればCIMDを優先します。Claudeも oauth_cimd をそのままサポートしますが条件がひとつ多く、token_endpoint_auth_methods_supported に none を広告していないとDCRへ落ちます。つながらない原因はCIMDに寄せたことではなく、none の広告漏れであることが多いと考えてください。

CIMDはRFCになっていますか？

まだです。2026年9月時点の最新はIETF OAuthワーキンググループの草案 draft-ietf-oauth-client-id-metadata-document-02 で、2026年7月6日発行、2027年1月7日に失効します。個人提出版だった draft-parecki-oauth-client-id-metadata-document はrev03で2026年1月24日に失効しており、追うべきはWG版です。RFC化前のため仕様変更はあり得ます。実際、draft-02では用語が「client identifier」から「Client Identifier URL」へ改称され、SSRFのループバック例外が開発・テスト用途限定であることも明確化されました。

既存のDCR実装はいつまで動きますか？

MCP仕様の非推奨機能一覧は、DCRの削除時期を「2027-07-28以降に出る最初のリビジョン」と明記しています。非推奨化されたのは2026-07-28版で、根拠はPR #2858です。Roots・Sampling・Loggingにも同じ日付が割り当てられており、最低12か月という廃止ポリシーが具体的な日付として運用されていることが確認できます。移行の締め切りはこの日付を基準に引くのが安全です。

KeycloakでCIMDを試すには何が必要ですか？

26.6以降のKeycloakを --features=cimd 付きで起動し、管理コンソールでクライアントプロファイル（client-id-metadata-document エグゼキューター）とクライアントポリシー（client-id-uri コンディション）を作成します。両方でTrusted domainsを設定する必要があり、空欄のままだと全ドメインが拒否されます。実験的機能のため、将来のバージョンで設定項目が変わる可能性があります。

関連記事

• MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説
• Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】
• FastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】
• Ory Hydraとは？OAuth2.0/OIDC認可サーバーの仕組みとDocker構築・認証基盤連携を解説
• Auth0 for AI Agentsとは？GA後の4機能とCIBA・Token Vault実装・料金を解説【2026年版】