Goで作るセキュリティ分析LLMエージェント(2): セキュリティアラートの分析業務における課題とLLMによる改善の可能性
この記事はアドベントカレンダー「Goで作るセキュリティ分析LLMエージェント」の2日目です。
本日はLLMエージェントを作っていくにあたり、まずセキュリティアラートの分析に関する課題の整理と、それを生成AIでどのように解決していけるかというアプローチについて議論していきます。
セキュリティアラート分析における課題
昨日紹介したように、本アドベントカレンダーでは「セキュリティアラート」を監視装置からの発報だけでなく、脆弱性情報やサプライチェーン攻撃など、組織のセキュリティに影響するリスク情報全般として扱います。これらはあくまで「セキュリティ侵害の可能性がある」という通知に過ぎず、実際の影響を判断するには担当者による分析が必要です。
このような課題はSOC（Security Operation Center）のような専門組織だけでなく、セキュリティに責任を持つほとんどのチームが抱えている問題です。今回、生成AIを活用してアラート分析を省力化することを目指します。
"Alert Fatigue"
セキュリティ関連のアラートは絶え間なく発生します。十分なセンサーの構築をしている、あるいは情報源のウォッチをしていれば、小さな組織でも一週間に数回は発生します。中規模以上の組織だと日に数回、数十回もめずらしくありません。
1つのアラートの処理はそこまで重くなくとも、数が多くなることで業務に支障がでてきます。このような現象は「アラート疲労」（Alert Fatigue）と呼ばれています。その結果、現場が疲弊してアラートの処理が滞ったり、対応が無視されるようになります。Palo Alto Networksの調査[1]によると、SOCアナリストは生成されたアラートの14%しか処理できておらず、Ciscoの2017年の調査では、セキュリティチームが日々受け取るアラートの44%が調査されずに放置されている[2]とされています。
SOCという専門家集団ですらそのような問題を抱えているため、小・中規模な組織のセキュリティチームではさらにそれが顕著に現れます。先述した通りセキュリティアラートは様々な情報を収集して統合的に判断するという作業が必要であり、認知能力を消費します。また実際に被害をおよぼす危険なアラートが少ないと逆に誤検知やノイズがほとんどを占めており、分析を劣後させてもよい・あるいは無視してもよいという風潮になりがちです。結果として真に重要・危険なアラートを見逃してしまう可能性があり、せっかくのセキュリティ監視や危機察知が機能しないという結果になってしまいます。
分析には専門的知識が必要
もう一つの別側面の課題としては、セキュリティアラートの分析にはある程度の専門知識が必要になるという点です。これはセキュリティの専門家からすると当然と思われるかも知れませんが、一般的な中小企業や組織においてセキュリティの実務をしているのは社内IT担当やインフラ担当の方が兼務していて、もともとセキュリティを専門としていないケースも多々あります。
筆者の知る範囲だとセキュリティに従事できるメンバーは全体のおよそ0.5%〜1%程度の人数というケースが多いです。200人規模の組織で1, 2人いるかいないかという規模感になります。また情報セキュリティといっても範囲が広く、こうしたテクニカルなセキュリティ分析を得意とした人ばかりではありません。
そのためそのようなアラートを受けたとしても、分析に必要な知識が不足しているケースがあります。例えば、一般的にどのような攻撃手法が存在するか（SQLインジェクション、クロスサイトスクリプティング、ランサムウェアなど）、攻撃者がシステム侵入後にどのような行動をとる可能性が高いか（権限昇格、横展開、データ窃取など）、攻撃の段階としてどのような手順があるか（偵察、侵入、拡散、目的達成）といった基本的な知識が必要です。さらに、より深い分析のためには脅威インテリジェンスやCVE情報などの外部情報源の活用や、組織固有の環境やシステムに関する理解も重要になりますが、そこまでたどりつくのが難しいことも多いでしょう。
そのため、そもそも分析対応できる能力がないという根本的な問題もあります。
自動対応ワークフロー（SOAR）における課題
こうした問題を解決するアプローチとして、2018年頃から登場したSOAR（Security Orchestration, Automation and Response）が大きな期待を集めていました。SOARの基本的なアイディアは、セキュリティ専門家が持つ知識や判断基準を事前に定義されたワークフロー（プレイブック）として実装することで、アラート対応の自動化を実現するというものです。例えば「あるサービスへの攻撃を検知したら、まず脅威インテリジェンスAPIで評判を確認し、悪性と判定されたらファイアウォールでブロックする」といった一連の処理を自動実行できます。これにより、専門家の知識や判断力をシステムに移譲し、人手による対応の負荷を大幅に軽減できると考えられていました。
実際、SOARは一定の成果を上げた領域もあります。定型的で繰り返しの多いタスク、例えば特定のツールからの情報収集やチケットシステムへの記録といった作業は効率化できました。しかし何年か運用された結果、いくつかの本質的な課題が明らかになってきました。2024年のGartner Security Operations Hype Cycleでは、SOARを「幻滅期」（Trough of Disillusionment）に位置づけ、プラトー期を迎える前に時代遅れになるとまで指摘しています[3]。プレイブック管理の複雑さ、継続的なメンテナンスに必要な開発リソース、そして期待されたROIの悪化が問題視され、一部では"SOAR is dead"とまで言われるようになりました。
厳密なワークフロー定義とメンテナンスコスト
SOARの最も大きな課題は、ワークフローを厳密に定義する必要があることです。「この条件のときはこの処理を実行する」という決定性のあるロジックを記述する必要があり、これは本質的にプログラミングと同等の作業になります。プレイブックの作成には条件分岐、ループ、エラーハンドリングなど、通常のソフトウェア開発と同様の設計と実装スキルが求められます。
この方式は、扱うアラートの種類が限定的で、対応パターンが明確な場合にはうまく機能します。例えば特定のEDRからのアラートに対する初動対応といった、ある程度定型化できるケースです。しかし実際のセキュリティ運用では、アラートの種類は多岐にわたります。EDR、ファイアウォール、WAF、侵入検知システム、脆弱性スキャナー、クラウドセキュリティツールなど、それぞれ異なるフォーマットと文脈を持つアラートが発生します。さらに同じツールでも検知ルールごとに異なるアラートタイプがあり、全体では数十〜数百種類となる場合も少なくありません。加えて、ブログやSNSでの脆弱性情報の公開、セキュリティ研究者による新しい攻撃手法の報告といった、構造化されていない非定形の情報も重要なインプットとなります。
こうした多様なアラートや情報源に対応するには、それぞれ専用のプレイブックを作成・メンテナンスする必要があります。しかしこれは結果として、環境変化に追従するための開発リソースが継続的に必要となり、多くの組織ではワークフロー定義とメンテナンスの工数が当初期待されたROIを上回るという事態に陥りました。これは単純な作業負荷の問題だけでなく、アラート分析をするSOCアナリストのような人物にソフトウェアエンジニアリングのスキルを求める必要があり、人材確保が難しいという側面もありました。これらのことから、自動化による効率化を目指して導入したはずのSOARがかえって運用負荷を増やしてしまうという問題がありました。
分析という業務の複雑さ
SOARのもう一つの本質的な限界は、セキュリティ分析という業務そのものが持つ複雑さに起因します。分析作業は単純な情報収集では完結しません。ある調査を進める中で、「どこまで深掘りすべきか」「次にどの情報源を当たるべきか」といった判断が常に求められます。例えば、不審なIPアドレスからのアクセスを調査する際、脅威インテリジェンスで悪性と判明した場合は追加のログ調査が必要ですが、そのIPが社内の正規システムからのアクセスだと分かれば、それ以上の深掘りは不要かもしれません。こうした判断は状況に応じて動的に変化するため、定型的な作業として落とし込みにくいのです。
ワークフローは基本的に事前に定義された手順を順次実行するものであり、決まったことしか実行できません。しかし実際の分析では、調査の過程で新たに発見した情報に基づいて、追加の調査方針を決定することが頻繁に起こります。事前に定義した固定的なワークフローでは柔軟性がなく、こうした動的な判断に対処することが困難です。さらに、アラートごとに必要な調査手順や深さは大きく異なります。単純な誤検知であれば数分で判断できる一方、複雑な攻撃の可能性がある場合は調査範囲を数日から数週間に広げる必要があります。このように状況に応じた対応が必要になります。
この問題の核心は、人間の分析者が持つ「次に何を調べるべきか」という判断力の自動化が極めて困難だということです。熟練したアナリストは、収集した情報を総合的に評価し、経験と直感を組み合わせて次の行動を決定します。そこまで高度な分析でなくても、人間が最終判断に必要な情報は人間が納得できるまで収集する必要があり、柔軟な対応が求められます。
LLMによる課題解決
これらの課題の解決の糸口が生成AIの利用です。筆者は2024年後半頃から、アラート分析を含むセキュリティ監視の分野で生成AIを活用できないかを検討してきました。最初はワークフローの一部に生成AIを導入したり、ルールのチューニングのプロセスに導入するなどを模索していましたが、2025年に入ってからツールを呼び出すためのFunction Calling機能の充実、MCP（Model Context Protocol）などの外部連携技術の普及なども相まって、エージェント型の生成AIプログラムを利用するのが適切なのではという確信を持ちました。
生成AIで解決しうる課題
本アドベントカレンダーを執筆時点で、LLMによるアラート分析で解決の可能性が高い課題について紹介します。
柔軟なデータ収集
SOARでは事前に定義したツールしか呼び出せませんでしたが、LLMは状況に応じて必要なツールを動的に選択できます。自然言語での指示により、必要な情報を動的に収集できます。具体的には、Function Callingという仕組みを活用して、脅威インテリジェンスAPIやログデータベースなど複数のツールを適切に選択し、実行することができます。
さらに重要なのは、収集した情報を評価して次に必要な調査を判断し、追加のデータ収集を自律的に実施できる点です。例えば、あるIPアドレスの評判を調べて影響が疑わしいと判断した場合には、関連するログをさらに深掘りさせることができます。逆に、ある情報源で情報が見つからなければ、別の情報源を探しに行かせるといった動作も可能です。これはSOARのような決定的なワークフローでは実現が難しかった、状況に応じた柔軟な情報収集そのものです。
大量データの要約や解説
SOARでは構造化されていないデータの解釈が困難でしたが、LLMはテキストデータの意味を理解し要約できます。数百から数千程度のログやアラートであれば、その中から関連性の高い情報を抽出し、人間が理解しやすい形で要約を生成できます。また、専門的な攻撃手法やCVE情報についても、分かりやすい言葉で解説することが可能です。
特に近年のLLMには、MITRE ATT&CKフレームワークのような一般的なセキュリティ知識が組み込まれています。このため、専門知識を持たない担当者にも分かりやすく説明したり、逆にざっくりとした指示を受け取ってそれを適切な処理へと解釈したりすることができます。複数のデータソースからの情報を統合し、全体像を把握しやすい形で提示することも得意です。
もちろんLLMは完璧ではなく、時には誤った情報を生成することもあります。しかし、人間の運用コストを削減したり、専門家がいない状況でのサポートツールとしては十分に強力です。またトークン制限という制約はありますが、データ圧縮や階層的要約といった技法を用いることで、コンテキストに収まる形で情報を整理することも可能です。
自然言語での指示
SOARではプログラミングスキルが必要でしたが、LLMは自然言語で指示できます。プログラミングの知識がなくても分析方針を伝えられます。組織固有の判断基準やポリシーを自然言語で記述し、それに基づいた判断をさせることも可能です。例えば「開発環境からのアラートで、営業時間内に発生したものは優先度を下げる」といった条件を記述したり、アラートの事前分類をさせたりすることもできます。
さらに、人間の分析者とのインタラクティブな対話により、段階的に分析を深めていくことができます。最初に全体像を把握し、その中で気になるところだけを深掘りしていくといった柔軟な調査も可能です。LLMから事前定義ワークフローを呼び出すことで、決定的な処理が必要な部分とLLMの柔軟性を組み合わせることもできます。これによって人間に伴走しサポートするエージェントとして機能してくれます。
コンテキストエンジニアリングによる状況の理解
生成AIの弱点として、組織固有のコンテキストが分からず一般的な回答しかできないという問題がよく指摘されてきました。しかし実際には、コンテキストをsystem promptやFunction Callingなどを通じて適切に与えることで、組織の状況に応じた回答ができることが分かっています。このようなLLMに適切な文脈情報を与える技術を、コンテキストエンジニアリングと呼びます。
もちろん、コンテキストエンジニアリング自体はまだ完全ではありません。すべてのコンテキストを明示的に与えるのは難しく、また人間自身が自覚していない暗黙知のようなコンテキストも存在します。さらに言えば、組織内の人間関係や政治的な配慮といったより上位のコンテキストは、そもそもシステムに与えること自体が困難です。それでも、システム構成、過去の対応履歴、組織のセキュリティポリシーといった明示化できる情報を適切に提供することで、一定程度は組織の状況に合わせた行動や回答ができるようになっています。
現在のLLMでは解決が難しい課題
一方、本アドベントカレンダー執筆時点では技術的、運用的に難しい観点もあります。これらは今回のアドベントカレンダーでは解決の対象とはしません。完全な解決は目指さず、現実的な範囲での活用を考えます。
大規模データの分析
LLMには「コンテキストウィンドウ」と呼ばれる、一度に処理できるデータ量の上限があります。近年は急速に拡大しており、比較的大きなGemini 2.5でも2025年10月現在で1Mトークンまで対応していますが、それでも大規模データを処理するには十分ではありません。
また、生成AIはそもそも大量のデータをそのまま投入してデータ分析させるようなタスクを苦手としています。例えば異常検知やクラスタリングといった統計的な処理は、一般的にLLMの苦手分野とされています。LLMは「このデータは異常か」という判断はできても、「数万件のログの中から異常なパターンを発見する」といったタスクは、筆者の経験上もうまく機能しませんでした。
そのため、大規模データに対しては、データをそのまま投入するのではなく、検索や変換といった機能を外部ツールとして提供し、LLMにはそれらを活用させるアプローチが効果的です。あるいは、異常検知やクラスタリングのような特殊な処理は、LLMへの問い合わせの外で専用のツールやアルゴリズムで処理し、その結果だけをLLMに渡すほうが効率的です。
最終的な影響度の決定
ビジネス上の影響度は組織固有の文脈や優先順位に強く依存します。LLMは組織の戦略やリスク許容度を完全には理解できません。また、LLM自体が誤った情報を生成する可能性（いわゆるハルシネーション）も考慮すると、最終的な判断は人間が行うべきです。
LLMの役割は、判断材料の整理と推奨事項の提示に留めるべきです。「このアラートは優先度が高い可能性があります。なぜなら〇〇だからです」という情報を提示し、最終的な対応方針の決定は人間が行う、という人間主体の設計が重要です。LLMはあくまで人間の判断を支援するツールであり、人間に代わって意思決定をするものではありません。
まとめ
セキュリティアラート分析における最大の課題は、アラートの量と分析の複雑さです。この問題に対し、SOARのような事前定義されたワークフローは、メンテナンスコストが高く、柔軟性に欠けるため限界がありました。
LLMエージェントがゲームチェンジャーとなりうるのは、まさにSOARの弱点である「状況に応じた動的な判断」が可能だからです。Function Callingによる柔軟なツール活用、自然言語での指示、コンテキストに応じた行動により、人間の分析者の思考プロセスに近い動作を実現できます。また一般的な知識と組織独自のコンテキストを組み合わせることで、人間をサポートするエージェントとして機能することが期待されます。
明日は、この考え方を具体化したシステムアーキテクチャと設計方針について解説します。
Discussion