Azure ポータルに突然サインインできなくなり、「AADSTS5000224」や「AADSTS5000225」のエラーが表示される――この現象の大半は、Microsoft Entra ID（旧 Azure AD）のテナント自体が長期間非アクティブとなり、ライフサイクル ポリシーによりブロック・削除対象になっていることが原因です。本記事では、発生背景、判別方法、状態別の復旧手順、今後の再発防止策までを実務目線で詳説します。
Azure ポータルにサインインできない：エラー「AADSTS5000224 / AADSTS5000225」の正体
Azure ポータルのサインイン画面で次のようなメッセージが表示され、ポータルに入れないケースがあります。
AADSTS5000224: このテナントは認証解除され、利用できません
またはコード違いで AADSTS5000225 が出ることもあります。いずれも実態は「テナントが無効化（ブロック）され、ユーザー認証を受け付けない状態」を示すエラーとして扱われることが多く、対処方針は同じです。
なぜ起きるのか：ライフサイクル ポリシーと「非アクティブ ≒ 200 日」ルール
Microsoft Entra ID では、長期間利用のないテナントに対して清掃（ガバナンス）を行うライフサイクル ポリシーが適用されます。概ね次のタイムラインで状態が遷移します。
| 経過状況 | テナント状態 | ポータル/サインイン | 復旧可能性 | 実務での注意点 |
|---|---|---|---|---|
| 非アクティブ期間がおおむね 200 日に到達 | ブロック（認証受け付け停止） | Azure ポータルや管理 API へのサインインに失敗 | 高い（ブロック化から 20 日以内が目安） | 早期にサポート/管理者へ復旧依頼。影響ユーザーと理由を明確化 |
| ブロック状態が 20 日を超過 | 完全削除 | テナント自体が消滅。ログイン不可のまま | 不可（新規テナント作成が必要） | 公式上は 30 日の記載もあるが、実運用では 20 日超で復旧が困難と案内される |
要点は、非アクティブ ≒ 200 日でブロック、その後 20 日を超えると完全削除という二段階です。キャッシュ削除やシークレット ウィンドウでの再ログインは「テナントが有効」であることが前提の回避策であり、今回のようにテナント自体が無効化されている状況では効果がありません。
まず結論：状態別の最短アクション
| テナントの状態 | 推奨アクション | 伝えるべき情報 |
|---|---|---|
| ブロックから 20 日以内（まだ削除されていない） | 1) Microsoft サポートまたはテナント管理者に復旧依頼。 2) 迅速な審査のため、依頼内容を具体化。 | ・テナント ID またはドメイン名 ・影響を受けるアカウントのメール アドレス ・ビジネスへの影響と復旧を希望する理由 |
| 20 日超（＝完全削除） | 1) 復元不可のため、新しいテナントを作成。 2) 必要なリソースを再構築（ID、グループ、アプリ、RBAC 等）。 | ・新テナントの設計方針（命名、リージョン、セキュリティ基準） ・復元が必要な資産のリストと優先順位 ・関係者の合意（変更管理） |
現場で役立つ判別チャート（テキスト版）
症状: Azure ポータルで AADSTS5000224/5000225 →
├─ テナント管理者が存在する/連絡可能？
│ ├─ Yes → 管理者がテナント状態を確認（管理センター/サポート窓口）
│ │ ├─ 状態: ブロック（20日以内） → 復旧依頼へ
│ │ └─ 状態: 完全削除（20日超） → 新テナント計画へ
│ └─ No → 影響ユーザーがサポートに直接エスカレーション
└─ 個人設定/ブラウザ問題の可能性？ → 今回のケースでは低い（テナント無効化が本質）
CLI で早期に兆候をつかむ：Az CLI のヒント
ポータルに入れなくても、開発マシンや運用端末で早期に兆候を検出できます。Az CLI の例：
# ログイン済みのコンテキストで、関連付けられたテナント一覧を取得
az account tenant list --output table
# 出力例（サンプル）
# TenantId Default Domain
# ---------------------------------- ------- -------------------------
# 00000000-0000-0000-0000-000000000000 True contoso.onmicrosoft.com
# 11111111-1111-1111-1111-111111111111 False fabrikam.onmicrosoft.com
# 疑わしいテナントを選択し、サブスクリプションの参照可否を確認
az account list --all --output table ブロック中はコマンドの失敗や表示の不整合が増える場合があります。「以前は参照できたのに突然参照できなくなった」という変化は重要なサインです。
似て非なる落とし穴：サブスクリプション停止とテナント無効化は別問題
Azure のサブスクリプション（課金単位）が停止/無効化されていても、テナント（ID 基盤）さえ生きていればサインイン自体は可能です。今回のエラーはあくまでテナント側の問題です。サブスクリプション運用や請求トラブルと混同しないようにしましょう。
Microsoft 社員（FTE）向け：IcM での復旧依頼
外部顧客向けの一般手順ではなく、社内システム IcM（Incident Management） にて Tenant Re‑authentication を選択し、aka.ms/tenantreauthentication から申請します。必要な承認書類等を添付のうえ送信してください。
状態別の詳解：復旧の流れと成功率を高めるコツ
ブロックから 20 日以内：復旧依頼の要点
- 依頼先：Microsoft サポート または テナント管理者（パートナー経由でも可）
- スピード：20 日の目安をまたぐ前にエスカレーション。週末・祝日をまたぐ場合は前倒しで。
- 添付情報：テナント ID / ドメイン名、影響ユーザー、発生日、業務影響、希望期日、任意のログ（スクリーンショット等）
- 社内合意：再有効化に伴うセキュリティ ポリシーや利用目的の整合性を明確化。
- 再発防止：復旧作業と同時に、後述の予防運用の仕込みを開始。
20 日超（完全削除）：新テナント設計と移行の現実的ステップ
復元不可となった場合は、「ゼロから再構築」が前提です。優先度順に、短期リカバリーと中長期の再整備を切り分けます。
| 期間 | 目的 | 主なタスク |
|---|---|---|
| Day 0–3（緊急） | 最低限の業務復旧 | ・新テナント作成と管理者アカウント準備（Break-glass を含む） ・主要 SaaS/アプリの暫定ログイン経路の用意 ・関係部門への告知（影響範囲/復旧 ETA） |
| Week 1–2 | 基本基盤の再構築 | ・ユーザー/グループ/ロールの再作成と自動化 ・必要なサブスクリプションの紐付けと RBAC 設計 ・条件付きアクセス/多要素認証/ID 保護のポリシー整備 |
| Week 3–6 | 完全復旧と強化 | ・アプリ登録、エンタープライズ アプリ（SAML/OIDC）の再構成 ・監査/アラート/バックアップ体制の強化 ・運用文書・BCP 更新、再発防止の KPI 設定 |
AADSTS5000224 と AADSTS5000225 の違いと共通点
現場では両者とも「テナントが無効化されアクセス不可」という実質同義のシグナルとして取り扱われます。ログ収集・エスカレーションの観点では、どちらのコードが出ても対処は同じで問題ありません。
サポート依頼にそのまま使えるテンプレート
件名: 【復旧依頼】テナントがブロックされ Azure ポータルにサインイン不可（AADSTS5000224/5000225）
平素よりお世話になっております。
以下テナントにおいて、Azure ポータルにサインインできない事象が発生しております。
ブロック解除（再認証化）をご支援ください。
・テナント ID:
・ドメイン名（.onmicrosoft.com / 独自ドメイン）:
・影響ユーザー（メールアドレス）:
・発生日/検知日時:
・業務影響（停止している業務、影響人数、損失見込み等）:
・希望期日:
・添付資料（エラー画面、ログ等）:
以上、何卒よろしくお願いいたします。 「念のためやってみた」が効かない理由（キャッシュ削除・別ブラウザ）
- ブラウザ キャッシュの問題ではない：テナント側で認証を拒否しているため、クライアント側の再試行では改善しません。
- InPrivate/シークレット ウィンドウも無効：クリーンなセッションでもテナント無効化は回避できません。
- ユーザー/パスワードの再発行も意味がない：認証受付そのものが遮断されています。
監査・記録：発生から復旧までのトレーサビリティ
テナントのブロック/削除は事業継続に直結する重大インシデントです。復旧後の監査対応に備え、以下の記録を残しましょう。
- 発生日と検知ルート（アラート/問い合わせ/定期点検）
- 影響範囲（システム・ユーザー数・期間）
- 連絡体制（誰がいつ誰に何を伝えたか）
- サポートとのやり取り（ケース番号、時系列、結論）
- 恒久対策と再発防止の KPI（例：非アクティブ残日数の監視件数 0）
再発防止：200 日ルールに刺さる「実装済み運用」を作る
「気づいたら 200 日」を防ぐには、人の記憶や属人化に依存しない仕掛けが要です。
最低限の必須対策
- 定期サインインの自動化：月 1 回の自動ジョブ（サービス プリンシパル/マネージド ID）で Graph/管理 API にアクセスし、アクティビティを発生させる。
- モニタリング：「最終アクティブ日」や「サインイン無し日数」をダッシュボード化。閾値で通知。
- 運用カレンダー：組織の休眠期間（長期休暇・年度末）を考慮した前倒しチェックを登録。
- 責任者の明確化：テナントごとにオーナーと副担当を定義し、退職/異動時の引継ぎを標準化。
- Break-glass アカウント：多要素・強力な保護を施した緊急管理者を準備（ただしテナント無効化時はログイン不可になるため、早期検知が根本対策）。
推奨の実装例（擬似ワークフロー）
# 毎月 1 日 09:00 に実行
1) マネージド ID で Graph API へヘルスチェック呼び出し
2) 呼び出し結果（HTTP 200/401 等）を記録
3) 180 日相当で「黄色」、190 日相当で「橙」、195 日相当で「赤」通知
4) 196 日到達時は運用当番へ自動エスカレーション（電話/SMS）
5) 199 日到達時は管理者が明示的にサインイン実施（証跡保存）
業務影響の洗い出し：ID 基盤停止が波及する範囲
テナントが無効化されると、Azure ポータルだけでなく、Azure リソース操作、アプリ登録/Enterprise Apps、条件付きアクセスを前提とする SaaS 連携などが広く影響を受けます。Microsoft 365 と同一テナントを共有している場合は、Exchange Online / SharePoint / Teams のログインにも波及する可能性があるため、早急な社内周知が必要です。
よくある質問（FAQ）
Q. 200 日・20 日は絶対値ですか？
A. 目安です。公式説明では 30 日などの表現が見られる一方、実運用ではブロックから 20 日超で復旧が極めて難しいと案内されるケースが多いというのが現場感です。安全側で運用しましょう。
Q. 管理者が見当たらない/退職してしまった場合は？
A. 影響ユーザーが Microsoft サポートへ直接エスカレーションするか、関連するサブスクリプション/課金情報を手がかりに組織内の責任部署を特定して連携を取りましょう。
Q. 条件付きアクセスや多要素認証の誤設定でロックアウトしている可能性は？
A. それらの誤設定でもサインイン失敗は起き得ますが、AADSTS5000224/5000225 はテナント レベルの拒否を指すため、まずテナント状態の確認を優先してください。
Q. DNS/ドメイン失効が原因の可能性は？
A. 独自ドメインの失効はメールやフェデレーションに影響しますが、今回のコードはテナント無効化が本質です。切り分けのために onmicrosoft.com ドメインでの動作確認も有効です。
Q. どの操作が「アクティビティ」としてカウントされますか？
A. ポータルへの管理者サインイン、Graph/管理 API へのアクセス、アプリ登録の更新などテナントに関連する操作が対象です。完全自動化で人手の抜け漏れを防ぎましょう。
チェックリスト：発生〜復旧〜再発防止
| フェーズ | 確認項目 | 完了 |
|---|---|---|
| 検知 | エラーコードが AADSTS5000224/5000225 である | □ |
| 切り分け | ブラウザ要因ではない（他端末/ネットワークでも再現） | □ |
| 判定 | テナントがブロック中か完全削除かを確認 | □ |
| 復旧 | 20 日以内ならサポートへ復旧依頼（テンプレ使用） | □ |
| 代替 | 完全削除なら新テナントの立ち上げ計画と優先度を策定 | □ |
| 恒久 | 定期アクティビティの自動化、監視、責任者の明確化 | □ |
| 監査 | 記録（時系列/影響/対応/KPI）をドキュメント化 | □ |
トラブル事例から学ぶ「ダメなパターン」
- 担当が決まっていない：誰も「自分のテナント」と思っていないため、200 日の壁を超えがち。
- 月次点検の属人化：カレンダー登録だけで人の手に依存。異動・休暇で簡単に抜ける。
- 発見の遅れ：最初のエラーを軽視して複数日放置。週末/連休で 20 日の壁が迫る。
- 証跡不足：復旧依頼がふわっとしており、審査に時間がかかる。
復旧後にやるべき「3 つの仕上げ」
- テナント健全性のスコアリング：監視項目（最終サインイン、アプリ登録の更新日、特権アカウントの利用履歴など）を点数化。
- テストによる担保：毎月の自動ジョブに 失敗検知 を組み込み、失敗時は運用当番へ能動通知。
- BCP 反映：「ブロック → 削除」の時間軸を明記し、休日対応ルール・連絡網を更新。
まとめ
AADSTS5000224 / AADSTS5000225 は、ほぼ確実に Microsoft Entra ID テナントの無効化を示します。非アクティブ ≒ 200 日でブロック、20 日超で完全削除という現実を踏まえ、状態の早期判定と即時の復旧依頼、そして人に依らない定期アクティビティの自動化で再発を防ぎましょう。キャッシュ削除などの一般的な小手先の対処は、本件では解決策になりません。今日からできる最小の一歩は「毎月 1 回の自動アクセスと残日数の見える化」です。これだけで、次の 200 日問題を確実に回避できます。
コメント