ClaudeCodeでセキュリティ監視業務を半自動化_1年の運用でわかったAIに任せる設計の5つのポイント

Transcript

1. Claude Codeで セキュリティ監視業務を半⾃動化 1 年の運⽤でわかった、AI に任せる設計の 5 つのポイント 2026.08.26 【CDLE Cyber Security】AI×Security 勉強会#12 KINTOテクノロジーズ株式会社 太⽥ 俊⼀
2. ⾃⼰紹介 太⽥ 俊⼀ KINTOテクノロジーズ株式会社 セキュリティ‧プライバシー部 サイバーセキュリティG 兼務：コーポレートIT部 AIファーストG 担当 SOC 業務の設計‧運⽤と、⽣成AI活⽤の推進 経緯 テックブログ「SOC 監視業務を半⾃動化した話」をご覧いただいたご担当者からの お声がけをきっかけに、本⽇の登壇に⾄る KINTO Technologies Corporation
3. 本⽇の内容の元ネタ AI x SOC の取り組み初期を紹介 SOC 監視業務の半⾃動化（2025-12） Codex と Splunk MCP を活⽤ 手順書駆動プロンプト開発 KINTO Technologies Corporation 参考：https://blog.kinto-technologies.com/posts/2025-12-20-ai-agent-soc-monitoring-automation/
4. 関連情報：リアルタイム型 SOC エージェント AWS を活⽤した SOC 業務の⾃動化 社内別部署による事例 アラート起点の⼀次分析をAI エージェント で処理‧Slack スレッドへ返却 効果：トリアージ 1〜2 時間 → 15 分以内 KINTO Technologies Corporation 参考：https://speakerdeck.com/kintotechdev/aratopi-bi-karanotuo-que-hesocye-wu-niokeru-ai-esientohuo-yong-noshi-jian-v2
5. ⽬次 なぜ AI 活⽤が必要だったか P.06 何を作ったか P.10 設計のポイント（5 点） P.17 まとめ P.26 KINTO Technologies Corporation
6. 01 なぜ AI 活⽤が必要だったか 監視業務の実態と、3 つの課題 KINTO Technologies Corporation
7. 監視業務の流れ（AI 活⽤前） ⼀次調査 深堀り要否判断 深掘り調査 対応‧判断 ログを調査し、監視レポート を作成 深掘り調査の要否をレポート で判断 必要に応じて追加調査を実施 対応要否を判断し、事案対応 を実施 KINTO Technologies Corporation
8. SOC ⽇次監視の課題 1 ⽇ 2〜3 時間の⼿動作業が、特定の担当者に集中していた 監視業務の全⼯程を⼈⼿で実施しており、3つの課題がありました 作業時間：1 ⽇あたり 2〜3 時間の⼿動作業が発⽣している 属⼈化：SPL 知識‧ログ解析スキルが特定担当者に集中している 標準化不⾜：判断基準が暗黙知となり、新メンバー参画の障壁になっている 業務の分解‧明⽂化を起点に、Splunk Cloud MCP による半⾃動化から着⼿しました KINTO Technologies Corporation
9. SOC ⽇次監視の課題 1 ⽇ 2〜3 時間の⼿動作業が、特定の担当者に集中していた 監視業務の全⼯程を⼈⼿で実施しており、3つの課題がありました 作業時間：1 ⽇あたり 2〜3 時間の⼿動作業が発⽣している 属⼈化：SPL 知識‧ログ解析スキルが特定担当者に集中している 標準化不⾜：判断基準が暗黙知となり、新メンバー参画の障壁になっている 業務の分解‧明⽂化を起点に、Splunk Cloud MCP による半⾃動化から着⼿しました KINTO Technologies Corporation
10. 半⾃動化からワークフロー化へ 段階を踏んで⾃動化範囲を広げ、現在の形に⾄りました 約 1 年の運⽤で、3 つの段階を経ています 第1段：AI エージェントで半⾃動化 — ⼀次調査を AI エージェント化し、作業時間を約半分に 残った課題：品質チェックの⼯数、知⾒反映の属⼈性、起票の⼿作業 第2段：Claude Code でワークフロー化（soc-run）— 調査から起票‧レポート作成までを実⾏ 以降は、この過程で⾒えた「設計のポイント」を中⼼にお話しします KINTO Technologies Corporation
11. 02 何を作ったか SOC ⽇次監視のワークフロー KINTO Technologies Corporation
12. おさらい：Claude Code の構成要素 いずれも「AI に何をどこまで任せるか」を決める部品。この組み合わせが設計の中⾝になります カスタムコマンド スキル ‧スラッシュコマンドで定型の作業⼿順を呼び出す ‧必要なときだけ読み込む⼿順書 ‧後述の soc-run 本体がこれ ‧判断基準や調査⼿順の置き場 サブエージェント MCP ‧役割ごとに別コンテキストで動く AI エージェント ‧外部システムへの接続⼝ ‧システム別の監視担当を並列実⾏ ‧Splunk‧JIRA‧Confluence と連携する フック（hooks） CLAUDE.md ‧ツール実⾏の前後に⾛るプログラム ‧常に読み込まれるプロジェクト規約 ‧危険な操作を⽌める‧記録する ‧ルールは書けるが強制はできない KINTO Technologies Corporation
13. soc-run とは コマンド 1 発のフルワークフロー 調査 → 判断 → 品質チェック → 起票 → レポート作成まで、カスタムコマンド 1 発で実⾏ AI エージェント＋プログラム処理 判断は AI、実⾏と検証は Python プログラムが担う分担構成 規模：10 数サービス‧80 以上の監視項⽬ 検知ルール‧監視観点を記載した YAML を Git 管理。1 実⾏ 30〜60 分で完⾛ KINTO Technologies Corporation
14. 全体像：判断は AI、実⾏と検証はプログラム オーケスト レーター Phase 0 Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 事前チェック ⼀次レポート⽣成 品質保証 過去対応照合 起票 レポート⽣成 MCP / Codex 接続確認 AI エージェント 10 数体を並列起動 サブ エージェント ハイライト所⾒を執筆 解釈‧判断‧深堀り md ＋ state.json 出⼒ 別モデルの 独⽴レビュー （LLM-as-a-Judge） 過去チケットを検索 起票要否を判断 チケット⽂⾯を⽣成 検知 YAML → SPL ⼀括実⾏ QA 機械検証 （改変‧件数） 要対応のみ抽出 チケット起票 ⼦∕親ページ更新 集計は⾃動導出 Codex CLI JIRA 検索 JIRA API Confluence 機械的処理 出⼒検証ゲート 外部サービス Splunk / Atlassian Codex Splunk Cloud AI が判断 KINTO Technologies Corporation Python が実⾏‧集計 機械的チェックで検証 外部サービス
15. 全体像：判断は AI、実⾏と検証はプログラム オーケスト レーター Phase 0 Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 事前チェック ⼀次レポート⽣成 品質保証 過去対応照合 起票 レポート⽣成 MCP / Codex 接続確認 AI エージェント 10 数体を並列起動 サブ エージェント ハイライト所⾒を執筆 解釈‧判断‧深堀り md ＋ state.json 出⼒ 別モデルの 独⽴レビュー （LLM-as-a-Judge） 過去チケットを検索 起票要否を判断 チケット⽂⾯を⽣成 検知 YAML → SPL ⼀括実⾏ QA 機械検証 （改変‧件数） 要対応のみ抽出 チケット起票 ⼦∕親ページ更新 集計は⾃動導出 Codex CLI JIRA 検索 JIRA API Confluence 機械的処理 出⼒検証ゲート 外部サービス Splunk / Atlassian Codex Splunk Cloud AI が判断 KINTO Technologies Corporation Python が実⾏‧集計 機械的チェックで検証 外部サービス
16. ⼿動運⽤からどう変わったか 観点 ⼿動運⽤（AI 活⽤前） 現在（soc-run） 作業時間 1 ⽇あたり 2〜3 時間 AI 実⾏ 30〜60 分＋⼈はレビューのみ （⼈間の実働は 30 分程度） ⾃動化範囲 ⾃動化なし（全⼯程を⼈⼿） 調査‧判断‧QC‧起票‧レポートまで 品質チェック 担当者が全件を⽬視確認 ⾃動チェック ＋ 別モデルの クロスレビューで⾃動化 スキルと体制 SPL 知識が必要‧1 名に集中 標準化‧複数名体制 ナレッジの蓄積 担当者の記憶とチケットへのメモに依存 JIRA チケットに調査‧判断履歴が蓄積 過去対応を⾃動照合して再利⽤ KINTO Technologies Corporation
17. 03 設計のポイント 失敗と、その対策 KINTO Technologies Corporation
18. ポイント①：⼿順書駆動プロンプト開発 業務を分解し、判断基準を明⽂化してから AI に渡すことが近道でした 失敗：バイブコーディング的アプローチ 成功：まずは業務分解‧⼿順書作成 AI とチャットしながらプロンプトを作成 業務を⼯程単位に分解し、迷いなく実⾏できる 粒度まで明⽂化 判断基準が⽂書化されず曖昧で、 AI の出⼒がブレる 監視⽬的‧クエリ‧判断基準‧出⼒要件を 構造化して定義し、AI へ引き渡す 1〜2 週間かけても 納得のいくプロンプトが作れなかった 明⽂化を含め約 2 ⽇でドラフト完成。 定義の再利⽤で、他の監視業務への横展開も容易 KINTO Technologies Corporation
19. では、AI にどこまで任せるべきか？ KINTO Technologies Corporation
20. ポイント②：判断だけを AI に、実⾏と検証はプログラムに AI とプログラムの分担を徹底することが、再現性と事故防⽌の鍵です AI が担当（判断） プログラムが担当（実⾏‧検証） ログ解釈と⼀次判定（正常/継続監視/要対応） SPL の実⾏‧検証‧保存（SPL は読ませない） 判断根拠‧所⾒の⽂章化とレポート⽣成 ⼯程の間で AI の出⼒を機械チェック チケット、レポートの⽂⾯作成 JIRA / Confluence への API 実⾏‧⾃動集計 KINTO Technologies Corporation
21. ポイント②：判断だけを AI に、実⾏と検証はプログラムに AI とプログラムの分担を徹底することが、再現性と事故防⽌の鍵です AI が担当（判断） プログラムが担当（実⾏‧検証） ログ解釈と⼀次判定（正常/継続監視/要対応） SPL の実⾏‧検証‧保存（SPL は読ませない） 判断根拠‧所⾒の⽂章化とレポート⽣成 ⼯程の間で AI の出⼒を機械チェック チケット、レポートの⽂⾯作成 JIRA / Confluence への API 実⾏‧⾃動集計 KINTO Technologies Corporation
22. ポイント③：出⼒の品質は、信頼ではなく検証で担保する 出⼒の「正しさ」を、⼈のレビュー前に機械で確かめます ⼈間が⾏っていた品質チェックを、3つの仕組みで⾃動化 ⾃動チェック：⼯程の間で必須項⽬と整合性を機械検証し、直せる⽋落は⾃動修復 独⽴評価（LLM-as-a-Judge）：別ベンダーのモデルが判断品質をレビュー 誤起票防⽌：dry-run‧テスト⽤の⽬印‧⼆重起票防⽌の三重安全策 ⼈のレビューに頼っていた品質チェックをハーネス側に寄せることで、AI に任せられる範囲を広げられました KINTO Technologies Corporation
23. プロンプトに「注意して」と書けば、 意図しない動作は防げる？ KINTO Technologies Corporation
24. 防げませんでした KINTO Technologies Corporation
25. ポイント④：統制は「実⾏される機構」として実装する 意図しない操作は、実⾏される前に仕組みで制御 実際に起きた事故を、hooks に落とし込む タイマー誤発⽕で全フェーズ重複実⾏ → 該当操作を hook で実⾏前に拒否 エージェントの再帰委譲で指⽰が劣化 → 再委譲をツール設定で構造的に禁⽌ 危険な操作（force push‧⼀括削除等）→ 実⾏前に本⼈確認を挟んで防⽌ 注意書きは読み⾶ばされます。統制はハーネス側の機構として実装するのが確実です KINTO Technologies Corporation
26. ポイント⑤：「できること」と「やるべきこと」は違う 完全⾃動化ではなく「⼈間の判断を⽀援するツール」と位置づけることが成功の鍵です 陥った罠 「過度に複雑な調査」が気軽にできてしまう 「せっかくだからこの観点も…」と監視対象を 広げすぎる AI が⼤量にチケット‧レポートを⽣成し、 ⼈間の確認が追いつかない KINTO Technologies Corporation ⼤切な考え⽅ 最終判断は⼈間が⾏う （ヒューマン‧イン‧ザ‧ループ） ⼈間が確認できる範囲で、 注⼒すべき観点に絞る 「監視の意図‧⽬的」に⽴ち返る
27. 04 まとめ 個⼈のスキルから、チームの仕組みへ KINTO Technologies Corporation
28. まとめ：「個⼈のスキル」から「チームの仕組み」へ Summary ✓ 効率化：2〜3 時間の⼿作業 → AI 実⾏＋レビューのみ（実働 約 30 分） ✓ AI 活⽤は業務の構造化から始まる ✓ AI とプログラムの役割分担を徹底し、ワークフロー化 ⼈間の役割は、「回す」から「⾒極める」へ バイブコーディング的アプローチではなく、業務の分解‧明⽂化を⼟台に 判断以外をプログラム化することで⾃動化範囲が拡⼤ KINTO Technologies Corporation
29. 本⽇の持ち帰り：AI エージェント活⽤の3原則 SOC に限らず、ワークフローへの AI エージェント組み込みへ⼀般化できる原則です 2 段階‧約 1 年の運⽤から抽出した、転⽤可能な3原則です 業務を分解し、暗黙知‧判断基準を明⽂化する — AI 活⽤はここから始まる 判断だけを AI に委ね、実⾏と検証はプログラムで統制する 出⼒は独⽴に検証する — 品質‧信頼はアーキテクチャで設計する ハーネス側で統制する設計は、AI エージェント⾃⾝の制御（Security for AI）にも通じます KINTO Technologies Corporation
30. Thank you KINTO Technologies Corporation