Reduce costs for Microsoft Sentinelは、Microsoft Sentinelの費用を下げるために、取り込むログ量、価格レベル、保持期間、データレイク、データ収集ルールを見直す公式ガイドです。結論から言うと、最初にやるべきことは「直近31日程度の課金対象データ量を確認し、不要な取り込みを減らし、利用量に合う価格レベルへ調整する」ことです。2026年5月14日更新の公式情報では、Microsoft Sentinel in the Microsoft Defender portalとAzure portalの両方が対象として示されていますが、2027年3月31日以降はAzure portalでのMicrosoft Sentinelサポートが終了し、Microsoft Defenderポータルのみで利用する流れになる点も重要です。(Microsoft Learn)
この記事では、Microsoft Defender環境でMicrosoft Sentinelのコスト削減を進めるために、何が変わるのか、誰が影響を受けるのか、管理者や開発者がどの設定を確認すべきかを実務目線で整理します。単に「ログを減らす」のではなく、検知に必要なデータは残し、価値の低いデータや長期保管データを適切な場所へ移すことがポイントです。
Microsoft Defenderの「Reduce costs for Microsoft Sentinel」は何が変わるのか
今回押さえるべき変更点は、「Microsoft Sentinelのコスト削減策そのもの」だけではありません。より大きなポイントは、Microsoft Sentinelの運用場所がMicrosoft Defenderポータルへ集約されていくことを前提に、コスト管理・データ保持・検知ルール・自動化を見直す必要があることです。
Microsoftの公式情報では、Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスを使っていない顧客でも、Microsoft SentinelをDefenderポータルで利用できると説明されています。さらに、2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされなくなり、Defenderポータルのみで利用することになります。(Microsoft Learn)
つまり、いまMicrosoft Sentinelの費用を見直すなら、次の2つを同時に考える必要があります。
| 観点 | 確認すべきこと | 実務上の意味 |
|---|---|---|
| コスト最適化 | 取り込み量、価格レベル、保持期間、データレイク、DCRを見直す | 月額コストの増加要因を分解して対策できる |
| ポータル移行 | Azure portal中心の運用からDefenderポータル中心の運用へ移る | SOC運用、API、自動化、権限、手順書の見直しが必要 |
| データ管理 | Analytics tierとData lake tierの使い分けを決める | リアルタイム検知に必要なデータと長期調査用データを分離できる |
| 開発・自動化 | Microsoft Graph REST API、KQL、Logic Apps、プレイブックの影響を確認する | 既存連携やチケット起票の不具合を防げる |
重要なのは、「Defenderポータルへ移る＝コストが自動的に下がる」ではない点です。公式情報では、Defenderポータルへの移行そのものに追加コストはない一方、Microsoft Sentinelの利用量に応じた課金は通常どおり続くと説明されています。(Microsoft Learn)
影響を受ける対象者
Reduce costs for Microsoft Sentinelの更新内容は、Microsoft Sentinelを使うすべての組織に関係します。特に影響が大きいのは、次のような担当者です。
| 対象者 | 影響 | すぐ確認すべきこと |
|---|---|---|
| Azure管理者 | 課金、ワークスペース、保持期間、価格レベルの見直しが必要 | Cost Management、Log Analytics、Sentinelの価格レベル |
| セキュリティ管理者 | 検知に必要なログと不要なログを切り分ける必要がある | データコネクタ、分析ルール、インシデント運用 |
| SOCアナリスト | Defenderポータルの統合インシデントキューに運用が変わる | トリアージ手順、フィルター、エンティティ調査 |
| 開発者・SRE | API、KQL、プレイブック、チケット連携に影響が出る可能性がある | Microsoft Graph API、SecurityInsights API、Logic Apps |
| MSSP・マルチテナント運用者 | 複数ワークスペースや複数テナントの管理方法を見直す必要がある | プライマリワークスペース、マルチテナント管理、権限設計 |
特に、Azure portalでMicrosoft Sentinelを日常的に操作している組織は、2027年3月31日を待たずにDefenderポータルでの運用検証を始めるべきです。移行直前にまとめて対応すると、分析ルール、自動化、運用手順、権限の差分確認が重なり、SOC業務に影響しやすくなります。(Microsoft Learn)
コスト削減で最初に見るべきは「何に課金されているか」
Microsoft Sentinelのコスト削減で失敗しやすいのは、いきなりログを削ることです。まずは、どのソリューション、どのテーブル、どのデータ型が課金対象になっているかを確認します。
Microsoft SentinelのコストはAzure請求全体の一部であり、Azureサブスクリプション内のほかのAzureサービスやパートナーサービスも請求対象になります。Microsoft Sentinelだけを見ても、分析、Log Analytics、データレイク、保持、Logic Apps、Azure Functionsなどが別のコスト要因になる場合があります。(Microsoft Learn)
Cost Managementで日次コストを見る
Azure portalのCost Managementでは、Microsoft Sentinel関連のコストを日次、月次、予算、予測コストなどで確認できます。Microsoft Sentinel関連だけを確認したい場合は、サービス名で「Sentinel」「Log Analytics」「Azure Monitor」をフィルターするのが実務上分かりやすい方法です。(Microsoft Learn)
確認の流れは次のとおりです。
| 手順 | 操作 | 見るポイント |
|---|---|---|
| 1 | Azure portalでCost Management + Billingを開く | 対象のサブスクリプションまたはリソースグループを選ぶ |
| 2 | Cost Analysisを開く | 日次コスト、累積コスト、月次推移を確認する |
| 3 | サービス名で絞り込む | Sentinel、Log Analytics、Azure Monitorを確認する |
| 4 | 予算と比較する | 急増日、超過傾向、予測コストを見る |
| 5 | 急増した日を特定する | 新しいコネクタ、保持期間変更、検証ログ投入の有無を確認する |
KQLで課金対象のデータ型を確認する
費用を下げるには、請求額だけでなく、どのデータが増えているかを確認する必要があります。Microsoft Learnでは、Usageテーブルを使って取り込み量を確認するKQL例が紹介されています。実務では、まずデータ型別に課金対象データ量を並べると、削減候補を見つけやすくなります。(Microsoft Learn)
Usage
| where TimeGenerated > ago(32d)
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by Solution, DataType
| sort by BillableDataGB descこの結果を見て、上位のDataTypeを次の3種類に分類します。
| 分類 | 例 | 判断 |
|---|---|---|
| リアルタイム検知に必要 | 認証、権限変更、セキュリティアラート、EDR関連 | Analytics tierに残す候補 |
| 調査・監査には必要だが即時検知は不要 | 低優先度の大量ログ、長期保管用ログ | Data lake tierやTotal retentionを検討 |
| セキュリティ用途ではない | アプリの詳細テレメトリ、性能ログ、一般運用ログ | Sentinel有効ワークスペースから分離を検討 |
「上位だから削る」のではなく、「検知・調査・監査のどれに使うか」で判断することが重要です。たとえば、認証失敗ログは量が多くても攻撃検知に必要な場合があります。一方、セキュリティ分析に使っていない運用ログが同じワークスペースに入っている場合は、削減余地が大きくなります。
価格レベルを見直す：Pay-as-you-goとCommitment tierの判断基準
Microsoft SentinelのAnalytics tierには、従量課金のPay-as-you-goと、一定量をコミットするCommitment tierがあります。公式情報では、取り込み量のパターンに合うCommitment tierを選ぶことがコスト最適化の基本として示されています。Commitment tierはいつでも増やせますが、Pay-as-you-goへ戻す、または低いCommitment tierへ下げるには31日間のコミットメント期間が終わるまで待つ必要があります。価格レベルの変更には、Microsoft Sentinelワークスペースに対するContributorまたはOwner権限が必要です。(Microsoft Learn)
| 状況 | 向いている選択肢 | 理由 |
|---|---|---|
| 毎日ほぼ一定量のログを取り込む | Commitment tier | 予測しやすく、従量課金よりコストを抑えやすい |
| 検証環境や小規模環境 | Pay-as-you-go | 固定的なコミットを避けやすい |
| ログ量が急増中 | まず31日程度の推移を確認 | 一時的な増加で高いtierへ上げると無駄が出る |
| すでに100GB/日以上が安定している | Commitment tierや専用クラスターを検討 | 複数ワークスペースの集約効果が出る可能性がある |
価格レベルは、Microsoft Sentinelの左ナビゲーションからSettingsを開き、Pricingタブで確認できます。現在の価格レベルはCurrent tierとして表示されます。(Microsoft Learn)
価格レベル変更で失敗しやすいポイント
Commitment tierは「上げるのは簡単、下げるのはすぐにはできない」と考えておくべきです。たとえば、インシデント対応や検証で一時的にログ量が増えたタイミングだけを見て上位tierへ変更すると、その後ログ量が戻ったときに余剰が出ます。
実務では、次の基準で判断すると安全です。
| チェック項目 | 判断基準 |
|---|---|
| 直近31日間の平均取り込み量 | Commitment tierの基準に近いか |
| 最大値ではなく中央値 | 一時的なピークに引きずられていないか |
| 新規コネクタ追加予定 | 追加後の増加分を見込んでいるか |
| ログ削減施策の予定 | DCRや保持期間見直し後に再計算しているか |
| 月末だけの増加 | バッチ処理や監査処理による一時増ではないか |
Pre-purchase planは安定利用が見えてから検討する
Microsoft Sentinelでは、Microsoft Sentinel commit units（CU）を事前購入することで、Analytics tierのコスト削減につなげられます。公式情報では、事前購入したCUは1年間の購入期間中に利用でき、対象となるMicrosoft Sentinelコストから自動的に差し引かれるため、ワークスペースへ再デプロイしたり割り当てたりする必要はないと説明されています。(Microsoft Learn)
ただし、Pre-purchase planは「先に買えば安心」というものではありません。次の条件を満たす場合に検討するとよいでしょう。
| 検討に向いている状況 | 理由 |
|---|---|
| 本番環境の利用量が安定している | 事前購入分を使い切る見込みを立てやすい |
| 複数ワークスペースでSentinel利用が定着している | 組織全体で費用計画を立てやすい |
| 年間予算が確定している | 予算消化とコスト削減を両立しやすい |
| ログ削減施策を実施済み | 不要なログに対して事前購入枠を使う無駄を避けられる |
逆に、検証段階、ログ設計の見直し中、Defenderポータル移行前で運用が固まっていない段階では、先に取り込み量の可視化と削減を進める方が安全です。
セキュリティ以外のデータは別ワークスペースへ分離する
Microsoft Sentinelは、Microsoft Sentinelが有効化されたLog Analyticsワークスペースに取り込まれたデータを分析します。そのため、セキュリティ運用に使わないデータを同じワークスペースに入れると、Sentinelのコスト増加につながります。公式情報でも、非セキュリティの運用データは別ワークスペースに分けることが推奨されています。(Microsoft Learn)
分離を検討すべきデータの例は次のとおりです。
| データ | Sentinelワークスペースに入れるべきか | 判断のポイント |
|---|---|---|
| 認証ログ | 多くの場合必要 | 不正ログイン、権限昇格、横展開の検知に使う |
| EDRやDefenderアラート | 多くの場合必要 | インシデント相関や調査に使う |
| アプリケーション性能ログ | 原則として分離を検討 | セキュリティ分析に使わないなら別ワークスペースが適切 |
| CI/CDの詳細ログ | 用途次第 | サプライチェーン攻撃検知に使うなら残す、単なる実行履歴なら分離 |
| 監査目的の長期保存ログ | tierの見直しを検討 | 即時検知不要ならData lakeやTotal retentionを検討 |
ここで大切なのは、部門ごとの都合だけでワークスペースを決めないことです。運用監視チームが使うログとSOCが使うログを同じ場所に入れると、後から「どれがセキュリティ上必要なのか」を切り分けにくくなります。
Microsoft Sentinel data lakeを使い、リアルタイム検知と長期保管を分ける
Microsoft SentinelのAnalytics tierは、継続的なリアルタイム脅威検知に向いています。一方、Microsoft Sentinel data lakeは、リアルタイム検知に必ずしも必要ではない二次的なセキュリティデータのクエリや分析に向いており、取り込みや保管を低コストにできる選択肢として説明されています。(Microsoft Learn)
実務では、次のように使い分けます。
| データの性質 | 推奨される扱い | 理由 |
|---|---|---|
| 分析ルールで即時検知に使うログ | Analytics tier | 検知遅延や検知漏れを避ける |
| 調査時にだけ見る大量ログ | Data lake tierを検討 | 常時分析の必要が低い |
| 監査・証跡として長期保持するログ | Total retentionを検討 | 長期保管コストを抑えやすい |
| 価値が低く、調査でも使わないログ | 取り込み停止や分離を検討 | 保管先を変えてもコスト削減効果が薄い |
Microsoft Sentinelでは、Analytics tierのデータは既定で最初の90日間保持されます。古いデータはリアルタイム分析での価値が下がる一方、履歴調査や監査では必要になることがあります。そのため、Data management > TablesからAnalytics retentionとTotal retentionを調整し、必要なデータだけを適切な期間保持する設計が重要です。(Microsoft Learn)
Data lake tierのコスト管理はDefenderポータル側も確認する
2026年5月14日更新の管理・監視情報では、Microsoft DefenderポータルのMicrosoft Sentinel > Cost managementに、Data lake tierの利用量を管理・監視する新しいコスト管理体験がプレビューとして示されています。このページへアクセスするには、Billing AdministratorとSecurity Administratorの両方のロールが必要です。(Microsoft Learn)
Data lake tierでは、次のような使い方に注意が必要です。
| 機能 | 注意点 |
|---|---|
| Data lake query | クエリでスキャンしたデータ量がコストに影響する |
| Advanced data insights | Notebookやジョブの実行がコスト要因になる |
| しきい値通知 | 想定外の利用増を検知するために設定する |
| Enforcement | 超過後の利用ブロックに使えるが、反映はリアルタイムではない |
公式情報では、Data Lake QueryとAdvanced Data Insightsに対して、しきい値超過後に将来のクエリ、ジョブ、セッションを失敗させるEnforcementを有効化できると説明されています。ただし、Enforcementはリアルタイムではなく、しきい値到達後に反映まで最大4時間かかる場合があります。(Microsoft Learn)
Windows Security EventsはDCRで「必要なイベントだけ」取り込む
Windows Security Events connectorでは、Azure Monitor Agentとデータ収集ルール（DCR）を使って、どのイベントを収集するかを定義できます。公式情報では、All events、Minimal、Commonといった定義済みセットに加えて、カスタムフィルターを使って特定のイベントだけを取り込めると説明されています。Azure Monitor Agentはソース側でフィルターし、選択したイベントだけを取り込むため、コスト最適化に有効です。(Microsoft Learn)
DCR見直しの考え方は次のとおりです。
| 見直し項目 | 実務上の判断 |
|---|---|
| All eventsを使っているか | 本当に全イベントが検知・調査に必要か確認する |
| Minimal/Commonで足りるか | 検知ルールや調査要件と照合する |
| カスタムフィルターを使えるか | 大量発生する低価値イベントを抑えられるか確認する |
| サーバー群ごとの差分 | ドメインコントローラー、業務サーバー、検証機でルールを分ける |
| 変更後の検知影響 | 分析ルール、ワークブック、ハンティングクエリが壊れないか確認する |
特に避けたいのは、「念のため全部取り込む」という設計です。セキュリティログは一度増え始めると、ワークスペース、保持、クエリ、アラート、調査時間のすべてに影響します。DCRは、単なるコスト削減ではなく、SOCが見るべきノイズを減らすための設計として扱うべきです。
Log Analytics dedicated clusterは100GB/日以上が目安
1つまたは同一リージョン内の複数のMicrosoft Sentinelワークスペースで少なくとも100GBのデータを取り込む場合、Log Analytics dedicated clusterへの移行を検討できます。専用クラスターでは、同じリージョン内の複数ワークスペースのデータ量を集約し、Log AnalyticsのCommitment tierを共有できます。(Microsoft Learn)
ただし、専用クラスターはコスト削減効果だけで判断すると失敗しやすい構成です。制約も確認してから進める必要があります。
| 確認項目 | 内容 |
|---|---|
| 最小規模 | 100GB/日以上の取り込みが目安 |
| リージョン | リンクするワークスペースは同一リージョンである必要がある |
| クラスター数 | リージョンおよびサブスクリプションあたり最大2つ |
| ワークスペース数 | クラスターにリンクできるワークスペースは最大1000 |
| クロスワークスペースクエリ | 専用クラスターでも単一クエリに含めるワークスペース数には上限がある |
| CMK | 既存ワークスペースをCMKクラスターへ移動することはできず、クラスター内に作成する必要がある |
| 移動 | クラスターを別のリソースグループやサブスクリプションへ移動することは現在サポートされていない |
専用クラスターは、大規模環境や複数ワークスペースを持つ組織では効果が出やすい一方、後戻りや移動に制約があります。設計段階でリージョン、ワークスペース分割、データ保持、CMK要件を一緒に確認することが重要です。
Microsoft Defenderポータル移行で確認すべき設定
Microsoft SentinelをMicrosoft Defenderポータルへ移行しても、Log Analyticsの観点では基本的なデータ収集アーキテクチャやテレメトリの流れは維持されます。既存のデータコネクタも中断なく動作し、基盤となる取り込みパイプラインやデータスキーマに変更はないと説明されています。(Microsoft Learn)
ただし、運用上は変更点が多くあります。特に管理者と開発者は、次の項目を確認してください。
データコネクタと重複取り込み
Defender製品関連のアラートは、Microsoft Defender XDR connectorから直接ストリーミングされます。ワークスペースでこのコネクタのインシデントとアラートが有効になっているか確認が必要です。また、Defender for Cloudを使っている場合、テナントベースのコネクタとレガシーのサブスクリプションベースコネクタの扱いによって、重複イベントや重複アラートを防ぐ対応が必要になります。(Microsoft Learn)
コスト削減の観点では、重複取り込みは最も避けたい状態です。同じ意味のアラートやログを複数経路で取り込むと、コストだけでなく、インシデント数、誤検知、アナリストの確認時間も増えます。
分析ルールとインシデント相関
Microsoft Sentinelの分析ルールはDefenderポータルでも利用できます。ただし、Defenderポータルでは、アラート相関やインシデント統合をDefender XDR側のエンジンが担います。Azure portalでFusion分析ルールが担っていた相関は、DefenderポータルではDefender XDRのインシデント作成・相関機能に置き換わると説明されています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 項目 | 確認内容 |
|---|---|
| 分析ルール | Defenderポータルで同じ検知意図が維持されるか |
| インシデント統合 | 複数アラートが想定どおり統合されるか |
| Fusion | Azure portal時代の前提で手順書を書いていないか |
| Custom detection rules | Defender XDRデータとSentinelデータをどう使うか |
| アラートのみ生成するルール | Defenderポータルで見える運用になっているか |
特に、インシデント名や相関結果を条件にしている運用は注意が必要です。Defenderポータルでは相関の結果として、既存のインシデント名が変わる可能性があります。
自動化ルールとプレイブック
Microsoft SentinelのプレイブックはAzure Logic Appsベースです。Defenderポータル移行後も使えますが、トリガー条件やフィールドの差分に注意が必要です。公式情報では、SecurityIncidentテーブルのDescriptionフィールドがオンボード後に含まれなくなるため、このフィールドを条件にした自動化ルールは動作しない可能性があると説明されています。また、インシデントプロバイダー名、更新者フィールド、プレイブック実行の遅延、手動実行の対応範囲にも注意が必要です。(Microsoft Learn)
自動化の確認表は次のようになります。
| 確認対象 | 失敗しやすいポイント | 対応 |
|---|---|---|
| インシデントタイトル条件 | 相関で名前が変わる可能性がある | 分析ルール名やタグで条件指定する |
| Description条件 | オンボード後に使えない可能性がある | 別フィールドやタグへ置き換える |
| 外部チケット連携 | 説明文が欠落する可能性がある | ServiceNowなどの連携項目を再マッピングする |
| 手動プレイブック実行 | アラートやエンティティへの手動実行が未対応の場合がある | インシデント単位での運用に変更する |
| 実行遅延 | インシデント同期や転送に時間がかかる場合がある | 即時実行前提のSLAを見直す |
API連携はMicrosoft Graph REST APIを確認する
Defenderポータルの統合エクスペリエンスでは、インシデントやアラート関連の自動化にMicrosoft Graph REST API v1.0を使えます。一方、分析ルールや自動化ルールなどMicrosoft Sentinelリソースへの操作では、Microsoft Sentinel APIも引き続き使われます。公式情報では、統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨されています。(Microsoft Learn)
開発者が確認すべき代表的な差分は次のとおりです。
| 項目 | Azure portal中心の運用 | Defenderポータル中心の運用 |
|---|---|---|
| インシデントURL | incidentUrlを使うことが多い | providerIncidentUrlも確認する |
| プロバイダー名 | Azure Sentinel前提の処理がある可能性 | Microsoft XDRとして扱われる |
| アラート取得 | 既存のSecurityInsights API中心 | Microsoft Graphでalerts展開が必要な場合がある |
| チケット連携 | 旧フィールドに依存しがち | レスポンスボディの差分確認が必要 |
| 自動化条件 | 旧ポータルの値を前提にしがち | Defenderポータルで返る値に合わせる |
移行時は、本番API連携をいきなり切り替えるのではなく、代表的なインシデントを使って、URL、プロバイダー名、アラート名、重大度、ステータス、コメント、タグが期待どおり連携されるか確認してください。
管理者が確認すべき権限
コスト削減施策では、価格レベル、Cost Management、Defenderポータル、Data lake tierのコスト管理など、複数の権限が関係します。権限不足のまま作業を始めると、画面は見えるが変更できない、コストは見えるがしきい値を設定できない、といった問題が起きます。
| 作業 | 必要な権限の目安 |
|---|---|
| Microsoft Sentinelの価格レベル変更 | 対象ワークスペースのContributorまたはOwner |
| Cost Managementでコスト分析 | 対象スコープへの少なくとも読み取りアクセス |
| Data lake tierのコスト管理ページ | Billing AdministratorとSecurity Administrator |
| データコネクタ変更 | Sentinelや関連サービスに対する管理権限 |
| DCR変更 | Azure Monitor Agent、DCR、対象リソースへの管理権限 |
| 自動化・プレイブック変更 | Sentinel、Logic Apps、接続先サービスの権限 |
特にData lake tierのコスト管理ページは、課金管理者だけでも、セキュリティ管理者だけでも不十分です。事前にロール設計を確認しておくと、移行作業やコスト監視設定が滞りにくくなります。(Microsoft Learn)
コスト削減を進める実践手順
Microsoft Sentinelのコスト削減は、一度にすべて変えるより、影響を測りながら段階的に進める方が安全です。次の順序で進めると、検知品質を落とさずに改善しやすくなります。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | Cost Managementで日次・月次コストを確認 | コスト増加の時期と対象サービス |
| 2 | KQLでBillableDataGBをDataType別に確認 | 課金対象データの上位一覧 |
| 3 | データを用途別に分類 | リアルタイム検知、調査、監査、不要の分類表 |
| 4 | 価格レベルを見直す | Pay-as-you-goまたはCommitment tierの判断 |
| 5 | DCRとコネクタを調整 | 不要な取り込みや重複取り込みの削減 |
| 6 | 保持期間とData lake tierを設計 | 長期保管コストの最適化 |
| 7 | 予算・アラート・しきい値を設定 | 想定外コストの早期検知 |
| 8 | Defenderポータル移行の影響を検証 | 自動化、API、SOC手順書の更新 |
実務では、まず「コスト削減対象リスト」を作ると進めやすくなります。
| 対象 | 現状 | 対応案 | リスク | 優先度 |
|---|---|---|---|---|
| Windows Security Events | All eventsで大量取り込み | DCRでCommonまたはカスタムへ | 一部検知ルールに影響 | 高 |
| アプリ性能ログ | Sentinelワークスペースへ投入 | 別ワークスペースへ分離 | SOC調査で参照できなくなる | 中 |
| 長期監査ログ | Analytics tierで長期保持 | Total retentionやData lake tierへ | クエリ方法が変わる | 高 |
| Defender for Cloudアラート | 複数コネクタで取り込み | 重複経路を整理 | 設定ミスで欠落の可能性 | 高 |
| プレイブック | Description条件を使用 | 条件をタグや分析ルール名へ変更 | チケット連携の修正が必要 | 高 |
変更前に確認すべき注意点
コスト削減は、セキュリティ品質とトレードオフになる場合があります。次の注意点は、展開前に必ず確認してください。
ログを減らす前に検知ルールとの依存関係を見る
あるテーブルを削減・移動した結果、分析ルール、ハンティングクエリ、ワークブックが期待どおり動かなくなることがあります。特に、SOCが日常的に使っているワークブックやKQLは、担当者以外が把握していないこともあります。
変更前に確認する項目は次のとおりです。
| 確認項目 | 理由 |
|---|---|
| 分析ルールが参照しているテーブル | 検知漏れを防ぐため |
| ワークブックが参照しているテーブル | ダッシュボード破損を防ぐため |
| プレイブックが参照しているフィールド | 自動化失敗を防ぐため |
| 外部チケット連携の項目 | インシデント情報の欠落を防ぐため |
| ハンティングクエリ | 調査手順の劣化を防ぐため |
無料データと有料データを混同しない
Microsoft Sentinelには、Azure Activity Logs、Microsoft Sentinel Health、Office 365 Audit Logs、各種Microsoft Defender製品のセキュリティアラートなど、無料データソースとして扱われるものがあります。一方で、Microsoft Defender XDR、Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Appsなどに関連する一部の生ログは有料になる場合があります。(Microsoft Learn)
「Defender関連だから無料」とまとめて判断すると危険です。アラートは無料でも、生ログや追加データ型は課金対象になる可能性があります。データコネクタで無料・有料のデータ型を選べる場合は、どのデータ型を有効化するかを明示的に確認してください。
Defenderポータルでは一部の表示場所が変わる
Microsoft Sentinelの機能はDefenderポータルに統合されますが、Azure portalと同じ場所に同じ名称で表示されるとは限りません。たとえば、インシデントはDefenderポータルのInvestigation & response配下、データコネクタや分析ルールはMicrosoft Sentinel配下のConfigurationで扱うなど、ナビゲーションの違いがあります。(Microsoft Learn)
移行時には、次のような運用ドキュメントを更新しておくと混乱を防げます。
| ドキュメント | 更新内容 |
|---|---|
| SOC一次対応手順 | インシデント確認場所、フィルター、担当割り当て |
| 分析ルール変更手順 | Defenderポータルでの設定場所 |
| データコネクタ手順 | 表示されるコネクタと表示されないコネクタ |
| プレイブック実行手順 | 手動実行できる対象とできない対象 |
| API連携仕様書 | Microsoft Graph APIとSentinel APIの使い分け |
よくある疑問
Defenderポータルへ移行すればMicrosoft Sentinelのコストは下がるのか
移行そのものが直接のコスト削減策ではありません。公式情報では、Defenderポータルへの移行に追加コストはないと説明されていますが、Microsoft Sentinelの利用量に応じた課金は継続します。コストを下げるには、取り込み量、価格レベル、保持期間、データレイク、DCR、重複取り込みを見直す必要があります。(Microsoft Learn)
まず何から始めればよいか
最初にCost ManagementとUsageテーブルで、課金対象のデータ量を確認します。次に、DataType別に「リアルタイム検知に必要」「調査・監査用」「不要または分離可能」に分類します。いきなり価格レベルを変えるより、不要な取り込みや重複を減らしてからCommitment tierを判断する方が安全です。
Data lake tierへ移せば何でも安くなるのか
Data lake tierは、リアルタイム検知に不要な二次的データや長期保管データに向いています。ただし、クエリやNotebookなどの使い方によって別のコストが発生します。DefenderポータルのCost managementで利用量、しきい値、Enforcementを確認し、想定外の利用増を防ぐ設計が必要です。(Microsoft Learn)
開発者は何を確認すべきか
API連携、プレイブック、外部チケット連携、KQL、Advanced huntingの差分を確認してください。統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨され、Microsoft Sentinel APIは分析ルールや自動化ルールなどのSentinelリソース操作で引き続き使われます。既存コードがproviderName、incidentUrl、Description、インシデントタイトルに依存している場合は、移行前にテストが必要です。(Microsoft Learn)
まとめ：次に取るべき行動
Reduce costs for Microsoft Sentinelの要点は、単純なログ削減ではなく、データの価値に応じて取り込み、分析、保持、調査の場所を分けることです。Microsoft Defenderポータルへの移行が進む中で、コスト削減と運用移行は別々に考えるのではなく、同じプロジェクトとして進める方が安全です。
まずは次の5つを実行してください。
- Cost ManagementでSentinel、Log Analytics、Azure Monitorのコスト推移を確認する
- UsageテーブルでBillableDataGBをDataType別に集計する
- 不要なログ、重複取り込み、セキュリティ以外のデータを洗い出す
- DCR、保持期間、Data lake tier、価格レベルを順に見直す
- Defenderポータル移行に向けて、API、自動化、SOC手順書を検証する
特にAzure portal中心でMicrosoft Sentinelを運用している組織は、2027年3月31日を期限としてではなく、今から段階的に移行検証を始めるべきです。コストを下げながら検知品質を維持するには、「何を減らすか」よりも「何を残すべきか」を明確にすることが最も重要です。
コメント