既存スタックを置き換えずに AI SOC を始める方法
実用的なAI SOCは、大規模な置き換えではなく測定可能な一つのworkflowから始めます。安全に範囲を広げる90日間の手順を解説します。
既存スタックを置き換えずに AI SOC を始める方法
実用的な AI SOC は大規模な置き換えではなく、測定可能な一つの workflow から始めます。権限を広げる前に control model を検証します。
1–30 日：観測
アラート要約または関連イベント収集を選び、read-only でアナリスト時間と修正率を記録します。
31–60 日：支援
レビュー可能なクエリ、レポート下書き、範囲を限定した ticket 操作を追加し、承認画面と監査記録を作ります。
61–90 日：改善
成果を比較し、弱い自動化を削除し、playbook を改善して低リスク操作の委任範囲を決めます。
初日までに決めておく 4 つのこと
表記：「zcr の資料に記載」は製品ドキュメントにある内容、「推奨パターン」は当社の助言、「お客様側の設定」はお客様の環境で設定していただく内容です。
- 資産と ID の文脈。あるホストの所有者を agent に尋ねると、実データがなくても流暢に答えてしまうことがあります。推奨パターン：最重要資産と特権アカウントについて、所有者・環境・重要度の一覧を作り、agent のアカウントから読めるようにします。完了の目安は、パイロット対象のアラートに関わるホストの所有者と重要度を、アナリストが一か所で確認できることです。
- ログの網羅性。パイロット対象のアラートに必要なログソースを洗い出し、それぞれがソース側のタイムスタンプ付きで届いていることを確認します。推奨パターン：ソースの稼働状況は agent 以外の手段で確認してください。ソースが止まっているのに agent が「関連する活動は確認されませんでした」と報告しても、誰も気づけないからです。完了の目安は、止まったソースが人の目に見えるフラグを出すことです。zcrLog はタイのコンピュータ犯罪法に対応したログ保持で、用途が別のため、パイロットには必要ありません。
- チケット運用。お客様側の設定：既存のチケットシステムに権限を絞ったサービスアカウントを作り、各下書きへのアナリストの判定を記録する欄を用意します。zcr の資料に記載：zcrSOAR はチケット管理ツールと連携できます。お使いの製品のコネクタは先に試験してください。完了の目安は、クエリで判定を集計できることです。
- 承認者の指名。推奨パターン：最初の playbook を作る前に、自動化しうる操作ごとに承認者 1 名、代理 1 名、agent のアクセスを止められる人を書き出します。zcr の資料に記載：zcrSOAR は操作の種類、重大度、資産、拠点、事業部門ごとに承認先を振り分け、操作をロールで制限できます。完了の目安は、計画した操作のすべてに承認者と代理がいることです。
パイロットの対象を選ぶ
推奨パターン：次の 5 つの条件をすべて満たすアラートを 1 種類だけ選びます。
- 出力が「読む」か「下書き」で、システムの変更ではない（要約、コンテキストを補ったチケットなど）。
- 30 日以内にベースラインが取れる頻度で発生する。
- 必要なデータがすでに運用中のツール経由で届いている。エンドポイント用エージェントの新規導入や新しいログソースが必要なら、それは 2 つ目のプロジェクトです。
- 誤りが同じシフト内に見つかり、元に戻すコストが低い。
- 担当者が 1 人指名されていて、毎営業日に出力を読む。
ブルートフォースは、繰り返し発生し、データがすでに運用中のツール経由で届いていれば、条件 2 と 3 を満たせます。zcrSIEM には定義済みユースケース、zcrSOAR には標準の playbook の種類が用意されています（zcr の資料に記載）。同じアラートでもホストの隔離やアカウントの無効化は条件 1 と 4 を満たさないため、パイロットには含めません。
30/60/90 日ロードマップ
各期間は、終了条件がすべて「はい」になって初めて終わります。判定はチケットとログから人かクエリが読み取り、モデル自身の自己評価は使いません。
| 期間 | 目的 | 具体的な成果物 | 終了条件（はい／いいえ） | 手作業のまま残すもの |
|---|
| 1–30 日：観測 | パイロット対象のアラートで agent を読み取り専用で動かし、ベースラインを把握する | パイロット対象ソースへの読み取り専用アクセス；agent の要約をアナリスト自身の作業と並べて残すレビューログ；手作業の手順書；アラート 1 件あたりのアナリスト作業時間と修正率のベースライン | ベースラインが期間全体をカバーしている；すべての要約が元のイベントにリンクしている；「関連する活動は確認されませんでした」の回答をすべてソースの稼働状況と照合した | トリアージの判断、チケットの更新、システムへの変更のすべて |
| 31–60 日：支援 | 下書きと範囲を限定した操作を、承認者を明確にして本番のワークフローに組み込む | 本番チケット上の下書きと生成クエリ（下書きと明示）；パイロット対象アラート向けの playbook 1 本（標準提供のものか AI が下書きしたもの）を、組織が許可するまで Dry-run または Simulation Mode に置き、状態を変えるステップは Approval か Blocked に設定；承認マトリクスに承認者を登録し、代理は当番表に記録 | すべての下書きにアナリストの判定がある；状態を変えるステップが、承認者の記録なしに実行されていない；すべての承認者に代理がいる | 重大度の判断とクローズ；封じ込めとアカウント変更は、自分で実行するか承認するかを問わず人の判断 |
| 61–90 日：改善 | ベースラインと比較し、役に立たない自動化を外し、人を介さず動かしてよい範囲を決める | チケットデータからクエリで作る前後比較；自動化ごとの維持・絞り込み・廃止の決定；playbook のバージョン履歴の見直しとロールバックの試験；ステップごとに Approval・Autonomous・Blocked を書面で決定 | パイロットの責任者が前後比較をレビューした；自動化ごとの決定が、記録された根拠を挙げている；ロールバックが試験で成功した；次のユースケースについて進める・保留・中止の決定が書面にある | 最重要資産、元に戻せない操作、委任に所有者の署名がないステップ |
zcr の資料に記載（表の中）：zcrSOAR のステップ単位のゲート設定、Dry-run・Simulation Mode、ロールバック付きのバージョン履歴、AI が下書きする playbook、zcrSIEM が質問から作る確認可能なクエリ。
お客様側の設定：サービスアカウントとそのアクセス権、判定欄、承認マトリクス、代理の当番表。表のそれ以外は推奨パターンです。
限界、失敗のしかた、停止条件
OWASP の「LLM06:2025 Excessive Agency」は、根本原因として過剰な機能、過剰な権限、過剰な自律の 3 つを挙げ、影響の大きい操作に人の承認を求めることを緩和策に含めています。推奨パターン：期間が変わるたびに、agent が何を呼び出せるか、接続先でどんな権限を持つか、人を介さず何が動くかを確認します。
次のいずれかに当てはまったら、停止してパイロット対象アラートの手作業の手順に戻し、パイロットの責任者に伝えます。
- パイロット対象のソースが止まっていたのに、誰かが agent の出力を確認するまで気づかなかった
- 要約が、元の証拠にあったイベントを落としていた（原因が分かるまで範囲を広げない）
- 状態を変えるステップが、承認者の記録がないまま実行された
- 承認キューが丁寧に読める量を超えた（承認する人を増やすのではなく、範囲を絞る）
推奨パターン：アラート内のメール件名、URL、user agent などは攻撃者が操作できる文字列なので、要約するためのデータとして扱い、指示としては扱いません。
Approval のステップは人を待つため、当直者のいない深夜 2 時の承認は待たされます。許容できるかを事前に決めてください。
よくある質問
既存の SIEM、EDR、チケットシステムを置き換えずに始められますか？
はい。zcrSOAR は既存のファイアウォール、Active Directory、EDR、SIEM、メールセキュリティ、ID 基盤、チケット管理ツールと連携でき、zcrSIEM を必須としません。zcrSIEM は別製品で、CEF、LEEF、Syslog、JSON 形式の既存ログソースのログを、元のシステムを変更せずに解析・正規化でき、zcrLog を必要とせず、SOAR は含みません。
AI に playbook を書かせられますか？
下書きまでは可能です。zcrSOAR の AI アシスタントがプロンプトから playbook を下書きし、確認したうえで使えます。下書きは未承認のため、状態を変えるステップは Approval か Blocked から始めてください（推奨パターン）。
どんなときにマネージドサービスへ一部を任せるべきですか？
推奨パターン：営業時間外に承認者を立てられない、または agent の出力を毎日読める人がいない場合に検討します。zcrMDR は承認済みのチャネルパートナー経由で提供されるマネージドサービスです。対応時間、範囲、連携内容は契約と導入時に取り決めるため、承認が対象に含まれるかを確認してください。
出典
続き: AI Agent で証拠を隠さず Alert Fatigue を減らす方法、Human-in-the-Loop SOC、Alert から証拠へ：監査可能な AI SOC workflow、AI SOC Agent ガイド
zcrMDR を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。
次に読む