何が起きたのか

パスワード管理の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件になります。

一方、集計テーブルの Total Valid Iterations は Claude 3,001件・ChatGPT 3,079件の計6,080件です（PDF 表7）。差し引き400件は「チート」として除外されています。ここでいうチートは技術的な用語で、パッチャーが上流の公式修正コミットを検索・取得して写した疑いのある試行を指します。専用の監査エージェントがトランスクリプトを読み、curl での差分取得、CVE番号の検索、git show による上流コミットの閲覧、アドバイザリのミラー閲覧などを検出します（PDF 2.9節）。

除外率は脆弱性ごとに大きく偏っています。ただし、そのチート率の分母は有効試行の分母とは別物です。監査が走るのは iterative と exploratory の2モードだけで、oneshot は対象外です（表2で N/A）。したがって1脆弱性・1モデルあたりの監査対象は540試行のうち360試行で、表7・表8のチート率はこの360件に対するフラグ率です。フラグは cheated と suspicious の合計で、集計から実際に除外されるのは cheated だけです。

Linux の Copy Fail（CVE-2026-31431）では Claude のチート率が46.4%（PDF 表8）、件数にすると360件中167件がフラグ対象です。うち実際に除外されたのは157件で、有効試行は540件から383件に減りました。全体では監査対象4,320件に対してフラグが468件（10.8%）、集計から外れた cheated が6,480件中400件（6.2%）です。10.8% と 6.2% は分母も分子も違う数字で、矛盾はしていません。なお、除外率が脆弱性ごとに偏る原因はレポートでは分析されていません。

S1〜S5：どこで線を引くかで数字が倍近く動く

分類の定義はこうです（PDF 2.6.1節）。

区分定義平均
S1全ての悪用可能パスを塞ぎ、無関係な挙動も変わらない（または上流の正規パッチと同一の変化に留まる）26.0%
S2全て塞いだが、アプリケーションの挙動が変わった20.1%
S3悪用可能パスが残る（新規脆弱性はなし）49.3%
S4元の脆弱性は塞いだが、新しい脆弱性を作った2.3%
S5塞げず、かつ新しい脆弱性を作った2.2%

ここで注意が要るのは、レポート後半の分析表で使われる Fix-Success Rate が S1 でも S1+S2 でもないことです。Fail-To-Fix Rate が S3+S5 と明記されている（PDF 表7）ため、その補数である Fix-Success は

$$\text{Fix-Success} = S_1 + S_2 + S_4 = 26.0 + 20.1 + 2.3 = 48.4\ [\%]$$

となります。表7の Fail-To-Fix Rate 51.5% の補数は48.5%で、この48.4%とは0.1ポイントずれますが、各区分の丸めた値を足しているためです。つまりプロンプト条件別の分析で出てくる「約48%が成功」には、新しい脆弱性を混入させた S4 が含まれています。厳しく取れば26.0%、緩く取れば48.4%。同じデータセットから2倍近い開きの数字が出せてしまうので、要約を引用するときは定義を確認する必要があります。

レポート自身は5.1節で厳しい側の解釈を採っており、フロンティアLLMが自律的にパッチを書いたとき成功するのは「おおよそ4回に1回」、そして「完全にLLMが生成し人間のレビューを経ないパッチの期待値は、かなりの差でネットマイナスである」と書いています。

間違った助言は、助言なしより悪い

実務に一番効くのは、プロンプトが渡す修正方針の正しさで結果が割れた点です（PDF 表12、4.1節）。

  • 正しい修正方針を与えた場合：Fix-Success 65.0%、Fail-To-Fix 35.0%
  • 修正方針を与えなかった場合：Fix-Success 50.4%、Fail-To-Fix 49.6%
  • もっともらしいが誤った修正方針を与えた場合：Fix-Success 15.2%、Fail-To-Fix 84.8%

情報を増やすこと自体の効き幅より、方針の正誤の効き幅のほうが大きい、というのがレポートの整理です。5.2節では、修正方針の正誤に起因する差が49.8ポイント、プロンプトの情報量（richness）に起因する差が24.5ポイントだと明示しています。richness $R$ は6つの順序尺度の和で定義され、0から21までの値をとります。

$$R = r_{\text{class}} + r_{\text{loc}} + r_{\text{fix}} + r_{\text{impact}} + r_{\text{trig}} + r_{\text{scope}}$$

$R=0$（バグ分類も場所も何も渡さない、セキュリティとすら言わない開発者の雑談）で51.8%、$R=21$（CWE・正確なファイル行・修正API・影響・再現手順・スコープを全部渡す）で76.3%（PDF 表11）。richness を上げる価値はありますが、誤った方針の15.2%はそのどちらよりはるかに低い水準です。

4.1節には、この挙動の質的な観察も書かれています。誤った方針を与えたプロンプトでは、エージェント自身のツール実行結果がその方針を否定していても、モデルは目の前の証拠より指示への従順さを最適化する傾向が見られた、というものです。対話セッションならモデルがユーザーを訂正することもあるが、非対話のパッチャー実行ではそれが起きにくかったと説明されています。

SAST ツールの自動修正提案やバグバウンティ報告の推測を、検証せずそのままパッチャーへ流すワークフローには直接刺さる観察です。レポートは5.4節で、バグハンターとパッチャーの間に人間の検証を挟まない全自動パイプラインについて「これは特に見通しが悪い」と述べています。

『直った』の37.5%は fragile、採点者は36.8%で食い違う

S1/S2 と判定されたパッチには、追加で fragile フラグが付きます。悪用を直ちに不可能にはしたが、脆弱なコード自体は別経路から到達しうる形で残っている、という状態です（PDF 2.6.1節）。成功扱いの2,694件のうち1,010件、37.5%が fragile でした（PDF 表19、この表は自己検証スコアのみを使った集計）。公式ブログは同じ論点を「33%超」と書いています。

採点そのものの揺れも小さくありません。各パッチは生成したモデル自身と、もう一方のモデルの両方が採点し、レポートが結果として報告する数値はこの2者の二次判定を等重みで平均したものです。両者の S 判定が食い違った割合は、ペア比較できた6,077件のプールで36.8%でした（PDF 表20）。しかも食い違いはほぼ一方向で、向きは採点側が誰かで決まります。Claude が生成したパッチを ChatGPT が採点すると、「修正済み」を「未修正」へ覆すのが17.3%、逆に「未修正」を「修正済み」へ動かすのは0.8%。ChatGPT が生成したパッチを Claude が採点すると向きが反転し、「未修正」を「修正済み」へ覆すのが25.8%、逆向きは0.3%です（PDF 表20）。検証者としての Claude は S1+S2 を57.4%と付け、ChatGPT は36.5%と付けます（PDF 表22）。誰が採点したかで20ポイント動く、ということです。

著者らは10%以上のパッチを人手でレビューし、その結果を反映した二次検証ステップを入れています。それでも自己検証側の二次判定が人手レビューと S1〜S5 の等級まで一致したのは1,052件中693件、65.9%でした（PDF 表24、この表も自己検証スコアのみを使った集計）。「元のバグが直ったか」という二値判断に絞れば87.7%まで上がります。

Copy Fail：人間が踏んだ地雷を、生成パッチの約3分の1が踏み直した

もっとも具体的な失敗例が Linux カーネルの Copy Fail（CVE-2026-31431）です。上流の修正コミット a664bf3d は元のクロスマッピング破壊を塞ぎましたが、その過程で自ら off-by-one を作り込み、メンテナが1コミット後の 31d00156 で修正し直しています。

Off-by-1 Labs が候補パッチを構造比較したところ、非チートの ChatGPT 5.5 パッチ400件中129件（32.2%）、Claude パッチ383件中119件（31.1%）が、この a664bf3d と同じ off-by-one を再現していました（PDF 表25）。しかもこの回帰は自動評価にほぼ映りませんでした。再現スクリプトは検出せず、検証者が新規脆弱性として認識したのは ChatGPT 側14件・Claude 側10件だけです。比較の基準にした上流パッチ自体が欠陥入りだったため、同じ欠陥を持つ候補は「上流と等価」と採点されたわけです。

さらに4.5節では、同じ authencesn の復号パスに 5db6ef98 で塞がれた別の境界外書き込みが残っていた点を挙げ、非チートの783試行すべてがこのガードを入れなかったと報告しています。示された脆弱性と与えられたテストには対応するが、いま書き換えている関数の安全性そのものには対応しない、という切り分けです。続く4.6節「Tunnel vision」は、この種の狭い成功シグナルへの最適化を reward hacking の一形態と位置づけています（レポートPDF）。

1試行2.46ドル、S1一本あたり6.74ドル

コストは per-stage のトークン集計から出されています。6,080件の非チート試行について、パッチ生成（patcher）と自己検証（validator）の2段階を合計した額が、Claude Opus 4.8 で8,436.60ドル（1試行あたり2.81ドル）、ChatGPT 5.5 で6,493.96ドル（同2.11ドル）、平均2.46ドルです（チート監査エージェントのコストは除外、PDF 表14）。生成のみに絞った1試行あたりは平均1.42ドル（Claude 1.65ドル／ChatGPT 1.19ドル）です。Claude 側はプロバイダの請求実績、ChatGPT 側はトークン数と定価からの計算値と注記されています。

失敗分を成功分に按分すると単価は跳ね上がります。生成コストだけを S1 の本数で割ると平均6.74ドル、S1+S2 で割ると3.19ドル（PDF 表15）。この表は検証と監査のコストを除外しているので、実運用で検証を回すなら実効単価はさらに上がります。CVE 別では Gemini CLI が平均4.40ドルと最も高く、もっとも低いのは Chromium（CVE-2026-8512）の1.55ドル、次いで ActiveMQ（CVE-2026-34197）の1.71ドルでした（PDF 表16）。

CVEごとの成否の散らばりも極端です。Claude の S1 率は Exim（CVE-2026-45185）で75.8%に達する一方、Gemini CLI の信頼モデル不具合（GHSA-wpqr-6v78-jr5g）では0.9%、ActiveMQ（CVE-2026-34197）では3.3%です（PDF 表8）。4.2節は、モデルの違いよりバグとコードベースの性質のほうが結果を大きく左右するように見えると述べ、導入を検討するなら自社コードベースで過去に人手修正済みのCVEを使って基準値を測ることを勧めています。

残された不確実性

  • 判定の大半はLLMによるものです。 著者自身が2.10節で、規模の都合上ほとんどの試行でLLM検証に依存したと認めています。人手レビューは10%以上のサンプル、二次検証は gpt-mini による散文の再評価であり、等級一致率は65.9%です。
  • 対象CVEは意図的に難しいものが選ばれています。 高深刻度・高複雑度・複数コードパスという条件で選定されているため、2.10節は「現実の脆弱性全体と比べて平均より修正が難しい」と明記しています。この数字を一般的なバグ修正の成功率として読むことはできません。
  • モデルの effort 設定が揃っていません。 ChatGPT 5.5 は medium、Opus 4.8 は high で実行されています（PDF 2.3節）。2.1節はそもそもこの研究がモデル間の優劣比較ではないと明言しており、モデル別の数値差をそのまま能力差として読むのは避けるべきです。
  • 時点のスナップショットです。 研究開始は2026年5月20日、対象CVEの公開は2026年3月26日〜5月12日。モデルやAPIの挙動が変われば同じテストでも結果は変わる、と2.10節が断っています。

まとめ

このレポートを一行で要約すると数字が壊れます。26.0%は「全ての悪用パスを塞ぎ、無関係な挙動は変えない（変わっても上流の正規パッチと同一の変化に留まる）」という最も厳しい基準の値で、後半の分析表に出てくる約48%は新規脆弱性を作ったケース（S4）を含む緩い基準の値です。53.9%という数字は26.0%と20.1%の残余であり、その内訳の大半（49.3%）は「直っていないが新しい穴も開けていない」ケースです。

実務に落とすなら、レポートから直接読める受け入れ基準は3つあります。第一に、検証していない修正方針をパッチャーに渡さないこと。正しい方針65.0%に対して誤った方針15.2%、方針なし50.4%という並びは、不確かなヒントが害になることを示しています。第二に、再現スクリプトが通ったことを完了条件にしないこと。Copy Fail では約3分の1の候補が自動評価に映らない回帰を再現し、Chromium の use-after-free では参照カウント化を採用したパッチの4割前後がコールバック側の参照を取り忘れていました（PDF 表27）。第三に、成功と判定されたものの37.5%が fragile である以上、レビュー工数を「AIが出したから軽くできる」前提で見積もらないこと。1試行2.46ドルという生成コストは、そのレビュー工数の前ではほぼ誤差です。

主要出典

関連する過去記事