既存 EDR と AI Agent を連携する：SentinelOne、BYO
AI SOC AgentはEDRを置き換えません。SentinelOneを制御点として残し、権限と承認範囲を段階的に定める方法を解説します。
既存 EDR と AI Agent を連携する：SentinelOne、BYO
AI SOC Agent の導入に EDR の置き換えは必要ありません。EDR を telemetry と制御点として残し、agent の読み取り・提案・実行範囲を明確にします。
読み取り専用から始める
アラートのコンテキスト、エンドポイント履歴、ID、脅威インテリジェンスから開始し、証拠を確認します。
アクションを段階化する
提案、承認済み操作、低リスクの自動操作を分離し、本番隔離や ID 変更は承認にします。
境界を文書化する
対応データ、保持、レート制限、レスポンス、エスカレーション責任を明記します。
認証情報を発行する前に答える 2 つの問い
EDR は読み取り用に何を公開する必要があるか
推奨パターンとして、まずは次の範囲だけを求めます。
- 検知の内容。EDR 自身が付与する ID と、受信したままのペイロードを含む
- EDR 上のエンドポイントの識別情報（デバイス ID、ホスト名、所属する顧客または拠点）
- EDR エージェントの状態（最終確認時刻と現在の隔離状態を含む）
- 対象エンドポイントのプロセス、ネットワーク、ファイルのアクティビティ（期間を限定）
- EDR が自動で実施済みの処置（ブロック、ファイルの検疫、対処せず通過させたものなど）
選んだ連携方式（zcrSOAR が記載しているのは API、Webhook、Syslog、Native Connector、Custom Integration）で、このうちどれかを EDR が公開できない場合は、欠落として書き残します。AI agent に推測で埋めさせてはいけません。
どの操作なら要求を認めるか
1 回の呼び出しがどこまで届くかで分け、次に元に戻せるかを見ます。
- 1 台・元に戻せる：スキャンの実行、エンドポイントの隔離とその解除。解除にも同じ慎重さが要ります。直前まで疑っていた端末をネットワークへ戻す操作だからです
- 1 台・元に戻しにくい：ファイルの削除、プロセスの強制終了、リモートでのスクリプト実行
- 複数台、または EDR 自体：複数台への一括操作、EDR のポリシー変更、EDR エージェントのアンインストール
連携範囲の表
EDR の機能ごとに 1 行、顧客の環境ごとに記入します。記入できない行は、連携させない機能です。ゲート設定の列には、zcrSOAR が playbook のステップごとに記載している Autonomous、Approval、Blocked の 3 状態を使います。表の値は推奨パターンです。
| EDR の機能 | 方向 | 付与する最小権限の範囲 | ゲート設定 | 残す証拠 |
|---|
| 検知とエンドポイントの状態 | 読み取り | 顧客 1 社のテナントまたは拠点に限定した読み取り専用 | Autonomous（読み取りのみ） | EDR の検知 ID、受信したままのペイロード、最終確認時刻と隔離状態 |
| エンドポイントのアクティビティ履歴 | 読み取り | 読み取り専用。期間を限定し、操作用の認証情報とは分ける | Autonomous。ケースごとにクエリ予算を設定 | クエリ、対象期間、結果が完全か一部か |
| スキャンの実行 | 操作（元に戻せる） | 顧客 1 社のエンドポイントへのスキャンのみ | Approval。Autonomous は、低リスクの端末グループのうち、可逆で、見直し期間を通じて承認付きで運用し、後から取り消した承認がなく、元に戻す手順を試験した場合のみ | 承認者、デバイス ID、EDR 側のジョブ ID（EDR が返す場合）、結果 |
| エンドポイントの隔離 | 操作（元に戻せるが業務に影響） | 隔離のみ。1 要求につき 1 台 | Approval | 承認記録、資産の重要度、実行前後の状態 |
| 隔離の解除 | 操作（元に戻せるが、端末をネットワークへ戻す） | 解除のみ。1 要求につき 1 台 | Approval。端末が問題ないことを示す根拠を承認者に見せる | 承認者、その根拠、実行前後の状態 |
| ファイル削除、プロセス強制終了、リモートスクリプト、EDR ポリシー変更、EDR エージェントのアンインストール | 操作（元に戻しにくい） | AI agent が使える認証情報は付与しない | Blocked | 要求のたびに、要求者と理由を付けた手動タスクとして記録 |
推奨パターン：読み取りと操作は認証情報を分けます。そうすれば操作側だけを失効させても、読み取りは止まりません。EDR のロールでスキャン、隔離、解除を分けられない場合は、余分な操作を playbook で Blocked にし、その認証情報は表より広い権限を持つものとして扱います。「1 要求につき 1 台」は EDR のロールではなく、playbook のルールです。
記載済みの機能、推奨パターン、お客様側の設定
zcrSOAR の記載済み機能：EDR を含む複数の分類のシステムと連携します。カタログの例は、SentinelOne を通じたエンドポイントの隔離・解除とスキャンの実行を、ケースまたは playbook のステップから行うものです。zcrSOAR は各実行について、タイムスタンプ、ユーザー、操作、playbook、コネクタ、入力、結果を記録します。未承認の playbook は、組織が本番実行を許可するまで Draft、Test、Dry-run、Simulation Mode のままです。zcrSOAR の AI 機能は、プロンプトから playbook の下書きを作成してレビューに回すアシスタントです。
zcrMDR の記載済み機能：既存の EDR ワークフローと併用でき、連携内容、対応操作、SLA はオンボーディングで取り決めます。承認済みのチャネルパートナー経由で提供されるマネージドサービスです。
推奨パターンとお客様側の設定：表の値と、想定すべき障害の項の各確認は推奨パターンです。EDR 側の認証情報の作成、承認者の指名、スキャンを Autonomous にしてよい端末グループの判断、AI agent を zcrSOAR の playbook のステップにつなぐ作業は、お客様側の設定です。
想定すべき障害と、人へ引き継ぐ条件
古いテレメトリ：最終確認時刻が古い場合、その端末は再イメージングされたか、移動したか、電源が落ちているかもしれません。zcrCTEM は資産ごとの EDR カバレッジ（導入済み、欠落、未確認）を示し、死角の発見には役立ちますが、操作前の確認の代わりにはなりません。
推奨パターン：操作を伴うステップの前に必ず EDR エージェントと隔離の状態を読み直し、最終確認時刻が顧客の定めた基準より古ければ停止して、「コンテキスト不足」としてケースを担当者のキューへ回します。
引き継ぎ条件：重要な資産で EDR エージェントが欠落しているか、確認できない場合。
同じ検知が 2 経路で届く：zcrSOAR は接続済みの EDR から取り込めるほか、両方を導入していれば zcrSIEM と連携でき、zcrSIEM はエンドポイントなど複数の検知元からのアラートを 1 つのインシデントにまとめます。両方の経路でケースを作成する設定にした場合、1 件の検知が 2 つのケースになることがあります。
推奨パターン：EDR の検知 ID をすべてのケースに持たせ、作成前に同じ ID の未クローズのケースを探し、冪等キー（idempotency key）を「検知 ID＋操作＋対象」で組み立てます。こうすれば 2 回目の隔離要求は同じ要求と認識されます。
引き継ぎ条件：同じエンドポイントに 2 つのケースがある場合は、担当者が統合します。
API のレート制限：上限は EDR ベンダーの API ドキュメントで確認してください。調査用のクエリはたいてい操作より頻繁に呼ばれるため、先に上限へ達しやすくなります。
推奨パターン：期間を限定したクエリを使い、ケースごとにクエリ予算を設け、結果をケースに残して再利用し、操作を伴うステップは繰り返し再試行しません。API が HTTP 429（RFC 6585 が定義する、一定時間内の要求過多を示すステータス）を返したら、応答の指示に従って待ちます。Retry-After ヘッダーは付いてもよい（MAY）とされているだけで必須ではないため、playbook には既定の待機時間が必要です。
引き継ぎ条件：読み取りが完了しない場合は、不完全なデータで操作せず担当者へ回します。
MSP のテナント分離：複数の顧客で認証情報を共有すると、トークンが 1 回漏れる、または対象を 1 回誤るだけで、全顧客に影響します。
推奨パターン：顧客ごとに認証情報とコネクタを 1 つずつ用意してその顧客のテナントまたは拠点に限定し、操作を伴うステップの前に対象のデバイス ID がケース上の顧客のものか確認し、クエリ予算も顧客ごとに分けます。
引き継ぎ条件：対象が別の顧客のものなら、playbook を止めて担当者へ知らせます。
よくある質問
すでに使っている EDR（CrowdStrike など）をそのまま持ち込めますか？
EDR を残すのが推奨パターンです。zcrSOAR で記載されている例は SentinelOne です。CrowdStrike など他の EDR については、playbook を組む前に、どの操作が使えるかを承認済みのチャネルパートナーに書面で確認してください。
AI agent に操作を許す前に、どうテストしますか？
推奨パターンは、まず読み取り専用で運用し、過去の実際の検知について、AI agent が集めた情報とアナリストが手作業で集めた情報を比べることです。その後、操作を伴うステップを Approval にして Dry-run で動かします。
MSP の場合、顧客の端末の隔離は誰が承認しますか？
契約で決める事項なので、推奨パターンとして、オンボーディングの前に、顧客ごとに隔離と解除を承認できる人を書面で定めます。zcrSOAR は承認者を資産、拠点、事業部で振り分けられます。
出典
- IETF（RFC Editor）、RFC 6585: Additional HTTP Status Codes、2012 年 4 月、2026-09-28 閲覧
続き: Alert から証拠へ：監査可能な AI SOC workflow、Human-in-the-Loop SOC、AI SOC Agent ガイド、SentinelOneとCrowdStrikeのEDRログをSIEMに転送する方法
zcrMDR を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。