各コーディングエージェントがコードを「どう把握」しているのか差異と特徴を調べた

はじめに

「Claude Code や GitHub Copilot にコードを直してもらうと、毎回プロジェクト全体を読み込んでトークンをガンガン消費してるんでしょ？」
と質問を受け
「いやそうじゃないよ」と言いかけて「あれ？でもそれぞれ具体的にどう把握しているんだ？」と具体的には答えられませんでした。

各コーディングエージェントとも「いかに全部読まずに必要な箇所だけ拾うか」の仕組みが用意されていますが コードベースの把握の仕方（＝コードの拾い方）にはツールごとに結構な差異がある ので、それをまとめてみました。

「調べた」とか言っていますが私自身が分析したわけではなく文献調査です。

ベースにしたのは、7つのコーディングエージェントを同一タスクで走らせて検索手法を比較した調査研究¹です。
https://www.preprints.org/manuscript/202510.0924
論文の対象に GitHub Copilot は入っていないので、そこは別途調査しています。

3行で

• コーディングエージェントはコードベースを全読みしておらず、「必要な箇所だけ拾う」ための手法が複数存在する
• 大きく分けて「字句検索」「意味検索（埋め込み）」「構造検索（LSP/AST/グラフ）」「エージェント検索」「マルチエージェント」の5タイプがあり、製品ごとに採用が違う
• 同一タスクでトークン消費が 8.5k〜117k と1桁以上 バラついたのに全エージェントが成功した。つまり「読み込みタイプの選び方＝効率の差」であって、できる/できないの差ではない

製品ごとの読み込みタイプ

7エージェント＋GitHub Copilot を、把握タイプで並べるとこうなります。表中のタイプ名は次章で説明します。

製品	主な読み込みタイプ	ひとことメモ
Claude Code	エージェント検索（grep / glob 中心）	あえて埋め込みインデックスを持たない方針
Gemini CLI	エージェント検索（grep + 並列読み）	複数ファイルをバッチで読んで高速
Codex CLI	エージェント検索（シェルコマンド + あいまいファイル検索）	透明性重視、ただし表示トークン数が実態とズレる罠あり
Cursor	ハイブリッド（埋め込み + grep）	バックグラウンドでインデックス構築、全体俯瞰が得意
GitHub Copilot	ハイブリッド（意味インデックス + Code Search + grep）	Cursor に近い思想。下で補足
Cline	ハイブリッド（ripgrep + あいまい検索 + Tree-sitter AST）	3層構成でVS Code統合
Aider	構造検索（Tree-sitter AST + PageRank）	埋め込みを一切使わず、グラフで重要ファイルをランク付け
Amp	マルチエージェント（検索サブエージェントに委譲）	コンテキスト隔離で本体を汚さない

ざっくり言うと、CLI系（Claude Code / Gemini / Codex）はエージェント検索、IDE統合系（Cursor / Copilot）は埋め込みハイブリッド、そして Aider と Amp が独自路線、という分布です。

GitHub Copilot の補足（論文に載っていない分）

GitHub Copilot は論文の比較対象外なので、別途まとめておきます。Copilot はワークスペースに対して 意味的インデックスを自動で構築 し、概念ベースの検索を行います²。GitHub にリモートのインデックスがあればそれを使う「Code Search」と、ローカルの埋め込み検索、それと grep を組み合わせるハイブリッド型です³。

かつてインデックス構築に5分ほどかかっていたのが、数秒（最大60秒）で完了するよう改善されたり⁴、2025年には専用の新しいコード埋め込みモデルで 検索品質が約37.6%向上・インデックスサイズが8分の1 になったり⁵と、地味に進化しています。

立ち位置としては論文の Cursor に近く、「全体俯瞰が得意・初期インデックスのオーバーヘッドあり・検索ロジックは部分的にしか見えない」というハイブリッド型の特徴をそのまま持っている、と考えてよさそうです。

コードベースの把握タイプ

ここからは、前章の表に出てきたタイプを1つずつ説明します。論文では検索手法がいくつかの系統に整理されています¹。実際には組み合わせて使われる（エージェント検索の中で grep を使う、など）ので排他的ではないのですが、把握タイプとして整理するとこんな感じです。

把握タイプ	仕組み	長所	短所
字句検索	grep / ripgrep による正規表現・キーワード一致	高速・透明・インデックス不要・常に最新	キーワードが一致しないと拾えない（例：read JSON data で deserialize_JSON_obj を見つけにくい）
意味検索（埋め込み/RAG）	コードをベクトル化し、概念的な類似度で検索	キーワードが違っても概念で拾える・全体俯瞰しやすい	インデックスの構築・保守が必要、コード変更で陳腐化、検索ロジックが不透明
構造検索（LSP/AST/グラフ）	構文解析・依存関係グラフ・記号テーブルで辿る	正確（定義/参照ジャンプ）、トークン効率が良い	初期セットアップや言語ごとの対応が必要
エージェント検索	LLM が実行時に「どのコマンドをどう打つか」を動的に組み立てる	柔軟・常に最新のコードを見る・人間の探索に近い	探索の往復でトークン消費が膨らみがち
マルチエージェント	検索専用のサブエージェントに探索を委譲	コンテキスト隔離でメインを汚さない・並列化可能	エージェント間の受け渡し（調整）コストが発生

私見（タイプ別）

• 字句検索 は地味ですが、コードは命名規則がそこそこ揃っていれば grep がめちゃくちゃ効くんですよね。「シニアエンジニアが当たりをつけて grep する」のと同じ動きです。逆に言うとコードが汚い場合はうまく動かなそうです。
• 意味検索 は便利そうに見えて、コードの場合は「意味は近いけど文脈的に無関係なチャンク」がノイズになる、という指摘が論文でも紹介されています¹。テキストと違ってコードは論理構造が強いので、ぶつ切りのチャンクと相性が悪い場面がある、と。
• 構造検索 のうち LSP は「人間がIDEで使う前提」のツールなので、エージェントにそのまま渡すと結構コケます（後述）。一方で AST + グラフは、その思想をエージェント向けに作り直したもので、これが今回かなり強かったです。

論文の実験：同じタスクで7エージェントを走らせた

論文では、約5万行・338ファイルの実在するリポジトリ（InfraGPT）に対して「GitHubコネクタのインターフェース実装を探す」という、複数ファイルにまたがる現実的なタスクを与えています¹。

結果のトークン消費がこちら。

製品	消費トークン	コンテキスト使用率
Aider	8,500〜13,000	4.3〜6.5%
Amp	19,000	2.0%（968kウィンドウ）
Cursor	29,400	14.7%
Cline	35,000	17.5%
Codex CLI	39,540（キャッシュ込み190,964）	14.5%（実質70.2%）
Gemini CLI	102,280	51.1%
Claude Code（通常）	108,000	54.0%
Claude Code（LSP併用）	117,000	58.5%

注目すべきは、トークン消費が1桁以上ばらついたのに、7エージェント全部がタスクに成功した という点です。つまり「読めるか読めないか」ではなく「どれだけ無駄なく読むか」の勝負だということですね。

論文の主な発見

論文の結論を3つに絞ると、

1. 意味検索（埋め込み）は字句検索に対して、明確な性能優位を示さなかった。 少なくともこのタスクでは、埋め込みインデックスがあってもなくても結果は出せた。むしろ最も省トークンだったのは埋め込みを使わない Aider のグラフ方式でした¹。

2. 人間向けのLSPは、エージェントにそのまま転用できなかった。 Claude Code で LSP を併用する実験では、シンボル解決が失敗しまくり、結局 grep に戻って完了。トークンだけ増えて効果なし、という結果でした。ただし LSP の「構造を理解する」思想自体は、Aider のように AST + グラフへ作り直すと有効でした¹。

3. マルチエージェント（検索委譲）は有望だが、調整コストがある。 Amp は2番目に省トークンでしたが、サブエージェントとの結果受け渡しのオーバーヘッドがあり、単一エージェントに対する決定的な優位までは示されませんでした¹。

Claude Code が「あえて」埋め込みを捨てた話

個人的に一番おもしろかったのがここです。

Claude Code は初期に埋め込みベースのRAGをいろいろ試したものの、エージェント検索のほうが一貫して上回ったため、RAGを捨ててエージェント検索を選んだ という設計判断をしています¹。理由として大きいのは、インデックスは構築・保守が必要なうえコードが変わると陳腐化する点、そしてコードベース全体を埋め込む行為自体がセキュリティリスクにもなりうる点です。

この論文をみるまでは「AIが全体把握できるようにドキュメント用意しよう」「埋め込みで全体マップを作れば効率的なのでは？」と考えていたのですが・・・
直感的には正しそうに見えて、コードという対象に対しては必ずしも勝たない、というのがこの研究の地味に効いてくる結論だと思います。

ただ理屈的に汚いコードだとうまく動かなそうな気がしますので、
適切なレベルでモジュール/クラス/関数分割されているか、密結合になっていないか、命名規則が直感的か、コメントが入っているか・・・etc等のClaude Codeの場合従来のコーディングで気を付けるべき点がより重要になってくると思います。

まとめ

• コーディングエージェントは全コードを読み込んでいるわけではなく、必要な箇所だけ拾う手法を各自持っている
• その把握タイプは「字句 / 意味（埋め込み）/ 構造（LSP・AST・グラフ）/ エージェント / マルチエージェント」に整理でき、製品ごとに採用が分かれる
• 同一タスクで全エージェントが成功した一方、トークン効率は1桁以上違った。効率の差はあっても、できる/できないの差ではない
• 「埋め込みで全体マップ」は一見良さそうだが、コードに対しては字句検索やグラフ検索が勝つ場面も多く、Claude Code はあえて埋め込みを採用していない

なお論文はあくまで「単一タスク・単一リポジトリの探索的研究」であり、統計的な優劣を結論づけるものではない点には注意です¹。タスクの種類やリポジトリの規模が変われば、向き不向きも変わってくるはずです。このあたりの定量ベンチマークは今後の課題として挙げられています。

1. Jain, P. (2025). An Exploratory Study of Code Retrieval Techniques in Coding Agents. Preprints. DOI:10.20944/preprints202510.0924.v1. https://www.preprints.org/manuscript/202510.0924 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. Visual Studio Code Docs. How Copilot understands your workspace. https://code.visualstudio.com/docs/agents/reference/workspace-context ↩

3. Rashan, Y. How GitHub Copilot Knows Your Code: Inside Its Indexing Magic. https://yasithrashan.medium.com/how-github-copilot-knows-your-code-inside-its-indexing-magic-aba59a0ce0e8 ↩

4. GitHub Changelog (2025). Instant semantic code search indexing now generally available for GitHub Copilot. https://github.blog/changelog/2025-03-12-instant-semantic-code-search-indexing-now-generally-available-for-github-copilot/ ↩

5. GitHub (2025). A new Copilot embedding model for code retrieval in VS Code（検索品質37.6%向上・インデックス8分の1）。 ↩