DatabricksとGoogleのセキュリティチームが直面する新たなAI防御のトレードオフ

Databricksは、ある一つの対立軸を中心に据えた新たなセキュリティガイドを公開した。AIは防御を加速できるが、それを支えるデータと自動化をチームが信頼できる場合に限られる、というものだ。databricks googleの導入を検討する組織にとって、この提案は分析の枠を超える。Databricksは、レイクハウスをセキュリティデータ、調査、検知エンジニアリング、AI支援型レスポンスの運用レイヤーへと位置付けたい考えだ。

このガイドは、従来ログとアラートを一元化してきたセキュリティ情報・イベント管理システム、すなわちSIEMを、セキュリティチームが見直す中で登場した。Databricksは、断片化されたテレメトリー、高額な保持コスト、分断されたワークフローが、防御側によるAIの効果的な活用を妨げていると主張する。同社が提示する答えは、ガバナンスの効いた企業データを中心に置き、アナリストとAIエージェントがその共有コンテキストを横断して作業できるようにするものだ。

この立場により、Databricksが対峙するのは既存SIEMベンダーだけではない。セキュリティデータは専門的なセキュリティプラットフォーム内に留めるべきだという考え方にも挑戦している。Google Security Operations、Microsoft Sentinel、Splunk、CrowdStrikeなどのベンダーも、AI主導の調査とレスポンスを追加している。競争は、統合セキュリティスイートを選ぶか、防御向けに適応された広範なデータプラットフォームを選ぶかという選択へと変わりつつある。

Databricksが実際に提示したもの

この発表は、独立して検証された製品ベンチマークではなく、セキュリティ運用に関する戦略的な設計図である。

Databricksは2026年9月2日、セキュリティリーダーシップに関する電子書籍を公開した。このガイドは、統合データアーキテクチャを現代のサイバー防御の基盤として提示している。中心的な主張は、ログ、アイデンティティ、アラート、ビジネスコンテキストが分離されたままでは、組織は信頼できるセキュリティエージェントを導入できないというものだ。

同社は、相互につながる3つの変化を説明している。セキュリティチームは、より多くのテレメトリーを統合し、専門的なエンジニアリンググループ以外にも分析を利用可能にし、ガバナンスの効いたワークフロー内でAIエージェントを導入すべきだという。このアプローチにより、レイクハウスは長期保管場所以上の存在となる。検知、調査、エンリッチメント、そして選択的なレスポンス活動の場となる。

security leadership guideでは、複数の顧客事例と業界データが取り上げられている。Databricksによれば、調査対象となったセキュリティエグゼクティブの72%がサイロ化したデータに苦慮している。また、Arctic Wolfが毎週8兆件のセキュリティイベントを処理していることにも言及している。

同ガイドによると、Rivianはセキュリティデータアーキテクチャの近代化後、SIEM関連コストを60%削減したという。別の事例では、チームが検知ルールを5～6倍速く導入できたとされる。これらの数値は同社の主張を示すものだが、慎重な解釈が必要だ。

Databricksは、すべての数値を同等のセキュリティ環境における統制比較として提示しているわけではない。ワークロード構成、保持ポリシー、人員配置、データ量、既存契約は、結果に大きく影響し得る。ある顧客導入の成功が、普遍的なコスト削減率を示すわけではない。

有用なシグナルは、これらの事例の背後にある傾向だ。セキュリティチームは、より長い保持期間、より広範なテレメトリー、そしてコンテキストを伴うデータへの迅速なアクセスを求めている。従来型SIEMのコスト構造は、取り込み前に情報を絞り込んだり、古いログを別のストレージへ移したりする圧力となり得る。

この分断は、運用上の摩擦を生む。不審なアクセスを調査するアナリストは、エンドポイントアラート、アイデンティティ履歴、クラウド監査記録、資産所有者、アプリケーション活動を必要とする場合がある。これらの記録が複数のシステムにまたがっている場合、自動化された調査も同じ欠落を引き継ぐことになる。

レイクハウスは、ストレージと分析の境界を変える。構造化された記録を、標準化の度合いが低い情報とともに保持しながら、SQL、Python、機械学習、ガバナンスの効いたデータ共有をサポートできる。Databricksはこのアーキテクチャを、データ、分析、AIのための統合プラットフォームと呼んでいる。

同社はまた、ドメイン固有のAIエージェントを構築する環境であるAgent Bricksを推進している。セキュリティ運用において、エージェントは関連アラートを要約したり、過去の活動を取得したり、検知ロジックの下書きを支援したりできる。とはいえ、エージェントは依然として権限、信頼できるコンテキスト、明確に定義された承認経路に依存する。

この区別は重要だ。このガイドは、AIエージェントがセキュリティアナリストを安全に置き換えられることを示してはいない。むしろ、より大きな自動化に備え、Databricksが組織にデータとガバナンスをどう整備してほしいかを示している。

これはより限定的な主張だが、同時により大きな影響を持つ。企業がこの前提を受け入れるなら、セキュリティアーキテクチャに関する意思決定はデータプラットフォームチームに近づく。SIEMの調達は、ストレージ形式、カタログ、モデルアクセス、再利用可能な企業コンテキストに関する問いにもなる。

DatabricksとGoogleの導入が今重要な理由

databricks googleの動向が重要なのは、AI防御が今やデータプラットフォーム、クラウド制御、アイデンティティシステム、外部モデルプロバイダーにまたがるためだ。

Databricksは、両社が2021年に提携を発表して以来、Google Cloud上で提供されてきた。当初のcloud partnershipでは、統合分析、機械学習、統合請求、Googleアイデンティティのサポート、容易なデータアクセスが強調されていた。

その後、セキュリティ上の意味合いは拡大している。Databricksのワークスペースは、Google Cloudのストレージ、ネットワーク、アイデンティティ、暗号化、監査サービスを利用できる。セキュリティチームは、プラットフォーム自体を唯一の保護源として扱うことなく、Databricks内でテレメトリーを分析することもできる。

現在のGoogle Cloud guidanceでは、セキュリティはDatabricks、顧客、クラウドプロバイダー間の責任共有として説明されている。組織がより多くのセキュリティデータをレイクハウスへ移す際、この境界は不可欠だ。

Google Cloudは基盤インフラを保護し、アイデンティティ、ネットワーク、ストレージ、暗号化のための制御を提供する。Databricksは管理対象プラットフォームを保護し、ワークスペースレベルの機能を提供する。顧客は、権限、データ分類、ワークロード分離、アプリケーションの動作、そして多くの設定選択に引き続き責任を負う。

統合されたセキュリティデータセットは、これらの境界をなくすものではない。むしろ、それらをより可視化する。調査ではシステム横断でアクションを相関付けられるが、管理者はどの制御がどの運用主体に属するかを依然として理解していなければならない。

たとえば、Google Cloud上のDatabricksは、アイデンティティフェデレーション、シングルサインオン、プライベート接続、顧客管理キー、クラウド監査ログをサポートしている。これらの制御は、正しく設定されれば露出を低減できる。一方で、別の当事者が要件を満たしているとチームが思い込めば、盲点を生む可能性もある。

したがって、databricks googleという表現は、いくつか異なる購買判断を指し得る。ある組織はDatabricksを分析に使いながら、Google Security Operationsを主SIEMとして維持するかもしれない。別の組織は、過去のテレメトリーをDatabricksへオフロードするかもしれない。さらに別の組織は、レイクハウスのデータ上で直接検知を構築する可能性がある。

これらの設計には、それぞれ異なるリスクがある。二次的な分析ストアには、主たるセキュリティコンソールにあるすべてのワークフローは不要だ。リアルタイムのトリアージ、自動封じ込め、規制上の証拠を扱うシステムには、より厳格な運用保証が求められる。

Googleも独自のセキュリティおよびエージェント制御スタックを前進させている。2026年のagent identity frameworkには、自律型ソフトウェア向けのアイデンティティ、アクセス管理、ゲートウェイ、ガードレール、ランタイム防御が含まれる。これは、Databricksがデータレイヤーから取り組むガバナンスの問題と重なる。

この重なりは、協力と競争の両方を生む。DatabricksはGoogle Cloudのインフラから恩恵を受け、Googleのアイデンティティとストレージにすでに投資している顧客に対応できる。しかしGoogleも、テレメトリー、アナリストの注意、そして自動化ワークロードを巡って競合するセキュリティ運用プラットフォームを販売している。

この緊張関係はクラウドソフトウェアでは珍しくない。プラットフォームはしばしばインフラレイヤーで統合しながら、アプリケーションスタックの上位では競合する。購入者は、どのシステムを検知、ケース、レスポンス承認、証拠保持の権威ある基盤にするかを評価すべきだ。

アーキテクチャはポータビリティにも影響する。Databricksはオープンデータ形式とマルチクラウド運用を強調する。Google Cloudは統合サービスとクラウドネイティブな制御を強調する。企業は両方を評価するかもしれないが、これらの目標が常に同じ設計へと導くわけではない。

オープンなストレージ形式は、セキュリティ記録の再利用を容易にし得る。しかし、検知ルール、インシデントワークフロー、自動化プレイブックまで自動的にポータブルになるわけではない。こうした上位レベルの資産は、多くの場合、独自スキーマとAPIに依存する。

その結果、セキュリティリーダーに残される問いはより具体的になる。抽象的にオープン性と統合性のどちらを選ぶかではない。どこで専門性を受け入れ、どこでポータビリティを求め、どこで一貫したガバナンスを維持しなければならないかを決めることになる。

真の競争はデータレイヤー対SIEMスイート

Databricksは、従来のアナリストコンソールの所有権よりも、セキュリティデータの制御が重要になると賭けている。

従来型SIEMは、取り込み、正規化、検索、検知、アラート、調査、レポーティングを組み合わせる。その価値は、これらの機能を一つのセキュリティ重視のワークフローに統合することにある。弱点は、データ量の増加が予算や運用能力を上回る際に現れる。

Databricksは、逆方向からこの問題に取り組む。まず、スケーラブルなデータストレージ、オープンな処理ツール、中央集権的なガバナンス、機械学習から始める。その基盤の上にセキュリティ機能を構築する。

このモデルは、チームが後の調査に備えて生のテレメトリーを保持するのに役立つ可能性がある。また、セキュリティ記録とビジネスコンテキストの結合もサポートする。異常なログインは、アナリストが従業員の役割、管理対象デバイス、アプリケーション所有者、最近のアクセス変更と結び付けられると、より有用になる。

AI主導の防御は、そのようなコンテキストから恩恵を受ける。アラートのタイトルと数個のイベントフィールドしか受け取れないモデルでは、証拠が限られる。許可された履歴を取得できるガバナンスの効いたエージェントは、有用な要約を生成できる可能性がより高い。

データが増えれば、より良い回答が保証されるわけではない。正規化が不十分だと、矛盾するアイデンティティ、重複イベント、誤解を招くタイムラインが生じる可能性がある。セキュリティチームは、依然としてスキーマ、品質チェック、リネージ、検知ロジックを維持しなければならない。

ここでSIEMベンダーは優位性を維持している。セキュリティ固有のコンテンツ、確立された調査インターフェース、コネクター、ケース管理、レスポンス統合を提供している。多くの顧客は、汎用データプラットフォーム上で組み立てるよりも、こうしたパッケージ化された機能を好む。

Google Security Operationsは、専用の運用環境内でクラウドスケールのセキュリティ分析と脅威インテリジェンスを提供する。MicrosoftはSentinelをアイデンティティ、エンドポイント、生産性、クラウド製品と結び付けている。CrowdStrikeは、エンドポイントと脅威データをエージェント型セキュリティプラットフォームへ拡張している。

Splunkは、大規模な導入基盤、幅広い統合、長年にわたる検知コンテンツを持つ。Palo Alto Networksをはじめとするセキュリティベンダーも、データと自動化を統合している。Databricksが参入する市場では、購入者はすでに重複するプラットフォームの主張に直面している。

Databricksの最も強い立ち位置は、即時の置き換えではない。アーキテクチャ上のレバレッジである。組織はレイクハウスを活用し、すべての運用プロセスを一度に移行することなく、テレメトリーの重複を減らし、より長い履歴を保持し、調査を充実させ、AI支援ワークフローを試行できる。

段階的なアプローチは、パフォーマンスの測定も容易にする。チームはログコストの最適化や過去の脅威ハンティングから始められる。既存システムと比べて、クエリ速度、検知範囲、エンジニアリング工数、総運用コストを比較できる。

次の段階では、選択した検知ロジックをDatabricksへ移行することになるかもしれない。セキュリティエンジニアは、バージョン管理やテストを含む、使い慣れた開発プラクティスでロジックを管理できる。アラートは既存のケース管理システムに引き続き流せる。

全面的な置き換えには、より多くの根拠が必要だ。主要なSIEMは、信頼性の高い取り込み、低遅延の検知、調査の継続性、監査要件、対応の連携を支えなければならない。また、他のエンタープライズシステムに影響が及ぶインシデント時にも利用可能でなければならない。

Databricksは、自社プラットフォーム上に構築されたオープンでエージェント型のSIEMとしてLakewatchを打ち出している。この製品の方向性は、競争上の狙いをより明確にする。Databricksはセキュリティ分析の支援にとどまらず、より多くの運用ワークフローを担おうとしている。

この変化は、保持コストとデータアクセスの面で従来ベンダーに圧力をかける。同時に、セキュリティ固有の期待に応えることをDatabricksにも求める。データプラットフォームの信頼性は必要条件だが、運用防御システムには追加の責務が伴う。

購入側の交渉力は、主張を検証可能なレイヤーに分けることで生まれる。ストレージの経済性は検知品質とは別に評価できる。エージェントの生産性も、対応の安全性とは切り分けて評価できる。ポータビリティは、データ、クエリ、ルール、ワークフローの各レベルでテストできる。

セキュリティリーダーは、隠れた労働コストも追跡すべきだ。あるプラットフォームがライセンス負担を軽減する一方で、エンジニアリング作業を増やす可能性がある。スキーマ保守、コネクタ開発、検知チューニング、権限管理、オンコール対応はいずれも比較対象に含めるべきだ。

これが、Databricksの提案が単なるAI機能の発表以上に重要である理由だ。これは、エンタープライズデータインフラとセキュリティオペレーションセンターの境界を改めて問い直す。この境界は長年にわたり、セキュリティ予算とワークフローを形作ってきた。

AI主導の防御はAIガバナンスの問題を引き継ぐ

調査を圧縮する同じエージェントが、ミス、不正アクセス、不十分に監督された対応も加速させかねない。

Databricksは、ガバナンスを独立したコンプライアンス手順ではなく、アーキテクチャの一部として提示している。Unity CatalogはデータとAIアセットへのアクセスを制御する。Unity AI Gatewayはモデルとツールサービスへのトラフィックを管理する。

同社のAI governance guideによれば、このゲートウェイはモデルおよびModel Context Protocolのリクエストをルーティングできる。また、プロバイダーをまたいで、制限の適用、ポリシーの施行、利用状況の記録も行える。

Model Context Protocol、すなわちMCPは、AIアプリケーションをツールやデータソースに接続するための標準である。セキュリティ環境では、MCPサービスが脅威インテリジェンス、チケット処理機能、アセット記録、承認済みの対応ツールを公開する場合がある。

中央集権的な制御には実務上の利点がある。組織は、他のデータアセットに用いるのと同じアクセスレイヤーを通じて、外部モデル、コーディングエージェント、MCPサービスを統制できる。Databricksによれば、これにはGoogle、Anthropic、OpenAIのモデルも含められる。

一部の機能は依然としてベータ版だ。Databricksは、コンテンツに基づいてリクエストを許可、拒否、または承認必須にできるサービスポリシーを説明している。これらのポリシーに機密データの露出や危険なツール利用の阻止を期待する場合、プレビュー段階であることは重要だ。

セキュリティリーダーは、ベータ版のガードレールを、本番対応アクションを守る唯一の防壁として扱うべきではない。防御には重層的な制御が必要である。ID制限、スコープを限定したツール、承認ゲート、ログ、レート制限、可逆的なアクションが相互に補強し合うべきだ。

人によるレビューにも正確な定義が必要である。アナリストにすべての提案の承認を求めれば統制は維持できるが、自動化で削減するはずだったキューを再現する可能性がある。広範な自律性を許せば速度は向上する一方、誤った判断の影響も大きくなる。

実践的な設計では、アクションを結果の重大性で分ける。読み取り専用の取得は、アカウントの無効化よりリスクが低い。検知ルールの草案作成は、そのデプロイとは異なる。単一エンドポイントの隔離は、ネットワーク全体のポリシー変更とは異なる。

各カテゴリには、それぞれ固有の認可境界が必要だ。確信度が高く、可逆的なアクションには、より多くの自動化を適用できる。曖昧なアクションや影響の大きいアクションには、追加の証拠と明示的な承認を求めるべきである。

データ露出も別の懸念を生む。調査エージェントは、ユーザーアクティビティ、デバイスの詳細、アプリケーションログ、組織コンテキストを必要とすることが多い。それぞれの情報源が単独では無害に見えても、この組み合わせは機密性の高い個人情報や事業情報を明らかにし得る。

DatabricksはAI trust documentationで、パートナーモデルプロバイダーはプロンプトや応答を保存しないとしている。また、Unity Catalogの権限が、同社のAI機能が送信できるデータを統制するとも説明している。

このドキュメントは、モデルがハルシネーションを起こしたり、不正確な回答を生成したりする可能性を認めている。その警告は、流暢でも不正確な要約が調査の方向を誤らせたり、ユーザーに誤った疑いをかけたりするセキュリティ領域で特に重要だ。

権限を意識した取得は、不正アクセスを減らす。しかし、事実の正確性を保証するものではない。チームには、実際のインシデントパターン、敵対的な入力、不完全なテレメトリー、矛盾する証拠に基づく評価が必要だ。

プロンプトインジェクションも別のリスクを加える。攻撃者は、チケット、ログフィールド、リポジトリ、文書の中に悪意あるテキストを置き、エージェントが後で取得するように仕向けることができる。システムがその内容を指示として扱えば、調査ワークフローが操作される可能性がある。

ガバナンスポリシーで一部の攻撃はフィルタリングできるが、信頼できる防御はアーキテクチャ上の分離にも依存する。取得したデータは信頼できないものとして扱うべきだ。ツールはモデルの外側で認可を強制すべきである。機密性の高いアクションは、生成された判断だけに依存すべきではない。

最終的な試金石は監査可能性である。チームには、エージェントがアクセスしたデータ、処理したモデル、呼び出されたツール、結果を承認した人物を示す記録が必要だ。この連鎖がなければ、インシデントレビューや規制上の証拠提示は難しくなる。

これは、セキュリティオペレーションセンター以外のナレッジワークにも関係する。AI knowledge baseを利用するチームも、権限、情報源の品質、追跡可能性について同様の問いに直面する。セキュリティでは結果の重大性が増すが、ガバナンスの原則は変わらない。

Databricksは、この問題に対する信頼できる構成要素をそろえている。ただし、すべての顧客がそれらを安全な自律防御に組み合わせられることを、同社はまだ立証していない。その結果は、実装の規律、測定、運用上のオーナーシップに左右される。

戦略が機能しているかを示す3つのシグナル

次の試金石は、さらなるAIデモではない。Databricksがコストとリスクを別の場所へ移すことなく、防御を改善できることの証拠である。

最初のシグナルは、独立して理解できる顧客パフォーマンスである。Databricksには、ベースライン、ワークロード、導入範囲、測定期間を定義したケーススタディがさらに必要だ。これらの詳細を欠く割合の数値は注目を集めるが、実用的な指針はほとんど与えない。

セキュリティリーダーは、検知範囲、平均調査時間、誤検知率、保持期間の深さ、総エンジニアリング工数を確認すべきだ。コストの主張には、移行作業、コネクタ保守、インフラ、人員配置を含めるべきである。

顧客がより広範なテレメトリーを保持しながら、調査時間と運用コストの両方を削減できるなら、Databricksの主張は強まる。削減効果が大規模なカスタムエンジニアリングに依存するなら、小規模チームにとっては説得力が弱くなる。

2つ目のシグナルは、統制されたエージェント運用の成熟度である。サービスポリシー、承認制御、ツール制限、監査記録は、デモを超えた段階に進まなければならない。購入者には、障害、攻撃、曖昧な証拠の下での挙動が文書化されている必要がある。

有用な検証では、エージェントが悪意ある取得コンテンツに遭遇してもそれに従わないことを示せる。別の検証では、要求元のIDに権限がないため対応アクションがブロックされることを示せる。チームには明確なロールバック手順とインシデントレビュー手順も必要だ。

こうした制御が一般提供され、敵対的テストに耐えられるなら、AI主導の防御という論拠は強化される。重要な保護策がプレビュー段階にとどまる、または大規模なカスタム作業を要するなら、自律性は厳格に限定すべきだ。

3つ目のシグナルは競合の対応である。Google、Microsoft、Splunk、CrowdStrike、Palo Alto Networksはすでに重要なセキュリティワークフローを掌握している。これらの企業は、保持モデルの調整、データアクセスの開放、エージェントガバナンスの拡充、クラウド統合の深化を行える。

Googleは、インフラパートナーであると同時にセキュリティプラットフォームの競合でもあるため、特に注目に値する。databricks google customerは両社のサービスを組み合わせられるが、重複するコントロールプレーンはオーナーシップを不明確にする可能性がある。

より緊密な相互運用性はDatabricksを支えるだろう。セキュリティデータはポータブルな状態を保ちつつ、アラート、ケース、脅威インテリジェンス、対応アクションは定義されたインターフェースを通じて移動できる。購入者は、すべてのワークフローを再構築することなく、アーキテクチャ上の選択肢を得られる。

より強いプラットフォームバンドルは、この主張を弱める可能性がある。既存ベンダーが許容可能なストレージ経済性と成熟したセキュリティエージェントを組み合わせれば、顧客は単一の運用スイートを選ぶかもしれない。インシデント時には、利便性と説明責任がアーキテクチャ上の優雅さより重要になることが多い。

セキュリティリーダーは、最終的なアーキテクチャを直ちに選ぶ必要はない。高コストまたは分断されたワークロードの1つに対して、Databricksモデルをテストできる。過去の脅威ハンティング、クラウド監査分析、検知開発は、範囲を限定した出発点になる。

パイロットでは、既存のワークフローを維持しながら、比較可能な測定値を生成すべきだ。チームはデータを移す前に成功基準を定義すべきである。また、テレメトリーの正規化と検知の信頼性維持に必要な作業も記録すべきだ。

有用なレビューでは、5つの問いを投げかける。新しいシステムは、より多くの関連データを保持できたか。アナリストはより迅速に調査できたか。検知は改善したか。総運用工数は減ったか。ガバナンスは理解しやすいままだったか。

その答えは、レイクハウスがセキュリティの運用レイヤーになりつつあるのか、それとも単なる新たなログの保存先なのかを示す。また、ベンダーがしばしば一緒に提示するAIの価値とストレージの価値を切り分けることにもなる。

Databricksは、現実的な制約を見極めている。エージェントは、分断され、アクセスしにくく、ガバナンスが不十分なセキュリティデータを補うことはできない。そのガイドは、セキュリティリーダーに対し、そのデータをどこに置き、誰が管理するのかを再考する理由を与えている。

未解決の問題は運用上の信頼だ。データプラットフォーム企業は、最前線の防御システムに期待される信頼性、セキュリティコンテンツ、対応制御、説明責任を提供できるのか。

databricks google architectureを評価するチームにとって、次の一手は即時の置き換えではなく、慎重な比較である。1つの調査ワークフローを選び、その権限を定義し、ベースラインの結果を記録する。そのうえで、アクセス範囲を広げたり隠れた作業負担を増やしたりせずに、統合されたコンテキストが判断を改善するかを検証する。その証拠は、製品デモに登場するエージェントの数よりも重要になる。