Microsoft Sentinelは提供されるセキュリティ価値ではなくデータ量（取り込み・長期保存）に比例して増加します。本記事では、Sentinelを運用する方向けに、コストを最適化（削減）するための手法を11個まとめました。
本記事は2026年9月時点の公開情報、検証結果（一部は未検証）に基づいています。また、削減することだけを目的にすると、Sentinelの存在意義が薄れてしまいます。そのため、セキュリティ・コストとバランスをとった「最適化」を心がけていきましょう。
前提：SentinelとSentinelコストの主要な構成要素
Microsoft Sentinel 1 は、Microsoft が提供するクラウドネイティブなSIEM（Security Information and Event Management）／SOAR（Security Orchestration, Automation and Response）です。組織内外の様々なデータソース（Microsoft 365、Azure、オンプレミス機器、サードパーティ製品など）からログを集約し、相関分析による脅威検知、インシデント調査、自動化対応までを一つの基盤で行えます。Sentinelの実体は、Azure Monitor の Log Analyticsワークスペース 上に構築されており、Log AnalyticsワークスペースでSentinelを有効にすることで、分析ルールなどのSentinel固有の機能を利用できます。そんな、Sentinel の主要な構成要素は以下の通りです。
| 主要な構成要素 | 概要 |
|---|---|
| データ取り込み（Ingestion） | 各種データソースからログを Sentinel のワークスペースに取り込む処理 |
| データ保持（Retention） | 取り込んだログをワークスペース内に保存しておく期間。一定期間（例：90日）までは無料の場合が多いが、それを超える保持期間や長期保存は別途課金 |
| その他コスト | Logic Apps（SOAR）やログ転送費用、Data Lakeのクエリ、Security Copilot、Sentinel Graph などのコスト |
| 割引 | 後述 |
上記のうち、「その他コスト」は複雑すぎる、且つSecurity Copilot以外は見直しインパクトが薄いことが多いので、このブログでは主にデータ取り込み（Ingestion）とデータ保持（Retention）を主な論点とします。
手法1：現状の取り込み状況を可視化する
最適化の前に、まず「どのテーブルが、どれだけコストを発生させているか」を把握するところからはじめましょう。以下のKQLで課金対象データ量をテーブル別に集計できます。
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize IngestedGB = sum(Quantity) / 1024 by DataType
| sort by IngestedGB desc
また、手法2以降を考えるうえで、Sentinel の検知ルールの存在も避けては通れません。GUIでも見れますが、以下で棚卸しておくとよいでしょう。
SentinelHealth
| where SentinelResourceType == "Analytics Rule"
最近は、SentinelとDefender XDRポータルを統合すると、コストのダッシュボードが見えるので、そこで見るのもよいですね。
手法2：無料・特典枠を取りこぼさない
Sentinel には条件によって、以下のようなタダ/安価で取り込めるデータがあります。手法1でボリュームが多い場合でも、無料枠の範囲である場合には後述の手法の優先度を落とすことができるかと思います。
無料データソース2：
- Azure アクティビティ ログ
- Microsoft Sentinel の正常性状態
- Office 365監査ログ (すべての SharePoint アクティビティ、Exchange 管理者アクティビティ、Teams を含む)
- 次のソースからのアラートを含むセキュリティ アラート。
- Microsoft Defender XDR
- Microsoft Defender for Cloud
- Microsoft Defender for Office 365
- Microsoft Defender for Identity
- Microsoft Defender for Cloud Apps（クラウドアプリを守るマイクロソフトのセキュリティサービス）
- Microsoft Defender for Endpoint（エンドポイント用マイクロソフトディフェンダー）
- 次のソースからのアラート:
- Microsoft Defender for Cloud
- Microsoft Defender for Cloud Apps（クラウドアプリを守るマイクロソフトのセキュリティサービス）
特典3：
Microsoft 365 E7、E5、A5、F5、G5 および Microsoft 365 E7、E5、A5、F5、G5 Security のユーザーは、Microsoft 365 データ インジェスト量 1 ユーザーにつき 1 日あたり最大 5 MB のデータ助成を利用できます。このオファーに含まれるデータソースは以下のとおりです。
- Microsoft Entra ID (旧 Azure AD) サインインおよび監査ログ
- Microsoft Defender for Cloud Apps Guard シャドウ IT 検出ログ
- Microsoft Purview Information Protection ログ
- Microsoft 365 の高度な追求データ
手法3：アーキテクチャを見直す（アラートは取り込むが生テレメトリはエッジに任せる）
EDR / NDR / CWPPといったエッジのセキュリティツールは、ベンダーのR&Dと脅威インテリジェンスが組み込まれた強力な検知エンジンです。ここで一次検知を済ませ、SIEMには精度の高いアラートを送る構成にすると、データ量は劇的に変わります。例えばエンドポイント数千台からのEDR生ログ・テレメトリは月間数千GB規模になることがある一方、EDRアラートだけなら0.1〜0.5GB程度で収まることがあります。（条件によって異なります。）
特にこの作戦が効いてくるのは、Micrsoft Defender for Endpoint ですね。アラートはXDRコネクタ経由（無料）で取り込み、DeviceProcessEvents 等の生テレメトリを全量Analyticsティア取り込みすることは避けるといいかもしれません。Microsoft Defender XDR には Sentinel の分析ルール（検知ルール）と似た機能である「カスタム検出」やKQLでログ分析ができる「Advanced Hunting」が用意されているので、これを使うことで、Sentinel にデータを取り込まなくても、オリジナルの検知ルールを構成することだってできます。加えて、DefenderとSentinelのポータル統合により、Sentinelに取り込まなくてもDefender XDR側のデータはデフォルトで30日間Advanced Huntingから参照できるため、ユーザー体験上の断絶は生まれません。30日以上の保管が必要な場合には、手法5のデータレイクを使うと良いかもしれません。
注意点として、アラートのみに頼ると相関分析やカスタムシナリオが組めず、コンテキストも限定的になります。バランスを取りながらやっていきましょう。
手法4：シナリオ起点でログ取り込みを決める（検知エンジニアリング）
ここで、「先に脅威シナリオを作り、その検知に必要なデータだけを取り込む」というプロセスの重要性を強調しておきます。稟議書で「SIEMにログを集めて相関分析する！」という言葉を見たり見なかったりしますが、「何をどう相関させて、どのようなアウトカム（成果）をもたらしたいのか」というシナリオがない限り、少なくともAnalyticsティアに取り込むべきではありません。フォレンジック用だけのデータも同様です。とりあえず取り込んでからルールを考える事をやると、データは必ず膨張します。コスト最適化と検知品質向上は、検知エンジニアリングを介して同じ活動になる気がします。
Sentinel はテーブル単位でログの取り込みを調整できるので、それをテーブルに反映していきましょう。
手法5：Sentinel Data Lakeティアへ低価値ログをルーティングする
2025年に一般提供されたMicrosoft Sentinel Data Lakeは、コスト最適化の重要オプションです。これを有効にすると、Sentinel Analyticsティアのデータをレイク層にミラーすることができ、コスト効率高く長期保管することができます。
| Analyticsティア | Data Lakeティア | |
|---|---|---|
| 用途 | リアルタイム検知、分析ルール、自動化 | 監査・コンプライアンス保管、レトロスペクティブ分析、脅威ハンティング、AIモデル学習 |
| クエリ性能 | 高速（KQLフル機能） | 低速・バッチ的（KQLジョブ、ノートブック） |
| コスト | 高額（取り込み+保持） | 取り込み・保存とも大幅に低額、ただしKQLジョブなどは別料金 |
なお、Data Lakeティアのデータも、インシデント調査で必要になったタイミングでKQLジョブによりAnalyticsティアへ昇格（プロモート）して深掘りできます。「まず全部Analyticsティアに入れる」という従来の発想から脱却することが削減インパクトの大きい一手です。また、条件を満たせばData Lakeに直接取り込みもできるので、マイクロソフトが出しているMicrosoft Sentinel のデータ レイク直接取り込みガイダンスなどもぜひ参考にしてください。
手法6：検知に使わないテーブルをLog AnalyticsのBasic Logs / Auxiliary Logsに切り替える
ここまでは主にSentinel側の設計の話でしたが、実はSentinelの土台であるLog Analyticsワークスペース自体に、テーブル単位で選べる安価な保存プランが用意されています。これはSentinel固有の機能ではなく、Log Analyticsワークスペースの機能です。Sentinelを使っていなくても存在する仕組みで、Sentinelはこのワークスペースの上に乗っかっているだけ、という理解をしておくと混乱しません。手法5との違いは、Sentinel のAnalyticsティア（分析ルール）を使うか否かというポイントかなと個人的には理解しています。具体的には、テーブルごとに以下の3つのプランを選択できます。4
| Analytics（通常） | Basic Logs | Auxiliary Logs | |
|---|---|---|---|
| 取り込み単価 | 高い（基準） | Analyticsの1/4〜1/5程度 | Basicよりさらに安い |
| クエリ課金 | ワークスペース料金に含む | 都度課金 | 都度課金 |
| 主用途 | リアルタイム検知・相関分析 | トラブルシュート・調査のためのログ一時参照 | 監査・コンプライアンス保管、たまに見るverboseログ |
手法1で洗い出したテーブルのうち、「分析ルールで一度も参照されていない」「相関分析には使っていない、単に置いてあるだけ」のテーブルがあれば、わざわざAnalyticsティアに置いておく必要はありません。
Basic LogsまたはAuxiliary Logsに設定したテーブルは、Sentinelの分析ルール（サマリールールは除く）の対象にできません。そのテーブルに関しては、リアルタイムの相関検知はできず、KQLで手動検索できるだけの「安いログ倉庫」になります。すでに分析ルールがそのテーブルを参照している場合、切り替えるとルールがサイレントに機能しなくなる可能性があるため、必ず事前に影響範囲を確認してください。「普段は検知に使わないが、インシデント発生時に念のため見たい」「監査で問われたら出したい」程度のログの置き場所として最適です。
設定は [Azure Portal] > [対象の [Log Analyticsワークスペース] > [左メニュー テーブル (Tables)] > [対象テーブルの「…」] > [テーブルプランを管理 (Manage table plan)] で Analytics / Basic Logs / Auxiliary Logs を切り替えする形です。
手法7：DCR変換でインジェスト前にフィルタ・整形する
今まではどちらかというと、テーブルベースでのコスト削減の話をしてきました。今度はカラム・レコードベースです。Data Collection Rules（DCR）の変換（Transformation）を使うと、不要な行・列を落とせます。取り込まれなかったデータには課金が発生しません。なお、フィルタ率が50%を超える場合は超過分に処理課金ありますが、それでも取り込むより大幅に安価です。
より大規模・複数宛先のルーティングが必要な場合は、Azure Monitorパイプラインや、サードパーティのテレメトリパイプラインをSentinelの前段に置く構成も考えられます。この場合、大きなボリューム削減が見込めますが、ツールとTCOの追加、データエンジニアリングのスキルが必要になる点はトレードオフとして評価してください。個人的にはよっぽど大規模にならないとリターンないかと・・・
手法8：CCFネイティブコネクタでBlob Storage経由のログを取り込み
Microsoft Sentinelの Codeless Connector Framework（CCF）は、これまでREST APIからの取り込みが中心でしたが、2026年に Azure Storage Blob を直接ソースにできる接続方式が追加されました。アプリケーション側がBlob Storageにログファイルを書き出すと、Event Gridがblob作成イベントをストレージキューに送り、SentinelコネクタがキューをポーリングしてBlobを取得し、Logs Ingestion API経由でワークスペースに取り込こむという流れだとドキュメントに記載があります。
この構成だと、Blobが安価な一次保管先として仕え、さらに後工程で選択的取り込みを設計しやすくなりそうです。取り込み範囲を絞った上で手法7のDCR変換を重ねれば、Analyticsティアの課金対象をさらに絞り込めるはずです。
ちなみに、私は未検証です。未検証のものを人に勧めて申し訳ないですが、網羅性を上げたかったので。。。そのうち検証します。
手法9：コミットメントティア（確約料金）を正しく選ぶ
1日あたりの平均取り込み量が概ね100GB/日を超えているなら、従量課金（Pay-as-you-go）からコミットメントティアへの切り替えを検討します。ティアに応じて実効GB単価が段階的に下がり、上位ティアでは従量課金比で数十%の割引になります。ポイントはログ量が落ちるであろう休日を勘案して計算するということです。コミットメントすると、土日を含めてコミットすることになるので、逆に損をしないように気を付けましょう。5
| SKU | Meter type | Price（本書執筆時点 EastUS） |
|---|---|---|
| Pay-as-you-go | Analysis (GB) | $4.3 USD（100GBだと$430GB/Day） |
| 100 GB Commitment Tier | Commitment Tier/Day | $296 USD |
| 200 GB Commitment Tier | Commitment Tier/Day | $548 USD |
| 300 GB Commitment Tier | Commitment Tier/Day | $800 USD |
| 400 GB Commitment Tier | Commitment Tier/Day | $1037.33 USD |
| 500 GB Commitment Tier | Commitment Tier/Day | $1265 USD |
| 1000 GB Commitment Tier | Commitment Tier/Day | $2480 USD |
| 2000 GB Commitment Tier | Commitment Tier/Day | $4800 USD |
| 5000 GB Commitment Tier | Commitment Tier/Day | $11550 USD |
| 10000 GB Commitment Tier | Commitment Tier/Day | $22240 USD |
| 25000 GB Commitment Tier | Commitment Tier/Day | $53450 USD |
| 50000 GB Commitment Tier | Commitment Tier/Day | $102600 USD |
50 GB のコミットメント レベルもありますが、パブリックプレビュー中なので、考慮しませんでした。
手法10：コストの継続監視とガードレールを設定する
リバウンドを防ぐ仕組みです。日次取り込み上限（Daily Cap）は想定外のログ爆発（デバッグログの誤送信等）に対する最後の防波堤として設定しましょう。ただし上限到達中はセキュリティログも欠落するため、あくまで異常時のサーキットブレーカーと位置づけです。加えて、取り込み量の急増を検知する異常検知アラートルールを仕込むのも効果的です。さらに、Azure Cost Managementの予算アラートをワークスペース単位で設定するのは基本です。忘れないでおきましょう。
手法11：Sentinel のリージョンを変更する
実はSentinelの1GBあたりのコストは、リージョンで最大2倍近くも違います。筆者がポチポチ調べた結果が以下の通りですが、USはかなり安いですね。Sentinelは一度作ると、リージョンは移動できないので、既存テナントがある場合は作り直しとなりますが、要件が許すならばUSにSentinelのリージョンを移すと、日本リージョンと比較して3割ほどコスト削減できます。6
Central US $5.22 USD
East US $4.3 USD ★最安値
East US 2 $4.76 USD
North Central US $5.16 USD
South Central US $5.16 USD
West Central US $5.16 USD
West US $5.59 USD
West US 2 $4.3 USD ★最安値
West US 3 $4.3 USD ★最安値
UK South $5.38 USD
UK West $5.5 USD
UAE Central $7.4 USD
UAE North $5.93 USD
Switzerland North $5.99 USD
Switzerland West $7.18 USD
Sweden Central $5.59 USD
Sweden South $6.37 USD
Spain Central $5.59 USD
Qatar Central $5.93 USD
Poland Central Commitment Tierのみ
Norway East $5.29 USD
Norway West $7.99 USD
New Zealand North 未展開
Mexico Central $4.73 USD
Korea Central $5.81 USD
Korea South $5.61 USD
Japan East $6.24 USD
Japan West $6.67 USD
Italy North $5.59 USD
Israel Central $5.93 USD
Central India $6.02 USD
South India $6.47 USD
West India $6.21 USD
Germany North Commitment Tierのみ
Germany West Central $5.59 USD
France Central $5.26 USD
France South $6.02 USD
North Europe $5.16 USD
West Europe $5.59 USD
Canada Central $5.16 USD
Canada East $5.16 USD
Brazil South $8.6 USD
Brazil Southeast $9.89 USD ★最高値
Australia Central $6.24 USD
Australia Central 2 $6.24 USD
Australia East $6.24 USD
Australia Southeast $6.14 USD
East Asia $7.13 USD
Southeast Asia $5.59 USD
South Africa North $6.28 USD
South Africa West $6.88 USD
※2026年6月7日現在
昨今の電力価格の高騰やデータセンター・半導体投資、地政学的な影響等により、価格の優位性は変化する可能性もありますので、価格はあくまで現時点のものだと捉えていただけたら幸いです。
余談
Sentinelのコスト試算には専用ツールがあるので、ご利用ください。
まとめ
Sentinelのコストは、非常に複雑ではありますが、特にエンタープライズにもなると、最適化することで人が雇えるほどの変化をもたらすこともあったり、なかったりします。コストを最適化させられると、その原資を別のことに使えるようになると思うので、地道ですが取り組んでいきましょう。