AIエージェントがバグを修正したが、他に何が変わったのか？

AIエージェントがバグを修正したが、他に何が変わったのか？

本日、patching-bugsとregression-huntを公開します。これらは、エンジニアがパッチ開発とリグレッションチェックをエージェントに委任できる2つのプラグインです。patching-bugsプラグインは、報告されたバグを再現し、修正を開発し、テストします。regression-huntプラグインは、変更が以前に動作していたサポートされている動作を壊していないかを確認します。エンジニアは作業を指示し、その結果を確認できます。メンテナーは独自のセキュリティ上の仮定やパッチ要件を提供できるため、エージェントはプロジェクトのルール内で動作します。

私たちは、OpenAIとの共同イニシアチブであるPatch the Planetを通じて、patching-bugsとregression-huntを構築しました。このイニシアチブでは、広く使用されているオープンソースプロジェクトのために数百ものセキュリティパッチを共同執筆してきました。Scapyなどのプロジェクトでの大きな成功に触発され、私たちのプラグインは、マージされたパッチの分析と、何千ものエンジニアのCodexセッションからの知見を活用しています。

これらのプラグインは、メンテナーに構造化されたワークフロー、証拠、独立したチェック、およびベストプラクティスを提供し、パッチの衛生状態を改善します。予備評価では、regression-huntは、「PRのリグレッションをレビューせよ」と指示されたベースラインCodexエージェントよりも25%少ない偽陽性検出結果を生成します。

パッチプロセスの標準化

9月の投稿で、私たちのPatch the Planetパッチの一部によって導入されたリグレッションについて報告しました。それ以来、Trail of Bitsのエンジニアが作成し、メンテナーがアップストリームにマージしたすべてのパッチを見直しました。レビューにより、130件以上のマージされたPRから21件のリグレッションが確認されました。機能的なものが16件、パフォーマンスが1件、ビルド/テストが4件でした。セキュリティ保護を壊したものは一つもありませんでした。

（「リグレッション」とは、変更によって導入された新しい欠陥であり、実際のユーザーまたは攻撃者が到達できるパスに沿って、以前は正しかったサポートされている動作を壊すものです。）

各パッチについて、エージェントは潜在的なリグレッションを探し、各リグレッションを変更の前後に実行された概念実証（PoC）で確認し、その後、エンジニアにレビューのために結果を渡しました。

レビューはノイズが多かったです。今日のバグ開示は前例のない速度と規模で到着しており、パッチが追いつくためには、業界はその信号対雑音比を向上させる必要があります。確認された21件のリグレッションは、単一の実行で58件の候補の中から特定されました（精度約36%）。しかし、エージェントはさまざまなアプローチを取り、異なる結果を出すため、各実行で手動でソートする必要がある候補が増えます。

これにより、2つの結論に至りました。

1. リグレッションを減らすためには、毎回同じチェックが適用される、パッチを記述するための標準的な方法が必要でした。
2. それでも導入してしまうリグレッションを捕捉するためには、リグレッションをチェックするための標準的な方法、つまり、何がリグレッションと見なされるかの記述されたルールが必要でした。

両方のステップを標準化することで、各実行が再現可能で比較可能になります。固定されたチェックリストではすべてリグレッションを捕捉できないため、エンジニアのパッチセッションからのエージェントの軌跡を収集し、以前のバージョンがベンチマークできなかったタスクを次のバージョンに使用します（図1）。

［画像: 「パッチの生成と評価のためのフィードバックループを示す図。」］

図1: パッチの生成と評価のためのフィードバックループ。

プラグインの設計方法

プラグインの設計をガイドするために、2つの主要な情報源を使用しました。アップストリームにマージしたすべてのパッチのレビューと、エンジニアがそれらのパッチを記述するために使用した何千ものCodexセッションです。

これにより、patching-bugsとregression-huntプラグインを形作った4つの原則が生まれました。

1. できるだけ少ない言葉で、意見の強いガイダンス。 エージェントに広範な裁量を与え、良いパッチと実際のバグとは何かについてのTrail of Bitsの判断のみを記録します。目標は、最小限のガイダンスでエージェントを望ましい結果に導くことです。
2. モジュール化されたステップ。 プラグイン全体をエンドツーエンドで実行する必要はありません。どちらも複数のスキルを提供しており、連携または単独で使用できます。
3. 厳格な入力と出力スキーマ。 各ステップは、クレーム、コードリビジョン、必要なチェック、生の証拠、および未解決の質問を含む定義済みのスキーマを受け取り、返します。固定スキーマは実行ごとのばらつきを減らし、各ステップが前のステップの作業を要約ではなく検証できるようにします。
4. すべてのクレームに対するライブ概念実証。 すべての結論は、ライブデプロイメントに対して実行されたPoCに依存します。ビルドされ、実行されているプロジェクトのインスタンスであり、実際のユーザーが使用するインターフェースを通じて到達されます。バグを再現し、修正を証明し、リグレッションを確認する際に、ステップがライブPoCを生成できない場合、その結果は結論が出ないものとなります。

regression-hunt は偽陽性率を低減します

regression-hunt プラグイン（図2）:

1. 候補リグレッションを列挙します。変更されたコード（差分）を呼び出し元から実際のインターフェースまでトレースします。
2. ライブデプロイメントで各候補リグレッションを再現します。
3. フレッシュコンテキストエージェントでライブデプロイメント上のPoCを再生します。
4. 前のすべてのステップの結果を判定し、証拠がリグレッションの要件を満たしていることを検証します。

［画像: 「リグレッション検索ワークフローを示す図。」］

図2: リグレッション検索ワークフロー。

上記の4つの原則に加えて、プラグインの重要なコア側面が2つあります。

1. リグレッションの定義: プラグインは、リグレッションとは何か、そしてより重要なこととして、リグレッションとは何かではないかについて強い意見を持っています。証拠の負担はエージェント（特に「裁定エージェント」ステップ中）に課せられ、疑わしいリグレッションが偽陽性、不完全な修正、潜在的なバグ、既存のバグなどではないことを示す十分な証拠があると証明する必要があります。プラグインは、これらのすべてのゲートを通過した場合にのみリグレッションを報告します。
2. 脅威モデルの組み込み: 脅威モデルが利用可能な場合、オーケストレーターは意図的にこのドキュメントを各個々のエージェントステップのグローバルコンテキストの一部として渡します。これは、各ステップ/エージェントが結論に達する前に脅威モデルを参照するように要求する試みです。

マージされたPRのレビューから、regression-huntを評価するために使用できる21件の確認済みリグレッションのセットが得られました。「PRのリグレッションをレビューせよ」と指示されたベースラインCodexエージェントと比較するために、セット全体を使用しました。

これらの実行全体で、regression-huntはベースラインよりも25%少ない偽陽性検出結果を生成しました。信頼区間は95%で14%から38%でした。その厳格な証拠要件により、既知のリグレッションの一部が境界線として分類されました。プラグインはリグレッションの可能性を特定しましたが、それを確認するのに十分な証拠を収集できませんでした。したがって、偽陽性が少なくなる代わりに、自信を持って報告できる既知のリグレッションの数が減るというトレードオフがありました。

次に、これらのケースがなぜ境界線のままだったのかを調査し、証拠収集のためのプラグインの戦略を改善します。目標は、より多くの実際のリグレッションを確認すると同時に、証拠が依然として不確かな場合にメンテナーに明確な情報を提供することです。

patching-bugs は数千ものエージェントセッションからのベストプラクティスを合理化します

patching-bugs プラグインは、Trail of Bits のエンジニアによる数千もの Codex セッションの分析から特定されたすべてのベストプラクティスを蒸留したものです（図3）。ライブデプロイメントでの再現や独立した敵対的レビューなどのより伝統的な機能に加えて、プラグインは以下を強調しています。

1. 3つのアームの証明: 証明は、3つの仕様に対して同じ再現を実行します。元のコードは失敗する必要があり、パッチが適用されたコードは成功する必要があり、完全なロールバックは再び失敗する必要があります。パッチを削除することでバグを再現することは、パッチ自体がバグを修正したこと、環境やテストの変更とは無関係であることをより強力に証明します。
2. 不変条件ガイドによる修復: パッチは、特定のバグを修正するのではなく、根本的な、違反されたセキュリティ不変条件を修正しようとします。これにより、同じバグクラスの可能なバリアントに対してパッチを一般化するのに役立ちます。
3. リグレッション分析の組み込み: プラグインは、パッチが間違いをチェックするために同じ標準パイプラインを通過することを保証するために、regression-hunt の実行を義務付けています。

［画像: 「パッチバグワークフローを示す図。」］

図3: パッチバグワークフロー。

プラグインの今後の展開

patching-bugs と regression-hunt の両方は進化し続けます。エンジニアは現在、Patch the Planetの作業でそれらを使用しており、使用方法、何が機能し、何が機能しないかについてのデータを収集しています。そのデータは、より良い評価とともに、次期バージョンの機能を形作ります。

• patching-bugs の評価。 プラグインのパッチが報告されたバグとそのバリアントを、リグレッションを導入せずに修正するかどうかを測定する評価を構築しています。
• エージェントのトレースから学ぶ。 エンジニアのセッションからの最初のトレースレベルデータのバッチを分析しています。Codexが各ステップで要求されるルールと定義に従っているか、どのステップをスキップしているか、証拠がどこで弱いかを示します。
• プラグインの構成可能性を高める。 patching-bugs はすでにプロジェクト独自のパッチガイドラインを読み取っています（これについては後述）。次に、メンテナーがパッチセットを最小化するかどうかを選択できるようにしたいと考えています。あるいは、より広範なカバレッジがより多くの偽陽性をもたらす価値がある場合は、regression-hunt のルールを緩和して、より多くの候補を表面化できるようにしたいと考えています。

これらのプラグインは、エージェントがバグを適切にパッチするために私たちが発見したベストプラクティスをエンコードしており、プロジェクトの動作方法を指示すると改善されます。

プラグインは、次の2種類のプロジェクト知識を入力すると最も効果的に機能します。

1. THREAT_MODEL.md: エージェントに何が脆弱性またはリグレッションと見なされるかを伝えます。regression-hunt プラグインはこれを各ステップに渡すため、各エージェントは結論をファイルに対してチェックする必要があります。これは、その侵害が重要であるアセット、信頼境界、アクセス制御、サポートされている構成、脆弱性であるもの/そうでないものに関する仕様、および有効なバグレポートに必要な証拠を定義する必要があります（例）。
2. PATCHING_GUIDELINES.md (または AGENTS.md): プロジェクトがどのように修正を記述したいかをエージェントとpatching-bugsに伝えます。プロジェクトのビルドとテスト方法、修正のサイズ、修正をどこに配置するか、提案された変更をどのように提示するか、リグレッションテストが何を示す必要があるかを概説する必要があります（例）。

GPACとのPatch the Planet作業では、エンジニアは脅威モデルとプロジェクト固有のパッチスキルを作成しました。これは、GPACのメンテナーがバグをどのように再現したいか、修正にどのような証拠が必要か、パッチが何を保持する必要があるかを捉えています。Liboqsとvalidator.jsも、私たちのガイダンスに従って脅威モデルを公開しています。

これらのファイルがプロジェクト、コード規約、運用スタイルに包括的かつ具体的であるほど、受け取る出力は良くなります。

業界はパッチに焦点を当てる必要がある

AIがバグ発見を加速させるにつれて、私たちはそれらの発見をできるだけ早く信頼できる修正に変える必要があります。ソリューションは、速度と品質のバランスを取る必要があります。エージェントはレポートを理解し、何を変更する必要があるかを決定し、パッチがリグレッションを導入することなく問題を修正することを確認する必要があります。私たちのpatching-bugsとregression-huntプラグインは、Patch the Planetから得た教訓をそのワークフローにもたらし、メンテナーがバグレポートから自信を持ってレビューおよび出荷できるパッチへと移行するのを支援します。

patching-bugsとregression-huntをインストールし、リポジトリにTHREAT_MODEL.mdとPATCHING_GUIDELINES.mdを追加して、次のバグレポートで活用してください。ツールにプロジェクトのコンテキストを提供することで、適切な修正に集中し、より迅速に検証できるようになります。その後、フィードバックを共有してください。デフォルトがプロジェクトに合わない点についてのコメントも含めてください。これらの実際のケースは、次期バージョンを構築するのに役立ちます。