「Azure のテナントを新規作成したのに、いきなり AADSTS5000225: This tenant has been blocked due to inactivity. と出てサインインできない…」という相談がここ数年一気に増えています。実はほとんどのケースで、新しく作ったテナントではなく「昔作って放置していた別テナント」にブラウザが勝手に飛んでしまっているだけです。本記事では、このエラーの正体と確認すべきポイント、そして本当にブロックされているテナントだった場合の対処方法を、アカウント作成直後のケースに絞って分かりやすく解説します。
Azure サインイン直後に出る AADSTS5000225 とは何か
どんなエラーが出るのか
Azure ポータル（https://portal.azure.com）や Microsoft Entra 管理センター（https://entra.microsoft.com）にアクセスしたとき、サインイン後すぐに次のようなメッセージが表示されることがあります。
Error code: AADSTS5000225
Error message: AADSTS5000225: This tenant has been blocked due to inactivity.
To learn more about tenant lifecycle policies, see https://aka.ms/TenantLifecycle.
見慣れないコードですが、ポイントは次の 2 つです。
- 「テナント（＝ディレクトリ）」単位でブロックされている
- 理由は「長期非アクティブ」扱いになったため
Microsoft の公式ドキュメントでは、長期間使われていないテナントはコスト削減・セキュリティの観点から「アクセス不可状態」に移行され、この状態のテナントにアクセスすると AADSTS5000225 が返る、と説明されています。
テナント ライフサイクルと AADSTS5000225 の関係
テナントが非アクティブになると、概ね次のようなライフサイクルをたどります。
| 段階 | 状態 | ユーザー / 管理者ができること |
|---|---|---|
| 通常利用 | サインイン可能 | ポータルやアプリから通常どおり利用できる |
| 長期間非アクティブ | 「非アクティブ候補」として内部的に扱われる | 通常はまだサインイン可能だが、警告メールが送られる場合がある |
| ログインブロック | AADSTS5000225 が返る「アクセス不可テナント」 | 管理者が Microsoft サポートに連絡すれば、一定期間内なら復旧できる可能性がある |
| 削除 | テナント自体が永久削除 | 復旧は不可。必要なら新しいテナントを作り直す |
Microsoft Q&A などの公式回答によると、多くのケースでは「請求サイクルから約 200 日以上サインインがないテナント」が自動的にログインブロック対象となり、その約 20 日後に完全削除される、という目安が示されています。
つまり AADSTS5000225 は「このテナントは長期間使われていないので、ログインを受け付けない状態になっています」というサインです。
「作成直後なのに非アクティブ？」が起こる典型パターン
ここからがこの記事の本題です。「今まさに新しく Azure テナントを作ったばかりなのに、なぜ『非アクティブ』扱いになるのか？」
結論から言うと、次のようなパターンが非常に多く見られます。
- 過去に同じメールアドレスで別のテナントを作っており、それが長期放置でブロックされている
- ブラウザのキャッシュや「最近使ったディレクトリ」の情報に引きずられ、ログイン先として古いテナントが解決されてしまう
- その古いテナントがちょうど AADSTS5000225 状態にある
その結果、ユーザー側から見ると「新テナントを作った直後に AADSTS5000225 が出ている」ように見えるわけです。実際には、新テナントではなく、昔のテナントに飛ばされているだけ、というケースが Reddit や Microsoft Q&A でも多数報告されています。
よくある勘違いパターン
| 症状 | 実際に起こっていること |
|---|---|
| Azure 無料アカウントを新規作成 → すぐに AADSTS5000225 | 同じメールで昔に作った学習用テナントがブロックされており、ブラウザがそちらへリダイレクトしている |
| Entra 管理センターにアクセスすると毎回 AADSTS5000225 | 前回使っていたテナントがブロックされており、「最後に使ったディレクトリ」として自動選択されている |
| Microsoft Learn のサンドボックス練習用に使っていたアカウントが急に AADSTS5000225 | 学習用テナントが長期間非アクティブとなり、テナントライフサイクルによりブロック状態に移行している |
したがって、「本当に今作った新テナントがブロックされているのか？」を切り分けることが、最初にやるべき作業になります。
切り分けフロー：どのテナントにサインインしようとしているか確認する
ここからは、確認すべき順番に沿って具体的な手順を紹介します。難しい操作はなく、ブラウザと URL の指定だけでほとんど判定できます。
ステップ 1：完全サインアウト & 別ブラウザで試す
まずはシンプルな切り分けからです。ブラウザのセッションやキャッシュの影響を受けている可能性が高いため、次を実施します。
- 現在開いている Microsoft のページ（Outlook、OneDrive、Azure ポータルなど）から すべてサインアウト する
- ブラウザの Cookie / ログイン情報を削除 する、または
- シークレットウィンドウ（プライベートブラウズ） を開き、そこからアクセスする
- 可能であれば、Chrome / Edge / Firefox など 別のブラウザ でも同じ手順を試す
この状態で https://portal.azure.com にアクセスし、メールアドレス・パスワードを入力してサインインします。ここで AADSTS5000225 が消える場合、単純に古いセッションの情報に引きずられていた可能性が高いです。
ステップ 2：テナントを URL パラメータで明示指定する
次に、ログイン先テナントを明示的に指定します。新しく作成したテナントの テナント ID（GUID） または 既定ドメイン名（<tenantName>.onmicrosoft.com） を使って、以下の URL からアクセスします。
https://portal.azure.com/?tenant=<テナントID または tenantName.onmicrosoft.com>
https://entra.microsoft.com/?tenant=<テナントID または tenantName.onmicrosoft.com>
例：
https://portal.azure.com/?tenant=contoso123.onmicrosoft.com
https://entra.microsoft.com/?tenant=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ポイントは、クエリパラメータ ?tenant= で明示指定されたテナントがログイン先として使われることです。これにより、「ブラウザが勝手に選んだ別テナント」に飛ばされるのを防げます。
サインインに成功したら、画面右上の「アカウントアイコン」をクリックし、「ディレクトリ + サブスクリプション」 を開きます。そこに目的のテナント名が表示されているか、ブレード上部の「現在のディレクトリ」に期待した名称が出ているかを確認してください。
CLI でテナント指定して確認する方法（補足）
もし Azure CLI が使える環境なら、次のコマンドで同様の確認ができます。
az login --tenant <テナントID または tenantName.onmicrosoft.com>
ここで AADSTS5000225 が出るかどうかを確認すると、ブラウザ依存の問題か、テナントそのものの問題かを切り分けるのに役立ちます。CLI でも同じエラーになる場合は、テナント自体がブロックされている可能性が高まります。
ステップ 3：テナント ID / ドメインが分からないときの探し方
「そもそもテナント ID や onmicrosoft.com ドメイン名が分からない」というケースもよくあります。その場合は、以下を確認してみてください。
- Azure 申し込み時に届いた 「ようこそ」メール に、
<tenantName>.onmicrosoft.comが書かれていないかチェックする - Microsoft アカウントの組織一覧（アカウント管理ページ）から、自分が所属している組織（テナント）の名称を確認する
- 職場や学校の管理者がいる場合は、その人にテナント ID / ドメインを問い合わせる
どうしても新テナントを特定できない場合は、後述する「Microsoft サポートへの問い合わせ」で、メールアドレスと状況を説明し、調査してもらうのが確実です。
ステップ 4：テナントを明示しても AADSTS5000225 が出る場合
?tenant= を付けても AADSTS5000225 が表示される場合、そのテナントはほぼ確実に 「アクセス不可（ブロック）状態」 にあります。
この状態になる理由として多いのは次のようなケースです。
- 学習用に作った無料テナントを長期間使わずに放置していた
- 検証用テナントで課金が止まっており、サブスクリプションも失効している
- 一度使わなくなったテナントを、あとから再利用しようとしたが、すでにテナントライフサイクルによりブロックされていた
Azure 側の仕様として、ブロックされたテナントを管理者が自力で解除することはできません。Microsoft のサポートに連絡し、一定期間内であれば「テナントの再アクティブ化」を依頼する必要があります。
Microsoft サポートにブロック解除を依頼する
ブロック解除のタイムリミット
Microsoft の公式ドキュメントでは、テナントがアクセス不可状態（AADSTS5000225）になってから 20 日以内であれば、管理者の依頼により再アクティブ化できる場合があるとされています。
20 日を過ぎると、テナントは永久削除され、もはや復旧できません。そのため、エラーに気付いたら即動くことが非常に重要です。
| 時期 | テナントの状態 | 対応可否 |
|---|---|---|
| 長期非アクティブだが、まだブロック前 | 通常どおりサインイン可能 | 定期的にログインすれば問題なし |
| ブロック直後 〜 20 日以内 | AADSTS5000225 が返る「アクセス不可テナント」 | 管理者がサポートに依頼すれば再アクティブ化の可能性あり |
| ブロックから 20 日以降 | テナントが永久削除 | 復旧不可。新規テナント作成のみ |
サポートへ伝えるべき情報
サポートリクエストを行う際は、Microsoft Q&A の回答で例示されているように、次の情報を準備しておくと話がスムーズです。
- テナント ID（GUID）
- 関連するサブスクリプション ID（分かれば）
- エラー画面に表示される トレース ID / コリレーション ID / タイムスタンプ
- ビジネスへの影響（試験勉強で必要、検証環境で必要など）
- いつごろからログインできなくなったか
サインインできないテナントの場合、Azure ポータルからサポートチケットを起票できないことも多いので、国別の Microsoft Global Customer Service の電話番号や、Azure / Entra のサポート窓口ページから問い合わせます。
注意点として、同じ件について複数の問い合わせ窓口から重複してチケットを送らないようにしましょう。公式ドキュメントでも、1 件のケースについて複数リクエストを送ると処理が遅れる可能性があると注意されています。
「新テナント＋古いブロックテナント」が共存している場合の考え方
「本当は新しく作ったテナントだけ使いたいのに、昔のブロックテナントが邪魔をしている」――このパターンもよくあります。この場合のポイントは次の通りです。
- ブロックされた古いテナントをあえて復旧する必要はない（使う予定がなければ削除されても構わない）
- 重要なのは、常に「新テナントを明示してログインする」習慣をつけること
具体的には、次のような運用が考えられます。
- ブックマークに
https://portal.azure.com/?tenant=<新テナントの onmicrosoft ドメイン>を登録しておく - ブラウザの プロフィール（アカウント）」をテナントごとに分ける（例：Chrome のプロファイル機能、Edge の「プロファイル」など）
- CLI やスクリプトでログインするときは、必ず
--tenantオプションで指定する
このように「ログイン先テナントを常に意識する」だけで、AADSTS5000225 に振り回されるリスクをかなり減らせます。
再発防止：テナントをブロックさせないための運用アイデア
最後に、同じ問題を繰り返さないための具体的な運用アイデアを紹介します。
1. 最低でも数か月に一度は管理者がサインインする
テナントが長期間完全放置になると、テナントライフサイクルによって自動的に非アクティブ・削除対象になります。すべてのテナントについて、最低でも数か月に一度は次のようなチェックを行いましょう。
- グローバル管理者アカウントでポータルにサインインする
- サインインログ（Entra ID の「サインイン」メニュー）で最新状況をざっと確認する
- サブスクリプションが期限切れになっていないか確認する
2. ブレークグラス用の管理者アカウントを用意しておく
緊急用に、MFA 有効かつ強固なパスワードを設定した「ブレークグラス管理者」を 1～2 アカウント用意しておくのは、セキュリティベストプラクティスとしても推奨されます。
- 普段はログインしない（緊急時だけ使う）
- 連絡先メールアドレスや電話番号を最新に保つ
- このアカウントでのサインイン方法を、社内の運用手順書に明記しておく
こうしたアカウントがあれば、通常の管理者アカウントに問題が起きたときでも、最低限の操作ができる保険になります。
3. テナント情報を「資産」として管理する
検証用や学習用を含め、テナントの存在自体を資産管理台帳に載せることをおすすめします。
| 項目 | 例 |
|---|---|
| テナント名 | Contoso Dev Tenant |
| 既定ドメイン | contoso123.onmicrosoft.com |
| テナント ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| 用途 | 検証用 / 学習用 / 本番 など |
| メイン管理者 | [email protected] |
| 最終サインイン日（目安） | 2025-10-01 など |
スプレッドシートやチケットシステム、資産管理ツールなど、組織で使っている仕組みに紐づけておくと、「あのテナントはまだ必要？」といった判断もしやすくなります。
4. 複数テナントを使う場合の「ログイン習慣」を決める
開発者・管理者が複数テナントを行き来する場合、次のような「自分ルール」を決めておくと混乱を防げます。
- テナント A 用ブラウザプロファイル、テナント B 用ブラウザプロファイルを分ける
- テナントごとに専用ブックマークを用意し、必ず
?tenant=付き URL から入る - CLI のログインスクリプトは、必ず
--tenantを指定した形でテンプレート化し、使い回す
こうした小さな工夫だけで、「どのテナントにログインしているのか分からない」「気付いたらブロックされた古いテナントに接続していた」といったトラブルを大きく減らせます。
クイック判定：あなたのケースはどっち？
最後に、本記事の内容をもとに、1 分でざっくり状況を判断するチェックリストをまとめておきます。
| 質問 | はい | いいえ |
|---|---|---|
| 過去に同じメールアドレスで Azure / Microsoft 365 を使っていたことがある | 古いテナントへのリダイレクトが疑わしい → ステップ 1～2 でテナントを明示 | 新テナント自体が問題の可能性 → ステップ 2・4 へ |
?tenant=<新テナント> を付ければサインインできる | 原因はリダイレクト誤り。今後はテナント指定 URL を利用 | ↓ 次の質問へ |
?tenant=<新テナント> を付けても常に AADSTS5000225 になる | 対象テナントがブロック状態の可能性大 → 20 日以内ならサポートに連絡 | ブラウザやアカウントの切り替えを再確認 |
| テナントを使わなくなってから 1 年以上経っていそう | すでに削除済みの可能性。復旧は難しいため、新テナント作成を検討 | ブロック直後かもしれないので、急いでサポートに相談 |
あらためて要点をまとめると、次のようになります。
- AADSTS5000225 は「そのテナントでのサインインがブロックされている」状態を示す
- 「新規作成直後なのに非アクティブ」の多くは、実際には昔のテナントにリダイレクトされているだけ
- テナント ID / ドメインを
?tenant=で明示してサインインできるかどうかが、切り分けの第一歩 - 本当にブロックされたテナントの場合、管理者でも自力解除は不可で、20 日以内に Microsoft サポートへ連絡する必要がある
- テナントのライフサイクルと運用ルールを意識すれば、同じトラブルに悩まされる可能性は大きく減らせる
もしあなたが今まさに AADSTS5000225 に遭遇しているなら、この記事のステップに沿って「どのテナントにサインインしようとしているのか」を落ち着いて確認し、それでも解決しない場合は早めにサポートへ相談してください。
コメント