コードエージェントはリポジトリを理解しているのか、それとも見覚えで判断しているのか

導入

SWE-bench のようなリポジトリレベルのベンチマークは、コーディングエージェントの能力を測る主要な手段になっています。単一関数の補完とは異なり、実際のプロジェクトを読み、問題の原因を探し、必要なファイルを修正し、テストで結果を確認することを求めます。そのため、現実のソフトウェア開発に近い評価だと考えられています。

一方で、この形式には見落としやすいリスクがあります。評価対象のオープンソースリポジトリが、モデルの学習データや公開された修正例に何度も登場している可能性があるからです。高いスコアは、純粋なコード理解だけでなく、プロジェクト名、ディレクトリ構成、issue の表現、よくある実装パターンを認識した結果でもあるかもしれません。

SchrodingerRepo の仕組み

上海交通大学の研究チームは、この問題を調べるため SchrodingerRepo を提案しました。評価時にリポジトリの表現を動的に生成し、元のプロジェクトと同じ実行上の振る舞いを保ちながら、見慣れた表面的な特徴を減らします。エージェントが受け取るのは動作可能なコードですが、固定された「正典版」とは異なる姿になっています。

主な変換は次の四段階です。

• 問題文の再構成：元の issue の定型表現への依存を減らします。
• 名前空間の変更：クラス名、関数名、モジュール名などを置き換えます。
• ファイル内配置の並べ替え：動作を変えずにコードの配置や構成を変更します。
• 機能を保つコード書き換え：実装パターンそのものを別の形にします。

研究では SWE-bench Verified と SWE-QA を使い、複数の大規模言語モデルを評価しました。報告によると、リポジトリに関する既知の手がかりを減らすと、モデルの性能は一貫して低下しました。また、エージェントが行う操作も増えています。追加コストの中心は最終的なパッチ生成ではなく、リポジトリの探索と問題箇所の特定でした。

意義と今後の評価

この結果だけで、現在のエージェントが答えを記憶していると断定することはできません。しかし、ベンチマークのスコアが、一般的なデバッグ能力、プロジェクト固有の慣れ、学習データに含まれたコードの記憶を同時に反映している可能性は示されました。

本当に頑健なエージェントには、未知のディレクトリ構成を読み、ファイル間の依存関係を追い、仮説をテストし、手がかりが少ない状況でも調査範囲を絞る能力が必要です。動作が同じ複数のリポジトリ表現を用いれば、「プロジェクトを知っていること」と「問題を解決できること」をより明確に分けられます。

もちろん、変換によって元の課題とは別の難しさが生じないよう、意味と実行結果を慎重に検証する必要があります。SchrodingerRepo の重要性は、データ漏えいへの懸念を、実験可能な評価設計へと変えた点にあります。見慣れたコードベースでの高得点だけでは、未知の開発環境で安定して働けることの証明にはなりません。

出典：Hugging Face Daily Papers