Databricks Lakewatchとは何か？ Open Security Lakehouse時代のSIEMをデータ基盤視点で整理してみる
投稿日：2026年03月25日
はじめに
Databricksが発表した Lakewatch は、単なる新しいSIEM製品というより、Lakehouseアーキテクチャの上でSecOpsを再設計しようとする新しいアプローチとして見ると理解しやすいです。
発表では Lakewatch を open, agentic SIEM と位置付けており、セキュリティデータだけでなく、ITデータや業務データまで含めて単一のガバナンス配下で扱う構想が示されています。
個人的には、この発表の面白さは「SIEMにAIを載せた」ことよりも、セキュリティ運用そのものをデータプラットフォームの延長線上に置き直そうとしている 点にあります。
本記事では、Databricksの発表内容をもとに、Lakewatchの要点と、データ基盤の観点で見たときの意味を整理します。
Lakewatchの概要
Lakewatchは、Databricksが新たに発表した open, agentic SIEM です。
特徴は、セキュリティ、IT、業務データを単一の統制された環境にまとめ、その上でAIを使った検知、調査、対応を行う点にあります。
従来型SIEMでは、取り込めるデータ量や保存期間がコストに強く制約されることが多く、結果として「必要なときに必要なデータが残っていない」という問題が起こりがちでした。
Lakewatchはこの前提を見直し、マルチモーダルなデータも含めて大規模に取り込み、長期間保持し、必要なときに分析する方向を打ち出しています。
また、発表時点では Private Preview とされており、AdobeやDropboxといった企業名も利用例として挙げられています。
Lakewatchの全体ダッシュボード。データソースの健全性、イベント量、Agentによる調査状況をひと目で把握できます。
なぜ今SIEMを作り直すのか
Databricksの主張はシンプルで、攻撃者はすでにAIや自動化を使って機械速度で行動している一方、防御側の運用はまだ人手中心である、というものです。
つまり、攻撃のスピードが上がっているのに、防御側の調査、ルール更新、トリアージ、脅威ハンティングは依然として手作業に依存しており、アーキテクチャそのものが追いついていない、という課題認識です。
さらに、従来型SIEMではストレージとコンピュートが密結合しやすく、取り込むデータ量が増えるほどコストが重くなります。
その結果、保持期間を短くしたり、ログを間引いたり、対象データを絞ったりする必要が生まれ、防御側の可視性が攻撃側より先に落ちてしまう構造が発生します。
Lakewatchは、こうした課題に対して ストレージとコンピュートの分離、全量志向のデータ保持、AIエージェントによる自動化 で対抗しようとしています。
Lakewatchの中核にある考え方
Lakewatchの本質は、セキュリティ運用を専用の閉じたツール群に閉じ込めるのではなく、Open Security Lakehouse 上で実行するという発想です。
これは、セキュリティデータを他のデータと切り離して管理するのではなく、業務データやITデータと横断的に関連付けて分析できるようにする考え方です。
たとえば、ある不審なアクセスが発生したときに、認証ログだけを見るのではなく、HR情報、SaaS監査ログ、アプリケーションイベント、コラボレーション履歴などを同じ基盤上で突き合わせられるようになります。
この構成は、SecOpsの文脈でも「セキュリティはデータ問題である」という見方をかなり強く押し出しています。
Lakewatchのコンセプト図。多様なデータソースをOpen AgentsとOpen Formatsの上で統合する思想がよく分かります。
注目したいポイント
1. 100%テレメトリ志向
Lakewatchは、データを減らすことで成立させるのではなく、できる限り多くのテレメトリを保持する 方向を取っています。
対象は一般的なログに限らず、音声や動画のようなマルチモーダルデータにも広がっています。
この発想は、従来の「高いから捨てる」というSIEMの前提とはかなり異なります。
2. オープン標準を前提にしている
Databricksは、Lakewatchで OCSF を採用し、保存形式として Delta Lake や Apache Iceberg のようなオープンフォーマットを前提にしていると説明しています。
ここで重要なのは、セキュリティデータを特定ベンダー独自の形式に閉じ込めず、ユーザー側がデータの所有権と将来の選択肢を持ちやすい構成を志向している点です。
データプラットフォームの観点では、この「運用製品より先にデータ形式を開く」という思想はかなり大きな意味を持ちます。
3. AIを補助ではなく中核に置いている
Lakewatchでは、AIはダッシュボードの横に追加された補助機能ではなく、検知・調査・対応の中核 に置かれています。
発表では、Genie を使ってログソースの取り込みやOCSFへの正規化、新しい検知ロジックの作成、ルール改善、自然言語からSQLへの変換などを支援する方向が示されています。
これにより、SecOpsの一部は専門クエリ言語を使える少数の担当者だけの仕事ではなくなっていく可能性があります。
Genieを使った検知ルール作成の画面。AIを補助機能ではなく運用フローに組み込んでいる点が特徴です。
4. SIEMの経済性を作り直そうとしている
Lakewatchは、ストレージとコンピュートを分離し、必要なときだけサーバレス計算資源を使う構成を前提にしています。
Databricksはこれにより、大規模データを長期間保持しながら、従来型SIEMより低コストで分析できる可能性があると打ち出しています。
発表では、ケースによっては 最大80%低いTCO という表現も使われており、これは多くの企業にとってかなり強い訴求点になるはずです。
データプラットフォーム視点で見た構成要素
Lakewatchは単独の新製品というより、Databricksがすでに持っているデータ・AI基盤をSecOps向けに束ねたものとして捉えると分かりやすいです。
具体的には、以下のような構成が見えてきます。
-
Unity Catalog
アクセス制御、リネージ、監査を統合的に扱うガバナンス基盤。 -
Lakeflow Connect
AWS、Okta、Zscaler などからデータを取り込み、正規化するための接続基盤。 -
Detection-as-Code
YAML、SQL、Python notebook などを使って、検知ロジックをコードとして管理する考え方。 -
MLflow / Model Serving
機械学習ベースの異常検知やリスクスコアリングを組み込むための基盤。 -
Serverless compute
大量のデータを保持しつつ、必要なタイミングだけ分析や推論を実行するための計算基盤。
この構成を見ると、Lakewatchは「セキュリティ製品を追加した」というより、Databricks LakehouseをSOCの実行基盤へ拡張した と見る方が自然です。
調査・クエリ実行画面。時系列の可視化と自然言語支援を組み合わせた脅威ハンティングのイメージです。
Anthropic連携とエコシステム
発表では、LakewatchのAI面で Anthropicとの連携強化 も示されています。
Claudeのようなモデルを使いながら、セキュリティ、IT、業務データを横断し、調査や脅威分析を高速化する狙いがあるようです。
また、Open Security Lakehouse Ecosystem として、Akamai、Arctic Wolf、Cribl、Deloitte、Okta、Palo Alto Networks、Proofpoint、Slack、Wiz、Zscaler など複数のパートナー企業も挙げられています。
この点からも、Lakewatchは単体で完結する製品というより、周辺ツールとの接続性を重視したプラットフォーム戦略として設計されていると感じます。
この発表をどう見るか
個人的には、Lakewatchの一番大きなポイントは、セキュリティ運用をOpen Lakehouseの上に再配置する という思想にあります。
従来型SIEMは、セキュリティ専用の世界を閉じた形で最適化してきましたが、Lakewatchはそこを「データプラットフォームの一部」として開こうとしています。
これは、データエンジニアリングやAI基盤の進化が、SecOpsの設計思想そのものに影響を与え始めていることを示しているように見えます。
一方で、Lakewatchはまだ Private Preview の段階であり、実運用での完成度や、既存SIEMからの移行容易性、運用担当者の学習コスト、AIエージェントの精度管理などは、今後しっかり見ていく必要があります。
そのため、現時点では「すぐ全面移行すべき製品」というより、次世代SOCアーキテクチャの方向性を示す重要な発表 として受け止めるのがよさそうです。
まとめ
Databricks Lakewatchは、Open・AI-native・Lakehouseベースという3つの要素を組み合わせて、SIEMを再定義しようとする試みです。
特に、セキュリティデータを他の業務データと統合し、その上でAIエージェントを動かすという設計は、これからのSecOpsにおいてかなり大きなインパクトを持つ可能性があります。
また、オープン標準、オープンフォーマット、ストレージとコンピュートの分離という要素は、データプラットフォームの観点から見ても非常にDatabricksらしい戦い方です。
今後、実際の導入事例や運用パターンが増えてくれば、Lakewatchは「セキュリティ製品の新機能」ではなく、SecOps基盤の新しい設計パターン として語られるようになるかもしれません。