Claude CodeやCodexのようなAgent Harnessは、RAG（Retrieval-Augmented Generation）をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか？Software Engineer兼Database ResearcherのTaro L. Saito（@taroleo）氏のポストが、その本質を簡潔に説明している。
コンテキストウィンドウの拡大がRAGの必要性を変えた
現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。
| モデル | コンテキストサイズ |
|---|---|
| GPT-4o | 128k tokens |
| Claude Sonnet 4.x | 200k tokens |
| Gemini 1.5 Pro | 1M tokens |
Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。
RAGの弱点：断片的な情報がハルシネーションを生む
RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。
RAG特有の問題点：
- 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある
- 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる
- 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する
こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。
Agent Harnessが「100ファイル以下」で高精度な理由
Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。
- プロジェクト構造の把握（
ls、findなど） - 関連ファイルの直接読み込み（
cat、read） - 完全なコンテキストを持った上でコード生成・編集
RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。
これにより：
- 実際に存在する関数・型・インターフェースのみを参照する
- インポート関係や依存構造を正確に把握する
- プロジェクト固有の命名規則や設計パターンに従う
ベクトル検索が有効なケースと直接読み込みが有効なケース
NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか？」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。
ベクトル検索が有効なケース：
- 100ファイルを超える大規模コードベース（モノレポ、大企業の内部リポジトリ）
- 広範なドキュメント検索（社内ナレッジベース、技術文書）
- リアルタイム情報の取得（外部ドキュメント、最新の仕様）
コンテキストに収まる場合に直接読み込みが有効なケース：
- 中小規模のプロジェクト（スタートアップのコードベース、個人プロジェクト）
- 特定モジュールへの集中作業
- 正確な依存関係の把握が必要な場合
RAG自体を強化する方向: GraphRAG という選択肢
「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。
GraphRAGの基本アイデアは次の通り：
- グラフ構築フェーズ: コーパス全体からLLMでエンティティ（人物、概念、ファイル、関数など）と関係を抽出し、ナレッジグラフを構築する
- コミュニティ検出: Leidenアルゴリズムなどでグラフをクラスタ化し、各コミュニティの要約を事前生成しておく
- 検索フェーズ: クエリにマッチしたノードから近傍ノードへ展開し、関係性のある情報を併せて取得する
これにより、ベクトル類似度だけでは拾えない「間接的に関連する情報」や「複数ホップ先の依存情報」を統合的に判断できるようになる。断片的コンテキスト問題への一つの解答と言える。
GraphRAGのトレードオフ
ただし、GraphRAGには運用コストが重くのしかかる：
- グラフ構築コスト: エンティティ抽出・関係推論がLLM呼び出しで、コーパスサイズに対して線形（あるいはそれ以上）にコストが増える
- 再構築頻度のジレンマ: 更新頻度を下げるとグラフがステイルになり古い関係を参照し続ける。上げるとLLM呼び出しコストが爆発する
- ノイズ増幅のリスク: 近傍展開を広げすぎると関連度の低い情報が混入し、かえって精度を落とす
選択の基準: グラフ維持コスト vs コンテキスト拡大コスト
結局のところ「RAGを賢くする」か「RAGを使わない」かは、どちらのコストに投資するかの選択になる。
| アプローチ | 主なコスト | 向いているケース |
|---|---|---|
| Agent Harness（直接読み込み） | コンテキストウィンドウ（トークン課金） | 中小規模・依存関係が明示的（コードベース） |
| 素のRAG | ベクトルDB運用・埋め込み計算 | 大規模・浅い参照で十分な文書検索 |
| GraphRAG | グラフ構築・再構築のLLM呼び出し | 大規模・関係性が本質的（社内ナレッジ、論文） |
Agent Harnessが「RAGなしで勝っている」ように見えるのは、コンテキストウィンドウの大容量化により、グラフ維持コストを支払わずに同等の統合的判断ができるようになったからだ。コンテキストに収まらない規模ではGraphRAGのようなアプローチが引き続き有効だが、100ファイル程度のコードベースなら、グラフを毎日再構築するより全ファイルを素直に読むほうがシンプルで安価になる。
まとめ
Agent Harnessが高精度に動く背景には、コンテキストウィンドウの大容量化と「直接読み込み」戦略がある。RAGが苦手とする「断片的で依存関係が複雑な情報」を、ファイルごと丸ごと参照することで回避している。
「100ファイル以下」という目安は、現在のAIのコンテキストサイズ（20k〜1Mトークン）と、一般的なソースファイルのトークン数から導き出されるシンプルな経験則だ。プロジェクト規模がこの閾値を超えるなら、RAGやGraphRAGなどのインデックス戦略を組み合わせることが有効になる。
コーディングエージェントを使う際は、自分のプロジェクトがこの「100ファイル」の目安のどちら側にあるかを意識することで、ツール選択やエージェント設計の指針が見えてくる。「RAGの精度をグラフで補う」方向と「コンテキストで殴る」方向はどちらもコスト構造の違いであり、コードベース規模と関係性の複雑さで使い分けるのが実務的だ。