Azure ポータルや Microsoft Entra 管理センターにサインインしようとすると「AADSTS5000224」が表示されてログインできない――この症状は、ブラウザーの不具合というより “テナント側の状態” が原因で発生することが多いエラーです。この記事では、エラーの意味、現場で役立つ切り分け手順、Microsoft サポートへ依頼する際の準備、復旧後の再発防止までをまとめて解説します。
症状：AADSTS5000224 が出ると何が起きているのか
AADSTS5000224 は、Azure ポータル（portal.azure.com）だけでなく、Microsoft Entra（旧 Azure AD）を認証基盤として使うさまざまな画面・アプリで発生し得ます。典型的には、サインイン画面の直後に以下のような表示が出て、先へ進めません。
Sign-in failed
Error code: AADSTS5000224
Error message: The tenant you are trying to access has been deauthenticated and is no longer available. …
Try signing in using a new or private browser window. If you are a member of another tenant, you can sign in using:https://portal.azure.com/{tenant-id}orhttps://portal.azure.com/{tenant-domain}.
Error details: … AADSTS5000224: We are sorry, this resource is not available. If you are seeing this message by mistake, please contact Microsoft support.
ここで重要なのは、エラーメッセージ自体が「このテナントは deauthenticated（認証が無効化されていて利用できない）」と明言している点です。つまり、入力したパスワードが間違っている・MFA が通らない、といった “ユーザー単体の認証失敗” とは性質が異なります。
実際、Microsoft Q&A 上でも「Teams ユーザーが Teams にアクセスできず、Azure 管理センターへ入ろうとして AADSTS5000224 に遭遇した」という報告があります。影響範囲が Azure ポータルだけに見えないのは、このエラーが “テナント単位” の状態に紐づくためです。
AADSTS5000224 の意味：テナントが “利用不可状態” にされている
AADSTS5000224 は、ざっくり言うと「そのテナントに対してトークン発行（認証）ができない状態になっている」ことを示します。ユーザーの PC やスマホのキャッシュが壊れているのではなく、サインイン先の “部屋（テナント）” 自体に入室制限が掛かっているイメージです。
Microsoft Q&A のモデレーター回答では、AADSTS5000224 は「最近のセキュリティ インシデント等を理由に、対象 Azure テナントの認証が一時的に無効化されている状況で発生することが多い」と説明され、復旧には Microsoft 側（エンジニアリング チーム）の対応が必要だと案内されています。
また、同じく Q&A の別回答では、deauthenticated になる背景として「ディレクトリが削除された／移行された／構成上の問題がある」といった可能性にも触れられています。つまり、原因は 1 つに固定されませんが、共通点は “テナント側の状態異常” であることです。
エラーメッセージの文言を実務向けに読み替える
| 表示されがちな文言 | 実務での読み替え | 示唆 |
|---|---|---|
| The tenant you are trying to access has been deauthenticated | テナント単位で認証が止められている | ユーザー操作だけでの復旧は難しい |
| Try signing in using a new or private browser window | セッション要因を切り分けてね | “切り分け” には有効だが根本解決とは限らない |
| sign in using: portal.azure.com/{tenant-id} | テナントを明示して入室先を固定してね | 誤テナント選択・ディレクトリ切替ミスの除外に使える |
| please contact Microsoft support | 最終的に Microsoft 側対応が必要 | 復旧はサポート経由の調査・再有効化が王道 |
なぜ「キャッシュ削除」や「別ブラウザー」だけでは直らないのか
サインイン問題の多くは、端末側（Cookie、セッション、拡張機能、プロキシ）で起きます。しかし AADSTS5000224 の主戦場はそこではありません。誤った対処を続けると、復旧までの時間だけが延びやすいので、まずは “どちらの層の問題か” を切り分けるのが近道です。
| 観点 | 端末・ブラウザー起因の例 | テナント起因（AADSTS5000224 で多い） |
|---|---|---|
| 再現性 | 特定 PC / 特定ブラウザーでのみ起きる | PC・ブラウザー・回線を変えても起きる |
| 影響範囲 | 特定アプリだけ・特定アカウントだけ | 同一テナントに向かう認証が広く失敗する |
| 対処の主語 | ユーザーが自分で直せることが多い | 管理者・サポート対応が必要になりやすい |
特に、メッセージに Trace ID / Correlation ID / Timestamp が出る場合は、サポート側の調査（ログ追跡）で非常に重要になるため、画面のスクリーンショットやテキストの控えを必ず残しておくと後工程がスムーズです。
まずやる切り分け：短時間で確認できるチェックリスト
根本原因がテナント無効化だとしても、現場では「本当にそれか？」を短時間で確かめる必要があります。以下は、手戻りが少ない順に並べたチェックリストです。
基本チェック
- プライベート ウィンドウで再試行 セッション残りや別アカウント自動選択を除外します。エラーメッセージ自体にも案内が出ることがあります。
- テナントを明示指定してアクセス 可能なら、以下の形式で “入るテナント” を固定します。
https://portal.azure.com/{tenant-id}https://portal.azure.com/{tenant-domain}
- 他テナントに入れるか確認 複数テナントに所属している場合、他テナントは正常で “特定テナントだけ失敗” なら、テナント固有の問題と判断しやすくなります。
CLI / 自動化で起きているかも確認（運用・開発向け）
ポータルだけでなく、Azure CLI や自動化（CI/CD、スクリプト）でも同様の認証エラーとして顕在化することがあります。実例として、az login で interaction_required: AADSTS5000224 が出る報告があります。
az login --tenant {tenant-id}ここで CLI でも同系統のエラーになるなら、ブラウザー固有の問題ではない確度がさらに上がります（もちろん、ネットワーク制限や条件付きアクセス等は別途あり得ますが、AADSTS5000224 の文言が出る場合は “テナント状態” に注目すべきです）。
チェック結果の読み取り早見表
| やったこと | 結果 | 示唆 | 次にやること |
|---|---|---|---|
| プライベート ウィンドウ | 改善しない | セッション要因の可能性が下がる | テナント明示指定へ |
| テナント明示指定 | 同じ AADSTS5000224 | 誤テナント選択ではない | 管理者へ連絡・サポート準備 |
| 他テナントへサインイン | 他は成功、対象だけ失敗 | 対象テナント固有の問題 | 対象テナント情報を集める |
| Azure CLI でログイン | 同じ AADSTS5000224 | ブラウザー依存ではない | Microsoft サポートの出番 |
結論：解決には Microsoft サポート（または社内サポート）への依頼が必要
AADSTS5000224 は、ユーザー側で “解除” できるタイプのエラーではないことが多く、最終的には Microsoft 側の調査・再有効化プロセスが必要になります。Microsoft Q&A の案内でも、エンジニアリング チームと連携して認証を再有効化する流れが示されています。
ポイントは「サポートに投げる前に、必要情報を揃えておく」ことです。これができていると、往復回数が減り、復旧までの時間を短縮できます。
サポートへ渡すべき情報（チェックリスト）
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 影響テナントの識別子 | xxxx.onmicrosoft.com / {tenant-id} | どのテナントを調査するか確定するため |
| グローバル管理者（Global Administrator）の UPN | [email protected] | 所有・管理権限の確認、連絡先の特定に使う |
| Microsoft 社員かどうか（該当時） | Work ID | 社内ルート／社外ルートの切り分け |
| テナントの用途 | 本番 / 開発 / 検証 / 学習 | 影響度により優先度・対応方針が変わる |
| 影響（インパクト） | Teams が利用不可、業務停止、限定影響など | 緊急度の判断材料 |
| エラー詳細 | Trace ID / Correlation ID / Timestamp | サポート側がログを追跡する鍵 |
なお、Microsoft Q&A でも「これらは個人情報を含むのでプライベートメッセージで共有してほしい」と案内されています。公開掲示板や社外へ貼り付けるログには十分注意してください。
テナント ID が分からないときの “探し方”
現場で一番詰まりやすいのが「テナントに入れないのでテナント ID を確認できない」という鶏卵状態です。まずは “過去のどこかに必ず残っている” という前提で探索すると見つかりやすくなります。
| 探す場所 | 具体例 | ヒント |
|---|---|---|
| 過去メール | 初期セットアップ通知、請求・契約関連、サービス通知 | 件名に「Azure」「Microsoft Entra」「tenant」などで検索 |
| IaC / リポジトリ | Terraform / Bicep / ARM / GitHub Actions | tenantId 文字列検索が最速 |
| ローカルのスクリプト履歴 | PowerShell、Azure CLI | 以前使っていた --tenant の値を発掘 |
| 社内台帳・運用メモ | 環境管理表、構成図、引き継ぎ資料 | 本番なら高確率で残っている |
| 関係者への確認 | 別の管理者、請求担当、導入支援ベンダー | “誰かの手元のメモ” が最後の砦 |
Q&A の回答でも「Tenant ID や Subscription ID はトラブル対応・復旧で重要なので、今後は安全な場所に記録しておくべき」といった趣旨の助言があります。復旧後の再発防止としても、ここは強く意識しておくと事故対応が楽になります。
サポート依頼文のテンプレ（そのまま使える形）
サポートや社内窓口に投げるときは、最初の一通に情報を詰め込むほど往復が減ります。以下をベースに、分かる範囲で埋めて送るのがおすすめです。
件名: AADSTS5000224 によりテナントへサインインできない（テナント再有効化の依頼）
■事象
- Azure ポータル/Entra 管理センターにサインイン不可
- エラーコード: AADSTS5000224
- エラーメッセージ: tenant has been deauthenticated ...（全文添付）
■影響テナント
- テナントドメイン: {xxxx}.onmicrosoft.com
- テナントID(GUID): {tenant-id}（不明なら「不明」）
■管理者情報
- グローバル管理者 UPN: admin@{xxxx}.onmicrosoft.com
- （該当する場合）Microsoft Work ID: {work-id}
■用途/影響
- 用途: 本番 / 開発 / 検証 / 学習
- 影響: （例）Teams が利用不可、業務影響あり、検証のみで影響軽微 など
■エラー詳細（分かる範囲で）
- Trace ID:
- Correlation ID:
- Timestamp:
■補足
- プライベートブラウザーでも再現
- テナント明示指定（portal.azure.com/{tenant-id}）でも再現
- 他テナントはサインイン可能よくある原因パターンと、判断のための考え方
AADSTS5000224 の背景は 1 つに限りません。ただし、どのパターンでも「ユーザー側の操作で直し切る」のは難しい点は共通です。ここでは、切り分けの “考え方” を整理します。
| パターン | 状況の例 | 見え方（サインイン時） | まずやること |
|---|---|---|---|
| セキュリティ起因で一時停止 | 侵害疑い、異常な操作が検知された等 | 急に AADSTS5000224、同テナント配下が広く影響 | サポートへ状況共有（インパクト明記） |
| ディレクトリ削除・移行・構成不整合 | 統合・移管、検証テナント整理、設定不整合 | deauthenticated と出て利用不可 | テナント識別子を確定し、履歴や関係者確認 |
| （参考）長期未使用テナントのブロック | 未使用テナントが非アクティブ扱い | 別コード（例: AADSTS5000225）で案内されることがある | 反応期限がある場合があるので早めに確認 |
参考として、未使用テナントが “非アクティブによりブロック” されたケースでは、AADSTS5000225 として案内され、一定期間内の再有効化リクエストや期限に関する説明があります（AADSTS5000224 と混同しやすいため、コードの違いは意識してください）。
復旧後にやっておくと強い：同じ事故を繰り返さない運用のコツ
テナントが再有効化できた（あるいは復旧の見通しが立った）タイミングで、次の “仕組み化” を入れておくと、次回の障害対応が一気に楽になります。ここは一般論ではなく、AADSTS5000224 のような「入れない」系トラブルに効く実務ポイントです。
テナント識別情報を「安全に」保管する
- テナント ID（GUID）、初期ドメイン（
onmicrosoft.com）、主要サブスクリプション ID を、運用台帳（アクセス制御された場所）に保管する - CI/CD や IaC 内に埋め込む場合は、リポジトリ直書きではなくシークレット管理へ寄せる
- 「誰がどこに問い合わせるか（契約窓口、サポートプラン、社内連絡先）」も台帳にセットで残す
管理者の “詰み” を避ける（運用設計）
- グローバル管理者が 1 人だけ、1 アカウントだけ、になっていないかを定期点検する
- 退職・異動・アカウント停止の運用に、管理者ロールの棚卸しを組み込む
- 緊急時にサポートへ渡せる情報（テナント用途、影響範囲、代表連絡先）をテンプレ化しておく
「セキュリティ要因で止められた」前提で、初動も用意しておく
- サインイン不能を “単なる障害” と決めつけず、侵害疑いも含めた初動（関係者連絡、影響範囲確認、証跡保全）を用意する
- 復旧後は、直近の変更（ユーザー/アプリ/条件付きアクセス/ID連携）をレビューし、心当たりがあるならサポートへ共有する
開発者向けメモ：エラーコードの参照方法
アプリや自動化から AADSTS 系エラーを扱う場合、エラーコードや文言が将来的に変更される可能性がある点に注意が必要です。Microsoft Learn のエラーコード参照ページでは、最新のエラー情報は https://login.microsoftonline.com/error で確認でき、コードを付けて直接参照できる旨が案内されています。
運用の現場では、ユーザーから受け取ったスクリーンショットの「コード」「Trace/Correlation」「時刻」をセットで保管しておくと、サポートへのエスカレーションが速くなります。
よくある質問
プライベートブラウザーでも直りません。もう打つ手はないですか？
切り分けとしては正しい手順です。ただし AADSTS5000224 は “テナント側” の状態が原因であることが多く、ユーザー側での復旧は難しいケースが多いです。テナント情報とエラー詳細を揃え、管理者経由で Microsoft サポートに依頼するのが現実的です。
他のテナントには入れます。対象テナントだけ AADSTS5000224 です。
その場合、端末やアカウント全体の問題ではなく「対象テナント固有の問題」である可能性が高まります。テナント ID / ドメイン、管理者 UPN、Trace/Correlation を揃えてエスカレーションしてください。
Azure CLI でも同じエラーになります。
CLI で interaction_required: AADSTS5000224 が出る報告もあり、ブラウザー依存の問題ではないことを裏付ける材料になります。ポータルと CLI の双方で同様なら、サポート調査へ進む判断がしやすくなります。
まとめ
- AADSTS5000224 は「テナントが deauthenticated（認証が無効化）で利用できない」状態を示すエラーで、キャッシュ削除などユーザー側の操作だけでは解決しないことが多い。
- まずはプライベートブラウザー、テナント明示指定、他テナントとの比較、CLI での再現確認で “テナント起因” の確度を上げる。
- 解決の王道は、テナント ID（または
onmicrosoft.comドメイン）、グローバル管理者 UPN、用途/影響、Trace/Correlation/Timestamp を揃えて、Microsoft サポート（または社内サポート）へ再有効化を依頼すること。 - 復旧後は、テナント識別情報の安全な保管、管理者体制の点検、初動テンプレ化で “次の詰み” を防ぐ。
コメント