ある日突然、Azure サブスクリプションが「Microsoft Online Services の許容利用ポリシー（AUP）違反の疑い」で停止されると、多くの人は「何が悪かったのか」「いつ復旧できるのか」が分からず不安になります。本記事では、よくある停止理由から原因特定の進め方、停止中でもリソース削除ができるのかまで、実務で困らないレベルで詳しく解説します。
Azure サブスクリプション停止と AUP 違反疑いの全体像
Azure 上で疑わしい挙動が検知されると、Microsoft は Microsoft Product Terms（Online Services） に定義された Acceptable Use Policy（AUP：許容利用ポリシー） に基づいて、対象サブスクリプションを 一時的に停止（Disabled / Suspended） したり、重大な場合は 解除不可の状態（Terminated / Deleted） にすることがあります。
多くの場合、ポータルやメールには「AUP violation suspected」「Acceptable Use Policy に反する可能性」などのメッセージだけが表示され、具体的な違反内容までは書かれていません。そのため、
- よくある停止理由は何か
- 自分のケースの原因をどうやって特定するか
- 停止中でもリソースを削除できるか
を理解しておくことが非常に重要になります。
Azure の許容利用ポリシー（AUP）とは何か
Acceptable Use Policy（AUP） は、「Microsoft Online Services をどのように使ってはいけないか」を定めた規約で、Azure を含む多くのオンラインサービスに共通して適用されます。
Product Terms の「For Online Services」セクションには、次のような禁止事項が明記されています（意訳）：
- 法律・規制・行政命令に違反する利用
- 他者の権利侵害（知的財産、プライバシーなど）
- サービスやネットワークへ不正アクセスを試みる行為、またはサービスを妨害する行為
- スパムやマルウェアの配布
- 暗号資産（仮想通貨）のマイニング
- サービスや他の利用者に害を与える利用
- 上記を助長する行為全般
さらに、Azure OpenAI や各種 AI サービスについては、Microsoft Enterprise AI Services Code of Conduct によって、有害コンテンツ生成・差別・ハラスメント・偽情報拡散など AI 固有の禁止用途 が追加で定義されています。
これらに違反すると判断された場合、Microsoft は AUP に基づき、必要最小限の範囲でサービスを一時停止・制限・終了 する権利を持ちます。
よくある Azure サブスクリプション停止理由
実際に「AUP 違反疑い」で停止される典型パターンを、整理しやすいように表にまとめます。
| カテゴリ | 典型的な例 | Azure 上でのよくある状況 |
|---|---|---|
| 不正アクセス・侵入／サービス妨害 | ポートスキャン、ブルートフォース攻撃、DoS/ DDoS の踏み台など | セキュリティ侵害により VM が乗っ取られ、外部への攻撃トラフィックを大量送信している |
| スパム送信／マルウェア配布 | SMTP サーバからの大量スパム、ランサムウェアの配布サイトなど | 25/TCP などを使ったメール送信が急増し、スパムフィルタや Abuse レポートで検知される |
| 仮想通貨マイニング | GPU / 高性能 VM を使ったマイニング | 侵害された VM が勝手にマイニングを始め、高額な課金と異常な CPU/GPU 使用率が発生 |
| 違法／高リスク用途 | 違法コンテンツのホスティング、高リスク産業の制御など | 各種法令・規制、Microsoft のハイリスク利用ポリシーに抵触すると判断される構成 |
| 課金メカニズムの回避 | メーターの無効化、ライセンス条件を迂回するような利用 | サービス利用量と課金レポートが明らかに乖離し、不正な迂回が疑われる |
| AI サービスの不適切利用 | 差別・ヘイト、暴力・自殺助長、人格のなりすまし、政治的操作など | Azure OpenAI などで禁止カテゴリを継続的に生成・配信するアプリケーション |
停止理由は「悪意ある攻撃者」だけではない
現場でよくあるのが、運用側は善意で行っているつもりだが、Microsoft から見ると AUP 上はグレー／NG というケースです。例えば：
- 自社システムの脆弱性診断を Azure から実施したところ、外形的には「攻撃トラフィック」と見なされる
- 性能試験のために大量の HTTP リクエストやメール送信を行い、スパム／DoS に類似した挙動になってしまった
- AI チャットボットの「悪い例」を大量に生成してテストした結果、AI Code of Conduct 的には危険な利用パターンと判断された
このような「意図せざる AUP 違反」は、設計・運用段階での配慮と Microsoft との事前調整 によって、かなりの部分を回避できます。
自分のケースの原因を特定するための具体的な手順
AUP 由来の停止は、コミュニティやフォーラムでは解除できず、必ず Microsoft サポートとの対話が必要です。ここでは、すでにサポート リクエストを起票している前提で、原因特定を進めるためのステップを整理します。
サブスクリプション状態を正確に把握する
まずは Azure ポータルの「サブスクリプション」ブレードから、対象サブスクリプションの Status を確認します。Microsoft の公式ドキュメントでは、主に次の状態が定義されています。
| 状態 | 概要 | 許可される操作の例 |
|---|---|---|
| Active / Enabled | 通常の利用可能状態 | GET / PUT / PATCH / POST / DELETE すべて許可 |
| Warned | 警告状態。未対応だと Disabled へ移行 | GET / DELETE は許可、PUT / PATCH / POST は不可 |
| Disabled | 請求不備や AUP などで無効化された状態 | VM は停止・割り当て解除、ストレージは読み取り専用。GET / DELETE のみ許可 |
| Expired | キャンセルなどで有効期限切れ | GET / DELETE のみ許可（新規作成や変更は不可） |
| Deleted | サブスクリプションとリソースが完全削除 | 一切の操作不可 |
特に AUP 関連では、Disabled / Warned / Suspended いずれかになっていることが多く、この状態によって 「何ができて、何ができないか」 が変わります。
通知メールとポータル上のメッセージを集約する
次に、停止に関する情報を一か所に集めます。
- 受信したすべての通知メール（ヘッダー含む）
- Azure ポータル上のバナーやアラートのスクリーンショット
- 停止が発生した日時（UTC / ローカル両方）
メールには「何を根拠に AUP 違反と疑われたか」のヒント（Spam, Malware, Cryptocurrency mining など）が含まれることが多いので、英語部分も含めて丁寧に読み取ることが重要です。
ログから「疑われていそうな挙動」を洗い出す
サポートに丸投げする前に、手元である程度仮説を立てておくと対話がスムーズです。代表的なログと、確認したいポイントをまとめます。
| ログ／機能 | 見る場所 | 確認したいポイント |
|---|---|---|
| アクティビティ ログ | サブスクリプション / リソース グループ / リソース | 停止前後に大量作成された VM や NSG 変更など、不自然な操作がないか |
| サインイン ログ（Microsoft Entra） | Entra ID → サインインログ | 海外からの異常なログイン、深夜帯の急増、既知 IP 以外からの管理者ログイン |
| NSG フロー ログ / Firewall ログ | Network Watcher / Azure Firewall | 外部へのスキャン・攻撃トラフィック、25/TCP や 22/TCP への異常な通信 |
| アプリケーション ログ | App Service / Function / コンテナログ | 異常なスクリプト実行・マルウェアっぽいパターン・不審な URL へのアクセス |
| コスト分析・予算 | Cost Management + Billing | 直近で急激なコスト増加がないか（マイニング・攻撃の踏み台などの兆候） |
ここで「明らかに怪しい挙動」が見つかった場合は、その時刻・リソース・送信先 IP/URL をサポートに共有できるよう整理しておきましょう。
Azure ポータルからサポート リクエストを一本化して送る
原因の公式な開示や、解除／一時的な再有効化を依頼する窓口は Azure サポートのみです。Azure では、全ての顧客がサブスクリプション管理・請求に関するサポートを無償で利用できます。
サポート リクエストの作成手順は次のとおりです。
- Azure ポータル右上の 「?」→「ヘルプ + サポート」 を開く
- 「サポート リクエストの作成」 をクリック
- 問題の種類で 「サブスクリプション管理」や「アカウント & 請求」 を選択
- 該当サブスクリプション（停止されているもの）を選択
- 問題の詳細に、次のような情報を整理して記入
- Subscription ID
- 停止日時（UTC / ローカル）
- 通知メールの件名・本文（必要あればファイル添付）
- 直近で実行していたワークロードの概要
- ログから判明している不審な挙動（分かる範囲で）
- 「原因の明示」「誤検知の可能性」「再発防止策」を確認したい旨
- 可能であれば、クリーンアップやバックアップのための 一時的な再有効化（例：24時間）の可否
なお、サポート リクエストを作成するには、そのサブスクリプションに対して Owner / Contributor / Support Request Contributor などの RBAC 権限が必要です。
CSP（パートナー）経由契約の場合は販売パートナーも巻き込む
CSP 経由で Azure を利用している場合、サブスクリプションのライフサイクル管理や Microsoft へのエスカレーションは、基本的に販売パートナーの権限で行われます。
このため、
- Azure ポータルから自社でサポートチケットを起票
- 同時に販売パートナー（リセラー）にも状況を連絡し、Microsoft へのエスカレーションを依頼
という 二本立て で進めるのが現実的です。
電話が必要な場合は国別サポート番号を利用する
「ポータルにログインできない」「サポート リクエストの作成自体ができない」状況では、Microsoft の 国別サポート番号 や問い合わせページからの電話サポートを利用します。Azure の公式ページでも、「ポータルにアクセスできない場合は国別のカスタマーサービス番号に電話するように」と案内されています。
停止中サブスクリプションでリソース削除はできるのか
多くの人が気にするポイントが「停止中でも自分の手でリソースを削除できるのか？」という点です。Microsoft の公式ドキュメントでは、Disabled / Warned / Expired 状態のサブスクリプションでは、作成・更新（PUT / PATCH / POST）はできないが、取得と削除（GET / DELETE）は可能 と明記されています。
つまり、原則として次のように考えられます。
- 新規リソース作成・設定変更は不可
- 既存リソースの参照と削除は許可
- サブスクリプションの所有権移譲などは不可
ただし、「AUP 重大違反による恒久的な停止」など特殊ケースでは、削除すら制限される可能性もあります。その場合は、サポートに クリーンアップやデータ退避のための一時解放 を交渉するしかありません。
ストレージやロックなど、削除時の代表的な制約
サブスクリプションがキャンセル・無効化された後は、Azure のサービスは基本的に停止し、ストレージは読み取り専用になりますが、ストレージ アカウント自体の削除は可能です。
一方で、次のような場合は削除がブロックされます。
- ストレージ アカウント上に イミュータブル BLOB（WORM） や リーガルホールド が設定されている
- リソースやリソース グループに 削除ロック（CanNotDelete） がかかっている
- バックアップ ボルトやレプリケーションなどの依存リソース が残っている
- ポータル上で表示されない 隠しリソース（hidden types） が残っている
特に最後の「隠しリソース」は要注意で、サブスクリプションの削除画面で「まだアクティブなリソースがあります」と表示された場合は、次の手順で確認できます。
- Azure ポータル → サブスクリプション → 対象サブスクリプションを選択
- 左メニューの 「リソース」 を開く
- 画面上部の 「表示の管理」→「隠しタイプを表示」 を有効化
- 表示された隠しリソースを削除
実際のクリーンアップ手順の例
サブスクリプションが Disabled / Warned などの状態で、「今後はこのサブスクリプションを使わない。料金も発生させたくない」 という場合、次のようなステップでクリーンアップを行うのが現実的です。
ステップ 1：証跡とバックアップの確保
削除は不可逆操作なので、まずは以下を実施します。
- アクティビティ ログ、診断ログ、サインインログなどのエクスポート
- 構成情報（ARM テンプレート、Bicep、Terraform、スクリーンショットなど）の保存
- 残したいデータの 別サブスクリプションや他クラウド／オンプレミスへの退避
特に AUP 関連では、後から「本当に誤検知だったか」や「再発防止策の妥当性」を検証するために、証跡を残しておくことが重要です。
ステップ 2：リソース グループ単位で削除
Azure では、基本的に リソース グループ単位 での削除が推奨されています。
- リソース グループに設定されているロックを解除
- 依存関係の強いリソース（バックアップ、ボルト、IP など）を先に削除
- リソース グループ自体を削除
ステップ 3：Azure CLI で一括削除（自己責任）
サブスクリプション内のリソース グループを一括削除したい場合は、Azure CLI を使って次のようなスクリプトを実行できます（誤削除防止のため、必ず検証環境でテストし、自己責任で実行してください）。
SUB="<SubscriptionID>"
az group list --subscription "$SUB" --query "[].name" -o tsv | \
xargs -I{} az group delete --subscription "$SUB" -n "{}" --yes --no-wait
このコマンドは、指定したサブスクリプション内の全てのリソース グループを取得し、それぞれに対して削除コマンドを投げます。一度実行すると ほぼ元に戻せない ため、実行前にサブスクリプション ID と削除対象が本当に正しいかを必ず確認してください。
ステップ 4：サブスクリプションのキャンセルと最終削除
不要リソースを削除した後は、サブスクリプション自体をキャンセル → 削除 という流れになります。
- キャンセル後はすぐに課金が止まる（最終請求の締めは数日後）
- データは通常 30～90 日間保持 された後、自動的に削除される
- キャンセルから数日（多くの場合 3 日）経過すると「サブスクリプションの削除」ボタンが有効になる
- 条件を満たしていれば、ポータル上からサブスクリプションを完全削除可能
- 90 日経過後は自動的にサブスクリプションも削除される
ここまでの操作が困難な場合、または AUP 由来の停止で UI 上の操作が制限されている場合は、サポートに「サブスクリプションのキャンセルと削除」を依頼します。
再発防止のための設計・運用チェックリスト
AUP 違反疑いでの停止は、一度起きるとビジネスへのインパクトが非常に大きくなります。ここでは、再発防止のために最低限チェックしておきたいポイントを整理します。
アイデンティティ・アクセス管理
- 多要素認証（MFA） を全管理者アカウントに必須化しているか
- パブリックな IP からの管理アクセスを 条件付きアクセス や Just-In-Time (JIT) VM アクセス で制限しているか
- 「グローバル管理者」などの特権ロールを 最小人数・最小期間 に抑えているか
ネットワークと通信制御
- インターネット向けの 送信トラフィック（egress）を NSG / Firewall で制限 しているか
- SMTP など スパムに悪用されやすいポート を安易に開放していないか
- 脆弱性診断・負荷試験を実施する際、対象・期間・トラフィック量を事前に明確化 しているか
監視・アラート・コスト管理
- Defender for Cloud や Microsoft Entra のセキュリティアラートを有効化し、アラートに対する対応フロー を決めているか
- Cost Management で 予算・アラート を設定し、急激なコスト増を即検知できるようにしているか
- Azure Monitor / Log Analytics を用いて、不審なログインや異常トラフィックを可視化 しているか
AI サービス利用時のポリシー整備
- Microsoft Enterprise AI Services Code of Conduct を読み、社内の AI 利用ポリシーに落とし込んでいるか
- チャットボットや生成 AI を使ったサービスで、禁止コンテンツ（差別・暴力・自殺助長・なりすまし等） が出力・配信されないよう制御しているか
- 利用規約や UI 上で、AI 生成であることの明示 や ユーザーからのフィードバック手段 を用意しているか
ガバナンスと Azure Policy の活用
- Azure Policy で「特定リージョンのみ許可」「高リスクな VM SKU を禁止」「パブリック IP の制限」などの ガードレール を設定しているか
- Azure Blueprints や IaC（Bicep/Terraform 等）で 安全な標準構成をテンプレート化 しているか
- 定期的な セキュリティ レビュー／アーキテクチャ レビュー を行い、AUP に抵触しそうな部分を洗い出しているか
まとめ：AUP 由来の停止は「サポートとの対話」と「計画的クリーンアップ」が鍵
最後に、本記事のポイントを改めて整理します。
- Azure サブスクリプションの AUP 由来停止では、具体的な違反内容がポータル上には出ない ことが多い
- よくある停止理由は、不正アクセス・攻撃トラフィック、スパム／マルウェア、仮想通貨マイニング、違法／高リスク用途、AI サービスの不適切利用 など
- 原因特定の第一歩は、サブスクリプション状態（Disabled / Warned など）とログの整理、および Azure サポートへの詳細な情報提供
- Disabled / Warned / Expired 状態では、作成・更新はできないが、GET / DELETE による削除は原則可能
- ストレージの読み取り専用化、イミュータブル BLOB、削除ロック、隠しリソースなど、削除を妨げる要素 を理解して対処することが重要
- サブスクリプションを使い続けない場合は、証跡を確保 → リソース削除 → サブスクリプションのキャンセル・削除 まで計画的に実施する
- 再発防止には、アイデンティティ管理、ネットワーク制御、監視・アラート、AI 利用ポリシー、Azure Policy によるガバナンス を組み合わせた総合的な対策が必要
AUP 違反疑いによる停止は、事業継続に大きな影響を与えますが、早期に原因を把握して是正策を提示することで、Microsoft との対話もスムーズになり、再発リスクも下げられます。この記事を参考に、自社の Azure 利用状況と運用プロセスを見直し、「止められない Azure 環境」を目指していきましょう。
参考リンク（公式ドキュメント）
- Microsoft Product Terms – For Online Services（Acceptable Use Policy）
- Microsoft Enterprise AI Services Code of Conduct
- Azure subscription states
- Create an Azure support request
- Azure Support Options
- Cancel and delete your Azure subscription
- Delete resource groups and resources
- Subscription Lifecycle States – Partner Center（CSP）
コメント