ログイン

トップ

アウェアネス

PhishAI

AI SOC

サービス一覧

会社概要

記事

ホワイトペーパー

セミナー

用語集

ニュース

インシデント速報

お問い合わせ

資料ダウンロード

Insight

2026/09/11

SOARとAI SOCの違い：プレイブック自動化からエージェントによる自律調査へ

迎健太

SOARは定型作業のプレイブック自動化でSOCの負荷を下げてきましたが、効果は「手順を書けた範囲」に留まりがちです。SOARの定義と限界、AIエージェントによる自律調査との違い、併用モデルと移行ステップ、人間の承認・監査などの統制設計を解説します。

「SOARを導入したのに、アラートの多くは今も人が見ている」「プレイブックの手直しに追われ、新しい自動化に手が回らない」。セキュリティ運用の現場で、こうした声を聞く機会が増えています。SOAR（Security Orchestration, Automation and Response：セキュリティの連携・自動化・対応）は、定型作業を自動化してSOC（Security Operation Center）の負荷を下げる仕組みとして普及しましたが、その効果が「あらかじめ手順を書けた範囲」に留まりやすいことも、多くの組織で経験的に知られるようになっています。

本記事では、SOARの定義と得意分野を整理したうえで、その構造的な限界を解説し、AIエージェントによる「自律調査」がSOARと何が違い、どう併用すべきかを、移行のステップと統制の観点から考えます。特定の製品を比較するものではなく、運用の自動化を「手順の自動化」から「調査・判断の自律化」へ進める際の考え方を示すことが目的です。AI SOCという概念の全体像は「AI SOCとは？仕組み・従来型SOCとの違い・導入メリット」で解説しています。

SOARとは何か：定義・3つの要素・普及の背景

SOARとは、セキュリティ運用に関わる複数のツールを連携させ（Orchestration）、繰り返し発生する作業を自動化し（Automation）、インシデントへの対応（Response）を一つの基盤で管理する仕組み、またはその製品カテゴリを指します。SIEM（Security Information and Event Management）が「ログを集めて検知する」役割を担うのに対し、SOARは「検知した後に何をするか」を担う存在として、2010年代後半以降に普及が進みました。

背景には、SIEMやEDR（Endpoint Detection and Response）のアラートが人手で処理できる量を超えたこと、運用に関わるツールが増えてアナリストが複数の画面を行き来する時間が膨らんだこと、対応品質が担当者の経験に依存し標準化と記録が求められたこと、という三つの課題があります。米国NISTが2025年4月に公開したインシデント対応の指針SP 800-61 Rev.3でも、既知の悪意ある活動や不審な活動を継続的に監視するツールの例としてSIEMとSOARが挙げられており（NIST, 2025）、SOARは今や標準的な運用部品の一つと位置づけられています。

Orchestration・Automation・Responseの3要素

Orchestration（連携）は、異なる製品のAPIを呼び出して情報を集め、指示を出す機能です。たとえば、アラートに含まれるIPアドレスを脅威インテリジェンスに照会し、該当端末の情報をEDRから取得し、ユーザーの所属をID管理システムから引くという一連の問い合わせを、一つの流れとして実行します。Automation（自動化）はその流れを定義済みの条件に従って人手なしで実行する機能、Response（対応）は端末のネットワーク隔離、アカウント無効化、メール隔離、チケット起票や通知など、実際に環境へ働きかける機能です。三つが揃うことで、「検知→情報収集→判断材料の整理→初動対応→記録」という流れの一部を機械に任せられるようになります。

プレイブックとケース管理

SOARの中核が「プレイブック」です。特定のアラートやインシデントが発生したときに実行する対応・修復の手順と分岐ロジックを、ワークフローとして定義したものです。SIEMにSOAR機能を統合した製品の公開ドキュメントでは、プレイブックを「対応と修復のアクションとロジックの集合で、ルーチンとして実行できるもの」と説明し、SOARの主目的を「繰り返し発生し、予測可能なエンリッチメント・対応・修復の作業を自動化し、高度な脅威の詳細な調査やハンティングに時間と資源を振り向けること」としています（Microsoft Learn, 2026）。「繰り返し発生し、予測可能な」作業こそがSOARの対象であり、逆に言えば、予測できない事象は最初から対象の外にあるということです。

もう一つの柱がケース管理です。インシデントごとに状態、担当者、重大度、タグ、アナリストが実施すべきタスクを管理し、誰がいつ何をしたかを記録します。同ドキュメントでは、プレイブックを使わなくても自動化ルールだけで「タスクの追加」「状態の変更」「重大度の変更」「担当者の割り当て」「タグの付与」ができると説明されています（Microsoft Learn, 2026）。派手さのない機能ですが、監査対応や引き継ぎ、対応品質のばらつき抑制において、実務上は最も価値のある部分の一つです。

SOARが得意なこと

定型作業の自動実行：IPアドレスやハッシュ値の評価照会、ユーザー・端末情報の付加（エンリッチメント）、チケット起票、通知、明確な条件を満たした場合の端末隔離やアカウント無効化。
ツール間の連携：EDR、SIEM、ID管理、メールセキュリティ、チケット管理などをAPIでつなぎ、画面を行き来する時間を削減する。
記録と標準化：誰がいつどの操作を実行したかを自動的に残し、対応手順を組織の標準として定着させる。

いずれも「手順が事前に決まっている」作業です。2023年に900名のセキュリティ実務者を対象に行われた調査では、25%が「業務時間の半分以上を退屈な手作業に費やしている」と回答し、93%が「自動化が進めば仕事と生活のバランスが改善する」と考えていました（Tines "Voice of the SOC", 2023）。手作業を減らしたいという現場の要請は明確で、SOARはそれに応える技術として受け入れられてきました。

SOARの限界：プレイブック中心の自動化が行き詰まる4つの理由

ここで述べるのは特定製品の欠点ではなく、「手順をあらかじめ書いて実行する」というアプローチそのものに由来する、一般的な制約です。

1. プレイブックの作成・保守にコストがかかる

プレイブックは、アラートの種類ごと、連携先ごとに設計・実装・テストが必要です。連携先がAPI仕様を変えれば手直しが必要になり、検知ルールを追加すれば対応するプレイブックも増えます。一般に、SOARで自動化できる範囲は、組織が書いて維持できるプレイブックの数と品質に比例します。ところが、プレイブックを書けるのはSOC業務と開発の両方を理解する人材であり、多くの日本企業でその人材は限られています。結果として、導入初期に作った十数本のプレイブックが更新されずに残り、自動化の範囲が頭打ちになる状況が起こりやすくなります。

2. 想定外の事象に弱い

プレイブックは「この条件なら、この手順」という形で書かれるため、条件に当てはまらないアラート、複数の兆候が組み合わさった攻撃、正規ツールを悪用した攻撃など、事前に想定していなかった事象には基本的に対応できません。MITRE ATT&CKのEnterpriseマトリクスは、実際に観測された攻撃者の戦術・技術を15の戦術に分類して整理していますが（MITRE ATT&CK v19.2, 2026）、その組み合わせは膨大で、一つひとつにプレイブックを用意することは現実的ではありません。IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の3位に「AIの利用をめぐるサイバーリスク」が初めて選出されており（IPA, 2026）、攻撃側の変化の速さは今後さらに増すと考えるのが妥当です。

3. 「判断」は人に残る

SOARは手順を実行しますが、「このアラートは本当に脅威か」「影響範囲はどこまでか」「今、端末を隔離してよいか」という判断は行いません。プレイブックが情報を集めて整理した後、最終的に判断するのはアナリストです。つまり、SOARが短縮するのは判断の「前後」の作業であり、判断そのものにかかる時間と、判断できる人材の不足という根本的な課題は残ります。前述の調査では、実務者の63%が何らかのバーンアウト（燃え尽き）を経験し、55%が1年以内に転職する可能性があると回答しています（Tines "Voice of the SOC", 2023）。アラートが増えれば判断待ちの行列が伸び、それを処理する人材は疲弊していくという構造は、SOARだけでは変わりません。

4. 導入後の運用負荷が想定より大きい

SOARは導入して終わりではなく、プレイブックの改善、誤作動の調整、連携先の変更対応、自動実行結果の確認といった運用が継続的に発生します。とくに端末隔離やアカウント停止を行う「対応」のプレイブックは、誤作動すれば業務を止めるため、起動条件を厳しく絞る必要があります。条件を絞れば自動化の範囲は狭まり、広げれば誤作動のリスクが高まるというトレードオフの中で、調整を続けることになります。一般に、SOARの効果を持続させるには専任に近い担当者が必要になり、その負荷が「人手を減らす」という当初の目的と矛盾する場面も少なくありません。

AIエージェントによる自律調査とは何が違うのか

ここで言うAIエージェントとは、大規模言語モデル（LLM）を中核に、与えられた目的に向かって「次に何を調べるか」を自ら決め、SIEMへのクエリやEDRからの端末情報取得などのツールを呼び出し、結果を踏まえて次の行動を選び、結論と根拠を報告するソフトウェアを指します。SOARとの本質的な違いは、人が「手順」を書くのか、「目的」を与えるのかという点にあります。

手順を書くのか、目的を与えるのか

SOARのプレイブックは「不審なログインのアラートが来たら、IPアドレスを照会し、過去24時間の同一ユーザーのログインを検索し、結果をチケットに添付する」というように、調査手順を人が事前に定義します。一方、AIエージェントには「このアラートが真の脅威かどうかを判定し、根拠を示す」という目的を与えます。エージェントは内容に応じて、IPアドレスの評価を確認し、同一ユーザーの直近の挙動を調べ、必要なら端末側のプロセス実行履歴を追い、他のアラートとの関連を探すという調査を自ら組み立てます。手順が固定されていないため、アラートの種類ごとにプレイブックを用意する必要がなく、検知ルールを追加しても調査側の追加実装は原則として不要です。

この違いは、SOCで最も時間を要してきた一次調査（トリアージ）の性質を変えます。プレイブックが「材料を集めて人に渡す」ところで止まるのに対し、エージェントは材料を集めたうえで「これは誤検知である」「これは調査を深めるべき」という一次判断まで行い、その理由を記述します。一次調査の手順と精度の担保については「アラートトリアージの自動化：AIエージェントによる一次調査の手順と精度の担保」で詳しく解説しています。

非定型のアラートへの対応

SOARが弱い「想定外」に対して、AIエージェントは相対的に強みを持ちます。事前に定義されていないアラートでも、「攻撃者の一般的な行動」「この組織の通常の挙動」「アラートに含まれる要素の意味」といった知識をもとに調査方針を立てられるためです。たとえば、正規の管理ツールが深夜に実行されたというアラートに対し、端末の利用者、直前の認証、同時刻の他端末での類似挙動を横断的に確認し、単体では判断できない事象を文脈の中で評価します。単体のアラートでは見えない攻撃の全体像を捉える考え方は「ログの相関分析はなぜ重要か」でも解説しています。ただし、「非定型に対応できる」ことと「常に正しい」ことは同義ではありません。エージェントの判断には誤りが含まれ得るため、「どれだけ広く調査できるか」と同時に、「その判断をどう検証し、誤りをどう発見するか」を設計に組み込む必要があります。

説明可能性をどう設計するか

SOARのプレイブックは実行した手順がそのまま記録になるため、「何をしたか」の説明は容易です。AIエージェントは調査の経路が毎回異なるため、説明可能性を意識的に設計しなければなりません。実務的には、少なくとも次の要素を調査結果に含めることが求められます。

結論と確度：真の脅威か誤検知か、どの程度の確度でそう判断したか。
根拠となる証跡：判断の材料にしたログ、実行したクエリ、参照した端末・ユーザー情報。
攻撃手法との対応：観測された挙動がMITRE ATT&CKのどの戦術・技術に該当するか。ATT&CKは「実世界の観測に基づく攻撃者の戦術と技術の、世界中からアクセス可能な知識ベース」であり（MITRE, 2026）、人とAIが共通の語彙で攻撃を語る基盤になります。
推奨した対処と実行済みの対処の区別：提案しただけのものと、実際に実行したものを明確に分ける。

こうした出力があれば、アナリストは調査をゼロからやり直すのではなく、エージェントの結論を「レビュー」する立場に移れます。アナリストを置き換えるのではなく増強するという考え方は「AIエージェントSOCの時代―アナリストを置き換えず増強する」で詳しく述べています。

併用モデルと移行のステップ：SOARを実行基盤、AIエージェントを調査・判断層に

SOARとAIエージェントは、どちらかを選ぶ関係ではありません。両者の得意分野は補完的であり、多くの組織にとって現実的なのは併用です。基本的な考え方は、「SOARを実行と記録の基盤に、AIエージェントを調査と一次判断の層に」置くことです。アラートが発生すると、まずエージェントが自律的に調査し、脅威か否か、影響範囲、推奨する対処を根拠とともに出力します。その結論に基づき、端末隔離やアカウント停止といった実際の対処は、権限と記録の仕組みが確立しているSOARのプレイブックが実行します。ケース管理もSOAR側に残し、エージェントの調査結果はケースに添付します。

この分担には三つの利点があります。既存のSOAR投資とプレイブック、連携設定が無駄にならないこと。環境へ働きかける「対応」の実行経路がSOARに一本化され、権限管理と監査が単純になること。そして、「判断待ち」で滞留していたアラートにエージェントが一次判断を提供することで、SOARの自動化範囲を制約していた「人の判断」というボトルネックが緩和されることです。SOARの側から見れば、プレイブックの起動条件を「人が確認した後」から「エージェントが根拠つきで判定した後」へ拡張できる、と言い換えられます。なお、この構成は外部委託（MSSやMDR）とも組み合わせられます。運用サービスの各形態とAI SOCの関係は「MDR・MSS・XDR・AI SOCの違いとは？セキュリティ運用サービスの選び方」で整理しています。

移行の5ステップ

現状の棚卸し：アラート種類別の件数、人が調査している割合、プレイブックで自動化済みの範囲、1件あたりの平均調査時間を把握します。「判断待ちで滞留しているアラート」の量が、エージェント導入の効果の上限を決めます。
読み取り専用での並走：エージェントにはSIEM・EDRへの読み取り権限のみを与え、既存運用と並行して調査させます。人の判断との一致率と、不一致の原因を分析します。
一次判断の委任：一致率と説明の品質が基準を満たしたアラート種別から、エージェントの一次判断を正式な運用に組み込みます。誤検知と判定されたものは抜き取りで確認し、脅威と判定されたものは人がレビューして対処を決めます。
対処の接続：エージェントの判定を起点にSOARのプレイブックを起動する経路を作ります。初期は「人の承認を経て実行」とし、影響が限定的で可逆な対処（チケット起票、追加ログの取得、通知など）から自動実行の範囲を広げます。
継続的な評価と改善：MTTR（平均復旧時間）、調査率、誤検知率などを定点観測し、判断の誤りをフィードバックします。NIST SP 800-61 Rev.3は、インシデント対応で得た教訓は多くの場合「復旧の完了後まで遅らせるのではなく、特定され次第共有すべき」だと述べており（NIST, 2025）、この考え方はエージェント運用の改善サイクルにもそのまま当てはまります。

とくにステップ2と3は、AI SOC製品を評価するPoC（概念実証）の中心となる工程です。確認すべき項目は「AI SOCの選び方：PoCで確認すべき評価項目と失敗しない導入ステップ」で詳しく解説しています。

リスクと統制：人間の承認・権限分離・監査ログ

AIエージェントの運用には固有のリスクがあります。誤った判断による見逃しや過剰な対処、意図しない操作、そして「なぜその結論に至ったか」を後から説明できない状態です。Gartnerは2025年6月、「エージェント型AIプロジェクトの40%超が、コストの増大、不明確なビジネス価値、または不十分なリスク統制を理由に、2027年末までに中止される」と予測し、既存製品を実質的な変更なしにエージェントと呼び替える「エージェント・ウォッシング」にも注意を促しています（Gartner, 2025）。一方で、IBMの「Cost of a Data Breach Report 2026」では、データ侵害の世界平均コストが前年比12%増の499万ドルに達する中、セキュリティにAIと自動化を広範に活用している組織では平均193万ドルのコスト削減効果が確認されています（IBM, 2026）。リスクを理由に活用を見送ることも、効果を理由に統制を省くことも、合理的ではありません。日本企業が実務上押さえるべき統制は次の三つです。

人間の承認（Human-in-the-loop）

不可逆または業務影響の大きい操作（サーバーの隔離、特権アカウントの停止、本番システムに関わる変更など）は、エージェントが「推奨」し、人が「承認」して実行する原則を置きます。承認なしで自動実行する対処は影響が限定的で可逆なものに限定し、その範囲を文書で定義します。NIST SP 800-61 Rev.3も、マルウェアの隔離のような一部の封じ込め措置をセキュリティ技術によって自動実行することを検討事項として挙げていますが（NIST, 2025）、対応全体の自動化を意味するものではありません。「何を自動で行い、何を人が承認するか」の線引きを明示することが、統制の出発点です。

権限分離

「調査」に必要な権限と「対処」に必要な権限を分離します。調査はログやテレメトリの読み取りで完結するため、読み取り専用の権限で十分です。対処の実行権限はSOAR側の実行基盤に限定し、エージェントは対処を「依頼」する立場に置きます。SIEM統合型SOARのドキュメントでも、プレイブックを手動実行するロール、自動化ルールからプレイブックを実行するロール、プレイブックをルールに紐づけるロールが別々に定義されています（Microsoft Learn, 2026）。この種の権限モデルを土台に、エージェントに与える権限を最小限に設計します。金融機関や防衛サプライチェーンのように規制上の要請がある業界では、この分離が委託先管理や説明責任の観点からも問われます。

監査ログ

エージェントが実行したクエリ、参照したデータ、下した判断とその根拠、提案した対処と実行された対処、人が承認・却下した記録を、改ざんできない形で保存します。SOARのケース管理と統合し、インシデント単位で「人とAIの行動」を一つの時系列で追えるようにしておくことが理想です。監査ログは事後の説明責任のためだけでなく、判断の誤りを発見し、改善につなげる一次データでもあります。

ヤグラAI SOCの位置づけ

ヤグラAI SOCは、ここまで述べた「調査・判断層」を担うAIエージェントとして設計されています。一流アナリストの調査手法を再現し、EDR・SIEMのアラートを24時間365日、AIエージェントが自律的に調査・対処します。EDR・SIEM・ID管理製品など100以上のセキュリティ製品と連携し、自社開発のサービスとしてMicrosoft Sentinelなど既存製品と連携するため、既存のSIEM・SOAR投資を活かしながら導入できます。コンテキストメモリで自社環境を学習し、運用を続けるほど調査精度が向上する点も特徴です。

効果を比較する際は、SOARによる手順の自動化で減らせた作業と、AIによる調査・一次判断の支援で減らせた作業を分けて測定します。ヤグラAI SOCも、アラート調査を支援して担当者の負担軽減を目指すサービスです。調査率、手動分析時間、再調査の工数、承認待ちの時間を自社環境で確認し、既存のSOARとの組み合わせが運用全体の改善につながるかを検証してください。

まとめ

SOARは、定型作業の自動化、ツール間の連携、対応の記録と標準化において、今後も価値を持ち続ける基盤です。その限界は、プレイブックの作成・保守コスト、想定外の事象への弱さ、判断が人に残ること、導入後の運用負荷の四点に集約され、いずれも「手順を事前に書く」というアプローチに由来します。AIエージェントによる自律調査は、手順ではなく目的を与えることで非定型のアラートにも調査を広げ、一次判断まで担う点でSOARと異なります。ただし判断には誤りが含まれ得るため、説明可能性、人間の承認、権限分離、監査ログという統制を前提に設計する必要があります。

現実的な進め方は、SOARを実行と記録の基盤として残し、AIエージェントを調査・判断層として重ねる併用モデルです。読み取り専用での並走から始め、一致率と説明の品質を確認しながら段階的に委任範囲を広げることで、既存投資を守りつつ、SOCの最大のボトルネックであった「人の判断」に手を打つことができます。

関連サービス：EDR・SIEMのアラートをAIエージェントが24時間365日自律的に調査・対処する「ヤグラAI SOC」の詳細はこちら。既存のSOAR・SIEMを実行基盤として活かしながら、調査・判断層を自律化する構成についてもご相談いただけます。