Microsoft Defender環境でMicrosoft Sentinelを使っている場合、2026年5月14日更新の公式情報「Manage and monitor costs for Microsoft Sentinel」で最初に確認すべき点は、コスト管理の見方が“Azure Cost Management中心”から、“Analytics tierはAzure、Data lake tierはMicrosoft Defenderポータル”という二段構えで整理されていることです。料金単価の改定を告知する内容ではなく、Microsoft Sentinelの利用量、請求、予算アラート、Data lake tierのしきい値管理をどこで確認するかを明確にした実務向けの更新と捉えるとよいでしょう。Microsoft Learnの該当ページはMicrosoft Sentinel in the Microsoft Defender portalとAzure portalの両方を対象にしており、ページの最終更新日は2026年5月14日です。(Microsoft Learn)
特に重要なのは、Microsoft SentinelのAzureポータル提供が2027年3月31日以降サポートされず、Microsoft Defenderポータルでの利用に移行する前提が明記されている点です。コスト監視だけでなく、権限、データコネクタ、分析ルール、Playbook、API連携まで影響を受けるため、管理者は「請求額を眺める」だけでなく、監視方法そのものをDefenderポータル前提に見直す必要があります。(Microsoft Learn)
今回の要点：Sentinelのコスト監視は2つの経路で考える
Microsoft Sentinelのコストは、Azure請求全体の一部として発生します。公式ドキュメントでも、Sentinelのコストだけでなく、同じAzureサブスクリプションで利用する他のAzureサービスやパートナーサービスも請求対象になると説明されています。つまり、Sentinelの費用を正しく見るには、Sentinel単体ではなく、Log Analytics、Azure Monitor、Logic Apps、Notebook、Data lake関連の利用量まで含めて確認する必要があります。(Microsoft Learn)
| 確認対象 | 主な管理画面 | 見るべき内容 | 主な担当者 |
|---|---|---|---|
| Analytics tier | AzureポータルのCost Management + Billing | データ取り込み量、日別コスト、予測コスト、予算超過 | Azure管理者、SOC管理者、FinOps担当 |
| Data lake tier | Microsoft DefenderポータルのMicrosoft Sentinel > Cost management | Data lakeのメーター別利用量、リソース別内訳、しきい値 | SOC管理者、セキュリティ管理者、請求管理者 |
| 予算・アラート | Azure Cost Management | サブスクリプションまたはリソースグループ単位の予算、通知 | Azure管理者、経理・FinOps担当 |
| データ取り込み分析 | KQL、Workspace Usage Report | 課金対象データの種類、ソリューション別・テーブル別の増減 | セキュリティエンジニア、運用担当 |
| 移行・展開 | Microsoft Defenderポータル、Microsoft Sentinel設定 | 権限、コネクタ、Playbook、API、分析ルール | 管理者、開発者、MSSP |
この更新で実務上のポイントになるのは、「どの画面で何を見るか」を切り分けることです。Analytics tierの課金状況は引き続きAzure Cost Managementで確認します。一方、Sentinel data lakeを有効化している場合は、Microsoft Defenderポータル側のCost managementでData lake tierの利用量やしきい値を確認します。(Microsoft Learn)
対象者と影響範囲
この情報の対象は、Microsoft Defender製品全体のライセンス管理者というより、Microsoft Defenderポータル上でMicrosoft Sentinelを利用・移行・運用する管理者です。Microsoft Defender for EndpointやDefender XDRだけを利用していて、Sentinelワークスペースを有効化していない環境では、直接の影響は限定的です。
一方で、次のような環境では確認が必要です。
| 対象環境 | 影響する理由 |
|---|---|
| Microsoft SentinelをLog Analyticsワークスペースで運用している | データ取り込み量とLog Analytics関連コストが請求に影響する |
| Sentinel data lakeを有効化している | Data lakeの取り込み、保存、クエリ、Notebook実行などが別メーターで管理される |
| AzureポータルでSentinel運用を続けている | 2027年3月31日以降はDefenderポータル利用が前提になる |
| Logic AppsのPlaybookや外部チケット連携を使っている | Defenderポータル移行後にインシデント項目やトリガー条件が変わる可能性がある |
| KQL、Notebook、Graph API、Microsoft Graph APIを使う開発チームがいる | Data lake queryやAdvanced data insightsの利用量、APIレスポンス差分を確認する必要がある |
注意したいのは、Microsoft Sentinelでは一部のセキュリティアラートが無料データソースとして扱われる一方、Microsoft Defender XDRやDefender for Endpointなどの一部の生ログは有料になる場合がある点です。アラートが無料でも、分析のために取り込む生データが課金対象になることがあります。(Microsoft Learn)
Analytics tierのコスト管理：まずAzure Cost Managementで日別に見る
Analytics tierのコスト監視では、AzureポータルのCost Management + Billingを開き、Cost Managementから対象スコープを選択します。スコープは、サブスクリプション、リソースグループ、必要に応じて管理グループなどで切り分けます。公式ドキュメントでは、Microsoft Sentinelで課金対象データの取り込みが始まるとコストが発生し、Cost Analysisで日別、月別、年別、予算、予測コストを確認できると説明されています。(Microsoft Learn)
実務では、最初に次のフィルターを設定します。
| 設定項目 | 推奨設定 | 理由 |
|---|---|---|
| View | Daily costsまたはAccumulated costs | 日々の急増と月次累積の両方を確認できる |
| Granularity | Daily | コネクタ追加やルール変更後の増加を検知しやすい |
| Service name | Sentinel、Log Analytics、Azure Monitor | Sentinel単体では見落とすLog Analytics関連コストを拾える |
| Date range | 直近31日、前月、四半期 | 通常運用と変更後の差分を比較しやすい |
特にクラシック価格レベルを利用しているワークスペースでは、Microsoft SentinelとLog Analyticsの請求が別々に表示される場合があります。簡素化された価格レベルでは両方のコストが1つの価格体系にまとめられますが、クラシック価格レベルではSentinel、Log Analytics、Azure Monitorを分けて見る必要があります。(Microsoft Learn)
KQLで課金対象のデータ取り込み量を確認する
Cost Analysisだけでは、「どのテーブルが増えたのか」「どのソリューションが原因なのか」までは分かりにくいことがあります。そこで、Log AnalyticsのUsageテーブルを使い、課金対象のデータ取り込み量をKQLで確認します。公式ドキュメントでも、ソリューション別、データ型別、またはその両方で取り込み量を確認するKQL例が示されています。(Microsoft Learn)
データ型別に直近31日分の課金対象データを確認する場合は、次のようなクエリを使います。
Usage
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType
| render columnchartこのクエリで確認したいのは、単に合計GB数ではありません。実務では次の順で見ると原因を特定しやすくなります。
| 見るポイント | 判断の目安 |
|---|---|
| 急に増えたDataTypeがあるか | 新しいデータコネクタ、ログ転送設定、DCR変更の影響を疑う |
| 平日と休日で差があるか | 業務系ログ、バッチ、スキャン、監査ログの周期性を確認する |
| 直近の構成変更と一致するか | コネクタ追加、EDR設定変更、診断ログ有効化のタイミングを見る |
| IsBillableがtrueのデータが多いか | 無料アラートではなく、有料の生ログを取り込みすぎていないか確認する |
原因が分かったら、すぐに削除や停止をするのではなく、検知・監査・コンプライアンス上の必要性を確認します。セキュリティログは「高いから切る」ではなく、「Analytics tierに置くべきか、Lake tierに逃がせるか、保持期間を変えられるか」で判断するのが安全です。
Workspace Usage Reportでテーブル別の消費を可視化する
KQLに慣れていない管理者や、定例会議で共有しやすい画面が必要な場合は、Microsoft SentinelのWorkspace Usage Reportワークブックを使うと便利です。このワークブックは、ワークスペースのデータ消費、コスト、利用状況、無料データと課金対象データ、テーブル別の取り込み量を確認するために使えます。(Microsoft Learn)
導入手順はシンプルです。Microsoft SentinelのWorkbooksで「workspace usage」を検索し、Workspace Usage Reportを開きます。テンプレートのまま表示することも、保存して編集可能なコピーを作ることもできます。実務では、保存したコピーに「直近31日」「前月比較」「上位10テーブル」などのビューを作っておくと、月次レビューで使いやすくなります。(Microsoft Learn)
Data lake tierのコスト管理：Defenderポータルでメーター別に確認する
Sentinel data lakeを有効化している場合、Data lake tierの利用は新しいMicrosoft Sentinel data lakeメーターで請求されます。公式情報では、Data lake tierのコストはデータ取り込み、データ処理、データ保存、KQLクエリでスキャンした非圧縮データ量、Advanced data insightsのコンピュート時間などに基づくと説明されています。(Microsoft Learn)
Data lake tierのコスト管理では、Microsoft DefenderポータルのMicrosoft Sentinel > Cost managementを確認します。この新しいコスト管理エクスペリエンスはプレビューとして提供されており、Data lake tierに関連する利用量をメーター別に可視化できます。アクセスにはBilling AdministratorとSecurity Administratorの両方のロールが必要です。(Microsoft Learn)
| メーター・機能 | 確認すべき内容 | 使いすぎの典型例 |
|---|---|---|
| Data lake storage | 保存量、保持期間、対象テーブル | 長期保持が必要ないログまでLakeに残している |
| Data lake query | KQLクエリやジョブでスキャンした量 | 広すぎる期間・全列検索・定期ジョブの乱発 |
| Advanced data insights | NotebookセッションやNotebookジョブの実行時間 | 検証用Notebookを長時間起動したままにする |
| Resource contributors | 利用量に寄与しているリソース | 特定ワークスペースやジョブだけが急増している |
Usage summaryでは、メーターを選択して日別の利用量を確認できます。既定では1か月分の表示ですが、フィルターで期間を調整できます。さらに、利用量に寄与しているリソースの内訳を表で確認し、個別リソースの詳細をサイドパネルで掘り下げられます。(Microsoft Learn)
Data lakeのしきい値通知とEnforcementは慎重に設定する
DefenderポータルのCost managementでは、Configure PoliciesからData lake機能に対するしきい値ベースのアラートを設定できます。通知は、現時点ではポリシーを構成した課金管理者にメールで送信されます。運用上は、個人のメールだけに依存せず、共有メールボックスや運用チームへの転送ルールを設計しておくと安全です。(Microsoft Learn)
さらに、しきい値を超えた後に利用をブロックするEnforcementも設定できます。ただし、EnforcementがサポートされるのはData Lake QueryのインタラクティブKQLクエリ・ジョブと、Advanced Data InsightsのNotebook実行・Notebookジョブです。しきい値超過後は、将来のクエリ、ジョブ、セッションが失敗し、ユーザーにはLimit exceededエラーが表示されます。(Microsoft Learn)
重要なのは、Enforcementがリアルタイムではない点です。公式ドキュメントでは、上限到達後にEnforcementが有効になるまで最大4時間かかる可能性があると説明されています。つまり、予算超過を完全に防ぐスイッチではなく、「超過後の拡大を抑える仕組み」と考えるべきです。(Microsoft Learn)
| 設定 | 実務での考え方 |
|---|---|
| Alert percentage | 70〜80%程度で早めに通知し、月末前に対策できるようにする |
| Total threshold | 月次予算ではなく、検証環境・本番環境・ジョブ用途ごとに分けて考える |
| Enforcement | 本番調査に必要なクエリまで止まらないよう、最初は検証環境から有効化する |
| 通知先 | ポリシー作成者だけでなく、SOC、Azure管理者、FinOps担当に共有する運用を作る |
| レビュー頻度 | Data lake導入直後は週次、安定後は月次で見直す |
管理者が確認すべき設定
Microsoft Defenderポータル移行を見据えると、管理者はコスト画面だけでなく、権限、予算、エクスポート、保持期間、コネクタをセットで確認する必要があります。
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| Cost Managementの閲覧権限 | Azure Cost Managementで対象スコープの読み取り権限があるか | コスト異常に気付けない |
| DefenderポータルのCost management権限 | Billing AdministratorとSecurity Administratorを持つ担当者がいるか | Data lake tierの利用量を確認できない |
| Cost Analysisのフィルター | Sentinel、Log Analytics、Azure Monitorを含めているか | Sentinel関連コストを過小評価する |
| 予算アラート | サブスクリプションまたはリソースグループ単位で設定しているか | 月末に請求額を見て初めて気付く |
| コストデータのエクスポート | 日次、週次、月次でStorage Accountに出力しているか | ExcelやPower BIで継続分析しにくい |
| Workspace Usage Report | テーブル別、無料・有料データ別に可視化しているか | どのログが費用増の原因か分からない |
| 保持期間とテーブル階層 | 高容量・低価値ログをLake tierへ移せるか | Analytics tierに不要なログを置き続ける |
公式ドキュメントでは、コストデータをStorage Accountへ日次、週次、月次でエクスポートでき、コストデータセットを取得する推奨方法として説明されています。また、予算とアラートはサブスクリプションやリソースグループ単位で作成でき、特定リソースやサービスにフィルターをかけることも可能です。(Microsoft Learn)
移行時の注意点：Azureポータル前提の運用を見直す
Microsoft Sentinelは2027年3月31日以降、Azureポータルではサポートされず、Microsoft Defenderポータルのみで利用可能になる予定です。既存のAzureポータル利用者はDefenderポータルへの移行計画を始めることが推奨されています。(Microsoft Learn)
移行そのものに追加費用はかからず、顧客は引き続きSentinelの消費量に応じて通常どおり課金されると説明されています。ただし、追加費用がないからといって、運用影響がないわけではありません。画面、権限、インシデント相関、Automation rule、Playbook、API連携に違いが出るため、移行前に棚卸しが必要です。(Microsoft Learn)
データ収集とコネクタ
Microsoft SentinelをMicrosoft Defenderに統合しても、既存のデータ収集やテレメトリの流れ、Log Analyticsの取り込みパイプライン、データスキーマの基本構造は維持されると説明されています。ただし、Microsoft Defender XDR関連のアラートはDefender XDR connectorから直接ストリーミングされるため、ワークスペースでインシデントとアラートが有効になっているか確認する必要があります。(Microsoft Learn)
Defender for Cloudのテナントベースコネクタを使っている場合は、重複イベントや重複アラートを避けるための対応が必要です。レガシーのサブスクリプションベースコネクタを使っている場合も、インシデントやアラートの同期設定を確認する必要があります。(Microsoft Learn)
分析ルールと相関
Defenderポータルでは、Microsoft SentinelのAnalytics rulesは引き続き検出、構成、管理に使えます。ただし、Defenderポータル側ではDefender XDRの相関エンジンがインシデントのグルーピングやマージを制御するため、AzureポータルでのFusionルールやアラートグルーピングの見え方と同じになるとは限りません。(Microsoft Learn)
特に、インシデント名を条件にした自動化は失敗しやすいポイントです。Defenderポータル移行後は相関によってインシデント名が変わる可能性があるため、Automation ruleの条件には、インシデントタイトルよりも分析ルール名やタグを使う方が安定します。(Microsoft Learn)
Playbookと外部連携
PlaybookはAzure Logic Appsを基盤にした自動化機能ですが、Defenderポータル移行後は一部のトリガーや条件に注意が必要です。たとえば、SecurityIncidentテーブルのDescriptionフィールドがDefenderポータル移行後に含まれなくなるため、このフィールドを条件にしたAutomation ruleは動作しなくなる可能性があります。外部チケットシステムにインシデント説明を連携している場合も影響を確認してください。(Microsoft Learn)
また、Defenderポータルでインシデントが作成・更新されてからAutomation ruleが実行されるまで、最大10分程度の遅延が発生する可能性があります。即時対応を前提にしたPlaybookでは、遅延を考慮した設計や監視が必要です。(Microsoft Learn)
APIと開発者向けの確認
開発者は、インシデントやアラートを扱うAPI連携を必ず確認してください。公式情報では、統合されたインシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨され、Microsoft Sentinel APIはAnalytics rulesやAutomation rulesなどSentinelリソースに対する操作を引き続きサポートすると説明されています。既存のSecurityInsights APIでSentinelインシデントを処理している場合、レスポンス本文の変更により自動化条件やトリガー条件の修正が必要になる可能性があります。(Microsoft Learn)
Data lake導入時に見落としやすいコスト要因
Data lake tierは、長期保存や大量ログの扱いに向いていますが、安い置き場所としてだけ見ると失敗します。保存だけでなく、クエリでスキャンしたデータ量、Notebookの実行時間、Data lake向けのデータ処理もコスト要因になります。公式ドキュメントでは、Data lake ingestion、Data processing、Data lake storage、Data lake query、Advanced data insightsなどのメーターが説明されています。(Microsoft Learn)
| 失敗パターン | 起きること | 対策 |
|---|---|---|
| 広い期間を毎回KQLで検索する | Data lake queryのスキャン量が増える | 期間、列、条件を絞る。定型調査は保存済みクエリ化する |
| Notebookを検証後も起動したままにする | Advanced data insightsのコンピュート時間が増える | セッション終了ルールと利用者教育を徹底する |
| 低価値ログをAnalytics tierに置き続ける | 高コストな分析対象が増える | 二次的なログはLake tierへの切り替えを検討する |
| しきい値通知だけを設定する | 通知を見逃すと超過が続く | Alert percentageとEnforcementを段階的に併用する |
| Enforcementを本番で即有効にする | 調査中のKQLやNotebookが止まる | 検証環境で動作確認し、運用時間帯と対象を決める |
保持期間も重要です。Microsoft SentinelをLog Analyticsワークスペースで有効化した後、最初の90日間の保持は追加料金なしで利用でき、90日を超える保持はLog Analyticsの保持料金に従うと説明されています。また、高容量で低価値のログはLake tierに切り替えることで、低コストで保存しつつクエリ機能を利用できる選択肢があります。(Microsoft Learn)
変更管理で必ず残すべき記録
コスト増の原因調査で最も困るのは、「いつ何を変えたか」が残っていないことです。Microsoft Sentinelのコストは、単価よりもデータ取り込み量と利用パターンの変化で大きく動きます。次の項目は、変更チケットや運用台帳に残しておくことを推奨します。
| 記録する項目 | 例 |
|---|---|
| 変更日 | 2026年6月1日にDefender for Cloudコネクタ設定を変更 |
| 対象ワークスペース | 本番SOCワークスペース、検証用ワークスペース |
| 追加・変更したコネクタ | Microsoft Defender XDR、Defender for Cloud、CEF、Syslogなど |
| 取り込み対象のデータ型 | SecurityAlert、CommonSecurityLog、DeviceEventsなど |
| 予想される増加量 | 日次で数GB増、月次で前月比20%増など |
| Cost Analysisの確認日 | 変更後1日、7日、31日 |
| ロールバック条件 | 日次コストが想定の2倍を超えたら一時停止する、など |
この記録があれば、請求額が増えたときに「Microsoft Defender側の変更なのか」「Sentinel側のコネクタなのか」「Log Analyticsの保持期間なのか」を切り分けやすくなります。
実務でおすすめの運用フロー
Microsoft Defenderポータル移行とSentinelコスト管理を同時に進める場合は、次の流れで整理すると失敗しにくくなります。
| タイミング | 実施内容 |
|---|---|
| 初回棚卸し | Sentinelワークスペース、価格レベル、Log Analytics設定、Data lake有効化状況を一覧化する |
| 初回設定 | Azure Cost AnalysisでSentinel、Log Analytics、Azure Monitorを含むビューを保存する |
| 初回分析 | KQLで直近31日の課金対象データをDataType別・Solution別に確認する |
| Data lake利用時 | DefenderポータルのCost managementでメーター別利用量とResource contributorsを確認する |
| 予算設定 | Azure Cost Managementで予算アラート、DefenderポータルでData lakeしきい値を設定する |
| 週次確認 | 急増したテーブル、クエリ、Notebook、ジョブを確認する |
| 月次確認 | 予算、予測コスト、保持期間、Lake tierへの移行候補をレビューする |
| 移行前確認 | Automation rule、Playbook、API、外部チケット連携、コネクタ重複をテストする |
この運用で重要なのは、コスト監視をFinOpsだけに任せないことです。Microsoft Sentinelの費用は、セキュリティ検知の質、ログ保持、インシデント対応、自動化の設計と密接に関係します。SOC管理者、Azure管理者、開発者、請求管理者が同じ指標を見る体制を作ることが、コスト削減と検知品質の両立につながります。
まず実行すべきチェックリスト
最後に、今回の「Manage and monitor costs for Microsoft Sentinel」を受けて、管理者がすぐに実行すべき作業を整理します。
| 優先度 | 作業 |
|---|---|
| 高 | Azure Cost ManagementでSentinel、Log Analytics、Azure Monitorを含むCost Analysisビューを作る |
| 高 | 直近31日のUsageテーブルをKQLで確認し、課金対象データの上位DataTypeを把握する |
| 高 | Sentinel data lakeを有効化している場合、DefenderポータルのMicrosoft Sentinel > Cost managementを確認する |
| 高 | Billing AdministratorとSecurity Administratorの担当者を明確にする |
| 中 | 予算アラートとData lakeしきい値通知を設定し、通知先を運用チームで共有する |
| 中 | Workspace Usage Reportを保存し、月次レビュー用のビューを作る |
| 中 | 低価値・高容量ログのLake tier移行や保持期間変更を検討する |
| 中 | 2027年3月31日までのDefenderポータル移行計画を作る |
| 中 | Playbook、Automation rule、API、外部チケット連携の移行影響をテストする |
今回の更新は、単なる請求確認手順ではありません。Microsoft Defenderポータルを中心にMicrosoft Sentinelを運用する時代に向けて、コスト、データ保持、KQL、Notebook、自動化、API連携を一体で管理するための整理です。まずは現在のSentinelワークスペースごとに、Analytics tierとData lake tierのどちらで何が課金されているかを可視化し、予算アラートとしきい値設定を入れるところから始めてください。
コメント