AI 支援 SOC と Autonomous SOC：運用モデルの選び方
適切なSOC運用モデルは、自律性の見せ方ではなく業務影響と証拠の品質、レビュー体制で決まります。両モデルの選び方を実務目線でわかりやすく解説します。
AI 支援 SOC と Autonomous SOC：運用モデルの選び方
適切な運用モデルは、マーケティング上の自律性ではなく、業務影響、証拠の品質、結果をレビューできる体制で決まります。
判断が重要なら支援型
影響の大きい操作や不完全なデータでは、調査、トリアージ、レポート、アナリスト学習に AI 支援が適しています。
低リスクの反復作業は限定自律
enrichment、重複排除、チケット振り分け、承認済み通知は、影響が限定され観測可能なら自動化できます。
エスカレーション契約を定義
意思決定者、必要な証拠、停止条件、人への連絡方法を文書化します。
自律度は製品単位でなくアクション単位で決める
実際の SOC では、自律度は製品全体で 1 つではなく、アクションごとに決めます。インシデントの要約は支援型の作業、承認を得てからノート PC を隔離するのは承認付き自動化、チケットに IP の評判情報を付けるだけなら、事前に誰かが承認しなくても回せます。
アクションの位置づけは、可逆性と影響範囲（検証用ノート PC 1 台なのか、ドメインコントローラなのか）という 2 つの性質で決まります。推奨パターンは次のとおりです。読み取りだけのステップや、メモ・タグの追加のように元に戻せるステップは、限定自律の候補です。本番環境の状態を変えるステップは、可逆で範囲が狭くても、まず人の承認から始めます。不可逆または広範囲のものは人が判断します。
アクションの段階づけの詳細は Human-in-the-Loop SOC を参照してください。OWASP の LLM 向けガイダンスは、承認の部分を裏づけています。Excessive Agency の典型的な根本原因として過剰な機能・権限・自律性を挙げ、影響の大きいアクションへの人の承認を対策としています。可逆性と影響範囲は当社の基準であり、OWASP のものではありません。
判断表：3 つの運用モデル
この表は推奨パターンであり、特定の製品を説明するものではありません。3 つのモデルは、AI 支援型（AI-assisted）、承認付き自動化（human-approved automation）、限定自律（bounded autonomy）です。
| 観点 | AI 支援型 | 承認付き自動化 | 限定自律 |
|---|
| 誰が決めるか | アナリスト。AI は要約とクエリ案を用意する | 指定した承認者。AI が提案し、承認後にプラットフォームが実行する | 文書化した方針。AI は事前承認済みの一覧の範囲でのみ動く |
| 典型的なアクション | 要約、確認用の検索案、次の手順の提案 | エンドポイントの隔離、アカウントの無効化、インジケータのブロック | タグやメモの追加、チケットの起票、読み取り専用の検索。事前承認済みの一覧にある可逆なステップに限る |
| 証拠の残し方 | アナリストのメモ、AI への入力、アナリストが確認したクエリ | 前の列に加え、提案、承認者、承認時刻、結果 | 前の列に加え、許可した方針と定期的な抜き取りレビュー |
| 人員への影響 | 全案件にアナリストが必要で、処理能力は人数に比例する | 対応時間内に連絡がつく承認者が必要。時間外も含む | 結果を確認し許可一覧を管理する責任者が必要。定常作業は最小だがゼロではない |
| 誤りを見つける場面 | アナリストが実行前に見つける。ただし要約だけでなく根拠となる証拠を確認した場合に限る | 承認者が見つける。ただし提案を実際に読んだ場合に限り、中身を見ずに承認すると誤りがそのまま実行される | 実行前には見つからない。事後の抜き取りレビューで見つけるため、一覧は狭く可逆なものに絞る |
| 選ぶ場面 | データが不完全、重要な資産、体制が新しい、初回導入 | 業務に影響し、手作業では遅すぎるアクション | 反復的で影響が小さく可逆であり、承認付きで十分に運用して信頼できた作業 |
| 例：サービスアカウントでのサインイン失敗の連続 | AI がタイムラインとクエリ案を作り、アナリストが判断する | AI がアカウントの無効化を提案し、指定された承認者が証拠を読んだうえで承認する | AI は IP の評判情報をメモとしてチケットに追記し、アカウントには触れない |
あらゆるベンダーに投げかける 4 つの質問
推奨パターンです。各質問のあとに、良い回答の目安を示します。
- システムはどのアクションをどのレベルで実行でき、その一覧を自社で変更できますか。良い回答は、編集可能なアクション別の一覧です。システム全体で 1 つだけの自律度設定では足りません。
- AI の部分は何にアクセスできますか（認証情報、コネクタ、スコープ）。良い回答は、コネクタごとの最小権限と、モデルの判断に任せず接続先のシステム側で行う権限チェックです。
- アクションの種類ごとに誰が承認でき、誰も応答しない場合はどうなりますか。良い回答は、ロールとタイムアウトを示し、代替動作として保留またはエスカレーションを挙げています。
- 各アクションは取り消せますか。どのような記録が残りますか。良い回答では、アクションごとに元に戻す手順が定義され、入力、根拠となる証拠、承認者、結果が監査人の読める形で残ります。
zcr が記載している内容と、お客様が決める内容
記載されている内容：zcrSOAR では、playbook の各ステップを Autonomous、Approval、Blocked のいずれかに設定します。Autonomous は即座に実行され、Approval はロールで制限された承認を待ち、Blocked はゲート設定を変更するまで実行されません。未承認の playbook は、組織が本番実行を許可するまで Draft、Test、Dry-run、Simulation Mode のままで、対応アクションは、ユーザー、入力、結果、実行状況とともに記録されます。zcrSIEM は自然言語の質問を、アナリストが確認できるクエリに変換しますが、SOAR は含まれません。承認と封じ込めアクションは zcrSOAR の機能です。
この記事での対応づけ（推奨パターン。記載された機能ではありません）：Approval は承認付き自動化、Autonomous は限定自律に対応し、Blocked はどのモデルにも共通の下限です。AI 支援型は、zcrSIEM の確認できるクエリを使って人が手作業で進める部分にあたります。記載されているゲート設定の対象は playbook のステップであり、AI agent 自身のツール呼び出しではありません。AI をこれらのレベルの下に置く設計は、お客様が行うことになります。
マネージドサービス：zcrSOC と zcrMDR は、承認済みのチャネルパートナーを通じて提供されます。zcrSOC の Essential はアラートの受領、トリアージ、月次レポートを対象とし、Response は対応調整、エスカレーション、IR 支援を加えます。対応時間は契約で定めます。推奨パターンは、サービスが実行できるアクションと承認者を、契約にも明記することです。
お客様の設定：どのステップを Autonomous にするか、誰が承認するか、どの資産を業務上重要とみなすかです。
限界、失敗パターン、エスカレーションの条件
承認キューは静かに機能しなくなることがあります。承認者がほぼすべてを承認する、あるいは滞留を解消するためにステップを Autonomous に引き上げる、という状態では、人の確認は遅延にしかなりません。zcrSOAR では承認キューの監視と承認記録の確認ができます。推奨パターンは、滞留している申請や、中身を読まずに通る承認がないかを確認し、時間外のルール（待機担当の承認者、マネージドサービスの対応時間、アクションを待たせる）も事前に決めておくことです。
推奨パターン：責任者を指名し、その人がアクションを 1 段階戻せるようにします（Autonomous から Approval、Approval から手動）。zcrSOAR では、そのステップのゲート設定を変更することにあたります。次のいずれかが起きたら戻します。
- 想定した範囲外の対象に触れた
- 元に戻す操作をしたが、以前の状態に戻らなかった（ホストの隔離は理屈の上では可逆ですが、業務に必要な処理を実行中のホストでは戻りません）
- 入力が不完全または古かった（例：ログソースが送信を止めていた）
- 記録を見ても、なぜ実行されたのかレビュー担当者が説明できない
- 対象が業務上重要な資産になった
よくある質問
完全自律型の SOC を目指すべきですか？
目標にはしないでください。限定自律が向くのは、読み取りやメモの追加のように可逆なステップです。封じ込め、不可逆なアクション、業務上重要な資産には、人の判断を残します。
人員が足りないチームは、限定自律で穴を埋められますか？
埋められるのは、メモやタグの追加、参照のような読み取り中心のステップだけです。人手不足は封じ込めステップを Autonomous に引き上げる理由になりません。承認者を増やす、時間外は待たせるアクションを決めておく、あるいは承認済みのチャネルパートナー経由でマネージドサービスを利用する、といった手段を先に検討してください。
ある運用モデルから次の運用モデルへ、どう移行すればよいですか？
推奨パターンは、AI 支援型から始め、そのステップを Dry-run または Simulation Mode で試したうえで Approval に移すことです。Autonomous に上げるのは、可逆で、見直し期間を通じて承認付きで運用し、後から取り消した承認がなく、元に戻す手順を試験したステップだけです。
出典
続き: 既存スタックを置き換えずに AI SOC を始める方法、SOCにおけるAgentic AIとは、AI SOC Agent ガイド
zcrSOC を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。