Azure にサインインしようとしたときに「AADSTS5000225: このテナントは非アクティブのためブロックされています」と表示されると、多くの場合は課金情報やパスワードを直しても解決しません。本記事では、このエラーが出る本当の理由と、「まだ復旧できるテナント」と「完全に削除されてしまったテナント」を素早く見分ける方法、そして再発させないための運用ポイントまでを、実務目線で整理します。
AADSTS5000225 エラーとは何か
まずはエラー メッセージの意味を押さえます。Azure ポータルや Microsoft Entra 管理センター（旧 Azure AD 管理センター）にサインインしたとき、次のようなメッセージが表示されるケースがあります。
Sign-in failed
Error code: AADSTS5000225
Error message: This tenant has been blocked due to inactivity.
（日本語環境では「このテナントは非アクティブのためブロックされています」などと表示）
これは「ユーザー名やパスワードが間違っている」という認証エラーではなく、テナントそのものが課金基盤側のポリシーにより “非アクティブ扱い” になり、ログインが拒否されている状態を示します。
Microsoft のテナント ライフサイクルの説明では、長期間利用されていないテナントはコスト削減のため「アクセス不能状態（inaccessible）」に移行し、このとき AADSTS5000225 が返されるとされています。
コミュニティの Q&A では、概ね 200 日程度サインインなどのアクティビティがないテナントに対してログイン ブロックが掛かり、その後 20 日が経過するとテナントが完全削除される、という説明が繰り返し登場します。
ただし、実際の猶予期間は契約種別やポリシー変更のタイミングによって変わる可能性があるため、「○日までは絶対安全」と決め打ちせず、エラーが出た時点で即座に動くのが重要です。
テナント ライフサイクルと AADSTS5000225 発生タイミング
AADSTS5000225 は、テナントが次のようなライフサイクルを辿る途中で発生します。
| 状態 | 概要 | サインイン結果 | 復旧可否 |
|---|---|---|---|
| 通常利用中 | ユーザーのサインインやリソース利用がある通常の状態 | 成功 | 問題なし |
| 非アクティブ／ブロック | 長期間利用がなく「コスト削減のためアクセス不能」と判断された状態 | AADSTS5000225 が返される | 管理者が Microsoft に再有効化を依頼すれば、 一定期間内（目安 20 日以内）なら復旧可能 |
| 完全削除 | 非アクティブ状態のまま猶予期間を過ぎたテナント | テナント自体が存在しないため、 エラー内容も別メッセージになることがある | 復旧不可。新規テナントの作成が必要 |
Microsoft のドキュメントでは、「非アクティブ状態になってから 20 日以内であれば、管理者が Microsoft に再有効化を依頼できる」と明記されています。 一方、コミュニティの回答では「ブロックは 200 日以上の非アクティブ後に発生し、さらに 20 日経過で削除」という説明もあり、実際には内部のライフサイクル ロジックがもう少し複雑であることが伺えます。
重要なのは、AADSTS5000225 が出た瞬間が “タイマーのスタート地点” ではなく、すでに「非アクティブ判定」が行われた後だという点です。したがって、エラーを見かけた時点では、猶予はかなり短いと考えておきましょう。
最初にやるべきこと：テナントの「生死」を確認する
AADSTS5000225 が出たときに最優先で確認すべきポイントは、次の 2 つです。
- そのテナントは「まだ存在しているがブロック中」なのか
- すでに完全削除されており、論理的にも物理的にも存在しないのか
これを判断するために、まずは次の情報を揃えておきましょう。
| 項目 | 内容 | 主な用途 |
|---|---|---|
| テナント ID | GUID 形式の ID（例：aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee） | Azure ポータルや CLI でテナントを明示する／サポート依頼 |
| テナント ドメイン | xxx.onmicrosoft.com や、紐づくカスタム ドメイン | テナントの特定、ユーザーの UPN の確認 |
| 影響ユーザー | ログインできないアカウントのメールアドレス | サポートに影響範囲を説明する材料 |
| エラーの詳細 | トレース ID / 相関 ID / タイムスタンプなど | Microsoft サポートがログを追跡するために必須 |
| 業務影響 | 復旧できない場合に困ること（例：検証環境、試験、顧客環境…） | 復旧の優先度判断の材料 |
この情報を揃えた上で、次の二段階で状況を確認します。
ブラウザーからテナントを明示してサインインしてみる
まず、通常のブラウザー セッションに残っているキャッシュや別テナントへのサインイン状態を切り離すため、シークレット／プライベート ウィンドウを開きます。その上で、次のようにテナントを明示した URL にアクセスします。
https://portal.azure.com/<テナントIDまたはドメイン>
例：
https://portal.azure.com/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
https://portal.azure.com/contoso.onmicrosoft.com
この方法は、別のテナントに自動リダイレクトされてしまうケースや、複数の組織に属している個人アカウントのトラブルを回避するのに有効です。
ここで依然として AADSTS5000225 が出る場合は、テナント自体は存在しているが「非アクティブでブロック中」である可能性が高いと言えます。
CLI からテナントを明示してログインを試す
Azure CLI が使える環境であれば、次のコマンドでテナントを明示してログインを試せます。
az login --tenant <テナントIDまたはドメイン>
ここで同じく AADSTS5000225 が返ってくる場合、CLI のバグではなく、Azure 側のテナント状態そのものが原因であると Microsoft からも説明されています。
ブラウザー／CLI いずれでも AADSTS5000225 となる場合は、自力での復旧はほぼ不可能であり、Microsoft サポートにテナントの再有効化を依頼するしかありません。
テナントがまだ復旧可能な場合の対処手順
ここからは、テナントがまだ存在しており、「非アクティブのためブロック」の段階にとどまっているケースを前提に、具体的な対処手順を整理します。
Step 1: サポートに伝える情報を整理する
サポート依頼を行う前に、次の情報を文章にまとめておくとスムーズです。
- テナント ID（GUID）
- テナントのドメイン（
xxx.onmicrosoft.com/ カスタムドメイン） - 影響ユーザーの UPN（メールアドレス）
- エラー発生時刻、トレース ID、相関 ID
- 直近の利用状況（「半年以上触っていなかった」「学習用で数か月放置していた」など）
- 業務影響（復旧できないと何が困るか）
Microsoft Q&A などでも、これらの情報を非公開メッセージで共有した後、サポート側でテナントがバックエンドから再有効化された事例が報告されています。
Step 2: ポータルへのアクセス方法を工夫してみる
次の操作で状況が改善するケースもあります。
- 別ブラウザー／シークレット ウィンドウでのサインイン
- https://portal.azure.com/<テナントID> でのテナント指定サインイン
- 個人 Microsoft アカウントの場合は、
https://myaccount.microsoft.com/organizationsにサインインし、
古い組織（ブロックされたテナント）を「離脱（Leave）」してから再度ポータルへアクセス
ただし、AADSTS5000225 が返っている時点で、単なるキャッシュやクッキーの問題である可能性は低く、上記は「誤ったテナントに接続されていないか」を確認するためのチェック程度に考えておくとよいでしょう。
Step 3: Microsoft サポートにブロック解除を依頼する
テナントがブロックされてから 20 日以内であれば、テナント管理者からの依頼によりバックエンドで再有効化してもらえる場合があります。
代表的な問い合わせルートは次のとおりです。
- 有料サブスクリプションを持っている場合：
本来は Azure ポータルからサポート リクエストを登録しますが、そもそもポータルに入れない場合は、グローバル サポートの電話窓口や Web のコンタクト フォームを利用します。 - 無料アカウントや初回サインインでブロックされた場合：
Azure Free Account 向けの問い合わせカテゴリを選び、
「AADSTS5000225 でテナントがブロックされた」「初回ログインで発生した」ことを詳細に記載して送信します。
問い合わせ時には、先ほど整理した情報（テナント ID、エラー詳細、業務影響など）をそのまま転載するとスムーズです。
Step 4: サポート依頼時の注意点
- 複数の窓口に重複して問い合わせを送らない – Microsoft のドキュメントでも、1 件の事案に対して複数のサポート リクエストを送ることは避けるよう案内されています。
- 「復旧できない場合の代替案」も合わせて考えておく – もし復旧不可だった場合に、新規テナントでどこまで再構築するかをあらかじめ整理しておくと、サポート側の説明も理解しやすくなります。
- 無料／検証用途のテナントでは「削除済み」判定されやすい – 本番環境よりもアクティビティが少ないため、ブロック～削除までの流れが相対的に早く感じられることがあります。
復旧期限を過ぎた／既に削除済みの場合
サポートに問い合わせた結果、「既にテナントが削除されており復旧不可」と判断された場合は、残念ながら元のテナントを戻すことはできません。Microsoft のドキュメントでも、非アクティブ状態から 20 日を超えたテナントは削除されると明記されており、この状態からの復旧手段は提供されていません。
失われるものの例
- Entra ID（Azure AD）内の全ユーザー／グループ
- アプリ登録（アプリケーション／サービス プリンシパル）
- ロール割り当てや条件付きアクセスなどのポリシー設定
- Azure サブスクリプションとの紐づけ（※サブスクリプション側の状態によっては個別対応が必要）
- Microsoft 365 側のメールボックスや SharePoint など（対象プランの場合）
削除済みと判定された場合は、「元のテナントの復旧」は諦めて、新しいテナントの設計と再構築に集中するのが現実的です。
新規テナントを作成する手順（概要）
- ブラウザーのシークレット ウィンドウを開く
- Azure の無料サインアップ ページから新規登録を開始する
- セットアップ途中で「新しいディレクトリ（テナント）の作成」を選択する
- 作成したアカウントは新テナントのグローバル管理者になる
- 必要に応じてサブスクリプションを紐づけ、検証用／本番用の構成を作り直す
検証用途のテナントであれば、「新しく作り直す」ことが最も早く、安全な解決策になる場合が多いでしょう。
カスタム ドメインの再利用について
- 初期ドメイン（
xxx.onmicrosoft.com）は再利用不可 – 削除済みテナントの初期ドメイン名と完全に同じものを、新しいテナントで再度使うことはできません。 - 独自ドメイン（
contoso.comなど）は再登録可能な場合が多い – 旧テナント側から完全に解放されていれば、新テナントに対して TXT レコード認証を行い、再登録することができます。
個人アカウントに紐づくテナントでの注意点
最近は「GitHub アカウントや個人 Microsoft アカウントで Azure にサインアップしたが、初回ログインからいきなり AADSTS5000225 が出る」という相談も増えています。
このケースでは、同じメールアドレスが過去に別の Azure テナントに紐づけられており、その古いテナントが非アクティブでブロックされていることがあります。対処のポイントは次のとおりです。
- シークレット ウィンドウで
https://myaccount.microsoft.com/organizationsにサインイン - 表示される組織一覧の中から、心当たりのない古い組織（テナント）を「離脱（Leave）」する
- その後、改めて
https://portal.azure.comへサインインし、新しいテナントを明示してアクセスする
それでも AADSTS5000225 が解消しない場合は、やはり Microsoft サポートに問い合わせて、どのテナントに対してブロックが掛かっているのかを調査してもらう必要があります。
CLI・スクリプト観点での注意点（開発者向け）
インフラ自動化や IaC を利用している環境では、Azure CLI や各種 SDK からのログイン時に AADSTS5000225 が発生することがあります。
az login --tenant <テナントID>を実行した際にエラーが出る- GitHub Actions / Azure DevOps のサービス接続が急に認証エラーになった
- 長期間使っていなかった検証環境のパイプラインが、久々に動かしたタイミングで失敗した
GitHub 上の Azure CLI リポジトリでも、同様の報告に対して 「このエラーは CLI の問題ではなく、テナントが非アクティブでブロックされているため。サポートに連絡してほしい」という回答が繰り返し示されています。
つまり、スクリプト側でリトライしても解決しないため、次のような運用を検討するとよいでしょう。
- 定期ジョブ（週 1 回など）で、対象テナントに対してログイン＋軽微な API 呼び出しを行う
- パイプラインが AADSTS5000225 で失敗した場合は、すぐに運用担当に通知するアラートを設定する
- 「検証テナントが削除された場合」に備えて、テンプレート（Bicep / Terraform など）で再構築できるよう IaC を整備する
再発防止のための運用ベストプラクティス
同じトラブルを繰り返さないために、最低限押さえておきたい運用ポイントを整理します。
定期的なアクティビティを残す
- 月に 1 回程度、管理者が Azure ポータルや Entra 管理センターにサインインする
- 何らかの簡単な操作（ユーザー一覧の確認など）を行い、監査ログにアクティビティを残す
- 自動化できる場合は、定期的に Graph API などへ読み取りアクセスするスクリプトを実行する
通知メールの受信体制を整える
- Entra ID の「セキュリティ連絡先」や「代替連絡先メール」を設定し、管理者が退職しても通知が届くようにする
- テナントの非アクティブ化に関する警告メールが来たときに、誰かが必ず目を通す体制を作る
- 監査用メールボックス（共有メールボックス）を 1 つ用意し、重要通知を集約するのも有効
管理者アカウントの冗長化
- グローバル管理者を最低 2 名以上用意する
- 非常時のみ利用する「ブレークグラス」アカウントを用意し、多要素認証や長期有効なパスワードを適切に管理する
- 管理者が異動・退職する際は、テナントの所有権やドキュメントを必ず引き継ぐ
支払い情報・サブスクリプションの整備
- 有料サブスクリプションが紐づくテナントでは、請求先情報・支払い方法を常に最新に保つ
- クレジットカードの有効期限切れなどでサブスクリプションが停止しても、すぐに気付けるよう請求通知を複数のメールアドレスに送る
テナント状態の監視
| 監視対象 | 例 | 目的 |
|---|---|---|
| サインイン失敗 | 特定のアプリ／管理者アカウントのサインイン失敗回数 | ブロックやポリシー変更に早期に気付く |
| アクティビティ ログ | Entra ID 監査ログの「管理操作ゼロ」の期間 | 長期間放置されているテナントを検知する |
| 請求関連 | 利用料金が極端に少ない／ゼロの月が続いていないか | 「本当に不要なテナント」か、「たまたま利用が少ないだけ」かを判断する材料 |
すぐ使えるチェックリスト
実際に AADSTS5000225 が発生したとき、次のチェックリストを上から順に埋めていくと、サポート依頼までの準備がスムーズになります。
- ☑ テナント ID または
xxx.onmicrosoft.comを控えている - ☑ 影響ユーザーのメールアドレスを特定した
- ☑ エラー発生時刻、トレース ID / 相関 ID をメモした
- ☑ 業務影響（復旧理由／復旧不可時の影響）を文章化した
- ☑ シークレット ウィンドウで
https://portal.azure.com/<テナントID>にアクセスして試行した - ☑ CLI（
az login --tenant <テナントID>）でも同様のエラーになることを確認した - ☑ Microsoft サポートに問い合わせるチャネル（電話／Web フォーム）を把握した
- ☑ 復旧不能だった場合の方針（新規テナント作成・再構築）を決めた
よくある質問（FAQ）
無料評価版や学習用テナントでも AADSTS5000225 は発生する？
はい、発生します。特に、学習用・検証用テナントは数か月単位で放置されやすく、本番テナントよりも非アクティブ化されるリスクが高いと考えておいた方が安全です。
ブロックから何日以内なら確実に復旧できる？
公式ドキュメントでは「非アクティブ状態から 20 日以内に管理者が再有効化を依頼できる」とされていますが、内部の処理タイミングや契約種別によって結果が変わる可能性があります。 「20 日経っていないから絶対に大丈夫」とは考えず、エラーを確認したら即座にサポートへ連絡するのが最善です。
自分でテナントの「非アクティブ化」を解除することはできないの？
現時点では、管理者がポータル上の設定だけでブロックを解除する方法は提供されていません。AADSTS5000225 の状態から復旧するには、必ず Microsoft サポートを通してバックエンドでの再有効化を依頼する必要があります。
サインイン エラーでもテナントが削除されないパターンは？
パスワード間違いや条件付きアクセス、MFA の失敗など、ユーザー側の認証要因が原因の場合はテナントが削除されることはありません。エラー コードが AADSTS5000225 ではなく、別のコード（例：AADSTS50076 など）であれば、まずは通常のサインイン トラブルシューティングを行ってください。
まとめ：AADSTS5000225 への向き合い方
- AADSTS5000225 は、「ユーザー」ではなく「テナント」がブロックされていることを示すエラーであり、ユーザー側のパスワード変更では解決しない
- 猶予は短く（目安 20 日）、しかも非アクティブ判定はエラー表示より前の段階で行われているため、発生を確認したら即座に動く必要がある
- まずは テナントがまだ存在しているか（ブロック状態か／完全削除か）を切り分ける
- ブロック状態であれば、テナント ID やエラー詳細を揃えた上で Microsoft サポートに再有効化を依頼する
- 既に削除されている場合は、新規テナントの作成と再構築が唯一の現実的な解決策となる
- 再発防止のために、定期的なサインイン・通知メールの整備・管理者の冗長化・テナント監視をセットで実施する
一度 AADSTS5000225 を経験すると、「テナントを長期間放置することのリスク」を実感できるはずです。この機会に、検証用を含めた全テナントの棚卸しと運用ルールの見直しを行い、二度と同じトラブルで時間と労力を失わないようにしておきましょう。
コメント