コードRAGとコーディングエージェント

約10分

AIコーディング支援、リポジトリ検索、コード生成RAGを設計したい方

コードRAGとは、自然文の文書ではなく、ソースコード、型定義、テスト、設定、Issue、PR履歴、設計メモなどを検索し、コード生成や修正に使うRAGです。コード生成に検索を組み合わせる有効性は CodeRAG-Bench などで検証されており、リポジトリレベルのコード生成に注目したサーベイも公開されています。[1][4]

コードでは通常のRAGがそのまま使えない

自然文RAGでは、文書を一定文字数や段落で分割して検索することがよくあります。しかし、コードではそれだけでは不十分です。

コードには、自然文と違う構造があります。

関数
クラス
型
import / export
呼び出し関係
テスト
設定ファイル
生成ファイル
ビルドスクリプト
過去の変更履歴

関数の途中でチャンクが切れると、戻り値、例外、型、依存関係が失われます。逆に複数の無関係な関数をまとめると、LLMが関係ないコードに引っ張られます。

コードRAGが扱う情報

コードRAGの検索対象は、ソースコードだけではありません。

情報	使い道
ソースコード	実装の理解、修正箇所の特定
型定義	APIの入力・出力、制約の理解
テスト	期待される挙動、回帰確認
README / docs	設計意図、使い方
設定ファイル	ビルド、Lint、ルーティング、環境差分
Issue / PR	過去の議論、変更理由
コミット履歴	なぜその実装になったか
実行ログ	失敗原因、環境依存の確認
エージェント指示ファイル	リポジトリ固有の作業ルール

コーディングエージェントは、これらを組み合わせて「どこを読めばよいか」「何を変更すべきか」「どう検証すべきか」を判断します。

コードRAGの基本フロー

graph TD
    Task["自然文の開発タスク"] --> Plan["調査計画"]
    Plan --> Search["コード・文書検索"]
    Search --> Read["関連ファイル読解"]
    Read --> Edit["コード編集"]
    Edit --> Test["テスト・Lint実行"]
    Test --> Observe["結果確認"]
    Observe -->|失敗| Search
    Observe -->|成功| Summary["変更説明"]

通常のRAGが「回答生成」で終わるのに対して、コードRAGは編集、実行、検証までつながります。

チャンク設計: 行ではなく構造で切る

コードRAGの品質は、チャンク設計で大きく変わります。

悪い例は、単純な固定長分割です。

1-80行
81-160行
161-240行

この分割では、関数やクラスの途中で切れる可能性があります。

より良い考え方は、構文構造を使うことです。

分割単位	向いている検索
関数	特定処理の理解
クラス	状態や責務の理解
型定義	API契約の理解
ファイル	モジュール全体の理解
ディレクトリ	サブシステム単位の理解
呼び出しグラフ	影響範囲調査

2025年のcASTのような研究では、ASTを使って意味的にまとまったチャンクを作る重要性が示されています。コードでは、文字数よりも「構造が壊れていないこと」が重要です。[2]

検索方式: ベクトル検索だけでは足りない

コードRAGでは、複数の検索方式を組み合わせます。

検索方式	例	強み
テキスト検索	`rg "functionName"`	名前、文字列、エラーの完全一致
シンボル検索	定義・参照検索	関数や型の関係を追える
ベクトル検索	似た処理の検索	言い換えや意図ベースの検索
AST検索	構文パターン検索	特定構造の発見
実行結果検索	テストログ、エラー	失敗原因の特定
履歴検索	Gitログ、PR	変更理由の理解

実務のコーディングエージェントは、まず高速な文字列検索で手がかりをつかみ、必要に応じて意味検索やファイル読解に進むことが多くなります。

コーディングエージェントとRAGの関係

コーディングエージェントは、RAGを内部部品として使います。ただし、役割は単なる検索ではありません。

エージェントの行動	RAGとの関係
タスクを理解する	関連ドキュメント、Issue、既存実装を読む
変更箇所を探す	コード検索、シンボル検索、依存関係検索
実装方針を決める	類似実装、設計パターン、テストを参照する
編集する	取得した文脈に基づいてコードを変更する
テストする	実行結果を次の文脈として使う
修正する	エラーログを検索・読解して再編集する
説明する	根拠ファイルと検証結果を引用する

つまり、コーディングエージェントにとってRAGは「読む能力」の中核です。

リポジトリレベルで難しくなる理由

小さな関数生成と、リポジトリ全体の修正は別問題です。

リポジトリレベルのタスクでは、次の難しさがあります。

変更が複数ファイルにまたがる
既存設計に合わせる必要がある
テスト、Lint、型チェックが関係する
生成コードではなく既存コードの変更が必要
影響範囲を見誤ると回帰が起きる
プロジェクト固有のルールを守る必要がある

SWE-PolyBenchのようなベンチマークが登場しているのは、コーディングエージェントの評価が「単体のコード問題」から「実リポジトリでの変更」に移っているためです。[3]

エージェント文脈ファイルの重要性

近年のコーディングエージェントでは、AGENTS.md や類似の文脈ファイルが重要になっています。Agent README 研究では、エージェント向けの文脈ファイルがどのような情報を含むかが調査されています。[5] OpenAI Codex も、リポジトリ内の AGENTS.md を使って作業指示を読む仕組みを持っています。[6]

コードRAGの観点では、これは「常に参照すべき高優先度の文書」です。

たとえば、次のような情報が入ります。

本番ビルドコマンドは承認なしに実行しない
日本語をソース・オブ・トゥルースにする
既存UIを変更しない
検証にはどのコマンドを使うか
生成ファイルと手編集ファイルの境界

エージェントがこれを読まずにコードだけ検索すると、技術的には正しいがプロジェクト方針に反する変更をしてしまいます。

コードRAGの評価

コードRAGは、回答品質だけで評価できません。実際にコードが動くかが重要です。

評価観点	確認すること
Retrieval Recall	必要なファイル・関数・テストを見つけたか
Context Precision	不要なコードを読みすぎていないか
Edit Correctness	変更が要求を満たすか
Regression Safety	既存挙動を壊していないか
Test Success	テスト、Lint、型チェックが通るか
Style Consistency	既存コードの書き方に合っているか
Minimality	無関係な変更を避けているか
Traceability	変更理由と根拠を説明できるか

自然文RAGでは「正しい回答」がゴールですが、コードRAGでは「正しく変更され、検証できること」がゴールです。

コードRAGの実務設計

1. まず文字列検索を強くする

コードでは、関数名、型名、エラー文、テスト名が強い手がかりになります。意味検索より先に、正確な検索が効く場面が多くあります。

2. 構造情報をインデックスする

ファイル本文だけでなく、次の情報を持つと検索精度が上がります。

シンボル名
定義位置
参照位置
import / export
テスト対象
モジュール依存
所有ディレクトリ

3. テストを文脈として扱う

テストは仕様の一部です。実装だけでなく、関連テストを検索し、期待挙動を確認することが重要です。

4. 実行結果を次の検索に使う

テスト失敗ログは、次の検索クエリになります。

失敗ログ → エラー名検索 → 関連テスト読解 → 修正 → 再テスト

このループは、Agentic RAGと相性が良い設計です。

5. 変更権限と安全ルールを分ける

エージェントが読める範囲と書ける範囲は分けて考えます。

操作	例
読む	ソース、テスト、ドキュメント、設定
書く	指定された実装ファイル、テスト
承認が必要	本番ビルド、破壊的操作、外部送信
禁止	secrets、認証情報、無関係な大規模整形

RAGはコーディングエージェントでどう変わるか

コーディングエージェントの登場で、RAGは「回答のための根拠検索」から「作業のための文脈管理」へ広がっています。

今後のコードRAGでは、次の方向が重要になります。

ASTや型情報を使った構造化検索
テスト、実行ログ、カバレッジとの統合
リポジトリ固有ルールの常時参照
過去の修正履歴を使う継続学習的なメモリ
変更前後の差分を評価するエージェント
コードレビューコメントを検索・反映するワークフロー

まとめ

コードRAGは、コード、テスト、設定、履歴、エージェント指示を検索して開発作業に使うRAG
コードでは、固定長チャンクよりも関数、クラス、AST、シンボル単位の構造化が重要
コーディングエージェントは、検索、読解、編集、テスト、再修正のループでRAGを使う
評価では、検索精度だけでなく、実際の変更が動くか、既存挙動を壊さないかを見る

参考文献

クイズ

RAGの今後

Agentic RAGとは