CI-Repair-Bench: A Repository-Aware Benchmark for Automated Patch Validation via CI Workflows

以下は、論文「CI-Repair-Bench: A Repository-Aware Benchmark for Automated Patch Validation via CI Workflows」の詳細な技術的サマリーです。

1. 問題定義

継続的インテグレーション（CI）は、多段階のワークフローを通じてリポジトリレベルの正しさを強制することで、現代のソフトウェア開発の中心をなしています。しかし、CI の失敗を診断し修復することは、自動化システムにとって依然として大きな課題です。従来のプログラム修復とは異なり、CI の失敗はしばしば以下のような要素を含みます：

• 非コードアセット: ビルドスクリプト、依存関係の仕様、環境変数、ワークフロー設定。
• ノイズの多い実行ログ: 冗長で多段階のログであり、根本原因はしばしば隠蔽されていたり、症状とは異なるステージに位置していたりする。
• 動的環境: 依存関係の解決、環境のドリフト、またはツールチェーンの不一致に起因する失敗。

既存の自動プログラム修復（APR）ベンチマーク（例：SWE-bench、Defects4J）は、このドメインには不十分です。その理由は以下の通りです：

1. 修復をソースコードのみに制限している。
2. 完全なパイプライン検証ではなく、テスト中心のオラクル（通過/失敗）に依存している。
3. 固定されたコンテナ化された実行環境を前提としている。
4. 問題駆動の入力ではなく、ログ駆動の診断を使用している。
5. 現実の複雑さ（例：条件付き実行、マルチジョブ依存関係）を欠く単純化されたワークフローで評価している。

2. 手法：CI-Repair-Bench

著者は、これらのギャップに対処するため、実世界の GitHub Actions 実行から構築された大規模ベンチマーク「CI-Repair-Bench」を導入します。

データセット構築

• ソース: スター数と最近の活動に基づいて選択された、103 の活発にメンテナンスされている Python リポジトリ。
• 規模: 「失敗から通過」へのコミットペアから導出された 567 の CI 失敗インスタンス。
• インスタンスごとのコンポーネント:
  1. リポジトリメタデータ: オーナー、名前、ブランチ。
  2. CI ワークフロー詳細: YAML 設定と検証ステップ。
  3. CI ログとアセット: 失敗したジョブからの実行ログ。
  4. コミットペア: 失敗したコミットと、その直後に通過した最も近いコミット。
  5. 真の修復パッチ: コミットペアから導出された最小かつ検証済みのパッチで、CI 失敗と因果関係のある変更のみを分離したもの。
• エラー分類: 失敗は、コードフォーマット、リンティング、構文エラー、ランタイムエラー、テスト失敗、依存関係の問題、設定エラー、環境エラーを含む12 の明確なタイプに分類されます。
• 検証: 正しさは、元の（標準化された）ワークフロー下での完全な GitHub Actions の再実行によってのみ評価されます。修復が成功するのは、パイプライン全体が新しい失敗を導入することなく通過した場合に限られます。

参照修復フレームワーク

ベンチマークの使用例を示すため、著者は 3 つの段階からなる参照的なエージェント型 CI 修復パイプラインを提案します：

1. CI ログ分析: 反復的なエージェントベースの LLM 戦略を用いて、ノイズの多いログをチャンク化、フィルタリング、要約し、構造化された失敗レポートにします。
2. 故障局所化: 変更されたファイルを選択し、因果証拠に基づいて候補を洗練し、微細な行レベルの局所化を行うことで、検索空間を狭めます。
3. パッチ生成: リポジトリレベルのパッチを生成します。ルール違反に対しては（リンターを実行するなど）決定論的なツールベースの修正を優先し、複雑なロジックには LLM ベースのコード編集を使用します。

3. 主な貢献

1. CI-Repair-Bench: リポジトリレベルで CI 検証されたプログラム修復のために特別に設計された最初のベンチマーク。非コードアセットの変更をサポートし、隔離されたテストではなく完全な CI パイプラインに対して修復を検証します。
2. 参照修復パイプライン: ログ分析、故障局所化、パッチ生成を統合したモジュール型フレームワーク。4 つの異なる大規模言語モデル（LLM）をインスタンス化してベースラインを確立します。
3. 実証分析: 修復の有効性が、異なる CI 失敗モードやモデルの能力によってどのように変化するかを特徴づける包括的な研究。

4. 実験結果

著者は、4 つの LLM（GPT-5-mini、DeepSeek-Coder、DeepSeek-Chat、GPT-4o-mini）を使用して参照フレームワークを評価しました。

全体的なパフォーマンス

• 修復成功率（Pass@1）: 最高性能のモデル（GPT-5-mini）でも、成功率はわずか**18.9%**でした。最低は 7.9% でした。
• 局所化と修復のギャップ: 故障局所化（Top-1 精度）はモデル間で比較的一貫していました（約 42-45%）が、最終的な修復成功率は 2 倍以上変動しました。これは、正しいファイルを特定することは必要だが不十分であり、すべての CI ステージを満たす正しい最小変更を生成することが主要なボトルネックであることを示しています。
• パッチ適用対 CI 成功: 適用されたパッチの約 73–89% が完全な CI 再実行で失敗しました。これは、テストのみの評価と比較して、ベンチマークが極めて厳格であることを浮き彫りにしています。

ログ分析戦略の影響

• エージェントベース対検索（BM25）: 反復的なエージェントベースのログ分析を軽量な BM25 検索戦略に置き換えると、パフォーマンスが劇的に低下しました。
  • Pass@1 の低下: モデル間で**28.0% から 75.9%**の範囲で低下しました。
  • 局所化の低下: Top-1 精度は 24〜37 ポイント低下しました。
  • 結論: 正確で推論を重視したログ分析は CI 修復に不可欠です。単純なキーワード検索では、診断に必要な意味的コンテキストを捉えられません。

失敗タイプ別パフォーマンス

修復成功率は、エラーの「信号局所性」に基づいて明確な 3 段階の階層に従います：

1. 高い成功率（トップティア）: コードフォーマット（35.5%）とリンティング（17.8%）。これらはログに明示的なエラー位置を持ち、直接的で決定論的な修正を可能にします。
2. 中程度の成功率（ミドルティア）: テスト失敗、ランタイムエラー、構文エラー（10–13%）。
3. 低い/ゼロの成功率（ボトムティア）: 依存関係の問題、設定エラー、環境エラー（成功率 9% 未満、しばしば 0%）。これらは、クロスファイルの推論、外部コンテキスト、反復的な検証を必要とし、現在の単一パス LLM では信頼性高く提供できません。

5. 意義と示唆

• 現実的な評価: CI-Repair-Bench は、環境やワークフローの制約を無視することで修復能力を過大評価しがちな既存の APR ベンチマークの限界を露呈させます。
• 研究の方向性: 結果は、将来の CI 修復システムが単一パスのコード生成を超えて進む必要があることを示唆しています。複雑で局所化されていない失敗に対処するには、リポジトリを認識した推論、依存関係分析、反復的な検証ループが必要です。
• ツールのギャップ: LLM はツール強制ルール（フォーマット/リンティング）には効果的ですが、「システム的」な失敗（依存関係、環境設定）には苦労します。これは、LLM と専門的な静的分析および依存関係解決ツールを組み合わせたハイブリッドアプローチの必要性を示しています。
• オープンリソース: ベンチマーク、データセット、参照コードは公開されており、CI ネイティブな自動化修復研究を進展させるための標準化された基盤を提供します。