新しく作成した Azure テナントで Azure ポータルにアクセスした際、「AADSTS5000225: This tenant has been blocked due to inactivity.」と表示されてサインインできず、先へ進めないケースが増えています。本記事では、このエラーの意味と、最も再現性の高い解決方法、そして今後同じ問題を防ぐための具体的な運用ポイントをわかりやすく整理します。
Azure ポータルで「AADSTS5000225」が発生する症状
まずは、エラーの全体像を整理します。実際の画面で見える情報をテキストにすると、次のようなイメージです。
| 項目 | 内容 |
|---|---|
| 状況 | Azure ポータル (https://portal.azure.com) にサインインしようとしたタイミングで失敗する。 |
| メッセージ | AADSTS5000225: This tenant has been blocked due to inactivity. |
| 影響範囲 | 対象テナントに対するポータル サインイン、CLI、PowerShell などからの認証がブロックされる。 |
| よくある発生タイミング | ・新規作成したばかりの Azure テナント ・しばらく利用していなかったテナント ・サブスクリプションや課金情報を紐づけていない検証用テナント |
特に「複数のテナントを持っているアカウント」で発生しがちです。アカウント自体 (メールアドレス) は正しいのに、サインイン先のテナント コンテキストが想定とずれているために、エラーになるパターンが多く見られます。
「This tenant has been blocked due to inactivity.」の意味
メッセージだけを見ると、「テナントが完全に削除されたのでは？」と不安になりますが、実際には次のような状態であることがほとんどです。
- テナント自体はディレクトリとして存在している
- Azure 側の判定で「非アクティブ」と扱われ、通常のフローでのサインインがブロックされている
- サインイン時にどのテナントへ入ろうとしているかが曖昧で、意図しないテナント側でブロックされている
つまり、「あなたのアカウントが Azure に入れない」のではなく、「今アクセスしようとしているテナントが、非アクティブ扱いになっている」ことが原因です。ここをきちんと切り分けると、対処の方向性が見えやすくなります。
| よくある誤解 | 実際の状態 |
|---|---|
| アカウントがロックされた | テナント単位でのブロック。アカウント自体は他テナントで利用可能なことが多い。 |
| テナントが完全削除された | 削除ではなく「非アクティブ扱い」のため、条件次第で再有効化が可能。 |
| Azure 自体の障害 | 特定テナントに限定した状態であることがほとんど。別テナントでは問題なくサインイン可能なケースが多い。 |
最も有効な対処：テナントを明示してサインインする
多くのケースでは、「サインイン先のテナントを URL やコマンドで明示するだけ」でエラーが解消します。ここがこのエラーを扱う上での最大のポイントです。
Azure ポータルの URL にテナント ID を指定する
ブラウザーで次の形式の URL にアクセスし、対象のテナントを直接指定します。
https://portal.azure.com/<テナントID>/またはドメインを使って指定します。
https://portal.azure.com/#@<テナントドメイン>例として、テナント ID が 12345678-aaaa-bbbb-cccc-1234567890ab の場合は次のようになります。
https://portal.azure.com/12345678-aaaa-bbbb-cccc-1234567890ab/テナント ドメインが contoso.onmicrosoft.com の場合は次のとおりです。
https://portal.azure.com/#@contoso.onmicrosoft.comこのように URL 側で「このテナントに入りたい」と明示すると、アカウントが複数のテナントに所属していても、意図したテナントへ直接サインインできるようになります。
テナント ID やテナント ドメインの確認方法
すでにどこかのテナントには入れる場合は、Azure ポータルまたは Microsoft Entra 管理センターからテナント情報を確認できます。
- テナント名
- テナント ID（ディレクトリ ID）
- プライマリ ドメイン（例:
xxxxx.onmicrosoft.com）
これらの情報を控えておくと、URL や CLI でテナントを明示する際に迷わなくなります。特に複数テナントを扱う管理者は、テナント ID とドメインの一覧をドキュメント化しておくと便利です。
| 情報 | 用途 |
|---|---|
| テナント ID (GUID) | スクリプト、CLI、PowerShell、URL 指定など機械的な指定に向いている。 |
| テナント ドメイン | ポータル URL など、人間が覚えやすい形式での指定に向いている。 |
| テナント名 | 画面上での識別用。ドキュメントや社内説明での表記に適している。 |
なぜ「テナントを明示する」だけで解決するのか
Azure のアカウントは、1 つのメールアドレスで複数のテナントに所属していることがあります。このとき、https://portal.azure.com のトップページからサインインすると、「以前使っていたテナント」や「ホーム テナント」に自動で接続されることがあります。
もし、その自動的に選ばれたテナントが「非アクティブ扱い」になっていれば、AADSTS5000225 が返されます。一方で、同じアカウントでも、別のテナントに関しては問題なく有効な場合があります。
URL でテナント ID やドメインを明示することで、Azure 側の「自動判定」に任せず、自分でサインイン先のテナントを決めることができるため、ブロックされていないテナントへ直接アクセスできるようになる、という仕組みです。
| サインイン方法 | 挙動 | エラー発生のしやすさ |
|---|---|---|
https://portal.azure.com だけ | 自動的にテナントが選ばれる（直近利用テナント、ホームテナントなど）。 | ブロックされたテナントが選ばれると AADSTS5000225 が発生しやすい。 |
https://portal.azure.com/<テナントID>/ | 指定したテナントに対してサインインを試みる。 | ブロックされていないテナントを指定すれば、エラーを避けやすい。 |
https://portal.azure.com/#@<テナントドメイン> | テナント ドメインを元に対象テナントへ直接接続する。 | 複数テナント運用時の明示的な切り替えに有効。 |
CLI／PowerShell で AADSTS5000225 が出る場合の対処
Azure CLI や PowerShell からログインしようとしたときに同じエラーが出る場合も、基本的な考え方はポータルと同じです。コマンドでテナントを明示することで回避できます。
Azure CLI からのログイン
Azure CLI を利用している場合は、次のように --tenant オプションでテナントを指定します。
az login --tenant <テナントID>サービス プリンシパルでログインする場合も同様です。
az login --service-principal \
--username <アプリケーションID> \
--password <クライアントシークレット> \
--tenant <テナントID>--tenant を付けずに az login だけ実行すると、アカウントが所属している複数のテナントのうち、Azure CLI 側で自動判断されたテナントに接続しようとします。その自動選択先が非アクティブなテナントであれば、ここでも AADSTS5000225 が発生します。
PowerShell (Az モジュール) からのログイン
PowerShell の Az モジュールを利用している場合は、次のコマンドでテナントを明示します。
Connect-AzAccount -Tenant <テナントID>サービス プリンシパルでのログイン例は次のとおりです。
$tenantId = "<テナントID>"
$appId = "<アプリケーションID>"
$secret = "<クライアントシークレット>"
$secureSecret = ConvertTo-SecureString $secret -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential($appId, $secureSecret)
Connect-AzAccount -ServicePrincipal -Tenant $tenantId -Credential $credsログイン後、現在どのテナント／サブスクリプションにいるかを確認するために、次のコマンドもセットで実行しておくと安心です。
Get-AzContext
Get-AzSubscriptionCLI と PowerShell のオプション比較
| ツール | テナント指定のオプション | 補足 |
|---|---|---|
| Azure CLI | --tenant <テナントID> | GUID だけでなく、contoso.onmicrosoft.com のようなドメインも指定可能。 |
| PowerShell (Az) | -Tenant <テナントID> | Connect-AzAccount のほか、コンテキスト切替にも使用可能。 |
新規テナントが「非アクティブ」と判定される背景
「作ってすぐのテナントなのに、なぜ非アクティブ？」と感じるかもしれません。実際には、次のような条件が重なると、Azure 側で自動的に「アクティブな利用がされていないテナント」と判定されることがあります。
- テナントに紐づく有効な Azure サブスクリプションが存在しない
- 課金情報 (クレジット カードなど) が未登録の状態が続いている
- 試用版サブスクリプションの期限が切れたまま放置されている
- 長期間にわたり、ユーザー サインインやリソース作成が行われていない
特に「検証用としてテナントだけ作って、そのまま放置していた」ケースでは、久しぶりに触ろうとしたタイミングで AADSTS5000225 に遭遇しやすくなります。
この状態からの基本的な回復ステップは次のとおりです。
- テナントを明示してポータルへサインインする
- 有効な Azure サブスクリプションをテナントに紐づける
- 課金情報の登録やサブスクリプションの有効化を行う
- 必要に応じてサポートへ「テナントの再有効化」を依頼する
ログイン後に行うべき設定と確認ポイント
無事にポータルへサインインできたら、「二度と同じエラーを起こさない」ための準備をしておくのがおすすめです。
有効なサブスクリプションの関連付け
まずは、そのテナントに対して有効な Azure サブスクリプションが紐づいているか確認します。
- サブスクリプションの状態が「有効（Enabled）」であること
- 請求先情報が正しく設定されていること
- サブスクリプションの所有者／共同管理者に自分が含まれていること
検証用テナントであっても、最低限 1 つは有効なサブスクリプションを持っておくと、非アクティブ判定を受けにくくなります。また、課金を発生させたくない場合は、無料枠や低コストのリソース、停止中の VM などで運用することも検討できます。
グローバル管理者アカウントの確認
対象テナントに対して、少なくとも 2 アカウント以上のグローバル管理者を用意しておくと、万が一のときに復旧しやすくなります。
- メインの管理者アカウント
- バックアップ用の管理者アカウント（別のメールアドレス）
バックアップ用アカウントにも、テナント ID やポータル URL を共有しておくことで、どちらか一方のアカウントに問題があっても、別アカウントからサインインして状況を確認できます。
定期的なサインインと簡易ヘルスチェック
「作ったまま放置」状態を避けるために、最低でも月に一度はテナントへサインインし、次のような簡単なチェックを行うことをおすすめします。
- ポータルへ問題なくサインインできるか
- 主要なリソース（仮想マシン、ストレージ アカウントなど）が想定どおりに表示されるか
- サブスクリプションの有効期限や課金の警告が出ていないか
この程度のライトな運用でも、「気付いたらテナントが非アクティブ扱いになっていた」というリスクを大きく減らすことができます。
テナントを明示してもサインインできない場合
テナント ID を URL や CLI で指定しても AADSTS5000225 が解消しない場合は、そのテナント自体が Azure 側でより厳格にブロックされている可能性があります。具体的には次のようなケースが考えられます。
- 長期間まったく利用されておらず、自動的にブロックされた
- サブスクリプションの未払いなどでテナント レベルの制限がかかっている
- コンプライアンス上の理由により、Microsoft 側でテナントが保護措置の対象となっている
このようなケースでは、自力での復旧には限界があるため、サポートへ「テナント再有効化 (Re-enable tenant)」を依頼する必要があります。
サポート チケットを起票する際のポイント
サポート宛てに起票する際は、次の情報を整理しておくと話がスムーズです。
- 問題のテナント ID
- テナント ドメイン（例:
contoso.onmicrosoft.com） - エラー メッセージの全文（AADSTS5000225 を含む）
- 発生日時と、これまで試した対処内容（テナントを明示してのサインイン、CLI でのテナント指定など）
また、問題のテナント自体にサブスクリプションが無く、ポータルから直接サポート チケットを起票できない場合は、以下のようなアプローチも検討します。
- 別テナントで保有している有効な Azure サブスクリプションからサポート チケットを起票し、対象テナント ID を明記する
- 組織で契約している他の Microsoft クラウド（例: Microsoft 365）のサポート経由で相談する
複数テナントを運用する場合のベストプラクティス
AADSTS5000225 は、複数テナントを並行運用している環境ほど発生しやすいエラーです。運用レベルで工夫しておくと、そもそもトラブルに巻き込まれるリスクを減らせます。
テナントごとの「入口」を固定しておく
特定テナントへ入るための URL を、社内ポータルやドキュメントに明記しておくのがおすすめです。
- 運用テナント用 URL：
https://portal.azure.com/#@prod.onmicrosoft.com - 検証テナント用 URL：
https://portal.azure.com/#@dev.onmicrosoft.com - 個人検証テナント用 URL：
https://portal.azure.com/<個人テナントID>/
このように「テナント名とポータル URL のセット」をチームで共有しておくと、誤ったテナントにサインインしてトラブルになる確率が大きく下がります。
CLI・PowerShell でもテナントを固定する
スクリプトや自動化でも、テナントを明示するのが基本です。次のような形で、テナント ID を変数化し、スクリプト内で使い回すと安全です。
TENANT_ID="12345678-aaaa-bbbb-cccc-1234567890ab"
az login --tenant "$TENANT_ID"$TenantId = "12345678-aaaa-bbbb-cccc-1234567890ab"
Connect-AzAccount -Tenant $TenantIdこのようにしておけば、スクリプトを実行するたびに「どのテナントに対して操作しているのか」が明確になり、意図しないテナントでエラーを踏むリスクを減らせます。
トラブルシューティング用チェックリスト
最後に、AADSTS5000225 が発生したときに確認すべきポイントをチェックリスト形式でまとめます。実際の運用で困ったときは、この表を上から順に潰していくイメージで確認するとスムーズです。
| 確認項目 | 具体的な確認内容 | 対処例 |
|---|---|---|
| テナントを明示しているか | URL や CLI コマンドでテナント ID / ドメインを指定しているか。 | https://portal.azure.com/<テナントID>/ で再試行する。 |
| テナント ID が正しいか | コピー＆ペーストの際に余計なスペースや文字が混ざっていないか。 | ポータルや管理センターでテナント ID を再確認し、貼り直す。 |
| 別テナントではサインイン可能か | 同一アカウントで他のテナントに問題なく入れるか。 | アカウントではなく特定テナントの問題であることを切り分ける。 |
| サブスクリプションの状態 | 対象テナントに有効なサブスクリプションが紐づいているか。 | 必要に応じて新規サブスクリプションを追加し、課金情報を設定する。 |
| 利用履歴 | 最後にログインまたはリソース操作を行った時期。 | 長期間未使用の場合は、サポートへの再有効化依頼を検討する。 |
| サポートへの連絡 | 自力での解消が難しいかどうか。 | テナント ID とエラー メッセージを添えて、サポート チケットを起票する。 |
まとめ：まずは「テナントを明示してサインイン」する
AADSTS5000225 はメッセージだけ見るとインパクトが大きく、「テナントが完全に使えなくなった」と感じてしまいがちです。しかし、実務上の多くのケースでは、
- ポータルや CLI でテナントを明示してサインインし直す
- そのテナントに有効なサブスクリプションや課金情報を紐づける
といった対応だけで解消できます。
特に、複数テナントを持つアカウントで Azure を利用している場合は、「常にテナントを明示する」という運用ルールを設けておくことが、エラー回避にもセキュリティ向上にもつながります。もし、テナントを明示してもなお解消しない場合は、早めにサポートへ相談し、「テナント再有効化」を依頼するのが確実です。
要点をもう一度整理すると、
- エラーの正体は「テナントが非アクティブ扱いでブロックされている」状態
- まず試すべきは、テナントを明示したサインイン（URL や CLI オプションの活用）
- ログインできたら、有効なサブスクリプションの関連付けや課金情報の設定を行う
- それでもダメなら、必要情報を揃えてサポートへ「再有効化」を依頼する
この流れを押さえておけば、AADSTS5000225 に遭遇した際も落ち着いて切り分けと対処を進められるようになります。
コメント