10月21日、Trail of Bitsが「Your AI agent fixed the bug, but what else did it change?」と題した記事を公開した。AIエージェントが自動生成したセキュリティパッチが意図せず既存の動作を壊す「リグレッション」問題に対処するため、新たに2つのプラグインをOSSとして公開したことを報告する内容だ。
AIコーディングエージェントによる自動パッチ生成は、セキュリティ分野でも急速に普及しつつある。しかしその裏側では「バグは直ったが、別の何かが壊れた」という問題が静かに蓄積されてきた。Trail of Bitsはこの問題を数値で示した上で、再現性ある解決策を提示している点で業界内外から注目を集めている。
130件超のPRを精査して判明した21件のリグレッション
Trail of BitsはOpenAIとの共同イニシアチブ「Patch the Planet」を通じて、OpenAI Codexを活用し広く使われるOSSプロジェクトへセキュリティパッチのPRを大量に送付してきた。AIエージェントが脆弱性を自動的に発見・修正し、プロジェクトにPRを送るという取り組みだ。
その過程でマージ済みの130件以上のPRを精査したところ、21件のリグレッションが確認された（機能的リグレッション16件、パフォーマンス1件、ビルド/テスト4件）。幸いセキュリティ保護そのものを破壊したケースはなかったが、比率として無視できない水準だ。この知見をもとに公開したのが以下の2つのプラグインである。
- **patching-bugs**：バグの再現・修正・テストをエージェントに委任する
- **regression-hunt**：パッチが既存の動作を壊していないか検証する
どちらもTrail of Bitsの「skills」リポジトリでOSSとして公開されており、任意のプロジェクトに適用できる。
regression-hunt：誤検知を25%削減する4段階ワークフロー
regression-huntの核心は「リグレッションとは何か・何ではないか」を厳密に定義したことにある。ワークフローは4段階で構成される。
- 列挙：変更されたコード（diff）をコールチェーンで追跡し、リグレッション候補を洗い出す
- 再現：ライブデプロイ環境でリグレッション候補を再現する
- リプレイ：別の新規エージェントが同じPoC（概念実証コード）をライブ環境で再実行する
- 判定：前段階の証拠を総合して「本当にリグレッションか」を判定する
重要な設計方針は証拠不十分の場合は報告しないという原則だ。フォルスポジティブ・不完全な修正・既存バグとの混同などに当てはまる可能性がある場合、プラグインはリグレッションとして報告しない。また、リポジトリに脅威モデル（THREAT_MODEL.md）が置かれていれば、各エージェントのステップがその定義を参照して判断する仕組みになっている。
評価結果として、ベースライン（「PRのリグレッションをレビューせよ」とプロンプトしたCodexエージェント）と比較して誤検知を25%削減（95%信頼区間：14〜38%）した。ただしトレードオフもある。厳格な証拠要件のため「確認できた可能性あるが証拠不十分」として保留になったリグレッションも存在する。
patching-bugs：数千セッションの知見を詰め込んだ修正プラグイン
patching-bugsには、Trail of BitsのエンジニアがCodexを使って行った数千のパッチ作成セッションで得られた知見が反映されている。特徴的な点は3つある。
三腕証明（three-arm proof） はTrail of Bitsが採用するユニークなアプローチだ。「3つのパターンで修正の有効性を確認する」という手法で、以下の3パターンのテストを必須とする。
- オリジナルコードでバグが再現される（FAIL）
- パッチ済みコードでバグが再現されない（PASS）
- パッチを完全に元に戻したらバグが再現される（FAIL）
3番目のステップが重要で、「パッチではなく環境変化でたまたまテストが通った」という誤魔化しを防ぐ役割を持つ。
不変条件に基づく修正（invariant-guided repair） では、特定のバグ症状ではなく、破られたセキュリティ上の不変条件そのものを修正することを目指す。これにより同種のバグバリアントへの汎化が期待できる。
さらにregression-huntの実行が必須となっており、どのパッチも同じ標準パイプラインで検証される構造になっている。
効果を高めるプロジェクト固有の知識ファイル
両プラグインは、リポジトリに以下の2ファイルを置くと精度が向上する。
- **
THREAT_MODEL.md**：何が脆弱性・リグレッションに該当するかを定義する。資産、信頼境界、アクセス制御、サポート対象の設定、有効なバグレポートに必要な証拠などを記載する（GPACプロジェクト向けの例を参照） PATCHING_GUIDELINES.md（またはAGENTS.md）：ビルド・テスト方法、修正の粒度、変更の提示方法、リグレッションテストの要件などを記載する
liboqsやvalidator.jsもこのガイダンスに沿った脅威モデルを公開しており、実際の記述例として参考になる。
確認されたリグレッションの一覧（抜粋）
| プロジェクト | パッチ | 種別 | 何が壊れたか |
|---|---|---|---|
| botan | PR #5825 | 機能 | 中間発行者の委任代理人が署名した有効なOCSPレスポンスを拒否するようになった |
| crypto-bigint | PR #1274 | ビルド/テスト | DER専用ユニットテストがコンパイル失敗 |
| nats-server | PR #8276 | 機能 | 権限更新中に禁止メッセージが一時的に配信されてしまう |
| noble-curves | PR #251 | パフォーマンス | 有効な署名検証で楕円曲線演算が重複実行される |
全21件の一覧および各PRの詳細は元記事で確認できる。AIエージェントによるパッチ自動化を検討しているチームにとって、実運用上の落とし穴とその対策を具体的に把握できる内容だ。
詳細はYour AI agent fixed the bug, but what else did it change?を参照していただきたい。
