Microsoft Sentinel の請求が難しく見えるのは、料金の話に見えて、実際はデータ設計の話だからです。2026年4月8日に更新された公式ガイダンスでは、Analytics 層と Data Lake 層の違いだけでなく、保持、請求明細、無料データ、graph や MCP まで含めて課金の全体像が整理されています。結論から言うと、最新の Microsoft Sentinel 請求ガイダンスで最も重要なのは、コスト管理を「導入後の経理処理」ではなく「SOC 設計の初期要件」として扱うことです。 (Microsoft Learn)
具体的には、リアルタイム検知に使うログは Analytics、低頻度の調査や監査向けは Data Lake や長期保持、SOC で使わない運用ログは Sentinel を有効にしない別ワークスペースへ分けます。そこに Cost Management、Defender ポータルのしきい値ポリシー、SOC 最適化を重ねると、コストだけでなく検知の抜けも減らしやすくなります。 (Microsoft Learn)
まずは「ログの時間価値」で置き場所を決める
Microsoft Sentinel の請求を実務でさばくなら、ログを「どの製品のログか」ではなく「どれだけ早く行動に使うか」で分けるのが最短です。Analytics 層はリアルタイム分析・ハンティング・ワークブック向け、Data Lake 層は低コストの長期保有と後追い分析向け、SOC で使わない運用データは非 Sentinel ワークスペース向け、という切り分けが基本になります。 (Microsoft Learn)
| ログの使い方 | 置き場所の目安 | 理由 |
|---|---|---|
| すぐに検知・ハント・可視化に使う | Analytics 層 | 高速クエリと Sentinel 機能をフルで使える |
| 後日の調査、監査、履歴分析で使う | Data Lake / total retention | 低コストで長く持てる |
| 運用監視だけで SOC では使わない | Sentinel なしの別ワークスペース | Sentinel 分析課金を避けやすい |
この整理は、公式が示す Analytics と Data Lake の役割差、長期保持の考え方、そして非セキュリティデータを別ワークスペースへ分離する推奨を、そのまま設計判断に落としたものです。 (Microsoft Learn)
特に重要なのは、Microsoft Sentinel が有効な Log Analytics ワークスペースに入ったデータは、すべてコスト設計の対象になることです。公式のワークスペース設計サンプルでも、Perf、InsightsMetrics、ContainerLog など SOC が直接使わないデータは運用用ワークスペースへ逃がし、Office 365、Azure Activity、Microsoft Entra ID、Azure PaaS のセキュリティ関連データを Sentinel 側へ寄せる構成が示されています。 (Microsoft Learn)
さらに、AKS は監査ログだけを Sentinel ワークスペースへ、パフォーマンス系は非 Sentinel ワークスペースへ送り、Windows VM は AMA でセキュリティイベントとパフォーマンス/Windows イベントを分離する、という設計も可能です。重複して持つ必要があるデータは、テーブルレベル RBAC で共有範囲を絞る方が、何でも一つのワークスペースに入れるより後から管理しやすくなります。 (Microsoft Learn)
Microsoft Sentinel の請求モデルを実務向けに整理する
Analytics 層
Analytics 層は、既定の従量課金制か、コミットメント レベルで支払います。コミットメントは 100GB/日からで、増額はいつでもできますが、減額や従量課金制への戻しは 31 日間のコミット期間が終わるまでできません。しかもインジェストと分析は日次で課金されるため、価格レベルの判断は月平均ではなく、平日と休日を含めた日次の山谷で見るのが実務では重要です。 (Microsoft Learn)
また、2023年7月より前の古いワークスペースではクラシック価格のまま残っている場合があり、請求書上で Sentinel と Log Analytics が分かれて見えることがあります。Cost Analysis でも、Sentinel だけではなく Log Analytics と Azure Monitor を一緒に追わないと、実額を読み違えやすいです。 (Microsoft Learn)
POC 段階なら、Analytics ログで最初の 10GB/日が 31 日間無料の試用を使えますが、automation、BYOML、Data Lake 関連の料金は別です。さらに Azure Activity、SentinelHealth、Office 365 監査ログの一部、Defender 系のアラートは無料データに含まれます。一方で、Defender や Entra の一部の生ログは有料なので、「アラートが無料だから生ログも無料」と考えない方が安全です。 (Microsoft Learn)
Data Lake 層
Data Lake 層は、リアルタイム検知よりも、履歴調査・監査・長期保管向けの層です。Data Lake only のテーブルには、インジェスト、処理、ストレージ、クエリの各料金が発生し、ストレージは分析保持が終わった後のデータに対してかかります。ストレージ課金は 6:1 の圧縮率で計算され、クエリはコンピュート時間ベースです。つまり、大量ログをとにかく Analytics に積み続けるより、「今すぐ使うか」「後で掘るか」で分けた方が設計が素直になります。 (Microsoft Learn)
分析層のデータは既定で同じ保持期間だけレイクにミラーされ、分析保持を超えて最大 12 年まで低コストで延長できます。継続的なアラートや通常のハンティングに不要なログ、たとえばストレージアクセスログ、NetFlow、VPC フローログ、プロキシログ、ファイアウォールログ、IoT ログなどは、Data Lake only の候補として検討しやすい種類です。 (Microsoft Learn)
ただし、Data Lake only のデータはリアルタイム分析や通常の脅威ハンティングの土台には向きません。「長く持ちたいから全部 Data Lake」ではなく、「即時対応に使うか」「後日分析に使うか」で分けるのが失敗しにくい考え方です。 (Microsoft Learn)
見落としやすい追加料金
今回の請求ガイダンスで見逃しにくくなったのが、graph と AI エージェント連携の MCP 周辺です。Defender/Purview ポータルに埋め込まれたグラフ表示は課金されませんが、カスタムグラフや Graph API、MCP のグラフツール経由の処理はコンピュート時間ベースで請求されます。MCP サーバー自体に追加料金はありませんが、Data Lake ツールはクエリ メーターを使い、Entity Analyzer は SCU と Data Lake クエリ料金が発生しえます。さらに Logic Apps、Notebooks、Azure Functions、BYOML など周辺 Azure サービスの料金も別建てです。 (Microsoft Learn)
コストを抑えながら検知力を落とさない実践手順
- まず Azure Cost Analysis で
Sentinel、Log Analytics、Azure Monitorを同時に見て、日次の増減と請求先を把握します。次にWorkspace Usage Reportでテーブル別の無料/課金データ量を見て、どのテーブルが本当に金額を押し上げているかを洗います。 (Microsoft Learn) - テーブルを「A: リアルタイム検知に必要」「B: 後追い調査や監査用」「C: SOC で使わない運用データ」の 3 つに分けます。C は別ワークスペース、B は Data Lake / total retention / eligible table なら basic logs を検討し、A だけを Analytics に残すと、コストと検知価値の対応が見えやすくなります。SOC 最適化は 24 時間ごとに再計算され、低利用テーブルや改善候補を出してくれるので、この棚卸しの起点に向いています。 (Microsoft Learn)
- インジェストが安定して大きいなら価格体系を見直します。コミットメント レベルは日次パターンに合わせて選び、同一リージョンで 100GB/日以上を複数ワークスペースに入れているなら専用クラスターも候補です。さらに支出が読みやすい環境なら、分析層向けの事前購入プランを重ねると節約しやすくなりますが、Data Lake などは対象外です。 (Microsoft Learn)
- ガードレールは通知だけで終わらせません。Azure 側では予算とアラート、必要なら
Send-IngestionCostAlertプレイブックを使い、Data Lake 側では Defender ポータルのコスト管理でしきい値アラートと強制を設定します。ただし強制適用はリアルタイムではなく最大 4 時間かかることがあるので、これだけを緊急遮断装置にしない方が安全です。Data Lake のコスト管理ページには Billing Administrator と Security Administrator の両方が必要です。 (Microsoft Learn) - 最後に、コスト運用の主戦場を Defender ポータルへ寄せます。Microsoft は 2027年3月31日以降、Azure portal での Microsoft Sentinel をサポートしないとしており、Data Lake のコスト管理や SOC 最適化も Defender ポータル中心です。請求の見直しを機に、ポータル移行と権限設計まで一緒に進める方が手戻りを減らせます。 (Microsoft Learn)
失敗しやすいポイント
- 月平均だけでコミットメント レベルを決めること。Microsoft Sentinel のインジェストと分析は日次課金なので、月末の平均がきれいでも、平日の山で毎回超過すると想定より高くなります。 (Microsoft Learn)
- SOC 最適化の「未使用」をそのまま採用すること。SOC 最適化は直近 30 日で課金対象テーブルを見て提案し、公式もプラン変更前にコンプライアンス要件や取り込み制限を確認するよう注意しています。四半期監査でしか使わないログは、30 日だけ見て切ると危険です。 (Microsoft Learn)
- Sentinel を削除すれば課金も止まると思うこと。Microsoft Sentinel を外しても Log Analytics ワークスペース自体や、そのワークスペースに紐づく別料金は残ります。 (Microsoft Learn)
- 請求書で
Sentinelだけを確認すること。クラシック価格や関連サービスでは、Log AnalyticsやAzure Monitorに費用が出ることがあるため、コスト分析では 3 つまとめて追うのが安全です。 (Microsoft Learn)
まとめ
2026年4月8日時点の Microsoft Sentinel 請求ガイダンスは、料金表の読み方を更新しただけではありません。「どのログを Analytics に残すか」「どこから Data Lake へ落とすか」「そもそも Sentinel に入れないデータは何か」を、Cost Management と SOC 最適化まで含めて設計させる内容になっています。Microsoft Sentinel のコストを本気で下げたいなら、最初にやるべきことは値引き交渉ではなく、テーブル分類、ワークスペース分離、日次ボリューム確認、そして Defender ポータルでのガードレール設定です。ここまでできれば、請求の最適化はそのまま SOC の成熟度改善につながります。 (Microsoft Learn)
コメント