はじめに
前回の記事では、n8n を MCP サーバーとして OpenClaw に統合し、ワークフロー自動化の基盤を作りました。記事の最後に「今後の展望」としてこう書きました:
セキュリティアラート自動トリアージ: Sysdig アラート → 情報収集 → 重大度判定 → 通知
あれから取り掛かったのが、まさにこれ。自宅の Mac Mini 上で動く AI に、24 時間 365 日のセキュリティ監視を任せるという取り組みです。
Sysdig Secure が K8s クラスター上の脅威を検知し、Slack にアラートを飛ばしてくれる仕組みは前回までに出来上がっていました。しかし問題は、アラートが飛んできても結局は自分でダッシュボードを開いて、内容を確認して、深刻度を判断して、対応を考える——という手作業が残っていたこと。仕事中や深夜にアラートが来ても即座に対応できるわけがありません。
結論から言うと、OpenClaw を AI SOC アナリストとして仕立て上げることで、アラートの自動トリアージ・深掘り調査・Telegram 通知・日次サマリー生成まで、すべて AI が自律的にこなす世界を実現できました。
ただし、その道のりは「プロンプトを書くだけ」という単純な話では全くありませんでした。要件定義 8 ラウンドのレビュー、61 件の指摘事項、「検知と分析の役割分担をどう設計するか」という本質的な問いとの格闘——予想外のドラマの連続でした。
エンタープライズ SOC を自宅に作る
▲ SOC 導入前後の比較: 手動対応の世界から AI 常駐 SOC へ
Before: アラートが来ても見るだけの世界
これまでの運用はこうでした:
- Sysdig Secure がアラートを検知 → Slack
#security-alertsに投稿される - 自分がたまたま Slack を見たときに「あ、アラート来てる」と気づく
- Sysdig のダッシュボードを開いて内容を確認する
- 重大かどうかを自分で判断する
- 深夜や仕事中のアラートは翌日まで放置
ホームラボとはいえ、K8s クラスターを 4 ノードで運用していると、それなりにアラートは発生します。Falco ベースの検知ルールが動いているので、/etc/shadow の読み取りや不審なプロセス実行をちゃんと捕捉してくれる。しかし検知だけでは意味がない。検知の後の「分析→判断→対応」のサイクルを回さなければ、SOC とは呼べません。
After: AI が常駐する SOC の世界
構築後の世界はこうなりました:
24/7 自動トリアージ: アラートが来た瞬間に AI がスレッド内でトリアージ結果を投稿。重大度、MITRE ATT&CK テクニック ID、影響範囲、推奨初動を含む構造化レポート。
自動深掘り調査: Critical/High アラートは自動で Sysdig MCP を使った 2 フェーズ調査（情報収集 → Diamond Model 仮説検証）に進む。
スマート通知: 深夜の Low アラートで起こされることはない。Critical/High だけが Telegram に即時通知。
日次サマリー: 毎朝 8 時に前日の全アラート統計、K8s 健全性、トレンドを Telegram で受け取る。
エンタープライズ SOC との対応
面白いのは、エンタープライズ SOC のツールスタックがそのままホームラボにマッピングできることです。
| エンタープライズ SOC | ホームラボ SOC | 役割 |
|---|---|---|
| SIEM | Slack ログ | ログ集約・検索 |
| CNAPP/CWPP | Sysdig Secure | ランタイム検知・クラウドワークロード保護 |
| SOAR | n8n ワークフロー | 自動対応・オーケストレーション |
| AI Analyst | OpenClaw (Claude Opus) | AI によるトリアージ・分析 |
| チケット管理 | Slack スレッド + GitHub Issues | インシデント追跡 |
| 通知 | Telegram + Slack | アラート通知 |
| TIP | n8n + Web 検索 | 脅威インテリジェンス |
エンタープライズでは 3 ティア（Tier 1 トリアージ → Tier 2 分析 → Tier 3 ハンティング）の SOC モデルが一般的ですが、ホームラボでは 2 ティア に圧縮しました:
- AI Tier（OpenClaw）: Tier 1 トリアージ + Tier 2 深掘り調査を自動実行
- Human Tier（自分）: Tier 3 脅威ハンティング + 最終判断
6 つのハンドオフポイント（HP-1〜HP-6）で AI と人間の境界を明確に定義し、破壊的な操作（Pod 削除、認証情報ローテーション、ノード再起動）は必ず人間の承認が必要という安全設計にしています。
設計プロセス: 要件定義書を 10 回レビューした話
なぜ要件定義から始めたのか
前回の n8n 統合（27 タスク、1 日で完了）の経験から、「先に要件をしっかり定義すると、実装がスムーズに進む」と実感していました。SOC 運用は n8n より遥かに複雑です。12 のプレイブック、18 の ATT&CK テクニック、9 つのメトリクス、14 の E2E テスト——これらを場当たり的に実装するのは無謀でした。
そこで、実装に一切手を付けず、要件定義書の品質を徹底的に高めることから始めました。
10 回のレビューで見つかった 61 件の問題
要件定義書は v1.0 から v1.9 まで進化し、その過程で 8 ラウンドのレビューを実施、合計 61 件の問題を発見・修正しました。
| レビュー | 対象バージョン | 発見件数 | Critical | High | Medium |
|---|---|---|---|---|---|
| REV1 | v1.0 | 18 | 1 | 5 | 6 |
| REV2 | v1.2 | 15 | 1 | 3 | 5 |
| REV3 | v1.3 + タスク定義 v1.0 | 18 | 1 | 5 | 6 |
| REV4 | v1.4 + タスク定義 v1.1 | 12 | 0 | 2 | 5 |
| REV5〜8 | v1.5〜v1.8 | — | — | — | — |
レビューを重ねるごとに品質が目に見えて向上しました:
| 指標 | v1.0（初版） | v1.9（最終版） |
|---|---|---|
| 用語集 | 20 語 | 43 語 |
| プレイブック数 | 4（概要のみ） | 12（全詳細手順付き） |
| ATT&CK カバレッジ | 15 テクニック | 18 テクニック |
| NIST CSF カバレッジ | Detect/Respond のみ | 全 6 機能 |
| F3EAD カバレッジ | なし | 全 6 フェーズ |
| IOC/IOA 分類 | なし | 4 分類 + Pyramid of Pain |
| 相関分析 | なし | 4 タイプ（時間窓パラメータ付き） |
特に印象的だったのは REV1 の Critical 指摘: MITRE ATT&CK のサブテクニック ID T1543.005 と T1552.007 が公式マトリクスに存在しないというもの。コンテナ環境に特化した検知パターンを ATT&CK に無理やりマッピングしていたのですが、存在しない ID を使っていました。カスタムマッピング (*) として明示することで解決しましたが、レビューなしでは間違った ATT&CK ID が本番運用に流れるところでした。
採用したフレームワーク
SOC 運用の設計にあたり、以下のフレームワークを採用しました:
| フレームワーク | 用途 | 適用箇所 |
|---|---|---|
| NIST CSF 2.0 | SOC 全体のガバナンスフレーム | アーキテクチャ設計（6 機能マッピング） |
| MITRE ATT&CK for Containers | 脅威分類・検知ルール設計 | トリアージの ATT&CK マッピング |
| F3EAD | インテリジェンス運用サイクル | 検知→トリアージ→対応→改善のサイクル |
| Diamond Model | 深掘り調査の仮説検証 | Critical/High アラートの 4 仮説分析 |
| Cyber Kill Chain | 攻撃段階の分析 | 相関分析のキルチェーンベース相関 |
| PEAK | 脅威ハンティング | 人間主導のプロアクティブ調査 |
アーキテクチャ
コンポーネント構成
▲ ホームラボ SOC アーキテクチャ -- NIST CSF 2.0 の 6 機能にマッピング
システムは 3 つの主要コンポーネントで構成されています:
- Sysdig Secure（SaaS）: K8s クラスター上の Falco ベースランタイム検知。21 の MCP ツールで OpenClaw と連携
- OpenClaw Gateway（Mac Mini）: AI SOC アナリスト。Sysdig MCP + n8n MCP を駆使してトリアージ・調査を実行
- n8n（Docker）: ワークフロー自動化。Web ページ取得（脅威インテリジェンス）等を MCP ツールとして提供
▲ n8n の実行履歴: MCP Server Trigger → get_current_time / fetch_webpage。全実行が数ミリ秒で成功
アラートライフサイクル
▲ アラートの 6 ステージライフサイクル: 検知→通知→トリアージ→調査→対応→記録
アラートは 2 フェーズで処理されます:
Phase 1（検知→トリアージ）:
- Sysdig Secure が Falco ルールでランタイムイベントを検知
- Webhook 経由で Slack
#security-alertsに投稿 - OpenClaw AI が自動でスレッド内にトリアージ結果を投稿
Phase 2（調査→記録）:
4. Critical/High アラートは Sysdig MCP で自動深掘り調査
5. Diamond Model による 4 仮説検証（正常運用/権限昇格/外部侵入/自動化異常）
6. インシデントレポート生成 → Slack スレッド + GitHub Issue に記録
MCP ツールの全体像
今回のプロジェクトで最も特徴的なのは、52 本の MCP ツールを SOC 機能に完全マッピングしていることです。
| MCP サーバー | ツール数 | 主な用途 |
|---|---|---|
| Sysdig | 21 | イベント検索、プロセスツリー、SysQL クエリ、K8s 状態監視 |
| Serena | 27 | コードベース分析、シンボル検索（SOC 外の開発支援） |
| drawio | 3 | ダイアグラム生成 |
| n8n | 1 | Web ページ取得（脅威インテリジェンス用） |
Sysdig の 21 ツールは SOC 機能にこう対応します:
検知系: sysdig_list_runtime_events, sysdig_get_event_info
調査系: sysdig_get_event_process_tree, sysdig_run_sysql, sysdig_generate_sysql
K8s 監視: sysdig_k8s_list_nodes, sysdig_k8s_list_workloads, sysdig_k8s_list_pod_containers
リソース: sysdig_k8s_list_top_cpu_consumed_*, sysdig_k8s_list_top_memory_consumed_*
障害検知: sysdig_k8s_list_top_restarted_pods, sysdig_k8s_list_top_unavailable_pods
「プロンプトがプロダクト」— AGENTS.md の設計
コードではなくプロンプトが成果物
今回のプロジェクトで最も重要な気づきは、成果物がコードではなくプロンプトであるということです。
| 項目 | 前回（n8n MCP 統合） | 今回（SOC 運用） |
|---|---|---|
| 主な成果物 | Docker コンテナ、設定ファイル | AGENTS.md（プロンプト） |
| テスト方法 | ツール呼び出しの成否確認 | AI 出力品質の評価 |
| 完了基準 | 技術的に動作すること | 運用品質が目標を満たすこと |
| 反復性 | 一度構築すれば完了 | 継続的改善が必要 |
AGENTS.md は OpenClaw の「人格」を定義するファイルです。ここに SOC アナリストとしての振る舞い——重大度の判断基準、ATT&CK マッピングのルール、トリアージの出力フォーマット、エスカレーション条件——をすべて記述します。
AGENTS.md の構成
圧縮版 AGENTS.md（336 行、11052 文字）の主要セクションを紹介します。
重大度テーブル: Sysdig のアラート重大度を SOC の 4 段階に変換するルールです。
▲ Sysdig のアラート重大度を SOC の 4 段階にマッピング。MTTR 目標も紐づけて対応速度を管理
Sysdig は High が最高重大度のため、Runtime Event や Notable Events のように重大度が明示されないアラートも含めて High = Critical/High 扱いとし、最優先で対応するルールにしています。
トリアージ出力フォーマット: AI がスレッドに投稿するトリアージ結果のテンプレートです。
1. ヘッダー（重大度 / ATT&CK Txxxx / 影響範囲）
2. サマリー（1-2 文の日本語要約）
3. 検知ルール（Sysdig ルール名 + 条件）
4. 影響評価（ビジネスインパクト + 緊急度）
5. 推奨初動（3 項目のチェックリスト）
6. 追加調査（Sysdig MCP 深掘り提案）
7. 攻撃指標（IOC/IOA 分類 + Pyramid of Pain レベル）
ATT&CK マッピングガイド: 18 テクニックの検知パターンとの対応表です。AI はこのテーブルを参照して、各アラートに適切なテクニック ID を付与します。
T1059 コマンドインタプリタ ← sh/bash 実行
T1609 コンテナ管理コマンド ← kubectl exec
T1611 ホストへのエスケープ ← /proc/1/root, nsenter
T1496 リソースハイジャック ← CPU 異常 + Stratum プロトコル
T1552 認証情報の窃取 ← /etc/shadow, ServiceAccount Token
...（全 18 テクニック）
深掘り調査ワークフロー: Critical/High アラートに対して自動実行される 2 フェーズ調査。
Phase 1: 情報収集（MCP 6 ツール連鎖）
sysdig_get_event_info → sysdig_get_event_process_tree
→ sysdig_run_sysql（同 Pod 1h） → sysdig_k8s_list_workloads
→ sysdig_k8s_list_pod_containers → CPU/メモリ分析
Phase 2: Diamond Model 仮説検証
H1: 正常運用 H2: 権限昇格 H3: 外部侵入 H4: 自動化異常
各仮説を Adversary/Infrastructure/Capability/Victim 軸で分析
自己進化するプロンプト: 特筆すべきは、AGENTS.md 内に「偽陽性パターンリスト」が直接埋め込まれていること。オペレーターがアラートスレッドに「FP」と返信すると、AI がそのパターンを抽出してリストに自動追加します。運用するほど賢くなる仕組みです。
なぜ「検知は Sysdig、分析は AI」なのか？
「AI が賢いなら、検知も AI にやらせればいいのでは？」——これはもっともな疑問です。しかし、検知と分析では求められる特性がまったく異なります。
検知に求められるもの: Sysdig Secure は eBPF を通じてカーネルレベルのシステムコール（プロセス実行、ファイルアクセス、ネットワーク通信）をリアルタイムに監視します。Falco ルールにマッチした瞬間にアラートが発火する——ミリ秒単位の即応性と、同じ入力なら必ず同じ結果を返す決定論的な再現性が特徴です。
分析に求められるもの: 「このアラートは本当に危険か？」「複数のアラートは関連しているか？」「コマンドチェーン全体を見たとき、どの攻撃手法の組み合わせか？」——こうしたコンテキストを踏まえた判断こそ、AI が真価を発揮する領域です。
| 能力 | Sysdig (Falco/eBPF) | AI (OpenClaw) |
|---|---|---|
| リアルタイム検知 | ◎ カーネルレベル・ミリ秒 | ✕ API ポーリングでは遅延 |
| 決定論的判定 | ◎ 同じ入力 → 必ず同じ結果 | △ 生成ごとに微妙に異なる |
| コンテキスト分析 | ✕ ルールマッチのみ | ◎ 環境全体を考慮した判断 |
| ATT&CK マッピング | △ ルールに事前定義された静的タグ | ◎ 実行コンテキストから動的に特定 |
| 攻撃チェーン推定 | ✕ | ◎ 時間的・空間的な相関分析 |
| 自然言語レポート | ✕ | ◎ 構造化トリアージレポート |
つまり、Sysdig が「何が起きたか」をリアルタイムに捕捉し、AI が「それは何を意味するか」を判断する——この役割分担こそが AI SOC の設計原則です。
この分離には運用上のメリットもあります:
- 耐障害性: AI がダウンしても検知は止まらない。Slack にアラートは届き続ける
- コスト効率: 全システムコールを AI に流すのは非現実的。検知でフィルタしてから AI に渡す
- 監査性: 検知ルールは確定的で再現可能。「なぜこのアラートが出たか」を後から検証できる
💡 実装 Tips:
AGENTS.mdには 20000 文字の上限があるため、運用ルール本体（11052 文字）と詳細手順書SOC-REFERENCE.md（25717 文字）の 2 ファイル構成に分離しています。プロンプト設計でも「コードのモジュール分割」と同じ発想が必要です。
実際の運用: AI は何をしているのか？
ここからは、実際に動いている SOC の具体的な出力を見ていきます。設計の話だけでは「本当に動くの？」という疑問が残ると思うので、リアルなトリアージ結果をお見せします。
▲ 実際の Slack #security-alerts 画面: 左にアラート一覧、右スレッドに AI のトリアージ結果
実例: 認証情報探索アラートのトリアージ
テスト用の busybox コンテナで /etc/shadow の読み取りと証明書ファイルの探索を実行したところ、Sysdig が Find Authentication Certificates アラートを検知。Slack #security-alerts に投稿されてから 数秒後、OpenClaw が以下のトリアージ結果をスレッドに自動投稿しました:
## 🟠 Medium | T1649 + T1003 + T1083 | Pod: test-recon-blog (nuc2/default)
### 概要
busybox:latest コンテナ内で認証情報の探索・窃取を目的とした
複合偵察コマンドが root 権限で実行された。
### 実行コマンドチェーン（⚠️ 重要）
sh -c cat /etc/shadow; find / -name "*.key" -o -name "*.pem" 2>/dev/null; whoami; exit 0
3段階の偵察を単一シェルで実行:
1. cat /etc/shadow → パスワードハッシュ窃取 (T1003)
2. find / -name *.key -o -name *.pem → 証明書・秘密鍵探索 (T1649)
3. whoami → 権限確認 (T1083)
### ATT&CK マッピング
| 戦術 | テクニック | 根拠 |
|-------------------|------------|--------------------------|
| Credential Access | T1649 | 鍵・証明書ファイル探索 |
| Credential Access | T1003 | /etc/shadow 読み取り |
| Discovery | T1083 | ファイルシステム全体スキャン |
| Execution | T1059 | sh による複合コマンド |
### 攻撃指標
- IOA: busybox + /etc/shadow + 証明書探索の組み合わせ（Pyramid of Pain: TTP レベル）
- IOC: proc.hash.sha256=786295... (find binary)
- IOC: Pod test-recon-blog / Image busybox:latest in default ns
### 推奨初動
- [ ] Pod の即時削除: kubectl delete pod test-recon-blog -n default
- [ ] Pod の作成元を調査（kubectl get events / audit log）
- [ ] 同一ノード(nuc2)の関連イベントを確認
注目すべきポイント:
-
コマンドチェーンの自動分解: 単一の
sh -cに含まれる 3 段階の偵察を AI が自動で分離し、それぞれに ATT&CK テクニック ID を付与 - Pyramid of Pain の適用: 単なるハッシュ値（変えやすい）ではなく、TTP レベル（行動パターン）として分類——攻撃者が変更しにくい指標を重視
-
実行可能な推奨初動:
kubectl delete podの具体的なコマンドまで提示
MCP ツールの連鎖呼び出し
上記のトリアージでは、AI が裏側で以下の Sysdig MCP ツールを自動的に呼び出しています:
1. sysdig_get_event_info → アラート詳細の取得
2. sysdig_list_runtime_events → 同一 Pod の関連イベント検索
3. sysdig_get_event_process_tree → プロセスツリーの可視化
1 つのアラートに対して 3 つの MCP ツールを連鎖的に呼び出し、コンテキストを積み上げてからトリアージ結果を生成しています。人間が Sysdig のダッシュボードを開いて同じ情報を集める作業を、AI が数秒で完了します。
複数アラートの相関分析
同じ Pod から 2 つのアラート（Terminal shell in container + Find Authentication credentials）が同時に発火した場合、AI は 相関分析を自動実行します:
### 検出ルール
| ルール | 重要度 |
|---------------------------------|--------|
| Terminal shell in container | Medium |
| Find Authentication credentials | Medium |
2つのルールが同時刻に発火 → コンテナ内でシェル取得後に
認証情報を探索するパターン（Kill Chain: Execution → Credential Access）
判定: Pod 名の "test-recon" パターンと kubernetes-admin による
即時削除から、セキュリティテストの可能性が高い。
ただし、作成者の意図確認が必要。
単独では Medium のアラートも、複数アラートの時間的・空間的な相関を分析することで、攻撃チェーンとしての全体像を提示します。
偽陽性の自動学習
運用を続けると node-exporter が SUID/SGID バイナリをスキャンするアラートが定期的に発生します。オペレーターがスレッドに「FP」と返信するだけで:
以降は同じパターンのアラートに [FP候補] タグが自動付与され、ノイズが削減されていきます。運用するほど賢くなる SOC です。
5 Phase × 43 タスクの実装
タスク定義書に基づき、5 つのフェーズ・43 タスクを実行しました。
| Phase | 名称 | タスク数 | Must | Should | Could | 内容 |
|---|---|---|---|---|---|---|
| 1 | SOC 基盤構築 | 13 | 12 | 1 | 0 | アラート受信、トリアージ、エスカレーション、日次サマリー |
| 2 | AI トリアージ強化 | 7 | 2 | 5 | 0 | FP 判定、IOC/IOA 分類、相関分析、品質保証 |
| 3 | SOAR ワークフロー | 9 | 1 | 7 | 1 | PB-004〜010 プレイブック、レポートテンプレート、証拠保全 |
| 4 | 定期監視・脅威ハンティング | 8 | 1 | 3 | 4 | 定期スキャン、PEAK フレームワーク、脅威インテリジェンス |
| 5 | 継続的改善 | 6 | 1 | 2 | 3 | メトリクス計測、週次レポート、運用チェックリスト |
| 合計 | 43 | 17 | 18 | 8 |
Phase 1 のハイライト: 初めてのトリアージ
Phase 1 で最も感動したのは、テストアラートに対して AI が初めてトリアージ結果を返した瞬間です。
kubectl run で busybox コンテナから /etc/shadow を読み取るテストを実行。Sysdig がそれを検知し、Slack にアラートを投稿。数秒後、OpenClaw がスレッド内に構造化されたトリアージ結果を投稿しました:
- 重大度: High
- ATT&CK: T1003（OS Credential Dumping）/ T1609（Container Admin Command）
- 影響範囲: default namespace の busybox Pod
- 推奨初動: Pod の停止、イメージ調査、アクセス経路の確認
これが全自動で、アラート投稿から数秒で実行されたのです。
Phase 2 のハイライト: AI トリアージの深化
Phase 2 では、単なるアラート応答から「賢い分析」へと進化させました。偽陽性自動判定（3 基準）、IOC/IOA 分類体系（Pyramid of Pain 対応）、アラート相関分析（4 タイプ）を追加。前述の運用例で見たような、ATT&CK マッピングや Pyramid of Pain レベルの付与は、この Phase で設計したルールが効いています。
Phase 4 のハイライト: 自動定期監視
OpenClaw のネイティブ cron 機能を使って 4 つの定期ジョブを設定:
| ジョブ名 | スケジュール | 送信先 | 内容 |
|---|---|---|---|
soc-daily-summary |
毎日 08:00 JST | Telegram | 日次 SOC サマリー |
soc-security-scan-hourly |
毎時 | Slack | ランタイムイベントスキャン |
soc-k8s-health-15m |
15 分間隔 | Slack | K8s 健全性チェック |
soc-weekly-report |
月曜 09:00 JST | Telegram | 週次トレンドレポート |
日次サマリーは約 80 秒で生成され、前日のアラート統計、K8s クラスター状態、トレンド分析を含む包括的なレポートが毎朝 Telegram に届きます。
成果と効果
定量的成果
| カテゴリ | 数値 |
|---|---|
| 要件定義書 | v1.9（25 FR / 10 NFR / 12 PB / 14 E2E テスト） |
| タスク | 43/43 完了（5 Phase） |
| レビューラウンド | 8 回、61 件の問題修正 |
| MCP ツール | 52 本（Sysdig 21 + Serena 27 + drawio 3 + n8n 1） |
| ATT&CK テクニック | 18（11 タクティクス） |
| プレイブック | 12（PB-001〜PB-012） |
| SOC メトリクス | 9（MTTD / MTTN / MTTT / MTTC / MTTR / FPR / AI 精度 / 処理率 / エスカレーション精度） |
| 定期監視ジョブ | 4（15m / 1h / 日次 / 週次） |
| リスク | 11（識別・緩和策付き） |
| アーキテクチャダイアグラム | 6 種（draw.io + Mermaid + PNG） |
AGENTS.md |
336 行 / 11052 文字（20000 文字制限内） |
SOC-REFERENCE.md |
609 行 / 25717 文字 |
運用体制
縮退運用設計: MCP サーバーがダウンしても SOC 監視は止まりません。4 段階の縮退レベルを定義:
| 障害 | 影響 | 対応 |
|---|---|---|
| Sysdig MCP のみダウン | 深掘り調査不可、Slack メッセージのみでトリアージ | 手動確認を要請 |
| n8n MCP のみダウン | プレイブック自動実行停止 | 他機能は継続 |
| 全 MCP ダウン | Slack 監視のみ | Telegram に全系統ダウン通知 |
| 復旧時 | 未処理アラートを一括トリアージ | 自動で通常運用に復帰 |
バックアップ: ~/openclaw-backups/backup.sh が OpenClaw 設定、AGENTS.md（FP パターン含む）、SOC-REFERENCE.md、n8n データベース、cron ジョブ設定を一括バックアップ。30 日以上前のバックアップは自動削除。
運用チェックリスト: 日次/週次/月次/四半期/随時の 5 段階で 12 項目を定義。月次には「プロンプト品質保証」（トリアージ精度 > 85%、FP 率 < 30% 等の閾値評価）を含みます。
まとめと今後の展望
「プロンプトエンジニアリング = ソフトウェアエンジニアリング」
今回の最大の学びは、プロンプトエンジニアリングにもソフトウェアエンジニアリングと同じ規律が必要ということです。
- 要件定義: 曖昧な指示は曖昧な出力を生む。明確な出力フォーマット、判断基準、例外処理を定義する必要がある
- テスト: プロンプトの変更は「AI の出力品質」に直結する。回帰テスト（過去のアラートで品質が落ちていないか）が必要
- サイズ管理: コードのモジュール分割と同様、プロンプトも「本体」と「参照ドキュメント」に分離すべき
-
バージョン管理:
AGENTS.mdの変更履歴を追えることは、品質問題の原因特定に不可欠 - レビュー: 人間のコードレビューと同じく、プロンプトのレビューも品質向上に直結する
要件定義書を 10 回レビューして 61 件の問題を修正した過程は、まさにこの規律の実践でした。
今後の展望
SOC の本番運用が始まったばかりです。今後は実運用データを蓄積しながら、以下に取り組む予定です:
- メトリクス改善: 現在のベースラインを計測し、段階的に目標値（FP 率 < 25%、AI 精度 > 90%）に近づける
- ATT&CK カバレッジ拡大: 現在の 18 テクニックから、コンテナ環境に関連する未カバー領域を追加
- FP パターンの蓄積: 運用を通じて偽陽性パターンリストを充実させ、ノイズを削減
- 脅威ハンティング実践: PEAK フレームワークに基づくプロアクティブな調査を月次で実施
- プロンプト品質の定量評価: 月次レビューで精度メトリクスを追跡し、プロンプトを継続的に改善
AI SOC アナリストは「デプロイしたら終わり」ではなく、運用しながら育てていくものです。偽陽性パターンの学習、新しい攻撃手法への対応、メトリクスに基づく改善——このサイクルを回し続けることで、ホームラボの SOC はエンタープライズ SOC に匹敵する成熟度に近づいていくと考えています。