セキュリティチームが単なる「エージェント型AIの購入者」ではなく「構築者」になりつつある理由

AIエージェント。今やあらゆる場所で目にする存在です。テレビ広告でも、公共交通機関でも、さらにはスタジアムでも見かけます。 

セキュリティ専門家にとって、AIエージェントはもはや避けて通れない存在です。ほぼすべてのベンダーが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)サーバーが、これらのエージェントとツールをつなぎます。 

MCPサーバーは、アクティブなサーバー数が10,000を超え、月間ダウンロード数も700万件に上る、圧倒的に主流のエージェントプロトコルであり、エージェントをベンダーニュートラルかつ共有可能なものにしている要素でもあります。 

担当者は、たとえば特定の検知ツール向けにMCPサーバーを自ら書くことができ、ベンダーがその統合を用意するのを待つ必要がありません。同様に、チームをまたいで、あるいは組織をまたいでさえも、担当者たちは同業の誰かが構築したMCPサーバーを取り入れて実行できます。 

このような形でAIエージェントを共有することは、オープンソースの脅威インテリジェンスと同じように集団防御を強化します。 

オープンソースの脅威インテリジェンスによって、セキュリティチームは脆弱性を解消したり攻撃を阻止したりするために必要な情報を得られます。 

オープンソースのセキュリティ向けエージェント型AIは、それをさらに一歩進め、チームがゼロから構築する必要のない、すぐに使えるツールを提供してくれます。 

AIエージェントのガバナンス問題を解決する

しかし、これだけの利点があるとはいえ、担当者たちが何の監督もなしにAIエージェントを次々と立ち上げてよいわけではありません。これらは単にテキストを生成するだけのチャットボットではなく、実際にアクションを実行するものだからです。 

エージェントが人間の許可なくコードを自律的に書き、データストアに問い合わせ、ネットワーク構成を変更できるとなれば、無秩序な共有や監視されない利用は深刻な運用上のリスクをもたらします。 

そのリスクをエコシステム全体、さらには業界全体にまで拡大して考えれば、悪用される可能性は膨大かつ看過できないものになります。 

では、エージェントに書き込み権限を与える前に、ガバナンスはどのような形であるべきでしょうか。 

まず、最小権限の原則を、後付けの対策としてではなく、最初からの前提条件として適用することです。

エージェントを導入する簡単な方法は、あらゆるものへのアクセス権を与えて自由にやらせることです。しかし、それは不必要なリスクをもたらします。エージェントに与えるアクセス権を絶対に必要なものだけに限定することで、事業の他の部分で意図しない結果が生じるのを防げます。 

次に、最も影響の大きいアクションについては、人間を介在させるチェックポイントを設けることです。 

一般に、アラートのトリアージやログの相関分析といった影響の小さいアクションについては、ミスがあっても大きな被害にはつながらないため、承認なしでエージェントに任せて構いません。一方、本番システムに対する書き込みアクションのような影響の大きいアクションでミスが起きれば、事業が立ち行かなくなりかねません。だからこそ、人間による承認が不可欠なのです。 

最後に、エージェントは監査可能でなければなりません。優れたセキュリティエージェントの監査証跡には、実行されたアクションだけでなく、エージェントがそのアクションを取ると判断した理由、何に対して操作を行ったか、そして誰が承認したかまで記録されている必要があります。これらは、人間が事後に確認できる、改ざん検知可能かつ照会可能な記録として残されるべきです。

AIエージェントが成果を上げているかどうかをチームはどう測定すべきか

共有されるAIエージェントの基盤となるコードやロジック自体は無料であることが多い一方で、それを運用し安全に保つにはコストがかかります。ですから、その労力に見合う価値があるかどうかを確認する必要があります。 

つまり、具体的な成果指標に照らして評価するということです。MTTRは低下したか。アナリストのトリアージ負荷は軽減されたか。重大な検出事項の見落としは減ったか。これらは、あなた自身とチームに問いかけるべき質問の一部です。 

オープンソースのAIエージェントはどこへ向かうのか

担当者たちがセキュリティ向けのエージェント型AIを自ら構築することに、より慣れていくにつれ、こうしたツールはさらに数多く登場してくるでしょう。オンライン上での交換の場はますます盛んになり、集団防御にとってもプラスに働くはずです。 

とはいえ、大惨事が起こる可能性が完全にないわけではありません。制御を外れたオープンソースのエージェントが、甚大な運用上の混乱や侵害を引き起こす可能性は十分にありますし、実際に起こり得るでしょう。 

だからこそガバナンスがこれほど重要なのであり、導入するエージェントを慎重に選び抜く必要があるのです。