Ripwire 0.4、コードグラフでエージェントの検索範囲を縮小—ただしトークン削減がタスクコスト低下につながるとは限らず

Ripwire 0.4.0 は9月7日にリリースされ、コーディングエージェントがリポジトリを理解するために検索を繰り返し、大量のソースコードを読み込むコストの解消を目指している。これは実行時依存関係のない C++23 製 CLI で、MCP server としても利用できる。ローカル環境で tree-sitter を使ってコードを解析し、シンボル、呼び出し、インポートの関係を抽出したうえで、タスクの説明に基づき Personalized PageRank で順位付けする。出力には候補ファイルだけでなく、関数シグネチャ、呼び出し元、複雑度、Git の変更頻度、変更の波及範囲、推奨テストも含められる。embedding、API key、ホスト型ベクトルインデックスは不要だ。

[プロジェクトの評価](https://github.com/redhat-et/ripwire)では、Python が中心の LocBench サンプル60件における strict file@10 が58.3%だった。これは、正解とされるすべてのファイルが上位10件に入ったことを意味する。比較対象のうち最良のツールは40.0%だった。ただし、これはあくまで「ファイルを見つける」評価であり、正しいパッチを生成する評価ではない。Django を使った実験では、コンテキスト token を単純な grep-and-read の約5%まで圧縮できた一方、厳格な正解判定を通過した件数は5/12にとどまり、grep-and-read は11/12だった。

さらに注目すべきなのは、プロジェクトが公開した6回の Codex エージェント実験だ。Ripwire は3回すべてで正解パッチの対象ファイルを1位にランク付けしたが、Ripwire を組み込んだワークフローでは出力 token の中央値が約80.2%増加し、経過時間も約40.7%増加した。[独立技術レビュー](https://wavect.io/blog/ripwire-ai-repo-context-review-2026/)は、主因はランキング機構そのものではなく、エージェントが過剰なスキル説明を読み込み、定型的な呼び出しを行う点にあると分析している。そのため、エンジニアリングチームは Ripwire を、対象範囲が不明な場合にのみ有効化する位置特定ツールとして扱い、直接検索とテストの経路も残すべきだ。評価指標も、1回のクエリでどれだけ token を節約できたかではなく、受け入れ基準を通過するパッチを得るまでのコストにすべきである。