AIエージェント。今やどこにでもある。テレビや公共交通機関、さらにはスタジアムでも広告を目にする。
セキュリティの専門家にとって、AIエージェントは避けて通れない。ほぼすべてのベンダーが、それを使う製品を売り込もうとしており、その言葉はほとんど意味を失いかけているほどだ。
そこでセキュリティ担当者は、セキュリティ向けのエージェント型AIを自ら構築、設定、運用し始めている。
カスタム構築したエージェントは、市販のツールでは埋められないギャップを補う。オープンソースでベンダーに依存しないAIエージェントは、集団防御の強化に大きく貢献できる。しかし、適切なガバナンスがなければ、利益よりも害をもたらしかねない。
なぜセキュリティチームは、自分たちのエージェントを構築し、共有しているのか。
セキュリティチームが自らエージェントを構築する主な理由は3つある。AIエージェントは機能し、カスタム構築したものはさらに高い効果を発揮し、オープンソースのエージェントは集団防御を強化するからだ。
そもそも、なぜAIエージェントを使うのか。
過剰な期待が広がる一方で、セキュリティ向けのエージェント型AIは成果を上げている。
Verizon DBIR 2026によると、組織が対処すべきCISA KEVの脆弱性は、1年前より50％増えている。脆弱性の件数が増加するなか、セキュリティチームはこれまで以上に迅速に脆弱性を見つけ、優先順位を付け、解消する必要がある。AIエージェントはその支援ができる。
エージェント型AIシステムは、人の介入なしに、脆弱性を関連付け、優先順位を付け、場合によっては修正まで実行できる。これにより平均対応時間（MTTR）は大幅に短縮される。同じ報告書で、CISA KEVの脆弱性にパッチを適用するまでの中央値が前年の32日から43日に延びたことが判明していることを考えれば、これは喫緊の課題だ。
なぜ自社でAIエージェントを構築するのか。
市販のツールが、ビジネス固有の要件を満たすことはめったにない。汎用AIエージェントには、コンテキストの不足や十分な制御・ガードレールの欠如、意図のずれといった問題が生じることが多い。
担当者は、こうした欠点に対処するために自らエージェントを構築する。
セキュリティアーキテクチャや現場のテレメトリーと深く統合した形で構築し、厳格なツールの許可リストと強固な実行境界を組み込む。カスタム構築のループによって、人間を介在させた承認ゲートもより厳密に設定できる。最後に、Model Context Protocol（MCP）サーバーによって、これらのエージェントをツールに接続する。
なぜAIエージェントを共有するのか。
MCPサーバーは、1万台を超えるアクティブサーバーと月間700万ダウンロードを誇る、圧倒的に優勢なエージェント型プロトコルであり、エージェントをベンダーに依存しない共有可能なものにする役割も果たす。
担当者は、ベンダーがその統合機能を提供するのを待つことなく、例えば特定の検知ツール向けのMCPサーバーを作成できる。同様に、チーム間、さらには組織間の担当者も、同業者が構築したMCPサーバーを取り入れて実行できる。
このようにAIエージェントを共有することは、オープンソースの脅威インテリジェンスと同じように、集団防御を強化する。
オープンソースの脅威インテリジェンスがあれば、セキュリティチームは脆弱性を解消したり、攻撃を阻止したりするために必要な情報を得られる。
オープンソースのセキュリティ向けエージェント型AIは、その一歩先を行く。チームがゼロからツールを構築するのではなく、作業を実行できる既製のツールを提供するのだ。
AIエージェントのガバナンス問題を解決する
しかし、メリットがあるからといって、担当者が監督なしにAIエージェントを次々と立ち上げてよいわけではない。これは単にテキストを生成するチャットボットではなく、アクションを実行するものだ。
エージェントが人の許可なしに自律的にコードを書き、データストアにクエリを実行し、ネットワーク設定を変更できる場合、無秩序な共有や監視されていない利用は、深刻な運用リスクを招く。
そのリスクがエコシステム全体、さらには業界全体に広がれば、悪用の可能性は非常に大きくなり、無視できないものとなる。
では、エージェントに書き込みアクセスを許可する前に、ガバナンスはどうあるべきなのか。
まず、最小権限の原則を適用する。これは後付けではなく、出発点となる条件だ。
エージェントを導入する最も簡単な方法は、すべてへのアクセスを与えて自由に使わせることだ。しかし、それでは不要なリスクが生じる。絶対に必要なものだけへのアクセスをエージェントに許可すれば、ビジネスの他の領域で意図しない結果が生じるのを防げる。
次に、影響の大きいアクションには、人間を介在させたチェックポイントを設ける。
アラートのトリアージやログの相関分析など、影響の小さいアクションは、承認なしに完了するようエージェントを信頼してよい場合が多い。ミスをしても大きな害にはならないからだ。一方、本番システムへの書き込みなど、影響の大きいアクションを誤れば、ビジネスを機能停止に追い込む可能性がある。そのため、人による承認が不可欠になる。
最後に、エージェントは監査可能でなければならない。セキュリティエージェント向けの優れた監査証跡には、実行したアクションだけでなく、エージェントがそれを実行すると判断した理由、アクセスした対象、承認者も記録されるべきだ。これらは、後から人が確認できる、改ざんの有無を検証でき検索可能な記録として保存する必要がある。
AIエージェントが成果を上げているか、チームはどう測定できるのか。
共有AIエージェントの基盤となるコードやロジックは無料であることが多いが、それを実行し、セキュリティを確保するには費用がかかる。したがって、その労力に見合う価値があることを確認しなければならない。
つまり、具体的な成果指標に照らして測定するということだ。MTTRは短縮したか。アナリストのトリアージ負荷は減ったか。重大度の高い検出結果の見落としは減ったか。こうした問いを自分自身とチームに投げかける必要がある。
オープンソースのAIエージェントはどこへ向かうのか。
担当者がセキュリティ向けのエージェント型AIを自ら構築することに慣れるにつれて、こうしたツールはさらに数多く登場するだろう。オンラインの交換プラットフォームはより普及し、集団防御にも恩恵をもたらす。
しかし、災厄の可能性がなくなったわけではない。悪意あるオープンソースエージェントによって、甚大な業務の混乱や侵害が生じる可能性はあり、実際にそうなる公算も大きい。
だからこそガバナンスが重要であり、導入するエージェントは慎重に選ばなければならない。