Microsoft Entra ID（旧 Azure AD）でテナントを切り替えた際に「AADSTS5000225: This tenant has been blocked due to inactivity」が表示される事例が急増しています。本記事では、ブロックの発生条件、削除までの猶予、解除依頼の具体手順、再発防止（“活動中”の維持）までを、運用に直結する観点でまとめました。検証・学習用の無償テナントや放置気味の検証環境でも起こり得るため、管理者は必読です。
現象とメッセージ
管理センターや Azure ポータル、Azure CLI／PowerShell、Azure DevOps などでディレクトリを切り替えたりサインインしたりすると、次のエラーが表示される場合があります。
AADSTS5000225: This tenant has been blocked due to inactivityこの状態はテナント自体が「非アクティブ（アクセス不可）」に切り替わったことを意味し、通常のログイン操作では復帰できません。グローバル管理者が所定の手順で解除（アンブロック）を依頼する必要があります。
先に結論（要点サマリ）
| ポイント | 内容（運用の勘所） |
|---|---|
| ブロックの発生条件 | 請求期間終了後、長期間（目安：200日以上）まったく利用がないテナントに対し、Microsoft 側のライフサイクル運用により自動でログインブロック（AADSTS5000225）がかかります。通知メールで「200日超の非アクティブ」と案内されるケースが多く報告されています。 |
| 削除までのタイムライン | ブロック（アクセス不可）から原則 20日経過でテナントは削除され、復旧不可になります。案内によっては「30日」表現が混在しますが、安全側の運用として“20日以内対応”を厳守してください。 |
| 解除可能期間 | ブロックから20日以内であれば、グローバル管理者が Microsoft サポートへ解除（再アクティブ化）を依頼可能です。20日を超えると原則復旧できません。 |
| 解除手順の骨子 | （1）グローバル管理者がサポート チケットを起票 →（2）サポートが内部エンジニアリングへ依頼 →（3）アンブロック完了後、直ちにサインインや Graph API 呼び出しなどの「アクティビティ」を発生させ、再ブロックを防止します。 |
| 予防策 | 少なくとも200日に1回はポータルへのサインイン、または自動スクリプトでの Microsoft Graph 呼び出し等を実行し、テナントを「活動中」に保つ。検証用でも通知メール（非アクティブ警告）を見逃さない体制を。 |
なぜブロックされるのか（仕組みの理解）
Microsoft はコスト最適化と保護の観点から、長期間利用のないテナントを「アクセス不可」状態に切り替え、一定期間経過後に削除するライフサイクル運用を実施しています。非アクティブ判定のアルゴリズムは公表されていませんが、実運用上の目安として「200日以上の非アクティブ」がブロックのトリガーとなることが広く確認されています。
なお、ブロック＝削除ではありません。ただしブロック後の猶予は短く、原則 20日です。ここを過ぎるとテナント自体が削除され復旧できません。早期対応が必須です。
| 時点 | 状態 | 管理者ができること |
|---|---|---|
| 非アクティブ期間の進行（～200日目安） | 通常利用（ただし実態は放置） | サインイン／運用タスクを実施し「活動中」に戻す。警告メールに注意。 |
| 非アクティブ閾値到達 | アクセス不可（AADSTS5000225） | 直ちにサポートへ解除依頼。解除後は必ずアクティビティを発生させる。 |
| ブロック後 ～20日以内 | 再アクティブ化の対象 | サポート チケットで解除。復帰直後にログインや API 呼び出しを実行。 |
| ブロック後 20日を超過 | 削除・復旧不可 | バックアップやデータ保全は原則不能。新テナントでの再構築を検討。 |
「アクティビティ」とは何か（再ブロック防止のカギ）
詳細な判定条件は非公開ですが、一般に次のような操作が「アクティビティ」と見なされます。月次～隔月の自動実行を推奨します。
- 管理者またはユーザーのインタラクティブ サインイン（管理センター／ポータルのログイン）
- Microsoft Graph API の呼び出し（例：
/organizationの取得） - 課金やサブスクリプション操作を伴う管理タスク（請求関連の操作等）
非推奨の思い込み：メール配信だけ、無関係な他サービスの利用だけではカウントされないことがあります。「テナント自体へのアクセス」を定期的に発生させてください。
ブロック解除（アンブロック）を依頼する手順
解除は自己操作では行えず、グローバル管理者が Microsoft サポートに依頼します。次の流れが実務の標準形です。
- 前提確認：自組織のグローバル管理者資格情報を保持していること。テナント ID（GUID）やプライマリ ドメイン名（
contoso.onmicrosoft.com等）を控える。 - チケット起票：管理センターのサポート機能または電話窓口から「テナントが非アクティブで AADSTS5000225、解除希望」と明記して依頼する。本人確認やテナント所有の証跡が求められる場合があります。
- エスカレーション：サポートが内部エンジニアリングに連携し、再アクティブ化可否の審査と処置が行われます。
- 解除後の即時対応：すぐに管理ポータルへサインインし、ユーザー一覧の表示や監査ログの参照など複数の操作を行ってアクティビティを明確化。Graph の“疎通”スクリプトも実行しておくと安心です。
よくある詰まりポイント
- 管理者本人がブロックされてログインできない → 別テナントのサポート契約経由で起票、または電話窓口を利用（テナント ID と所有証跡を準備）。
- 「支払いをすれば解除されるのか？」 → 未払いが原因でないケースが多いため、課金情報の更新は不要な場合が一般的。ただし契約状態によって追加対応が必要になり得ます。
再発防止：200日に一度の“活動”を自動化する
月1回～隔月の軽量な Graph 呼び出しを自動実行し、テナントを“活動中”に保つのが実務的です。以下は最小限の例です（監視・監査の都合で月1回を推奨）。
PowerShell（Microsoft Graph SDK／アプリのみ認証）
# 事前にアプリ登録：Application Permission「Organization.Read.All」に管理者同意
# 証明書認証を推奨（シークレットより安全）
# Install-Module Microsoft.Graph -Scope CurrentUser
$TenantId = "<テナントID(GUID)>"
$ClientId = "<アプリ(クライアント)ID>"
$Thumbprint = "<クライアント証明書の拇印>"
Connect-MgGraph -TenantId $TenantId -ClientId $ClientId -CertificateThumbprint $Thumbprint | Out-Null
# テナント情報を取得（“存在確認”の軽い API）
Invoke-MgGraphRequest -Method GET -Uri "[https://graph.microsoft.com/v1.0/organization](https://graph.microsoft.com/v1.0/organization)" | Out-Null
Disconnect-MgGraph cURL（クライアント資格情報フロー／学習用）
# トークン取得
TENANT_ID="<テナントID>"
CLIENT_ID="<アプリID>"
CLIENT_SECRET="<機密情報：環境変数や秘密管理を使用>"
ACCESS_TOKEN=$(curl -s -X POST
-d "client_id=$CLIENT_ID&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=$CLIENT_SECRET&grant_type=client_credentials"
"[https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token](https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token)" | jq -r .access_token)
# 疎通（レスポンスは捨てる）
curl -s -H "Authorization: Bearer $ACCESS_TOKEN"
"[https://graph.microsoft.com/v1.0/organization](https://graph.microsoft.com/v1.0/organization)" >/dev/null GitHub Actions（毎月1日に実行する例）
name: keep-entra-active
on:
schedule:
- cron: "0 3 1 * *" # 毎月1日 12:00(JST相当は環境により調整)
workflow_dispatch:
jobs:
ping:
runs-on: ubuntu-latest
steps:
- name: Call Microsoft Graph (client credentials)
env:
TENANT_ID: ${{ secrets.ENTRA_TENANT_ID }}
CLIENT_ID: ${{ secrets.ENTRA_APP_ID }}
CLIENT_SECRET: ${{ secrets.ENTRA_CLIENT_SECRET }}
run: |
set -e
token=$(curl -s -X POST
-d "client_id=$CLIENT_ID&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=$CLIENT_SECRET&grant_type=client_credentials"
"[https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token](https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token)" | jq -r .access_token)
curl -s -H "Authorization: Bearer $token" "[https://graph.microsoft.com/v1.0/organization](https://graph.microsoft.com/v1.0/organization)" >/dev/null セキュリティの注意：アプリには最小権限（例：Organization.Read.All）を付与し、シークレットより証明書認証を推奨。秘密情報は Key Vault／CI のシークレット管理に格納し、アクセスは監査可能に。
実務で役立つチェックリスト
| 確認事項 | 具体的な観点 |
|---|---|
| 対象テナントの特定 | テナント ID、プライマリ ドメイン、請求契約の有無、最終サインイン日時（把握できる範囲で） |
| 管理権限の確認 | グローバル管理者のアカウント有無、MFA デバイス、生体/番号の利用可否 |
| 通知メールの有無 | 「200日以上非アクティブ」「購入が必要」等の案内メールを見逃していないか（迷惑メールも確認） |
| 解除依頼の準備 | ビジネス影響、復旧目的、テナント所有の証跡（契約書・ドメイン証明など） |
| 復旧後の対策 | 即時のサインイン・Graph 疎通、自動化ジョブのセット、アラート設定 |
「30日」表現が出てくる理由（現場でのギャップ）
フィールドでは「ブロックから30日で完全削除」という説明に出会うことがあります。これは製品領域の違い（Microsoft 365 ライセンス満了後の一般的な猶予）や案内文面の差異が混在しているためです。しかし、非アクティブによるテナントのアクセス不可ケースでは、原則 20日以内に再アクティブ化を依頼するのが最も保守的で安全です。運用設計では「20日で不可逆」を前提にしてください。
よくある質問（FAQ）
Q. 課金をすれば解除されますか？ A. 多くのケースでは未払いが直接原因ではありません。請求・契約の状態によっては購入や更新が促されることもありますが、まずはサポートでの再アクティブ化手続きを行ってください。 Q. Graph を月1回呼ぶだけで十分ですか？ A. 実運用上は有効な対策として広く使われています。念のため管理者のポータル サインインも併用し、アクティビティを多面的に残すと確実です。 Q. どの API が最小で安全ですか？ A. 読み取り専用の /organization の取得など、低負荷かつ読み取り系のエンドポイントが扱いやすいです。アプリ権限は最小限に。 Q. ブロックされたらユーザー データは見られますか？ A. いいえ。テナント自体がアクセス不可になるため、自力での取り出しやバックアップは困難です。解除後すぐに必要データの保全戦略を見直してください。 Q. 監査や規程上、定期アクセスを正当化できるか？ A. 「テナント維持のための健全性チェック」として文書化し、最小権限・記録保持・変更管理を整備すれば、多くの組織で許容されます。
実務 Tips：見逃しを減らす運用レシピ
- メール ルール：件名に「inactive」「200 days」「Entra tenant」等を含む通知をフォルダへ自動仕分け＆高優先度フラグ。
- ジョブの二重化：GitHub Actions とローカルのタスク スケジューラを冗長化し、月次の Graph 疎通を二系統で実行（片系停止の保険）。
- ダッシュボード：最後のサインイン／API 実行時刻を記録し、90日・150日・180日で警報を段階的に鳴らす。
- 権限の棚卸し：自動化アプリの権限は半年ごとに棚卸し、不要権限を削除。証明書は短めの有効期限でローテーション。
トラブルシュート（起票前にできること）
- テナント ID とプライマリ ドメイン名を正確に把握する。
- 組織内に複数のグローバル管理者がいる場合、少なくとも二人で照合し、認証要素（MFA）の有効性を確認する。
- 通知メールの宛先（課金・技術両方）を見直し、共有アドレスで受信できるようにする。
- 解除後すぐに実行する作業リスト（サインイン、ユーザー一覧表示、監査ログ確認、Graph 疎通、ジョブ有効化）を事前に準備しておく。
付録：最小権限アプリの作り方（要点）
- 「アプリの登録」で疎通用アプリを作成。
- 証明書をアプリにアップロード（推奨）。
- API のアクセス許可で
Organization.Read.All（アプリケーション）を追加し、管理者の同意を与える。 - スケジューラ（CI、タスク スケジューラ、オートメーション）で毎月 1 回以上、
/organizationを GET。 - 実行結果（成功／失敗）と実行日時をログに残し、失敗時はメール通知。
まとめ
AADSTS5000225 は、Microsoft Entra ID の非アクティブ化（テナントのアクセス不可化）を示すサインです。ブロックから20日以内であればサポート経由で解除を依頼できますが、猶予を超えると削除され復旧不能になります。最善策は定期的な「アクティビティ」の自動化と、通知の見逃しを防ぐ運用です。検証環境や学習用テナントでも軽視せず、「月1回の疎通」＋「起票体制の整備」を今日から導入しましょう。
参考情報（リンクなしの概要）
- Microsoft 公式ガイダンスでは、非アクティブでアクセス不可になったテナントは 20日以内に再アクティブ化を依頼でき、20日を超えると削除とされています。
- 現場事例では、「200日以上の非アクティブ」でブロックの対象となった旨の通知メールやサポート回答が多く確認されています。
コメント