Microsoft Defender for Cloud を無料試用で有効化したまま放置すると、試用終了後に有料プランへ切り替わり、気づかないうちに Azure 請求が発生することがあります。さらに、オフにしたはずなのに日次で少額課金が続くケースも。本記事では原因の切り分けから、課金元の特定、完全停止までを手順付きで解説します。
起きている現象を整理：よくある相談パターン
まず前提として、Microsoft Defender for Cloud（旧称 Azure Security Center / Azure Defender）は「一括でオン・オフする単一機能」ではなく、ワークロード別に用意された複数の“Defender プラン（料金プラン）”の集合です。無料試用を開始したつもりでも、試用が終わったあとに有料（Standard）へ移行し、サブスクリプション全体または特定リソース単位で課金が積み上がることがあります。
今回のように、次の流れでトラブルに気づくケースは珍しくありません。
- Azure サブスクリプションで Defender for Cloud の無料試用版を有効化した
- 試用終了後にオフにし忘れ、10日ほど経ってからDefender 関連の料金が Azure 請求に出ていることに気づいた
- サブスクリプション レベルと、いくつかの App Service で Defender をオフにした
- それでも翌月に入っても毎日少しずつ課金が継続している
この状態で知りたいポイントは、ほぼ次の3つに集約されます。
- Defender を無効化したのに、なぜ課金が続くのか
- 料金の発生元が Azure のどこなのか（どの設定・どのリソースか）
- 完全に課金を止めるにはどうすればよいか
結論：課金が続くときの「原因」は大きく4パターン
先に全体像を押さえると、切り分けは一気に楽になります。課金が続く場合、ほとんどは次のどれかです。
| パターン | 何が起きているか | 見分けるポイント | 打ち手 |
|---|---|---|---|
| プランが残っている | どこかの Defender プランが Standard のまま | Resource Graph で microsoft.security/pricings の Standard が残る | Environment settings で全プラン Off、必要なら個別に再保存 |
| 管理グループ等で再適用 | 上位（管理グループ、ポリシー、Lighthouse 等）から再度オンにされる | オフにしたのに翌日またオン、アクティビティログに再更新が出る | 上位スコープの設定・ポリシーを点検 |
| 請求反映のタイムラグ | 停止操作後も、日割り計上・集計遅延でしばらく表示される | 停止日直後の1～数日だけ少額、以降は減る | 停止日時を記録し、数日分の推移を確認 |
| バックエンド起因の不具合 | 設定上は全部オフなのに、課金だけが継続 | Standard が0なのに請求が毎日出る | 課金サポートで内部調査（返金相談含む） |
この記事では、上から順に「潰し込み」できるように、確認の順番を固定して解説します。ポイントは請求（課金メーター）→ 設定（Environment settings）→ 機械的な棚卸し（Resource Graph）→ サポートの順に進めることです。
なぜ「オフにしたのに課金が続く」のか：Defender for Cloud の課金構造
Defender は“サービス”ではなく“料金プランの束”
Defender for Cloud は、サーバー、App Service、Storage、SQL、Key Vault、コンテナなど、ワークロードごとにプランが分かれています。Azure の内部的には、サブスクリプション配下に Microsoft.Security/pricings というリソースとしてプラン状態（Free/Standard など）が保存されます。
ここが重要で、ポータルのどこかで「オフ」に見えていても、別画面のプラン状態が Standard のまま残っていると課金は止まりません。逆に言えば、課金を止めたいなら“Defender プラン（料金プラン）”をすべて Free/Off に落とす必要があります。
無料で残せる項目と、有料に直結する項目が混在する
Defender for Cloud には、無料で提供される基本的なセキュリティ評価（いわゆる基本的な CSPM 機能）と、ワークロード保護（Defender プラン：Standard）として課金される機能が混在します。UI 上でも「Foundational CSPM」などの名称で表示されることがありますが、無償範囲や名称は更新されることがあるため、“オンにしている項目が請求に載っていないか”を必ず請求画面で確認してください。
「オフにしたのに翌月も少額が出る」理由は2種類ある
- 停止操作の反映遅延：停止した当日～翌日にかけて、日割り計上や集計遅延で少額が見えることがあります。
- 停止しきれていない／再適用／不具合：数日経っても同じペースで課金が続く場合は、この可能性が高いです。
最優先：Azure 請求から「課金の発生元」を特定する
「どこが原因か分からない」状態で設定画面を触り続けると、時間だけが溶けます。先に請求で“犯人”を絞るのが最短です。Defender の課金は、サービス名やメーター名、リソースIDが手掛かりになります。
Cost Management のおすすめ確認手順
- Azure ポータルで「Cost Management + Billing」を開く
- 「Cost analysis」へ進み、対象のサブスクリプション／期間（課金が続いている日付範囲）を選ぶ
- フィルターで「Service name」に Microsoft Defender for Cloud（または Security Center / Azure Defender 相当の名称）を指定する
- グループ化（Group by）をMeter、次にResource、さらに必要ならResource groupやResourceIdで切り替えて、どの単位で課金されているかを見る
- 同じ日に複数の明細がある場合は、“毎日出続ける行”のメーター名を控える
ここでメーター名が分かると、次のどのプランが残っているかを推測しやすくなります。例えば「Defender for Servers」「Defender for App Service」「Defender for Storage」など、プラン名が連想できる表記になっていることが多いです。
| 請求画面で見る場所 | 分かること | ここがポイント |
|---|---|---|
| Service name | どのサービス枠で請求されているか | 名称が変わることがあるため、Defender/ Security Center/ Azure Defender などで検索 |
| Meter / Meter category | どのプラン・どの計上単位かのヒント | “毎日”同じメーターが出続けるなら、そのプランの停止確認を優先 |
| Resource / ResourceId | 課金対象になっている具体的なリソース | リソースIDが出る場合、App Service なのか Storage なのかが一発で判別できる |
| Invoice details（請求書詳細/明細） | 最終的に請求に載る行の一覧 | Cost analysis で見えない属性が出ることがあるため、必要ならエクスポートして突合 |
請求の発生元が「特定の App Service」だと分かったなら、そのワークロードのプランを重点的に確認します。逆に、リソースが出ずサブスクリプション単位のメーターで出ているなら、Environment settings 側に原因が残っている可能性が高いです。
手順1：Environment settings で Defender プランが“全部”オフか再確認
最も多い原因は、Defender プランが一部だけ Standard のまま残っていることです。UI 上のオン・オフ表示は画面によって意味が違うことがあるため、Environment settings（環境の設定）で料金プランを直に確認します。
- Azure ポータルを開き「Microsoft Defender for Cloud」へ移動
- 左メニューから「Environment settings（環境の設定）」を開く
- 対象サブスクリプションの行を見つけ、右端の「…」メニューから「Edit settings（設定の編集）」を選択
- 「Defender plans（Defender プラン）」画面で、ワークロードごとのプランを確認
- Servers / App Service / Storage / SQL / Key Vault / Containers など、課金に直結するプランをOff（Free 相当）へ設定
- 必要に応じて、無償枠として提供される項目（例：Foundational CSPM 相当）だけをオンにする
- 最後に必ずSave（保存）を押して反映させる
注意：「サブスクリプション側でオフにした」「特定リソースのブレードでオフにした」だけでは不十分なことがあります。課金を止めたいなら、“Defender プラン（料金プラン）”自体を Off/Free にするのが原則です。
見落としやすいチェックポイント
- 複数サブスクリプション：同じテナントに複数サブスクリプションがある場合、別のサブスクリプションで有料プランが残っていても「毎日少しずつ」課金が続くように見えます。
- 管理グループ配下：管理グループで一括設定していると、サブスクリプション側の変更が意図せず上書きされることがあります。
- 対象ワークロードの取りこぼし：App Service だけオフにしても、Storage や SQL、Servers など別プランが残っていれば課金は続きます。
- 保存漏れ：画面遷移で保存せず戻ると、見た目だけ変わって反映されていないことがあります。
手順2：Azure Resource Graph で Standard が残っていないか棚卸しする
UI は便利ですが、トラブル時ほど「見落とし」「表示の差」「保存漏れ」が起こります。そこで、サブスクリプション内の Microsoft.Security/pricings を機械的に棚卸しし、Standard（有料）になっているプランが残っていないかを確認します。
Azure CLI での確認例（Standard のみ抽出）
Azure CLI が使える環境なら、次のようにクエリできます（実行前に対象サブスクリプションへ切り替えてください）。
# 対象サブスクリプションに切り替え
az account set --subscription <SUBSCRIPTION_ID>
# Defender の課金対象（Standard）が残っていないか確認
az graph query -q "
SecurityResources
| where type == 'microsoft.security/pricings'
| where properties.pricingTier == 'Standard'
| project name, pricingTier=tostring(properties.pricingTier), subId=subscriptionId
| order by name asc
"
結果が1行でも返ってくれば、そのプランはまだ有料です。まずはその name（例：AppServices, StorageAccounts, SqlServers など）を手掛かりに、Environment settings の該当プランを重点的に見直します。
質問でよく使われる「件数で見る」クエリ例
Standard が残っているかを“件数”で確認したい場合は、次のような集計クエリも有効です。
az graph query -q "
SecurityResources
| where type == 'microsoft.security/pricings'
and properties.pricingTier == 'Standard'
| summarize ResourceCount = count() by name, pricingTier=tostring(properties.pricingTier)
| order by ResourceCount desc
"
ここで ResourceCount が 0（結果が返らない）なら、少なくとも「Standard のプラン設定が残っている」線は薄くなります。
全プランの状態を一覧するクエリ
Standard だけでなく、全プランの状態を見たい場合は次のように一覧化すると便利です。
az graph query -q "
SecurityResources
| where type == 'microsoft.security/pricings'
| project name, pricingTier=tostring(properties.pricingTier), subId=subscriptionId
| order by name asc
"
ここで、意図せず Standard になっているプランがあれば、そこが課金の直接原因です。反対に、すべて Free/Off 相当なのに請求が続く場合は、次の手順へ進みます。
手順3：反映遅延か、再適用かを「時系列」で見分ける
「オフにしたのに課金が出る」という相談の中には、実際は“停止操作の直後に計上された分が後から見えているだけ”というケースもあります。ここを切り分けるには、停止日時と請求発生日を並べて見るのが有効です。
| 状況 | 請求の出方 | 可能性が高い原因 | 次にやること |
|---|---|---|---|
| 停止当日～翌日に少額が出たが、その後は減っていく | 日次の明細が数日で消える/減る | 反映遅延・日割り計上 | 停止日時を記録し、数日分の推移を追う |
| 停止後も同じペースで毎日出続ける | 明細が途切れない | プランが残っている/再適用/不具合 | Environment settings と Resource Graph を再確認、アクティビティログを見る |
| ある日を境に突然また課金が再開する | 一度止まって再開 | ポリシーや上位設定で再適用 | 管理グループ/ポリシー/自動プロビジョニングの確認 |
アクティビティログで「誰が・いつ」設定を変えたか確認する
再適用が疑わしい場合、Azure ポータルの「Activity log（アクティビティログ）」で、Defender プランに関係する更新が行われていないかを確認します。確認のコツは次の通りです。
- 対象サブスクリプションのアクティビティログを開く
- 期間を「課金が再開した前後」に絞る
- リソースプロバイダーで Microsoft.Security を含むイベントを探す
- 「Update」系の操作（設定変更）や、設定を変更した主体（ユーザー/サービスプリンシパル）を確認する
ここで“自分が触っていない更新”が出るなら、Azure Policy や自動化（ARM/Bicep、Terraform、CI/CD、Lighthouse など）で再度オンにされている可能性があります。課金を止めるには、その自動化の入口を止める必要があります。
手順4：それでも止まらない場合は「課金サポート」へ（最短で解決する）
Environment settings で全プラン Off、Resource Graph でも Standard が0、それでも日次で課金が続く場合は、課金システム側で状態が不整合になっている可能性があります。このパターンは、利用者側の操作で完全に止めきれないことがあるため、Azure の課金サポートで内部調査してもらうのが現実的です。
課金（Billing）カテゴリのサポートは、一般に追加料金なしで起票できます。返金可否の相談も同じ窓口で進められるため、時間をかけて設定を触り続けるより結果的に早いことが多いです。
サポートリクエスト作成の流れ
- Azure ポータルで「Help + support（ヘルプとサポート）」を開く
- 「Create a support request（サポート リクエストの作成）」を選択
- 問い合わせ種別でBilling（請求）を選び、対象サブスクリプションを指定
- 「Defender for Cloud を無効化したのに日次課金が続く」旨を具体的な日付と共に記載
- 途中で表示されるナレッジ/自動提案は参考にしつつ、最終的にケースを作成して送信
伝えるべき情報（コピペ用テンプレ）
現象： Microsoft Defender for Cloud の無料試用終了後に課金が発生し、サブスクリプションおよび対象リソースで Defender プランを Off にしたが、その後も毎日少額の課金が継続している。
対象： サブスクリプション ID：<SUBSCRIPTION_ID>
停止操作： <YYYY-MM-DD> <HH:MM>（JST など）に Environment settings で Defender プランをすべて Off に設定し保存。
確認結果： Resource Graph で
microsoft.security/pricingsのproperties.pricingTier == 'Standard'が 0 件であることを確認。請求： <YYYY-MM-DD> 以降もメーター名「<METER_NAME>」で日次課金が続く（スクリーンショット/エクスポート添付）。
依頼： 内部課金状態の調査、停止の実施、停止日以降の不要請求の返金可否の確認。
返金・調査をスムーズにする「証跡」チェックリスト
| 用意するもの | 具体例 | 目的 |
|---|---|---|
| 無効化した日時の証拠 | アクティビティログの該当イベント（CSV/スクショ） | 「この日時以降の課金は不要」の根拠になる |
| 請求明細の証拠 | Cost analysis のスクショ、請求明細のエクスポート | どのメーターで、いつから続いているかを明確化 |
| 再現条件のメモ | 無料試用開始日、停止操作日、影響を受けたワークロード | サポート側が内部ログを追うための手掛かり |
| 関係者情報 | 操作したユーザー/自動化の有無、管理グループ利用の有無 | 再適用やポリシーの線を潰す |
再発防止：無料試用の“うっかり課金”をゼロに近づける運用
Defender for Cloud は「セキュリティ強化と引き換えに、リソース数に比例して課金が増える」タイプのサービスです。無料試用は便利ですが、運用ルールがないと“気づいたら毎日課金”になりがちです。再発防止として、次の3つをセットで導入するのがおすすめです。
Cost 管理（Budgets / アラート）で早期発見する
- サブスクリプションに予算（Budget）を設定し、しきい値到達でメール通知
- 「サービス名：Defender for Cloud」でフィルターしたビューを保存し、週次で確認
- 試用を開始する場合は「停止予定日」をカレンダーに登録する（例：30日後）
設定の棚卸しを定期化する（Resource Graph の定期実行）
本記事で紹介した Resource Graph クエリは、そのまま棚卸しにも使えます。定期的に実行し、意図しない Standard の混入を早期に検知できるようにします。複数サブスクリプションを運用している組織ほど効果が大きいです。
「誰がオンにできるか」を絞る
無料試用の開始はワンクリックでできる反面、課金インパクトは小さくありません。運用ルールとして、少なくとも次を決めておくと事故が減ります。
- Defender プランの変更を行える権限（ロール）を限定する
- 変更を行ったらチケット/台帳に「開始日・停止日・目的」を記録する
- 自動化（Terraform など）で管理している場合は、意図しない再適用が起きないようコード側も点検する
よくある質問
オフにしたのに、停止日翌日分まで課金が出ます。失敗していますか？
停止操作の直後は、日割り計上や請求集計のタイムラグで、翌日分まで表示されることがあります。数日経っても同じペースで増え続ける場合は、プランが残っている・再適用されている可能性が高いので、Environment settings と Resource Graph を再確認してください。
App Service だけオフにしました。まだ課金が出るのはなぜ？
Defender for Cloud はワークロード別プランです。App Service をオフにしても、Storage や SQL、Servers など別のプランが Standard のままなら課金は続きます。請求のメーター名を手掛かりに、該当プランを特定して停止してください。
Resource Graph で Standard が0件です。それでも請求が続きます。
この場合、再適用（管理グループ/ポリシー/自動化）か、請求反映遅延、もしくはバックエンド側の不整合が疑われます。アクティビティログで設定更新が入っていないかを確認し、問題が見えない場合は課金サポートへ起票して内部調査を依頼するのが確実です。
Foundational CSPM だけオンにしても大丈夫？
一般に「基本的な CSPM 機能」は無償枠として扱われることがありますが、無償範囲や名称はアップデートされ得ます。オンにしてよいか迷う場合は、まず全プラン Off にしたうえで請求が止まることを確認し、その後に必要な項目だけ段階的にオンにして、請求メーターが増えないことを確認するのが安全です。
課金サポートには何を準備すればいい？
停止操作の日時（アクティビティログ）、請求明細（メーター名、発生日、金額の推移）、サブスクリプション ID の3点があるとスムーズです。特に「停止日以降も継続している」ことを示せる証跡は返金相談でも重要になります。
最終チェック：課金を止め切るためのチェックリスト
| チェック項目 | 確認方法 | OK の状態 |
|---|---|---|
| 請求メーターの特定 | Cost analysis で Service name と Meter を確認 | どのプラン由来か見当がつく |
| Environment settings で全プラン Off | Defender for Cloud → Environment settings → Edit settings | 課金対象プランが Off（Free）になっている |
| Resource Graph で Standard が0 | microsoft.security/pricings をクエリ | pricingTier == 'Standard' が 0 件 |
| アクティビティログで再適用なし | Microsoft.Security の更新イベントを確認 | 意図しない更新が発生していない |
| それでも日次課金が続く | 停止日以降も毎日増えるか | 続く場合は課金サポートへ起票 |
Defender for Cloud の課金は「設定の残り」と「見え方の差」で迷いやすい領域です。請求で発生元を押さえ、Environment settings と Resource Graph で機械的に潰し込み、それでも止まらなければ課金サポートで内部調査──この順番で進めれば、遠回りせずに解決へ近づけます。
コメント