MENU

Azureテナントが非アクティブでブロック（AADSTS5000225）された時の復旧・解除・課金停止ガイド

Azure

Azure ポータルで AADSTS5000225 — This tenant has been blocked due to inactivity と表示され、ログインや課金管理が止まると、不要課金の抑止も復旧手続きも進められません。本記事は「なぜブロックされるのか」「20日以内に何をするか」「解除後に何を止めるか」を、実務テンプレートとコマンド例付きで徹底解説します。

目次

Azure テナントが非アクティブでブロックされたときの全体像

項目要点影響
症状サインイン時に AADSTS5000225 が表示され、ポータルへ入れない。サポート チケット作成、課金/サブスクリプション管理、リソース削除ができない。
背景Databricks Premium へのアップグレード通知を受けたが、確認や解約操作ができない。意図しない請求が継続する可能性。コンプライアンス/セキュリティ上の懸念も残る。
目的①不要サブスクリプション/リソースの停止 ②今後の意図しない請求回避 ③テナント復旧または削除短期: 課金のブレーキ／中長期: 再発防止と運用ルールの整備

ブロックの仕組みと消滅タイムライン

非アクティブなテナントは、課金サイクル終了後 200 日以上ユーザー活動がないと自動ブロックされます。さらにブロックから 20 日経過で完全削除（復旧不可）となります。逆算すると、復旧はブロック後 20 日以内が絶対条件です。

<table>
  <thead>
    <tr>
      <th>段階</th>
      <th>状態</th>
      <th>目安日数</th>
      <th>できること / できないこと</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>通常</td>
      <td>アクティブ</td>
      <td>—</td>
      <td>全操作可</td>
    </tr>
    <tr>
      <td>非アクティブ期間</td>
      <td>沈黙</td>
      <td>課金サイクル終了後 → <strong>200 日</strong>（目安）</td>
      <td>無操作が続くと自動判定が進む</td>
    </tr>
    <tr>
      <td>ブロック後</td>
      <td>ログイン不可</td>
      <td><strong>20 日以内</strong></td>
      <td>通常のポータル操作不可／サポート経由の復旧申請は可能</td>
    </tr>
    <tr>
      <td>完全削除</td>
      <td>物理削除</td>
      <td>ブロック後 <strong>20 日経過</strong></td>
      <td>復旧不可、再作成のみ</td>
    </tr>
  </tbody>
</table>

<div>
  <pre><code>【時間軸イメージ】

課金サイクル終了 ────────────────(200日)───────────────▶ 自動ブロック 自動ブロック ─────(20日)─────▶ 完全削除（復旧不可） ※ 復旧できるのは「自動ブロックから20日以内」だけ。

まず 5 分でやる判断（緊急度の切り分け）

  1. ブロック発生日の推定：最後のサインイン日時や通知メールの受信日時から、現在がブロック後 20 日以内かを概算。
  2. 支払い継続可否の確認：社内決裁が不要であれば、復旧申請を即断。決裁が要る場合も、「復旧しないと課金を止められない」ことを明確化して緊急申請。
  3. 責任者と連絡先の確定：申請者（代表メール）と、テナント ドメイン/ID を手元で確認。

20 日を超過している可能性がある場合は、新テナントの並行準備と、後述の「再発防止設計」を先行させます。

復旧可否の確認方法（20 日以内かを判断する）

  • 社内のログやメールの痕跡：Azure からの通知メールの受信日、監査ログ、社内の運用記録。
  • 関係者の証言：最後に誰がいつログインしたか。自動化（アプリ/サービス プリンシパル）のサインイン有無。
  • 購買/経理の記録：最後に請求が発生した時期（課金サイクル終端の確認）。
<table>
  <thead>
    <tr>
      <th>判定</th>
      <th>対応</th>
      <th>ポイント</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>20 日以内</strong></td>
      <td>直ちに復旧申請（サポート経由で PG エスカレーション）</td>
      <td>必要情報を一度で出す。往復を減らすのが通し方のコツ。</td>
    </tr>
    <tr>
      <td><strong>超過の可能性あり</strong></td>
      <td>新テナントを準備。必要に応じてサブスクリプション移行/再構築を検討</td>
      <td>時間をかけても復旧見込みが薄い。再発防止設計を先行。</td>
    </tr>
  </tbody>
</table>

復旧申請の手順（サポート経由で Product Group に依頼）

ポータルへ入れないため、Microsoft サポート窓口または販売パートナー（CSP/リセラー）経由でチケットを作成し、PG（Product Group）エスカレーションを依頼します。

<h3>提出必須情報（抜けがあると差し戻されやすい）</h3>
<ul>
  <li>テナント ID（GUID）／ドメイン名（例：<code>contoso.onmicrosoft.com</code>）</li>
  <li>代表メールアドレス（折り返し連絡可能なもの、共有でも可）</li>
  <li>復旧が必要な理由（課金停止/監査/契約上の必要性/データ保持など）</li>
  <li>復旧できない場合の業務影響（具体的：費用、SLA、監査・法令順守、顧客影響）</li>
  <li>最後に想定されるサインイン日時（概算でも可）</li>
  <li>本人確認情報（組織名、契約種別、請求先情報の断片など）</li>
</ul>

<h3>依頼テンプレート（コピペして使えます）</h3>
<pre><code>件名：AADSTS5000225 によるテナント ブロック解除の依頼（PG エスカレーション希望）

内容： ・対象テナントID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ・ドメイン名：contoso.onmicrosoft.com ・代表連絡先：[[email protected]](mailto:[email protected])（担当：山田） ・事象：Azure ポータル サインイン時に「AADSTS5000225 — This tenant has been blocked due to inactivity」が表示され、ログイン不可。 ・背景：Databricks Premium へのアップグレード通知を受領。不要請求の回避と契約整理のため、至急ログインが必要。 ・最後のサインイン推定：2025-09-10（社内運用記録による概算） ・業務影響：課金停止/解約手続き/リソース削除ができず、不必要なコスト発生リスク。監査対応にも支障。 ・希望：PG へエスカレーションのうえ、ブロック解除を実施いただきたい。 ・本人確認のため必要な追加情報があればご連絡ください。 以上、よろしくお願いいたします。

<h3>申請時のコツ</h3>
<ul>
  <li>「<strong>20 日以内</strong>である根拠」を示すと判断が早い。</li>
  <li>連絡がつく電話/メールを必ず記載。<strong>平日/時間帯</strong>も明記すると折衝がスムーズ。</li>
  <li>社内決裁が必要な場合は、<strong>申請と並行</strong>で回す（待っている間に 20 日を越えないように）。</li>
</ul>

ブロック解除後の初動（課金系を最短で止める）

解除直後は、不要コストの発生源を潰すことが最優先です。以下の順で止めると効率的です。

<h3>1. 不要リソースの削除（リソース グループ単位）</h3>
<ol>
  <li>ポータル：<em>リソース グループ</em> で「タグ：<code>Keep=true</code>」以外を一括削除。</li>
  <li>影響範囲が見えない場合は「停止（停止可能な PaaS/IaaS）」→数日監視→削除の二段構え。</li>
</ol>

<details>
  <summary>CLI で一括棚卸し・削除（例）</summary>
  <pre><code># ログインとサブスクリプション選択

az login az account set –subscription # すべてのリソース グループ一覧（最終更新の新しい順） az group list –query “[].{name:name, location:location, tags:tags}” -o table # タグ Keep=true を除外して削除（確認ダイアログ無し・非同期） for rg in $(az group list –query “[?!(tags.Keep==’true’)].name” -o tsv); do az group delete -n “$rg” –yes –no-wait done # 残存個別リソースの確認 az resource list –query “[].{name:name, type:type, rg:resourceGroup}” -o table

※ 重要システムは必ずタグ等で保護しておき、誤削除を避けます。

<h3>2. サブスクリプションの解約（「無効化 → キャンセル」）</h3>
<p>課金の根を断つには、対象サブスクリプションを<strong>無効化</strong>し、その後<strong>キャンセル</strong>まで進めます。契約種別（従量課金/CSP/EA 等）により画面や手順が異なるため、<em>社内の契約情報</em>を確認してから進めてください。</p>
<ul>
  <li>無効化の影響：ワークロードは停止/削除され、復旧できなくなる場合があります。影響範囲に注意。</li>
  <li>返金や日割りは契約条件に依存。経理・購買と連携して進めましょう。</li>
</ul>

<h3>3. Databricks Premium の要否判断と後始末</h3>
<ol>
  <li>ワークスペースの棚卸し（本番・検証・個人検証を区別）</li>
  <li>不要ならワークスペースを削除（依存の Key Vault、VNet、ストレージも確認）</li>
  <li>必要なら SKU/プランの見直し（Premium が本当に要るか、コスト算定のやり直し）</li>
</ol>

<details>
  <summary>Databricks 関連の確認ポイント</summary>
  <ul>
    <li>クラスターの自動停止が有効か（アイドルコスト削減）</li>
    <li>ジョブがスケジュールされていないか（夜間の意図しない起動）</li>
    <li>Managed Resource Group 内の残骸（NIC、Disk、Public IP）が残っていないか</li>
  </ul>
</details>

課金防止の追加策（解除当日にやる）

予算とアラートの設定

  1. Cost Management + Billing > 予算 から新規予算を作成（上限必須）。
  2. 50% / 80% / 100% でメール通知。重要なチーム メール（finance@ や cloudops@）を登録。
  3. アクション グループを組み合わせ、Teams/電話/チケット自動発行まで繋げる。
<details>
  <summary>支払方法の見直し</summary>
  <ul>
    <li>不要カード/期限切れカードを外す。請求先住所/担当者も更新。</li>
    <li>二重契約（複数サブスク・複数 CSP）の有無を定期点検。</li>
  </ul>
</details>

再発防止の実装（「放置」を作らない）

最低限の運用ルール

  • 月 1 回のログイン：全グローバル管理者（または運用アカウント）に実施義務。自動化のサインインも補助として活用。
  • テスト用は短命の無料/開発テナントを使い、長期放置しない。
  • 所有者が変わるたびに管理者の棚卸しと代表メール更新を行う。
  • 課金と契約の年次レビュー（決算期に合わせて実施）。
<h3>技術的ガードレール</h3>
<ul>
  <li>タグ運用（<code>Owner</code>、<code>CostCenter</code>、<code>Keep</code>）。削除除外は <code>Keep=true</code>。</li>
  <li>Azure Policy で「指定タグ必須」「Public IP 制限」「未使用ディスク自動検出」などを強制。</li>
  <li>アラートの標準化（予算超過、従量課金の急増、Databricks の長時間ジョブ）。</li>
  <li>サービス プリンシパルの定期キー ローテーションと棚卸し。</li>
</ul>

<details>
  <summary>「ログインしたはずなのに」問題の落とし穴</summary>
  <p>自動化やバックグラウンドのトークン更新は、<em>意図した「アクティブ」判定にカウントされない</em>ことがあります。<strong>人間のインタラクティブ サインイン</strong>を月次で記録する運用を推奨します。</p>
</details>

ケース別：復旧できない/しない場合の現実解

20 日を超過している場合

  • 新テナント作成：命名規約、ドメイン取得、代表メール整備。
  • 再構築計画：IaC（Bicep/Terraform）で再展開。ソースがない場合は最小構成で作り直し。
  • 顧客/監査向け説明：発生/判断/対策/再発防止を 1 ページでまとめ、社外に出せる形に。
<h3>CSP/EA など契約が複雑な場合</h3>
<p>販売パートナー経由での請求・権限付与のため、<strong>パートナー側の手続き</strong>が必要なケースがあります。現テナントが動かない間に、<em>新テナント側での契約切替準備</em>を進めておくと移行が早いです。</p>

よくある質問（FAQ）

Q. AADSTS5000225 が出たら、必ず 20 日で削除されますか？ A. ブロック後 20 日の猶予を過ぎると物理削除が進み、復旧はできません。したがって、20 日以内の申請が勝負です。

  <dt>Q. 復旧申請は誰が出せますか？</dt>
  <dd>A. 契約/請求情報を確認できる組織の担当者が望ましいです。本人確認に必要な情報が揃っていれば、<strong>代表メール</strong>からの申請で進むことが多いです。</dd>

  <dt>Q. 復旧後に最優先でやることは？</dt>
  <dd>A. 不要リソースの削除、サブスクリプションの「無効化→キャンセル」、Databricks の棚卸し/削除、そして<strong>予算アラート</strong>の設定です。</dd>

  <dt>Q. 自動化のサインイン（アプリ）は「アクティブ」判定になりますか？</dt>
  <dd>A. 必ずしも期待通りにはカウントされません。<strong>人の月次サインイン</strong>を運用ルールとして残してください。</dd>

  <dt>Q. Databricks Premium のアップグレード通知が来たが、Premium は不要です。どうすべき？</dt>
  <dd>A. 復旧直後にワークスペースを棚卸しし、不要なら削除します。必要な場合も、SKU/プランとクラスターの自動停止を見直してコスト最適化します。</dd>

  <dt>Q. 支払いを止めるには解約しかありませんか？</dt>
  <dd>A. 一時的にワークロードを<strong>停止</strong>してコストを抑え、影響確認後に<strong>削除/解約</strong>へ進む二段階も有効です。契約条件により返金や日割りが異なります。</dd>
</dl>

実務に役立つスクリプト断片（棚卸し・見える化）

Azure Resource Graph でタイプ別の個数を把握

az graph query -q "Resources | summarize count() by type | order by count_ desc" -o table
<details>
  <summary>「止めていいもの」候補（タグ運用前提）</summary>
  <pre><code># Keep=true 以外で稼働中の VM を抽出

az vm list –show-details –query “[?powerState==’VM running’ && tags.Keep!=’true’].{name:name, rg:resourceGroup}” -o table # Public IP の残骸（課金源になりやすい） az network public-ip list –query “[?tags.Keep!=’true’].{name:name, rg:resourceGroup, sku:sku.name}” -o table

<details>
  <summary>PowerShell (Az) でリソース グループ削除</summary>
  <pre><code>Connect-AzAccount

Select-AzSubscription -SubscriptionId Get-AzResourceGroup | Where-Object { $*.Tags[‘Keep’] -ne ‘true’ } | ForEach-Object { Remove-AzResourceGroup -Name $*.ResourceGroupName -Force -AsJob }

関係者の巻き込み方（社内手続きの時短テク）

  • 経理/購買：請求の止め方（締め日/キャンセル規定）を即時確認。
  • セキュリティ：ブロック発生と対応の経緯を簡潔に記録。監査で聞かれる 4 点（発生/検知/対応/再発防止）を 1 枚に整理。
  • 現場：止めるリソースの確認。「止めても困らない」の明文化をもらう。
<table>
  <thead>
    <tr>
      <th>担当</th>
      <th>即日やること</th>
      <th>成果物</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>IT 運用</td>
      <td>復旧申請、棚卸し、削除/停止、予算アラート設定</td>
      <td>作業ログ、削除リスト、アラート設定のスクリーンショット</td>
    </tr>
    <tr>
      <td>経理/購買</td>
      <td>契約形態の確認、返金/日割りの可否、キャンセル手続き</td>
      <td>決裁メモ、ベンダー問い合わせ記録</td>
    </tr>
    <tr>
      <td>セキュリティ/監査</td>
      <td>事象の記録、アクセス権棚卸し、再発防止レビュー</td>
      <td>インシデント サマリ、是正計画、再発防止チェックリスト</td>
    </tr>
  </tbody>
</table>

チェックリスト（コピペ利用可）

緊急（Day 0）

  • ［ ］ ブロック発生日の概算（20 日以内か）
  • ［ ］ 復旧申請（PG エスカレーション希望を明記）
  • ［ ］ 代表メール・応答可能時間帯を記載
  • ［ ］ 経理/購買へ課金停止の緊急性を共有
<h3>解除直後（Day 0–1）</h3>
<ul>
  <li>［ ］ 不要リソース削除（RG 単位、タグで保護）</li>
  <li>［ ］ サブスクリプション無効化 → キャンセル</li>
  <li>［ ］ Databricks ワークスペースの棚卸し/削除</li>
  <li>［ ］ 予算とアラート設定、支払い方法見直し</li>
</ul>

<h3>安定化（Week 1）</h3>
<ul>
  <li>［ ］ タグ/Policy/アラートの標準化</li>
  <li>［ ］ ログイン月次運用の制度化（担当と予備）</li>
  <li>［ ］ 監査向けサマリ資料の作成</li>
</ul>

用語の整理（誤解しやすいポイント）

テナント（Microsoft Entra ID） アイデンティティの最上位コンテナー。サブスクリプションやアプリ登録の土台。ブロックされるとポータル操作全般が困難になる。

  <dt>サブスクリプション</dt>
  <dd>課金の単位。解約でコストを止めるが、契約条件に依存する。</dd>

  <dt>リソース グループ</dt>
  <dd>リソースの論理的な束。削除単位として使うと後始末が早い。</dd>

  <dt>Databricks Premium</dt>
  <dd>Databricks の上位プラン。監査やガバナンス機能が強化される一方、コスト増加要因になりやすい。不要なら削除/プラン見直し。</dd>
</dl>

まとめ（最短で被害を抑えるには）

  • 非アクティブ・ブロックは 20 日以内なら復旧可。期限を過ぎるとテナントは物理削除される。
  • 復旧には、テナント情報と業務影響を添えてMicrosoft サポートへ依頼（PG エスカレーション）。
  • 解除後は即座にサブスクリプション整理と課金対策（削除/無効化/キャンセル、予算アラート、支払方法見直し）。
  • 再発防止は月 1 回のログインとタグ/Policy/アラートの三点セットで運用に埋め込む。

ブロック発覚からの初動 24 時間が、その後のコストと手戻りを大きく左右します。この記事のテンプレートをそのまま使って、「申請→解除→後始末→再発防止」を一気通貫で進めてください。

付録：要点テーブル（この記事の骨子を 1 枚に）

ステップ要点詳細手順・補足
1. ブロックの仕組み把握課金サイクル終了後 200 日以上非アクティブで自動ブロック。
ブロックから 20 日で完全削除。		復旧は ブロック後 20 日以内が絶対条件。期限超過なら再作成のみ。
2. 復旧可否の確認「最後のサインイン日」や通知メール日付で経過日数を概算。20 日以内：復旧申請へ。超過：新テナントを作成し、必要ならサブスクリプションを移行/再構築。
3. 復旧申請Microsoft サポート/フォーラム経由で PG にエスカレーション。必須情報：テナント ID/ドメイン、代表メール、復旧理由、業務影響、最後のサインイン推定、本人確認情報。
4. ブロック解除後の対応ログイン可能になったら即座に課金系を整理。①不要リソース削除（RG 単位） ②サブスク解約（無効化 → キャンセル） ③Databricks Premium 要否判断と不要なら削除。
5. 課金防止の追加策予算/アラートで予防線を張る。50%/80%/100% 通知。アクション グループで Teams/電話/チケット連携。支払い方法の定期点検。
6. 再発防止テナントを放置しない。月 1 回ログイン。短命テナントの活用。タグ/Policy/アラートの三点セット。
Azure
Azure 復旧 Databricks 課金 Microsoft Entra ID テナント AADSTS5000225

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次