Goで作るセキュリティ分析LLMエージェント(25): 深刻度判定の自動化実現にむけて
この記事はアドベントカレンダー「Goで作るセキュリティ分析LLMエージェント」の25日目、最終日です。
最終日となる本日は実装ではなく、今後の構想について話をします。これまで24日間にわたってセキュリティアラート分析のためのLLMエージェントを構築してきましたが、まだ実現できていない重要な機能があります。それが「深刻度判定の自動化」です。
これは筆者がこれから取り組もうとしている構想であり、本アドベントカレンダーで実装したLLMエージェントをさらに高度化するとしたらどうするか、という内容になります。来年くらいには筆者自身、あるいは他の誰かが実現できているのではないかと期待しています。もし同じ課題に取り組まれた方がいたら、是非情報交換させてください。
なぜLLMエージェントは分析までなのか
これまで実装してきたLLMエージェントは、あくまで分析、あるいは分析の補助をするものとして役割を期待してきました。これは、LLMエージェントには深刻度の判断が難しく、最終的な判断は人間がやること（human-in-the-loop）というスタンスをとってきた結果です。しかし本当にそれで満足でしょうか？ 昨今のLLMの発展を鑑みるに、もっと期待してもいいのではないでしょうか。
本当にやってほしいこと
セキュリティ監視業務というなかで本当にLLMエージェントにやってほしいことの一つは、深刻度の判定をやりきることです。ここでいう 深刻度（severity） とは、実際に組織にとって被害がでる確度の高さ（影響度）、およびどのくらい急いで対応する必要があるか（緊急度）を統合したものと定義します。
これができるようになると初期トリアージを自動化できるようになります。本当に対応が必要なアラートだけに人間が介入すればよくなるため、ある程度の防御ができている環境であればアラートの9割近くは影響のないものとなり、実際に影響がある（侵害が発生している、あるいは直近で発生する可能性が高い）ものだけに人間の対応を限定できます。言い換えれば、これはオンコールの一次請けができるようになるということです。これによって人間がオンコールで24時間365日張り付く必要がなくなります。中小規模の組織（例：従業員500人程度まで）では24時間365日体制を作るのは極めて困難であり、この機能が実現できると大きな助けになります。
なお、インシデントレスポンスや問題の修正もやってほしいところですが、これはさらに難しく、またドメインも異なり筆者も詳しいとは言い切れないため今回は割愛します。
なぜ深刻度判定が難しいのか
もちろん現状でもLLMに「このアラートの深刻度はどの程度か？」と尋ねれば回答してくれます。しかしやったことがある人ならわかると思いますが、全く期待した答えにはなりません。これは組織やシステムの状況にかかわらず、一般的な回答になってしまっているためです。例えるならCVSSのようなものです。CVSSはソフトウェア脆弱性のリスクを定量化してくれますが一般化された内容であり、組織固有の文脈を反映していません。CVSSスコア8の脆弱性よりもスコア5の方が組織によっては深刻ということも当然ありえます。LLMもこれと同様に、組織内の文脈を無視して「一般的な」影響の有無を判断してしまいます。
他方、LLMのモデル自体の性能はどんどん上がっており、論理的な回答を導くというプロセスだけで考えれば、すでに十分な推論力を持っていると考えられます。例えばSWE-benchなどのソフトウェアエンジニアリングタスクのベンチマークでは、最新モデルが大幅な性能向上を示しています[1]。では何が足りないのかというと、ここからは仮説になりますが、ここまでもずっと言及してきた通り 単純にコンテキストが足りない と考えられます。分析に伴ってアラートそのものだけでなく様々なコンテキストを与える必要があります。これを適切に与えられるようになったとき、深刻度判定の精度の向上が見込めるのではないかと予想されます。
足りてない情報は何か
では、適切な深刻度判定を行うためには具体的にどのような情報が必要なのでしょうか。自分でアラートを分析し深刻度を判断するとき、何を参考にしているかを思い返すとわかりやすいでしょう。LLMは情報を揃えればある程度妥当な判定をしてくれるようになってきました。つまり、自分が深刻度判断するときに使っている知識や集めている情報がそのまま必要になる、ということです。実際に整理してみると、必要な知識がとても広範にわたることがわかります。筆者の思いつく範囲で主要なカテゴリを整理すると以下のようになります。
組織のコンテキスト
まず、そもそもセキュリティ監視によって最終的に守るべき組織についての理解が必要です。
- システムが扱うデータの機密性・重要度: 個人情報、機密情報、公開情報などデータの性質によってリスクは大きく変わります。例えば公開情報しか扱わないシステムであれば情報漏洩のリスクは低くなります。またデータの機密性だけでなく、環境の性質も重要です。検証環境などで本番データが入っていない場合は、深刻度は比較的低めに見積もることができます。もちろん検証環境も攻略の足がかりになる可能性はあるので対応しなくて良いわけではありませんが、緊急度には影響します。逆に個人の医療情報を扱う本番システムであれば、漏洩時の影響は甚大です。
- システムのビジネスインパクト: システムが停止した場合のビジネスへの深刻度も重要な判断材料です。例えばECサイトであれば停止すると直接売上に影響します。社内の勤怠管理システムであれば外部への影響はありませんが業務は滞ります。これらによって緊急度が左右されます。
- 組織のリスク許容度: 組織としてどの程度のリスクまで許容するのかという方針も重要です。扱っているサービスや業種によって法令・ガイドライン対応やレピュテーションリスクへの感度が変わります。これらによって同じアラートでも対応の優先度が変わってきます。
実装のコンテキスト
内外で利用している既成のシステムや、自社でプロダクトを提供している場合などはその実装の理解についても必要です。さらにそれを動かしているインフラや基盤についても、それらがどのような仕組みになっているか、現状どうなっているかによって影響は異なります。
プロダクト・システムの実装
検知されたアラートに関連する機能の実装詳細は重要な手がかりとなります。該当エンドポイントは何を処理しているのか、入力検証は実装されているか、使用しているライブラリやフレームワークのバージョンは何か、といった情報が必要になります。例えばSQLインジェクションの疑いがあるアラートでも、ORMを使っていてパラメータ化クエリが徹底されていれば影響は低くなります。一方で文字列連結でクエリを組み立てているような実装であれば、高リスクです。このように実装そのものを追跡できるような能力が必要です。
また細かい点でいうと、プロダクトの実装内容やシステムの認証設定も深刻度判定に影響します。不正ログインの試みを検知した場合でも、そのユーザやシステムにMFA（多要素認証）が設定されていれば影響はないと推定できます。ただし、これはどちらにしてもログを確認すべきではあります。逆にパスワードのみで認証していた場合、侵害を受けた可能性を判断する必要があります。
既知の脆弱性や技術的負債の有無も確認する必要があります。脆弱なライブラリのバージョンを使っていないか、過去のペネトレーションテストで指摘された未修正の問題はないか、といった情報です。これらがある場合、攻撃者が悪用できる既知の手法が存在する可能性が高くなります。
インフラや基盤の設計や実装
インフラや基盤の認可設定（権限設定）も確認が必要です。利用しているユーザ、サービスアカウントやロール、そしてその権限範囲などを把握する必要があります。強い権限を持つ主体が侵害された場合、影響は大きくなります。また重要なデータを扱う主体も同様です。逆に権限がちゃんと切られていてかつ重要なデータを扱っていなければ緊急度は低くなります。
インフラとしてのデータ配置や公開などの方針も重要です。インフラの設定としてデータ露出に関する方針がどうなっているのかを把握する必要があります。例えばオブジェクトストレージの公開範囲が任意のユーザになっていても、Webサイトの公開リソースであれば全く問題ありません。逆に意図せずそのような設定になっていて情報漏洩を起こしている可能性もあります。これは担当者に問い合わせるという方法もありますが、組織内になんらかのルールがあれば、それに則っているかどうかで影響を判定できます。
ネットワークセグメンテーションや境界防御の設定も見る必要があります。ネットワークが適切に分離しているか、疎通は必要最低限に設定されているか、といった情報です。これによって攻撃を受けたシステムから他のシステムへの横展開がどの程度可能かが変わります。例えば完全に隔離された環境であれば、そのシステムだけの問題で済む可能性が高くなります。一方でフラットなネットワーク構成であれば、一箇所の侵害が全体に波及するリスクがあります。
業務のコンテキスト
アラートに関連したユーザやシステムがどのような業務をしているかの理解も必要です。どのようなシステムと繋がって何をするためのシステムなのか、どのような業務をしている人でどのようなデータを扱う人なのか、といった情報を把握することで、適切な行動が推定され、アラートとして検知された内容が意図的なのかどうかの判断ができます。
当該システムに対する最近の変更履歴も重要な情報源です。直近のデプロイや設定変更はあったかを確認します。新しい機能をリリースした直後であれば、その機能に起因するアラートである可能性が高くなります。ただし設定変更によって意図せず脆弱な状態になっている可能性もあり、そこも含めて深刻度を判定する必要があります。変更履歴を把握していれば、少なくともアラートの原因を特定しやすくなります。
現在進行中のプロジェクトや業務イベントも考慮すべき情報です。新機能リリース直後ではないか、大規模キャンペーン実施中ではないか、といったタイミング情報です。これらのイベント時には通常と異なるトラフィックパターンが発生するため、このようなタイミング情報を加味することで、アラートの優先度を適切に判断できます。
脅威のコンテキスト
攻撃者の活動状況も判断材料になります。ドメインによっては同業他社への類似攻撃の発生状況が参考になります。例えば金融業界で特定のマルウェアキャンペーンが活発化しているという情報があれば、同様のアラートの優先度は上がります。
また最近活発な攻撃手法や領域に関する情報も、アラートの深刻度判定に影響します。脅威インテリジェンスフィードやセキュリティベンダのレポートから得られる情報を、組織の状況と照らし合わせることで、より精度の高い判定が可能になります。
解決のためのアイディア
ここまでで述べた通り、使うべき情報は多岐にわたり一筋縄ではいきません。これまで解説してきた通り、少なくとも現状ではLLMエージェントの適切な運用ではコンテキストウィンドウを適切に利用できるかが、結果を大きく左右します。これらのデータを無闇に全部渡せばいいというわけではないのが重要なポイントです。
この問題を解くのはとても難しいですが、いくつかのアプローチを組み合わせることで、この問題に対処できる可能性があります。以下では筆者が考えている解決策のアイディアをいくつか紹介します。
組織内情報の検索性向上
まず基本となるのは、組織に関連した情報をまとめ、エージェントが真の意味で検索可能な状態にすることです。ドキュメント、設計書、運用手順書、さらには事業関連の状況、セキュリティポリシー、組織図、業務分掌などの情報を検索可能な形で整備する必要があります。そもそもまずそれらの整備が必要であり、そのうえでシステムの機密性、ビジネスインパクト、リスク許容度なども含めて分かるように情報をまとめて検索可能にします。多くの組織では、こうした情報が散在していたり、属人化していたりするため、まずは情報の集約と構造化が第一歩になります。
ただし、おそらくただのRAGではうまくいきません。探すべき情報の範囲が横断的であり、エージェントが直接的に欲しい情報へたどり着くのは困難です。真の意味での「検索可能」は本当にエージェントがその情報にたどり着けてこそです。たどり着けないなら理論上は検索可能でも意味はありません。
そもそも何を探せるのか、ということからエージェントが知る必要があります。人間のアナリストであれば、経験から「こういう情報があるはず」という見当をつけて探索できますが、エージェントにはその経験がありません。これは「知らないものは探さない」問題と呼べるでしょう。
より効率的に知識・情報を検索するためには、より先進的なRAGのような仕組みが必要になります。例えばGraphRAGのような技術が候補になります。GraphRAGは知識をグラフ構造（ノードとエッジ）で表現し、関連情報をノード間のパスを辿って芋づる式に検索する技術です。単純なベクトル検索では見つけにくい間接的な関連情報も取得できるようになります。ただしセキュリティ分析という文脈・ドメイン特有の問題もあると考えられ、実地でいろいろと試していくしかありません。
また、検索されたドキュメントやポリシーなどをそのままエージェントに渡すと、単にコンテキスト消費が多くなるだけになってしまいます。重要なのは検索から得られた情報を、うまく咀嚼して今の状況にあわせて解釈し、適切な形でメインエージェントへ返すことです。ここでもサブエージェントが活躍します。検索を担当するエージェントが、単に文書を返すのではなく、「このアラートの文脈において重要な情報はこれ」という形で要約して返すイメージです。
開発・インフラ関連データへのアクセス機能の提供
次に重要なのは、開発・インフラ関連のデータへのアクセス機能を提供することです。静的なドキュメントだけでなく、実際のシステムの状態を動的に取得できることが、正確な深刻度判定には不可欠です。そのためにいろいろな権限を付けたりツールを用意して、エージェントがアクセスできる状態を作ります。
- ソースコードリポジトリへの読み取りアクセス: アラート関連のエンドポイントやロジックの実装を直接確認できるようにします。入力検証、認証実装、使用ライブラリのバージョンなどを自動抽出する仕組みが必要です。ただし、これについては単純にアクセスできれば良いというわけではなく、コードを追跡するようなエージェントとしての振る舞いが必要です。例えば「このエンドポイントはどのように入力を検証しているか」を調べるには、ルーティング定義からハンドラを特定し、そこから呼び出されている検証関数を追跡するといった複数ステップの分析が必要になります。こうしたコード理解に特化したAIエージェント（CursorやClaude Codeなど）の方が得意な領域です。またコストも掛かるので、クリティカルそうなアラートだけに絞るといった工夫も必要になりそうです。
- IaCおよび実際のインフラ情報の読み取り: 権限設定、ネットワーク構成、公開範囲などをTerraformやCloudFormationといったIaC（Infrastructure as Code）から読み取ります。さらに実際のインフラにアクセスして情報を読み取る機能も必要です。例えばGoogle CloudのCloud Asset InventoryやAWSのAWS Config、Azure Resource Graphなどのサービスから現在の構成情報を取得します。BigQueryに外出しして検索するような方法もありますが、生の情報が必要になる場面も多いでしょう。
- CI/CDパイプラインやデプロイ履歴へのアクセス: 最近のデプロイタイミングとアラート発生時刻を突き合わせることで、デプロイ内容から新機能起因かどうかを判断できます。また、どのソースコードがどこにどういう形でデプロイされたかを追跡できることも重要です。意外とソースコードのリポジトリと実稼働プロダクトが綺麗に繋がらない場合もあります。これを人間がちまちま調べるのではなく、エージェントにやらせたいところです。
関係者との対話の代行
すべての情報がシステムから取得できるわけではありません。特に「このシステムの意図された挙動は何か」といった設計意図や、「この設定は一時的なものか恒久的なものか」といった運用上の判断は、担当者に聞かなければわからないこともあります。そこで、関係者に「聞く・問い合わせる」ということ自体をエージェントに代行させるアプローチも考えられます。
システムオーナーやSREへの自動問い合わせを実装します。不明な設定や意図が不明なアラートについて、チャットシステム（SlackやTeams）で質問を代行させます。そこまで高度な会話を求めなくても、「Yes」「No」で答えられるようにして、ボタンで回答させる形式で良いはずです。人間の回答を受け取った後に深刻度判定を継続します。あるいは「このアラートについて詳しい人は誰ですか」と聞いて、適切な担当者を指名してもらうといった仕組みも考えられます。
このアプローチの利点は、人間の知識を活用しつつ、エージェントが24時間365日稼働できることです。夜間や休日に発生したアラートでも、翌営業日に担当者が出社したタイミングで質問への回答を得て、判定を完了できます。
マルチエージェント化
ここまでいくつか方法を挙げてきましたが、これらのアプローチは1つ1つの処理がとても複雑です。そうするとコンテキスト限界だけでなく、余計な処理によるコンテキスト汚染（不要な情報によるコンテキストの消費や、失敗情報の混入など）もかなり気にする必要がでてきます。こういった側面を考えると、やはりマルチエージェント化が必要になります。
前述の3つのアプローチ（検索性向上、データアクセス、対話代行）はそれぞれ独立した処理として実装できますが、これらを統合的に扱い、最適なタイミングで呼び出すには、マルチエージェント的なアーキテクチャが効果的です。以下では、マルチエージェント化における重要な考え方を2つ紹介します。
タスクの専門家を作る
マルチエージェントは「セキュリティアナリスト」「インシデントレスポンス」といった専門性をエージェントごとに分離すると思われがちですが、個人的にはそれはちょっと違っていて、本質は「タスクの専門家」を作ることだと考えています。例えばここまでの例で言うと「資料検索の専門家」「ポリシー解釈の専門家」「ソースコード分析の専門家」「ログ検索の専門家」といった具合です。これは人間の単位でみる専門性とは違います。例えばAIコーディングエージェントは「ソースコードを調べたり記述する専門家」とカテゴリすることができると思います。
このような各エージェントが、それぞれに特化したツールセットを持つことでタスクを効率化できる、というのがマルチエージェントの本懐だと考えます。例えばコード分析エージェントはGitHub API、インフラエージェントはクラウドAPIといった具合です。利用できるツールが多すぎると混乱するという問題もあるので、ツールの分散はその防止策でもあります。またプロンプトなども特定の領域に絞ってチューニングすることで、よりタスクの精度を高められることが期待されます。
エージェント間の制御
マルチエージェントについては並列性も利点として挙げられますが、これも個人的にはあまり本質ではないと考えています。直列でも正しく問題を解決できればものすごく価値があります。依存関係を事前に正確に把握することは困難であり、計画通りに並列実行しようとすると逆に複雑性が増す可能性があります。「早すぎる最適化は悪手」という格言もあります。
どちらかというとマルチエージェント全体では、複数のエージェントを「戦わせる」という制御をするのが本質かもしれません。多くの場合マルチエージェントでは、主たるエージェントがサブエージェントを使いこなすものとイメージされがちですが、並列する2つのエージェントを用意して意見を戦わせるという手法も考えられます。異なる前提や異なるモデル、プロンプトを与えることによって違う視点を持たせられます。人間の役割分担と同じく、例えばセキュリティ担当としての深刻度と事業担当者としての深刻度というのは異なってきます。そのため異なる役割を与えた時の結論は違うはずで、それを綱引きさせるというのは重要な判断においてはありえると考えています。もちろんコストや時間はかかります。
複数のエージェントでそれを判断するような仕組みが作れると、これは3つの役割から考察をして結論を導く、某スーパーコンピューターみたいになりそうです。実際に複数エージェントを戦わせる手法（ensembleやdebateなど）は研究が進められていますが、まだ実用段階ではないとのことです。逆に精度が下がる可能性もあるらしいですが、チャレンジしてみるだけの価値と夢はあるのではと考えています。
某スーパーコンピューターのストーリーは筆者がセキュリティに興味を持つきっかけでもあったので、少なからず感慨があります
まとめ
LLMを含む生成AIの発展は著しく、1年前の2024年12月と2025年12月ですら大きな変化がありました。未来のことを予想するのは難しいですが、引き続き生成AI関連への投資は続いていくとみられ、2026年にはまた違った景色が見えているのではないかと思います。
ここまでの解説でも何度か触れましたが、LLMをはじめとする生成AIはこれまでのソフトウェア開発のパラダイムを大きく変化させたと実感しています。これまででも機械学習などを駆使すれば実現できたこともありますが、その実現のためのハードルが大きく下がり様々なアイディアを試したり、実装できるようになりました。セキュリティの分野でも、監視に限らずまだまだ新しい活用方法や応用できることがたくさんあるのではないかと考えています。
生成AIは純粋にモデルの発展だけでなく、周辺のツールやエコシステムについても目覚ましい勢いで変化しています。実際、このアドベントカレンダーを書き始めた10月初頭にはなかったGo向けのAgent Development Kitが11月にリリースされてちょっと焦るということもありました。実際、GoでLLMエージェントをまず試すならADKを使ったほうが確実にお手軽なのですが、仕組みの理解に役立てばという観点と、セキュリティ分析という特定のユースケースについて紹介する意義はあると考えて執筆を続けてました。
このアドベントカレンダーで扱った内容ももしかすると来年にはもう時代遅れになっているかもしれませんが、読んでいただいた方の何かの参考になれば幸甚です。最後までお付き合いいただき、ありがとうございました。
Discussion