Microsoft Entraの公式ドキュメント更新「Clarify did.json troubleshooting URL is a placeholder」は、Microsoft Entra Verified IDの機能変更ではなく、did.json のトラブルシューティング手順にあるURL表記を分かりやすくするための修正です。結論から言うと、運用担当者が確認すべき点は「https://<your-domain>/.well-known/did.json の <your-domain> を自社ドメインに置き換えて検証しているか」です。
この更新は小さな文言修正に見えますが、security admins、compliance teams、enterprise IT readersにとっては見落とせません。Microsoft Entra Verified IDでは、did.json が匿名アクセス可能で、HTTPSやTLS証明書に問題がないことが登録状態の更新に関わります。公式ドキュメントでも、ブラウザーや curl で警告やエラーなく取得できない場合、ポータルの「Refresh registration status」を完了できないと説明されています。(Microsoft Learn)
Microsoft Entraの公式ドキュメント更新で何が変わったか
2026年4月30日のMicrosoftDocs系GitHubコミット「Clarify did.json troubleshooting URL is a placeholder」では、Microsoft Entra Verified IDの did:web 登録手順にあるトラブルシューティング用URLの表記が修正されました。
変更前は、トラブルシューティング例として次のようなURLが使われていました。
curl -Iv https://verifiedid.contoso.com/.well-known/did.json変更後は、次のように <your-domain> が明示され、その後に例として verifiedid.contoso.com が示されています。
curl -Iv https://<your-domain>/.well-known/did.jsonたとえば、自社のVerified ID用ドメインが verifiedid.example.co.jp であれば、確認コマンドは次のようになります。
curl -Iv https://verifiedid.example.co.jp/.well-known/did.jsonGitHub上のコミットでは、修正対象が docs/verified-id/how-to-register-didwebsite.md の1ファイルで、差分は1行の追加と1行の削除です。コミット説明では、以前の修正で yourdomain.com がリンク安全性の観点から verifiedid.contoso.com に置き換えられたものの、トラブルシューティング文脈では読者が自分のドメインに置き換える必要があるため、プレースホルダーと例を併記したと説明されています。(GitHub)
つまり今回のポイントは、verifiedid.contoso.com をそのまま実行するためのURLではなく、あくまで例示用のドメインだと明確にしたことです。
仕様変更ではなく、運用ミスを防ぐための明確化
今回の更新は、Microsoft Entra Verified IDの仕様変更、API変更、ポータル機能の変更ではありません。ドキュメント上の表記を修正し、読者が誤ったURLを使ってトラブルシューティングしないようにするための更新です。
ただし、実務上の影響はあります。社内手順書やナレッジベースに verifiedid.contoso.com のようなサンプルURLをそのまま転記している場合、障害調査時に本来確認すべき自社ドメインを見ていない可能性があるからです。
| 確認項目 | 見るべきポイント | 実務上のリスク |
|---|---|---|
| トラブルシューティングURL | <your-domain> を自社ドメインに置き換えているか | サンプルURLを確認して「異常なし」と誤認する |
/.well-known/did.json の配置 | Webサーバー上の正しいパスにあるか | 登録状態の更新が失敗する |
| HTTPS/TLS | 有効な証明書で警告なくアクセスできるか | ポータル側から取得できない |
| 匿名アクセス | 認証なしで取得できるか | 社内ネットワークでは見えるが外部から見えない |
| 運用手順書 | 古い例示URLが残っていないか | 障害対応時に調査対象を間違える |
特に大企業では、Microsoft Learnの内容をもとに社内Wiki、運用手順、監査証跡テンプレート、委託先向け手順書を作成していることがあります。今回のような1行修正でも、手順書に反映しておくと、将来の切り分けミスを防げます。
did.jsonとは何かを運用目線で理解する
did.json は、Microsoft Entra Verified IDにおける did:web のDIDドキュメントです。公式ドキュメントでは、DIDドキュメントには発行者の公開キーが含まれ、資格情報の発行とプレゼンテーションの両方で使用されると説明されています。Microsoft Authenticatorは、ウォレットとして動作する際に、この公開キーを使って発行要求やプレゼンテーション要求の署名を検証します。(Microsoft Learn)
簡単に言えば、did.json は「この組織が発行者として信頼されるために、外部から参照できる公開情報」です。
Microsoft Entra Verified IDで did:web を使う場合、DIDドキュメントはWebサーバーの次の場所に配置します。
https://<your-domain>/.well-known/did.jsonこのファイルは、社内の管理者だけが見られるファイルではありません。Microsoft Entra側や検証に関わるシステムが到達できる必要があります。そのため、ID基盤の設定でありながら、実際にはDNS、証明書、Webサーバー、CDN、WAF、プロキシ設定などの影響を強く受けます。
まず確認すべきポイント
今回のMicrosoft Entra公式ドキュメント更新を受けて、運用担当者が最初に見るべきなのは次の3点です。
自社ドメインに置き換えたcurlコマンドで確認する
公式ドキュメントの更新後の意図は明確です。<your-domain> は文字どおりプレースホルダーであり、自社のVerified ID用ドメインに置き換える必要があります。
例として、ドメインが verifiedid.example.co.jp の場合は次のように実行します。
curl -Iv https://verifiedid.example.co.jp/.well-known/did.jsonUbuntu環境またはUbuntuを使ったWindows Subsystem for Linuxでも確認できると公式ドキュメントに記載されています。(Microsoft Learn)
確認時は、単にコマンドが返ってくるかだけでなく、次の観点を見ます。
| 観点 | 確認内容 |
|---|---|
| URL | https://<自社ドメイン>/.well-known/did.json になっているか |
| HTTPS | 証明書エラーや警告が出ていないか |
| 到達性 | インターネットからアクセスできるか |
| 認証 | Basic認証、IP制限、SSO認証などが挟まっていないか |
| レスポンス | 期待する did.json が返っているか |
| リダイレクト | 意図しないHTTPリダイレクトや別ドメイン転送がないか |
curl -Iv はヘッダーやTLS接続の情報を見るのに便利です。一方、実際のJSON本文も確認したい場合は、次のように -I を外して実行します。
curl -v https://verifiedid.example.co.jp/.well-known/did.jsonHEADリクエストに対するサーバーの挙動が環境によって異なることもあるため、障害調査ではヘッダー確認と本文確認の両方を行うと切り分けしやすくなります。
Microsoft Entraポータルの「登録状態の更新」と同じ前提で確認する
公式ドキュメントでは、Azure portalのVerified IDページからDIDドキュメントを取得し、Webサーバーの /.well-known/did.json にアップロードした後、「Refresh registration status」でシステムがファイルを要求できることを確認すると説明されています。(Microsoft Learn)
ここで重要なのは、「自分のPCから見える」だけでは不十分という点です。
社内ネットワークからはアクセスできても、Microsoft Entra側から到達できなければ登録状態の更新は成功しません。たとえば、次のような構成では失敗しやすくなります。
| 失敗しやすい構成 | 起きる問題 |
|---|---|
| 社内IPのみ許可している | Microsoft Entra側から取得できない |
| WAFでbot判定が強すぎる | curl や外部システムからの取得がブロックされる |
| TLS証明書の中間証明書設定が不完全 | ブラウザー以外のクライアントで証明書エラーになる |
| HTTPからHTTPSへの転送が複雑 | 想定外のリダイレクトで取得に失敗する |
| CDNキャッシュが古い | 更新後の did.json が反映されない |
障害対応時は、社内端末、外部ネットワーク、UbuntuまたはWSL環境など、複数の場所から同じURLを確認すると原因を絞り込みやすくなります。
社内手順書のサンプルURLを洗い出す
今回の更新で最も現実的な対応は、社内に残っている古いサンプルURLの点検です。
特に次の資料に verifiedid.contoso.com や yourdomain.com がそのまま残っていないか確認してください。
| 対象資料 | 確認ポイント |
|---|---|
| 運用手順書 | 実行コマンドが自社ドメイン前提になっているか |
| 障害対応Runbook | 調査対象URLが固定サンプルになっていないか |
| 監査チェックリスト | did.json 到達性確認の証跡項目があるか |
| 構築手順書 | 本番、検証、開発環境のドメインが分かれているか |
| 委託先向け資料 | サンプルと実環境値の違いが明記されているか |
contoso.com はMicrosoftドキュメントでよく使われる架空の例示ドメインです。本番環境で確認すべきなのは、必ず自社がVerified IDで使っているドメインです。
security adminsが確認すべき点
セキュリティ管理者は、今回の更新を「URL表記の修正」として片付けず、did.json の公開状態をセキュリティ管理対象として見直すべきです。
匿名公開が必要なファイルとして扱う
did.json は、認証をかけて隠すファイルではありません。公式ドキュメントでも、ブラウザーや curl などのツールで匿名要求できない場合、登録状態の更新を完了できないと説明されています。(Microsoft Learn)
ただし、匿名公開が必要だからといって、管理が不要という意味ではありません。むしろ、外部公開されるID関連ファイルとして、次のような管理が必要です。
| 管理項目 | 推奨される確認 |
|---|---|
| 変更管理 | did.json の更新理由、更新者、反映日時を記録する |
| 改ざん対策 | Webサーバーやストレージの書き込み権限を限定する |
| 監視 | 404、403、5xx、証明書期限切れを監視する |
| 証明書管理 | 更新漏れを防ぐため、有効期限アラートを設定する |
| ログ確認 | 不審な大量アクセスや改ざん兆候を確認する |
did.json は個人情報そのものを載せるファイルではありませんが、発行者の公開キーに関わる重要な構成要素です。通常の静的ファイルよりも、ID基盤の一部として扱うのが安全です。
WAFやCDNでブロックしていないか確認する
大規模環境では、/.well-known/ 配下のファイルがCDN、WAF、リバースプロキシを通ることがあります。その場合、管理者のブラウザーでは表示できても、curl や外部サービスからはブロックされることがあります。
確認時は、WAFログやCDNログで次のような挙動を見てください。
| ログで見る項目 | 例 |
|---|---|
| ステータスコード | 200、301、403、404、500など |
| User-Agent | curl や外部クライアントが拒否されていないか |
| リクエストパス | /.well-known/did.json が別パスに書き換えられていないか |
| TLS関連 | 証明書チェーンやSNIの問題がないか |
| キャッシュ | 古いDIDドキュメントを返していないか |
WAFのルールで「JSONファイルへの外部アクセス」を厳しく制限している場合、例外設定が必要になることがあります。ただし、例外はパス単位に限定し、不要なディレクトリ公開を避けるべきです。
compliance teamsが確認すべき点
コンプライアンス担当者にとって、今回の更新は「監査証跡の対象を正しいURLにする」ための見直しポイントです。
did.json の確認証跡を残している場合、サンプルURLではなく、自社ドメインで確認した結果を記録している必要があります。監査時に verifiedid.contoso.com への到達性だけを証跡として残しても、自社環境の健全性を証明する材料にはなりません。
証跡として残すべき情報
監査・統制の観点では、次の情報を残すと後から説明しやすくなります。
| 証跡項目 | 例 |
|---|---|
| 確認日時 | 2026-05-01 10:00 JST |
| 確認者 | ID基盤運用担当者 |
| 対象URL | https://verifiedid.example.co.jp/.well-known/did.json |
| 実行コマンド | curl -Iv https://verifiedid.example.co.jp/.well-known/did.json |
| 結果 | TLSエラーなし、HTTP 200、匿名取得可 |
| 変更理由 | 公式ドキュメント更新に伴う手順確認 |
| 関連チケット | 変更管理番号、インシデント番号など |
証跡では、コマンド全文だけでなく、実際に自社ドメインへアクセスしていることが分かるスクリーンショットやログも有効です。ただし、出力に内部情報が含まれる場合は、保管ルールに従って扱ってください。
キーローテーションやリンクドメイン変更時の確認にも使う
公式ドキュメントでは、リンクドメインを変更する場合や署名キーをローテーションする場合、did.json 内のDIDドキュメントを再発行する必要があると説明されています。(Microsoft Learn)
そのため、今回の更新は一度だけ確認すれば終わりではありません。次のイベントが発生したときにも、同じ観点で確認する必要があります。
| イベント | 確認すべきこと |
|---|---|
| 署名キーのローテーション | 新しいDIDドキュメントがWebサーバーに反映されているか |
| リンクドメイン変更 | 新ドメインの /.well-known/did.json が公開されているか |
| Webサーバー移行 | 旧環境と同じパスで取得できるか |
| CDN導入 | キャッシュやリダイレクトで古い内容を返していないか |
| 証明書更新 | TLS警告なく取得できるか |
特に移行作業では、DNS切り替え、証明書更新、CDN反映、ファイル配置の順番がずれると、一時的に登録状態の更新が失敗することがあります。
enterprise IT readersが押さえるべき移行・運用準備
エンタープライズ環境では、Microsoft Entra Verified IDの設定はID管理チームだけで完結しないことが多くあります。Webサーバー管理、DNS管理、セキュリティ監視、監査、外部委託先が関わるため、今回のようなURL表記の明確化を運用設計に反映することが重要です。
環境ごとにURLを明確に分ける
本番、検証、開発環境で同じ手順を使い回す場合、<your-domain> をどの値に置き換えるかを表にしておくと、作業ミスを防げます。
| 環境 | 確認URLの例 | 注意点 |
|---|---|---|
| 本番 | https://verifiedid.example.co.jp/.well-known/did.json | 監査証跡と監視対象にする |
| 検証 | https://verifiedid-stg.example.co.jp/.well-known/did.json | 本番と証明書・WAF条件が異ならないか確認する |
| 開発 | https://verifiedid-dev.example.co.jp/.well-known/did.json | 外部公開範囲とセキュリティルールを明確にする |
よくある失敗は、検証環境ではアクセスできたのに、本番環境ではWAFや証明書設定が異なり失敗するケースです。Verified ID用のURLは、環境ごとの値を明文化しておくべきです。
Runbookには「置き換え前」と「置き換え後」を両方書く
運用手順では、単に「以下のコマンドを実行する」と書くよりも、プレースホルダーの意味を明記したほうが安全です。
悪い例は次のような記述です。
curl -Iv https://<your-domain>/.well-known/did.jsonこのままだと、経験の浅い担当者が <your-domain> をそのまま実行してしまう可能性があります。
実務向けには、次のように書くと誤解が減ります。
<your-domain> は自社のVerified ID用ドメインに置き換える。
本番環境では verifiedid.example.co.jp を使う。curl -Iv https://verifiedid.example.co.jp/.well-known/did.jsonこのように、説明用のコマンドと実行用のコマンドを分けるだけで、障害対応時のミスを減らせます。
障害発生時の切り分け手順
Refresh registration status が失敗する場合は、Microsoft Entra側だけを見るのではなく、URL、DNS、TLS、Webサーバー、WAF、ファイル内容の順に確認すると効率的です。
| 順番 | 確認内容 | 代表的な原因 |
|---|---|---|
| 1 | URLが正しいか | サンプルドメインのまま、パスの誤り |
| 2 | DNSが解決できるか | レコード未反映、内部向けDNSのみ |
| 3 | HTTPSで接続できるか | 証明書期限切れ、中間証明書不足 |
| 4 | 匿名アクセスできるか | 認証、IP制限、WAFブロック |
| 5 | did.json が返るか | ファイル未配置、パス違い、権限不足 |
| 6 | Microsoft Entraポータルで更新できるか | 外部からは到達できない、キャッシュ不整合 |
実行例は次のとおりです。
curl -Iv https://verifiedid.example.co.jp/.well-known/did.jsonレスポンス本文も見る場合は次のようにします。
curl -v https://verifiedid.example.co.jp/.well-known/did.jsonDNSを切り分ける場合は、環境に応じて nslookup や dig も使います。
nslookup verifiedid.example.co.jpdig verifiedid.example.co.jpただし、最終的に重要なのは「自分の端末で解決できるか」ではなく、「Microsoft Entraが外部から取得できる条件になっているか」です。社内ネットワーク限定の成功結果だけで判断しないようにしましょう。
今回の更新でやらなくてよいこと
今回のドキュメント更新は、誤解を防ぐためのURL表記の明確化です。そのため、次のような作業を慌てて行う必要は通常ありません。
| やらなくてよいこと | 理由 |
|---|---|
| Verified IDの再構成 | 機能仕様の変更ではないため |
did.json の即時再発行 | ドメイン変更やキーローテーションがなければ不要 |
| Microsoft Entraテナントの移行 | ドキュメント文言の修正であり、移行要求ではないため |
| API実装の変更 | curl の例示URL修正であり、API変更ではないため |
| 全ユーザーへの通知 | 影響は主に運用・監査・構築担当者に限定されるため |
ただし、社内文書に古いサンプルが残っている場合は修正してください。特に、障害対応手順に誤った確認先が残っていると、実際のインシデント時に調査が遠回りになります。
今後の運用に組み込むべきチェックリスト
Microsoft Entra Verified IDを運用している組織は、今回の更新をきっかけに、did.json の定期確認を標準運用に入れておくと安全です。
| タイミング | 確認内容 |
|---|---|
| 初期構築時 | 自社ドメインの /.well-known/did.json に匿名アクセスできるか |
| 本番リリース前 | 外部ネットワークからTLS警告なしで取得できるか |
| 証明書更新後 | curl -Iv で証明書エラーが出ないか |
| DNS変更後 | 正しいホストに解決されるか |
| WAF/CDN変更後 | /.well-known/did.json がブロックされていないか |
| キーローテーション後 | 最新のDIDドキュメントが反映されているか |
| 監査前 | 証跡のURLが自社ドメインになっているか |
チェックリストの目的は、Microsoft Entraの設定そのものだけでなく、周辺インフラの変更でVerified IDの信頼性が落ちることを防ぐことです。
まとめ：サンプルURLではなく自社ドメインで確認する
Microsoft Entraの公式ドキュメント更新「Clarify did.json troubleshooting URL is a placeholder」は、did.json のトラブルシューティングURLがプレースホルダーであることを明確にする更新です。機能変更ではありませんが、運用面では重要です。
確認すべきことは明確です。https://<your-domain>/.well-known/did.json の <your-domain> を自社のVerified ID用ドメインに置き換え、HTTPS、証明書、匿名アクセス、WAF/CDN、ファイル配置を確認してください。
次に取るべき行動は、社内手順書やRunbookにある did.json 確認コマンドを見直すことです。verifiedid.contoso.com のような例示ドメインが残っている場合は、自社環境の具体的なURLに置き換えた実行例を追記しましょう。小さな修正ですが、障害対応、監査、移行作業の精度を上げる実務的な改善になります。
コメント