Microsoft DefenderでMicrosoft Sentinelを運用している管理者がまず押さえるべき結論は、Microsoft Sentinelのログ取り込みはLog Analyticsワークスペースを基盤とし、カスタムデータ取り込みや取り込み時変換はDCR（Data Collection Rules）とLogs ingestion APIを中心に設計・管理する流れが強まっているという点です。
2026年5月末に更新された公式情報では、Microsoft Sentinelの「Custom data ingestion and transformation in Microsoft Sentinel」について、カスタム形式のログを取り込む方法、KQLによる取り込み前の変換、Defenderポータル上でのFilter/Split変換、コネクタ種別ごとのDCR対応範囲が整理されています。Microsoft Learn上の英語ページでは「Last updated on 2026-05-28」と表示されていますが、日本時間や配信タイミングでは2026年5月29日更新情報として扱われるケースがあります。(Microsoft Learn)
この記事では、Microsoft Defender管理者・SOC運用担当者・Microsoft Sentinel連携を開発する担当者向けに、何が変わるのか、どの環境に影響するのか、移行や展開前にどの設定を確認すべきかを実務目線で整理します。
Custom data ingestion and transformation in Microsoft Sentinelとは
Custom data ingestion and transformation in Microsoft Sentinelは、Microsoft Sentinelに取り込むログを、保存前に整形・フィルター・正規化・拡張するための考え方と機能群です。
Microsoft Sentinelに取り込まれるログは、Log Analyticsワークスペースに保存されます。脅威検出、調査、監視ではKQL（Kusto Query Language）を使ってログを検索します。そのため、ログを保存してから毎回複雑なKQLで整形するのではなく、取り込み時点で必要な形に近づけることが重要になります。(Microsoft Learn)
たとえば、次のようなケースで役立ちます。
| 利用シーン | 取り込み時変換でできること | 実務上のメリット |
|---|---|---|
| ファイアウォールログが多すぎる | 低重要度のallowイベントを除外する | SOCが見るべきイベントを減らし、調査効率を上げる |
| 独自アプリのJSONログをSentinelに入れたい | Logs ingestion APIでカスタムテーブルへ送信する | 標準コネクタがないシステムも監視対象にできる |
| ログ形式が製品ごとに違う | ASIMなどのスキーマに近づける | 分析ルールやハンティングクエリを再利用しやすい |
| 個人情報や機密項目を保存したくない | 取り込み前にマスク・削除する | 保存後のアクセス制御だけに頼らずリスクを下げられる |
| 長期保管は必要だが高速検索は不要 | Split変換でAnalytics層とData lake層に振り分ける | コストと検索性能のバランスを取りやすい |
ポイントは、これは単なるログ転送機能ではないということです。「どのログを、どの形で、どのテーブルに、どの保存層へ入れるか」を設計するためのデータパイプライン管理と考えると理解しやすくなります。
今回の更新で押さえるべき変更点
今回の公式情報で特に重要なのは、DCR、Logs ingestion API、DefenderポータルでのFilter/Split変換の位置付けが明確になったことです。
DCRがカスタム取り込みと変換の中心になる
DCRは、Azure Monitorのデータ収集フローを制御するルールです。Microsoft Sentinelでは、AMA（Azure Monitor Agent）ベースのコネクタやLogs ingestion APIを使うワークフローでDCRが利用されます。DCRには、どのデータをどこへ送るかだけでなく、保存前に実行する変換処理も含められます。(Microsoft Learn)
実務では、次のような設計判断が必要になります。
| 判断項目 | 確認すること |
|---|---|
| どのDCRが使われるか | AMA用DCR、Logs ingestion APIで指定するDCR、Workspace transformation DCRのどれか |
| どのテーブルへ出力するか | 標準テーブルか、カスタムテーブルか |
| 変換はどこで行うか | DCR内のKQL変換か、DefenderポータルのFilter/Splitか |
| 複数の変換が重ならないか | 既存DCR、Workspace transformation DCR、Filter/Splitの組み合わせ |
| 変更後に検出ルールが壊れないか | Analytics rule、Workbook、Hunting query、Parser、Playbookの参照先 |
DCRを「裏側の設定」として扱うのではなく、Sentinel運用の構成管理対象としてレビューする必要があります。
Logs ingestion APIがカスタムログ取り込みの軸になる
Logs ingestion APIは、任意のデータソースからカスタム形式のログをLog Analyticsワークスペースへ送るためのAPIです。標準テーブルまたはカスタムテーブルにログを格納でき、列名や型を含めたスキーマ設計を管理できます。公式情報では、このAPIがDCRを使ってデータフローに変換を定義・適用すると説明されています。(Microsoft Learn)
特に、従来のHTTP Data Collector APIを使っている環境では注意が必要です。Microsoft Learnでは、HTTP Data Collector APIは非推奨化の流れにあり、サポート終了日が2026年9月14日と案内されています。既存の取り込み自体は継続するとされていますが、APIは重要なセキュリティ修正に限定されるため、新規設計や改修ではLogs ingestion APIへの移行を前提にすべきです。(Microsoft Learn)
DefenderポータルでFilter/Split変換を扱う流れが強まる
今回の内容で管理者が特に確認したいのが、Filter and split transformationsです。これは、データ取り込み時に不要なデータを除外したり、Analytics層とData lake層へ振り分けたりする機能です。
公式情報では、Filter/Split変換はDCRを手動作成しなくても、Microsoft Sentinelのテーブル管理ページからDefenderポータル上で定義できるとされています。(Microsoft Learn)
| 変換 | 役割 | 向いているケース |
|---|---|---|
| Filter | 条件に一致するデータを取り込まずに破棄する | 調査に使わない低価値ログを減らしたい |
| Split | 条件に応じてAnalytics層とData lake層へ振り分ける | 高速検索したいログと長期保管したいログを分けたい |
| DCR内のKQL変換 | 列の追加、整形、マスク、正規化などを行う | カスタムログや複雑なスキーマ変換を管理したい |
Filterは強力ですが、条件に一致したデータはAnalytics層にもData lake層にも取り込まれません。つまり、あとから「やはり必要だった」と思っても、取り込まれていないデータはSentinel側で復元できません。公式ドキュメントでも、Filter条件に一致したデータは破棄されるため、KQL式が除外したいデータを正確に捉えていることを確認するよう注意されています。(Microsoft Learn)
影響を受ける対象者
今回の更新は、Microsoft Defenderポータルを使うSOCだけでなく、Microsoft Sentinelのデータ基盤を設計・保守する複数の担当者に関係します。
| 対象者 | 影響 |
|---|---|
| Microsoft Defender管理者 | Defenderポータル上でSentinelのテーブル、保持、Filter/Split変換を確認する必要がある |
| Microsoft Sentinel管理者 | DCR、Log Analyticsワークスペース、データコネクタ、テーブル設計の見直しが必要 |
| SOCアナリスト | 取り込み時点で除外・分割されたデータにより、検索結果や調査範囲が変わる |
| セキュリティエンジニア | Analytics rule、Hunting query、Workbook、Parserへの影響確認が必要 |
| 開発者・SRE | 独自アプリや外部SaaSのログ送信方式をLogs ingestion APIへ寄せる判断が必要 |
| コスト管理担当者 | Analytics層とData lake層の使い分け、不要ログ削減による費用最適化を評価する必要がある |
特に影響が大きいのは、次のような環境です。
- Azure Functionsベースの独自Sentinelコネクタを使っている
- HTTP Data Collector APIでカスタムログを送っている
- Syslog、CEF、Windows Security EventsをAMA経由で大量に取り込んでいる
- Microsoft 365、Microsoft Entra ID、Amazon S3などサービス連携ログをSentinelで分析している
- Log Analyticsの取り込み量が増え、コスト削減を検討している
- Azureポータル中心のSentinel運用からDefenderポータルへ移行中である
Microsoft SentinelはDefenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもDefenderポータル上で利用できると案内されています。また、2025年7月以降にSentinelへオンボードする多くの新規顧客は、Defenderポータルへ自動的にオンボードされる場合があります。(Microsoft Learn)
コネクタ種別ごとに確認すべきDCR対応
Microsoft Sentinelのデータ取り込みは、コネクタ種別によってDCRの使われ方が異なります。ここを誤解すると、「DCRを編集したのに変換が効かない」「Workspace transformation DCRの影響で想定外のデータが落ちる」といったトラブルにつながります。
| データコネクタ種別 | DCR対応の考え方 | 確認ポイント |
|---|---|---|
| AMAログ（Windows Security Events via AMA、CEF、Syslogなど） | エージェントに関連付いた1つ以上のDCRで処理 | 対象マシン、DCR関連付け、変換KQLを確認 |
| Logs ingestion APIによる直接取り込み | API呼び出しで指定したDCRを使用 | DCR ID、DCEまたはDCR ingestion endpoint、認証権限を確認 |
| Codeless data connectorsなどの組み込みAPIベース | コネクタ用に作成されるDCRを使用 | コネクタ作成時のDCRと出力テーブルを確認 |
| Diagnostic settingsベースの接続 | 対応テーブルではWorkspace transformation DCRを使用 | テーブルが変換対応か確認 |
| Legacy codeless data connectors、Azure Functionsベースのコネクタ | 現時点ではサポート対象外として整理 | 移行計画、代替コネクタ、参照クエリを確認 |
| Microsoft Office 365、Microsoft Entra ID、Amazon S3などサービス間連携 | 対応テーブルではWorkspace transformation DCRを使用 | テーブル単位で変換対応を確認 |
公式情報では、Legacy codeless data connectorsやAzure Functions-based data connectorsはDCRサポートが「Not currently supported」と整理されています。既存のAzure Functionsベース実装を使っている場合は、変換機能を前提にした設計へそのまま載せ替えられるとは限りません。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft DefenderまたはMicrosoft Sentinelの管理者は、いきなりFilterやDCRを変更する前に、現在の取り込み構成を棚卸しする必要があります。特に本番環境では、データ量削減より先に「検出に必要なログを落とさない」ことを優先してください。
SentinelワークスペースがDefenderポータルに接続されているか
Filter/Split変換をDefenderポータルで扱うには、Microsoft SentinelワークスペースがDefenderポータルにオンボードされている必要があります。Filter/Split変換の前提条件として、Microsoft SentinelワークスペースがDefenderポータルにオンボードされていること、Unified RBACでData operationsのData manage権限があること、Log Analyticsワークスペースに対する書き込み権限があることが示されています。(Microsoft Learn)
確認する場所の例は次のとおりです。
| 確認項目 | 見る場所 |
|---|---|
| Defenderポータル接続 | Microsoft Defender portal > System > Settings > Microsoft Sentinel |
| Sentinel設定 | Microsoft Defender portal > Microsoft Sentinel |
| テーブル管理 | Microsoft Sentinel > Configuration > Tables |
| DCR | Azure portal > Monitor > Data Collection Rules |
| Log Analyticsテーブル | Log Analytics workspace > Tables |
Microsoft Sentinelは、2027年3月31日以降Azureポータルではサポートされず、Defenderポータルのみで利用可能になると案内されています。まだAzureポータル中心で運用している組織は、データ変換の見直しとあわせてポータル移行計画も進めるべきです。(Microsoft Learn)
どのテーブルが変換対象か
すべてのテーブルで同じ変換ができるわけではありません。Filter/Split変換は、DCRをサポートするテーブルで利用する前提です。Splitについては、Analytics only ingestion、Data lake only ingestion、DCRをサポートするテーブルが対象とされています。(Microsoft Learn)
確認時は、次の順番で見ていくと安全です。
| 手順 | 確認内容 |
|---|---|
| 1 | データコネクタ参照で対象コネクタのDCR supportを確認する |
| 2 | 対象テーブルがDCR対応か確認する |
| 3 | 既存のDCRまたはWorkspace transformation DCRを確認する |
| 4 | DefenderポータルのTables画面でFilter/Splitルールの有無を確認する |
| 5 | 変更後にAnalytics ruleやWorkbookが参照する列が残るか確認する |
「このログは多いから削る」という判断だけでFilterを入れると、インシデント調査時に必要な周辺ログまで消してしまうことがあります。まずは過去30〜90日程度のアラート、ハンティング、ワークブック、監査要件で使われている列とイベント種別を洗い出すのが現実的です。
権限が最小権限になっているか
DCRやテーブル設定の変更は、ログの可視性そのものを変える操作です。権限を広く付けすぎると、意図しないFilterルールで重要なログが取り込まれなくなるリスクがあります。
最低限、次を分けて管理することをおすすめします。
| 操作 | 推奨される管理方針 |
|---|---|
| ログ閲覧 | Sentinel Readerなど読み取り中心 |
| 調査・インシデント対応 | Sentinel Contributor相当の範囲を必要最小限に |
| テーブル・DCR変更 | 限られたプラットフォーム管理者に限定 |
| API取り込み | アプリIDまたはマネージドIDにDCR単位で権限付与 |
| 本番反映 | Pull request、変更申請、検証ログの添付を必須化 |
DCRベースのLogs ingestion APIでは、Microsoft Entra IDによるOAuth認証とDCRスコープのRBACが使われます。従来の共有キー的な運用から、IDと権限を分けて管理できる点は大きな改善です。(Microsoft Learn)
開発者が確認すべき移行ポイント
独自ログ連携を開発・保守している担当者は、HTTP Data Collector API、Azure Functionsベースの古いコネクタ、カスタムテーブルのスキーマを重点的に確認してください。
HTTP Data Collector APIを使っていないか
HTTP Data Collector APIを使っている場合は、Logs ingestion APIへの移行計画を立てる必要があります。公式ドキュメントでは、2026年3月1日に古いTLSバージョンの受付が停止され、2026年9月14日にData Collector APIが非推奨になるとされています。TLS 1.2以降に対応していないクライアントは、移行時期に関係なく取り込みに失敗する可能性があります。(Microsoft Learn)
確認すべき箇所は次のとおりです。
| 確認対象 | 見るべきポイント |
|---|---|
| 送信コード | Data Collector APIのエンドポイントやSharedKey署名を使っていないか |
| カスタムテーブル | Custom table (classic) になっていないか |
| レコード | SourceSystem が RestAPI のデータがあるか |
| スキーマ | _s、_d、_t など旧API由来の列サフィックスがあるか |
| TLS | クライアントがTLS 1.2以降で通信できるか |
移行時は、既存テーブルを変換する方法と、新しいテーブルを作って段階的に切り替える方法があります。Microsoft Learnでは、既存テーブルを移行してもロールバックできない点や、Data Collector APIを継続利用しながらスキーマ変更するとレガシー取り込みが壊れる可能性がある点が注意されています。(Microsoft Learn)
DCRのtransformKqlをテストしてから反映する
Azure Monitorの変換クエリは、source という仮想テーブルから始めます。既存テーブルに対してKQLを試し、期待した出力になったら、テーブル名を source に置き換えてDCRへ反映するのが基本です。変換の出力はターゲットテーブルのスキーマに合わせる必要があり、TimeGenerated は datetime 型の有効な列として含める必要があります。(Microsoft Learn)
たとえば、Syslogのinfoレベルを除外したい場合、Log Analyticsでは次のようにテストします。
Syslog
| where SeverityLevel != "info"DCRに入れる場合は、入力ストリームを表す source に置き換えます。
source
| where SeverityLevel != "info"ただし、変換で使えるKQL機能には制限があります。普段のLog Analyticsクエリで動くKQLが、そのままDCR変換で使えるとは限りません。また、JSONを直接編集する場合、transformKql は1行で設定する必要があります。ポータルでは複数行で見やすく編集できますが、JSONを手作業で扱うと改行や余分な空白が原因で失敗することがあります。(Microsoft Learn)
スキーマ変更が検出ルールに与える影響を確認する
Logs ingestion APIへ移行すると、テーブル名や列名、列型、正規化方法が変わる場合があります。Microsoft Learnでは、Sentinelコネクタの移行時にAnalytics rules、Hunting queries、Workbooks、Playbooks、Parsersなど依存する成果物を更新する必要があると説明されています。(Microsoft Learn)
移行前に、少なくとも次を確認してください。
| 成果物 | 確認内容 |
|---|---|
| Analytics rule | 参照テーブル、列名、where条件、entity mapping |
| Hunting query | 旧テーブル名や旧列サフィックスを使っていないか |
| Workbook | 可視化パネルのKQLが新スキーマで動くか |
| Parser | ASIMや独自関数の入力列が変わらないか |
| Playbook | アラート本文やカスタム詳細のキー名が変わらないか |
| Watchlist連携 | join条件に使う列名・型が変わらないか |
特に危険なのは、「取り込みは成功しているが、検出ルールが空振りしている」状態です。移行後は、データ件数だけでなく、既存のアラートが想定どおり発火するかまで確認してください。
Filter/Split変換を使うときの注意点
Filter/Split変換は、コスト最適化とノイズ削減に効果があります。しかし、本番での扱いを誤ると、調査に必要なログが欠落します。
Filterは削除ではなく「未取り込み」と考える
Filter変換では、KQL条件に一致したデータが取り込まれません。たとえば、ファイアウォールログのうちroutineなallowイベントを除外する条件を設定すれば、Analytics層のデータ量を削減できます。
ただし、攻撃の初期調査では「許可された通信」も重要になることがあります。たとえば、C2通信、横展開、データ持ち出しの調査では、blockイベントだけでなくallowイベントの時系列も必要です。
Filterを使うなら、次のような判断基準を設けると失敗しにくくなります。
| 判断基準 | Filterしてよい可能性が高い | Filterしない方がよい |
|---|---|---|
| 検出への利用 | どの検出ルールでも使っていない | Analytics ruleやNRT ruleで参照している |
| 調査への利用 | 過去のインシデント調査でほぼ使っていない | 横展開・通信追跡・証跡確認に使う |
| 代替保管 | 別の監査基盤に保管している | Sentinel以外に保存先がない |
| 条件の明確さ | 製品仕様上、明確にノイズと判断できる | 値の意味が製品やバージョンで変わる |
| 復元要件 | 復元不要と合意済み | 監査・法務・規制対応で必要になる可能性がある |
最初から大きく削るのではなく、まずはKQLで過去データを集計し、候補を可視化してからFilter条件を作るのが安全です。
SplitはAnalytics層とData lake層の役割を分ける
Split変換は、条件に一致したデータをAnalytics層へ入れ、条件に一致しないデータをData lake層のみへ送る考え方です。公式ドキュメントでは、Analytics層へ指定されたデータもData lake層へミラーされるため、すべてのデータをData lake側で長期保持・コンプライアンス用途に使えると説明されています。(Microsoft Learn)
また、SplitでData lake層へ振り分けられたデータは、元テーブル名に _SPLT が付いた別テーブルに取り込まれます。たとえば FirewallLogs にSplitを適用すると、Data lake側の分割テーブルは FirewallLogs_SPLT になります。(Microsoft Learn)
Splitは次のような使い分けに向いています。
| データ | 推奨される置き場所 | 理由 |
|---|---|---|
| 高重大度のアラート関連ログ | Analytics層 | 検出・調査で高速検索したい |
| 直近の認証ログ | Analytics層 | インシデント対応で頻繁に検索する |
| 長期保管が必要な低頻度ログ | Data lake層 | コストを抑えて保持したい |
| 監査用の大量イベント | Data lake層中心 | 日常調査では使わないが保管要件がある |
| ノイズだが完全には捨てにくいログ | SplitでData lake層へ | Filterより安全にコスト最適化できる |
「消してよい」と言い切れないデータは、FilterよりSplitを検討する方が現実的です。
変換の反映遅延を考慮する
Filter/Split変換やデータ変換設定は、即時反映されるとは限りません。Filter/Splitの公式ドキュメントでは、変換が有効になるまで最大1時間かかる場合があるとされています。また、XDRテーブルに適用したSplit/Filter変換は、最初の30日分のデータについてAdvanced Hunting上に表示されない制限がある一方、Log AnalyticsやMicrosoft Sentinelからのクエリではコスト削減が反映されると説明されています。(Microsoft Learn)
そのため、展開後すぐに「効いていない」と判断せず、次の観点で確認してください。
| 確認項目 | 見る内容 |
|---|---|
| 反映時間 | 変更後1時間程度は様子を見る |
| Sentinel側クエリ | 対象テーブルの件数や列を確認 |
| Advanced Hunting | XDRテーブルでは表示制限の影響を考慮 |
| Cost Management | 取り込み量の傾向を日単位で確認 |
| アラート | 検出件数が異常に減っていないか確認 |
移行・展開前のチェックリスト
本番環境でCustom data ingestion and transformation in Microsoft Sentinelを扱う前に、次のチェックリストを使って確認してください。
| チェック項目 | 確認内容 |
|---|---|
| Defenderポータル移行 | 対象SentinelワークスペースがDefenderポータルに接続済みか |
| 権限 | Data manage権限、Log Analytics Contributor相当、DCR編集権限が適切か |
| コネクタ種別 | AMA、Logs ingestion API、CCF、Legacy、Azure Functionsのどれか |
| DCR対応 | 対象テーブル・コネクタがDCRやWorkspace transformation DCRをサポートするか |
| 既存変換 | 既存DCR、Workspace transformation DCR、Filter/Splitが重複しないか |
| KQLテスト | 本番適用前に既存データまたはサンプルデータで検証したか |
| スキーマ | TimeGenerated、列名、列型、予約語を確認したか |
| 依存成果物 | Analytics rule、Workbook、Parser、Playbookを確認したか |
| 移行方式 | 既存テーブル移行か、新テーブル併用かを決めたか |
| ロールバック方針 | 変更前DCR、KQL、テーブル設定を保存したか |
| 監視 | 展開後の取り込み件数、エラー、アラート数を確認する手順があるか |
| 監査・保持 | Filterで消すデータが監査要件に反しないか |
この中でも、特に重要なのは「既存変換の重複」と「依存成果物の確認」です。公式ドキュメントでも、Azure Monitor側で作成したDCR変換とMicrosoft Sentinel側で作成した変換が競合する可能性があると注意されています。たとえば、DCRで特定リージョン以外を通す設定をしているテーブルに、Sentinel側でそのリージョンだけを除外するFilterを重ねると、結果的にデータが取り込まれない可能性があります。(Microsoft Learn)
実務でおすすめの展開手順
いきなり本番テーブルにFilterやDCR変換を入れるのではなく、次の順番で進めると安全です。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 現状把握 | コネクタ、テーブル、DCR、API送信元を棚卸し | 取り込み構成一覧 |
| 影響分析 | 参照しているAnalytics rule、Workbook、Parserを洗い出す | 依存関係リスト |
| 候補抽出 | 削減・正規化・マスクしたいログや列を決める | 変換候補一覧 |
| 検証 | Log AnalyticsでKQLを試し、サンプルデータで確認 | テスト済みKQL |
| 段階展開 | 開発または一部テーブルでDCR/Filter/Splitを適用 | 変更済み設定 |
| 監視 | 取り込み量、検出件数、クエリエラーを確認 | 展開後レビュー |
| 標準化 | DCRテンプレート、命名規則、変更手順を整備 | 運用ルール |
小規模環境では手動設定でも始められますが、複数ワークスペースや複数テナントで運用する場合は、DCRをコード管理する方が安全です。ARMテンプレート、Bicep、Terraform、Azure CLIなどを使い、変更履歴とレビューを残せる形にしておくと、誤設定の追跡や再展開が容易になります。
よくある失敗と回避策
失敗: Filterで必要な調査ログまで消してしまう
ログ量を減らす目的でFilterを強くかけすぎると、後からインシデント調査に必要なイベントが見つからなくなります。特にネットワーク、認証、エンドポイントの「成功イベント」は、一見ノイズに見えても攻撃経路の確認に必要です。
回避策は、まずSplitでData lake層へ逃がすことです。完全に不要と判断できるまで、Filterで破棄しない方が安全です。
失敗: DCRを変更したが変換が効かない
よくある原因は、対象データがそのDCRを通っていないことです。AMAログ、Logs ingestion API、Workspace transformation DCR、組み込みコネクタでは使われるDCRが異なります。
回避策は、対象テーブルのDCR supportを確認し、どのコネクタがどのDCRを使っているかを図にすることです。
失敗: スキーマ変更でKQLが壊れる
Logs ingestion APIへ移行すると、旧API由来の列サフィックスやテーブル名が変わることがあります。これにより、既存のAnalytics ruleやWorkbookが空振りします。
回避策は、移行前後のテーブルに対して同じ検出ロジックを実行し、ヒット件数と代表レコードを比較することです。単に「データが入っている」だけでは検証として不十分です。
失敗: 本番反映後すぐに結果を判断する
変換設定には反映遅延があります。展開直後にデータ件数が想定と違っても、反映途中の可能性があります。
回避策は、変更時刻、反映確認時刻、対象テーブル、検証KQL、件数比較を記録し、最低でも1時間程度の遅延を考慮して評価することです。
まず何をすべきか
Microsoft Defender環境でMicrosoft Sentinelを運用している場合、最初にやるべきことは、新機能を試すことではありません。自社のログ取り込み経路をDCR視点で棚卸しすることです。
特に、次の3つを優先してください。
| 優先度 | やること | 理由 |
|---|---|---|
| 高 | HTTP Data Collector APIやClassic custom tableの有無を確認 | 2026年の非推奨化・移行影響が大きい |
| 高 | Defenderポータル上のSentinel接続と権限を確認 | 今後の運用画面がDefenderポータル中心になる |
| 中 | 大量ログに対してFilterではなくSplit候補を検討 | コスト削減と調査可能性を両立しやすい |
Custom data ingestion and transformation in Microsoft Sentinelは、ログの入口を整える機能です。入口で整えたデータは、検出、調査、自動化、コスト、監査に長く影響します。管理者はDCR、テーブル、コネクタ、権限を確認し、開発者はLogs ingestion APIとスキーマ移行を計画してください。最初の一歩として、現在のデータコネクタ一覧とDCR一覧を突き合わせ、どのログがどのルールでSentinelに入っているかを可視化することから始めるのが最も確実です。
コメント