🔧

Goで作るセキュリティ分析LLMエージェント(15): セキュリティ分析のためのツール・サブエージェント

に公開
AI
Go
Security
Agent
tech

この記事はアドベントカレンダー「Goで作るセキュリティ分析LLMエージェント」の15日目です。本日はAIエージェントの実装から少し離れ、セキュリティ分析エージェントが利用すると便利なツール、またはサブエージェントとしてどのようなものがあるかについて説明します。

これまでの記事では、AIエージェントの実装を進める過程で必要に応じてツールやサブエージェントを追加してきました。本日はこれまでと視点を変え、セキュリティ分析エージェントにどのようなツールやサブエージェントが役立つのか、またそれらを実装する際のポイントについて整理します。ここで紹介する内容はあくまで筆者の実運用経験に基づくものであり、これが全てではありません。むしろ、より良いツールのアイディアをお持ちの方がいらっしゃいましたら、ぜひ筆者に教えていただければと思います。

セキュリティ分析で活用できるツール・サブエージェントの種類

ここでは基本的にツールとサブエージェントの区別なしに解説していきます。ただし、どちらの実装形態がより適しているかが明確な場合は、その理由とあわせて言及します。

以下は本記事で紹介する7つのツール・サブエージェントの概要です。

ツール種別 主な用途 主な注意点
(1) IoC検索 脅威情報の取得 APIレート制限、フィードの更新管理
(2) ログ検索 過去の事象追跡 コンテキスト消費、スキーマ情報管理
(3) インフラ状態取得 現在の設定確認 リアルタイム性とコストのトレードオフ
(4) リポジトリ情報 コード変更履歴 APIレート制限、スキャン結果の鮮度
(5) 社内ドキュメント ポリシー・手順参照 存在の明示、検索性能の依存
(6) コミュニケーション記録 意図・背景の確認 機密情報配慮、検索範囲の設定
(7) Web検索 外部最新情報 セキュリティリスク、情報漏洩

(1) IoC検索

脅威情報データベースから、アラートに出現したIoC（Indicator of Compromise：侵害指標）の情報を検索するツールです。アラートに含まれるIPアドレス、ドメイン、ファイルハッシュなどの各種指標を脅威情報データベースと突き合わせることで、それが既知の脅威と関連しているのか、どの程度の危険性があるのかといった見立てを立てやすくなります。具体的には、あるIPアドレスへの通信を検出したアラートがあったとき、そのIPアドレスが過去にマルウェアのC&Cサーバーとして使われていたという情報があれば、単なる通信異常ではなく重大なインシデントの可能性が高いと判断できます。

ただし、IoC情報が存在するからといって必ずしもインシデントとは限らない点には注意が必要です。脅威情報データベースには誤検知や古い情報も含まれているため、IoC検索結果はあくまで判断材料の一つとして扱い、他のコンテキスト情報と組み合わせて総合的に評価する必要があります。このような文脈情報を自動的に取得できることが、IoC検索ツールの価値です。

実装方法

IoC検索の実装方法は大きく分けて2つのアプローチがあります。

API経由での取得

1つ目は外部サービスからAPIを通じてそのまま取得する場合です。これは9日目で実装したAlienVault OTXのツールとほぼ同じ形式で、APIキーを使ってHTTPリクエストを送信し、JSON形式のレスポンスを解析するという流れで実装できるため、特に複雑な実装を必要としません。主要な脅威情報プロバイダーの多くはAPI経由でのアクセスを提供しており、具体的にはVirusTotalやAbuseIPDB、URLScan.ioなどが代表例です。

これらのサービスは、指標を送信するとJSON形式で詳細な脅威情報を返してくれるため、単純なAPIラッパーとしてツールを実装するだけで対応できます。このアプローチの利点は、常に最新の脅威情報にアクセスできることと、自前でデータベースを管理する必要がないことです。ただし、API呼び出しにレート制限があったり、有料プランでないと十分な情報が得られないといった制約もあります。

フィード型データの内部データベース化

もう1つのアプローチは、脅威情報がフィードやリストの形式でのみ提供されている場合です。一部の脅威情報は、CSVファイルやJSONファイルとして定期的に公開されるだけで、API経由でのリアルタイム検索ができないケースがあります。このような場合は内部にデータベースを構築して検索可能な状態にする必要があります。

実装時には定期的にフィードをダウンロードして既存データを全件削除してから再投入したり、差分更新の仕組みがあれば新規のデータのみを追加するといった管理ロジックを実装しなければなりません。また、古くなった情報を削除する仕組みも必要です。クラウド環境で実装する場合は、DynamoDBのようなkey-value型のNoSQLデータベースを利用するのが比較的おすすめです。

AWS DynamoDBであれば、1日100万件の読み込みでも月あたり約4ドル程度で運用できるため、コスト面でも現実的な選択肢となります。IoC検索は基本的にキー（IPアドレスやハッシュ値）での単純な検索が中心なので、複雑なクエリ機能は不要であり、key-value型のシンプルな構造で十分です。

(2) ログデータ検索

アラートに登場した対象のユーザやリソースについて、どのような事象が起こったのかを調べるためのツールです。ログデータの取得や管理に関する詳細は、筆者が以前執筆した実践セキュリティ監視基盤構築にも記載されていますので、興味のある方は参照してください。

検索対象となるログの種類

セキュリティ分析で検索対象となるログは、主に以下の4つのカテゴリに分類されます。

インフラログ: クラウドプラットフォームやネットワーク機器から出力されるログです。以下のような種類があります。

  • クラウド監査ログ（AWS CloudTrail、Google Cloud Audit Logs）
  • ネットワークフローログ（VPC Flow Logs、Cloud NAT Logs）
  • DNSログ（Route 53クエリログ、Cloud DNS Logs）
  • ネットワーク機器ログ（ファイアウォール、ロードバランサー、プロキシサーバー）

これらは不審な通信先への接続や想定外のリソース操作を検出する際に重要な情報源となります。

プロダクトログ: 外部に提供しているプロダクトやサービスから出力されるログです。セキュリティ分析では以下が特に重要です。

  • 監査ログ（ユーザーによる重要な操作の記録）
  • 認証ログ（ログイン試行、認証成功・失敗、セッション管理）
  • アクセスログ（APIやWebサービスへのリクエスト履歴）

アプリケーションログ全般も監視要件によっては必要になりますが、「誰が」「いつ」「何をしたか」を追跡できるログが優先されます。

端末ログ: 従業員が利用する端末から収集されるログです。近年のセキュリティインシデントでは端末が侵入経路となるケースが多いため重要性が高まっています。

  • EDRログ（プロセス実行、ファイル操作、ネットワーク通信などの詳細な振る舞い情報）
  • システムモニタリングログ（OS標準のイベントログやsyslog）
  • MDMログ（端末の設定変更やポリシー違反）

特にEDRログは、マルウェア感染や不審なプロセス実行を調査する際に不可欠な情報を提供します。

社内システムのログ: 業務で利用する社内システムやSaaSから出力されるログです。オンプレミス、クラウド、SaaSを問わず、以下のような管理が必要です。

  • 各システムから監査ログを収集し統合ログ基盤へ転送
  • BigQueryやAthenaなどのデータウェアハウスに集約して検索性を向上
  • セキュリティ要件やコンプライアンス要件に応じた適切な保存期間の設定

典型例としては、Google WorkspaceやMicrosoft 365の監査ログ、GitHubやSlackなどの開発・コミュニケーションツールのログ、社内認証基盤のログなどが挙げられます。これらを統合管理することで、組織全体での不審な活動を横断的に追跡できるようになります。

ログ検索ツールの活用方法

これらのログを検索することで、アラート対象のユーザやリソースに関する詳細な情報を引き出すことができます。具体的には以下のような調査が可能です。

  • ユーザの行動追跡: あるユーザアカウントに関するアラートが発生した場合、そのユーザが前後の時間帯にどのような操作をしていたかを追跡できます（例: 深夜ログイン後のファイルダウンロードや外部サービスへのアクセス）
  • リソースへのアクセス履歴: 特定のリソースに誰がアクセスしたのか、どのタイミングでアクセスがあったのかを調べられます（例: S3バケットの権限変更後のアクセス状況）
  • リソースの不審な振る舞い検出: EC2インスタンスやコンテナが通常と異なる動作をしていないか調査できます（例: Webサーバーからの不審なIPアドレスへの通信）
  • 変更履歴の追跡: リソースの設定変更の時系列を追跡できます（例: セキュリティグループやIAMロールの変更履歴）

このような関連情報を引き抜いてくる作業は、LLMエージェントが得意とする領域です。人間がログを検索する場合、どのフィールドをどう組み合わせて検索すべきか、どういう条件で絞り込むべきかといった試行錯誤が必要ですが、エージェントであればアラートの内容から自動的に関連しそうな検索条件を推測し、複数の検索を並行して実行し、関連性のある情報を効率的に収集できます。また、最初の検索結果から新たな手がかりを見つけて、さらに深掘りした検索を自律的に行うこともできます。

実装時の注意点

ログ検索ツールを実装する際には、いくつか注意すべきポイントがあります。

サブエージェント化の推奨と検索ヒントの重要性

以前のサブエージェント実装の記事で解説した通り、ログ検索ツールはコンテキストウィンドウを大量に消費しやすい特性があるため、サブエージェントとして実装するのがおすすめです。メインエージェントで直接ログ検索を行うと、大量のログデータが会話履歴に蓄積され、あっという間にコンテキストウィンドウの上限に達してしまいます。サブエージェントとして分離することで、ログ検索の結果を要約してからメインエージェントに返すことができます。また、サブエージェント内でも検索に様々な条件をつけて結果を絞り込むなど、コンテキストウィンドウの消費を抑える工夫が必要です。

検索に関するヒントをなるべく多く与えることも重要です。以前のサブエージェント実装でも触れましたが、スキーマ情報だけを渡しても生成AIは十分に機能しません。実例として、BigQueryのテーブルスキーマに user_id というカラムがあったとしても、それがUUIDなのか数値IDなのか、どのようなサービスのユーザIDなのかといった情報がなければ、適切な検索クエリを生成できません。生成AIは適当な推論で適当な値を検索し、該当ログがなかったと勝手に判断します。可能な限り、どのフィールドがどういう意味を持つか、どういう形式のデータが格納されているか、どういう条件でデータが入っているか（ログイン成功時のみ記録される、特定のイベントタイプでのみ存在するなど）を説明した方が良い結果が得られます。

さらに、few-shot promptingの応用として、過去の成功事例を提示するとそれを参照して検索精度が向上します。「あるユーザの行動を追跡するには、このようなクエリを使った」という例をいくつか示しておくと、生成AIはそのパターンを学習して類似のケースに応用できます。

基本的な原則として、人間がやってもうまくいかないものはLLMがやってもうまくいきません。逆に言えば、人間が簡単にできることは生成AIも簡単にできる可能性が高いということです。そのため、人間にとってもわかりやすい情報を注入することに注意を払う必要があります。

スキーマ情報の管理

ログ検索ツールの実装でよくある誤解として、「検索結果のデータ量がコンテキストウィンドウを圧迫する」というものがあります。確かにそれも事実ですが、実は意外とスキーマ情報の方が重い場合があります。

実例として、Google CloudのAudit LogをBigQueryに格納すると、カラム数が数千を超えることも珍しくありません。各サービスごとに異なるメタデータフィールドがあり、それらがすべてネストした構造で格納されるためです。このスキーマ定義だけでコンテキストウィンドウをかなり圧迫します。EDRログも同様で、プロセス情報、ネットワーク情報、ファイル情報など、詳細な項目が数百〜数千に及ぶケースがあります。

対策として、事前に与えるスキーマ情報を限定しておくという手があります。セキュリティ分析でよく使う主要なカラムだけを抽出して、簡易版のスキーマ定義を用意しておく方法です。ただし、この方法には面倒な側面もあります。データソースのスキーマが更新されたときに、簡易版も手動で更新しなければならず、メンテナンスコストが発生するためです。また、簡易版に含まれていないカラムは検索できなくなるため、スキーマ情報の量と検索精度のバランスを考慮して設計する必要があります。

クエリ言語への対応

ツールのインターフェースは、当然ながらログ検索の方法に依存します。メジャーな検索クエリ言語、具体的にはSQLであれば生成AIで十分に生成できます。SQLは生成AIの学習データに大量に含まれているため、複雑な結合やサブクエリであっても比較的正確に生成できます。BigQueryのSTRUCT型やARRAY型など、方言的な機能も比較的正確に生成できます。

しかし、あまりメジャーではないデータウェアハウス製品の独自クエリ言語を使っている場合は注意が必要です。一部の商用製品では独自のDSL（Domain Specific Language）を採用しており、LLMがその構文を正しく理解していない可能性があります。その場合はクエリの構文や仕組みについて、システムプロンプトなどで詳しく説明する必要があります。

具体的には、以下のような情報を提供すると良いでしょう。

  • 基本的なクエリの構文（SELECT文に相当するもの、WHERE句に相当するもの）
  • データ型の扱い方（文字列のエスケープ方法、日付の表現方法）
  • よく使う関数やオペレータの例
  • 実際のクエリ例（few-shot promptingとして）

こうした状況を踏まえると、LLMエージェントの利用も視野に入れたログ保持・検索の仕組みを考える必要がある時代になったといえます。新しいデータウェアハウスやログ管理システムを導入する際には、「LLMがクエリを生成しやすいか」という観点も評価基準に含めるべきでしょう。

(3) インフラやシステムの最新状態取得

対象リソースが今どういう状況なのか、権限が正しく設定されているのか、どのようなリソースと接続されているのかなどを調べるツールです。ログが過去の事象を追跡するのに対し、このツールは現在の状態を把握するために使用します。

セキュリティアラートの分析では、「何が起きたか」だけでなく「今どうなっているか」も重要です。IAMロールの権限が変更されたというアラートがあった場合、その権限が現在どうなっているのか、すでに修正されているのか、それとも危険な状態が継続しているのかを確認する必要があります。

実装方法

実装方法としては主に2つのアプローチがあります。それぞれメリット・デメリットがあるため、用途に応じて使い分けることが重要です。

API直接呼び出し方式

クラウドプロバイダーやサービスが提供するAPIを直接叩く方法です。参照系の権限だけをLLMエージェントに渡して、必要に応じて検索させます。AWS環境であれば、IAM、EC2、S3などの各サービスのDescribe系APIやGet系APIを呼び出します。ある程度メジャーなサービスであれば生成AIもAPIの使い方を理解していますが、マイナーなサービスや社内システムの場合は、APIの仕様やパラメータの意味を詳しく説明する必要があります。この方法のメリットは、常に最新の情報を取得できることです。アラート発生直後の状態を正確に把握したい場合に有効です。しかし、API呼び出しにはrate limitや取得上限があるため、大量のリソースを一度に調査すると制限にひっかかる可能性がある点に注意が必要です。また、API呼び出しのたびにコストが発生するサービスもあります。

スナップショット方式

定期的にスナップショットを取得してデータウェアハウスに保存する方法です。頻繁に検索する場合や検索対象が多すぎる場合はこの方法が適しています。実例として、CloudQueryを使えば、AWSやGoogle Cloud、Azureなどのリソース情報を定期的に取得してBigQueryやPostgreSQLなどに保存できます。Google Cloudの場合は、Cloud Asset InventoryをBigQueryへexportする機能が標準で提供されているため、これを利用するのが簡単です。一方、AWSやAzureを含むマルチクラウド環境では、CloudQueryを使うことで統一的なスキーマで管理できるメリットがあります。この方法のメリットは、SQLで横断的な検索ができることと、rate limitを気にせずに大量のリソースを検索できることです。また、スナップショット間の差分を比較することで、いつリソースの設定が変更されたかを追跡することもできます。欠点としては定期実行（通常は1時間〜1日ごと）なので、リアルタイム性に欠け、アラート発生時点とスナップショット取得時点の間に状態が変わっている可能性があります。

活用例

このツールによってリソースの現在の状況を様々な角度から調べることができます。

  • 権限設定の検証: もっともよく見るユースケースです。実例として、「S3バケットがパブリックアクセス可能になっている」というアラートに対してポリシー設定やACL設定を確認したり、危殆化したIAMユーザーの権限範囲を調査して影響範囲を見積もったりします
  • 設定ミスの継続確認: 設定ミスに関するアラートが、現在も継続しているのかを確認します（セキュリティグループのポート開放状態の確認など）
  • リソース間の関係性分析: 侵害されたリソースがどのVPCに属し、どのセキュリティグループが適用され、どのIAMロールがアタッチされているかといった情報を取得して攻撃の影響範囲を評価します

(4) 開発リポジトリの情報取得

プロダクトに対するセキュリティに責任を持つ場合、開発リポジトリ内にあるコードの状況や開発者のやりとりなどを検索できると便利です。アプリケーションの脆弱性やインフラの設定ミスなどのアラートが発生したとき、その原因がコードの変更に起因するケースは少なくありません。リポジトリ情報を検索できることで、いつ・誰が・なぜその変更を行ったのかを迅速に把握できます。

基本的な検索機能

リポジトリ内のコードや変更履歴を検索できるようにします。GitHub APIやGitLab APIなどを利用して、以下のような調査が可能になります。

  • IaCの設定変更調査: TerraformやCloudFormationを使っている環境で設定ミスが疑われる場合、その設定が意図的なものか誤った変更なのかを確認できます（セキュリティグループのポート開放がコミット履歴やプルリクエストのレビューコメントで承認されているかなど）
  • アプリケーション変更の影響調査: 問題が発生した際に、いつから変更が加わったのかを追跡できます（認証バイパスの可能性があるアラートに対し、認証ロジックの変更履歴から脆弱性の混入時期を特定するなど）
  • 脆弱性の影響範囲特定: 攻撃の痕跡に対応するソースコードを追跡できます（SQLインジェクションの痕跡から該当エンドポイントのコードを確認するなど）。ただし、アラート情報だけでは実行されたコードを正確に特定するのが難しいケースも多いため、この用途は補助的なものとなります。

スキャン結果のデータベース化

別アプローチとして、スキャン結果やある時点での状態をデータウェアハウスに保存しておき、検索するという手もあります。これはリアルタイムでコードを検索するのではなく、事前にスキャンした結果を蓄積しておく方式です。

筆者はoctovyというツールをGitHub Appsとして実装し、リポジトリへのpush時に自動的にpackage.jsonやgo.modなどを解析してそのリポジトリで利用している3rd partyパッケージ情報の一覧を取得しています。これを全リポジトリで実行し、パッケージ情報をBigQueryに保存しています。どのパッケージがどのバージョンで使われているかをデータベース化することで、サプライチェーン攻撃があったときにこれを検索させると、影響のあったパッケージが社内で使われているかを即座に判定できて便利です。実例として、「npmパッケージXのバージョン1.2.3に脆弱性が発見された」というアラートがあった場合、データベースを検索することで「リポジトリAとリポジトリBで該当バージョンが使われている」という情報を数秒で得られます。

この方法のメリットは、検索が高速であることと、GitHub APIのrate limitを気にせずに大量の検索ができることです。一方で、定期実行なので最新のコード変更が反映されるまでにタイムラグがある点には注意が必要です。

(5) 社内ドキュメントの検索

社内に関するポリシーや決められた手順などをエージェントが参照できるようにするツールです。組織のセキュリティポリシーや対応手順書、エスカレーション基準などを検索対象とすることで、組織固有のルールに基づいた判断ができるようになります。

実例として、「このアラートは重大インシデントとして扱うべきか」という判断をする際に、組織のインシデント分類基準を参照できれば、より正確な判断ができます。また「この種のアラートにはどう対応すべきか」という手順を検索できれば、標準化された対応を促すことができます。

実装時の課題

ただし社内ドキュメント検索の扱いはやや難しく、どういう情報があるかを事前に教えておかないといけません。以前説明した通り「知らないものは探さない」という原則（エージェントは人間と同様、存在を知らない情報源は検索しようとしない）があるため、ドキュメントの存在をエージェントに認識させる必要があります。

単に「社内ドキュメントを検索できます」とだけ伝えても、エージェントはいつそのツールを使うべきかを判断できません。使う場合は、「インシデントの重要度判定が必要な場合は、インシデント分類基準ドキュメントを検索せよ」といったように、具体的な利用シーンとあわせて情報を提示しておく必要があります。

あるいは、よく参照されるドキュメントの内容をシステムプロンプトに事前に埋め込んでしまうという方法もあります。ドキュメントの量が少ない場合や、頻繁に参照される重要な情報であれば、この方法が効率的です。ただしドキュメントが更新されたときにシステムプロンプトも更新する必要があるため、運用の手間は増えます。

ドキュメントサービスの選択

また、利用しているドキュメントサービスの検索性能も重要です。そもそも検索機能が貧弱な場合は、LLMエージェントにやらせてもうまくいきません。

全文検索ができない、日本語の検索が苦手、検索結果の関連度順ソートができないといったドキュメントサービスでは、LLMが適切なドキュメントを見つけられない可能性が高くなります。それであれば素直にドキュメントのURLリストを用意して、エージェントに直接ドキュメントを取得させる方がよいでしょう。

理想的には検索機能が充実しているサービスを使い、APIを通じて検索できるようにしておくことです。これによりLLMが検索キーワードを生成し、検索結果から適切なドキュメントを選択するといった一連の流れを自律的に実行できます。

(6) 社内コミュニケーション記録の検索

Slackやチャットツールの履歴、自動生成議事録など、社内コミュニケーションの記録を検索するツールです。一見すると優先度が低そうに思えますが、セキュリティアラートの分析において意外と役に立ちます。

形式的なドキュメントには残らない情報や、リアルタイムのやりとりから得られる文脈情報が、アラートの真偽判定に重要な手がかりを提供することが多いためです。

活用例

コミュニケーション記録を検索することで、以下のような判断を迅速に行えます。

  • 構成変更の意図確認: 構成変更があった際に、その意図を判定できます（セキュリティグループの22番ポート開放に対し、開発チームのSlackで「デバッグのために一時的に開放した」という会話を発見し、意図的変更か攻撃かを判断するなど）
  • 未知のサービス・ツールの調査: 見慣れないサービスやアプリケーションの出どころを調べられます（CloudTrailログの知らないIAMユーザーをSlack検索し、別部署が作成したサービスアカウントと判明するなど）
  • ツール利用状況の確認: 不審に見えるアプリケーションが実は正規の業務ツールかを確認できます（アラートに含まれるアプリケーション名を検索し、業務利用が確認されるなど）
  • 誤検知の迅速な判断: 事前に告知されていた正規活動を素早く特定できます（深夜の大量データアクセスアラートに対し、データエンジニアチャンネルで事前共有されていたメンテナンス予定を発見するなど）

実装上の注意

Slack APIなどを利用する場合、機密情報へのアクセスに関する配慮が必要です。全チャンネルの全メッセージを無制限に検索できるようにするのではなく、検索対象を特定のパブリックチャンネルや業務関連チャンネルに限定するといった制限を設けることを検討してもよいでしょう。また、個人のDMは検索対象外とするなど、組織のポリシーに応じた適切な範囲設定が重要です。

(7) Web検索＆ページ取得ツール

Web検索やページ取得ができるツールは、外部の最新情報を取得する手段として便利な場合があります。新しく公開されたCVE（Common Vulnerabilities and Exposures）に関する詳細情報や、最新の攻撃手法に関する技術記事、セキュリティベンダーのアドバイザリなどを取得する際に役立ちます。

セキュリティリスクと注意点

このツールにはいくつかの重大なセキュリティリスクがあり、実装には慎重な検討が必要です。

  • 悪意あるURLへのアクセスリスク: アラートに含まれるURLやIoCを踏み抜いてしまう可能性があります。攻撃者が仕掛けたフィッシングサイトやマルウェア配布サイトに自動アクセスしてしまうと、エージェント環境の侵害や、組織のネットワークからのアクセスであることが攻撃者に伝わるリスクがあります
  • 情報漏洩のリスク: 攻撃に関する情報を検索クエリに含めてしまう可能性があります（「社内システムXで脆弱性Yが検出された」という情報を検索クエリに使うと、検索エンジンのログを通じて組織の脆弱性情報が漏洩するなど）

実装時の推奨事項

プロンプトで「既知の悪意あるドメインにはアクセスしない」「機密情報を検索クエリに含めない」といった制約をある程度はガードできますが、完全ではありません。そのためこのツールは筆者にとってもまだ未知数の部分が多く、実装するならサブエージェントの方がよいかもしれません。サブエージェントにすることで検索クエリの事前レビュー（機密情報が含まれていないかチェック）などはしやすくなります。またURLやドメイン名のホワイトリスト化も検討に入れるのが良いでしょう。

これらの対策を講じることで、ある程度リスクを低減できますが、それでも完全に安全とは言えません。組織のセキュリティポリシーと照らし合わせて、導入の可否を慎重に判断[1]する必要があります。

まとめ

本日はセキュリティ分析エージェントに組み込むと有用なツール・サブエージェントについて、7つのカテゴリに分けて解説しました。これらは筆者の実運用経験に基づくものですが、重要なのは「どのツールを実装するか」ではなく、自組織のセキュリティ分析業務で何が必要かを見極めることです。

  • コンテキストウィンドウの問題: ログ検索やスキーマ情報はコンテキストウィンドウを大量に消費します。サブエージェント化や事前のスキーマ限定など、設計段階から対策を講じる必要があります
  • 「知らないものは探さない」原則: LLMエージェントは人間と同じで、存在を知らないツールや情報源は使えません。システムプロンプトやツール説明で明示的に導く必要があります
  • LLMが利用しやすいシステム・基盤の選択: SQLのようなメジャーなクエリ言語はLLMが得意ですが、独自DSLを使うデータウェアハウスは苦手です。ツール選定時に生成AI適性も考慮すべき時代になっています

セキュリティ分析エージェントの価値は、個々のツールの性能ではなく、状況に応じて適切なツールを呼び出し、情報を統合して判断する能力にあります。自組織に必要なログや情報がなんなのかを整理したうえで、ツールやエージェントの実装を検討するのが良いと考えられます。

脚注

  1. 実際のところ、筆者もまだセキュリティ分析文脈での安全なLLMによるWebアクセスのベストプラクティスについては浅く、経験値をお持ちの方がいたらぜひ共有してもらえると嬉しいです。 ↩︎

Discussion