はじめに

Sysdig 運用サービスとして、Sysdig Secure の MSP サービスを提供しているなかで、お客様から受ける管理のための相談があります。

「全プロダクトの対応状況を横断で見たい」「この Zone は安全だと、根拠をもって説明できる状態にしたい」というものです。

Sysdig Secure には MCP (Model Context Protocol) ツールが提供されており、Claude から直接 API を呼び出すことができます。 Sysdig Secure には Zone という強力な管理単位があり、これを軸にお客様の環境を 深く管理することが、MSP として提供する価値の核心だと考えています。

本記事では、Zone 管理をさらに深く実現するために私が構築した仕組みを紹介します。
大きな構成は「Sysdig API を叩く CLI」「Claude が参照する docs」 「Spreadsheet による管理レイヤー」の 3 つです。

この仕組みが実現すること

この仕組みが目指しているのは、「セキュリティ対策できています、と根拠をもって社内外に説明できる状態を継続する」ことです。

まず前提となる Zone の考え方を説明した上で、実現できることを紹介します。

Zone の活用

Sysdig Secure には、Zone という管理単位が提供されています。

複数の AWS アカウントや Google Cloud プロジェクトなどを自由に組み合わせてスコープを定義でき、 プロダクトや環境単位で影響を把握できる仕組みです。

MCP や Headless Cloud Security はそれぞれの用途に強みを持つ機能です。
しかし、執筆時点 (2026年7月) では、 MCP のみを使用した場合、Zone ごとの管理のニーズを満たせませんでした。

今回は Zone を軸とした管理に特化した使い方を実現するために、 Sysdig API を直接活用する CLI を追加で作成しました。
これにより、お客様ニーズを満たすためのアプローチを行い、ギャップを埋めることができました。

Zone（プロダクト）単位の状態把握

「全体のリスク件数」ではなく、「このプロダクトは今月どういう状態か」を問うと、Claude が Sysdig のデータを取得・分析し、判断と推奨アクションをセットで回答します。
※以下は回答イメージです。

Q: 全プロダクトのセキュリティ状態を教えてください
A: （全 Zone の Risk を集計し、以下のようにプロダクト別に回答する）

ProductA_Zone: Critical 1件 / High 3件。CVE-2024-2961 が外部公開リソースに影響。48時間以内の対応を推奨。
ProductB_Zone: Critical なし / High 5件。すべて isNew:false のため対応遅延の可能性あり。MSP に計画提出を指示してください。

横断的な CVE 影響調査

新規 CVE が公表された際に、全プロダクトへの影響を即座に確認できます。
※以下は回答イメージです。

Q: CVE-2026-31431 はどのプロダクトに影響しますか
A: 3 Zone に影響。うち ProductA_Zone は外部公開リソースへの影響があり最優先。CISA KEV 掲載済みのため即時対応が必要。

管理者向けの Spreadsheet エビデンス

AI の回答だけでなく、全 Zone × CVE の分布を Spreadsheet で管理・追跡できます。
これは、経営・監査向けの説明材料として機能します。

AI は、推論することは得意ですが、大規模なデータセットの集計や数値の正確な処理は苦手です。

数値の取り違えやデータの欠落が発生しやすいのは、LLM の特性によるものです。
そのため、コマンドは AI を経由せず直接 CSV を生成し、 Spreadsheet にインポートすることで Zone ごとの影響マトリクスを作成します。

これらのいずれの仕組みにおいても、Zone を主体として管理可能としています。
管理層の関心は「どのプロダクト (Zone) が安全か」であり、AWS Account ID 単位の情報は粒度が細かすぎることが多いためです。
プロダクト単位でスコープを切れる Zone は、この管理粒度に合致します。

これらを支えているのが、以下に説明する 3 層の構成です。

実現の裏側

なぜ Zone 専用の CLI を作成したのか

Sysdig の MCP ツールは、Runtime Events の取得や Response Actions の実行など、Detection & Response 管理においては強力です。
Claude から直接「このコンテナを隔離して」と指示できる体験は、今後の Security Operations の姿を先取りしていると感じます。

今回の目的は、これとは異なる領域、Attack Surface Management における Zone 単位の継続的な管理です。

Sysdig の Zone はプロダクトや環境単位でスコープを定義できる、設計として 非常に優れた概念です。
この Zone を管理の主体として、全 Zone を横断的に 集計・比較し、毎回同じ粒度でデータを引き出せる仕組みを作ることが、 「管理に使う」というお客様のニーズに応える最善の方法だと判断しました。

MCP による問い合わせと、Zone 専用 CLI による定期的なデータ収集は、 用途の異なる補完的な手段です。両者を組み合わせることで、 Detection & Response と Attack Surface Management の両領域をカバーできます。

構成の全体像

構築した仕組みは 3 層に分かれています。

データ収集層 — CLI（sysdig-by-zone）

Sysdig API を叩き、Zone ごとの Risk・脆弱性・Posture・Identity・Compliance データを JSON / JSON Lines 形式で出力する TypeScript 製の CLI ツールです。
Claude からの利用を前提として設計しており、「Claude がこの出力だけで分析を完結させる」ことを原則にしています。

本ツールは Claude Code を用いて作成しました。

知識層 — docs

Sysdig の概念説明、お客様からの想定問答、分析シナリオを Markdown で記述したドキュメント群です。
Claude はお客様の質問に対して、どのツールを用いてデータを収集し、管理するのか。
この docs を参照しながら分析・回答を組み立てます。

管理レイヤー — Spreadsheet

脆弱性マトリクス（全 Zone × CVE 分布）とコンプライアンス・マトリクスを Spreadsheet で管理可能なように CSV で出力します。
AI が答え、人間が承認・追跡するという役割分担を実現する層です。

この 3 層が揃ってはじめて、「AI for Security を管理に使う」という要件に答えられると考えています。

なぜ JSON Lines か

CLI の出力形式として JSON Lines（JSONL）を選んだことには、明確な理由があります。

JSON Lines は 1 行 1 レコードのフォーマットです。
Claude にデータを渡す場合、全件をコンテキストに載せるとトークン消費が膨大になります。
JSON Lines にしておくと、grep で特定条件の行だけを事前に絞り込んでから Claude に渡すことができます。

たとえば次のような使い方です。

# CISA KEV に掲載されている CVE のみ取得
pnpm start vulns --format jsonl --group-by cve | grep '"isCisaKev":true'

# Critical リスクのみ取得
pnpm start risks --format jsonl | grep '"severity":"Critical"'

Claude にとって、1 行 1 レコードという構造は処理しやすいフォーマットです。
全件を渡さずに済む設計は、コンテキストウィンドウの有効活用につながります。

一方で、人間が管理する用途には通常の JSON が適しています。
JSON は他ツールとの連携に適しており、構造化されているため集計処理などに向いているためです。

CLI は --format json と --format jsonl を切り替えられる設計にしており、用途によって使い分けます。
また、出力の最長行長（wc -L）を 1,000 文字以下に保つことを開発指針としており、LLM のコンテキスト消費を設計段階から意識しています。

「LLM が使いやすいデータ形式は何か」を突き詰めると、人間がツールに合わせるのではなく、ツールが LLM に合わせる必要があるという発想に辿り着きます。

Spreadsheet との組み合わせ

AI が分析し、人間が管理する。この役割分担を実現するのが Spreadsheet との連携です。

CLI には、全 Zone と全 CVE を掛け合わせた分布を CSV で出力するコマンドがあります。

pnpm start vulns matrix
pnpm start compliance matrix

この出力には、各 Zone について CVE ごとの深刻度、外部公開状態、実行中パッケージへの影響、EPSS スコア、CISA KEV への掲載有無などが含まれます。
これを Spreadsheet に取り込むことで、プロダクト担当者が「自分の Zone に影響する CVE はどれか」を一覧で確認できる状態が作れます。

重要なのは、この CSV が「Claude が回答に使うデータ」ではなく「人間が管理・追跡するためのエビデンス」として機能する点です。

Claude は個別の問いに答えるのが得意です。
「この Zone は今月安全か」「対応が遅れているプロダクトはどこか」といった問いに、docs の知識を踏まえて答えます。
しかしその回答の証跡、つまり「どのデータに基づいて判断したか」を継続的に残すのは Spreadsheet の役割です。

お客様が本当に必要としているのは、「AI が答えてくれた」という体験ではなく、「社内外に根拠をもって説明できる管理状態が継続する」ことです。
その継続性を担うのが Spreadsheet です。

docs で Claude に文脈を渡す

データがあるだけでは、Claude は適切な回答を出せません。
Sysdig 固有の概念や、お客様の環境に固有の文脈を Claude が理解していないと、データを正しく解釈できないからです。

そこで docs を整備しました。構成は大きく 2 つに分けています。

シナリオ（顧客ニーズ対応） は、お客様の問いを起点に、どのコマンドを実行し、結果をどう解釈すべきかを記述したものです。
「月次レポートを作りたい」「新規 CVE の影響を全プロダクトで確認したい」「この Zone は安全か判断したい」といった問いに対して、判断基準と手順を明文化しています。

分析リファレンス は、Sysdig の概念（Risk の Severity 判定ロジック、In Use パッケージの定義、Zone の扱い方など）を出典付きで記述した知識ベースです。
Claude がデータを解釈する際の根拠となります。

運用していくと、docs の問題点も見えてきました。
たとえば、「対応が遅れているプロダクト」の判断基準がシナリオに明記されていなかったために、Claude が独自に基準を作り、一部の Zone に適用しなかったという事例がありました。
判断基準は docs に明記し、「全 Zone に同一基準を機械的に適用すること」という制約も合わせて書くことで再現性が高まります。

また、データが欠落している状態で Claude が内容を推測して回答してしまうケースもありました。
docs に「データが欠落している項目について内容を推測して記載することを禁止する」と明記することで、この問題を抑制できます。

docs の品質が、Claude の回答品質を大きく左右します。
これは運用を通じて痛感したことです。

まとめ

Sysdig Secure を「管理に使う」という要件に答えるために、MCP だけに頼らず、CLI・docs・Spreadsheet を組み合わせた仕組みを構築しました。

AI for Security の本質は、AI が全部やることではないと考えています。
AI が問いに答え、Spreadsheet に証跡を残し、人間が承認・指示する。
この構造があってはじめて、「セキュリティ対策できています、と根拠をもって言える状態」が継続します。

アイレットでは、Sysdig Secure を活用したマネージドセキュリティサービス (Sysdig 運用サービス) を提供しています。
本記事で紹介した仕組みのように、お客様の環境に合わせた AI 活用の設計・運用支援もご相談いただけます。
興味のある方は、ぜひお声がけください。