SIEMは死んだのか？ Scanner事例で見直すセキュリティログ運用

“

この記事は Sequoia Capital の Scanner 紹介記事をきっかけに、変化しやすい資金調達額や市場規模ではなく、セキュリティログ運用の設計論点に絞って整理しています。

「SIEM は死んだ」という見出しは強いですが、実務で重要なのは勝敗表ではありません。問題は、ログをどこに保存し、どこまで検索可能にし、検知や調査をどのレイヤーで回すかです。

Scanner のような data-lake-first の製品が注目される理由も、単なる新興ベンダーの話ではなく、従来の取り込み課金型 SIEM だけでは 保持したいログ量 と 検索したいログ量 がずれやすいからです。ここに AI エージェントや MCP / API 連携が重なると、論点はさらに広がります。

この記事では、特定ベンダーの現在地を追うより、今後も使い回せる設計観点として次の4つを整理します。

---

この記事でわかること

1. なぜ「SIEM をやめるか」より「どのログをどこまで検索可能に保つか」が重要なのか
2. data lake と SIEM を分けて考えるときに、どの責務を切り出すべきか
3. AI エージェントがログ調査に入るとき、MCP / API 連携より先に決めるべき境界は何か
4. 日本企業がログ基盤を見直すときに、どの順番で棚卸しすべきか

基本情報

---

「SIEMは死んだ」というより、検索可能な保持設計が問われている

実務で起きているのは、SIEM が一夜で不要になる話ではありません。多くの組織では、ログが次の3層に分かれます。

問題は保存場所そのものではなく、調査に必要な期間のログが、必要な速度で引けるかです。S3 や Blob Storage に置いているだけでは、証跡として残っていても、インシデント対応の現場では使いにくいことがあります。

この観点で見ると、Scanner のような製品が提示しているのは「SIEM の終焉」ではなく、検索可能な保持期間をどこに置くかという再配線です。ホットな検知基盤、長期保管、対話的な検索を 1 つの箱で解くのではなく、責務ごとに分けて設計し直す流れだと捉える方が実務に近いです。

---

Data-lake-first の設計で先に決めるべき4つの問い

Scanner を含む data-lake-first の話題で本当に重要なのは、製品名より次の問いです。

1. どのログを再水和なしで検索できるか

長期保管したログを調査時に取り戻す運用では、検索のたびにコストと待ち時間が増えます。確認したいのは次の点です。

• 直近 30 日だけでなく、事故調査に必要な期間を対話的に引けるか
• 検索対象を source / tenant / dataset ごとに絞れるか
• 生ログと正規化後フィールドのどちらを source of truth にするか

2. 検知ロジックをどこで実行するか

データレイクにログを置くだけでは、検知基盤にはなりません。設計時には、次を分けておく必要があります。

3. index と raw data の ownership をどう置くか

data-lake-first の製品を評価するときは、raw log は自社クラウドに残るか だけでは不十分です。実務では次も重要です。

• index や metadata がどこに置かれるか
• 解除時にどの成果物が残るか
• アクセス権を storage / query / admin で分けられるか

ログ基盤は、導入時よりも調査・監査・契約更新時に差が出ます。ownership の境界が曖昧だと、運用が始まった後に困ります。

4. 調査の最終成果物をどこに残すか

ログ検索ツールが優れていても、最終的に必要なのは 誰が、何を見て、どう判断したか の記録です。

• 調査クエリ
• 参照したログ断片
• 検知からエスカレーションまでの流れ
• human approval の有無

この evidence chain を case 管理や ticketing に戻せないと、検索が速くなっても SOC の統制は良くなりません。

---

Scannerのような製品は、SIEMの代替というより補助線として見る

現場で使いやすい見方は、製品を「全部置き換える箱」ではなく、レイヤーごとに置くことです。

この整理にすると、「Scanner は SIEM を完全に置き換えるのか」という問い自体が少しずれます。実際に必要なのは、どのレイヤーを今の基盤で持ち、どのレイヤーに別の道具を足すかの設計です。

ベンダー比較でも、固定のランキングより次の質問の方が役に立ちます。

1. 高頻度で見るログと、めったに見ないが消せないログは分離できているか
2. lake 側の検索結果を、既存の case / SOAR / ticket に戻せるか
3. raw data、index、investigation note の ownership が分かれているか
4. 解除や障害時に、調査の継続手段が残るか

---

AIエージェントがログ調査に入るなら、MCPより先に承認境界を決める

Scanner の話題で目を引きやすいのが AI エージェント連携です。ここでも追うべきなのは採用率ではなく、agent が何を読めて、何を実行できて、どこで止まるかです。

MCP や API を使えば、エージェントにログ検索を渡すこと自体は可能です。ですが、実務では接続そのものより次の4点が重要です。

1. Tool boundary

• agent が read-only query だけを実行するのか
• saved search や detection rule の変更まで許すのか
• case 更新や外部送信まで一続きにしてよいのか

2. Approval boundary

次の action は human approval を挟む方が安全です。

• 検知ルールの本番反映
• block / quarantine / disable のような是正措置
• 他システムへの横断検索
• 個人情報や機微データを含む証跡の共有

3. Evidence boundary

agent が返した要約だけでは監査に弱いことがあります。少なくとも次を残せるか確認します。

• 実行した query
• 参照した期間と dataset
• 要約の根拠となる raw log または normalized event
• human reviewer の判断結果

4. Replay / rollback

AI 支援調査を導入するときは、成功率より止め方の方が重要です。

• 誤検知時にどの rule / prompt / tool policy を戻すか
• incident review で同じ query を再実行できるか
• provider や model を切り替えたときに挙動差分を比較できるか

要するに、AI エージェントは調査速度を上げる可能性がありますが、統制まで自動で解いてはくれません。ログ基盤と agent workflow をつなぐなら、approval と evidence を先に設計する必要があります。

---

日本企業が先に棚卸ししたいポイント

日本企業では、ログ基盤の見直しが ツール入れ替え の議論に寄りやすいですが、実務では順番が重要です。

1. 保持期間ではなく「検索可能期間」を出す

監査向けの retention period と、SOC が実際に引ける期間は別物です。まずは次を一覧化します。

• どのログソースを何日検索できるか
• どこから先は archive 扱いか
• 取り出しに何時間かかるか

2. SOC と platform の責務を分ける

検索基盤の ownership が platform 側、検知と case が SOC 側、という分業はよくあります。ここで重要なのは、障害時と例外時の handoff です。

• index 障害時に誰が復旧するか
• schema 変更を誰が管理するか
• 外部 MSSP や委託先がどこまで見られるか

3. 規制・監査対応を「保存」だけで終わらせない

長期保管が必要でも、調査不能なら運用上の価値は限定的です。規制や内部監査がある組織ほど、次を確認した方が安全です。

• evidence export の形式
• approval の記録方法
• 調査メモと raw data の紐付け
• case close 後の再検証手順

4. AI支援調査を PoC で切り離す

最初から自律応答までつなげる必要はありません。PoC では次の順番が現実的です。

1. read-only の query assistant として使う
2. 調査メモ生成まで広げる
3. detection tuning の提案に使う
4. 承認付きの response automation を別途評価する

この順番なら、agent の価値と統制コストを分けて見られます。

---

よくある質問（FAQ）

Q1. Data lake があれば SIEM は不要ですか？

必ずしも不要にはなりません。直近の検知やアラート処理は hot path に残し、長期の検索や再調査を lake 側に寄せる構成も現実的です。重要なのは製品名ではなく、レイヤーごとの責務分離です。

Q2. 検索が速ければ、それだけで十分ですか？

十分ではありません。検知ルールの ownership、調査結果の evidence export、ticket / case への handoff がなければ、調査速度が上がっても統制は強くなりません。

Q3. AIエージェントを使うと何が一番変わりますか？

変わるのは query 実行速度より、承認境界の設計です。agent にどこまで read/write を渡すか、何を human approval に残すかが一番大きな論点です。

Q4. 最初の見直しはどこから始めるべきですか？

まずは 検索可能期間 の棚卸しからです。保持日数、archive の取り出し時間、hot path に残すログの基準を並べると、構造的なボトルネックが見えやすくなります。

Q5. ベンダー比較で追うべき指標は何ですか？

固定の市場シェアより、searchable retention、index ownership、detection portability、approval / audit trail の4点を優先して比較する方が実務に効きます。

---

まとめ

Scanner をめぐる議論が示しているのは、「SIEM が死ぬ」という単純な話ではありません。セキュリティログ運用が、保存 と 検索 と 検知 を同じ箱で抱える設計から、責務ごとに分けて考える設計へ移っていることです。

実務で見るべきなのは、資金調達や市場予測ではなく、どこまでのログを検索可能に保つか、どのレイヤーで detection を回すか、AI 支援調査の承認境界をどう置くかです。ログ基盤を見直すなら、まずは searchable retention と evidence chain を定義するところから始めると、製品比較もぶれにくくなります。

---

関連記事

---

参考リソース

• Sequoia Capital「Partnering with Scanner」
• Jump Capital「The SIEM Stack Is Breaking」
• Scanner Documentation

---

本記事はネクサフローのAI・セキュリティ分析シリーズの一部です。