Azure サインインで「AADSTS5000225: このテナントは非アクティブのためブロックされています」と表示されてポータルに入れない――本記事は、その原因・猶予期間・解除依頼の書き方から、復旧できない場合の打ち手、再発防止策までを実務視点で網羅します。対応の優先度やチェックリストも用意し、すぐに現場で使える形にまとめました。
Azure テナントが AADSTS5000225 でブロックされたときの全体像
まずエラーの正体を押さえます。AADSTS5000225 は テナント（Microsoft Entra ID／旧 Azure AD）自体が「非アクティブ扱いでブロック」されている状態で、通常のユーザー／管理者サインインができません。サブスクリプションの有効・無効とは別管理であり、課金状態を復活させてもディレクトリのブロックが自動解除されるわけではありません。
Error code: AADSTS5000225
このテナントは非アクティブのためブロックされています
(This tenant is not active. It is blocked.)要点の早見表（結論）
| 要点 | 詳細 |
|---|---|
| ブロックが発生する条件 | 最終課金サイクルから約 200 日間にわたりアクティビティ（サインイン・課金・API 呼び出し等）がまったく無いと、Microsoft Commerce（OMS）側でディレクトリに「ログインブロック」が自動付与され、AADSTS5000225 が返されます。 |
| 猶予期間 | ブロック後およそ 20～30 日以内に解除依頼を行わないと、自動削除に進むリスクがあります。公式情報は 20 日／30 日の両表現が混在するため、20 日以内の着手を推奨します。 |
| 解除手順（概要） | 1) まだ削除されていないことを確認 2) Microsoft サポート（推奨）または Microsoft Q&A のモデレーターへ連絡 3) 次の 3 点を必ず提示： ・テナント ID またはカスタム ドメイン名 ・影響を受ける管理者メールアドレス ・ビジネス影響と復旧不可時のリスク説明 |
| Microsoft 側の対応 | 依頼が受理されると内部のプロダクト グループがテナント状態を「Blocked」→「Active」に戻します。復旧完了後、Azure ポータルへのログインが再び可能になります。 |
| 解除できない場合 | 猶予超過により既に自動削除済みなら復旧不可。検証・テスト用途なら「Microsoft Entra ID で新規テナントを作成」して再構築します。 |
ブロックの判定と初動（最優先で 20 日以内に着手）
まず「ブロック中」なのか「削除済み」なのかを見極めます。次の観点を確認してください。
- サインイン挙動：上記メッセージ（AADSTS5000225）が返るなら「ブロック中」の可能性が高いです。「該当テナントが見つからない」旨の別コードに変わっている場合は削除済みのシグナルです。
- メール・通知：従来の管理者連絡先に「テナント非アクティブ／自動ブロック」の案内が届いている場合があります。組織内の共有メールボックス・メーリングリストも確認してください。
- DNS 上のドメイン所有：テナントで検証済みのカスタムドメインが引き続き自組織に紐付いているか（TXT 証跡など）はサポートでの所有確認に役立ちます。
重要：「ブロックから削除」へは自動遷移し得ます。20 日以内を硬い締切として、後述の解除依頼に直ちに進んでください。
なぜ 200 日でブロックされるのか（仕組みの理解）
Microsoft Commerce（OMS）は、利用や課金が長期にわたり完全に停止しているテナントを「非アクティブ」と判定し、ディレクトリへログインブロックを付与します。ここでいう「利用」には以下が含まれます。
- サインイン（Azure ポータル、Microsoft 365 管理センター、Graph Explorer など）
- API 呼び出し（Microsoft Graph、Azure Resource Manager など）
- 課金アクティビティ（サブスクリプションの消費・請求発生）
逆に言えば、上記のいずれも 200 日間発生しないと、テナントは「だれも使っていない資産」とみなされ、誤用・放置リスクの観点からログインブロックが付与されるという理屈です。
なお、「サブスクリプションが無効」でもテナントは別管理です。課金を再開しても、OMS のブロックは自動解除されません。ディレクトリ（Entra ID）を「Active」に戻す操作は Microsoft 側の内部手続きが必要です。
解除依頼の前に準備する 5 つの情報
サポートは「そのテナントの正当な所有者」からの依頼であることを重視します。スムーズに進めるため、以下をまとめましょう。
- テナント ID（GUID）またはカスタム ドメイン名（例：contoso.onmicrosoft.com、contoso.com）
- 影響を受ける管理者アカウント（メールアドレス）
- ビジネス影響の説明（生産停止・顧客影響・法令順守の観点など定量的に）
- 所有証明の用意（必要に応じて TXT レコード追加などで証明可能である旨）
- 希望する対応期限（猶予 20 日内であること、業務上の締切日）
所有証明では、DNS に TXT レコードを追加してもらう方法が一般的です。サポート指示に従い、次のようなレコードを一時的に設定する準備をしておきます。
| 項目 | 例 |
|---|---|
| タイプ | TXT |
| ホスト名 | @（ルート）または指定名 |
| 値 | MS=msXXXXXXXX（サポートから提示される一意の文字列） |
| TTL | 3600 など（任意） |
解除依頼の進め方（ステップ別の実務フロー）
ステップ 1：ケース起票（Microsoft サポート推奨）
組織のサポート契約がある場合は Microsoft サポートへケース起票します。契約が無い・管理者ポータルへ入れない場合は、Microsoft Q&A でモデレーターに連絡する方法もあります。いずれも外部公開の情報は控え、テナント ID 等はプライベートメッセージ／チケット内でやり取りします。
ステップ 2：提出テンプレート（コピペ用）
件名：AADSTS5000225 によるテナント ログインブロック解除依頼
・テナント ID（または onmicrosoft.com / カスタムドメイン）：
・影響を受ける管理者アカウント：
・最終利用時期（概算で可）：
・ビジネス影響（定量的／定性的に）：
・所有証明の実施可否（DNS TXT 追加など）：
・希望対応期限（猶予 20 日以内）：
補足：
・今後の利用計画（運用再開の具体策）
・連絡可能な時間帯／代替連絡先ステップ 3：サポートからの確認事項に即応
- 所有証明要求（DNS TXT）への対応
- 管理者本人確認（本人の会社メール宛てコード検証等）への対応
- ビジネス影響の追記（障害・契約・監査の期限等）
ステップ 4：内部処理（Microsoft 側）と復旧確認
サポートが依頼を受理するとプロダクト グループにエスカレーションされ、テナント状態が Blocked → Active に変更されます。数分～数十分快後を目安に、Azure ポータルや CLI へのサインインが成功するかを確認してください。
# 復旧確認（例）
# ブラウザで Azure ポータルへサインイン
# または CLI
az login
az account show # tenantId が表示されることを確認ステップ 5：回復後の後処理
- 全管理者の緊急アクセス（ブレークグラス）口座の確認（使用期限・パスワード期限・MFA 設定）
- サインイン リスク・条件付きアクセスの有効化とレビュー
- 監査ログ／サインインログの確認（ブロック前後の不審動作）
- 運用再開計画の実施（後述の再発防止策）
もし解除できない（削除済み）場合の現実的対処
猶予超過により自動削除に進んだテナントは復旧できません。この場合の打ち手を用途別に整理します。
| 用途／要素 | 移行・再構築の方向性 |
|---|---|
| ユーザー／グループ | 新規テナントを作成し、ユーザー情報を再作成（人事台帳・バックアップ CSV から再投入）。UPN とメールアドレスの整合に注意。 |
| アプリ登録（App registrations） | アプリの再登録・クライアント ID／シークレット再発行。リダイレクト URI・スコープを復元。依存システム側の構成値更新が必要。 |
| サービス プリンシパル／企業アプリ | 外部 SaaS との SSO はフェデレーション再設定。証明書更新・メタデータ書き換えを実施。 |
| カスタム ドメイン | 旧テナント削除後にドメインが解放されるまで待機し、新テナントで再検証（TXT／MX 等）。解放までの時間差に注意。 |
| Microsoft 365／Azure リソース | サブスクリプションやメールボックス等はテナントに強く結合。原則として新規配備・再構築が必要。 |
現場で迷いやすいポイントとベストプラクティス
テナントとサブスクリプションの違い
- テナント（Entra ID）：組織の ID 基盤。ユーザー・グループ・アプリ登録など。
- サブスクリプション（Azure 請求単位）：課金・リソース管理の単位。テナントに関連付くが別管理。
この違いを誤解すると「課金を再開したのに入れない」という事態になります。AADSTS5000225 はディレクトリ側のブロックである点に注意してください。
「自己解決」できない理由
Azure ポータルや CLI はディレクトリに対する認証に依存しており、ブロック中は管理者自身もアクセスできません。自己解除する UI／API は提供されていないため、Microsoft 経由での解除が必須です。
管理者が複数いる場合の連携
- 組織内の役割（情報システム、ドメイン管理者、法務・コンプライアンス、経理）を素早く束ね、ケース情報を一元管理。
- ドメイン DNS を触れる担当者を確保（TXT 追加のため）。
- 上長承認が必要な場合はひな形（後述）で迅速に決裁。
タイムライン指針（いつまでに何をするか）
| 時点 | やること | 目的 |
|---|---|---|
| 発覚当日（T+0） | 内部連絡、ケース起票、必要情報の収集（テナント ID／影響／所有証明方針） | 猶予消費を最小化。証跡を集約。 |
| T+1～2 営業日 | サポート質疑への即応（DNS TXT、本人確認、追加説明） | エスカレーションを前倒し。 |
| T+3～5 営業日 | 解除可否の判断、復旧後の後処理（ブレークグラス口座、条件付きアクセスの見直し） | セキュリティ健全化と再発防止。 |
| 猶予期限（T+20 目安） | 未解決なら優先度を最高に引き上げ、意思決定者を巻き込む | 自動削除回避の最後の防波堤。 |
よくある質問（FAQ）
Q. 「200 日」のカウントに含まれるアクティビティは？
A. サインイン、課金、API 呼び出しなど広い意味での利用が含まれます。「誰かが一度でもポータルに入る」「Graph API を定期実行する」などで非アクティブ判定は回避しやすくなります。
Q. 解除には追加料金が必要？
A. 解除自体はテナント状態の復帰操作であり、通常は「サポート チャネルの利用範囲」に依存します。契約外の場合は Microsoft Q&A ルートでモデレーターに橋渡ししてもらうケースもあります。
Q. サブスクリプションを再アクティブ化したら直る？
A. いいえ。ディレクトリのブロックは別です。テナント側の「Blocked」→「Active」変更が必要です。
Q. 自動削除後にデータは戻せる？
A. いいえ。テナントそのものが消えるため復旧不可です。新規テナントでの再構築と、ドメインの解放待ちが必要になります。
Q. 連絡先アドレスが使えない（退職・ドメイン移行等）場合は？
A. DNS による所有証明（TXT レコード追加）と組織の法的書類（登記・社名一致など）で実体確認できるよう準備してください。
再発防止：非アクティブ化を避けるための運用設計
200 日の非アクティブ判定を回避するには、低コストで確実な「生存信号」を残す運用が有効です。以下は実践例です。
| 対策 | 実施方法 | ポイント |
|---|---|---|
| 月次の管理者サインイン | 情報システム部の共有アカウント（MFA 有）でポータルにログインし、サインインログを確認 | 人依存を避けるため当番制・自動リマインダーを設定 |
| 定期的な Graph API 呼び出し | 最小権限のアプリにて「/organization」「/auditLogs」等の読み取りを月 1 回実行 | 機能停止中でも軽量に「利用実績」を残せる。秘密情報の保管とローテーションを徹底 |
| アラート設定 | サインイン失敗急増・長期未使用ユーザー・監査ログ無活動を検知するアラート ルールを構成 | アラート先にチームのメール＋チャットを併記し見逃しを防止 |
| ブレークグラス口座の定期点検 | パスワード期限・MFA・連絡先更新を四半期ごとに確認 | 緊急時のログイン不可を回避 |
| 連絡先の多重化 | テナントの技術／請求／緊急の連絡先を 2 名以上に設定 | 退職・異動時の連絡断絶を防ぐ |
内部承認用・上長向け説明テンプレート
迅速な決裁のため、要点を 1 枚にまとめて共有します。必要に応じて文面を調整してください。
件名：Azure テナント ログインブロック（AADSTS5000225）解除の至急対応について
１）状況
・最終利用から長期未使用となり、Microsoft Commerce によりテナントが非アクティブ判定。
・現在、管理者含む全ユーザーが Azure へサインイン不可。
２）期限
・ブロック後 20～30 日で自動削除の可能性 → 20 日以内の対処が必須。
３）対応
・Microsoft サポートに解除依頼を即時起票。
・DNS による所有証明（TXT）と本人確認へ即応。
・復旧後は再発防止（定期サインイン／監査アラート）を実装。
４）影響
・放置時はテナント削除 → 全構成の消失、新規構築コスト発生（X 人日／Y 週間見込み）。
以上、承認のうえ至急実施します。トラブルシューティング補遺：似た症状との見分け方
| 現象 | 原因の傾向 | 初期対応 |
|---|---|---|
| AADSTS5000225（本件） | テナントが OMS により非アクティブ判定 → ログインブロック | 猶予 20 日以内に解除依頼。所有証明と本人確認を準備 |
| 「このテナントが見つかりません」系 | テナント削除済みまたはドメイン解放済み | 復旧不可。新規テナントで再構築計画へ |
| 多要素認証で止まる | MFA ポリシー／条件付きアクセスの誤設定 | ブレークグラス口座でサインインし、ポリシーを是正 |
| AD FS／フェデレーションで止まる | 証明書期限切れ・フェデレーション障害 | フェデレーション設定の修正または一時的にクラウド認証へ |
ケーススタディ：中小企業での復旧シナリオ例
以下は実務に即した想定シナリオです。自社の体制・ツールに合わせて読み替えてください。
- 発覚：管理者が久々にポータルへ入ろうとして AADSTS5000225 を確認。
- 準備：テナント ID・影響・所有証明（TXT 追加可）を 1 時間で整理。
- 起票：サポートへケースを送信。希望期限を「猶予 20 日以内・業務停止中」と明記。
- 検証：サポートからの TXT 指示に即応し、10 分で DNS 追加。伝播を待機しながら本人確認を完了。
- 復旧：同日中に Blocked → Active に変更。サインインと CLI 動作を確認。
- 後処理：定期サインイン当番表・Graph 月次実行のオートメーション・監査アラートを設定。
チェックリスト（コピペして使える）
- [ ] AADSTS5000225 のスクリーンショットを取得（時刻入り）
- [ ] テナント ID／ドメイン名を確認
- [ ] 影響範囲（部門／顧客／法的期限）を整理
- [ ] DNS 管理者の手配（TXT 追加可否の確認）
- [ ] サポート起票（希望期限は 20 日以内を明記）
- [ ] サポートからの照会に 1 営業日以内で回答
- [ ] 復旧後の後処理：ブレークグラス／条件付きアクセス／監査ログの見直し
- [ ] 再発防止（定期サインイン／Graph 実行／アラート）を実装
まとめ：最短で安全に元へ戻し、二度と起こさない
AADSTS5000225 は「テナントの非アクティブ化」という明確な理由で発生します。20 日以内に解除依頼、所有証明と本人確認に即応、復旧後は生存信号を残す運用――この 3 点を押さえれば、ブロック解除は現実的かつ再発しない形で実現できます。放置は自動削除に直結します。今日すぐに、起票と運用改善に着手してください。
付録：担当者別の役割分担サンプル
| 担当 | タスク | 完了基準 |
|---|---|---|
| 情報システム（主担当） | ケース起票／技術説明／復旧検証／運用設計 | サインイン回復、再発防止策が運用に組み込まれている |
| ドメイン管理者 | DNS TXT 設定・削除 | サポートの所有証明が通過し、不要な TXT を撤去 |
| 経理・購買 | サポート契約・請求連絡先の最新化 | 連絡が確実に届く体制へ更新 |
| セキュリティ | ブレークグラス運用と条件付きアクセスのレビュー | 緊急ログイン可能・最小権限とリスクベース制御の両立 |
| 法務・監査 | 監査ログ保全・対応記録の管理 | 証跡が監査要件を満たす形で保存されている |
付録：再構築チェック（削除済みケース）
- [ ] 新規テナント作成と基本設定（組織情報・セキュリティ既定）
- [ ] ドメイン再検証（TXT／MX／CNAME／SPF／DKIM 等）
- [ ] ユーザーとグループの再作成（CSV 取り込み）
- [ ] アプリ登録の再設定（ID／シークレット発行・権限付与）
- [ ] サービス プリンシパル（企業アプリ）の再連携（SAML／OIDC）
- [ ] サブスクリプションの新規割り当て／移行
- [ ] 条件付きアクセス・MFA・ブレークグラスの初期構成
- [ ] 監査・アラート・定期サインインの自動化
最後に：この記事を現場ですぐ使うために
上記のテンプレート・チェックリストをそのままチケットや社内ワークフローに貼り付け、担当者と期限を割り当ててください。「誰が・いつまでに・何をするか」を明文化するだけで、復旧スピードと再発防止の定着率が大きく改善します。
コメント