AIエージェントが守るセキュリティ--少人数チームの脆弱性対策の常識を変えた話 (1/3)

はじめに

2025年12月5日、CVSS 10.0（最高スコア）の脆弱性が公開されました。React2Shell（CVE-2025-55182）。世界中で使用されている有名なフレームワークに影響を与えた、認証なしでサーバー上の任意のコードを実行できる「RCE (Remote Code Execution：リモートコード実行)」という脆弱性です。しかも公開から数時間で、国家レベルの攻撃者グループによる実際の攻撃が始まりました。AWS、Google、Microsoftがそれぞれ攻撃の観測を報告しています。

セキュリティ専任を用意出来る企業は希少

私たちは少人数でWebサービスを開発・運用しているチームです。セキュリティ専任のエンジニアはおらず、アプリエンジニア、インフラエンジニア、運用担当者がそれぞれセキュリティを意識しつつ対応するという属人的な運用でした。

NVD（米国の脆弱性データベース）には1日100件以上のCVEが公開されます。その中から自社に関係あるものだけを見つけ出し、影響を判断し、対策を立てる。これを手作業でやるのは、専任がいても大変です。

攻撃者はAIを使い始めている

さらに状況を深刻にしているのが、攻撃側のAI活用です。

2025年後半から、LLM（大規模言語モデル）を使ったエージェントが、脆弱性のエクスプロイト（攻撃コード）を自律的に作成できることが複数の研究で実証されています。従来は熟練のセキュリティ研究者が数週間〜数ヶ月かけていた作業が、AIを使えば数時間に短縮される。

つまり、脆弱性が公開されてから攻撃に使われるまでの「猶予時間」が急速に縮まっているのです。

攻撃者の優位性

攻撃者には、防御側にはない圧倒的な優位性があります。

まず、倫理的な制約がありません。世界中の本番環境を「練習台」に使えます。攻撃が成功すれば手法が磨かれ、失敗しても何のペナルティもない。私たちのサービスも、知らないうちに誰かの練習に使われていると考えることの方が現代においては健全でしょう。成功した手法は同じ技術を使う無数のサービスに横展開される。攻撃者の腕は、私たちの想像を超えるスピードで上がり続けています。

さらに、攻撃者は常に先手を取れます。新しい脆弱性が公開された瞬間から攻撃を始められる。防御側はそれを知ってから対応を始め、パッチを検証し、テストし、デプロイする。このタイムラグの間、サービスは無防備です。

その上で、攻撃側はAIエージェントを手にしました。これまで熟練した研究者が数週間〜数ヶ月かけていたエクスプロイト開発を、AIが数時間でやってしまう。24時間休まず、疲れもせず、世界中の脆弱性を同時に狙うことが可能という絶望的な状況です。

AIで防御を自動化する

私たちの答えはシンプルでした。攻撃者がAIエージェントを使うなら、防御側もAIエージェントを使う。

構築したのは、AIエージェントによるCVE自動トリアージシステムです。

トリアージとは、一般的に救急事故現場などにおいて医療や治療の優先度を見極めることを指します。一方、サイバーセキュリティにおけるトリアージは、発生したインシデントの重要性や緊急度を見極め、対応が必要かどうかの判断や、複数のインシデントが発生している場合にはその優先順位の決定などを行うステップのことを指します。

• NVDから新しいCVEを1時間ごとに自動取得
• 自社のソフトウェア構成（SBOM）と照合して、関係ありそうなものだけを絞り込み
• LLMが「このCVEは自社に影響するか？」を自動判定
• 影響ありの場合は対策案まで生成してSlackに通知

専任エンジニアがやっていた「情報収集→影響判断→対策立案」の一連の流れを、AIエージェントが24時間365日やってくれます。

導入してどう変わったか

Before:

• 脆弱性情報のキャッチアップは週1〜2回、手動でNVDやセキュリティニュースを確認
• 影響判断は脆弱性の説明を頼りに会議で判断
• 重要なCVEを見逃すリスクが常にあった
• たまに確認しても大量のCVEに圧倒されて「あとで見る」で放置

After:

• 影響ありのCVEは検知から数分以内にSlackにメンション付きで即時通知
• 影響度・該当コンポーネント・推奨対策がセットで届くため、判断が即座にできる
• 影響なしのCVEは朝と夕方の日次サマリで一括通知。チャンネルのノイズがゼロに
• React2Shellのような緊急の脆弱性が来ても、「対応すべきか？何をすべきか？」が自動で判断される

月額のAPI料金は数ドル程度。セキュリティ専任を雇うコストと比較すれば、桁違いに安い投資です。

通知設計で大事にしたこと

実は最初のバージョンでは、影響なしのCVEも1件ずつリアルタイムで通知していました。セキュリティ通知において、「抜け漏れ」が怖かったからです。

結果、チャンネルが影響なし通知で埋まり、メンバーが通知を無視するようになりました。セキュリティは常に利便性とのトレードオフです。初期バージョンでは利便性を考慮しなかった悪い例でした。

そこで影響なしは日次サマリ、影響ありだけ即時通知という方針に切り替えました。さらに影響度「高」「中」にはメンション付き、「低」はメンションなし、とノイズのレベルを細かく制御しています。

この「通知のS/N比を上げる」という発想は、セキュリティに限らず、あらゆる監視・通知システムに通じる設計原則だと思います。

この仕組み、セキュリティ以外にも使える

今回構築したシステムの本質は、「大量の情報を読んで、自社に関係あるか判断する」というタスクをAIに任せるパターンです。大量の情報を正確に処理することはコンピュータの得意領域ですね。

このパターンは他にも応用できます。

• WAFログから実際の攻撃だけを選別する
• 法改正が自社サービスに影響するか自動判定する
• 競合のリリースノートから自社に関係する変更だけを抽出する
• 依存パッケージのライセンス違反を自動検出する

「情報ソース」「自社コンテキスト」「判断基準」の3つをAIに渡すだけ。同じフレームワークで、監視対象をいくらでも増やせます。

次回予告

第2回では、このシステムの技術的な設計を詳しく解説します。なぜLLMを2回呼ぶのか、キーワードマッチングの精度をどう上げたか、Slack通知のノイズをどう減らしたか——エンジニアが気になるであろうポイントを掘り下げたいと思います。