Code Isn't Memory: A Structural Codebase Index Inside a Coding Agent

技術要約：コードはメモリではない：コーディングエージェント内部における構造的コードベース・インデックス

問題提起
コーディングエージェントは、ソフトウェアエンジニアリングのタスクを解決するために、大規模言語モデル（LLM）とワーキングリポジトリに対する検索メカニズムを組み合わせる手法をますます採用している。しかし、特定の検索戦略、特に構造的コードベース・インデックス（セマンティック、レキシカル、およびコールグラフのデータを組み合わせたもの）が与える影響は依然として不明確である。先行する評価では、エージェントのハーネス全体を比較することで、検索性能とプロンプトエンジニアリング、ツール表面、あるいは制御ループの効果を混同していることが多い。さらに、構造的インデックスの構築と運用にかかる高いコストは、重要なデプロイメント上の疑問を提起している。すなわち、性能向上はコストに見合うのか、それとも単純な「エージェンティック・グレップ（agentic grep）」で十分なのか、という点である。既存のベンチマークも、課題テキストにおける解決策のリークやモデルの記憶（memorization）を含む整合性の課題に直面しており、厳格な監査プロトコルを必要としている。

手法
著者らは、固定されたコーディングエージェント・ハーネス（SuperCoder）内で、単一の固定モデル（Claude Opus 4.7）を用い、3つのランダムシードを用いて因果的アブレーション研究（causal ablation study）を実施した。この研究では、SWE-PolyBench VerifiedおよびSWE-bench Proから抽出した91のインスタンスに対し、以下の3つの実験アームを比較した。

1. SC-ON: 構造的コードベース・インデックスが有効化されたSuperCoderハーネス。このインデックスには、ベクトルインデックス（セマンティック）、グラフインデックス（定義/コールエッジ）、およびレキシカルインデックス（BM25）が含まれる。これはリポジトリごとに一度構築され、Merkle-treeによる差分を用いて逐次更新される。
2. SC-OFF: 文脈エンジンツール（codebase_searchおよびcodebase_graph）をツールスキーマから削除した、同一のSuperCoderハーネス。その他のすべてのコンポーネント（プロンプト、モデル、サンドボックス、残りのツール）は同一である。
3. OpenCode: 主な検索メカニズムとしてエージェンティック・グレップ（ripgrep）とファイル読み込みを使用する、独立したオープンソースのハーネス。これはクロスハーネス比較用の比較対象として機能する。

主要な実験的制御および整合性措置:

• 因果的隔離（Causal Isolation）: 同一のハーネス内でエンジンツールのみを切り替えることで、構造的インデックスを他の変数から分離し、その影響を孤立させている。
• リーク監査: 「フェイル・クローズド（fail-closed）」プロトコルを採用した。これには、ゴールド・フィックス（正解となる修正）のコミットとその子孫を削除するための実行前のgitスクラビング、および残留リーク（例：ゴールドファイルを変更した履歴コミットに対するgit show）を検出するための実行後監査が含まれる。公開された除外台帳に基づき、26個のセルが除外された。
• ローカリゼーション指標: 局所化スコアリングのためにView Bを導入した。View A（エージェントが実際にアクセスしたかどうかに関わらず、表示されたすべてのパスをカウントする）とは異なり、View Bはエージェントがgrep、read、またはeditを通じて能動的に到達したパスのみをカウントする。これにより、候補リストを単に受け取っただけで、それらにインタラクトしていないエージェントによるスコアのインフレを防いでいる。
• 統計分析: シード間で平均化された、インスタンスごとのpass@1値に対して、対応のあるウィルコクソン符号付順位検定を用いて分析を行った。

主要な結果
構造的インデックスが有効な場合、セルあたりのコスト増を招くことなく、ローカリゼーションと解決の両方において統計的に有意な改善が報告された。

• ローカリゼーション (View B acc@5):

  • SC-ON: 84.5%
  • SC-OFF: 44.3%
  • デルタ: +39.6 パーセントポイント (pp) ($p < 0.0001$)。
  • OpenCode: 75.3% (SC-ONはOpenCodeを+8.1 pp上回るが、$p=0.080$)。
  • 観察: インデックスは、エージェントが軌跡の早い段階で正しいファイルを提示する能力を劇的に向上させる。特にトップランクにおいて顕著であり、SC-ONでは77.4%のセルでゴールドファイルがランク1にあったのに対し、SC-OFFでは33.3%であった。

• 解決 (Resolve %):

  • SC-ON: 50.4%
  • SC-OFF: 41.9%
  • デルタ: +7.9 pp ($p = 0.003$)。
  • OpenCode: 45.3% (SC-ON vs. OpenCode: $p = 0.087$)。

• コストと労力:

  • セルあたりのコスト: SC-ONとSC-OFFの間で統計的に差はない ($p = 0.73$)。
  • 労力: SC-ONは、収束までに必要なターン数（28.3 vs. 36.2, $p < 0.0001$）およびトークン数（10.1k vs. 11.1k, $p = 0.027$）の両方で大幅に少なかった。
  • 解決あたりのコスト ($/solved): SC-ONは、SC-OFFの$2.84およびOpenCodeの$2.92と比較して、最も低い**$2.30**を達成した。

• 不均質性（Heterogeneity）: 構造的インデックスの恩恵は、複数ファイルにまたがる変更（3ファイル以上）において最も顕著であり、その場合、SC-ONとSC-OFFのローカリゼーションの差は46.4 ppに達した。これは、変更が複数のファイルに及ぶ場合、単純なgrepよりもコールグラフによる到達可能性の方が価値が高いという直感と一致している。

意義と主張
本論文は、コーディングエージェント・ハーネス内における、リーク監査済みかつモデル制御された、構造的コードベース・インデックスの最初の因果的アブレーションを提供すると主張している。その主な貢献は以下の通りである：

1. 因果的証拠: プロンプトエンジニアリングやモデルの変更とは無関係に、構造的インデックスがファイルのローカリゼーションとタスク解決の両方を因果的に向上させることを実証している。
2. コスト効率: 構造的インデックスの運用コストが高いという仮説を論破している。本研究は、インデックスが個々のセルあたりのコストを削減するわけではないものの、成功率を高め、必要なターン数を減らすことで、解決あたりのコストを大幅に削減することを示している。
3. デプロイメントの指針: 著者らは、デプロイメントに関する問いは「インデックスが高すぎるか？」ではなく、「ワークロードに、構造的ランキングが恩恵をもたらすような複数ファイルの変更が含まれているか？」であると結論付けている。
4. 再現性: 著者らは、除外台帳、リーク監査スクリプト、ローカリゼーション抽出器（View AとView Bの両方をサポート）、および全結果データベースを公開しており、報告されたすべての数値が再現可能であることを保証している。

論文は、クロスハーネス比較（SC-ON vs. OpenCode）に関して、SC-ONが好ましい傾向にあるものの、統計的有意性は限定的である（$p \approx 0.08$）とし、控えめなトーンを維持している。最も強力で堅牢な主張は、ハーネス内での因果的アブレーション（SC-ON vs. SC-OFF）である。