Azureポータル/Entra IDで特定テナントにログインできない（AADSTS5000224）原因と復旧手順

昨日まで使えていたのに、Azure ポータル／Microsoft Entra 管理センターで「特定のテナントだけ」急にサインインできなくなり、AADSTS5000224（We are sorry, this resource is not available.）が出る――本記事では、この症状でまず疑うべき原因と、復旧までの最短ルート（URLでの回避策／サポートへの依頼手順／切り分けポイント）をまとめます。

発生している症状：Azureポータル／Entra IDで特定テナントにログインできない

本事象は、次のような状況で気づくことが多いです。

• Azure ポータルにアクセスすると、サインイン自体はできるがディレクトリ（テナント）選択後にエラーになる
• Microsoft Entra 管理センター（旧 Azure AD）でも同様に、そのテナントだけ管理画面に入れない
• エラー画面にTrace ID / Correlation IDが表示され、「誤りなら Microsoft サポートへ連絡してほしい」と案内される

代表的なエラー文は次の形式です（表示は英語/日本語いずれの場合もあります）。

AADSTS5000224: We are sorry, this resource is not available.
Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation ID: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Timestamp: 2025-xx-xx xx:xx:xxZ

ここで重要なのは、「パスワード間違い」「MFA未完了」「条件付きアクセスに引っかかった」といったよくある認証エラーの文脈と挙動が違う点です。実際、AADSTS5000224 は“サインインそのもの”というよりテナント側の状態に起因して、要求されたリソースが利用できないときに出ることがあります。

まず押さえる結論：テナントの保護措置（サインイン一時無効化）が疑われる

結論から言うと、今回のように「特定テナントだけ」突然サインイン不能になり、AADSTS5000224 とサポート連絡を促す画面が出る場合、原因として最も可能性が高いのは次のパターンです。

セキュリティ インシデント（不正アクセス疑い、異常なサインイン、マルウェア/フィッシング等）に対する保護措置として、Microsoft 側でそのテナントの認証（サインイン）が一時的に制限・無効化されている。

このケースは、利用者側の設定変更（条件付きアクセスを直す、MFAを再登録する、パスワードを変える等）だけでは復旧できないことが多く、Microsoft 側での解除対応が必要になります。逆に言えば、長時間あれこれ試すよりも、最短の復旧ルートは「回避策を試す → だめなら即サポートへエスカレーション」です。

切り分けのポイント：設定ミス系か、テナント側の制限か

同じ「ログインできない」でも、原因によって取るべき行動が変わります。まずは次の観点で状況を整理してください。

観点	確認すること	それっぽい場合	次にやること
影響範囲	他テナント/他アカウントはサインインできるか	他は入れるが、このテナントだけ不可	テナント固有の問題として切り分けを進める
エラーの性質	「パスワード誤り」「MFA」ではなく AADSTS5000224 か	サポート連絡を促す画面、Trace/Correlation が出る	保護措置/テナント状態を疑う
再現性	別ブラウザー/シークレットでも同じか	同じ	キャッシュではなくサーバー側の可能性が上がる
サインイン経路	Azure ポータル直アクセス/Entra 管理センター直アクセスの双方でどうか	どちらも不可	アプリ個別ではなくディレクトリ/テナントの可能性

この表で「テナント固有」「AADSTS5000224」「シークレットでも再現」が揃う場合、利用者側で粘るよりもサポート連絡を前提に動いた方が復旧が早いことが多いです。

最短で復旧するための対処手順

テナントを明示したURLで Azure ポータルにアクセスして試す

スレッド事例でも有効だったのが、テナントを明示した URL で Azure ポータルへアクセスする方法です。Azure ポータルは「どのテナントのコンテキストで開くか」を URL 側で固定できることがあり、通常アクセスで失敗しても、テナント固定で入れるケースがあります。

代表的な指定方法のイメージは次の通りです（環境やタイミングで URL の形式が変わることがあるため、まずは“テナントIDまたはテナントドメインを明示する”ことを意識してください）。

目的	指定例（イメージ）	ポイント
テナントIDで固定	portal.azure.com/<tenant-id>	テナントID（GUID）を明示して開く
テナントドメインで固定	portal.azure.com/#@<tenant-domain>/	onmicrosoft.com などのドメインでコンテキストを固定

上記で入れた場合は、まず管理画面で「ディレクトリの切り替え」や「サブスクリプション表示」を確認し、通常アクセスとの差分（どこで落ちていたか）を把握してください。入れない場合でも、次の手順に進む判断材料になります。

ブラウザー要因を排除する（シークレット/別プロファイル/別端末）

テナント側の問題であっても、ログイン周りはブラウザーのキャッシュやアカウント選択の状態に左右されます。サポートへ連絡する前に、次だけは短時間で確認しておくとスムーズです。

• シークレット（プライベート）ウィンドウで同じ操作を試す
• 別ブラウザー（Edge / Chrome など）で試す
• 同一ブラウザーでも別プロファイル（仕事用/個人用）で試す
• 可能なら別端末/別ネットワークでも試す

これらを試しても AADSTS5000224 が変わらないなら、「ローカル要因ではない」可能性が高くなり、サポートに渡す材料としても有効です。

Microsoft サポート（または Microsoft Q&A）へ復旧を依頼する

テナントの保護措置が疑われる場合、最終的に必要になるのがMicrosoft 側での解除対応です。自社で完結しにくい領域なので、早めにエスカレーションしてください。

ただし、ここで注意したいのが「問い合わせに必要な情報の扱い」です。テナントのドメインや管理者 UPN は、状況によっては個人情報・機密情報に該当します。公開スレッドやSNSに貼らず、サポートチケットや担当者とのメールなど、非公開の経路で共有しましょう。

共有を求められやすい情報	例	注意点
影響テナントの onmicrosoft.com ドメイン	contoso.onmicrosoft.com	公開スレッドに書かない
テナントID（Directory ID）	00000000-0000-0000-0000-000000000000	必要な範囲に限定して共有
グローバル管理者の UPN	[email protected]	個人特定につながる可能性あり
エラー画面の Trace ID / Correlation ID / Timestamp	エラー画面に表示	スクリーンショット共有時は不要部分をマスク
発生日時と影響範囲	「2025/xx/xx から」など	時刻は可能なら UTC/ローカル併記

問い合わせ時は「何が起きているか」「いつからか」「どのテナントか」「どんなエラーか」「切り分けで何を試したか」を短く整理すると、初動が早くなります。

同様の事象がある場合は“新規問い合わせ”で状況をまとめる

同じエラーが他の利用者にも起きている場合でも、既存スレッドへの便乗より、自分の環境の情報（発生日時・エラー全文・テナント情報）をまとめた新規問い合わせの方が、個別に状況を追ってもらいやすい傾向があります。

特に、テナント情報は公開できないことが多いため、最初から「非公開で共有可能である」旨を明記しておくと、やり取りがスムーズです。

問い合わせテンプレート（サポート/コミュニティ向け）

そのまま貼り付けて使えるよう、最小限のテンプレートを置いておきます。角括弧の部分を自分の環境に置き換えてください。

件名：Azure ポータル / Entra ID で特定テナントにサインインできない（AADSTS5000224）

発生日時：
・[YYYY/MM/DD hh:mm] 頃から（日本時間）
・継続中 / 断続的

影響範囲：
・このテナントのみサインイン不可（他テナントは正常 / 未確認）
・影響ユーザー：全員 / 特定ユーザー（[人数]）

エラー：
・AADSTS5000224: We are sorry, this resource is not available.
・Trace ID：[xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]
・Correlation ID：[yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy]
・Timestamp：[YYYY-MM-DDThh:mm:ssZ]

切り分けで試したこと：
・シークレットウィンドウ：再現
・別ブラウザー：再現
・テナントを明示した URL：成功/失敗（[結果]）

共有可能な情報（非公開経路で提供します）：
・テナントID / onmicrosoft.com ドメイン
・グローバル管理者 UPN

よくある誤解：パスワードやMFAの問題とどう違う？

「ログインできない＝資格情報が間違っている」と思いがちですが、エラーコードを見ると方向性が変わります。代表的なエラーとニュアンスの違いを表にしました。

エラー例	よくある原因	利用者側で直せる？	まずやること
AADSTS5000224	テナント/リソースが利用できない、保護措置、テナント状態の問題	難しい（サポート解除が必要なことが多い）	テナント固定 URL → だめならサポートへ
AADSTS50126	ユーザー名/パスワード不一致	可能	資格情報の確認、パスワードリセット
AADSTS50076 / 50079	MFA が必要/登録が必要	可能	MFA 登録、認証アプリの復旧
AADSTS53003	条件付きアクセスでブロック	可能（管理者がポリシー修正）	どの条件で拒否されたか確認
AADSTS50034	ユーザーが見つからない/ディレクトリ違い	可能	サインイン先テナント、UPN、アカウント種別を確認

もちろん例外はありますが、AADSTS5000224 が出ていて、かつ昨日まで動いていたのに急に止まった場合は、「自分の設定ミス」より「テナント側で止められている」可能性を優先して考えた方が復旧が早いです。

やってはいけないこと：復旧を遅らせがちな落とし穴

テナント側の保護措置が疑われる局面では、善意の対応が裏目に出ることがあります。次のような行動は「原因の特定を難しくする」「サポートとの会話が長引く」ことがあるため、最小限に留めるのが無難です。

やりがちな行動	なぜ危険か	代わりにやること
管理者のパスワードを闇雲に何度も変更する	影響範囲の切り分けが崩れ、監査上の説明も増える	まずは AADSTS5000224 の画面情報（Trace/Correlation）を保存し、サポートへ提示
条件付きアクセスやセキュリティ設定を勘で大量に変更する	復旧後に“何が原因だったか”が分からなくなり、再発防止が難しくなる	変更するなら 1 つずつ、変更日時と内容を記録して実施
公開掲示板にテナントIDや管理者UPN、画面のスクリーンショットをそのまま貼る	攻撃者にヒントを与える可能性がある（組織や管理者が特定される）	公開は「症状・エラーコード・発生日時」まで。識別子は非公開経路で共有

テナント固定URLを試すときのコツ

テナントを明示した URL で試す場合、次の点を意識すると成功率が上がります。

• アカウント選択画面で、意図した仕事用アカウントを選ぶ（個人用 Microsoft アカウントが混ざると挙動が変わる）
• 複数アカウントを使い分けている場合は、ブラウザーのプロファイルを分ける（同一プロファイル内のクッキーが干渉しやすい）
• URL で入れた後は、Azure ポータル上部のディレクトリ表示が狙ったテナントになっているか必ず確認する

「URL で入れた＝完全復旧」とは限りません。入れるようになった後も、管理センターやサブスクリプション画面で権限・表示が正しいかを確認し、必要ならサポートに追加連絡して状況を共有してください。

復旧後にやっておきたい：再発防止のための運用チェック

サインインが復旧したら、それで終わりにせず、同じ事象に備えた最低限の運用を整えておくと安心です。特に“突然ログインできない”は、復旧まで業務が止まりやすいトラブルなので、二度目を防ぐ価値が大きいです。

緊急用（ブレークグラス）アカウントの用意

• 条件付きアクセスの対象外にする緊急用管理者を用意（多要素認証は別の形で担保）
• 普段使いしない・監査/アラートを強めにして保管
• 管理者が退職/異動しても維持できる管理方法にする

サインイン/監査ログの監視と通知

• 異常なサインイン（国/匿名プロキシ/短時間多発）を見逃さない
• 管理者権限の付与、アプリ登録、同意（Consent）のイベントは通知する
• フィッシングに備え、ユーザー教育と通報窓口を整備する

問い合わせ情報を「すぐ出せる形」で保管する

いざサポートへ連絡するとき、テナントIDや契約情報がすぐ出せないと、それだけで復旧が遅れます。次の情報は社内の安全な場所にまとめておくのがおすすめです。

保管しておきたい情報	理由	保管のコツ
テナントID / 主要ドメイン	サポートがテナント特定に使う	運用台帳に記載、閲覧権限を限定
管理者アカウント一覧（役割/所有者）	連絡先・復旧時の確認に必要	定期棚卸し（四半期など）
サポート契約情報（プラン/窓口）	緊急連絡の経路を確保	電話/フォームなど複数手段を準備
直近の構成変更履歴（CA ポリシー等）	原因切り分けの材料になる	変更管理のログを残す

現場で役立つ小技：復旧までの“止血”アイデア

サポート対応には時間がかかることもあります。業務影響を抑えるために、状況に応じて次のような“止血策”を検討してください（無理に適用せず、セキュリティと業務影響のバランスで判断します）。

• 他テナントで動いている管理者がいるなら、連絡・状況共有の窓口を一本化する
• 影響テナントに紐づくアプリ/自動処理（Runbook、CI/CD など）が止まる場合は、代替手順を暫定運用する
• ユーザー向けには「原因調査中」「復旧見込みはサポート回答待ち」とだけ伝え、誤ったパスワード変更誘導をしない

特に、根本原因がテナント保護措置の場合、むやみに設定をいじると説明が難しくなったり、復旧後の整合性確認が増えたりします。試すことは最小限にし、試した内容を記録してサポートに渡すのが結果的に近道です。

まとめ：AADSTS5000224 で特定テナントに入れないときの最短ルート

AADSTS5000224（We are sorry, this resource is not available.）で Azure ポータル／Entra ID の特定テナントにログインできない場合、まずはテナントを明示した URLで入れるかを試し、だめならTrace ID / Correlation IDを添えて Microsoft サポート（または Microsoft Q&A）に復旧を依頼するのが最短ルートです。公開の場にテナント情報や管理者 UPN を出さず、非公開経路で必要情報を共有することも忘れないでください。