AIエージェントでSOC監視業務を半自動化した話〜AI活用の理想と現実〜

この記事は KINTOテクノロジーズ Advent Calendar 2025 の20日目の記事です🎅🎄
 1. はじめにこんにちは！ セキュリティ・プライバシー部でサイバーセキュリティに関する業務を担当している、たなちゅーです！
今回は、AI エージェントを活用して SOC 監視業務を半自動化し、作業時間を約半分に短縮した取り組みについてお話しします。
「AI エージェントを使えばすぐできそう！」と思って始めましたが、実際に取り組みを進めてみると試行錯誤の連続で、想定外の落とし穴や失敗がたくさんありました。この記事では、うまくいったことだけでなく、失敗からの学びも含めて共有したいと思います。
 2. 背景：SOC 業務の課題 SOCとは？SOC（Security Operation Center）は、組織の IT 環境を監視し、サイバー攻撃や不正アクセスなどのセキュリティ脅威を検知・分析・対処する役割を担います。
主な業務内容は以下の通りです。
ログ・アラート監視：システムのログやアラートを監視し、異常を検知
脅威分析：検知したアラートが本当の脅威かどうかを分析・判断
インシデント対応：セキュリティインシデント発生時の初動対応や調査
レポーティング：監視結果や対応状況を関係者に報告
いわば、組織のサイバーセキュリティにおける「最前線」です。
 監視業務の課題ログ・アラート監視の業務には、リアルタイムのアラート監視と定期的なログ監視・分析があります。今回、半自動化の対象としたのは後者の定期的なログ監視です。
定期的なログ監視では、SIEM（Splunk Cloud）を使い、以下の作業を手動で行っていました。
ダッシュボード上のイベント内容を確認
深掘り調査のための SPL クエリを実行
セキュリティインシデントか否かを判断
調査結果のレポートを作成
この手動運用は、1回あたり2〜3時間の作業時間がかかり、大きな業務負担になっていました。また、ログ解析スキルや SPL の知識が必要なため、特定の担当者に知識やノウハウが集中し、属人化が進んでいるという課題もありました。
これらの課題を解決するため、AI エージェント（OpenAI Codex IDE）と Splunk MCP を活用した半自動化に取り組みました。
 使用したツールMCP クライアント
OpenAI Codex IDE：OpenAI の AI エージェント「Codex」の VSCode 拡張機能。MCP サーバーと連携し、プロンプトに基づいた処理を実行
モデルは「GPT-5.1-Codex-Max」、推論は「High」に設定

MCP サーバー
Splunk MCP：Splunk Cloud へのログ検索を実行

その他
Splunk Cloud：システムのログ集約・分析基盤（SIEM）
Github：メンバー間でのプロンプト共有基盤

 3. 実現したこと結論から言うと、この取り組みにより監視業務の作業時間を2〜3時間から1〜1.5時間へ、約半分に短縮できました。ここからは、Before/After の運用フローを比較しながら、具体的に何が変わったのかを紹介します。
 Before：半自動化前の運用フロー半自動化以前は、以下の流れで定期的な監視業務を手動で実施しており、1回あたり2〜3時間を要していました。特にステップ1「一次調査」とステップ2「深掘り調査の要否判断」はログ解析スキルや SPL の知識が必要なため、属人化が課題となっていました。
一次調査を実施
ダッシュボードに表示された各イベントごとに、Splunk Cloud を使用して以下のような一次調査を実施
対象イベント前後のタイムラインを確認
対象イベントの調査の軸となる情報を基に異常性の有無を確認

一次調査結果を各イベントごとに整理

深掘り調査の要否判断
整理した情報を基に、深掘り調査の必要性を判断

深掘り調査の実施
ヒアリング
SIEM 外の情報収集（チャット内容、社内ナレッジなど）

セキュリティインシデントか否かの判断
深掘り調査の結果を基に、セキュリティインシデントかどうかを判断

セキュリティインシデント対応
関係者と連携し、セキュリティインシデント対応を実施

 After：半自動化後の運用フローAI エージェントがステップ1・2を担当し、人間は品質チェックと最終判断に集中する形としました。これにより作業時間は約半分（1〜1.5時間）に短縮。さらに、属人化していた監視業務の標準化も進み、チームとして運用できる体制が整いました。
一次調査を実施（AI エージェント）
Splunk MCP でダッシュボード相当の検索を実行し、各イベントごとに、以下のような一次調査を実施
対象イベント前後のタイムラインを確認
対象イベントの調査の軸となる情報を基に異常性の有無を確認

一次調査結果を各イベントごとに整理

深掘り調査の一次要否判断（AI エージェント）
整理した情報を基に、深掘り調査の必要性を一次判断
一次調査結果と判断内容を整理したレポートを作成

レポートの品質チェック・深掘り要否判断（人間）
AI エージェントが作成したレポートの品質を人間がチェック
品質チェックと合わせて、深掘り調査の必要性を人間が判断

深掘り調査の実施（人間）
ヒアリング
SIEM 外の情報収集（チャット内容、社内ナレッジなど）

セキュリティインシデントか否かの判断（人間）
深掘り調査の結果を基に、セキュリティインシデントかどうかを判断

セキュリティインシデント対応（人間）
関係者と連携し、セキュリティインシデント対応を実施

Before/After の運用フローを図で比較すると、このような形です。
 Before/After の運用フローの比較図
 具体例：半自動化後の運用フローでは、実際にどのように監視業務を進めているのか、具体的な流れを紹介します。前述の6ステップを、実務の観点から5つの作業に整理しています。
監視用プロンプトを準備：GitHub リポジトリから最新の監視用プロンプト（md ファイル）を取得
 クローンした監視用プロンプト
Codex で一次調査（深掘り調査含む）を実行：プロンプトファイルを指定して Codex に処理を実行
指示例：xxxxx/prompts/yyyyy.md のタスクを実行してください
処理時間：1プロンプトあたり10〜20分程度

 Codexへの指示
レポートの品質チェック・深掘り要否を判断：AI エージェントが作成したレポートを確認し、深掘り調査の必要性を判断
ログ件数や日時、調査内容の妥当性をチェック
品質チェック用ダッシュボードを作成し、チェック作業を効率化

 AI エージェントによる監視レポート
 品質チェック用ダッシュボード
深掘り調査を実施：必要に応じて追加調査を行い、セキュリティインシデントか否かを判断
Splunk Cloud で手動検索
Codex + Splunk MCP を活用した追加調査
セキュリティインシデント対応：インシデントと判断した場合、関係者と連携して対応を実施
 4. 学んだこと...と、ここまでは「うまくいった話」です。

ここからは、半自動化にたどり着くまでに経験した失敗や学びを共有します。
 【学び１】すべては「手順の明確化」から始まる最初に試したのは、Codex やその他の生成 AI とチャットで対話しながらプロンプトを作るアプローチでした。
「SOC の監視を自動化するプロンプトを作りたいんだけど...」

「こんな感じで...」

「うーん、もうちょっとこうして...」
このようなやり取りを何度も重ねて作成した初期のプロンプトは、以下のような構成でした。
## 1. メタデータ
- 出力先、必要ツール、タイムゾーン

## 2. ロール/前提
- SOC 調査アナリストとしての役割定義
- 前提

## 3. 共通解析手順（全 SPL 共通）
1. 調査対象イベントの特定（主指標の定義）
2. 深掘り（タイムレンジ拡張、ピボット観点）
3. エラー/事象の分類
4. 30日観測
5. 優先度判定
6. 不明点の明確化
7. 調査ログ（実行した SPL クエリ一覧）

## 4. 優先度判定基準（全SPL共通）
- 要（即時対応）/ 観察 / 不要 の3段階と具体的条件
- **要（即時対応）**
  - ベースライン比 ≥ 2.0 または P95超過、かつ分母 ≥ 30
  - 条件1 → 条件2：60分以内に失敗 ≥ 2
  - 条件3：xxx_count ≥ 2 かつ yyy_count ≥ 3
  ...（以下、複雑な条件が続く）

## 5. 調査結果整理
- 時間帯別サマリ表のヘッダー定義
- 主指標（SPL 別の記載ルール）

## 6. 調査用 SPL 一覧
- 調査観点①
- 調査観点②
...（以下、いくつかの調査観点が続く）

## 7. 出力フォーマット（必須）
- 調査概要
- 時間帯別サマリ表
- 調査ログ（実行した SPL クエリ一覧）
一見すると形になっているように見えますが、実際に運用してみると以下の問題が発生しました。
基準が曖昧：「ベースライン」の算出方法が不明確で、P95の計算に必要なデータ量も現実的ではなかった
条件が複雑すぎる：AI エージェントが正しく解釈できず、人間でさえ理解が難しいケースがあった。結果として、一次調査レポートの品質にブレが生じた
横展開できない：プロンプトが特定システムに過度に最適化されており、別システムへ展開する際はゼロから作り直しが必要だった
根本原因は明確でした。SOC 監視業務において「何を」「どういう基準で」判断しているのか、どのような出力を期待しているのか。これらを詳細に整理・文書化できていなかったのです。
解決策：手順書駆動プロンプト開発
そこでアプローチを変えました。やったことはとてもシンプルです。
まず「手順書」を作成する（人間が読んでも迷わず実行できる調査手順・判断基準を明文化）
その手順書を生成 AI に渡して「この手順書に沿って SOC 監視用のプロンプトを作って」と依頼する
すなわち、バイブコーディング感覚でプロンプトを作成するのではなく、仕様書駆動開発の考え方に倣い、期待値を先に整理してからプロンプトを作成してもらうアプローチです。
 調査観点などを記載した手順書
効果は劇的でした。
最初のアプローチでは、1〜2週間かけて試行錯誤を繰り返しても納得のいくプロンプトが作れませんでした。しかし、手順書駆動プロンプト開発に切り替えたところ、手順書作成を含めて約2日間で期待通りの一次調査レポートを出力できるプロンプトが完成しました。
さらに、同じ要領で他システム向けのプロンプトも作成できるため、レポートフォーマットを統一しながら横展開も容易になりました。
以下は、このアプローチで作成したプロンプトの構成です。
## 1. メタデータ
- 出力先、必要ツール、タイムゾーン

## 2. 役割定義
- SOC 調査アナリストとしての役割

## 3. 前提条件
- 監視対象期間
- 既知情報（静観対象）
- 無害化ルール

## 4. 監視項目
各監視項目ごとに以下を記載：
- 監視目的
- SPL クエリ
   - サーチマクロを活用することで、トークン節約、ブレ軽減
- 判断基準
   - 「調査必須：〇〇期間に〇〇件以上のイベント」など明確な基準を記載
- 深掘り手順
   - 深掘り時の観点や使用する SPL を記載
- 出力要件
   - 出力時の必要情報を明記

## 5. 出力フォーマット
各監視項目ごとに具体的なフォーマットを記載：
- 監視概要・サマリ
- 詳細結果
   - 表形式で出力（項目名や値の記述フォーマットなども明記）
- 総合所見・推奨対応
- 調査ログ
   - 実際に使用した SPL と検索結果サマリ等を全て調査履歴として記録

## 6. 注意事項
- 必須ルールを箇条書き

## 7. 実行手順
- 実行手順をいくつかのステップに分けて記載
学び

急がば回れ。まず業務内容を整理・文書化する。それを基にプロンプトを作成することで、AI エージェントとの認識のズレがなくなり、期待通りの出力が得られる。
 【学び２】「できること」と「やるべきこと」は違うこれが一番の失敗談かもしれません。
AI エージェントと Splunk MCP を組み合わせると、「過度に複雑な調査」が気軽にできてしまいます。「せっかくだから、この観点も追加しよう」「もっと深掘りできるな…」と、気づけば監視対象の観点を広げすぎて、本来注力すべきポイントがぼやけていました。
さらに厄介なのは、「やっている感」が出てしまうことです。AI エージェントが大量の分析をしてくれるので、なんとなく仕事をした気になります。しかし実際には、生成されたレポートのレビューに時間がかかり、本末転倒な状態に陥っていました。
あくまで「半自動化」であり、最終判断は人間が行います。人間がレビューできる範囲で、本来注力すべき観点に絞ること。この意識が大事だと学びました。
学び

AI エージェントができることを最大限やるのではなく、人間のレビューも含めた全体を俯瞰し、「監視の意図」に立ち返る。「やっている感」に惑わされない。
 【学び３】業務の標準化効果は想定以上だった！当初は「作業時間の短縮」を主な目的としていましたが、「業務の標準化」という副次的効果が想定以上でした。
詳細な手順書を作成したことで、判断基準が明文化されたことに加えて、ログ解析スキルや SPL の知識を要する部分を AI エージェントが担当することで、専門知識の有無に関わらず、誰が実施しても一定の品質で監視業務が行えるようになりました。
結果として、引き継ぎがしやすくなり、チーム全体の対応力向上にもつながっています。
学び

AI エージェント活用は効率化だけでなく、業務の標準化・属人化の解消にも大きな効果がある。
 5. まだ課題として残っていること半自動化を実現したものの、正直に言うとまだ改善の余地があります。
品質チェックに一定時間がかかる

AI エージェントの出力を鵜呑みにはできないため、人間によるレビューは必須です。ログの日時や件数、判断内容の妥当性チェックには、依然として一定の時間を要します。
ナレッジの蓄積・反映の仕組み

日々の調査で得られる「このパターンは実は〇〇だった」といった細かなナレッジを、プロンプトへフィードバックする仕組みが整っていません。現在、調査履歴を参照する形で解消できないか検証中です。
手順書やプロンプト、監視観点のメンテナンス

新しい脅威パターンや監視から得られた知見に合わせて、手順書・プロンプト・監視観点（SPL）を更新する必要があります。現状、これらについては属人的で、メンテナンスプロセスの標準化が今後の課題です。
 6. まとめ今回の取り組みを通じて学んだ3つのことを振り返ります。
すべては「手順の明確化」から始まる

急がば回れ。まず業務内容を整理・文書化する。これを基にプロンプトを作成することで、AI エージェントとの認識のズレがなくなり、期待通りの出力が得られる。
「できること」と「やるべきこと」は違う

AI エージェントができることを最大限やるのではなく、人間のレビューも含めた全体を俯瞰し、「監視の意図」に立ち返る。「やっている感」に惑わされない。
業務の標準化効果は想定以上

効率化だけでなく、業務の標準化・属人化の解消という効果も大きい。
「AI エージェントで業務効率化」というと華やかに聞こえますが、実際には地道な言語化作業と試行錯誤の連続でした。
この取り組みを通じて感じたのは、「業務効率化」ではなく「業務の棚卸しと標準化」と捉えること、そして完全自動化ではなく「半自動化」という現実的なゴールを設定することの大切さです。
この記事が、AI エージェントの業務活用を検討している方の参考になれば幸いです。