脆弱性診断

何が起きたのか パスワード管理の1Passwordが2026年に新設した社内セキュリティ研究チーム Off-by-1 Labs が、2026年8月6日に最初の研究成果『Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D.』を公開しました（1Password公式ブログ 2026-08-06）。F.L.A.W.E.D. は Fix-Like Artifacts With Embedded Defects の頭字語で、著者は Axel Mierczuk、Spencer Michaels、Keith Hoodlet の3氏です（レポートPDF 表紙）。 実験の骨格はこうです。2026年3月26日〜5月12日に公開された6件の高深刻度の脆弱性（うち1件は CVE 番号が採られておらず GHSA-wpqr-6v78-jr5g。レポート自身は表1でこの6件を「six CVEs」と総称しています）を対象に、OpenAI の ChatGPT 5.5（Trusted Access for Cyber ガードレール、effort は medium）と Anthropic の Claude Opus 4.8（Cyber Verification Program ガードレール、effort は high）へパッチ生成を依頼します。1脆弱性・1モデルあたり540試行。生成されたパッチは5段階（S1〜S5）に分類されました。集計対象は6,080件で、全ての悪用可能パスを塞ぎ、脆弱性と無関係な挙動を変えなかった（または上流の正規パッチと同一の変化に留めた）S1 は26.0%です（PDF 表7）。この26.0%は6,080件の単純な件数比ではありません。脆弱性6件それぞれの率を等重みで平均し、さらに2モデルを等重みで平均した値です（公式の集計スクリプト仕様 GENERATE_RESULTS_TABLES.md）。件数比になっているのは1モデル・1脆弱性のセル内部だけです。 ただしこの26.0%という数字、そして1Password公式ブログが前面に出した53.9%という数字は、いずれも「何を分母にし、何を成功と呼ぶか」で意味が変わります。報道各社の見出しは53.9%をそのまま使わず、「4本に3本」（Help Net Security 2026-08-06）、「半分」（Dark Reading）、「半分超」（CyberScoop）などに言い換えられています。PDF本体には、ブログ記事には載っていない分母の作り方が書かれています。 6,480件生成して、6,080件で数えている 540という数字は $3 \times 9 \times 20$ の積です。パッチャーの動作モードが3種類（oneshot / iterative / exploratory、PDF 2.4節）、プロンプトテンプレートが9種類（PDF 2.5節）あります。1組み合わせあたりの反復回数はPDF本文には書かれていませんが、表26・表27の脚注が「1モードあたり180件」としているため、テンプレートあたり20反復と逆算できます（レポートPDF）。したがって総生成数は6 CVE × 2モデル × 540 = 6,480件になります。 ...

2026年2月、AIによるセキュリティ監査の歴史を塗り替える出来事がありました。AnthropicのAIモデル（Claude）が、世界で最も厳格にテストされているオープンソースプロジェクトの一つである「Firefox」から、わずか2週間で22件の未知の脆弱性を発見したのです。 本記事では、この衝撃的な事例の背後にある技術的な仕組みと限界、そして皆さんの開発現場にLLMによるコードレビューをどう組み込むべきかを解説します。 1. 22件の脆弱性発見が意味する「AIの目」の進化 112件の報告から22件のCVE、14件が高深刻度 AnthropicのチームはMozillaに合計112件のレポートを提出し、そのうち22件がMozillaによって「セキュリティ上重要なバグ」として正式にCVEに登録されました。残る90件はセキュリティとは無関係な一般的なバグで、そのほとんどもすでに修正済みです。22件のCVEのうち、14件はMozillaのエンジニアによって「高嚴重度（High Severity）」と分類され、Firefox 148.0で修正されました。 JavaScriptエンジンに潜む「Use After Free」の発見 最も注目すべきは、ClaudeがFirefoxの心臓部であるJavaScriptエンジン（SpiderMonkey）に焦点を当てた点です。わずか20分の分析で、AIは「Use After Free（UAF）」というメモリ脆弱性を発見しました。 Use After Free（UAF）とは： メモリ領域を解放（Free）した後も、そのアドレスを指すポインタを使用（Use）し続けてしまうバグ。攻撃者がこの解放済みメモリに悪意のあるデータを書き込むことで、任意のコード実行やクラッシュを引き起こす可能性のある、極めて危険な脆弱性です。 何百万行にも及ぶ複雑なC++コードの中から、人間の目視では追いきれない動的なメモリ管理の破綻をAIが「パターン」として見抜き、指摘したのです。 2. LLMによるコードレビューはどのように行われたか？ 過去のCVEデータによる「脆弱性の文脈理解」 Anthropicは、モデルに過去のCVE（共通脆弱性識別子）データやセキュリティレポートを深く学習させています。これにより、モデルは単なる「文法エラー」ではなく、「構造的にリスクを生みやすいコードパターン」を理解しています。 並列処理による力技：大規模コードベースのスキャン 数百万行のコードを人間がすべて読むのは不可能ですが、LLMは並列処理によりこれを解決します。Firefoxの膨大なC++コードをモジュール単位に分割し、複数のClaude Opus 4.6インスタンスで同時並行でスキャンを行いました。 全体の処理時間は、単純化すると以下のような数式で表される並列化の恩恵を受けます。 $$ \text{処理時間} \approx \left( \frac{\text{総ファイル数}}{\text{並列インスタンス数}} \right) \times \text{1ファイルあたりの平均処理時間} $$このアプローチにより、人間なら数ヶ月かかるコード監査が、わずか2週間で完了しました。 3. AIの限界：バグは見つけても「攻撃」はできない しかし、AIは万能ではありません。この実験で明らかになった最大の限界は、「脆弱性の発見」と「攻撃の実証」の間の巨大な壁です。 成功率わずか9%：PoC（概念実証）生成の難しさ Claudeが発見した22件の脆弱性について、実際に悪用可能であることを証明する「PoC（Proof of Concept）コード」をAI自身に書かせようと試みました。 約4,000ドル分のAPIコストを費やして大量のプロンプトを試行したものの、実際に機能するPoCを生成できたのはたったの2件（成功率約9%）でした。 しかも、成功した2件のPoCは「モダンブラウザのセキュリティ機能（サンドボックス等）を意図的に無効化したテスト環境」でのみ動作するものであり、実際の攻撃環境で機能する「フルチェーンのエクスプロイト」の構築には至っていません。 Use After Freeのようなバグを実際に突くには、OSのメモリレイアウトやガベージコレクションの絶妙なタイミングなど、静的なコード解析だけでは分からない「動的な実行環境の深い理解」が必要です。 AIは「ここがおかしい」というフラグを立てる（発見者）には極めて優秀ですが、それを「どう悪用するか（エクスプロイト）」の構築には、依然として人間のホワイトハッカーの高度な専門知識が不可欠なのです。 4. 現場でLLMコードレビューを導入するための戦略 このAnthropicとMozillaの事例を踏まえ、一般の企業や開発チームがLLMをコードレビューに導入するための実践的なアプローチを紹介します。 戦略①：人間とAIのハイブリッド体制（トリアージ） AIの報告には必ず「偽陽性（False Positive：誤報）」が含まれます。AIを「最初のフィルタリング役（一次審査）」とし、そのレポートを人間のシニアエンジニアが確認（トリアージ）してバグチケットを切る、というパイプラインが現在最も実用的です。 戦略②：クラウドAPI vs ローカルLLM AnthropicのClaude Opus 4.6などのクラウドAPIは最高精度を誇りますが（今回の実験もOpus 4.6を使用）、機密性の高い自社のソースコードを外部に送信できない企業も多いでしょう。 プライバシー重視のローカルLLM構築 外部APIが使えない場合は、Ollama や vLLM などの推論エンジンを用いて、社内のGPUサーバー上でオープンソースモデル（Llama 3やQwenなど）を動かす選択肢が現実的です。 ...