Microsoft Sentinelのデータ収集基盤が、2026年4月にかけて大きな転換点を迎えた。コードレスコネクタ基盤の刷新（CCFへの改称とCCF Pushのプレビュー開始）、Defender Advanced HuntingテーブルへのLake専用インジェストのGA、そしてMicrosoft Fabricを活用したデータフェデレーション機能のプレビューが相次いで発表された。SOC（セキュリティオペレーションセンター）の運用コストと複雑性を同時に下げる施策として、日本のセキュリティ担当者も注目すべきアップデートだ。

Codeless Connector Framework（CCF）の刷新

これまで「Codeless Connector Platform（CCP）」と呼ばれていたSentinelのカスタムコネクタ基盤が、「Codeless Connector Framework（CCF）」に改称された。単なる名称変更ではなく、アーキテクチャの成熟とロードマップの整理を示すリブランディングだ。

今回のハイライトは「CCF Push」のパブリックプレビュー開始だ。従来のPull型コネクタ（Sentinelがデータソースに取りに行く）に加え、Push型（データソース側からSentinelに送り込む）をカスタムコードなしで実装できるようになった。これにより、独自のログ基盤やSaaSサービスからのイベントをSentinelに集約するハードルが大幅に下がる。

従来、独自コネクタを作るにはAzure Functionsなどのカスタム実装が必要だった。CCFはJSON設定ファイルだけで接続定義を完結させる設計であり、セキュリティエンジニアがインフラ管理の負担なくデータソースを追加できる点が最大の価値だ。Visual Studio Code向けのコネクタビルダーエージェント（プレビュー）も加わり、開発体験の底上げも図られている。

Lake専用インジェストのGA — 高コスト構成を見直す好機

Microsoft Defender Advanced HuntingテーブルへのLake専用インジェスト（Lake-only Ingestion）が一般提供（GA）を迎えた。

Sentinelのインジェストモデルには「分析ログ」「基本ログ」「補助ログ」という階層があるが、Lake専用インジェストはデータをAnalyticsテーブルとしてではなく、ストレージレイヤーにのみ保持する。これにより、常時クエリが不要なデータ（長期保存・コンプライアンス目的等）のインジェストコストを大幅に削減できる。

特にDefender Advanced Huntingのテーブルは大量のイベントを生成するため、全量をAnalyticsとして取り込むとコストが膨らみやすい。「重要なアラートはリアルタイム分析、ハンティング用データは低コストで長期保存」という使い分けが現実的になった。

【要注意】7月1日までにオートメーションルールを更新せよ

見逃してほしくない重要な変更がある。2026年7月1日より、Sentinelアナリティクスルールのアラートにおけるアカウントエンティティの「Account Name」フィールドの仕様が変更される。

現在、UPNが user@domain.com の場合、Account Nameには user が入ることも user@domain.com が入ることもある（挙動が不安定だった）。変更後は常に user（UPNプレフィックスのみ）が入り、ドメイン部分は別フィールド（UPNSuffix）として提供される。

既存のLogic AppsプレイブックやオートメーションルールでAccount Nameに対して Equals user@domain.com のような完全一致チェックをしている場合、この変更後に動作しなくなる可能性がある。Contains や Starts with オペレーションへの書き換えを推奨する。7月1日は想像より近い。早めに棚卸しを。

データフェデレーション（プレビュー）— データを動かさずに分析する

Microsoft Fabricをバックエンドとして活用する「Sentinelデータフェデレーション」もプレビューに入った。Azure Data Lake StorageやAzure Databricksに存在するデータを、Sentinelにコピーすることなくそのまま分析できる仕組みだ。KQLやノートブック、カスタムグラフなど、SentinelのUXから透過的に利用できる。

データ移動はコストとガバナンスの問題を生む。既存のDatabricksやADLSにセキュリティ関連データを持っている組織にとって、フェデレーションアプローチは現実的な選択肢になりうる。

実務への影響

SOC担当者・セキュリティエンジニアへ:

  • CCF Pushプレビューを試す価値がある。社内の独自ログ基盤や、既存コネクタがないSaaSからのイベント収集をAzure Functions不要で実装できる可能性がある
  • Lake専用インジェストのGAにより「全量をAnalyticsで取り込む」構成を見直す好機。特にDefender系テーブルはボリュームが大きいため、コスト試算を行うことを推奨する
  • 7月1日のUPN変更はすぐ確認。Logic AppsのPlaybookでAccountNameを参照している箇所は全数チェックを

IT管理者・CISOへ:

  • データフェデレーションにより、Sentinelへの一元化戦略が「コピー必須」から「フェデレーション選択肢あり」へと広がった。既存データ基盤の資産を活かしながらSentinelの分析力を活用できる
  • エンティティアナライザーのGA、AI駆動のSIEM移行ツールGAも重なり、今が既存SIEMからSentinelへの移行を検討する現実的なタイミングといえる

筆者の見解

Sentinelは着実に「SIEMとしての完成度」を高めている。CCF刷新とLake専用インジェストのGAは地味に見えるかもしれないが、現場で本当に効くのはこういった地道な改善の積み重ねだ。

Non-Human Identity（NHI）との連携も含め、Sentinelが「人間が常駐するSOC」から「AIエージェントが自律的にアラートをトリアージするSOC」へと移行するための基盤として機能し始めていることは評価できる。CCFのPush型コネクタは、エージェントがイベントをSentinelに直接報告するワークフローにも応用が効く設計だ。

一点、正直に言えば、こうした地道な改善を積み重ねているのに、全体的な発信が「機能一覧の羅列」に見えてしまうのがもったいない。「Sentinelでここまでできる」という具体的なユースケース・ROIの訴求がもっと強化されれば、採用の壁はさらに下がるはずだ。日本市場ではSIEMの費用対効果に懐疑的なCISOがまだ多い。Sentinelチームにはそのストーリーテリングにもエネルギーを割いてほしいと、応援する立場から思う。正面から勝負できる技術的な土台は、間違いなくある。

出典: この記事は Microsoft Sentinel Codeless Connector Framework (CCF) & Lake-only Ingestion GA の内容をもとに、筆者の見解を加えて独自に執筆したものです。