セキュリティデータのセマンティックレイヤー戦争：Google SecOps 検索仕様の背後にあるコンピュート経済学

コスト削減を教える文書が、業界全体の構造変化を露呈させた

Google Security Operations（旧 Chronicle）が、UDM 検索のベストプラクティスに関する文書を公開した。一読すると、典型的なベンダーの技術文書に見える。フィールドについて、演算子について、パフォーマンスチューニングについて、トラブルシューティングについて書かれている。

しかし文脈に戻して読むと、この文書は実はもっと大きなことを語っている。現代のセキュリティ運用プラットフォームにおいて、検索はもはや無償の行為ではない。

文書は冒頭で警告を発している——クエリの構築が不適切であれば、検索は大量の計算リソースを消費し、パフォーマンスはインスタンス内のデータの規模と複雑さによって変動する。その後、まるでコストコンサルタントのような口調で、「高性能フィールド」「除外されるフィールド」「時間範囲の絞り込み方」を項目ごとに列挙していく。

これは文法の授業ではない。計算資源の経済学である。セキュリティ製品の公式文書が、ユーザーにいかにコストを抑え、いかに計算を減らし、いかにデータをスキャンしないかを教えるために大量の紙幅を割かなければならないということは、セキュリティ運用の中心的矛盾が「攻撃を可視化できるか」から「可視化する余裕があるか」へと移行したことを意味している。

フィールドのホワイトリスト：スキーマこそがインフラの権力

この文書で最も情報量が多い部分は、クエリのシナリオごとに明確な「高性能 UDM フィールド」の一覧を示していることだ。メタデータ、主体（principal）、送信元、宛先、ネットワーク、セキュリティ結果——六つの大分類のフィールドが一つずつ列挙され、これらのフィールドが「高速な検索のために最適化されている」と明記されている。

これは成熟しているがしばしば見落とされる事実を反映している。統一データモデルは単なるデータ仕様ではなく、検索能力の境界を定義するものだ。

生のログの世界では、あらゆるフィールドが理論上検索可能であり、その代償は全表スキャンである。UDM の世界では、一部のフィールドはインデックスと検索パスに組み込まれ、別のフィールドは原文の中に生き、必要な時だけ解析される。この階層化は技術的な細部ではなく、製品設計者が未来のセキュリティ調査のあり方に対して行った賭けである——彼らは、調査員が実際に頻繁に使うのはホスト名、IP、ファイルハッシュ、プロセス ID、ユーザー識別子、メールアドレス、HTTP メソッド、セキュリティルール名だと考える。

この一覧自体が「セキュリティ調査行動学」の横顔である。現代の脅威ハンティングの原子単位は、自由記述のテキストではなく、関連付け可能なエンティティ識別子なのだ。

競合にとって、この一覧はさらに一つの壁である。フィールドを定義する者が、検出ルールの書き方、アナリストのメンタルモデル、そしてこのプラットフォームから移行するコストを定義する。スキーマは決して中立ではなく、インフラの権力の具体的な形態なのだ。

意図的に除外されたフィールド：計算資源の経済学が露わにする片隅ドキュメントには、まれに見る率直な一節がある：一部のフィールドは意図的に検索フィルターから除外されており、それには metadata.id、metadata.product_log_id、およびすべての *.timestamp フィールドが含まれる。理由は非常に直接的だ——これらのフィールドの一意の値が高いカーディナリティ（high cardinality）をもたらし、統計的な分散を生じさせ、検索パフォーマンスを損なう。

この一文は何度も読み返す価値がある。

可観測性とセキュリティデータの領域では、高カーディナリティは常にコスト構造において最も厄介な相手だった。数百万、さらには数十億の一意の値を含むフィールドを、効率的にインデックス化することはほぼ不可能だ。ベンダーがそれに対して取れる選択肢は2つだけだ。無理に耐えてコストをユーザーに転嫁するか、それを高速検索レイヤーの外に締め出し、必要なときにユーザーにより高い代償を払わせるかだ。

Google は後者を選び、しかもそれを公開ドキュメントに書き込んだ。これは、セキュリティデータプラットフォームでは、すべてのデータが生まれながらにして平等なわけではないということを認めたことを意味する。

さらに微妙なのは、タイムスタンプがこのカテゴリに含められている点だ。時間は本来、セキュリティ調査における第一の次元であるはずだ。しかし、まさに時間が取り得る値がほぼ無限であるために、費用対効果の高い完全一致条件として用いることはできない。ドキュメントが示す代替案は、Unix epoch 秒数で比較するか、YARA-L の時間関数を呼び出して日付を変換することだ——言い換えれば、「人間が読める時間」を「機械がインデックス化できる整数」に翻訳し、その変換コストをユーザーが負担するということだ。

これは典型的なエンジニアリング上の妥協であり、典型的なビジネスモデルの選択でもある。

二つの時計：イベント時間と取り込み時間の分裂

ドキュメントにある、もう一つ見落とされがちだが重要な意味を持つ細部は、「新しく取り込まれたがタイムスタンプが古いデータ」に関する説明だ：検索の時間範囲は、解析後のイベントタイムスタンプに基づいており、元のログの取り込みタイムスタンプではない。

さらに、その対処法まで示している——古いイベントタイムスタンプの中から新しく取り込まれたログを検索する場合は、All time オプションを使用し、代わりに metadata.ingested_timestamp をクエリしなければならない。

その背景には、ストリーム処理の領域における古くからの問題が、セキュリティの場面で再演されていることがある：イベント時間（event time）と処理時間（processing time）の分離だ。分散システムでは、ログの遅延到着、クロックドリフト、プロキシキャッシュ、オフライン機器からの後追い送信などによって、データの到着時間とイベントの発生日時が切り離される。

そしてセキュリティ調査では、この技術的な細部が結論の正誤を直接左右する。ある侵害のタイムラインを再構築する際、アナリストが検索ウィンドウを既定で取り込み時間によって区切られていると想定すると、攻撃者が数週間前に仕込んだものの、今日になって初めてアップロードされたログを完全に見落とす可能性がある。さらに深い問題は：セキュリティプラットフォームが「時間」という概念を2つのフィールドに分割することは、実は時間のセマンティクスの解釈権を部分的にユーザーに返上していることになる。これは柔軟性であると同時に、責任の移転でもある。プラットフォームが「どの時間が重要か」をあなたの代わりに決めなくなったとき、アナリストは本来データエンジニアリングに属する問いに自分で答えなければならなくなる。

エンティティとイベントの分裂：コンテキストデータは別個に扱われる

ドキュメントは明確に指摘している：metadata.log_type = "..." を使って AZURE_AD_CONTEXT、WORKSPACE_USERS のようなエンティティやコンテキストのログタイプを検索すると、空の結果が返される——なぜなら UDM 検索は UDM イベントレコードのみをクエリするからだ。これらのデータにアクセスするには、graph 構文に切り替え、graph.metadata.event_metadata.log_type や graph.entity.user.email_addresses のようなパスを通す必要がある。

この細部が明らかにするのは、セキュリティデータアーキテクチャの分岐である：イベント（events）とエンティティ（entities）は分離して保存・クエリされるようになっている。

イベントは「何が起こったか」であり、エンティティは「誰が誰であるか」である。過去10年間、SIEM は主に前者を扱ってきた。しかし現代のセキュリティ運用は後者にますます依存している——アイデンティティグラフ、資産コンテキスト、ユーザープロファイル。攻撃者が一度のイベントだけで自らを露呈することは稀である；彼らの痕跡は大量のイベントに分散しており、エンティティを通じてイベントを繋ぎ合わせて初めて、異常が浮かび上がる。

まったく異なる構文でエンティティデータをクエリすることは、アーキテクチャ上のシグナルである：エンティティデータはイベントの付属物ではなく、別の独立したモデリングと最適化を必要とするデータ構造である。これはまた、グラフクエリ（graph）が脅威インテリジェンス専用のツールにとどまらず、セキュリティプラットフォームの標準機能になりつつある理由も説明している。

スタートアップエコシステムにとって、ここには明確な機会の窓が存在する：エンティティ解決、アイデンティティ正規化、クロスソースのエンティティアラインメントは、SIEM とは独立したインフラストラクチャの層になりつつある。

重複フィールドと any の沈黙の罠

ドキュメントには「重複フィールド」に関する説明が一段落ある。口調は淡々としているが、結果は小さくない。principal.ip、target.file.md5 のようなフィールドは、単一のイベント内に複数の値を保存できる。デフォルトでは、それらは any オペレータで評価される：フィールド内のいずれか一つの値が条件を満たせば、述語全体が真となる。

ドキュメントに示された例は非常に代表的だ。principal.ip != "1.2.3.4" を検索するとき、あるイベントが 1.2.3.4 と 5.6.7.8 を同時に含んでいても、そのイベントは依然としてマッチする。なぜなら 5.6.7.8 が「等しくない」という条件を満たすからだ。

人間のアナリストにとって、これはほとんど直感に反する。自動検知ルールを構築するエンジニアにとって、これは誤検知と検知漏れを直接引き起こしうる罠だ。

これはより一般的な問題を明らかにしている：セキュリティクエリ言語のセマンティクスは、専門的に学ぶ必要のある学問になりつつある。論理演算子の振る舞いがデータモデル内部のストレージ構造に依存するとき、検知エンジニアリングはもはや「正しいロジックを書くこと」だけではなく、「基盤となるデータ構造がどのように評価されるかを理解すること」になる。

これはまた、なぜドキュメントがわざわざ、括弧内の論理演算子に上限（169 個）があること、列挙型フィールドに正規表現を使えないこと、RE2 エンジンの挙動を別途説明する必要があることに言及しているのかを説明している。セキュリティクエリ言語の複雑さは小さなプログラミング言語に迫りつつあり、そして新しい言語が生まれるたびに、新たな専門分業が生まれる。

AI 調査エージェントの前提条件は、このドキュメントに書かれている

このドキュメントを未来への布石として読むなら、最も興味深いのは、AI セキュリティエージェントが機能するために先に満たさなければならない条件を、意図せず定義している点だ。

条件一：クエリコストは予測可能でなければならない。自律的に動作する調査エージェントが、探索的なクエリのたびに制御不能な計算資源消費を引き起こしうるなら、誰もそれを自由に行動させようとはしない。フィールドのホワイトリスト、時間枠の制約、除外された高基数フィールドは、本質的にはコストモデルを予算化可能にするものだ。

条件二：セマンティクスは確定していなければならない。any 演算子のデフォルトの振る舞い、繰り返しフィールドの要素ごとの評価、イベント時間と取り込み時間の区別。これらはエージェントが正確に把握し、曖昧にしてはならないルールだ。機械は直感に頼ってセマンティクスの罠を回避することはできない。

条件三：インターフェースは構造化されていなければならない。ドキュメントは、大規模な値マッチングの代わりに参照リスト（reference lists）を使い、人間向けの時刻文字列の代わりに Unix epoch を使い、自由テキスト検索の代わりに明確なフィールドパスを使うことを推奨している。これらはすべて、「調査」を曖昧な人間の活動から、プログラムから呼び出し可能な一連の確定した手順へ作り変えるものだ。

言い換えれば、agentic SOC のような概念は、まずエージェントがあり、それからプラットフォームに適応するというものではない。実際の順序はちょうど逆だ：プラットフォームがまずデータモデル、クエリセマンティクス、コスト境界を機械が利用できる形式に整理し、それによってエージェントが居場所を得る。このドキュメントは、その準備作業の一部である。ただし、ドキュメント自身はそう述べていないが。

スキーマ標準化：静かだが決定的な競争## スキーマ標準化：静かだが重要な競争

視点を引いてみると、このドキュメントが置かれている戦場は、セキュリティデータスキーマ（schema）の標準化競争である。

一方はベンダー独自スキーマ、たとえば Google の UDM だ。その利点は深い最適化と自社の検索・検出エンジンとの緊密な統合にある。代償は移行コストとエコシステムの閉鎖性だ。もう一方は業界連合が推進するオープンスキーマの方向性であり、異なるソースのログに一貫したフィールドセマンティクスを持たせ、クロスプラットフォーム連携の障壁を下げることを目指す。

この競争が記者会見やマーケティング合戦の形で公衆の前に現れることはない。それはもっと地味な場所に現れる。フィールド命名、検索可能フィールド一覧、タイムスタンプの表現方法、エンティティとイベントを分離するかどうか、正規表現エンジンの選択。

しかしこれらの細部が次世代の現実を決める。検知ルールがクロスプラットフォームで再利用できるか、脅威インテリジェンスが組織間で交換できるか、AI エージェントが異なるベンダーのデータを理解できるか、そしてセキュリティチームがロックインされる前にどれだけ交渉の余地を残せるか。

結語：セキュリティ運用はストレージビジネスからセマンティックレイヤービジネスへ変わりつつある

過去20年間、SIEM の中心的物語は「ログを集約すること」だった。ストレージはコストであり、検索は機能だった。

今やこの関係は逆転している。ストレージは比較的安価であり、データを検索可能にし、関連付け可能にし、機械が理解できるようにすることこそが、真に高価で真に価値のある部分なのだ。

この Google SecOps ドキュメントの価値は、どの文法を教えているかではなく、新しいゲームのルールを正直に露呈している点にある。フィールドには階級があり、時間には曖昧さがあり、クエリには価格があり、セマンティクスには境界がある。

これらの境界を定義できる者は、単にセキュリティプラットフォームを売っているのではなく、セキュリティ調査そのものの文法を定義している。これはどの製品発表よりも注目に値する。

---

情報源：Search best practices | Google Security Operations