Azure ポータルにサインインしようとしたときに「AADSTS5000225: This tenant has been blocked due to inactivity」と表示され、昔作ったテナントが原因で何もできない――ここ数か月、この相談が一気に増えています。本記事では、このエラーの正体、復旧できるケース・できないケースの見極め方、サポートへの具体的な依頼文例、CLI で生き残ったリソースを救出する方法、そして今後同じ事態を避けるための運用ポイントまで、実務目線で詳しく解説します。
Azure ポータルで「AADSTS5000225」が出るときに起きていること
エラーコード AADSTS5000225 は、英語メッセージだと次のような形で表示されます。
AADSTS5000225: This tenant has been blocked due to inactivity.これは「アカウントのパスワードが違う」といったレベルの話ではなく、 テナント自体が「非アクティブ」扱いになり、バックエンドの課金システム（OMS Commerce System）によってブロックされた状態 を意味します。
Microsoft Q&A や公式ドキュメントでは、以下のような挙動が繰り返し説明されています。
| タイミング | テナント状態 | Azure ポータル / API から見える症状 | 備考 |
|---|---|---|---|
| 通常利用中 | アクティブ | ポータルに問題なくサインインできる | 課金サイクルも正常に動作 |
| 最終課金から約 200 日以上 かつ活動なし | 非アクティブ候補 | ある日を境に突然 AADSTS5000225 が出る | OMS Commerce System がテナントを「削除対象」と判定 |
| ブロック開始～20 日以内 | 非アクティブ（ブロック中） | AADSTS5000225 が表示されるが、 管理者が Microsoft に再有効化を依頼可能 | この期間が実質的な「猶予期間」 |
| ブロック開始から 20 日超 | 削除済み | テナント自体が削除されるため復元不可 | 新規テナントを作成するしかない |
公式のテナントライフサイクルの記事でも、 「非アクティブ状態から 20 日以内であれば管理者が再アクティブ化を依頼できるが、それを過ぎると削除され復元不可」 と明記されています。
一方で、「最終請求から 200 日以上放置されると OMS Commerce System によりブロックされる」という説明は、 最近の Microsoft Q&A で繰り返し案内されている内容です。
まとめると、AADSTS5000225 が出たときは次の 2 段階のどこかにいると考えてください。
- 約 200 日以上ほぼ利用がないテナントが「非アクティブ」と判定され、OMS Commerce System によってログインがブロックされた。
- ブロックされてから 20 日以内なら再アクティブ化のチャンスがあるが、それを過ぎるとテナントは完全削除される。
まず確認するべきポイント：本当に「昔のテナント」が原因か？
実際の相談では、 「最近新しいテナントを作ったのに、サインインすると昔のテナント側で AADSTS5000225 が出てしまう」 というパターンがよくあります。
Azure ポータルは、「既定のテナント」 を記憶しており、 https://portal.azure.com にアクセスすると、過去に使っていた古いテナント側に自動でつながることがあります。 その古いテナントが非アクティブでブロックされていると、 「今作った新しいテナントにはログインできないのに、なぜかエラーになる」という混乱した状態になります。
テナント切り替えの基本確認
次の 2 つは、必ず試しておきたい切り分けです。
- テナント ID（GUID）またはドメイン名を指定してポータルにアクセスする
たとえば、新しいテナント ID がxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxの場合:https://portal.azure.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxあるいは、テナント名がcontoso.onmicrosoft.comなら:https://portal.azure.com/contoso.onmicrosoft.comこれで新しいテナントにログインできる場合、 「ポータルの既定テナントが古いテナントに固定されていた」 だけの可能性があります。 - Azure CLI からログインして、テナントとサブスクリプションを一覧する
az login az account list --output tableここで新しいテナントに問題なくログインできる場合は、 「CLI では新テナントに入れるが、ポータルは古いテナントを見に行っている」という状況が疑われます。
逆に、az login --tenant <テナントID> を実行しても同じく AADSTS5000225 が表示される場合、CLI からもブロックされており、 テナント自体が「非アクティブ状態」 に入っている可能性が高いです。
症状別に見た「何が起きているか」早見表
| 症状 | 考えられる状態 | 優先して行うこと |
|---|---|---|
| ポータルだけが AADSTS5000225 CLI は正常にログイン可能 | 古いテナントが既定テナントとして選択されている | ポータルの URL に新テナント ID / ドメインを付けてアクセスし、 ポータル上で既定テナントを新しいものに変更する |
| ポータルも CLI も AADSTS5000225 | 対象テナントが OMS Commerce System により 非アクティブ（ブロック）状態になっている | 20 日以内であれば Microsoft サポートに 再アクティブ化を依頼する |
| サポートから「すでに削除済み」と案内された | ブロックから 20 日以上経過し、テナントが完全削除済み | 復旧は不可能。新規テナントを作成し、必要なら構成を作り直す |
復旧可能かどうかを判断する基準
もっとも重要なのは、 「ブロックされてから 20 日以内かどうか」 です。 公式情報では、非アクティブ状態から 20 日以内は管理者が再アクティブ化を要請できるとされています。
| テナントの状態 | 復旧可否 | 具体的な対応 |
|---|---|---|
| ブロックから 20 日以内と思われる （最近まで普通に使えていた） | 〇 復旧の可能性あり | Microsoft サポートに「テナント再アクティブ化」の依頼を行う。 |
| 最後に使ったのが半年～数年前で、 サポートからも「削除済み」と案内された | × 復旧不可 | 新規テナントを作成し、必要に応じて設定を作り直す。 |
| いつブロックされたか分からない | △ 要確認 | とりあえずサポートに問い合わせ、ブロック時期と再アクティブ化可否を確認する。 |
「20 日」という数字はあくまで 非アクティブ状態に入ってからの猶予 であり、 「最後にテナントを触ってからの 20 日」ではない点に注意が必要です。 多くのケースでは、最後の請求から約 200 日以上放置 → 非アクティブ化 → そこから 20 日の猶予、というタイムラインになります。
Microsoft サポートに再アクティブ化を依頼する際に必要な情報
テナントがまだ削除されていない可能性があるなら、 できるだけ早く Microsoft サポート（Entra ID / Azure チーム）に連絡 しましょう。 その際に、最初から以下の情報をまとめて伝えると話がスムーズです。
必須で用意しておきたい情報
- テナント ID（GUID）またはカスタムドメイン名
例:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/contoso.onmicrosoft.com - エラーコード
AADSTS5000225 - エラー発生時の Correlation ID と Timestamp
サインイン画面の「詳細情報」やエラーメッセージの詳細に表示されます。 - 影響を受けるサインイン用メールアドレス
例:[email protected] - ビジネスへの影響・復旧できない場合のリスク
「顧客向けサービスが停止する」「検証環境がなくなりリリースに影響する」など、できるだけ具体的に。 - （テスト用途の場合）再作成でも問題ないかどうか
「検証用のため、復旧が難しい場合は新規テナント作成でも問題ありません」と添えると、案内が明確になります。
問い合わせ文の例（日本語）
サポートに依頼するときの文面イメージは、例えば次のような形です。
件名:
Azure ポータルサインインエラー (AADSTS5000225) によるテナント再アクティブ化の依頼
本文:
いつもお世話になっております。
Azure テナントへのサインインができなくなったため、再アクティブ化の可否について確認させてください。
・エラーコード: AADSTS5000225
・エラーメッセージ: This tenant has been blocked due to inactivity.
・テナント ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・テナントドメイン: contoso.onmicrosoft.com
・エラー発生日時: 2025-10-01 09:30 (JST)
・Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・サインインに使用したアカウント: [email protected]
本テナントには、社内検証用の仮想マシンおよびアプリケーションが構成されており、
現在サインインできないことで検証作業に支障が出ております。
まだ再アクティブ化可能な状態かどうかをご確認いただき、
可能な場合はブロック解除のご対応をお願いできますでしょうか。
もし既に削除済みで復旧が不可能な場合は、その旨と今後取るべき対処（新規テナント作成など）についてご教示いただけますと幸いです。
よろしくお願いいたします。ここまで書いておくと、サポート側も状況を把握しやすく、 「再アクティブ化可能か・すでに削除済みか」 の回答までが早くなる傾向があります。
CLI や PowerShell でアクセスできる場合の「緊急避難」
ケースによっては、 Azure CLI や PowerShell からはまだリソースにアクセスできるのに、ポータルだけが AADSTS5000225 になる こともあります。一方で、テナントが完全にブロックされると CLI でも同様のエラーが返ってくることが確認されています。
もし CLI からまだログインできるなら、 サポートの回答を待つあいだに必要なデータをバックアップしておく ことを強くおすすめします。
Azure CLI での基本的なログイン手順
# 特定のテナントを指定してログイン
az login --tenant <テナントID>
# 利用可能なサブスクリプションを確認
az account list --output table主な用途の例を挙げます。
- ストレージアカウントのデータ退避
az storage blob download-batch \ --account-name <ストレージ名> \ --source <コンテナー名> \ --destination ./backup - 仮想マシンの構成エクスポート
新テナントに同じ構成を再作成したい場合、VM の設定を JSON としてエクスポートしておくと便利です。 - ネットワーク構成やロール割り当ての一覧取得
再構築時のチェックリストとして利用できます。
なお、CLI の認証自体が AADSTS5000225 で失敗する場合は、 テナント全体がブロックされている と見てよく、 残念ながら自力でできることはほぼありません。
どうしても復旧できない場合：新規テナントでの再スタート
Microsoft サポートから 「テナントは既に削除されており復元できない」 と案内された場合、現時点では 元のテナントを復旧する方法はありません。
この場合の現実的な選択肢は、次の通りです。
- テスト・学習用途の場合
迷わず 新しい Microsoft Entra ID テナントを作成 して再構築するのが最短です。 - 本番用途だったが、リソースは既に不要な場合
そのまま新テナントで環境を作り直し、古いテナントについては「削除済み」と割り切るしかありません。 - 本番用途で、どうしても同じドメイン名を使いたい場合
カスタムドメイン（例:example.com）を旧テナントに割り当てていた場合、 削除完了までドメイン再利用ができない期間が生じることがあります。 この点はサポートとよく相談してください。
新テナントで作業を始めるときは、https://portal.azure.com/<新テナントID またはドメイン> の形式でアクセスし、 ログイン後にポータルの「ディレクトリ + サブスクリプション」設定から 既定のテナントを新しいものに変更 しておくと、次回以降は余計な混乱を避けられます。
同じ目に遭わないための再発防止ベストプラクティス
AADSTS5000225 は、「うっかり放置していたらテナントがいつの間にか削除対象になっていた」という 運用上の事故 であることがほとんどです。ここでは、再発を防ぐための実践的なポイントをまとめます。
1. 半年に 1 回は「テナントに触る」ルールを作る
テナントが非アクティブと判定されるまでの「200 日」は約 6～7 か月です。 安全側に振るなら、「6 か月に 1 回は最低限の操作を行う」 ことをチーム内ルールにしておくと良いでしょう。
- 管理者アカウントで Azure ポータルにサインインする
- 検証用の小さなリソースをデプロイしてみる
- Entra ID でユーザーを 1 名追加・削除する
- 設定の変更（条件付きアクセス、アプリ登録など）を行う
要するに、「このテナントはまだ使われている」 というシグナルを定期的に出し続けることが大事です。
2. 請求（課金）サイクルを完全に止めない工夫
相談事例を見ていると、 無料枠だけで利用しており、長期間まったく課金が発生していないテナント がブロック対象になりやすい傾向があります。
もちろん「無駄に課金する」のは本末転倒ですが、たとえば次のような工夫があります。
- 無料プランの範囲内であっても、課金アカウントと紐付けておき、請求サイクルがきちんと回る状態 にしておく
- ごく小さなリソース（低スペック VM やストレージ）を短時間だけ起動し、利用実績を残しておく
- Microsoft 365 や他の有償サービスとテナントを共有し、完全な「遊休テナント」にしない
ポイントは、「ゼロコスト・完全放置」の状態を長期間続けない ことです。
3. 監査ログやサインインログのアラートを設定する
長期間ログインがない、あるいは管理者アカウントの操作が一定期間行われていない場合に、 メールでアラートを飛ばす運用も有効です。
- Entra ID のサインインログに対して、「直近 180 日間、管理者のサインインがない」 などの条件でアラートを設定する
- Log Analytics / Azure Monitor を使って、テナントの活動が一定期間ない場合に通知する
- 単純に、半年ごとにリマインダーを飛ばす Outlook カレンダーを作っておく
4. 個人アカウント 1 つに依存しない
古い検証テナントでありがちなのが、 「個人の Microsoft アカウント 1 つだけがグローバル管理者」 という構成です。この場合、その人が環境の存在自体を忘れると、誰も気づかないまま 200 日以上経ってしまいます。
- 最低でも 2 名以上の管理者アカウント（できれば
[email protected]のような組織アカウント）を用意する - テナントの情報を社内 Wiki やチケットに記録し、「どの用途で使っている何のテナントか」を共有する
5. テスト用テナントは「作り捨て前提」で割り切る
学習用・検証用テナントは、どうしても放置されがちです。 その場合は最初から 「いつでも捨てられる構成」 を意識しておくと、AADSTS5000225 が出てもダメージを最小限にできます。
- Bicep / ARM テンプレート / Terraform など IaC で構成をコード化しておく
- サンプルデータやテストユーザーは再生成できるようスクリプト化しておく
- 本番相当のカスタムドメインは極力紐付けない
まとめ：20 日以内ならサポートへ、過ぎていれば新テナントで再出発
AADSTS5000225（This tenant has been blocked due to inactivity）は、 テナントライフサイクルに基づく「削除プロセスの途中段階」 であり、 パスワードリセットや MFA のように自分だけで完結できる問題ではありません。
本記事のポイントを改めて整理すると、次のようになります。
- テナントが長期間（約 200 日以上）ほぼ利用されていないと、OMS Commerce System により非アクティブ判定され、AADSTS5000225 でブロックされる。
- 非アクティブ化から 20 日以内 なら、管理者が Microsoft サポートに依頼して再アクティブ化してもらえる可能性がある。
- 20 日を過ぎてテナントが削除されてしまうと、復旧は不可能であり、新規テナントを作成するしかない。
- CLI や PowerShell からまだアクセスできる場合は、その間に重要データをバックアップしておくとダメージを最小化できる。
- 半年に 1 回はテナントにログインする、請求サイクルを完全に止めない、アラートやリマインダーを仕込むといった運用で、同じトラブルを防ぎやすくなる。
いままさに AADSTS5000225 に遭遇している場合は、 「いつからブロックされていたか」 をできる範囲で推定し、 一刻も早く Microsoft サポートに状況を共有することが最優先です。 20 日以内ならまだ間に合う可能性がありますし、もし間に合わなかったとしても、 早めに諦めて新テナントで体制を整えた方が、結果的に復旧までの時間を短くできます。
コメント