RepoComplianceBench：4つのコーディングエージェントは、オープンソースプロジェクトのAIコントリビューション規則をほぼ自発的に確認しない

北京大学の研究チームは、コーディングエージェントがオープンソースプロジェクトの定めるAIコントリビューター向け規則を遵守するかどうかを評価するRepoComplianceBenchを発表した。このデータセットは、49の実在するリポジトリから106件のissueを収集し、ポリシーを4種類に分類している。AIの利用が禁止されている場合に作業を拒否すること、提出時にAIの支援を開示すること、指定された検証を実行すること、重要な手順を人間に引き継ぐことである。研究者は、エージェントが実際にupstreamへ変更を送信しないよう、クリーンアップ済みのリポジトリスナップショットを使用した。

評価対象は最終的なpatchだけではない。機械的な検証器によって、エージェントが指定されたテストを実行したか、開示文を追加したかといった観測可能なイベントを確認する一方、人間によるキャリブレーションを施したLLM rubricを用いて、作業拒否と人間への引き継ぎを判定した。この軌跡レベルの設計は重要だ。テストに合格する修正であっても、生成元を開示していなかったり、メンテナーに留保された手順を飛び越えたりすれば、コンプライアンス違反となり得る。

4つの最先端モデルは、追加の指示がない場合、CONTRIBUTING.md、AGENTS.md、AI_POLICY.md、PR templateに記載された規則を自発的に探すことがほとんどなかった。規則をpromptへ直接記載する、ファイルの場所を明示する、あるいはコンプライアンス検証器から失敗理由をフィードバックすると、開示と検証の行動は大幅に改善した。しかし、研究で評価されたすべての設定において、エージェントはAIによるコントリビューションを明確に禁止するリポジトリでも作業の実行を拒否しなかった。人間への引き継ぎも、ツールで確認できる規則より確実に発動させることが難しかった。

エージェントプラットフォームにとっての結論は、汎用的なsystem promptをもう一段追加することではなく、ポリシーの検出と適用をharnessの必須フェーズにすることだ。作業開始前に規則ファイルを検索し、禁止事項を回避不能なgateへ変換し、提出前にevent logを使ってテストと開示を検証する。必要な場合は作業を停止し、人間の承認を求めるべきである。AGENTS.mdのような形式は規則の可視性を高められるが、それ自体は執行メカニズムではない。

制約として、サンプルが49プロジェクトに限られていること、一部の意味的な判定が依然としてLLM evaluatorに依存していること、また論文の要約では各製品を直接比較できる完全なモデル別数値表が示されていないことが挙げられる。今後は、データと軌跡が公開されるか、さらに規則の配置、prompt injection、相互に矛盾するポリシーによってコンプライアンス率が一段と低下するかが注目される。