2026年10月19日、Reutersは、1人の攻撃者がAIエージェントを利用し、100以上の企業Webサイトに侵入したとされる事例を報じました。侵入を試みたサイトは1,200以上にのぼり、標的には日本の電子商取引サイトも含まれていました。
AIエージェントは、調査結果に応じて次の操作を選び、脆弱性の探索や攻撃の試行を継続できます。
攻撃者がAIを使ってシステムの弱点を探せるようになった現在、防御側も同じ技術で、侵入される前に脆弱性を見つけて修正できるのでしょうか。
米国のDARPAが主催した競技では、AIシステムが脆弱性の発見から修正パッチの生成までを自動で実行しました。商用の自律型ペネトレーションテストに加え、ShannonやButtercupのようなオープンソースのシステムも公開されています。
自分が管理するWebアプリのソースコードと隔離した検証環境があれば、Shannonを利用して、攻撃の実証まで含む自動診断を自分でも実行できます。ソフトウェアは無料で、AIモデルの利用方法によって費用が異なります。
一方、ソースコードを使わず外側から検査する機能や、診断をまたいだ脆弱性の継続管理は、Shannonでは商用版で提供されています。
AIによる自動診断の能力は、脆弱性を見つける速さだけでは決まりません。候補が本当に危険なのかを確かめ、必要な修正を行い、その修正が有効か検証する工程までが関わっています。
AIによるサイバー攻撃の自動化と防御側の課題
AIを組み込んだ攻撃システムでは、対象の調査、脆弱性候補の探索、攻撃の試行を連続して実行できます。
Reutersが2026年10月19日に報じた事例では、攻撃者は9月25日から、米国、カナダ、オーストラリア、日本の電子商取引サイトを標的にしていました。
セキュリティ企業NorForgeの研究者Snorre Fagerland氏の調査によると、攻撃者はオープンソースのAIエージェント基盤「Cairn」を利用していたとされています。
報道では1,200以上のサイトへの侵入試行が確認され、100以上の企業サイトへの侵入が報告されました。侵入に成功した事例では、脆弱性の探索に通常23時間ほどかかっていたといいます。
Fagerland氏は、この攻撃で使われたAIのトークン費用を総額約5,000ドル、侵入成功1件あたり約50ドルと推定しています。
トークンとは、AIが文字列を処理する際の単位です。この費用は研究者による推定であり、攻撃者の作業時間や設備費まで含んだ総費用ではありません。
Reutersは、侵入によってどの程度のデータが持ち出されたのかについては確認できていないと伝えています。
出典：Reuters — How one hacker used AI agents and a few thousand dollars to break into scores of sites
日本でも警告されたアプリ解析からのサーバー攻撃
日本でも、公開されたソフトウェアを解析し、攻撃に利用できる情報を探す手法が問題になっています。
2026年10月13日、情報通信研究機構（NICT）は、公開されたAndroidアプリを解析し、その接続先サーバーを攻撃する「A2B攻撃」について注意喚起しました。
NICTの脅威情報分析チームLETTICEは、国内で相次ぐ情報漏えい事案の原因の一つとして、この手法を特定したと発表しています。
Androidアプリには、接続先やAPIの仕様など、サーバーとの通信に関係する情報が含まれる場合があります。攻撃者はアプリを解析し、得られた情報を使ってサーバーを調べます。
NICTは、AIによってアプリの解析や脆弱性の発見が効率化され、同様の攻撃がさらに多くのシステムへ広がる可能性に注意を促しています。
NICTの発表は今後の攻撃拡大への警告であり、国内の個別事件についてAIの使用を特定したものではありません。
翌14日には、国家サイバー統括室が、国内の不正アクセスによる情報漏えいを踏まえた関係機関の注意喚起をまとめて公表しました。
国内の情報漏えい事案とAIの関係については、関連記事「2026年、日本で情報漏えいが相次ぐ理由とAI攻撃の実態」でも、公表資料に基づいて整理しています。
出典：NICT — 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」
出典：国家サイバー統括室 — 不正アクセスによる漏えい等の事案を踏まえた各機関による注意喚起等について
AIによる攻撃の探索能力が高まるなか、防御側には、攻撃者より先に問題を発見し、実際の修正につなげる能力が求められています。
AIによる脆弱性の自動発見と修復
防御側でも、AIを使ってソースコードを解析し、脆弱性の候補を探し、修正パッチを生成する技術が開発されています。
従来から脆弱性の検査には、既知の問題との照合、ソースコードの静的解析、さまざまな入力を試すファジングなどが利用されてきました。
現在はLLMを組み合わせることで、検査する箇所の選定、異常の原因調査、修正コードの作成といった工程の自動化が進んでいます。
その能力を具体的に示したのが、米国国防高等研究計画局（DARPA）が主催した「AI Cyber Challenge（AIxCC）」です。
AI Cyber Challengeで確認された自動修復の成果
2025年8月、DARPAはAIxCCの決勝結果を発表しました。
参加チームは「Cyber Reasoning System（CRS）」と呼ばれる自律型システムを開発し、ソフトウェアの脆弱性を発見して修正する能力を競いました。
決勝参加システム全体では、競技用に設定された63件の人工的な脆弱性のうち、54件（約86％）を発見し、43件（約68％）を修正しました。
| 評価項目 | 結果 |
|---|---|
| 人工的な脆弱性 | 63件 |
| 発見された人工的な脆弱性 | 54件（約86％） |
| 修正された人工的な脆弱性 | 43件（約68％） |
| 新たに発見された実在の脆弱性 | 18件 |
| 実在の脆弱性に対して提出されたパッチ | 11件 |
| 解析されたソースコード | 5,400万行超 |
| 競技課題あたりの平均費用 | 約152ドル |
割合の分母はいずれも63件です。
18件の実在する脆弱性と、それに対する11件のパッチは別に集計されています。
これらは競技環境における参加システム全体の成果です。実際の企業システムで同じ割合や費用を達成できることを保証するものではありません。
出典：DARPA — AI Cyber Challenge決勝結果
Buttercupは発見した脆弱性をどう修正するのか
AIxCCで2位となったセキュリティ企業Trail of Bitsは、自律型の脆弱性発見・修復システム「Buttercup」をオープンソースで公開しています。
Buttercupでは、プログラムの異常を探索する処理と、その原因を調査して修正する処理を分担しています。
| 構成要素 | 主な役割 |
|---|---|
| Orchestrator | 各処理の実行管理 |
| Seed Generator | 検査に使う初期入力の生成 |
| Fuzzer | 入力を変化させて異常動作を探索 |
| Program Model | プログラム構造の解析支援 |
| Patcher | 修正パッチの生成と検証 |
Fuzzerは、多様な入力をプログラムへ与えてクラッシュなどの異常を探します。Patcherは、発見された問題に関連するコードや検証情報を使い、LLMによる修正案の生成とテストを行います。
生成したコードについては、ビルドや脆弱性を再現するための入力を用いた検証が実行されます。
公開READMEによると、Buttercupの対象はOSS-Fuzz（オープンソースソフトウェア向けのファジング基盤）に対応したCまたはJavaのリポジトリです。正常にビルドでき、ファジング用の検査プログラムが用意されているプロジェクトが対象になります。
このように、Buttercupは条件を満たすソフトウェアの脆弱性を探し、修正するシステムです。後述する実装上の不具合が示すように、検証工程にも固有の課題があります。
AIによるペネトレーションテストはどこまで実用化されたのか
ペネトレーションテストは、許可されたシステムに対して攻撃者が使う可能性のある手法を試し、侵入や権限の悪用が成立するかを調べる検査です。
AIによる自律型ペネトレーションテストでは、対象を調査し、脆弱性の候補を発見して、実際に悪用できるかを自動で確かめます。
商用ではXBOWがこうした技術を提供しており、オープンソースではShannonなどが公開されています。
商用サービスXBOWの自律型検査
XBOWは、複数のAIエージェントを組み合わせて脆弱性の探索と検証を実行する商用サービスです。
同社が2026年4月に公開した技術記事では、LLMによる長時間の調査や、攻撃成立の判定に伴う問題を補う設計が説明されています。
LLMはWebアプリの応答を解釈したり、攻撃用の入力を考えたりできます。しかし、複雑な調査を長時間継続すると、それまでの条件を正確に扱えなくなったり、十分な証拠がないまま攻撃が成功したと判断したりする場合があります。
XBOWでは調査を比較的短い工程へ分割し、探索や検証を担当するエージェントを組み合わせています。
発見された問題は検証エージェントが確認し、実際に悪用可能かを調べる構成です。
出典：XBOW — AI for Pentesting: Strengths, Weaknesses, and Where XBOW Fills the Gaps
オープンソースのShannonでできること
Keygraphが公開する「Shannon」は、WebアプリケーションとAPIを対象とする自律型ペネトレーションテストシステムです。
Shannonはソースコードの解析と、実際に動作しているWebアプリへの検査を組み合わせます。
脆弱性の候補を見つけた後には、攻撃を試みて成立するかを確認し、再現できた問題を証拠とともに報告します。
オープンソース版は、自分のコンピューターやサーバーで実行でき、GitHub ActionsやGitLab CI/CDを利用した開発工程にも組み込めます。
CI/CDとは、コード変更に応じてビルドやテストを自動実行する仕組みです。
AIが発見した脆弱性を、修正できる問題に変える技術
AIが短時間に大量の問題を見つけると、確認と修正の負担が開発側に集中する場合があります。
PostgreSQLとcurlでは、この負担がそれぞれ異なる形で表れました。
PostgreSQLとcurlで見えた、発見後の処理の負担
2026年10月9日、PostgreSQLの開発者Peter Eisentraut氏は、PostgreSQL 19から約8〜10件の重要機能が取り下げられた背景を説明しました。
同氏は、LLM（大規模言語モデル）を使ったコードレビューで多数の不具合が見つかったことを、新機能の取り下げが相次いだ原因の一つとして挙げています。
以前なら正式リリース後の数年間で少しずつ報告されていた不具合が、開発中に短期間で発見されるようになったといいます。
例えば、40件の不具合報告が一度に届いた場合、それぞれの修正が平均3行程度で済んでも、問題の再現、原因の確認、修正内容のレビューには個別の作業が発生します。
Eisentraut氏は、こうした検証負担に加え、設計上の問題やセキュリティ対応による開発者の時間不足など、複数の事情が機能取り下げに影響したと考えています。
コミュニティは修正のためにリリースを延期するより、問題のある機能を取り下げて日程を維持する方針を選びました。
今回の問題には一般的な不具合や設計上の問題も含まれており、すべてがセキュリティ脆弱性だったわけではありません。
出典：Peter Eisentraut — The reverts will continue until morale improves
一方、curlでは問題の発見数よりも、寄せられる報告の品質が課題になりました。
2026年1月26日、curlの主要開発者Daniel Stenberg氏は、同月31日でバグ報奨金制度を終了する経緯をブログで説明しました。
Stenberg氏によると、以前はセキュリティ報告の15％超が実際の脆弱性として認定されていましたが、2025年には5％未満に低下しました。
理由の一つが、AIを利用した低品質な報告の増加です。
根拠が不十分な報告でも、開発者は問題の有無を調査する必要があります。Stenberg氏は、報奨金という金銭的な動機が不正確な報告の増加に関係している可能性を指摘しています。また、報告を改善するための協力が得られないケースも問題として挙げています。
出典：Daniel Stenberg — The end of the curl bug-bounty
ところが同じcurlでは、AIを使った専門的な監査が脆弱性の修正につながっています。
2026年10月14日、Stenberg氏は、セキュリティ企業Aisleとの約1年間の協力によって、少なくとも35件のCVEの発見に貢献したと報告しました。
CVEとは、公表されたセキュリティ上の脆弱性を識別するための番号です。
そのうち2026年の監査で確認された24件は、curl 8.22.0で6件、8.23.0で18件が修正されています。
Aisleでは、AIが見つけた候補をソースコードや仕様と照合し、再現テストを作成し、影響範囲を調べます。その後、専門のセキュリティ研究者が報告を確認してcurl開発チームへ提出します。
curl側でも内容を確認し、脆弱性として認定するか、修正が必要かを判断します。Aisleのエンジニアは修正コードの提供にも協力しました。
低品質なAI生成報告とAisleによる専門的な監査は、報告者の動機や協力関係なども異なります。そのうえで、再現可能な証拠を添えて問題を報告し、修正までつなげる工程の価値が分かる対比です。
AIによる脆弱性発見が開発に与える影響については、関連記事「「脆弱性の黙示録」――ハッカー文化70年史とAIが変えるセキュリティ」でも扱っています。
出典：Daniel Stenberg — A curl audit by Aisle
出典：Aisle — One AISLE curl Audit Produced 24 CVEs. 18 Ship Today
AIが発見した脆弱性候補をどう整理するのか
AIエージェントが大量の脆弱性候補を発見すると、同じ問題が異なるURLや入力から何度も報告される場合があります。
Shannonには「Finding Reconciliation」という候補を統合・整理する工程があります。Webアプリの調査とソースコード解析から集まった候補をまとめ、重複を取り除いて後続の検証エージェントへ渡します。
商用のXBOWは、重複を判定する方法をより詳しく公開しています。
報告を「問題の性質」「再現手順」「発生場所」「影響」の4要素に分け、それぞれの文章の意味を数値化して比較します。
さらに、脆弱性の種類によって各要素の重みを変更します。
例えば、Webアプリ全体で詳細なエラー情報が表示される問題では、異なるURLで同じ原因の問題が発生する場合があります。
一方、XSS（クロスサイトスクリプティング）では、同じURLであっても、入力パラメーターごとに独立した脆弱性が存在することがあります。
XBOWは、CWEという脆弱性の分類に応じて比較の重みと判定基準を調整しています。
同社の公表結果では、運用環境での報告件数が約30％減少し、重複報告の約90％を除去できました。調整用のデータでは、人間の分析者による分類との一致度も約90％だったとしています。
どの報告を同じ脆弱性として扱うかは、修正対象を正しく整理するための技術的な判断です。
出典：XBOW — De-Duplicating Security Findings at Scale
AIが見つけた脆弱性は本当に悪用できるのか
候補の重複を整理した後には、その問題が実際に悪用できるかを確かめます。
例えば、ソースコードにSQLインジェクションの可能性がある処理を見つけても、外部からその処理へ到達できるか、攻撃に必要な条件がそろうかを確認する必要があります。
Shannonは候補をExploitation Agentsという検証エージェントへ渡し、動作しているWebアプリに対して攻撃を試みます。
実証できた問題は証拠付きのレポートとして出力され、実証できなかった候補は最終レポートから除外されます。
この設計では、実証できた問題に報告を絞り込めます。一方、再現条件が不足していたために実在する脆弱性を実証できなかった場合も、その候補は最終レポートに含まれません。これは公開された処理方法から考えられる限界です。
Shannonの公式文書は、LLMが生成したレポートには根拠の弱い記述や誤りが含まれ得るとして、人間による確認を求めています。
修正パッチの検証で起きたButtercupの不具合
脆弱性を発見して修正パッチを生成した後にも、検証の仕組み自体に問題が生じる場合があります。
2025年7月30日、Buttercupでは、生成したパッチの検証に関する問題がGitHubの不具合報告（Issue #208）として登録されました。
一部の64ビットARM環境では、MemorySanitizerやUndefinedBehaviorSanitizerと呼ばれる検査機能を使ったビルドが、修正パッチとは無関係に失敗する場合がありました。
当時のButtercupでは、検証用ビルドが一つでも失敗するとパッチを不合格と判断し、修正案の作り直しへ戻していました。
翌7月31日、修正提案（Pull Request #209）によって、この問題に対応する変更が加えられました。
変更内容は、AArch64という64ビットARM環境に限り、複数のビルドのうち少なくとも一つが成功していれば、パッチを直ちに不合格にせず、脆弱性を再現する入力を使ったテストへ進める例外処理です。
失敗したビルドが後続のテストで必要になれば、その段階で失敗として扱われます。それ以外の環境では、従来のビルド判定が維持されました。
出典：Buttercup Pull Request #209
この事例では、人間の開発者がビルド失敗の条件を調査し、特定の環境に限定した例外処理を実装しました。
AIが生成したパッチを自動でテストできても、テストに失敗した原因を正しく切り分けるには、検証システム側の設計や人間の判断が必要になる場合があります。
Shannonの無料版と商用版は何が違うのか
Shannonはオープンソース版と商用版で、検査方法や脆弱性管理の機能に違いがあります。
2026年10月20日時点の公式READMEには、次の区分が掲載されています。
| 版 | 提供形態 | 公開されている価格 |
|---|---|---|
| Shannon OSS | 自分の環境で実行するオープンソース版 | ソフトウェア無料。AIモデルの利用費用は選択した方式による |
| Keygraph Pro | Keygraphが運営するクラウド版 | アクティブ開発者1人あたり月50ドル |
| Keygraph Enterprise | 自社環境やエアギャップ環境に設置する版 | 個別見積もり |
エアギャップ環境とは、外部ネットワークから分離した環境です。
ProとEnterpriseでは、オープンソース版の機能に加え、ソースコードを使わず外側から検査するブラックボックス診断、依存関係や秘密情報の検査、複数回の診断をまたぐ脆弱性管理、修正用プルリクエストの生成と再テスト、JiraやSSOとの連携などが提供されています。
Keygraphには、米国の501(c)(3)非営利団体と、シードまたはプレシリーズA段階でアクティブ開発者が20人以下のスタートアップを対象に、Proを無料提供するCommunity Programもあります。
出典：KeygraphHQ — Shannon README「Editions」
依存関係の脆弱性検査や秘密情報の検出には、別の専用ツールもあります。商用版の特徴は、これらを一つの製品に統合し、検査履歴や修正状況まで管理できる点です。
Shannonの無料版を自分で使うには何が必要か
Shannonのオープンソース版は、Webアプリのソースコードと、攻撃を試すための検証環境を用意して実行します。
公式READMEでは、次の条件が案内されています。
- Docker： 検証処理を動かすコンテナの実行に必要
- Node.js 18以降：
npxによる起動に必要 - 検証対象： ソースコードを参照でき、動作中の開発・ステージング環境へ接続できること
- AIモデル： 対応プロバイダーの認証情報、またはローカルモデルへの接続
公式READMEのQuick Startでは、対話形式でセットアップする起動方法も公開されています。
npx @keygraph/shannon@latest検査は、自分が所有するか、明示的な許可を得たシステムだけを対象にします。
Shannonは実際に攻撃を試みるため、アカウント作成、フォーム送信、データ変更などが発生する場合があります。公式文書は、本番環境を避け、使い捨てのデータを用意した検証環境で実行するよう求めています。
また、信頼できないコードベースや敵対的なコードベースを診断しないよう注意しています。ソースコードを読むAIが、コード内に埋め込まれた不正な指示によるプロンプトインジェクションの影響を受け得るためです。
利用できるAIモデルと費用
ShannonはAnthropic、OpenAI、xAI、AWS Bedrockなどのモデル接続に対応しています。
Ollama、vLLM、LM Studioを使ったローカルモデルも選択できます。
2026年10月20日時点の公式READMEでは、OpenAI Codex経由でChatGPT Plus・Proのサブスクリプションを利用する方法と、xAIのサブスクリプションを利用する方法が案内されています。
Claude Codeのサブスクリプションについては、最新版では対応しておらず、対応する最終版は1.9.0とされています。
公式文書では、1回の診断時間の目安を約1〜1.5時間としています。対象アプリの規模や使用するモデルによって所要時間と費用は変わります。
APIを利用する場合は使用量に応じた費用がかかり、ローカルモデルの場合は推論用の計算資源を自分で用意します。モデルによって検査能力にも差があります。
初回実行前に確認したいAIプロバイダーの安全対策
Shannonの公式READMEは、AnthropicとOpenAIのモデルを使う場合の注意事項を掲載しています。
両社はサイバーセキュリティ関連の処理にリアルタイムの安全対策を適用しており、正当な検査目的でも、診断が途中で中断されたり、モデルが処理を拒否したりする可能性があります。
そのためREADMEは、初回の実行前に、各社が案内する正当なセキュリティ検査者向けの確認手続きやガイダンスを済ませるよう求めています。
AIモデルの接続設定が正しくても、こうした制限によって自動診断が完了しない場合があります。
出典：KeygraphHQ — Shannon公式README「Prerequisites」「Quick Start」
自分で実行する場合に残る作業
Shannonのオープンソース版では、攻撃が成立した候補を証拠付きで出力し、CI/CDで重大度に応じた判定を行う仕組みも利用できます。
一方、発見された問題の優先順位を決め、実際の修正を行い、運用環境へ反映する判断は利用者側に残ります。
ShannonはAGPL-3.0ライセンスで公開されています。改変したソフトウェアの再配布やネットワーク経由での提供などについては、ライセンス条件の確認が必要です。
検証環境の維持、モデルの設定、診断結果の確認も、自前で運用する場合に担当する作業です。
AI脆弱性診断を導入するとき、何を確認すべきか
AI脆弱性診断の導入方法は、検査対象と運用目的によって変わります。
自分たちで開発しているWebアプリやAPIのソースコードを持ち、隔離された検証環境を用意できるなら、Shannonのオープンソース版が選択肢になります。
ソースコードを持たない自社システムを外側から調べる場合は、ブラックボックス診断に対応したサービスが必要です。いずれの診断も、自分が所有するか、明示的な許可を得たシステムだけが対象です。
診断履歴の一元管理や、修正用プルリクエストの生成、再テストまで継続して行いたい場合には、商用版の機能が検討対象になります。
AIによるWebアプリのペネトレーションテストは、OSやネットワーク構成を含むすべてのセキュリティ検査を代替するものではありません。
Linuxの認証設定、SSH、ファイアウォール、クラウドのアクセス権限などについては、対応する別の検査方法が必要です。
AIセキュリティ製品を選ぶ際の確認項目
| 評価対象 | 確認したい内容 |
|---|---|
| 探索範囲 | Webアプリ、API、ソースコード、OS設定のどこまで検査するか |
| 重複排除 | 同じ原因の報告をどう統合するか |
| 攻撃実証 | 何を証拠として攻撃の成立を認定するか |
| 見逃し | 実証できなかった候補を保存するか、除外するか |
| 修正 | パッチの生成と修正後の検証に対応するか |
| 継続管理 | 診断をまたいで脆弱性の状態を追跡できるか |
| 権限制御 | 検査対象外へのアクセスやデータ変更をどう防ぐか |
ソースコードと検証環境があるなら、まずShannonの無料版で自分たちのアプリを診断し、どの程度の問題が実証できるか、結果の確認にどれだけ手間がかかるかを評価できます。
その結果から、商用サービスへ任せる必要がある工程を判断する方法が現実的です。
FAQ
AI脆弱性診断は無料で利用できますか？
Shannonなど、無料で入手できるオープンソースの実装があります。AIモデルの利用費用や検証環境の運用費用は、選択する構成によって異なります。
ソースコードがなくてもAIで脆弱性診断できますか？
ブラックボックス診断に対応したサービスを利用する方法があります。Shannonのオープンソース版は、ソースコードを参照できるWebアプリやAPIを対象とする設計です。診断対象は、自分が所有するか、明示的な許可を得たシステムに限定する必要があります。
AIが見つけた脆弱性は自動で修正できますか？
Buttercupのように修正パッチを生成・検証する技術が公開されています。対象となるプログラムや検証条件には制約があり、実際のシステムへの適用には確認が必要です。
参考・参照元
- Reuters — How one hacker used AI agents and a few thousand dollars to break into scores of sites
- 国家サイバー統括室 — 不正アクセスによる漏えい等の事案を踏まえた各機関による注意喚起等について
- NICT — 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」
- DARPA — AI Cyber Challenge決勝結果
- Peter Eisentraut — The reverts will continue until morale improves
- Daniel Stenberg — The end of the curl bug-bounty
- Daniel Stenberg — A curl audit by Aisle
- Aisle — One AISLE curl Audit Produced 24 CVEs. 18 Ship Today
- Trail of Bits — Buttercup
- Buttercup Issue #208
- Buttercup Pull Request #209
- XBOW — AI for Pentesting: Strengths, Weaknesses, and Where XBOW Fills the Gaps
- XBOW — De-Duplicating Security Findings at Scale
- KeygraphHQ — Shannon
