静的解析ツールが挙げた大量の「脆弱性かもしれない箇所」を、LLMに実際に動かして確かめさせる——そんな自動化が現実になるかを検証した査読前研究が、2026年8月13日にarXivで公開されました。結論は率直です。予算の範囲内で、動的に実証できた脆弱性は1件もありませんでした。しかも失敗の原因は、LLMのコード生成能力でもファジングでもなく、「テストコードを対象ソフトのビルドに組み込む」という地味な工程でした。
AIによる脆弱性検証の自動化を売り込まれている情シスにとって、この「うまくいかなかった報告」は期待値を現実に合わせる材料になります。
この記事でわかること
- 研究が何を試し、何が起きたのか（数字で把握）
- LLMによる脆弱性の動的検証がどこでつまずくのか
- 「クラッシュを37件検出」をどう読み解くべきか
- AIセキュリティツールを評価するときの確認ポイント
どんな研究か（1文要約）
オープンソースの自動運転ソフトウェア基盤「Autoware」を対象に、静的解析で見つけた到達可能な弱点候補について、LLMに実行可能なテストコード（ハーネス）を自動生成させ、実際にビルド・実行して悪用可能性を確かめられるかを検証した研究です（arXiv:2608.13450、Md Wasiul Haque氏ら4名）。査読前のプレプリントである点にご注意ください。
Autowareとは何か
Autowareとは、自動運転車に必要な認識・自己位置推定・経路計画・車両制御の機能一式を提供するオープンソースのソフトウェア基盤です。ロボット向けミドルウェアのROS 2の上に構築され、Autoware Foundationが開発を統括しています。もとは2015年に名古屋大学で始まった日本発のプロジェクトで、同財団は20か国・約500社が関与していると説明しています。
もっとも、この研究で重要なのはAutowareという製品そのものよりも、「185パッケージからなる巨大な実在のソフトウェア群」という題材の性質です。ここで起きた問題は、規模の大きい業務システムや組込みソフトを抱える組織にもそのまま当てはまります。
何をして、何が起きたのか
研究チームはまず185パッケージに静的解析をかけ、判断ロジック1,375件、入力検証チェック2,274件、外部入力から安全に関わる出力へ至るデータフロー482件を洗い出したうえで、到達可能な箇所740件をサンプリングしました。
次に、ローカル環境で動く重み公開型のLLM2種類に、静的解析の文脈を与えない条件と単純なテンプレートを加えて比較し、合計3,700組のテストコードを生成させます。生成物は実際のビルドに対してサニタイザ付きでコンパイルし、失敗すればコンパイラの出力をLLMに返して修正させ（コンパイラ・イン・ザ・ループ）、動くようになったものをファジングにかけました。
| 観点 | 結果 |
|---|---|
| 解析対象 | 185パッケージ／到達可能な弱点候補740件をサンプリング |
| 生成したテストコード | 3,700組 |
| 一発でコンパイルが通った割合 | 推論特化モデル 64%／コード特化モデル 6% |
| 初回コンパイル失敗の内訳 | 80%が依存関係の結線に起因（プログラムのロジックではない） |
| ファジングまで到達した割合 | 推論特化モデルでも半数未満 |
| 観測されたクラッシュ | 37件。すべてスタブ（差し替えた仮実装）側で発生 |
| 動的に実証された脆弱性 | 0件（予算の範囲内） |
なぜ「ビルド統合」が壁になるのか
テストコードは単体では動かないからです。対象の関数を呼び出すには、依存するヘッダ、ライブラリ、ビルド設定、初期化済みのオブジェクト、実行時の設定ファイルまで揃えて、実際のビルドシステムに正しくつなぎ込む必要があります。LLMはコードの中身をもっともらしく書けても、この「配線」は対象リポジトリ固有の事情に依存するため、生成物が現実のビルドに乗りません。「初回コンパイル失敗の80%は依存関係の結線が原因で、ロジックの誤りではない」という内訳が、この構図を端的に表しています。
興味深いのは、推論特化モデルが64%、コード特化モデルが6%と、一発成功率に10倍以上の開きが出た点です。「コードを書くのが得意なモデル」が有利とは限らず、ビルド環境という文脈全体を推論して辻褄を合わせる能力のほうが効いたと読めます。ただし重み公開型モデル同士の比較であり、商用の大規模モデルに一般化はできません。
「クラッシュ37件」を鵜呑みにしてはいけない理由
クラッシュした場所が、調べたかったソフトウェアの中ではなかったからです。研究チームはコンパイルを通すために依存部分を大量のスタブ（中身のない仮実装）に置き換えており、観測された37件のクラッシュはすべてそのスタブ側で発生しました。Autoware本体の欠陥ではありません。
ここはAI検証ツールを評価するうえで最も注意すべき点です。「AIが自動でN件の脆弱性を検出しました」という報告は、件数よりも「どこで起きたのか」「実際の製品構成で再現するのか」を確かめないと意味を持ちません。テスト用に差し替えた足場が壊れているだけなら自社のリスクではなく、それを鵜呑みにして開発部門に修正依頼を投げれば、信頼を失うのは情シスの側です。
情シスの実務に何を示すか
この研究は自動運転ソフトを題材にしていますが、示唆はもっと広く効きます。
- 静的解析の「候補」は依然として人間の判断待ち。大量の指摘から、本当に攻撃者が到達でき悪用可能なものを機械的に絞り込む工程は、まだ自動化しきれていません。アラートの洪水に優先順位を付ける運用の問題は、AI導入では消えません。
- AI活用の前提条件は「ビルドと実行環境の再現性」。裏を返せば、CIでビルドが一発で通り、依存関係が整理され、テスト環境をコマンド一つで立てられる組織ほど恩恵を受けやすいということです。
- ベンダー評価の観点が一つ増える。「AIが自動でPoC（実証コード）を作って検証します」という提案には、対象コードのビルドをどう再現するのか、検出したクラッシュが対象製品由来かをどう判定しているのかを聞いてください。
現場目線の所感
正直なところ、この結果には既視感があります。スキャナを入れたはいいものの数千件のアラートを前に手が止まり、結局「Criticalだけ」といった雑な線引きで運用せざるを得なかった——そんな経験を持つ担当者は少なくないはずです。AIが選別を肩代わりしてくれるなら大歓迎ですが、少なくとも「実際に動かして確かめる」段階の自動化はまだ研究途上のようです。
もう一つ身につまされるのは「壁になったのが賢さではなく段取りだった」点です。ビルドが通らない、依存関係が絡まっている、環境をもう一度作れない——現場が日々つまずいているのとまったく同じ場所で、LLMもつまずいています。派手なAI投資より先に、資産管理とビルド環境の整理という地味な仕事のほうが効くのだとしたら、それはそれで筋は通っていると感じます。
情シスはどうすべきか
自前で長大なチェックリストを作る前に、公的機関がまとめた指針を土台にするのが近道です。
- IPA「脆弱性対策情報」：JVN／JVN iPediaへの入口に加え、CVE・CVSS・CWEといった標準やファジングの技術資料までまとまっています。ツールの出力を読み解く共通言語を揃えるのに向きます。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：限られた人員で何から手を付けるかの優先順位付けに使えます。
- 開発部門を持つ組織なら、AIツールの導入検討と並行してソフトウェア構成情報（SBOM）の整備とビルドの再現性確保を進めるほうが、結果的にAI活用の効果も上がります。
あわせて、開発・利用部門への地道な説明も欠かせません。「AIが検出したから直してほしい」ではなく、なぜその指摘が自社に効くのかを語れる状態にしておくことが、依頼を通す近道になります。
限界と留意点
- 査読前のプレプリントであり、結果や解釈は今後変わりうる。対象もAutowareという単一の基盤に限られる。
- 使用したのはローカルで動く重み公開型モデル2種。商用の大規模モデルや、ビルド環境を操作できるエージェント型の手法では結果が異なる可能性がある。
- 「予算内で実証0件」は計算資源・時間の制約下での結果であり、原理的に不可能だと示したものではない。
関連記事
- 脆弱性スキャナーで結果が食い違う理由｜査読前研究を解説
- AIが書いたコードを誰が検証するか──情シスが直視すべき現実
- AIエージェントの正解は証拠にならない｜研究解説
- AI生成コードの脆弱性は連鎖する 査読前研究の指摘
まとめ
- 静的解析が挙げた脆弱性候補をLLMに実証させる試みで、予算内に動的確認できたものは0件だった（査読前研究）。
- 壁は生成能力ではなくビルド統合。初回コンパイル失敗の80%は依存関係の結線が原因で、観測されたクラッシュ37件はすべてスタブ側だった。
- 情シスの実務的な含意は、「AI導入より先にビルド・依存関係・資産管理の再現性を整えること」、そして「AIの検出報告は件数でなく発生箇所で評価すること」。
