こんにちは。LayerX のバクラク事業部 AI・機械学習部でサマーインターンをしていました足利です。サマーインターンについてはこちら。
こちらはLayerX AI エージェントブログリレー、29日目の記事です。
エンジニアにとって最も身近なAI AgentはClaude Codeなどのコーディングエージェントだと思います。
この記事では、コーディングエージェントに適した検索システムという切り口から、AI Agentをより良く設計するためのポイントについて考えてみたいと思います。
最先端の知見に触れるため、新しめの論文に触れながら解説していきます。
入門、AIコード生成のためのコンテキスト検索
AI Agentを上手く動作させるには、解かせるタスクの定義やコンテキストの設計が非常に重要です。
- タスク設計：解決したい課題について、LLMに丸投げせず、どの部分をLLMに解かせるべきかを分析し、必要に応じてプログラムによる処理と組み合わせること
- コンテキスト設計：タスクに対してLLMが適切に判断するのに十分なコンテキストとはなにかを分析し、適切に情報を与えること
コード生成の分野では、解かせるタスクはエンジニアがプロンプトで指示するため、多種多様です。
そのため、エージェントの開発者側でタスク設計を行うことができません。
したがって、今回の記事ではコンテキスト設計に重点を置きます。
研究テーマ1 何を探せば有益か？
AI Agentに関連する検索システムやRAGの検索システムを設計する際に陥りやすい罠として、「本当に必要なものが何かを考えずに、単に類似度が高いものを検索してしまう」というものがあります。
我々がコンテキストに含めて揚げるべき情報は、クエリと似たものではなく、タスクを解くのに役立つものです。
したがって、何が役に立つ情報であるかを考察することが重要です。
コーディングエージェント向けの検索システムにおいても、どんな情報をコンテキストに含めれば最も性能が高いのかについて研究されています。
ICSE 2025に投稿されたThe Fact Selection Problem in LLM-Based Program Repairという論文では、バグ修正をテーマにこの問題を分析しています。
本研究では、Pythonで記述された314種類のバグを対象に実験を行いました。
まず、バグを解決するために必要なコンテキスト情報を7種類に分類しました。
次に、全てのバグについて各種類の情報を含めるプロンプトと含めないプロンプトを全パターン作成し、LLMにバグ修正をさせました。
次の図は、含めた情報の数ごとにバグの解決率をプロットしたものです。
グラフを見ると、事実が多すぎると逆に精度が下がっており、情報が多ければ多いほうが良いわけではないと分かります。これは、プロンプトに含める情報が多すぎると逆にLLMが混乱することを意味します。
さらに、この論文中では最適な情報の組み合わせはバグごとに異なることが明らかになりました。つまり、この情報を与えておけば常に最高の性能になる、というような都合のいい情報は無かったようです。
私たちがAI Agentを設計するときも、タスクをよく観察し「何を探すのが有益か」を考えることが重要であると考えられます。
研究テーマ2 どのように探せば有益か
検索するべき対象が定まったら、具体的にそれを検索してくる手法が必要になります。
AI向けの検索ツールを設計する際には、解くべきタスクの性質に合わせた検索手法を作ることで精度を向上させられます。
この事実はコーディング向けAIの研究でも変わりません。
ASE 2024に投稿されたGraphCoder: Enhancing Repository-Level Code Completion via Coarse-to-fine Retrieval Based on Code Context Graphでは、
GitHub Copilotのようなソースコードの補完タスクを解かせる場合に適した検索手法を提案しています。
GraphCoderでは、対象としているコード補完タスクに合わせた検索システムを設計しています。コード補完のためには、現在編集中の部分を編集するために参考となるソースコードを見つけるのが有益です。そこで、単に文字列として見た目が似ているだけではなく、具体的なデータフローやロジックを含めた類似度が高いものを探す戦略を取ります。
そのために使われているのがCode Context Graph（CCG）です。
CCGはソースコードを周辺のコードのロジックの流れを含めてグラフ化したものです。
詳細の説明は省略しますが、なんとなく変数の参照関係など意味的関係があるステートメントがエッジでつながれていることが分かると思います。
GraphCoderでは、ソースコード中のすべてのステートメントに対して、関連する（グラフ上で近い）ステートメントから構成されるCCGのサブグラフを作成します。意図としては、全ステートメントに対して、周辺の関連度が高いソースコードを付属した情報として追加するためです。例えば、次の図のようなサブグラフを作成します。
GraphCoderの目標は、対象となるソースコード行から生成されたCCGのサブグラフと最も意味的に近いCCGのサブグラフを持つステートメントを探すことです。これにより、構造的・意味的に類似したソースコードを探せるからです。
グラフの意味的な近さは、グラフの編集距離のようなものを用いて計算します。構造的に類似したコードほど意味が近いと判断されます。
この考え方は、リポジトリを単なる汎用的な文書集合とみなして文字列で検索するのとは大きく異なります。
ソフトウェアという対象ドメインにおいて、人間の専門家がどのように情報を整理しているかを分析し、それに合わせたデータ構造を作ることで、より精度を高めようとしているのです。
より具体的に検索システムの詳細を見てみましょう。
検索システムに入力されたソースコード行からCCGのサブグラフ（Sliced Query CCG）が作られ、検索されているのが分かりますね。
詳細は省きますが、計算の過程でいったん軽い手法（Course-grained Code Retriever）で大雑把に絞り込み、後から正確で計算量の多い手法（Fine-gained Code Re-Ranker）で最終的な出力を出させるよう工夫しています。
GraphCoderはあくまでも提案されている検索手法の一例です。しかし、ひとつの手法をなんとなく眺めてみるだけでも、リポジトリレベルのソースコード検索は単なる文書検索とは圧倒的に異なる工夫が行われているのが分かってもらえたと思います。
コーディングエージェント向け検索システム
近年のコーディングエージェントは、Claude Codeをはじめ複雑なタスクを解かせられるようになってきました。
そのため、単なるコード生成を超えたシステムになってきています。
あくまで検索はエージェントが必要に応じて呼び出すツールの一種という立ち位置に変わってきています。
このようなシステムでは、従来よりも検索システムに対する要求は難しくなります。
例えば高度なバグ解消タスクを頼む場合には、ユーザーが記述した症状から、ソースコード中の原因を推論して見つけなければなりません。
このような検索はもはやクエリとの類似度を考えるだけでは不十分です。
エージェントが高度な推論をするほど、必要なコンテキスト情報も高度に推論しないと得られません。
この記事では簡単に紹介するだけにとどめますが、ACL2025に投稿されたLocAgent: Graph-Guided LLM Agents for Code Localizationという論文では、検索に特化したAI Agentが自律的に知識グラフ上を探索することで、コード生成に特化したAI Agentを補助する仕組みが提案されています。
エージェントベースの手法は、これまでの手法を大きく上回る精度のコンテキストを提供できる可能性を秘めています。しかし、コストがかかる、実行時間が長すぎるなどの問題を抱えており、決して銀の弾丸ではありません。
さらに、検索向けAI Agent自体のコンテキスト検索はどうするべきかという問題も出てくるため、研究しがいのあるテーマです。
おわりに
この記事では、コーディングエージェント向けの検索というテーマを最新の論文を交えて説明しました。
今回紹介した次のような考え方は、業務レベルのAI Agent開発に役立つと思います。
- タスクに合わせた有益な情報が何かを考える
- 対象ドメインに合わせた論理構造を反映した検索手法にする
この記事を通じて、コーディングエージェントの奥深さ、検索・推薦システム設計の面白さを感じていただけたら幸いです。
コメント