DevOps Agentにあらゆるセキュリティインシデントのトリアージを任せた件

Security-JAWS #43（2026-11-12）の登壇資料です。

MDM と Amazon GuardDuty のアラートの一次調査を、AWS DevOps Agent に任せた事例を紹介します。Webhook と MCP を使い、AWS の外の検知も同じ仕組みで調べさせています。カスタマイズなしでも誤検知の見立てはほぼ当たり、人は Slack で結果を見て判断するだけになりました。

運用して見えてきた 3 つの課題と、その改善も話します。
・Slack の投稿が長すぎる
・良性の検知でも、同じ調査が何度も起動する
・Agent の改善提案がたまっていく

1. SECURITY-JAWS #43 · SESSION 3 DevOps Agentに あらゆるセキュリティインシデントの トリアージを任せた件 シンプルフォーム株式会社 - jirtosterone 2026-11-12
2. 自己紹介 @jirtosterone シンプルフォーム株式会社 セキュリティ・情シス 時々 SRE 役割：事業価値に繋がるセキュリティと皆の時間を奪わない情シスづくり 最近の関心：運用業務を AI 前提で組み直すこと、情報漏洩が起きても動じない体 制と心づくり
3. 今日話すこと 背景・目的 なぜ DevOps Agent なのか 導入してみてどうだったか 運用してきて見えてきた課題と改善 まとめ
4. 1. 背景・目的
5. アラートが鳴って調査するけど基本は誤検知 端末：MDM（重大度が中以上の検知を Slack に通知） クラウド：Amazon GuardDuty（組織の全アカウント） 見るのはセキュリティチームの数人。本業の合間に一次調査している 一次調査の中身は毎回ほぼ同じ。「誰の・どの操作で・正常業務か」 を数十分掛けて確かめて、ほとんどは誤検知で閉じる
6. 一次調査でやっていたこと 種類 手で見ていたもの 判断 MDM 検知名・端末と利用者 本人の操作か → 利用者にヒアリング GuardDuty Finding 種別・リソース・CloudTrail 正常業務か → リソースの持ち主に確認 調べる観点は決まっているのに、毎回コンソールを渡り歩く 夜間・休日は翌営業日まで手が付かない
7. AI を使って改善したかったこと 目的 1 目的 2 目的 3 通知と同時にトリアージ 調査を AI に任せて人は見て判断 人も時間も足りないので手間を最小に 即時の一次調査 人は判断だけ 当時 GA になって間もない DevOps Agent に着目 最小の運用コスト
8. 2. なぜ DevOps Agent なのか
9. なぜ DevOps Agent を選んだのか 調べるための土台が最初からある：AWS のアカウントを横断して読む仕組みと、Slack・GitHub・Datadog との連携が用意されて いる AWS 外との連携ができる：Webhook で調査を始められるので、ソースが GuardDuty だろうが MDM だろうが同じ仕組みで使える MCP で連携先を増やせる：MDM の情報は、自前の MCP サーバーをつないで読ませた エージェントを作り込まなくていい：実行基盤も調べ方の改善も AWS がやってくれる 実質ゼロコストで運用できる （プラン・利用料による） 人も時間も足りないので、ノンカスタマイズで使い始められることを重視
10. 全体像 API キーで受けて SNS に直接渡す すべて Terraform で管理 Webhook MDM 隔離・変更と 最終的な判断は人がやる DevOps Agent (コーポレートセキュリティ) API Gateway Lambda コードは 1 つ。transformer で 依頼文に揃え、署名して送る MDM の MCP サーバー (AgentCore Runtime) 役割ごとに Agent を分け 連携の登録は共有する DevOps Agent (プロダクトセキュリティ) GuardDuty 読み取りの tool だけを許可 EventBridge StackSet で 全アカウントに配る 各アカウントを横断して 確かめる読み取りロール Lambda Datadog MCP GitHub Slack 担当者
11. 3. 導入してみてどうだったか
12. 良かったこと 通知から 1 分以内に調査が始まり、5〜15 分で結論を原因とセットで出してくれる CloudTrail・リソース定義・過去の検知を横断して見てくれる ノンカスタマイズでも精度良く原因推定ができており、誤検知の見立てはほぼ間違い無し。人は「Slack を見て判断する」だけに なった 例：AI エージェントの操作を MDM が止めた検知 検知 DEVOPS AGENT の見立て 本人の回答 Claude Code（Mac） DylibHijackingMac claude → zsh → ruby が Homebrew のライブラリを読めるか確か RSpec の準備を Claude Code にさ めただけ。良性 せていた ChatGPT の Codex （Windows） CertutilRemoteFileCopy Codex が certutil であるサービスの CLI を公式の GitHub から落 とそうとした。良性 業務を Codex で動かしていた
13. 困ったこと Slack の投稿が長すぎて見づらい 同じ種類の検知でも、同じように調査が起動し続ける Agent が改善提案（recommendation）を出してくれるが溜まっていくだけ この 3 つを順に改善
14. 4. 運用してきて見えてきた課題と改善
15. 改善 1：Slack の投稿を短くする 課題 調査の経過がダイジェストとは言えスレッドに流れてきて、読 む人が結論にたどり着けない 長すぎて辛いので、通知を受けても読まなくなる やったこと 依頼文で要約を指示するも指示通りに出してくれず 結局 DevOps Agent 本体の更新 で良くなった
16. 投稿の形：改善前と改善後 改善前（2026-10-01） 改善後（2026-10-30） AWS DevOps Agent アプリ 🚨 Investigation started: A drive-by source domain name was queried by a resource. [severity=8.0] I've begun investigating an issue that requires attention. I'll provide updates as the investigation progresses. View investigation 💬 23 件の返信 AWS DevOps Agent アプリ Investigation: ▪▪▪ が ▪▪▪▪.com をクエリ（GuardDuty PhishingDomainRequest） Status: Complete · Severity: low インシデント ▪▪▪ が ▪▪▪▪.com を DNS クエリ（GuardDuty 2件） 原因 侵害ではなく良性。クローラーがサイトをプロキシ経由でクロールし GuardDuty が検知 緩和策 抑制フィルタに追加＋2件アーカイブ。多層防御強化を仕様提示 View investigation 💬 5 件の返信 親の投稿は「調査を始めた」のまま変わらない 結論を知るには、23 件の返信を読むしかない 調査が終わると、親の投稿が結論のカードに書き換わる 親を見るだけで、何が起きて何をすればよいかが分かる 試行錯誤が無駄に終わったが、マネージドサービスの恩恵を受け、DevOps Agent を選んで良かったと思った瞬間だった
17. 改善 2：良性の検知は抑制案まで出させる 課題 良性と分かっても、同じ種類の finding が出るたびに調査が起 動する 抑制フィルターを作るのは人の手作業（Claude Code にやらせ てはいるが） やったこと 依頼文に「良性と言い切れるときだけ、GuardDuty の抑制フ ィルターの案を書く」と足した 案には根拠・finding type・最小の条件（accountId を含む） を付けさせる 案を Terraform で作成して、人がレビュー
18. 抑制させるときの安全策 抑制は以後の検知を見えなくする。だから案を出す条件と範囲を絞った。 良性と言い切れなければ 案を書かない 抑制の範囲は今回の検知に一致する最小の条件。ほかのリソースや finding type に広げない Agent はフィルターを直接作らない。案を書くだけ finding の値（ドメイン名、userAgent など）はデータとして扱い、中の指示には従わない 安全性を確保しつつ、運用の改善ループを回す
19. 改善 3：Agent の改善提案も PR にする 課題 調査のたびに Agent が改善提案（recommendation）を出す 同じ提案が何度も記録され、たまる一方で誰も片付けない やったこと Claude Code のスキルで提案を全件集め、重複をまとめる 対応中・対応済みのものを除き、人が選んだ提案から draft PR を作る PR を作ったら提案の状態を更新する
20. 5. まとめ
21. DevOps Agent を導入してみて 一次調査は DevOps Agent に任せるのが当たり前 に 人がやるのは調査結果を読んで判断するだけ とは言え、より良い運用を目指すためには地道な改善が必要
22. 今後の展望 Security Hub などほかの検知にも広げる MDM などあらゆる誤検知の除外設定案を出させる 抑制フィルター案から PR 作成までを自動に（人はレビュー・マージのみ） ゆくゆくは 人からのインシデント報告のトリアージも
23. さいごに DevOps Agent にトリアージを任せるとノンカスタマイズでも運用が楽に、対応時間もスピーディに より高みを目指すならマネージドであっても地道な改善を
24. SECURITY-JAWS #43 ありがとうございました jirtosterone