脆弱性診断・脅威モデリングを行うセキュリティエージェントを実装しました

こんにちは！システムセキュリティ推進グループの小笠原 (@gassara5) です。

最近では連日のサプライチェーン攻撃の増加やClaude Mythosを始めとした AI のサイバー攻撃能力を考えると、守り側も AI を使わずにはいられない時代になりました。

今回は、私たちが実装したセキュリティエージェント「BUGMAP」の事例をご紹介したいと思います。BUGMAP はセキュリティチームだけでなく、社内のエンジニアが使えるツールとして提供しています。

*＊ BUGMAP： 「BUG（脆弱性）がどこにあるか明らかにし、解決のための道のり=MAP（地図）を提供する」、という意味合いで名付けました*

なぜ BUGMAP を作ったのか

私たちセキュリティチームはプロダクトセキュリティの課題解決がミッションとなります。その中でも、リリース前などに実施する脆弱性診断や、設計レビュー、脅威検知・モニタリングをメインに行ってきました。

今までのスピード感では対応できない

しかし、従来の脆弱性診断は完了までのリードタイムが数カ月かかることもあります。また、設計レビューや脅威モデリングについても規模によっては数日かかりきりでした。**

一方で、プロダクトのリリーススピードにセキュリティレビューが追いつかないという課題もあります。

普段から対象プロダクトを開発しているわけではないため、レビューに時間がかかるのは仕方ないのですが、現場エンジニア目線でも診断準備に相当な負担があるというのが課題でした。

AI の登場によって攻撃者側の能力やスピードも数段上がっているため、私たち守る側もスピード向上は急務の課題です。

品質とスピードの両方を向上する

スピードだけではなく、品質も落とすわけにはいきません。むしろ攻撃能力も日に日に上がっているため、今まで以上に脆弱性の解析能力が求められます。

そこで私たちは、「次世代セキュリティレビュー プロジェクト」を 2025 年 11月から始動し、BUGMAP というサービスを開発しました。今回はこの BUGMAP の取り組みで実践した内容と結果を共有したいと思います。

このプロジェクトでは、セキュリティチームだけで完結させるのではなく、診断チーム（診断士）、実際にプロダクトを開発するエンジニアと一緒に進めてきました。診断担当者が持っている暗黙知を分解し、AI エージェントが実行できるタスクやレビュー観点に落とし込みながら、現場のエンジニアでもセルフサービスとして使える形にすることを目指しました。

BUGMAP で何ができるのか

BUGMAP が提供しているメインの 2 つの機能をご紹介します。

1. WEB システムの脆弱性診断

まず最初にセキュリティ診断チームと一緒に脆弱性診断エージェントの実装に取り掛かりました。BUGMAP の診断は従来のブラックボックス診断だけでなく、ソースコードベースのホワイトボックス診断（White-box Diagnosis）の双方を行うことがポイントです。

また、診断の依頼者はこの準備のために特別な作業は必要なく、BUGMAP が、URL のエンドポイント一覧やデータのインプット・アウトプット解析図などを自動生成します。

最初に、GitHub App をインストールし診断対象のリポジトリを選択（複数可能）、あとは診断観点やブラックボックス診断等のオプション設定を入力し、診断を開始できます。

およそ、1h〜2h 程度で診断が完了し、サマリーレポートと指摘 Issue を見ることができます。GitHub と連携しているため、そのまま BUGMAP 側が PR（Pull Request）作成や GitHub Issue 連携も行えるようにしています。これはいち早く脆弱性を修復するためのフローに繋げるようにしたかったためです。

また、Issue コメントで AI に質問や深堀り調査を依頼することもできるようにしました。セキュリティチームと現場エンジニアとも共通のインターフェースでコミュニケーションを行います。

2. 設計レビュー／脅威モデリング

続いて、設計レビュー／脅威モデリングです。**

設計レビューの相談は、私たちのチームに来る相談の中でも特に多い依頼になります。例えば、新しい機能を設計・実装したり、システム全体のセキュリティを見直すケースで行われます。しかしこれらの設計レビューは非常に専門性の高いタスクになるため AI 化の効果が出やすい領域だと考えています。

私たちのチームでは主に 2 つのレビュー手法を採用しています。

• ベースラインレビュー

• リスクベースレビュー

1 の「ベースラインレビュー」では OWASP（Open Web Application Security Project）の ASVS（Application Security Verification Standard）や各種ベンダーのベストプラクティスを元にどれだけ準拠できてるかをチェックするものです。また、社内で過去に行ったレビュー履歴から実装ベースのナレッジも参照して評価し具体的な指摘に落とし込みます。

2 の「リスクベースレビュー」では脅威モデリング（Threat Modeling）を行うケースが多いです。データフロー図（DFD: Data Flow Diagram）を作成しシステム全体を可視化し、重要な資産がどこにあるのか、信頼境界（Trust Boundary）はどこかを特定し、脅威分析→リスク評価を行います。また、社内で広く導入されている RISKEN や Wiz といったセキュリティサービスと連携して、実際に観測されている Finding／Issue（エビデンス）を含めた脅威分析を行えるようにしています。

現場で放置されがちな CRITICAL や HIGH 以外の問題も含めてトータルで評価し、対応の有無や優先度の意思決定を支援します。

導入して何が変わったのか

2026 年の 2 月頃から徐々に、実際の診断業務やレビュー依頼に BUGMAP を導入していきました。また、セルフ診断ツールとしても 4 月に社内で公開しました。**

導入してみるといくつかの発見がありました。

診断能力が高く、誤検知が少なかった

ソースコードベースの診断を行うので、ある程度は予想はしていたものの、それをはるかに上回る性能が確認できました。実際の診断業務では、従来のレビュー手法と並行して BUGMAP による診断を行い、人手のレビュー結果と比較しながら品質を確認してきました。特に良かった点は非常に「誤検知」が少ない**点です。

従来のセキュリティスキャンツールでは誤検知に悩まされるケースが多かったのですが、実際にエクスプロイト可能かを丁寧に AI が検証してくれます。その場で PoC コードを生成して検証したり、実際に API リクエストを送って攻撃が成立するかを確認します。

継続的に繰り返し実行が可能になった

現場のエンジニアに好評だった機能の一つが、「スケジュール診断」機能です。日々変化するシステムに対して定期的に診断を行い、新しい脆弱性を発見したら通知します。

今までの診断では半年〜1 年に 1 回行うのが限界でしたが、1 回の診断が 1h〜2h で終わるのと人が介在しないため、自動化できるようになりました。

また、脅威モデリングも同様です。今まで 1 回のレビューに非常に工数がかかっていたのですが、継続的に生きたコードベースで診断ができるようになったのは非常に大きい変化です。

現場のエンジニアが使いやすい体験になった

BUGMAP を導入して特に嬉しかったのは、実際に利用した現場のエンジニアから非常にポジティブな声をもらえたことです。単に診断性能を高めるだけでなく、GitHub 連携、PR 自動作成、Issue 連携、AI エージェントとのチャットや追加調査など、現場担当者が脆弱性を理解し、修正まで進めるために必要な機能をフィードバックをもらいながら揃えていきました。

これまでレビュー依頼のために必要だった情報整理や資料作成も、BUGMAP がソースコードや設計書から自動生成することで、依頼者側の準備負担をかなり減らせるようになりました。セキュリティチームだけが使うツールではなく、プロダクト開発の現場で自然に使える仕組みにできたことは大きな成果だと感じています。

BUGMAP を支えるアーキテクチャ

先日、Cloudflare の Mythos Preview 利用レポートの記事を見ました。**

https://blog.cloudflare.com/cyber-frontier-models/

ここで紹介されている「4 つの教訓」や「Vulnerability Discovery Harness**」の仕組みは非常に参考になるポイントが多く含まれていました。

単に AI に「脆弱性を見つけて。」と指示するだけでは不十分で、本来 AI が持つサイバーセキュリティ能力をうまく発揮できません。実はこれは私たちのチームでも以前から強く実感しており、非常に似たアプローチを取っていました。

全体ワークフローの構築

まず、セキュリティレビューのフローをいくつかの専用タスクに分割する仕組みを構築しています。各タスクで生成したアウトプットを次のタスクにコンテキストとしてうまく渡すよう設計しています。

ワークフローの実行制御として AWS の StepFunctions を採用しました。また、タスク実行環境としては ECS Fargate 上でサンドボックス化し AI エージェントのセキュリティを考慮しています。

AI の基盤モデルは Amazon Bedrock や OpenAI、ローカル LLM、Devin などタスクによって様々使い分けができる設計にしています。また、タスクごとに推論能力がどれだけ必要かによってもモデル選択や ReasoningEffort を調整できるようにしています。

これらの AWS サービスを軸にした技術選定は、AI エージェントのハーネス構築としては、今でも非常に良い選択だったと思っています。パフォーマンス、安定性、セキュリティのバランスが非常に良くメンテナンス性が高いです。

144 個の専用レビューエージェント

各タスクでは複数の専用レビューエージェントを起動させ親プロンプトでそれらのエージェントをオーケストレーションさせる仕組みにしています。気付いたら 144 個のエージェントに膨れ上がっていましたが、今後もっと増えることが予想されます。多ければ良い、というわけではありませんが、各エージェントの範囲を絞り、タスクを並列化することでより良い結果が得られてることは CloudFlare の「4 つの教訓」でも言及されています。

タスクごとに与えられた役割に応じたレビュー計画をたて、複数のSubagent を並列で起動（Spawn）させます。最後に結果をまとめるフローです。

ガイドラインやベストプラクティスの観点ごとに専用の Subagent を分ける設計にしています。こうすることで AI エージェントがサボることもなくなりますし、並列実行してくれるため全体的に早くなります。

複数のタスク×Subagent のアウトプットは最後にレビュー・検証し、結果をまとめる専用のフローも用意しています。

AI エージェントを安全に使うための工夫

BUGMAP では PoC コードの生成や実際の API リクエストによる検証も行いますが、これらの検証を安全に行うための仕組みも重要です。

例えば、AI エージェントの実行環境は ECS Fargate 上でサンドボックス化し、タスクごとに実行範囲を制御しています。また、外部サイトへの意図しないリクエストが発生しないように専用プロキシなどの安全対策を組み込んでいます。

AllowList（URL やドメインの許可）では基本的に自社サイトのみを制限し、DenyList（決済機能やメール送信、サードパーティ通信のエンドポイントなどを除外するリスト）との組み合わせも設定できるようにしています。技術的には Egress プロキシ側で動的にルール制御することでこの仕組みを実現しています。

外部通信は、AWS の Security Group によって必ずプロキシを経由するようにネットワークレベルで制御しています。

AI エージェントの能力を高めるほど、同時に実行環境や権限、通信経路の制御も重要になります。BUGMAP では、単に強いモデルを使うだけでなく、安全に検証できる環境をセットで作ることを重視しました。

チームとして得た学び

BUGMAP を作る中で一番大きかった学びは、AI エージェントの性能だけでなく、セキュリティ担当者の知見をどのように分解し再利用できる形にするか、が重要だということです。

診断担当者が普段の業務において、

• どの順番で情報を見ているのか

• どの観点で危険度を判断しているのか

• どの状態なら修正に進めるのか

これらを言語化していくことで、AI エージェントに任せられる部分と人が判断すべき部分が整理されていきました。

また、現場のエンジニアからのフィードバックを受けながら機能を揃えたことで、セキュリティチームのためだけのツールではなく、プロダクト開発の流れの中で使える仕組みに近づけることができました。セキュリティレビューを一部の専門家だけの作業に閉じず、組織全体で扱える形にしていくことが、今後ますます重要になると感じています。

まとめ

今回は、AI セキュリティエージェント「BUGMAP」の事例をご紹介させて頂きました。

私が CyberAgent で経験した 7, 8 年分のノウハウを全て詰め込んだというものに仕上がってきました。なので、正直もうこの会社に私は不要な状態にできた自負があります（別にネガティブな意味はありません）。

また、セキュリティエージェントを実装した立場からすると、Claude Mythos などの高性能な基盤モデルの登場は「怖さ」が半分、「楽しみ」も半分という感じです。

今後も技術の進歩を楽しみつつ、インターネットの平和を願っていますimage