Microsoft Sentinelの「Custom data ingestion and transformation」は、単にカスタムログを取り込むための機能ではありません。2026年4月22日に更新された公式ドキュメントでは、Log Analytics、DCR、Logs Ingestion API、取り込み時変換、Filter／Split変換を組み合わせ、不要なログを減らしながら検知・調査・監査に必要なデータを残す考え方が整理されています。結論として、security admins、identity teams、compliance teamsがまず確認すべきなのは「どのデータを取り込むか」ではなく、「どのデータをAnalyticsに残し、どのデータをData lakeや別テーブルに逃がし、どのデータを捨てるか」です。(Microsoft Learn)
Microsoft Sentinelの最新動向: Custom data ingestion and transformation in Microsoft Sentinelで何が変わったか
Microsoft Sentinelでは、取り込まれたログはLog Analytics workspaceに保存され、KQLを使って脅威検出や調査に利用されます。今回の公式ドキュメントで重要なのは、Azure Monitor LogsをSentinelのデータ基盤として位置づけたうえで、データ取り込み前に整形・絞り込み・分岐できる仕組みが明確に整理されている点です。(Microsoft Learn)
特に注目したいのは、次の4点です。
| 更新後に押さえるポイント | 実務上の意味 |
|---|---|
| DCRが取り込み制御の中心になる | どのログを、どのテーブルへ、どの形式で保存するかをルール化しやすい |
| Logs Ingestion APIでカスタム形式のログを標準テーブルまたはカスタムテーブルへ送れる | SaaS、独自アプリ、オンプレ機器などのログをSentinelに統合しやすい |
| 取り込み時変換でフィルター、正規化、エンリッチ、マスクが可能 | クエリ実行後ではなく、保存前にデータ品質を整えられる |
| Filter／Split変換がDefenderポータルのテーブル管理から扱える | すべてをDCRのJSONで管理しなくても、ノイズ削減やストレージ階層分けを始めやすい |
これまで「Sentinelにログを集める」ことを主目的にしていた環境では、データ量の増加によりコスト、検索性能、保持期間、個人情報の扱いが課題になりやすくなります。今回の内容は、ログを増やす運用から、ログを設計して取り込む運用へ移行するための実務的な指針と捉えるべきです。
Custom data ingestion and transformationの基本
Microsoft SentinelのCustom data ingestion and transformationは、主に次の2つを扱います。
| 機能 | 役割 | 代表的な利用シーン |
|---|---|---|
| Custom data ingestion | 任意のデータソースからログを取り込む | 独自アプリ、外部SaaS、オンプレ製品、独自形式のセキュリティログ |
| Data transformation | 保存前にログを加工する | 不要行の除外、列の削減、ASIM向け正規化、機密情報のマスク、解析用列の追加 |
Azure Monitorの変換は、Log Analytics workspaceへ保存される前のデータに対してKQLを適用します。変換クエリは入力ストリームを表すsourceから始まり、行の絞り込み、列の加工、計算列の追加などを行えます。(Microsoft Learn)
たとえば、独自の認証ログをSentinelへ送る場合、取り込み後に毎回KQLで文字列を分解するのではなく、取り込み時点でユーザー名、送信元IP、結果、リスクスコアなどの列に整形できます。これにより、分析ルールやハンティングクエリの可読性が上がり、クエリ実行時の負荷も抑えやすくなります。
DCRは「ログ取り込みの設計図」として考える
DCR、つまりData Collection Ruleは、Azure Monitorにおけるデータ収集の中心的な設定です。DCRには、収集対象、入力スキーマ、変換、送信先などの情報を定義できます。Microsoftの公式説明でも、DCRベースの収集は従来方式より一貫性があり、Infrastructure as CodeやDevOpsプロセスにも向いた構成として説明されています。(Microsoft Learn)
Sentinel運用では、DCRを単なる設定ファイルではなく「ログ取り込みの設計図」として扱うと整理しやすくなります。
| 判断項目 | 確認すべきこと |
|---|---|
| 入力元 | AMA、Logs Ingestion API、組み込みコネクタ、Diagnostic settingsなど |
| 入力形式 | JSON、Syslog、CEF、Windows Security Event、独自形式など |
| 保存先 | 標準テーブル、カスタムテーブル、ASIMの正規化テーブルなど |
| 変換内容 | フィルター、列変換、マスク、エンリッチ、正規化 |
| 管理方法 | Azureポータル、API、ARMテンプレート、IaC管理 |
security adminsにとっては、DCRを使うことで検知に不要なノイズを保存前に減らせます。identity teamsにとっては、認証・サインイン関連ログの列設計を統一しやすくなります。compliance teamsにとっては、保持すべきログと削除・マスクすべきデータの境界を明文化しやすくなります。
Logs Ingestion APIでカスタムログ統合の自由度が上がる
Logs Ingestion APIは、REST APIまたはクライアントライブラリからLog Analytics workspaceへデータを送信する仕組みです。データはサポート対象のAzureテーブル、または作成済みのカスタムテーブルに送信できます。DCRによって、入力データの構造、変換、送信先テーブルを制御します。(Microsoft Learn)
実務では、次のような場面で有効です。
| 利用シーン | 具体例 |
|---|---|
| 独自アプリのセキュリティログをSentinelに集約する | ログイン失敗、権限変更、APIキー発行、管理者操作 |
| SaaSの監査ログを取り込む | 管理者操作ログ、ファイル共有ログ、アクセス元IP |
| オンプレ製品のログを整形して送る | 物理入退室システム、独自認証基盤、古いアプライアンス |
| 標準テーブルに近い形へ変換する | 認証ログをASIMのAuthentication系スキーマに寄せる |
ただし、カスタムログを入れれば自動的に検知品質が上がるわけではありません。重要なのは、取り込む前に「どの列が分析ルールで使われるか」「どの列が調査時のピボットになるか」「どの列が個人情報や機密情報に該当するか」を決めることです。
たとえば独自認証ログなら、少なくとも以下のような観点で列を設計します。
| 列の種類 | 例 | 用途 |
|---|---|---|
| 時刻 | TimeGenerated | タイムライン調査、相関分析 |
| 主体 | UserPrincipalName、AccountId | ID単位の追跡 |
| 接続元 | SourceIpAddress、Country | 不審アクセス検知 |
| 結果 | Result、FailureReason | 失敗増加、ブルートフォース検知 |
| 操作 | Action、OperationName | 権限変更や管理操作の把握 |
| リスク情報 | RiskScore、RiskLevel | アラート優先度付け |
列名や型は後から変更すると分析ルール、Workbooks、ハンティングクエリへの影響が出やすいため、最初に小さく試し、運用チームと監査チームの双方でレビューしてから本番化するのが安全です。
Filter／Split変換は「捨てる」と「分ける」を混同しない
2026年4月更新で実務上特に見落としやすいのが、Filter変換とSplit変換の違いです。どちらも取り込み時のデータ量や保存先を制御する機能ですが、意味は大きく異なります。
| 変換 | 何をするか | 向いているケース | 注意点 |
|---|---|---|---|
| Filter | 条件に合うデータを破棄する | 明らかに調査価値がないログを減らす | 破棄したデータはAnalyticsにもData lakeにも残らない |
| Split | 条件に応じてAnalytics tierとData lake tierへ振り分ける | 調査に必要な高価値ログだけAnalyticsに残す | Analytics対象データはData lakeにもミラーされる |
Microsoft Learnでは、Filter変換は「取り込まないデータ」をKQL条件で指定し、条件に合致したデータは破棄されると説明されています。一方、Split変換はAnalyticsに入れるデータをKQL式で定義し、それ以外はData lake tierのみに送られます。(Microsoft Learn)
ここで最も多い失敗は、Filterの条件を「残したい条件」と勘違いすることです。
たとえば、ファイアウォールログで低リスクのAllowイベントを捨てたい場合、Filter条件には「捨てたいログ」を書きます。
Action == "Allow" and Severity == "Low"逆に、Splitで重大イベントだけをAnalyticsに残したい場合は、「Analyticsに残したい条件」を書きます。
Severity in ("High", "Critical") or Action == "Deny"同じKQLでも、Filterでは「trueなら捨てる」、Splitでは「trueならAnalyticsへ送る」と考える必要があります。この違いをレビュー手順に入れておかないと、必要な監査ログを失ったり、逆にコスト削減効果が出なかったりします。
どのDCRを使うべきか
Microsoft Sentinelでは、データソースの種類によってDCRの扱いが変わります。公式ドキュメントでは、AMAベースのログ、Logs Ingestion API、Codeless connector、Diagnostic settings、サービス間連携などでDCRサポートの違いが整理されています。(Microsoft Learn)
実務では、次の表で大まかに判断できます。
| データソース | 推奨される考え方 | 担当チームの主な確認事項 |
|---|---|---|
| Windows Security Events via AMA、CEF、Syslog | AMAに関連付けたDCRで制御 | 収集対象イベント、変換条件、エージェント配布範囲 |
| 独自アプリや外部システム | Logs Ingestion APIとDCRで取り込み | 入力JSON、テーブル設計、認証、DCR権限 |
| Codeless data connectors | コネクタ作成のDCRを確認 | 変換可否、出力テーブル、既存分析ルールへの影響 |
| Diagnostic settingsベース | Workspace transformation DCRを検討 | 対象テーブルが変換に対応しているか |
| Microsoft Entra ID、Microsoft Office 365、Amazon S3などのサービス間連携 | 対応テーブルではWorkspace transformation DCRを検討 | コンプライアンス要件、保持期間、監査ログの完全性 |
| Legacy codeless connectorやAzure Functionsベースの一部コネクタ | 現時点では未対応の扱いに注意 | 移行計画、代替取り込み方式、既存ルールの棚卸し |
すべてのコネクタで同じように変換できるわけではありません。新しいログソースを追加する前に、対象テーブルが取り込み時変換に対応しているか、既存のDCRやWorkspace transformation DCRと競合しないかを確認してください。
Security adminsが見るべきポイント
security adminsにとって最大のメリットは、SOCのノイズを保存前に減らせることです。たとえば、ファイアウォール、プロキシ、DNS、EDR、クラウド監査ログをすべてAnalytics tierに入れると、検知ルールも調査クエリも大量の低価値データに埋もれます。
実務では、次の順番で検討すると失敗しにくくなります。
| 手順 | 実施内容 | 判断基準 |
|---|---|---|
| 現状把握 | Log Analyticsでテーブル別のデータ量と検索頻度を確認 | データ量が多く、調査利用が少ないテーブルを候補にする |
| 価値分類 | 検知・調査・監査で必要な列とイベントを分類 | アラート条件やインシデント調査で使うか |
| 変換方式の選択 | Filter、Split、DCR変換を選ぶ | 捨ててよいならFilter、保持が必要ならSplit |
| 小規模テスト | 一部テーブルまたは条件で適用 | 想定通りに破棄・分岐されるか |
| 監視 | 変換後のデータ量、分析ルール、アラート件数を確認 | 検知漏れや過剰削減がないか |
特にFilterは強力ですが、誤るとログを復元できません。最初から広い条件を設定するのではなく、まずはSplitや列削減で様子を見るほうが安全な場合があります。
Identity teamsが見るべきポイント
identity teamsは、Microsoft Entra IDや認証基盤のログを扱うため、データ変換を「見やすくする機能」だけで捉えないことが重要です。サインイン、MFA、条件付きアクセス、特権操作、アカウント変更などのログは、インシデント対応だけでなく内部統制や監査でも使われます。
取り込み時変換を検討する際は、次の列を安易に削らないようにしてください。
| 削除・変更に注意すべき情報 | 理由 |
|---|---|
| ユーザー識別子 | 調査時に同一ユーザーの操作を追跡できなくなる |
| IPアドレス、デバイス情報 | 不審な接続元や端末の特定に必要 |
| 認証結果、失敗理由 | パスワードスプレーやMFA疲労攻撃の分析に使う |
| アプリケーションID、リソース情報 | どのクラウドアプリが狙われたかを特定する |
| 条件付きアクセスの評価結果 | ポリシーの有効性確認に必要 |
一方で、国・地域名の正規化、リスクスコアの列追加、アプリケーション名の補完などは、調査を速くする効果があります。identity teamsでは、データを削るよりも「調査に使いやすい列を追加・正規化する」方向から始めると、運用リスクを抑えやすくなります。
Compliance teamsが見るべきポイント
compliance teamsにとって重要なのは、FilterとSplitの選択です。監査や法令対応で必要なログをFilterで削除すると、後から「保持していなかった」こと自体が問題になります。
そのため、判断は次のように分けるとよいでしょう。
| データの性質 | 推奨判断 |
|---|---|
| 明らかに業務上も監査上も不要 | Filter候補 |
| 調査頻度は低いが監査・証跡として必要 | SplitでData lake tierへ |
| 検知や日次運用で頻繁に使う | Analytics tierへ |
| 個人情報や機密情報を含む | マスク、列削除、アクセス制御を検討 |
| 国や地域ごとに保持要件が異なる | グローバル共通設定にせず、リージョン別の要件確認を行う |
Microsoft Learnでは、取り込み時変換による機密情報のマスクや削除もユースケースとして示されています。たとえばクレジットカード番号や社会保障番号のような個人情報は、一部をマスクして保存する設計が考えられます。(Microsoft Learn)
グローバル企業では、同じログでも国・地域によって保持期間、個人情報の扱い、監査要件が異なります。Sentinel側の変換ルールだけで完結させず、データ保護担当、法務、各地域のIT管理者と事前に合意しておくことが重要です。
ASIM正規化はクエリ性能と再利用性を意識する
Microsoft Sentinelでは、ASIMによる正規化も重要なテーマです。公式ドキュメントでは、取り込み時変換の有用なシナリオとして、ASIMを使ったログの正規化が挙げられています。(Microsoft Learn)
ASIMには、クエリ時にパーサーで正規化する方法と、取り込み時に正規化して保存する方法があります。取り込み時正規化は柔軟性では劣るものの、正規化済みの形式で保存されるため、大量データに対するクエリ性能の面で利点があります。(Microsoft Learn)
たとえば、複数の認証ログを扱う場合、製品ごとに列名が異なると分析ルールが複雑になります。
| 製品A | 製品B | 正規化後の考え方 |
|---|---|---|
| user | accountName | AccountまたはUserに統一 |
| src_ip | clientIp | SourceIpAddressに統一 |
| auth_result | status | EventResultに統一 |
| app | resource | TargetAppまたはResourceに統一 |
ただし、ASIMに寄せることだけを目的にして、元データの重要な文脈を消してはいけません。製品固有のイベントID、テナントID、ポリシー名、デバイス識別子などは、調査で必要になることがあります。正規化列と原始ログ由来の列をどの程度併存させるかを、事前に決めておくべきです。
コスト最適化で見落としやすい注意点
Microsoft Sentinelが有効なLog Analytics workspaceでは、Azure MonitorのAnalyticsテーブルに対する変換について、フィルタリング量にかかわらず変換コストの扱いが通常のAzure Monitorとは異なる旨が公式ドキュメントで説明されています。ただし、Sentinelでも変換そのものの制限やテーブル対応状況はAzure Monitor側の条件に従うため、料金だけを理由に無計画な変換を増やすべきではありません。(Microsoft Learn)
コスト削減でよくある失敗は次の3つです。
| 失敗例 | 影響 | 回避策 |
|---|---|---|
| 低価値ログをすべてFilterで削除する | 監査・フォレンジックで必要な証跡が残らない | まずSplitでData lake tierへ逃がす |
| 変換で列を追加しすぎる | データサイズが増え、取り込み量が増える可能性がある | 追加列は検知・調査で使うものに限定する |
| DCRとSentinel側の変換を重ねて設計する | 条件が競合し、想定外にデータが消える | 既存DCR、Workspace transformation DCR、Filter/Splitを一覧化する |
特にDCRとFilter／Split変換の組み合わせは慎重に扱う必要があります。MicrosoftのFilter／Split変換のドキュメントでも、Azure Monitor側のDCR変換とSentinel側の変換が競合し、意図しない取り込み結果になる可能性が示されています。(Microsoft Learn)
設定前に確認したい実務チェックリスト
本番環境でCustom data ingestion and transformationを使う前に、以下を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象テーブルの対応 | 取り込み時変換、Filter、Splitに対応しているか |
| 既存DCRの有無 | AMA、Logs Ingestion API、Workspace transformation DCRが既にあるか |
| 分析ルールへの影響 | 変換後も検知ルールが必要な列を参照できるか |
| Workbooksへの影響 | ダッシュボードの集計列が消えないか |
| ハンティングクエリへの影響 | 調査チームが使うKQLが壊れないか |
| 監査要件 | 削除してよいログと保持すべきログを区別できているか |
| 個人情報 | マスク・削除・アクセス制御の方針があるか |
| 反映時間 | 変換が即時反映されない可能性を考慮しているか |
| ロール権限 | DefenderポータルやLog Analyticsで必要な権限を持っているか |
Filter／Split変換では、反映に最大1時間程度かかる可能性があるとされています。また、XDRテーブルではAdvanced Huntingでの見え方に制限がある点も記載されています。設定直後に結果が見えないからといって、条件を何度も変更すると原因切り分けが難しくなります。(Microsoft Learn)
小さく始めるための導入手順
最初から全テーブルに変換を適用するのは避けるべきです。特にグローバル環境では、地域、部門、データソースごとに要件が違うため、小さな範囲から始めて、効果と副作用を確認します。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 調査 | データ量、検索頻度、アラート利用状況を確認 | 対象テーブル候補一覧 |
| 設計 | 残すデータ、捨てるデータ、Data lakeへ送るデータを分類 | 変換設計書 |
| テスト | 非本番または限定条件でKQLを検証 | テスト結果、サンプルログ |
| 実装 | DCR、Logs Ingestion API、Filter／Splitを設定 | 設定済みルール |
| 検証 | データ量、アラート、クエリ結果を確認 | 影響確認レポート |
| 運用 | 月次でデータ量・検知品質・監査要件を見直す | 改善バックログ |
実装時は、変換前後で次のようなKQL確認を行うと効果を把握しやすくなります。
YourTable
| summarize Count=count() by bin(TimeGenerated, 1h)
| order by TimeGenerated desc列の有無を確認する場合は、テーブルスキーマやサンプルレコードを確認し、分析ルールが参照する列が残っているかを必ず見ます。
YourTable
| take 10この段階で「ログ量が減った」だけを成功指標にしないでください。重要なのは、検知精度、調査速度、監査対応力を落とさずに、不要なデータを減らせているかです。
今回の更新を受けて次にやるべきこと
2026年4月更新のMicrosoft Sentinel Custom data ingestion and transformationは、ログ取り込みを「収集」から「設計」へ進めるための内容です。DCR、Logs Ingestion API、取り込み時変換、Filter／Split変換を理解すれば、コスト削減だけでなく、検知ルールの精度向上、調査の高速化、コンプライアンス対応の明確化にもつなげられます。
まず実施すべきことは、既存のSentinelワークスペースでデータ量の多いテーブルを確認し、次に「Analyticsに残すべきデータ」「Data lakeへ分けるべきデータ」「破棄してよいデータ」を分類することです。そのうえで、影響の少ないテーブルからFilterまたはSplit変換を試し、DCRやLogs Ingestion APIを使うカスタムログについては、列設計と変換ルールを標準化していきましょう。
コメント