Azure を久しぶりに開いたら 「AADSTS5000225: This tenant has been blocked due to inactivity（このテナントは非アクティブのためブロックされています）」 と表示され、サインイン自体ができなくなることがあります。この記事では、ブロック〜削除の流れを整理し、新しいテナントへ確実に入り直す方法と、同じトラブルを繰り返さないための実務的な対策をまとめます。
結論：AADSTS5000225 は「テナントが非アクティブ扱いでアクセス不能」になったサイン
AADSTS5000225 は、Microsoft Entra ID（旧 Azure AD）のテナントが 非アクティブ扱いになり、サインインがブロックされている状態で返されるエラーです。Microsoft のガイダンスでは、非アクティブ状態に入ってから 20 日以内なら、管理者が再アクティブ化（復旧）を依頼できる可能性がありますが、20 日を超えるとテナントは削除され、復旧できないとされています。
また、コミュニティ回答（Microsoft Q&A）では、課金サイクル終了後に長期間（目安として 200 日以上）操作がないテナントが「不要テナント削減」の対象になり、ログインブロック（AADSTS5000225）が付与されるという説明が繰り返し案内されています。
まず切り分け：今は「ブロック中」か「削除済み」か
同じ AADSTS5000225 でも、まだ救える状態なのか、すでに戻らない状態なのかで取るべき手が変わります。判断材料を表にまとめます。
| 状態 | サインイン | できること | 現実的な対応 |
|---|---|---|---|
| 非アクティブでブロック中 | 不可（AADSTS5000225） | 条件が合えば再アクティブ化を依頼できる | 早急にサポートへ復旧依頼 |
| 削除済み | 不可 | 復旧不可 | 新規テナント＋新規サブスクリプションで作り直し |
「ブロックされたのがいつか」を正確に把握できない場合でも、Microsoft のドキュメント上は 20 日が大きな境目になります。迷ったら、まずは「ブロックから 20 日以内の可能性がある」として、必要情報を揃えてサポートに相談するのが安全です。
本題：新しいテナントを作ったのに、なぜまた AADSTS5000225 になるのか
ここが一番ハマりやすいポイントです。状況を整理すると、次の“すれ違い”が起きがちです。
- 新しいテナント自体は作れている（または既に別テナントが存在する）
- しかし
https://portal.azure.comへ普通にアクセスすると、ブラウザーやアカウントの既定動作で「以前の（ブロックされた）テナント文脈」でサインインしようとしてしまう - 結果として、サインイン直後に AADSTS5000225 が再発する
つまり、問題は「テナントが作れない」ではなく、入口が古いテナントに固定されていることにあるケースが多い、ということです。
最短の解決策：URL で“入るテナント”を明示して Azure ポータルに入る
受け入れられた解決策として定番なのが、Azure ポータルの URL にテナント識別子を付けて、入り先を固定する方法です。
| 目的 | URL 例 | ポイント |
|---|---|---|
| テナント ID（GUID）を明示して開く | https://portal.azure.com/<テナントID> | 最も“ズレにくい”指定。GUID が分かるなら強い |
| テナントのドメイン名を明示して開く | https://portal.azure.com/<ドメイン> | xxx.onmicrosoft.com やカスタムドメインでも機能することがある |
| サインイン導線をドメインで固定する | https://portal.azure.com/signin/index/@<ドメイン> | アカウント選択が絡む環境で有効なことがある |
この記事のテーマである「新規テナントに入れない」症状は、上のいずれかで入口を固定すると改善することが多いです。特に、今回のようにブロック済みテナントが既定になってしまっている場合、https://portal.azure.com/<新テナントID> の形で開くのがシンプルです。
手順：https://portal.azure.com/<テナントID> でサインインする
- ブラウザーを InPrivate/シークレット で開く（キャッシュや既定テナントの影響を減らすため）
- アドレスバーに
https://portal.azure.com/<新しいテナントID>を入力してアクセス - Microsoft アカウント（個人の Microsoft アカウント）でサインイン
- ログイン後、右上の 「ディレクトリ＋サブスクリプション」（またはディレクトリ切り替え）で、意図したテナントになっているか確認
ポイント：「とりあえずサインインできた」だけで安心せず、テナント（ディレクトリ）が正しいか、さらに サブスクリプションが表示されているかまで確認してください。テナントが合っていないと、AI リソース作成画面に進んでも「作成できない／何も見えない」状態になりがちです。
テナント ID が分からないとき：見つけ方の現実解
「URL にテナント ID を入れたいのに、そもそもテナント ID が分からない」こともよくあります。その場合は、テナント ID ではなく“テナントのドメイン名”で固定するのが現実的です。
- 新しいテナントを作るときに指定した 初期ドメイン（例：
yourname.onmicrosoft.com）を使う https://portal.azure.com/signin/index/@yourname.onmicrosoft.comを試す- ポータルに入れたら、Microsoft Entra ID の概要（Overview）で Tenant ID を確認する
Microsoft Learn でも、テナント ID とプライマリドメインは Microsoft Entra の Overview（基本情報）で確認できると案内されています。まずは「テナントに入る」ことを優先し、入れた後に ID を控える流れがスムーズです。
それでもポータルが開けないときのチェックリスト
URL 固定で改善しない場合、原因が「既定テナントのズレ」ではない可能性があります。よくある原因と対処を表にまとめます。
| よくある原因 | 症状 | 対処 |
|---|---|---|
| ブロックから 20 日超で削除済み | 何をしても復旧しない／サポートでも不可 | 新規テナント＋新規サブスクリプションで作り直し |
| ブラウザーに古いセッションが残っている | 意図せず古いテナントに誘導される | InPrivate/別プロファイル/別ブラウザーで試す |
| テナント作成権限がない／作成が制限されている | 「テナントを作成」が無効、または失敗 | 設定の確認、Tenant Creator ロール付与 |
| 追加の Workforce テナント作成が制限されている | 「有料顧客のみ作成可能」等の表示 | 既存テナント利用、または要件を満たす契約を検討 |
「新しいテナントを作り直そうとしてもうまくいかない」場合に知っておくべき仕様
最近は、テナント乱立・不正利用対策の影響もあり、環境によっては 追加の Workforce テナント作成に制限がかかることがあります。Microsoft Learn のクイックスタートにも、“有料顧客のみ追加の Workforce テナントを作成できる”旨の注意書きがあります。
この制限に当たった場合の現実的な選択肢は次のとおりです。
- 既に持っているテナントを使い続ける（学習・個人開発ならこれで十分なことが多い）
- どうしても分離が必要なら、要件を満たす形で 契約（ライセンス）を整える
- 学習用途なら、別の Microsoft アカウントで新規に Azure を始める（テナント分離を最短で作れる）
サポートに復旧を依頼するなら：伝えるべき情報セット
ブロックから日が浅い可能性があるなら、サポート相談の価値があります。ただし「ただ困っています」だけだと前に進みにくいので、最初から必要情報を揃えるのがコツです。
| 項目 | 例 | なぜ必要？ |
|---|---|---|
| テナント ID / ドメイン名 | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xxx.onmicrosoft.com | 対象テナントの特定に必須 |
| エラーコード | AADSTS5000225 | 非アクティブ起因であることの確認 |
| 相関 ID / トレース ID / 発生時刻 | エラー画面に表示される値 | バックエンド調査の手掛かり |
| （あれば）サブスクリプション ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 課金・紐づき確認に使われることがある |
| 影響（重要度） | 業務影響／学習・個人開発でも期限がある等 | 優先度判断の材料 |
なお、Microsoft のドキュメントでは「既存ケースが処理中の間は重複依頼を控える」趣旨の注意もあります。チケットを乱立させるより、必要情報をまとめた 1 件で進めるほうが結果的に早いことが多いです。
AI リソースを作り直すときの実務ポイント
ブロックされたテナントを復旧できず、新しいテナントに切り替える場合、当然ながら古いテナント内のリソースは引き継がれません。AI 系（例：Azure OpenAI、Cognitive Services、各種 Azure AI サービス）も含めて、新しいテナント／新しいサブスクリプションで再作成が必要になります。
作り直し時に、見落としやすい点をまとめます。
- 課金の確認：古いサブスクリプションが残っていないか、請求が発生していないか（アクセス不能でも課金が残るケースの不安がある場合はサポートに確認）
- 権限の確認：新テナント側で自分が Global Administrator になっているか（作成者は既定で割り当てられる）
- アプリ連携の再設定：アプリ登録（App registrations）やシークレット、リダイレクト URI、キー・エンドポイントはテナントが変わると別物
裏ワザではなく正攻法：CLI でテナントを指定してログイン確認する
ポータルがややこしい場合、Azure CLI でテナントを明示してログインし、テナント切り替えが正しくできるか確認する方法もあります。
az login --tenant <テナントID>のように –tenant を付けてログイン- その後に表示されるテナント情報が意図したものか確認
「ポータルではブロック済みテナントに飛ばされるのに、CLI では新テナントに入れる」など、切り分け材料としても役立ちます。
再発防止：個人テナントでも“放置しない仕組み”を作る
個人の検証環境は、忙しくなると簡単に放置されます。放置が原因でブロックされると、復旧の猶予が短く、タイミング次第で取り返しがつきません。そこで、次のような軽い運用をおすすめします。
- 月 1 回だけでも、ポータルにサインインしてテナントが生きていることを確認する
- 「ディレクトリ＋サブスクリプション」で正しいテナントを選んだ状態をブックマークしておく（URL 固定ブックマークが効く）
- 検証が終わったリソースは削除し、課金・未使用資産を残さない
よくある質問
ブロックされたテナントは自分で解除できますか？
基本的に、管理者がポータル上の操作だけで解除する導線は用意されておらず、ドキュメントではMicrosoft への連絡（サポート）が案内されています。
新しいテナントに入れたのに、サブスクリプションが見当たりません
テナント（ディレクトリ）とサブスクリプションは 1 対 1 ではありません。テナントを切り替えると、表示されるサブスクリプションが変わります。必要に応じて「サブスクリプション」画面で Change directory（関連付け先の変更）などの操作が絡むこともあります。
エラー画面に aka.ms/TenantLifecycle が出ました。何を見ればいい？
このリンクは Microsoft Learn の「Tenant inaccessible due to inactivity（非アクティブでアクセス不能になったテナント）」に繋がり、再アクティブ化が可能な期間（20日）などの指針が記載されています。
まとめ：詰まりどころは「テナントの入口固定」と「20日ルール」
- AADSTS5000225 は、テナントが非アクティブ扱いでブロックされている状態
- ドキュメント上、非アクティブ状態から 20 日以内が復旧相談の勝負どころ（超えると削除・復旧不可）
- 新しいテナントがあるのに入れない場合は、URL でテナントを明示して入口を固定するのが効果的
- 新テナントに切り替えたら、AI リソースは新しいテナント／サブスクリプションで再作成が必要
コメント