セキュリティ企業のTrail of Bitsが10月21日、AIエージェントによるバグ修正の「副作用」を探す2つのスキルを公開しました。AIが報告どおりのバグを直しても、別の場所で正しく動いていた機能を壊すことがあります。同社は自社エンジニアが出してマージされたパッチ130件超を調べ、21件の退行を確認しました。AIによる修正が急増するなか、レビューの質をどう保つかという現場の課題に具体的な手順で答えています。
背景と文脈
AIエージェントを使ったバグ探しが広がり、オープンソースの保守担当者に届く報告は急増しています。修正パッチもAIが書くようになりました。その結果、保守担当者のレビューが追いつかない状況が生まれています。
ここで問題になるのが退行（regression）です。Trail of Bitsは退行を「以前は正しく動いていた機能が、実際の利用者や攻撃者が通る経路で壊れること」と定義しています。直したはずのパッチが、新しいバグを持ち込むケースです。
同社が調べた130件超のPRでは、21件の退行が見つかりました。内訳は機能面が16件、性能面が1件、ビルドやテストの問題が4件です。セキュリティの保護を壊したものはありませんでした。それでも、マージ済みのパッチの中に一定の割合で副作用が紛れていた事実は重いでしょう。
単純にAIへ「このPRの退行をレビューして」と頼む方法も試されています。しかし1回の実行で58件の候補が出て、本物は21件でした。適合率（候補のうち本物の割合）は約36%にとどまります。
技術/ビジネス面
公開したのは、trailofbits/skillsリポジトリにある2つのスキルです。スキルは、AIエージェントに特定の作業手順を教える指示書のようなものです。OpenAIとの共同プロジェクト「Patch the Planet」の一環として作られました。
1つ目のpatching-bugsは、バグの再現から修正、テストまでを担います。特徴は「3段階の証明」です。元のコードでは失敗し、修正後は成功し、修正を完全に戻すと再び失敗する。この3つがそろって初めて、そのパッチがバグを直したと認めます。さらに、個別のバグではなく破られた不変条件（常に守られるべき前提）を直すことで、同じ種類の亜種もまとめて防ぎます。
2つ目のregression-huntは、差分が呼び出される経路を外部の入口までたどり、退行の候補を洗い出します。各候補は実際の環境で再現し、文脈を持たない別のエージェントにPoC（Proof of Concept、問題を実証する最小限のコード）を再実行させます。最後に判定役が、証拠が退行の定義を満たすかを判断します。PoCを作れない段階は「判定不能」として扱い、推測で報告しません。
Trail of Bitsのブログによると、21件の退行で試した結果、誤検知は通常のCodexエージェントより25%少なくなりました。95%信頼区間は14〜38%です。一方、証拠の基準が厳しいため、本物の退行の一部が「境界線」に分類され、見逃しも出ています。
これからどうなるか
Trail of Bitsは保守担当者に、リポジトリへ2つのファイルを置くよう勧めています。1つはTHREAT_MODEL.mdで、守るべき資産や信頼の境界、何を脆弱性や退行とみなすかを書きます。もう1つはPATCHING_GUIDELINES.md（またはAGENTS.md）で、ビルド方法や修正の大きさ、退行テストの条件を書きます。
この2つは、AIに渡す「判断の基準」になります。liboqsやvalidator.jsはすでに脅威モデルを公開しました。自分のプロジェクトでもClaude CodeやCodexに修正を任せているなら、まずAGENTS.mdに「修正前に失敗するテストを書く」「戻すと失敗することを確かめる」と書くだけでも効果がありそうです。
同社は今後、パッチが亜種まで直し、かつ退行を起こさないかを測る評価を作る予定です。設定で緩い基準に切り替え、候補を多めに出す機能も検討しています。
まとめ
Trail of Bitsは、AIのバグ修正が生む退行を、実証付きで探す2つのスキルを公開しました。130件超のマージ済みPRから21件の退行が見つかった事実は、AI修正をそのまま受け入れる危うさを示します。3段階の証明や脅威モデルの文書化は、AIに修正を任せるチームならすぐ取り入れられる工夫です。
参考リンク
アイキャッチ画像: Photo by Christina @ wocintechchat.com M on Unsplash
