Azure ポータルにサインインしようとしたとき「このテナントは非アクティブのためブロックされました（AADSTS5000225）」と表示され、突然ログインできなくなるケースが増えています。本記事では、このエラーの正体と復旧可否の見分け方、新しいテナントを作る際の注意点まで、実務目線でわかりやすく解説します。
Azure サインインエラー「AADSTS5000225」とは？
まず、問題のエラーを整理します。
Azure や Microsoft Entra ID（旧 Azure AD）にサインインしようとした際に、次のようなメッセージが表示されることがあります。
Error code: AADSTS5000225
This tenant has been blocked due to inactivity.
このテナントは非アクティブのためブロックされました
このエラーは、入力したパスワードが間違っているわけでも、アカウントがロックされているわけでもありません。「サインイン先となるテナント（ディレクトリ）自体が、Microsoft のテナント ライフサイクルにより非アクティブ扱いになり、サインインをブロックされている状態」です。
もう少しイメージしやすくするために、エラーの意味を表で整理してみます。
| 項目 | 内容 |
|---|---|
| エラーコード | AADSTS5000225 |
| 主なメッセージ | This tenant has been blocked due to inactivity / このテナントは非アクティブのためブロックされました |
| 原因 | 長期間使用されていないテナントが、Microsoft により「非アクティブ（inaccessible）」に変更され、サインインがブロックされた |
| 影響 | ポータル（portal.azure.com / entra.microsoft.com）や CLI など、当該テナントへのすべてのサインインが失敗する |
| 復旧の可否 | 非アクティブ化から20日以内なら Microsoft サポート経由で復旧可、それ以降はテナントが削除され復旧不可 |
なぜテナントが「非アクティブでブロック」されるのか
Microsoft は、長期間利用されていないテナントが放置されることで、課金のトラブルやセキュリティリスクが発生しないよう、「テナント ライフサイクル」という仕組みを導入しています。
ざっくり言うと、ある一定期間まったく使われていないテナントは「非アクティブ」と判定され、次のような流れで処理されます。
| タイミング | 状態 | ユーザーができること |
|---|---|---|
| 長期間サインイン無し | テナントが「非アクティブ候補」としてマークされる（バックグラウンドで判定） | 特に通知に気づかないと何も起きていないように見える |
| 非アクティブ判定後 | サインインを試みると AADSTS5000225 で拒否される（テナントが「inaccessible」状態） | この時点から 20 日間は、管理者が Microsoft サポートに復旧を依頼できる |
| 非アクティブ状態から 20 日経過後 | テナントが削除対象となり、順次完全削除される | 一切復旧不可。データもポリシー上復元されない |
つまり、AADSTS5000225 が出ている時点で、すでにテナントは「通常の管理者操作ではどうにもできない」状態であり、対応は次の二択になります。
- ブロックから 20 日以内 → Microsoft サポートにテナント再有効化を依頼
- 20 日以上経過 → テナントは復旧不可、新しくテナントを作り直す
この 20 日という期間は Microsoft の公式ドキュメントやサポート回答でも明示されており、「21 日目以降はあきらめて新規テナントへ移行」が原則と考えておくのが安全です。
まず確認すべきポイント（セルフチェック）
いきなりテナントを作り直すのではなく、まず次のような観点で状況を整理してみてください。
| 確認ポイント | チェック内容 |
|---|---|
| 最終利用日 | そのテナントに最後にサインインしたのはいつ頃か（ざっくりで OK。「1年くらい前」「数か月前」など） |
| テナントの重要度 | 本番環境・検証環境なのか、試しに作っただけの検証テナントなのか |
| 他ユーザーの利用有無 | 自分以外に、そのテナントを使っているユーザーやシステムがいるか |
| 関連サブスクリプション | テナントに紐づいた Azure サブスクリプションがあるか（課金されていないか） |
| 20 日以内かどうか | 「最近も何回か使っていた」「ここ数週間で触った覚えがある」なら、20 日以内の可能性がある |
このセルフチェックの結果によって、次の判断フローに進みます。
シナリオ別の対処フロー
ブロックが 20 日以内か不明／20 日以内の可能性がある場合
「そこまで長く放置していない気がする」「最後に触ったのは数週間前かも」という場合は、まず Microsoft サポートにテナントの再有効化を依頼するのが最優先です。
サポートに問い合わせる際は、次の情報を用意しておきましょう。
| 項目 | 内容 | 入手場所の例 |
|---|---|---|
| エラーコード | AADSTS5000225 | エラー画面に表示される |
| エラーメッセージ | This tenant has been blocked due to inactivity | 同上 |
| Trace ID | GUID 形式の ID | エラー詳細に表示（コピー推奨） |
| Correlation ID | GUID 形式の ID | エラー詳細に表示 |
| Timestamp | エラー発生日時（UTC） | エラー詳細に表示 |
| テナント ID | 「xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx」の GUID | 分かる範囲で。過去のメールやポータル URL、CLI など |
| ビジネスへの影響 | このテナントが使えないと何に困っているか | 「本番環境へのログイン不可」「検定試験の演習ができない」など具体的に |
問い合わせチャネルは国や契約形態によって多少異なりますが、一般的には以下のような流れになります。
- Microsoft サポートサイトを開く
- 製品カテゴリとして Azure を選択
- 「サブスクリプションと課金」「Azure アカウント」など、アカウント関連のカテゴリを選ぶ
- 必要に応じてサインインし、問い合わせフォームから上記情報を記載して送信
重要なのは、同じ件名で何度もケースを起票しないことです。公式ドキュメントでも「既存のケースの結果が出るまで新しい依頼は出さない」よう案内されています。
テナントがまだ完全には削除されておらず、非アクティブ状態になってから 20 日以内であれば、サポート側でブロック解除（再アクティブ化）を行ってもらえる可能性があります。
ブロックから 20 日以上経過の可能性が高い／確実に超えている場合
一方、「最後に使ったのは1年以上前」「まったく記憶にない」といったケースでは、すでに 20 日を大きく超えていると考えられます。この場合、Microsoft のポリシー上、そのテナントは削除対象となり、復旧はできません。
このときに取れる選択肢は、次の 2 つです。
- 割り切って 新しいテナントを作成する
- 本当に重要なテナントかどうかもう一度見直す（本番環境であれば、念のため一度はサポートに聞いてみる）
いずれにせよ、「削除済みテナントのデータを復旧してほしい」という要望は基本的に通らないため、「このテナントが唯一無二の本番環境になっていないか」を日頃から意識して設計しておくことが重要です。
新しいテナントを作成する前に知っておきたいこと
テナントを新規作成する場合でも、既存の Microsoft アカウント（@outlook.com などの MSA）をそのまま再利用できます。アカウントを作り直す必要はありません。
ここでよく混同される「アカウント」と「テナント」の違いを整理しておきましょう。
| 種類 | 例 | 役割 | ポイント |
|---|---|---|---|
| アカウント | [email protected] / [email protected] に紐づく Microsoft アカウント（MSA） | サインインする「人」そのもの | 1つのアカウントで複数テナントの管理者になることもできる |
| テナント | contoso.onmicrosoft.com など | ユーザーやアプリ、グループをまとめる「組織の入れ物」 | 同じアカウントで複数のテナントを所有・管理可能 |
| サブスクリプション | 無料試用版、従量課金、Visual Studio サブスクリプション特典 など | Azure の課金単位 | どのテナントに紐づけるかを後から変更することもある |
つまり、「古いテナントが削除されたからといって、@outlook.com のアカウントが使えなくなるわけではない」点がポイントです。このアカウントはそのまま、新しく作るテナントのグローバル管理者として再利用できます。
新しいテナントを作成する手順（ステップバイステップ）
ここからは、実際に新しいテナントを作成する具体的な手順を、少し丁寧に解説します。
ステップ 1：サインイン環境をリセットする
まずは、過去にアクセスした組織テナントやゲストテナントへ自動的に飛ばされないよう、サインイン環境をリセットします。
- ブラウザで、すべての Microsoft 関連サイト（portal.azure.com / entra.microsoft.com / account.microsoft.com など）からいったんサインアウトする
- ブラウザの プライベート / シークレット ウィンドウを開く
login.microsoftonline.comのサイトデータ・Cookie を削除する（特に「常にサインインする」にチェックしていた場合は重要）
この操作により、「母校や前職のテナント」「ゲストとして招待された別組織」へ自動でルーティングされてしまう現象をかなりの確率で防げます。
ステップ 2：MSA（個人アカウント）でサインインする
次に、新しいテナントのオーナーとして利用したい個人アカウント（MSA）でサインインします。
https://portal.azure.comではなく、まずはhttps://account.microsoft.comなどアカウント管理ページにアクセスする- @outlook.com / @hotmail.com / @live.com などの個人アカウントでサインインする
- 組織アカウントの選択ダイアログが出た場合は、「個人アカウント」を明示的に選択する
ここで重要なのは、会社のメールアドレス（@example.co.jp）でそのままサインインしないことです。会社のアカウントはあくまで会社のテナントの一部であり、「自分専用のテナント」を作るためのオーナーアカウントとしては適しません。
ステップ 3：Microsoft Entra ID で新しいテナントを作成する
アカウントでサインインできたら、いよいよテナントを新規作成します。
https://entra.microsoft.comにアクセスする（Azure ポータルから「Microsoft Entra ID」を開いても可）- 左メニューから 「テナントの管理」 を選択する
- 「テナントの作成」 をクリックする
- 「Azure Active Directory」または「Microsoft Entra ID」など、用途に応じたテナント種類を選ぶ
- 組織名、初期ドメイン名（
xxxxx.onmicrosoft.com）を入力する - 国/地域を選択し、確認画面で内容をチェックして作成
テナント作成が完了したら、ポータル右上のアイコンから 「ディレクトリの切り替え」 を行い、新しく作ったテナントに切り替えます。ここで誤ったテナントが選択されていると、「せっかく新しいテナントを作ったのに、相変わらず古いテナントに接続しようとして AADSTS5000225 が出る」ということになりかねません。
ステップ 4：サブスクリプションを紐づける
テナントだけでは Azure リソースを作成できないため、サブスクリプションの作成・関連付けが必要です。
- Azure ポータル（
https://portal.azure.com）で、新しいテナントを選択した状態にする - 「サブスクリプション」を開く
- 「+ 追加」から無料試用版や従量課金サブスクリプションを作成するか、既存サブスクリプションの所有権をこのテナントに移管する
試験勉強や検証用途であれば無料試用版で十分なことが多いですが、過去に無料枠を使い切っていると再利用できない場合もあるため、その場合は従量課金サブスクリプションを検討します。
「母校や前職のログイン画面に飛ばされる」場合の対処
Azure や Entra にサインインしようとすると、なぜか昔所属していた大学や前職のログイン画面に飛ばされてしまい、目当てのテナントにたどり着けない、という相談も非常に多いです。
これは、次のような仕組みが働いているためです。
- 昔、その組織のテナントにユーザーとして所属していた、またはゲストとして招待されていた
- ブラウザの Cookie やセッション情報に基づき、「そのメールアドレスはこの組織のユーザーだろう」と Azure が判断している
この場合、対処としては次のような方法があります。
- 前述の通り、Cookie 削除＋シークレット ウィンドウでサインインし直す
https://portal.azure.com/テナントIDやhttps://portal.azure.com/contoso.onmicrosoft.comのように、URL で直接テナントを指定してアクセスする- ポータルに入れたら、右上の「ディレクトリの切り替え」から、デフォルトテナントを新しいものに変更する
特に、1つのアカウントで複数のテナントにゲストとして参加している場合、デフォルトのルーティング先が思わぬテナントになっていることがあるため、「URL でテナントを明示的に指定する」テクニックを覚えておくとトラブル時に役立ちます。
アカウント／テナント／サブスクリプションの設計ポイント
AADSTS5000225 に限らず、テナント関連のトラブルの多くは「最初の設計が曖昧だった」ことに起因します。ここでは、今後同じ問題にハマりにくくするための設計ポイントを簡単にまとめます。
個人アカウントとテナントを分ける
- 検証用テナントのオーナーは、会社のアカウントではなく、@outlook.com などの個人アカウントにしておく
- 本番環境のテナントは、組織の公式ドメイン（@example.co.jp）に紐づくアカウントで管理する
こうしておくことで、退職・異動・組織変更などがあっても、テナントの所有権が明確になり、意図せずテナントにアクセスできなくなるリスクを減らせます。
複数の管理者アカウントを用意する
- テナントのグローバル管理者を 1 人に集中させず、必ず複数の管理者を設定する
- 特に個人アカウントをテナント管理に使う場合は、そのアカウントが失効したときのバックアップ手段を用意しておく
これにより、「唯一の管理者アカウントが何らかの理由でログインできなくなり、テナントごと詰む」という事態を避けられます。
定期的にサインインして非アクティブ化を防止する
- 検証用テナントでも、数か月に一度はポータルにログインし、状況を確認する
- 試験勉強用テナントなど、一時的な用途であっても「今後使う可能性がある」なら、カレンダーにリマインダーを入れておく
これだけでも、テナントが勝手に非アクティブ扱いになり、AADSTS5000225 に悩まされる確率をかなり下げられます。
CLI / PowerShell からの確認と注意点（おまけ）
Azure CLI や PowerShell からログインした際にも、AADSTS5000225 が返されることがあります。例えば、次のようなエラーメッセージです。
Authentication failed
AADSTS5000225: This tenant has been blocked due to inactivity.
この場合も本質は同じで、「指定したテナント ID が非アクティブ状態でブロックされている」だけです。CLI のバグではありません。
az login --tenant <テナントID>で明示的にテナントを指定してログインしている場合、そのテナントが非アクティブなら AADSTS5000225 で失敗する- 一方、別の正常なテナントにログインしたい場合は、そちらのテナント ID を指定するか、
--tenantを付けずにログインしてからaz account setで切り替える
CLI 側でできることは限られているため、「このエラーが出たらサポート or 新規テナント」という大きな方針は変わりません。
よくある質問（FAQ）
Q. ブロックから 20 日以内かどうか、正確な日付が分かりません
A. 少しでも 20 日以内の可能性があるなら、まずは Microsoft サポートに問い合わせる価値があります。ただし、サポート側の判断で「すでに削除済み」「復旧不可」となる場合もあるため、その際は素直に新しいテナントへ移行する方が時間の節約になります。
Q. 無料試用版のテナントも同じようにブロックされますか？
A. はい、無料か有料かにかかわらず、「長期間使われていないテナント」は同じポリシーで非アクティブ化の対象となり得ます。特に試験勉強やイベント向けに一時的に作成したテナントは忘れられがちなので注意が必要です。
Q. 削除されたテナントで使っていたカスタムドメインは、再利用できますか？
A. 一般的には、テナントが完全に削除されると、そのテナントに紐づいていたカスタムドメインは他のテナントでも再検証して利用できるようになります。ただし、削除処理には一定の時間がかかる場合があり、その間は「このドメインはすでに他のテナントで使用されています」と表示されることがあります。その場合は、しばらく時間を置いてから再度試す必要があります。
Q. 新しいテナントに古いテナントのデータを移行する方法はありますか？
A. テナントがまだ完全に削除されておらず、サインインだけがブロックされている段階であれば、サポートで一時的に復旧してもらい、その間に必要なデータをエクスポートして新テナントへ移行する、という戦略が取れる可能性があります。しかし、「20 日を過ぎて完全削除された後」では、Azure のデータ保護ポリシー上、管理者であってもデータを復元することはできません。
チェックリスト：この記事どおりに対応できたか確認しよう
最後に、実際に対応する際に使えるチェックリストをまとめます。必要に応じてコピー & ペーストしてご活用ください。
- [ ] エラー画面の Error code / Trace ID / Correlation ID / Timestamp を控えた
- [ ] 最後にテナントを利用した時期を思い出し、20 日以内の可能性をざっくり判断した
- [ ] 20 日以内の可能性があれば、Microsoft サポートへの問い合わせを作成した
- [ ] 20 日以上経過していそうな場合は、復旧不可を前提に新しいテナントを作成する方針を決めた
- [ ] シークレット ウィンドウ＋Cookie クリアで自動リダイレクトを防止してサインインし直した
- [ ] Microsoft Entra ID から 「テナントの作成」 を実行し、新しいテナントを作成した
- [ ] ポータル右上の 「ディレクトリの切り替え」 で、新テナントにちゃんと入れていることを確認した
- [ ] 新テナントに Azure サブスクリプションを紐づけ、必要なリソースを作成できる状態にした
まとめ：AADSTS5000225 を見たらまず「テナントの寿命」を疑う
AADSTS5000225 は一見すると難解なエラーですが、意味するところは非常にシンプルです。
- AADSTS5000225 = 「非アクティブになったテナントへのサインインがブロックされている」状態
- 非アクティブから 20 日以内ならサポートで再有効化を依頼
- 20 日を過ぎている場合は、復旧不可と割り切って新しいテナントを作る
- @outlook.com などの MSA アカウントはそのまま新テナント管理に再利用できる
- Cookie クリア＋シークレットウィンドウ＋ディレクトリ切り替えを覚えておくと、サインイン先のトラブルをかなり減らせる
本記事の内容を押さえておけば、「突然 Azure に入れなくなった！」という状況でも慌てずに、復旧可能かどうかを冷静に判断し、最短ルートで次の一手を打つことができます。今後テナントを設計・運用する際は、「テナントのライフサイクル」も意識しながら構成を考えてみてください。
コメント