Microsoft Entraの公式ドキュメント更新「Replace ‘yourdomain.com’ placeholder with ‘verifiedid.contoso.com’」は、製品仕様の変更というより、Microsoft Entra Verified ID関連ドキュメント内のサンプル用ドメイン表記を安全で一貫したプレースホルダーにそろえる更新です。実運用の設定値を即変更する必要はありませんが、手順書、サンプルコード、検証環境のJSON、社内ナレッジにyourdomain.comをそのまま使っている場合は確認が必要です。
今回のポイントは、yourdomain.comがverifiedid.contoso.comに置き換えられたことです。特に、did:webの登録確認で使うdid.jsonのURL、Face CheckのacceptedIssuers、検証結果コールバック内のissuer例を参照しているチームは、サンプル値と本番値を混同していないか見直しましょう。
Microsoft Entraの公式ドキュメント更新で何が変わったか
2026年4月30日のMicrosoftDocs/entra-docsのコミットでは、Microsoft Entra Verified ID関連の2ファイルに対して、yourdomain.comというプレースホルダーをverifiedid.contoso.comに置き換える変更が行われました。対象はdocs/verified-id/how-to-register-didwebsite.mdが1か所、docs/verified-id/using-facecheck.mdが2か所で、合計3行の差分です。コミットメッセージでは、link-unsafe build reportの指摘解消と、Verified IDフォルダー内でverifiedid.contoso.comが標準的なプレースホルダーとして使われていることが説明されています。(GitHub)
変更内容を整理すると、次のようになります。
| 対象ドキュメント | 変更前 | 変更後 | 確認すべき意味 |
|---|---|---|---|
| did:web登録手順 | https://yourdomain.com/.well-known/did.json | https://verifiedid.contoso.com/.well-known/did.json | curlで確認するURL例が、より明確なサンプルドメインに変更された |
| Face Checkの提示要求例 | "acceptedIssuers": [ "did:web:yourdomain.com" ] | "acceptedIssuers": [ "did:web:verifiedid.contoso.com" ] | 受け入れる発行者DIDのサンプル値が変更された |
| Face Checkの検証結果例 | "issuer": "did:web:yourdomain.com" | "issuer": "did:web:verifiedid.contoso.com" | コールバック応答例の発行者DIDが変更された |
この更新で重要なのは、verifiedid.contoso.comもあくまでサンプルであり、自社の本番環境でそのまま使う値ではない点です。実環境では、組織がMicrosoft Entra Verified IDで登録した実際のDID、たとえばdid:web:id.example.co.jpのような値に置き換える必要があります。
今回の更新は仕様変更ではなく「ドキュメントの安全性と一貫性」の修正
今回の変更は、Microsoft Entra Verified IDの認証仕様やFace Checkの動作を変えるアップデートではありません。差分はドキュメント内の例示ドメインに限られています。
ただし、運用現場では小さなドキュメント修正が意外な混乱を生むことがあります。たとえば、社内の検証手順書に古いyourdomain.comの例が残っていると、担当者が「自社ドメインに置き換えるべきなのか」「Microsoftのサンプル値を使えばよいのか」を判断しにくくなります。
特に注意したいのは、次のようなケースです。
| 状況 | リスク | 推奨対応 |
|---|---|---|
社内Wikiにyourdomain.comを含む手順がある | 新任担当者が実在しないドメインとして扱わず、そのままコピーする可能性がある | 自社のVerified ID用ドメインに置換すると明記する |
| サンプルJSONを検証環境で使い回している | acceptedIssuersが誤ったDIDのまま残る | 実際の発行者DIDに置き換えてからテストする |
| 監査証跡や設計書にサンプル値が混在している | どのDIDが本番値か判断しにくくなる | サンプル値と本番値を別表で管理する |
| 多国籍チームで英語版ドキュメントを参照している | 更新前後の表記差によりレビュー観点がずれる | 参照日とドキュメントURLを設計書に残す |
yourdomain.comは「あなたのドメイン」という意味が伝わりやすい一方で、URLチェックやリンク検査の文脈では安全でないリンクとして扱われることがあります。contoso.com系の表記はMicrosoftドキュメントでよく使われる架空企業の例示に近く、サンプルだと判断しやすいのが利点です。
did:web登録手順で確認すべきポイント
Microsoft Entra Verified IDでdid:webを使う場合、DIDドキュメントをWebサーバー上の/.well-known/did.jsonに配置し、Azureポータル側で登録状態を更新して、システムがそのファイルを取得できるか確認します。Microsoft Learnの手順でも、DIDドキュメントのアップロード先として/.well-known/did.jsonが示されています。(Microsoft Learn)
今回の更新で置き換えられたcurlの例は、まさにこの到達性確認に関する部分です。Microsoft Learnでは、did.jsonがブラウザーやcurlなどから匿名で取得できない場合、登録状態の更新を完了できないと説明されています。HTTPS未使用、不正なTLS/SSL証明書、URLが公開されていない状態もエラー要因になります。(Microsoft Learn)
実務では、次のような観点で確認するとよいでしょう。
curl -Iv https://<自社のVerified ID用ドメイン>/.well-known/did.json確認すべき主な項目は次のとおりです。
| 確認項目 | OKの目安 | よくある失敗 |
|---|---|---|
| HTTPSでアクセスできるか | https://で接続できる | HTTPのみ、証明書期限切れ、証明書名不一致 |
| 匿名アクセスできるか | 認証なしでdid.jsonを取得できる | 社内ネットワーク限定、Basic認証、WAFでブロック |
| パスが正しいか | /.well-known/did.jsonに配置されている | /well-known/や/did.json直下に置いている |
| リダイレクトが問題ないか | 最終的に正しいJSONへ到達する | HTTPからHTTPSへのリダイレクトで失敗する |
| JSONが正しいか | DIDドキュメントとして解釈できる | CDNキャッシュに古いファイルが残っている |
DIDドキュメントには発行者の公開キーが含まれ、資格情報の発行と提示の両方で使われます。Microsoft Authenticatorなどのウォレットは、この公開キーを使って発行要求や提示要求の署名を検証します。また、リンク済みドメインを変更した場合や署名キーをローテーションした場合は、did.jsonの再公開が必要です。(Microsoft Learn)
つまり、今回のようなサンプルURLの変更を見たときに確認すべきなのは「サンプル値を更新するか」だけではありません。自社のdid.json公開状態、証明書、匿名アクセス、キー更新時の運用手順まで含めて点検するのが安全です。
Face Check利用環境で確認すべきポイント
もう一つの変更対象は、Microsoft Entra Verified IDのFace Checkに関するドキュメントです。Face Checkは、ユーザーのリアルタイム自撮り画像と資格情報に含まれる写真を照合する、Verified ID内の高保証検証向け機能です。Microsoft Learnでは、Face CheckはVerified ID内のプレミアム機能であり、利用前にMicrosoft Entra Verified IDのセットアップでFace Checkアドオンを有効化する必要があると説明されています。(Microsoft Learn)
今回の変更では、Face Checkの提示要求例に含まれるacceptedIssuersと、検証成功時のpresentation_verifiedコールバック例に含まれるissuerが、did:web:yourdomain.comからdid:web:verifiedid.contoso.comに置き換えられました。(GitHub)
ここで実務上重要なのは、acceptedIssuersは単なる表示用テキストではなく、検証アプリケーションが受け入れる発行者DIDを指定する値だという点です。自社の従業員証明書だけを受け入れるのか、グループ会社や外部機関が発行した資格情報も受け入れるのかによって、設定すべきDIDは変わります。
たとえば、ヘルプデスクで本人確認にFace Checkを使い、パスキー有効化やパスワードリセットのセルフサービスを行う場合、誤った発行者DIDを受け入れると、想定外の資格情報を検証対象にしてしまう可能性があります。Microsoft Learnでも、Face Checkを含む提示要求では、写真を含むクレーム名や信頼度しきい値を指定でき、既定値は70と説明されています。(Microsoft Learn)
acceptedIssuersの見直しで確認すること
Face CheckやVerified IDの検証アプリを運用している場合、次の観点でacceptedIssuersを確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 本番DIDが正しいか | Microsoft Entra Verified IDで登録済みの発行者DIDと一致しているか |
| サンプルDIDが残っていないか | did:web:yourdomain.comやdid:web:verifiedid.contoso.comが本番コードに残っていないか |
| 複数発行者を受け入れる理由があるか | グループ会社、外部IDプロバイダー、業務委託先など明確な要件があるか |
| 環境ごとに値を分けているか | 開発、検証、本番でDIDを混在させていないか |
| 監査で説明できるか | なぜその発行者DIDを信頼するのか、承認記録があるか |
本番環境のJSONやIaCテンプレートにサンプルDIDが残っている場合は、単なる表記ゆれではなく設定ミスとして扱うべきです。特に、セキュリティ管理者と開発チームが別組織の場合、「ドキュメントのサンプルをコピーしただけ」の値が長期間残ることがあります。
セキュリティ管理者が見るべき運用影響
security adminsが今回のMicrosoft Entraドキュメント更新で確認すべきことは、製品の新機能ではなく、サンプル値が本番設定に混入していないかです。
確認対象は、ソースコードだけではありません。次のような場所にも古いプレースホルダーが残りやすくなります。
- GitHubやAzure Repos上のサンプルJSON
- 社内Wiki、Runbook、手順書
- SIEMや監査ログの検索クエリ例
- API検証用のPostmanコレクション
- CI/CDパイプラインの環境変数テンプレート
- 開発者向けオンボーディング資料
- ベンダーに共有した設計書や検証手順
検索するときは、次の文字列をまとめて確認すると効率的です。
yourdomain.com
did:web:yourdomain.com
verifiedid.contoso.com
did:web:verifiedid.contoso.com
.well-known/did.json
acceptedIssuersverifiedid.contoso.comは更新後のサンプル値ですが、本番コードに残ってよい値ではありません。yourdomain.comだけを検索すると、新しいサンプル値の混入を見落とす可能性があります。
コンプライアンスチームが見るべき監査・説明責任のポイント
compliance teamsにとって今回の更新は、Verified IDやFace Checkの設定が「誰を信頼する設計になっているか」を再確認するよい機会です。特にFace Checkは高保証検証の文脈で使われるため、しきい値、発行者DID、検証結果の扱い、本人確認フローの説明責任が重要になります。
Microsoft Learnでは、Face Checkを実行した場合、検証アプリケーションは写真やライブネスデータではなく、写真との照合に関する信頼度スコアを受け取ると説明されています。また、ライブネスデータの保存や共有に関する説明も掲載されています。(Microsoft Learn)
コンプライアンス観点では、次の点を確認しましょう。
| 項目 | 確認内容 |
|---|---|
| 発行者DIDの承認 | どのDIDを信頼するか、承認者と承認日が記録されているか |
| Face Checkの利用目的 | パスワードリセット、機密業務承認など、利用目的が明確か |
| しきい値の根拠 | 既定値をそのまま使うのか、業務リスクに応じて変更するのか |
| ユーザー説明 | 顔照合で何が共有され、何が共有されないか説明できるか |
| ログ保全 | 検証結果、エラー、設定変更の監査ログを追跡できるか |
| 例示値の排除 | 監査資料にサンプルDIDが本番値のように記載されていないか |
特に重要なのは、acceptedIssuersを「技術者だけが知る設定値」にしないことです。これは信頼境界を定義する値であり、組織として誰の発行した資格情報を受け入れるのかというガバナンス上の判断に直結します。
企業IT担当者向けの移行準備チェックリスト
今回の更新そのものは移行作業を要求するものではありません。しかし、社内資料や検証環境を整理するにはよいタイミングです。enterprise IT readers向けには、次の順序で確認すると実務に落とし込みやすくなります。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | 公式コミットの差分を確認する | 変更対象が2ファイル3か所であることを把握する |
| 2 | 社内リポジトリを検索する | yourdomain.comとverifiedid.contoso.comの残存箇所を洗い出す |
| 3 | サンプルと本番値を分類する | 残してよい教材用サンプルと、修正すべき設定を分ける |
| 4 | 本番DIDを確認する | Microsoft Entra Verified IDで登録済みのDIDと一致させる |
| 5 | did.jsonの公開状態を検証する | HTTPS、匿名アクセス、証明書、JSON内容を確認する |
| 6 | Face Checkの設定を確認する | acceptedIssuers、信頼度しきい値、コールバック処理を確認する |
| 7 | 手順書を更新する | 「サンプル値は本番で使わない」と明記する |
| 8 | 変更記録を残す | 監査・運用引き継ぎ用に確認日と担当者を記録する |
移行準備という言葉から大がかりな作業を想像しがちですが、今回のようなドキュメント更新では、まず「誤ってコピーされたサンプル値を探す」ことが最も効果的です。
実務でありがちな失敗と防ぎ方
今回の変更に関連して、Verified IDの導入・運用で起きやすい失敗を整理しておきます。
サンプル値を本番値として扱ってしまう
did:web:verifiedid.contoso.comは、Microsoftのドキュメント上の例示値です。自社環境では、実際に登録したDIDを使う必要があります。
防止策として、社内手順書では次のように書くと誤解を減らせます。
例：did:web:verifiedid.contoso.com
本番では使用不可。自社のVerified ID発行者DIDに置き換えること。did.jsonを社内ネットワーク限定で公開してしまう
did.jsonは、Microsoft Entra側から取得できる必要があります。社内からアクセスできても、外部から匿名で取得できなければ登録状態の更新に失敗する可能性があります。Microsoft Learnでも、did.jsonがブラウザーやcurlから匿名で取得できない場合、ポータルの登録状態更新は完了できないと説明されています。(Microsoft Learn)
本番反映前に、社外ネットワークまたは制限のない検証環境からcurlで確認しておきましょう。
acceptedIssuersを広く設定しすぎる
複数のDIDを受け入れる設定は便利ですが、信頼範囲が広がります。特に本人確認や機密業務へのアクセス制御に使う場合は、受け入れる発行者を最小限にするのが基本です。
「将来使うかもしれないから」といって発行者DIDを多めに登録するのは避け、業務要件が確定したものだけを追加します。
Face Checkのしきい値を業務リスクと結び付けていない
Face Checkでは、信頼度しきい値を指定できます。Microsoft Learnでは、しきい値は50〜100の整数で指定でき、既定値は70とされています。(Microsoft Learn)
ただし、既定値がすべての業務に最適とは限りません。たとえば、社内ポータルの軽微な確認と、高リスクなパスワードリセットでは求められる保証レベルが異なります。セキュリティ、業務、コンプライアンスの関係者で、拒否率と不正受け入れリスクのバランスを検討する必要があります。
今回の更新を受けて今すぐ確認すべきこと
今回のMicrosoft Entra公式ドキュメント更新は、仕様変更ではなくプレースホルダー表記の修正です。しかし、Verified IDやFace Checkを扱う組織にとっては、サンプル値の混入、DIDの信頼範囲、did.jsonの公開状態を見直すきっかけになります。
まずは、社内のコード、手順書、検証用JSONからyourdomain.comとverifiedid.contoso.comを検索してください。次に、本番環境で使っているDIDが正しいか、/.well-known/did.jsonがHTTPSで匿名取得できるか、Face CheckのacceptedIssuersが業務上必要な発行者だけに絞られているかを確認しましょう。
小さなドキュメント更新でも、ID基盤では「どの値を信頼しているか」が運用品質を左右します。今回の変更は、Microsoft Entra Verified IDの設定を棚卸しし、サンプルと本番値を明確に分離する好機です。
コメント