Scannerをどう読むか？Security Data Lake運用の整理

Scannerを理解するとき、最初に見るべきなのは単発ニュースや顧客名ではありません。より durable なのは、security team が「保持」「探索」「検知」「引き継ぎ」を object storage の上でどう成立させるかです。Scanner の公式 site と docs を読むと、この product は Security Data Lake を短期間で組み上げ、query を中心に運用するための layer として設計されています。

本記事では Scanner の official site、docs、blog を起点に、Scanner を security data lake の operating guide として読む論点を整理します。単発の発表や company snapshot は後半の dated snapshot に分け、前半は S3 上のデータ保持、indexing、search、detections、deployment choice に絞ります。

この記事でわかること

1. Scannerを何として読むべきか: 安い SIEM 代替ではなく、S3 上のデータ保持と query runtime を束ねる security data lake として捉える
2. どこに価値が出るか: ingestion、indexing、query、detections が同じ設計の上でどうつながっているか
3. どこが導入判断になるか: deployment choice、index storage、event sink、owner 設計をどう見るか
4. どこを dated snapshot に回すべきか: headline announcement、顧客ロゴ、AI workflow の派手な事例をどの距離感で読むか

基本情報

---

Scannerを何として読むべきか

Scanner の home と docs は、この product を単なる検索ツールではなく、logs を自分の S3 に残したまま検索・検知・自動化へつなぐ security data lake として説明しています。ここで重要なのは「既存 SIEM より安いか」だけではありません。より本質的なのは、保持と探索を同じ query-centric な設計に寄せていることです。

この視点で見ると、Scanner は次の 4 面に分解できます。

つまり Scanner の本質は、security data をどこへ送るか より security data をどう retain し、どう query に変えるか にあります。ここを見ずに headline news や customer logo だけを追うと、記事はすぐ古くなります。

論点1: Data custody と indexing が本体

How it Works の docs では、Scanner の core design principles として、logs は customer の S3 に残し、Scanner は compact な index files を追加する構造が前面に置かれています。schema を先に固定した SQL table へ ETL するのではなく、raw logs を読んで index を作り、そこから selective scan を成立させる流れです。

この設計を読むときは、次の 2 点が特に重要です。

1. 保持と検索が分離されていない raw logs を残す場所と query の入り口が同じ data lake に寄るため、「安く残すが探せない」を避けやすくなります。

2. index 追加の trade-off が明示されている docs では、uncompressed logs 1 TB あたり index files が約 150 GB という storage ratio の目安が示されています。つまり Scanner は「追加 storage を払って query を成立させる」設計です。

この構造は、security team が retention policy を考えるうえで実務的です。どの logs を長期保持するか、どこまで raw のまま残すか、index files の lifecycle をどう設計するかを、製品選定の早い段階で考えやすくなります。

論点2: Query-centric design が incident response を変える

Scanner の docs では、ad-hoc query と continuous detections の両方が query-first infrastructure の上に乗ると説明されています。検索時には metadata database と index files を使って relevant な data region だけを特定し、Lambda workers が並列に処理します。

How Scanner Achieves Fast Queries の説明は、この product の読み方をかなりはっきりさせます。Scanner は scan を速くするというより、scan しなくていい領域を先に減らす 方向で設計されています。nested field や full-text search を含む security query を、そのたびに巨大な table scan へ落とさないことが価値です。

ここで見ておきたい運用論点は次の通りです。

docs 上の benchmark 例では、6 か月分の CloudTrail 調査で 10-15 TB を読む形から、2-5 GB の relevant region だけを見る形へ落とす説明があり、query time と cost の差もそこから導かれています。ここは timeless な保証というより、Scanner がどのボトルネックを潰そうとしているか を示す設計メモとして読むのが安全です。

論点3: Detections は saved queries として読む

Scanner を検索製品としてだけ捉えると、もう一つの本体を見落とします。How it Works と Detection Rule Engine の docs では、detections は「別の魔法」ではなく、query を継続評価する仕組みとして設計されています。

重要なのは次の 3 点です。

1. Any query can become a detection rule ad-hoc search で有効だった条件を、そのまま rule に昇格させやすい構造です。

2. indexing 時に detection 用の計算も進める aggregation を含む rule では、後から毎回 raw logs を読み直すのではなく、cached aggregation を参照する構造が取られています。

3. rules は code として持てる docs では GitHub と同期する detection-as-code の流れと、public repository から取り込める out-of-the-box rules が案内されています。

現時点の docs では、out-of-the-box rules は 400+ rules / 21 log sources と説明されています。ここで大事なのは rule 数そのものより、rule owner をどこに置くか です。SOC team が UI だけで管理するのか、platform / detection engineering team が GitHub repository で持つのかで、運用の安定性がかなり変わります。

また Detection Rule Engine の docs には、late-arriving logs を 1 週間まで再評価できること、aggregation を使う rule の方が storage 効率が高いこと、event sink として Webhook / SOAR / Slack / PagerDuty へ送れることが書かれています。Scanner を導入するなら、rule 数より どの query を rule 化し、どこへ通知し、誰が改善を回すか を先に決めた方が実務的です。

論点4: Deployment choice が governance と cost を決める

Scanner の docs は deployment model をかなり明確に切り分けています。ここを読むと、Scanner は単なる hosted SaaS ではなく、governance と infra ownership の取り方まで product の一部として設計していることが分かります。

How it Works の docs では、managed multi-tenant はおおむね 500 GB/day まで、single-tenant は 500 GB/day 以上が一つの目安として書かれています。BYOC / Self-hosted の docs では、Scanner 側が account を bootstrap して transfer する標準手順、同一 region 配置で transfer cost を避ける考え方、maintenance を Scanner 側が続ける model まで説明されています。

導入時は「どれが一番 secure か」より、次の順で見る方が分かりやすいです。

1. compute ownership をどこへ置きたいか
2. AWS 割引や budget を自社で使いたいか
3. ops 負担をどこまで受けるか
4. audit visibility をどこまで自前で持ちたいか

論点5: Automation と AI layer は最後に読む

Scanner の home page では MCP & APIs が product 面の一つとして置かれています。ただし、ここを product の本体として読むと逆に見誤りやすいです。automation layer は、fast query が先に成立しているから機能する上物 と考えた方が筋が通ります。

2025年12月1日の公式 blog では、Scanner MCP が remote MCP server として発表され、Claude Desktop、Claude Code、Cursor、Claude Agent SDK から security data lake へ structured access を与える使い方が説明されています。Sequoia の 2026年3月10日付記事でも、AI-driven security operations が投資理由の一つとして語られています。

ただし durable な読み方としては、次の順番を崩さない方が安全です。

1. retain できるか
2. query を速く回せるか
3. detections と event sinks を運用できるか
4. その上で automation や AI workflow をつなぐか

この順番にしておくと、MCP や AI workflow の派手さに引っ張られず、Scanner を security data lake の operating layer として評価しやすくなります。

---

導入前に見る問い

最後に、Scanner を「派手な AI セキュリティ product」として消費しないための問いを整理します。

1. どの logs を Scanner 側に残し、どれを既存 SIEM に置くのか retention と investigation pattern を分けて考えないと、どちらにも中途半端になります。

2. index files の owner は誰か storage ratio、S3 lifecycle、region 配置を誰が持つかを曖昧にすると、cost と visibility の議論がずれます。

3. どの ad-hoc query を rule 化するのか 検索体験が良くても、rule 化の owner がいないと運用資産になりません。

4. managed と self-hosted のどちらで責務を切るのか security posture より先に、compute ownership と運用負担の分界を決めた方が整理しやすいです。

5. automation や AI workflow を必須にするのか まず人間向けの investigation loop を回し、その後に API / MCP を足す方が設計ミスが少なくなります。

これらの問いに答えられるなら、Scanner は「新しい SIEM の話題株」ではなく、security data retention と query operation を組み替えるための設計選択として読みやすくなります。

---

Dated Snapshot

ここからは official source で確認できる内容だけを、時点メモとしてまとめます。下の内容は useful ですが、恒久的な product 定義として固定しない方が安全です。

この snapshot から分かるのは、Scanner が単なる「安い検索 SaaS」ではなく、security data lake、detections、automation をまとめて product 化しようとしていることです。逆に、次の話は固定せず、その都度 official source を見直した方が安全です。

• deployment の細かな要件や onboarding 手順
• query latency や cost の marketing 表現
• customer logo や case study の並び
• AI workflow の UI や連携先の説明

---

公式リソース

• Scanner Home
• What is Scanner
• How it Works
• How Scanner Achieves Fast Queries
• Detection Rule Engine
• Out-of-the-Box Detection Rules
• Bring Your Own Cloud (BYOC) / Self-Hosted
• Announcing Scanner MCP: Connect AI Agents to Your Security Data
• Scanner Raises Series A Led by Sequoia Capital
• Partnering with Scanner: Every Log Tells a Story—If You Can Find It Fast Enough

---

本記事はネクサフローのAI研究シリーズの一部です。