AADSTS5000225でAzure ADテナントが非アクティブによりブロックされた？解除・復旧の切り分け手順（Microsoft Entra ID）

Azure AD（Microsoft Entra ID）でログイン時に「非アクティブのためブロックされました（AADSTS5000225）」が出ると、Azure ポータルも Azure CLI も操作できず焦ります。本記事では、テナントが本当にブロックされたケースと、ツールが古いテナントを参照しているだけのケースを切り分け、最短で復旧する手順をまとめます。

AADSTS5000225（非アクティブでブロックされたテナント）とは

AADSTS5000225 は、Microsoft アカウント／職場アカウントでサインインしようとした際に「このテナント（ディレクトリ）は非アクティブのためブロックされました」といった趣旨のメッセージと一緒に返ってくるエラーです。ポイントは、サブスクリプション単位の停止ではなく、ディレクトリ（テナント）単位でサインインが拒否される可能性がある点です。

Azure AD は現在 Microsoft Entra ID という名称で提供されています。本記事では便宜上「Azure AD（Microsoft Entra ID）」と表記します。

まず押さえる：テナント／サブスクリプション／ユーザーは別物

Azure の障害切り分けは「どの単位が止まっているか」を間違えると遠回りになります。似た言葉が多いので、最初に整理しておきます。

対象	止まると何が起きる？	典型的なサイン
テナント（ディレクトリ）	ユーザー認証そのものが影響を受け、ポータル／CLI の入口で弾かれる	AADSTS5000225 など「tenant がブロック」系のエラー
サブスクリプション	サインインはできるが、リソース操作や課金周りが制限される	ポータルには入れるが、特定のサブスクリプションが「無効」「停止」
ユーザー／ロール	本人だけ入れない、または一部操作だけできない	他ユーザーは入れる／権限不足のエラーが出る

実務で多いのは「本当にテナントがブロック」か「参照しているテナントが違う」

現場では次の2パターンが混在します。

パターン	実際に起きていること	初動の方向性
本当にテナントがブロック	テナント全体が無効化・ブロック状態になり、所属ユーザーがサインインできない	早急に Microsoft へ解除依頼（アカウント／請求窓口等を含む）
ツールが古いテナントを参照	Visual Studio / VS Code / Azure CLI が、過去に使っていた別テナントをキャッシュしており、そのテナントがブロックされている	キャッシュ削除・再ログイン・テナント明示で切り替える

結論として、「テナントが本当にブロックされたのか」と「自分がどのテナントに向けて操作しているのか」を分けて確認するのが復旧の近道です。

エラー画面で必ず控える情報（復旧を速くするメモ）

AADSTS 系のエラーは、画面の下部に「相関 ID（Correlation ID）」「タイムスタンプ」「アプリ名」などが出ることがあります。サポート相談やログ調査で役立つので、スクリーンショットかテキストで控えておきましょう。

項目	例	用途
エラーコード	AADSTS5000225	原因カテゴリの特定
相関 ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	サインインログや内部ログの追跡
タイムスタンプ	2025-12-20 10:30:00Z など	該当ログの絞り込み
対象のテナント情報	xxx.onmicrosoft.com / テナントID	「参照テナント違い」の確認

最初にやるべき切り分け（10分で分かるチェック）

まずは現象を「範囲」で切り分けます。以下の表で、該当する行から順に確認してください。

確認ポイント	YES（該当）	NO（該当しない）
そのテナントの全ユーザーが AADSTS5000225 で弾かれる	テナント側のブロック可能性が高い → 「本当にブロック」へ	ユーザー／端末／ツール固有の問題の可能性 → 「キャッシュ疑い」へ
ブラウザで Azure ポータルに入ろうとしても、同じエラーで入れない	テナント側のブロック可能性が高い → 「本当にブロック」へ	CLI や IDE だけで起きるならキャッシュ濃厚 → 「キャッシュ疑い」へ
別端末（スマホや別PC）でも同じ	テナント側のブロック可能性が高い	端末固有のキャッシュ／資格情報の可能性
同じアカウントで別テナントにはログインできる	「ブロックされたテナント」ではなく「参照しているテナント」が違う可能性	アカウント側（MFA、条件付きアクセス等）の可能性

ケース：本当にテナントが非アクティブでブロックされている場合

コミュニティ回答としては、ブロック後の一定期間内ならサポート経由で解除できるが、期間を過ぎると完全削除で復旧不可という整理がされていることがあります。目安として「20日以内なら解除の余地がある」と言及されるケースがあり、もしこの条件に該当しそうなら、とにかく早く連絡して状況を説明するのが最優先です（ポリシーは変更される可能性があるため、最新の公式案内は必ず確認してください）。

有償サポートがなくても「連絡ルート」は作れる

「サポートプランがない＝詰み」になりがちですが、実際にはアカウント／請求関連の問い合わせやサブスクリプション管理系の問い合わせなど、比較的入口が用意されているケースがあります。テナントブロックは技術案件というより「アカウント状態」の問題として扱われることもあるため、次の順で当たるのが現実的です。

• Azure のアカウント／請求（Billing）サポート：課金・契約・テナント状態の相談として入口になりやすい
• Microsoft 365 管理センターのサポート（何らかの M365 契約がある場合）：テナント管理に近い窓口になりやすい
• パートナー／リセラー経由（CSP 等で契約している場合）：契約形態によっては代理で起票してもらえる

問い合わせ文テンプレ（コピペして整えるだけ）

サポートに連絡するときは「何ができないか」「いつからか」「どのテナントか」が伝わると前に進みます。以下をたたき台にしてください。

件名：AADSTS5000225 によりテナントが非アクティブでブロックされサインインできない

・テナントID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・初期ドメイン：xxx.onmicrosoft.com
・発生日時：2025/12/20 10:30 JST（継続中）
・影響範囲：当該テナントの全ユーザーがサインイン不可、Azure ポータル/CLI ともに不可
・表示エラー：AADSTS5000225（相関ID：xxxx... / タイムスタンプ：xxxx...）
・目的：PoC 継続のため、テナントの状態確認と再有効化（アンロック）可否を確認したい 

連絡時に準備しておくと話が早い情報

解除依頼は「本人確認・契約確認」に時間を取られがちです。次をあらかじめまとめておくと、やり取りが短縮できます。

項目	例	なぜ必要か
テナント ID（GUID）	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	同名ドメインがある場合でもテナントを一意に特定できる
初期ドメイン名	xxx.onmicrosoft.com	テナント識別の手がかりになる
影響範囲	全ユーザーがサインイン不可／管理者も不可 等	切り分け（テナント問題か個別問題か）に直結
発生日時	2025/12/20 10:30 JST など	ログ追跡に必要（相手側で調査しやすい）
エラー詳細	AADSTS5000225、表示メッセージ、相関 ID	サインインログと突合しやすい

PoC なら「復旧できない場合」のプランBも同時に用意する

検証用途のテナントは、復旧に時間がかかると計画全体が止まります。解除依頼と並行して、次のプランBも準備しておくと安全です。

• 新しいテナントを作成し、検証手順を再現可能な手順書として整備する
• IaC（Bicep / Terraform）やスクリプトを整えて、環境を作り直せる状態にする
• テナント固有データ（アプリ登録、証明書、条件付きアクセス等）は「どこまで必要か」を棚卸しする

ケース：実は「テナントが原因ではない」— ツールが古いテナントを参照している

現場でよくあるのが、過去に使っていたテナント情報が Visual Studio / VS Code / Azure CLI に残り続け、コマンド実行やデプロイ時だけ AADSTS5000225 になるパターンです。ブラウザで正しくログインできるのに、IDE や CLI だけ失敗する場合はこの可能性が一気に高まります。

まずは「今どのテナントに向いているか」を可視化する

Azure CLI を使っているなら、次のコマンドで現在のコンテキスト（テナント／サブスクリプション）を確認できます。

az account show
az account list --output table

ここで表示される tenantId が、想定しているテナントのものか確認してください。別テナントの ID が出ている場合、コマンドは「間違ったテナント」に対して実行されています。

Azure CLI のキャッシュをクリアして切り替える（基本手順）

最も手堅いのは、いったん完全にログアウトし、キャッシュをクリアしてからログインし直すことです。

az logout
az account clear
az login

複数テナントを持っていて選択がブレる場合は、ログイン時にテナントを明示します。

az login --tenant <テナントID または xxx.onmicrosoft.com>

サブスクリプションも明示しておくと、後工程の「別サブスクリプションにデプロイしてしまう事故」を防げます。

az account list --output table
az account set --subscription <サブスクリプションID>

Azure ポータル側で「ディレクトリ + サブスクリプション」を確認する

同じアカウントが複数テナントに所属している場合、ポータルの見た目上はログインできていても「表示しているディレクトリ」が違うことがあります。ログインできる状態なら、ポータルでディレクトリを明示的に切り替えて確認しましょう。

• Azure ポータル上部の検索ボックスで「ディレクトリ」または「ディレクトリ + サブスクリプション」を検索する
• 一覧から目的のディレクトリ（テナント）にチェックを付けて切り替える
• 切り替え後に、対象サブスクリプションが表示されるか確認する

ここで目的のテナントが表示されない、または切り替えでエラーになる場合は「本当にブロック／削除」の可能性もあるため、サポート相談ルートへ進みます。

それでも直らない場合に効く「ローカル資格情報の掃除」

環境によっては、CLI コマンドだけでは古いトークンが残り続けます。次の観点で「どこに認証情報が残っているか」を掃除します（削除前に業務影響がないことを確認してください）。

対象	残りやすいもの	対処の例
Azure CLI	ローカルのトークン／アカウント情報	az logout、az account clear、必要なら Azure CLI のキャッシュディレクトリを削除
Visual Studio	サインインしたアカウント情報、古いテナントの選択状態	VS からサインアウト → アカウント削除 → 再サインイン（利用テナントを選択）
VS Code	Azure Account 拡張のサインイン状態	拡張機能側でサインアウト → 再サインイン、必要なら拡張のキャッシュをクリア
Windows 資格情報	MSAL/ADAL 系のトークン、Office/VS が共通利用する資格情報	資格情報マネージャーで「Microsoft」「Azure」関連を見直す（慎重に）

Visual Studio / VS Code での具体的なやり直し手順

画面表記はバージョンや拡張機能で多少変わりますが、考え方は同じです。「サインアウトして、古いテナント選択を消し、改めて正しいテナントにサインイン」します。

Visual Studio の場合

• Visual Studio 右上のアカウントアイコンからサインアウトする
• 「アカウントの管理」画面で、不要なアカウントや古いテナントを外す（可能なら削除）
• Visual Studio を再起動し、目的のアカウントでサインインし直す

VS Code の場合

• コマンドパレット（例：Ctrl + Shift + P）で Azure: Sign Out（または同等のサインアウト）を実行
• 再度 Azure: Sign In でサインインし、目的のテナントに切り替える
• 改善しない場合は拡張機能（Azure Account / Azure Tools 等）を一度無効化→有効化、または再インストール

「既定ディレクトリ」問題で迷子にならないための整理

Azure では「アカウント」「テナント」「サブスクリプション」が別物です。特に PoC のようにテナントを作り直すと、同じ人が複数テナントに所属する状態になり、ツールが「最後に使ったテナント」を既定にしてしまうことがあります。

用語	ざっくり説明	混乱ポイント
アカウント	ログインする主体（ユーザー）	1つのアカウントが複数テナントに所属できる
テナント（ディレクトリ）	ユーザーやアプリ登録を管理する入れ物（Entra ID）	「既定ディレクトリ」が意図せず切り替わることがある
サブスクリプション	Azure リソース課金の単位	テナントと紐づくため、テナントを間違えると操作先も間違える

迷ったら、テナント ID を基準に「今の操作先はどこか」を確認し、az login --tenant で明示するのが最も確実です。

PoC で役立つ「再発防止」の実践ポイント

検証テナントは「しばらく触らない」ことが多く、結果として認証周りの事故が起きやすくなります。次の運用を入れておくと、同じトラブルが再発しにくくなります。

• テナント ID・初期ドメイン・検証目的を1枚のメモにまとめ、チームで共有する
• 月1回など、定期的に Azure ポータルにサインインして状態確認する（リマインダーを設定）
• CLI は az login --tenant を基本形にして、既定テナント依存を減らす
• 検証環境は IaC 化して「作り直せる」状態に寄せる（復旧不能時の保険）
• 管理者アカウントは必要最低限にしつつ、緊急用のブレークグラスを別管理する

よくある質問

有償サポートがないと本当に解除は無理ですか？

状況により異なりますが、テナントブロックは「技術サポート」よりも「アカウント状態・契約状態」の扱いになることがあり、課金・契約関連の窓口が入口になるケースがあります。まずはアカウント／請求系のルート、M365 契約があるなら管理センターのサポートも含めて当たり、テナント ID と影響範囲を具体的に提示して相談するのが現実的です。

CLI だけ失敗します。テナントがブロックされたと決め打ちして良いですか？

ブラウザではログインでき、CLI/IDE だけ失敗するなら、まずは「ツールが古いテナントを参照している」可能性を疑ってください。az account show で tenantId を確認し、az logout → az account clear → az login --tenant の順で切り替えると改善することが多いです。

テナントを作り直す場合、最低限どこを見直せばいい？

PoC でも影響が大きいのは、アプリ登録（クライアント ID）、証明書・シークレット、条件付きアクセス、ロール割り当て、リソースの RBAC です。新テナントで再現できるように、作業ログを残し、可能ならテンプレート化しておくと移行がスムーズです。

まとめ：AADSTS5000225 は「テナントの生死」と「参照先ミス」を同時に疑う

• 全ユーザーが入れずポータルも不可なら、テナントブロックの可能性が高い。目安として「早期なら解除の余地がある」とされることがあるため、アカウント／請求窓口なども含めて速やかに相談する。
• ブラウザはOKで CLI/IDE だけ NG なら、古いテナントを参照している可能性が高い。az logout / az account clear と az login --tenant で「正しい既定テナント」に合わせ直す。
• PoC は作り直せる設計（IaC、手順書、テナント情報の共有）に寄せると、万一の停止でも影響を最小化できる。