静的解析の「誤検知」と「見逃し」を、AIエージェントが検出ルール自体を書き直して減らす。2026年8月21日にarXivで公開された査読前の研究「ARQ」は、コード解析基盤 CodeQL の公式クエリ12件をLLMに自動修正させ、真陽性の検出を最大119.8%増やしながら精度(Precision)98.0%以上を維持したと報告しています。修正後のクエリは libpng・zlib という「どこにでも入っている」ライブラリで未知のバグ2件も掘り当てました。
本記事では、この研究を手がかりに「スキャン結果のノイズはなぜ減らないのか」「検出ルールは誰が保守するのか」を実務目線で整理します。
※ARQはarXivで公開された査読前(プレプリント)の研究です。結果は今後の査読で変わりうる点に留意してください。
この記事でわかること
- CodeQLとは何か、自社ですでに動いている可能性と確認方法
- ARQが誤検知・見逃しをどう見つけ、どう直したのか
- 評価結果の数字と、その正しい読み方
- 情シスがスキャン結果・検出ルールとどう付き合うべきか
CodeQLとは何か？ 知らないうちに動いていることがある
CodeQLとは、ソースコードをデータベースのように問い合わせて脆弱性を探す、コード解析の言語とツール群です。公式ドキュメントも「コード解析のための言語とツールチェーン」と定義しています。脆弱な書き方を「クエリ」として記述し、ソースコードに突き合わせて一致箇所を報告する仕組みです。
使うのは主に開発チームですが、「うちは導入していない」と即断できないのがこの手のツールです。CodeQLはGitHubのコードスキャン機能の中核として提供されており、リポジトリ側で有効化されていれば、情シスが知らないうちにCI（自動ビルド）の一部として動いていることがあります。次の3点で該当判定できます。
.github/workflows/配下にcodeql.yml（またはCodeQLアクションを呼ぶワークフロー）があるか- リポジトリの「Security」タブ →「Code scanning」にアラートが溜まっていないか
- 開発端末に
codeqlコマンド（CodeQL CLI）が入っていないか
ここでアラートが何百件も放置されていたら、それが本記事の主題そのものです。
ARQは何をしたのか？ 実行結果を「正解」にした
ARQは、わざと作ったテストプログラムを実行し、その結果とクエリの判定がズレた箇所を弱点とみなして、LLMにクエリを書き直させる枠組みです。従来の改善手法は正解ラベル付きデータセットや修正コミット履歴を必要としましたが、ARQはそのどちらも、脆弱性ごとの専用テンプレートも使いません。
| 合成プログラムの実行結果 | クエリの判定 | 診断される弱点 |
|---|---|---|
| 本当に脆弱だった | 何も報告しない | 偽陰性(FN)＝見逃し |
| 安全だった | 脆弱だと報告する | 偽陽性(FP)＝誤検知 |
実務者向けに言い換えれば、ルールの正しさを人間のラベルではなくプログラムの挙動で裏取りするということです。検知ルールの保守が属人化しがちな現場には示唆的な発想です。
どこまで効いたのか（評価結果）
| 項目 | 内容 |
|---|---|
| 改善対象 | CodeQL公式クエリ 12件 |
| 使用したLLM | GPT-5.4 / Claude-Sonnet-4.6 / Gemini-3.5-flash |
| 評価データセット | Juliet v1.3、FormAI v2 |
| 真陽性の検出 | 最大119.8%増（元の約2.2倍に相当） |
| 精度(Precision) | 全体を通して98.0%以上を維持 |
| 公式リポジトリへの貢献 | 未解決のGitHub issue 3件を解消（最長27か月放置） |
| 実世界での成果 | libpng・zlibで未知のバグ2件を発見 |
「119.8%増」の読み方には注意が必要です。検出率が119.8%になったのではなく、検出できた真陽性の件数が最大で約2.2倍になったという意味であり、しかも「最大」＝上振れの値です。全クエリで一律にこの改善が出たわけではありません。
むしろ注目すべきはPrecisionを98%以上に保ったという条件です。見逃しを減らすだけなら、クエリを緩めて片っ端から報告させれば済みます。しかしそれをやると誤検知が爆発し、現場は結局アラートを見なくなる。「検出を増やしつつ精度を落とさない」という縛りこそが実務的な価値です。
評価データの性格も押さえておきましょう。Juliet v1.3 はNSA Center for Assured SoftwareがNIST経由で公開する合成テストスイート（64,099件のテストケース、118種のCWE）、FormAI v2 はLLMが生成した約33万件のCプログラムに形式検証で脆弱性ラベルを付けたデータセットです。つまり本研究にはAIが書いたコードを、AIが改善したルールで検査するという構図の評価が含まれます（関連：LLMで脆弱性の自動検証は可能か｜査読前研究）。
libpngとzlibは「うちにも入っている」
未知のバグが見つかった2つのライブラリは、資産管理台帳に載らないまま社内の至るところで動いている典型例です。zlibとはデータを可逆圧縮・展開する汎用ライブラリで、公式サイトは「zlibはlibpngの不可欠な一部」と明記しています。libpngとはPNG画像を読み書きするための「PNGの公式リファレンスライブラリ」（公式サイトの表現）です。PNGを開く処理やデータ圧縮がある製品には入り込む余地があります。
どの製品に同梱されているかは製品ごとに異なるため、推測で有名製品名を挙げることはしません。代わりに確認手段を示します。
- Windows：アプリのインストールフォルダに
zlib1.dll、libpng16-16.dllが同梱されていないか - Linux/Unix系：
ldd <実行ファイル>にlibz.so、libpng16.soが出ないか。rpm -q zlib libpng/dpkg -l | grep -E "zlib|libpng" - アプライアンス・複合機：ベンダーが公開する同梱OSSライセンス一覧に記載がないか
これは机上の話ではありません。2026年1月公開の CVE-2026-22184（zlib 1.3.1.2以前、CVSS v4で9.3）は、実体がコアではなく contrib 配下のサンプルユーティリティ untgz の問題でした。スコアの高さがそのまま自社リスクの高さを意味しない好例です（関連：脆弱性の優先度は組織で変わる｜査読前研究を解説）。なおARQが見つけたという2件については、執筆時点でCVE番号や詳細の公開を確認できていません。論文の記述にとどまる情報として扱ってください。
情シスの実務にどう効くのか
「C/C++の解析クエリなら開発部門の話だ」と読み飛ばすのは早計です。この研究が突いているのは検出ルールというものの普遍的な性質だからです。クエリ、シグネチャ、相関ルール——呼び方は違っても、すべては「書いた時点の想定」を固めたものにすぎません。コードの書き方も攻撃手法も変わるため、ルールは放置すれば静かに劣化します。公式のCodeQLクエリですら弱点を指摘するissueが27か月未解決だった事実は、SIEM/EDRの検知ルール保守にもそのまま通じます（関連：Sigma検知ルールの56%は改訂される｜研究解説）。
そしてスキャン結果が信用されなくなる原因の多くは、ツールの導入失敗ではなく誤検知の蓄積です。一度「どうせノイズ」と認識されると、本物の指摘まで一緒に無視されます。ARQが示すのは、この問題に「担当者が頑張って選別する」以外の打ち手がありうるということです。
現場目線の課題
率直な実感を書いておくと、この種の改善は自社で再現しようとすると途端に重くなります。検出ルールを自分たちで書き直せる組織はごく少数で、多くの情シスにとってスキャナのルールはベンダー提供のブラックボックスです。触れる範囲はせいぜい「この指摘を除外する」程度。しかも除外設定は積み上がると誰も理由を説明できなくなり、いつの間にか本物まで抑止していた、という事故が起きます。
もうひとつはLLMを回すコストと検証の手間です。生成された修正クエリをそのまま本番の検査に載せるわけにはいかず、誰かが妥当性を確認する必要がある。その「誰か」が慢性的に足りないのが実情です。自動化が進むほど、最終判断を引き受ける人の負荷はむしろ見えにくくなります（関連：AIエージェントで脆弱性対応はどこまで自動化できるか）。それでも本研究が「人手のラベル付けなしで回る」設計を選んだ点は現実的です。ラベル付けを前提にした改善策は、たいてい人員が確保できずに止まります。
限界と留意点
- 査読前の研究。数値や評価条件は今後変わりうるため、製品選定の根拠にはしない。
- 対象はC/C++のCodeQLクエリ12件。他言語・他ツールへ一般化できるかは判断できない。
- 評価に用いたJulietとFormAI v2はいずれも合成・生成されたコード。実プロダクトで同じ改善幅が出る保証はない。
- 「最大119.8%増」は平均的な改善幅ではない。
情シスはどうすべきか
自前で長大なチェックリストを作るより、公的機関の指針で足元を固めるほうが確実です。
- IPA「脆弱性対策情報」：JVN、CVE/CVSS/CWEなど標準の解説、オープンソースのセキュリティ情報が集約されたハブ。まずはここを起点に。
- IPAテクニカルウォッチ「脆弱性対策の効果的な進め方（ツール活用編）」：「使っているソフトを把握する→関連情報を集める→対応を判断する」流れを現実的な工数に落とす手順。libpng・zlibのようなコンポーネントの棚卸しに悩むなら出発点になります。
あわせて地道な働きかけも欠かせません。開発チームには「コードスキャンのアラートを放置しない」という運用ルールの合意を、利用部門には「見慣れないアラートを握り潰さず情シスに上げる」という啓発を。ツールの精度が上がっても、結果を受け取る人が動かなければ何も変わりません。
まとめ
- ARQは、合成プログラムの実行結果を「正解」としてCodeQLクエリの誤検知・見逃しを検出し、LLMに書き直させる査読前の研究。公式クエリ12件で真陽性が最大119.8%増、Precisionは98.0%以上を維持したと報告されている。
- 検出ルールは書いた時点から劣化が始まる。公式クエリでも27か月未解決のissueがあった事実は、SIEM/EDRの検知ルール保守にも通じる警告である。
- libpng・zlibのように台帳に載らないコンポーネントは、確認手段を決めておく。DLL名・共有ライブラリ名・同梱OSS一覧で該当判定し、IPAの脆弱性対策情報で継続的に追う。
出典
- Chunyi Wang, Yunfei Ke, Junfeng Yang, Yun-Yun Tsai, Penghui Li, “ARQ: Agentic CodeQL Query Refinement for C/C++ Vulnerability Detection”, arXiv:2608.20637（2026年8月21日投稿、査読前）
- CodeQL公式ドキュメント「About CodeQL」
- zlib公式サイト / libpng公式サイト
- NIST SARD「Juliet C/C++ 1.3」
- GitHub Advisory Database「GHSA-7687-3v4j-49fr（CVE-2026-22184、zlib）」
- IPA「脆弱性対策情報」
- IPAテクニカルウォッチ「脆弱性対策の効果的な進め方（ツール活用編）」
