Azure 無料試用版や検証用の環境で突然サインインできなくなり、「AADSTS5000225: このテナントは非アクティブのためブロックされています」というメッセージに阻まれるケースが増えています。本記事では、なぜこの状態になるのか、どこを確認すればよいのか、そして最短で復旧するための実務的な手順を、サポートへの依頼テンプレートや再発防止の運用設計例まで含めて詳しく解説します。
現象の概要（エラー「AADSTS5000225」）
Azure のサインイン画面または Azure Portal で、以下のエラーが表示されサインインできない状態です。
エラー コード: AADSTS5000225
このテナントは非アクティブのためブロックされています。
無料試用版の登録途中・直後、あるいは長期間触っていなかった検証用テナントで発生することが多く、クレジットカード側では登録時の少額のオーソリ（与信）だけが見える場合があります。サブスクリプションの課金や利用明細は更新されず、管理者のメールボックスには「お支払い」や「更新」関連の通知が届かない・見落としているといった状況がよく見られます。
なぜブロックされるのか：原因と内部メカニズム
ポイントは「ディレクトリ（Microsoft Entra ID／旧 Azure AD）のアクティビティが一定期間観測されないと、課金／ライセンス管理側の評価によりテナント全体のサインインが抑止される」という点です。本記事の対象ケースでは、最終課金サイクルから約 200 日以上アクティビティが認められないテナントが 非アクティブ とみなされ、OMS（課金システム）側の判定によりサインインがブロックされます。
| 項目 | 内容（要点） |
|---|---|
| 原因 | 最終課金サイクルから約 200 日以上利用なし → 課金システムのポリシーで非アクティブ判定 → ログイン抑止（ブロック）。 |
| 復旧条件 | ブロックから20 日以内（ドキュメント上は最大 30 日以内の記載あり）にサポートへ解除依頼。期限超過でテナントは完全削除・復元不可。 |
| サポートに伝える情報 | 1) テナント ID もしくはカスタム ドメイン名 / 2) 連絡用メールアドレス / 3) 業務影響と復旧理由（なぜ今必要か）。 |
| 解除後のログイン | ブラウザーで https://portal.azure.com/<テナントID> にアクセスし、対象テナントを直接指定してサインイン。 |
| 復旧不能時 | 完全削除後は復元できないため、検証用途などは新規テナントを作成して再構築。 |
タイムラインで理解する
| 時点 | 状態 | 取れるアクション |
|---|---|---|
| 最後のアクティビティ ～ 200 日未満 | 通常稼働 | 定期サインインや軽量ジョブの実行でアクティブを維持。 |
| 約 200 日経過時点 | 非アクティブ判定 → ブロック | サインイン不可。20 日以内にサポートへ解除依頼。 |
| ブロックから 20～30 日 | 解除できる場合あり（ドキュメント上の猶予） | サポート判断。可否・必要情報・本人確認に迅速対応。 |
| 猶予超過 | テナントは完全削除 | 復元不可。新規テナントで再構築。 |
まず確認すべきチェックポイント
- テナント識別子を把握：テナント ID（GUID）またはカスタム ドメイン名（例：
contoso.onmicrosoft.com）。 - 誰が管理者か：グローバル管理者（全体管理者）の連絡先が生きているか。退職やメール停止があると通知が失われます。
- 最後に使った時期：おおよその最終サインインやリソース更新の時期を関係者で突き合わせ。
- 課金状態：サブスクリプションの種類（無料試用版／従量課金など）と支払い方法。オーソリのみで確定課金がないケースもありえます。
- 業務影響の整理：今止まって困っているシステム・検証計画・期限。サポートへの説得材料になります。
- 代替策の有無：緊急時に新規テナントを切って代替できるか、データの移行可能性はあるか。
用語を正しく理解する：テナントとサブスクリプションの違い
| 用語 | 意味 | 例 |
|---|---|---|
| テナント（ディレクトリ） | Microsoft Entra ID の「組織」。ユーザー、グループ、アプリの身元管理を司る。 | contoso.onmicrosoft.com / テナント ID（GUID）。 |
| サブスクリプション | Azure リソースの課金単位。テナントに紐づくが、テナントとは別概念。 | 無料試用版、従量課金、CSP 契約など。 |
| ライセンス | Microsoft 365 や Entra 製品の利用権。ユーザーやテナントに割り当て。 | Entra ID P1/P2、Microsoft 365 E3/E5 等。 |
今回のエラーは「テナント（ディレクトリ）側のブロック」である点が重要です。サブスクリプションの支払いが止まっているだけでは再現しない場合がある一方、ディレクトリが非アクティブ判定されるとサインイン自体が抑止されます。
復旧までの具体手順（最短ルート）
- テナント情報を確定
テナント ID（GUID）またはカスタム ドメイン名を関係者と確認します。記録がなければ、過去の構築メモやアプリ設定、ローカルの Azure CLI/PowerShell のプロファイル痕跡などを探します。 - 業務影響を一枚に整理
「誰が」「何の目的で」「いつまでに」「何を再開する必要があるか」を箇条書きでまとめます。 - サポート依頼テンプレを準備
下のテンプレートに沿って、必要情報を過不足なく用意します。画面のスクリーンショット（エラーコードが見えるもの）も添付用に保管します。 - ブロックからの経過日数を見積もる
「最後の利用日」または「最後の請求サイクル」からの経過を関係者の記憶やメールで推定し、20 日以内（最大 30 日）に該当する可能性が高いときは直ちに解除依頼を出します。 - サポートへ連絡
依頼テンプレをベースに、本人確認や追加質問に即応できる体制で連絡します。組織の代表アドレスだけでなく、担当者個人の連絡先も併記するとスムーズです。 - 解除後の初回サインイン
解除通知を受け取ったら、ブラウザーでhttps://portal.azure.com/<テナントID>にアクセスして対象テナントを明示し、グローバル管理者でサインインして状態を確認します。 - 重要アカウント・通知設定の見直し
通知先メール、代替連絡手段、予算・期限のアラート、管理者の二段階認証、ブレイクグラス（非常用）アカウントの整備を行います。 - 再発防止の軽量ジョブを配置
「半年に 1 回のサインイン」「月次の軽量 API 実行」「請求メールのルール化」をスクリプトや運用ルーチンに落とし込みます。
サポート依頼テンプレート（コピペ可）
件名: テナント非アクティブ (AADSTS5000225) 解除のお願い
内容:
お世話になっております。以下テナントでサインイン時に
「AADSTS5000225: このテナントは非アクティブのためブロックされています」
が発生し、管理作業ができない状態です。
1. テナント ID / カスタムドメイン:
* TenantID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
* Domain: contoso.onmicrosoft.com
2. 連絡先メールアドレス:
* 管理者: [[email protected]](mailto:[email protected]) / 090-xxxx-xxxx
3. 業務影響と復旧が必要な理由:
* 新規プロジェクトの検証環境準備のため至急復旧が必要
* 既存アプリの構成確認が止まっている
最後にテナントを利用したのはおおよそ yyyy/mm/dd です。
ブロック解除の可否と、必要な確認事項をご教示ください。
スクリーンショットも添付しております。
以上、よろしくお願いいたします。 解除後のログイン手順（確実にテナントを指定する）
- すべてのブラウザーでいったんサインアウトし、シークレット（プライベート）ウィンドウを開きます。
- アドレスバーに
https://portal.azure.com/<テナントID>を入力してアクセスします。
例：https://portal.azure.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - 解除対象のテナントのグローバル管理者でサインインします。
- サイドバーから「Microsoft Entra ID」を開き、ユーザー・グループ・アプリ登録・監査ログなど基本機能が利用できるか確認します。
- 必要に応じて「既定ディレクトリ」やホームテナントの既定設定を確認し、誤選択を防ぎます。
復旧不能時：新規テナントでやり直す手順の指針
猶予期間を超えて完全削除に至った場合は復元できません。検証・ PoC（概念実証）用途であれば、新規テナントを作成して再構築する方が早く、セキュリティ上もクリーンです。以下は再構築時の実務的チェックリストです。
- 命名規則：
<会社/部門略称>-<用途>-<環境>（例：ctso-lab-dev）。 - カスタムドメイン：本番と検証で混同しない別ドメイン、またはサブドメインを用意。
- アクセス設計：グローバル管理者は 2 名以上＋非常時のブレイクグラス（MFA なし保管厳格）。
- 監査と責任：所有者（Owner）と共同管理者の範囲を明確化。退職・異動時の引き継ぎ手順を定義。
- ライフサイクル：検証完了時の廃止手順（停止 → 保管 → 削除）と、非アクティブ化を防ぐ定期タスクの残置。
再発防止：運用のベストプラクティス
定期ログインでアクティブ維持
- 少なくとも半年に 1 回は、グローバル管理者アカウントで Azure Portal にサインイン。
- 不要なテナント混在を避けるため、ブックマークで対象テナントの URL を明示（
https://portal.azure.com/<テナントID>）。
軽量ジョブの自動実行
「人の手のログイン」に頼らず、軽い API 呼び出しやストレージ操作を月次で実行する方法です。最小構成の例を示します（クラウド側の価格や無料枠に留意）。
# Azure CLI の例（月 1 回の軽量操作）
# 前提: サービスプリンシパルに必要最小限の権限を付与
az login --service-principal -u <appId> -p <password> --tenant <tenantId>
az account show
az storage account list --query "[].name" --output tsv
「アカウント一覧の取得」など読み取り系のコマンドは負荷が小さく、監査ログにも残るためアクティビティの証跡として有効です。
課金・期限の通知を確実に受ける
- 請求・期限・残高・上限到達のアラートを、個人メールに依存せず「グループアドレス」へ集約。
- 監査・請求メールは自動ラベル化し、未読・重要の可視化ルールを設定。
- 契約・更新日をチームのカレンダー（休日考慮）に登録。2 段のリマインダー（30 日前／7 日前）。
アカウントと権限の健全性
- グローバル管理者は最小限。日常運用は特権ロール管理者／アプリ管理者など役割分担。
- MFA と条件付きアクセスで不正ログインを抑止。ブレイクグラスは厳格に金庫・封緘管理。
- 人事イベント（退職・長期休暇）時の権限棚卸しを標準手順に。
技術的な深掘り：何が「アクティビティ」とみなされるか
非アクティブの評価は複数シグナルの合成と考えるのが実務的です。典型的には以下が手掛かりになります。
- 管理者やユーザーによるポータル／API サインイン履歴（監査ログ・サインインログ）。
- サブスクリプションの課金トランザクションやリソース利用メトリクス。
- アプリ登録やサービス プリンシパルのトークン発行（機械的なアクセス）。
「月次で軽い API 呼び出しを行う」「サービスプリンシパルでスクリプトを実行する」など、人のログインに頼らないアクティビティを設計すると安定します。
Microsoft Graph PowerShell の確認例
# 監査ログや組織情報の取得例（読み取り）
Connect-MgGraph -TenantId <tenantId> -Scopes "Organization.Read.All","AuditLog.Read.All"
Get-MgOrganization | Format-List Id,DisplayName,VerifiedDomains
Get-MgAuditLogSignIn -Top 5 | Select-Object CreatedDateTime,UserDisplayName,Status | Format-Table
トラブルパターン別 FAQ
Q. クレジットカードには少額の請求（オーソリ）しかない。課金停止なのに、なぜ「テナントがブロック」になるの？
A. 課金の有無とディレクトリのアクティビティは別の軸です。請求がほぼ動かない場合でも、テナント側の非アクティブ判定（長期間のサインインや操作がない等）によりブロックされることがあります。
Q. 解除の猶予は 20 日なの？ 30 日なの？
A. 実務上の目安は20 日以内で、ドキュメント表記では最大 30 日の猶予が案内される場合があります。確実を期すなら「ブロックに気づいた時点で即連絡」が最善です。
Q. どの情報を添えればサポート対応が早い？
A. テナント ID（またはカスタム ドメイン）・業務影響・最後の利用見込み日・エラー画面のスクショの 4 点が揃っていると、ヒアリングの往復が少なくなります。
Q. 解除後にまたすぐブロックされないか不安。
A. 解除後 48 時間はログ・レプリケーションの都合で挙動が安定しないことがあります。落ち着いたら、月次の軽量ジョブと半年に 1 回のログイン、通知メールの分配を設定してください。
Q. 完全削除されたら本当に復元できない？
A. 復元不可です。再利用したいカスタムドメインは削除の反映待ち期間が発生する可能性があるため、新規テナントで一時的に別ドメインを使う計画も用意しましょう。
最小構成の「非アクティブ回避」ジョブ例（実装サンプル）
Windows タスク スケジューラ + PowerShell
# 月 1 回 / サービスプリンシパルで読み取り API を叩く
# 事前にアプリ登録し、証明書またはクライアントシークレットを安全に保管
$TenantId = "<tenantId>"
$AppId = "<appId>"
$Secret = ConvertTo-SecureString "<clientSecret>" -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential($AppId, $Secret)
# Azure リソース側（必要なら）
az login --service-principal -u $AppId -p "" --tenant $TenantId | Out-Null
az account show | Out-Null
# Graph PowerShell 側（組織情報と最新 1 件のサインイン）
Connect-MgGraph -TenantId $TenantId -ClientId $AppId -ClientSecret "" -Scopes "Organization.Read.All","AuditLog.Read.All"
(Get-MgOrganization).DisplayName | Out-File -FilePath "$env:TEMP\tenant_keepalive.txt" -Encoding utf8
(Get-MgAuditLogSignIn -Top 1).CreatedDateTime | Out-File -Append -FilePath "$env:TEMP\tenant_keepalive.txt" 証明書認証に切り替えるとセキュリティと可用性が向上します。シークレットはキーコンテナや安全な保管庫に置き、権限は最小権限で付与してください。
チェックリストでの総括
| カテゴリ | 推奨アクション | 備考 |
|---|---|---|
| 初動 | テナント ID／ドメインを確定、業務影響を 5 行で要約、スクショ取得。 | 依頼の往復を減らす。 |
| 猶予確認 | ブロックから 20 日（最大 30 日）以内か概算。 | 少しでも可能性があれば即依頼。 |
| 連絡 | テンプレに沿ってサポートへ申請。本人確認への即応体制。 | 担当の携帯・代替メールも併記。 |
| 解除後 | https://portal.azure.com/<テナントID> から直接サインイン。 | 誤テナント選択の回避。 |
| 運用 | 月次軽量ジョブ＋半年に 1 回のログイン。通知のグループ化。 | 人依存の排除。 |
| セキュリティ | MFA、条件付きアクセス、ブレイクグラスの見直し。 | 非常時手順を台帳化。 |
| 代替策 | 期限超過時は新規テナントで再構築。 | 命名規則と権限設計を先に決める。 |
エスカレーションと社内周知
エスカレーション基準
- ブロックからの経過が 20 日を超える見込み → 即時エスカレーション。
- 本番の依存アプリが停止 → 影響範囲と代替案を 2 時間以内に提示。
- 管理者アカウント全滅（メール不通） → 非常連絡網で対応、代表電話・契約窓口に並行コンタクト。
社内周知テンプレ（短文）
【周知】Azure テナントの一時ブロック発生と復旧対応
・対象: <テナント名/ID>
・現象: サインイン時に「AADSTS5000225」
・影響: 管理ポータルへのアクセス不可（ユーザー影響は限定的/要確認）
・対処: サポートへ解除依頼済み（受付番号: <xxxx>）
・再発防止: 月次軽量ジョブ＋半年ログイン、通知先の見直しを実施予定
ご不明点は <連絡先> まで
監査・コンプライアンス対応の視点
- 台帳整備：テナント ID、契約形態、管理者、通知先、ライフサイクル計画を 1 枚に。
- 証跡の保管：ブロック発生から解除までのやり取り、スクリーンショット、実行スクリプトのログを保存。
- 権限の適正化：緊急時にのみ使う権限と通常運用の権限を分離し、最小権限化を継続。
セキュリティ上の注意点
- 解除直後はフィッシングを装った偽連絡に注意。メールの送信ドメインと文面整合性を確認。
- ブレイクグラスの認証情報は紙と金庫で保管。クラウド上のメモや共有チャンネルに置かない。
- 古いアプリ登録や不要なサービスプリンシパルは棚卸しし、必要最小限のスコープへ権限縮小。
トラブルの根本を断つ運用設計例（参考アーキテクチャ）
「小さく作って確実に回す」ための最小構成案です。
| 構成要素 | 役割 | ポイント |
|---|---|---|
| サービスプリンシパル（アプリ登録） | 月次の読み取り API 呼び出し | 証明書認証。権限は Organization.Read.All 等の最小付与。 |
| スケジューラ | 定期実行（月 1 回） | 失敗通知をメール／チャットに転送。3 回連続失敗で人手対応。 |
| ログ保管 | 実行結果の証跡 | 時刻・実行 ID・対象テナントを記録し 1 年以上保管。 |
| アラート | 検知と初動 | 未実行 45 日で注意、75 日で警戒、150 日で緊急の 3 段階。 |
まとめ：今日からできる 3 ステップ
- 現状把握：テナント ID・管理者・最終利用・通知先を洗い出し。
- 即応準備：解除依頼テンプレとスクショ、連絡網を整備。
- 仕組み化：月次軽量ジョブ、半年ログイン、通知のグループ化と予算アラート。
「AADSTS5000225」は珍しいようでいて、運用の隙間から誰にでも起こり得る典型的インシデントです。初動を速く、再発防止は仕組みで。これだけで、大半のリスクは現実化しなくなります。
付録：記事の要点（クイックサマリー）
- 長期非アクティブ（目安 200 日）でテナントがブロックされる。
- ブロックから20 日以内（最大 30 日）ならサポート解除の余地あり。過ぎると完全削除で復元不可。
- 解除後は
https://portal.azure.com/<テナントID>で対象を明示してサインイン。 - 防止策は「定期ログイン」「軽量ジョブ」「課金通知の運用化」。
- 復旧不能時は新規テナントを短時間で立ち上げ、命名・権限・通知を最初から健全化。
コメント