LayerX AI エージェントブログリレー51日目の記事です。前回の記事は、@unachang113 の 「大きなHTMLをAIで取得したくなったときに考えたこと」 でした！
バクラク事業部 CTO の @yyoshiki41 です！
今回、Coding Agent に代表されるような AI 開発ツールがコード検索をどのように実現しているかについてみていきます。
前置き
汎用的なチャットボットであるChatGPTの登場以前から、LLMを利用したコード生成の製品化は進んでいました。2021年に発表されたGitHub Copilotは、GitHubとOpenAIによる共同開発[1]で、搭載されたモデルはGPT-3派生で公開ソースコードを含むデータセットで学習され、より自然言語からのコード生成に特化したCodex[2]（注: 生成モデルの名称であり、2025年にリリースされた同名のCLIベースのCoding Agentとは異なります）が利用されました。
多くのプレイヤーがこのソフトウェア開発領域 でしのぎを削っています。コードを書くのみではなく、コードレビューやソフトウェア品質保証のためのテスト実行など、開発プロセスのあらゆるフェーズでAIが活用されています。
Coding Agentはタスクを与えられた際、コード生成をすぐに行うわけではなく、まずドキュメントや既存のコードベースを検索し関連するコードをコンテキストとして利用できるように準備します。コード検索はタスクを行うプロジェクトを理解し、コードを生成する前の必須のステップといえます。
コード検索固有の課題
自然言語検索はこれまでも多くのシステムで実装されてきました。キーワードマッチによる検索、ステミングや正規化を施しキーワード検索よりも広範な検索を可能にした全文検索、加えてLLM登場後は、セマンティック検索がこれまで以上に注目を集めるようになりました。
検索対象となる文章を適切な単位（チャンク）で分割し、そのチャンクをベクトル化してインデックス化します。ユーザーからのクエリも同様にベクトル化し、インデックスと比較して類似度の高いチャンクを取得します。この手法は意味的な文脈を考慮させたい場合において、有効な手段として拡がりました。LLMを利用した検索応答の生成においては、外部の知識ベースからセマンティック検索を行い、その情報を基に応答を生成するRAG（Retrieval-Augmented Generation）も広く注目を集めました。
自然言語で人間が読むことを前提としたドキュメントに対する検索でセマンティック検索が盛り上がりを見せる一方、コードベースには異なるアプローチが求められます。
コードの構造理解
コードベースは自然言語テキストと異なる（文書）構造をしています。段落や行数ベースなどのナイーブなチャンク分割では、関数定義と呼び出し、型やインターフェースなどの役割関係を断ち切り、機能的関連（意味的なまとまり）を壊してしまいます。したがって、コード検索では構造単位（関数・クラス・モジュール）や依存関係の追跡、場合によってはコードベース全体のグラフ構築まで含めて「まとまり」を再現するアプローチが重要になります。
またインデックスがコードの変化に追随し続けるコストも掛かってきます。
各ツールのアプローチ
上記の課題がある中、主要なAI開発ツールはコード検索をどのように実現しているか。公開情報から読み取れる各ツールのアプローチを紹介します。
GoDoc
AI開発ツールではありませんが、Go言語の公式ドキュメントツールであるGodocは、コード検索の基本的なアプローチを理解する上で参考になります。ビルド時にIndexerを通じてAST（抽象構文木）を走査し、識別子単位で出現箇所と共にドキュメントを組み立てます。宣言と使用箇所の両方を記録し、正確なコード構造の把握を実現しています。
公式ツールということもあり、AST解析を用いて正確にコード構造を把握している点が特徴的です。これにより、ユーザーは特定の関数やメソッドに関する情報を識別子ベースで検索可能になっています。
Claude Code / Codex / Gemini CLI
CLI型のエージェントはいずれも構文解析やコードベースのインデックス化を行わず、ローカル上でLLMにgrepやripgrepなどのツールパラメータを推論させ、キーワード・正規表現検索を実行する方法を採用しています。（Claude Codeは標準でripgrepバイナリを同梱し、OpenAIのCodex CLIもクロスプラットフォーム向けにrgバイナリを配布し、ツールチェーンから安全に呼び出せるよう依存関係をセットアップしています[3]）。
Cladue Codeがリリースされた際、grepなどのローカルツールへの権限をわたし、パワフルにコードベースを走査している点は印象的でした。
他方でパターン検索を繰り返し行うため、クライアントとLLMでの逐次的なターンが増え、実行速度の面で課題があることも指摘されています。
こうしたローカルで動作するCLI型エージェントは事前インデックスを持たず、LLMがツールパラメータを推論してローカル検索を繰り返すことで、最新のコードベースに追従します。また、ソースコードを外部に持ち出さずにコードを走査できる点も特徴です。
Claude Codeはローカルで動作し、開発者と同じツールを用い、同じメンタルモデルを共有することが多くの開発者に選ばれる理由の１つにあげています[4] 。
Works in your terminal: Not another chat window. Not another IDE. Claude Code meets you where you already work, with the tools you already love.
Cursor
CursorはIDEに搭載されているキーワード検索に加えて、コードベースのインデックス化をオプトイン機能として提供しています。インデックス化を有効にすると、検索や補完の品質向上を目的にEmbeddingsがクラウド上に作られ、コードベース全体のセマンティック検索が可能になります。5分起きに自動でのインデックス更新が行われ、ファイル単位ではなく、関数やクラス、論理的なコードブロックなど意味のある単位に分割されます。テキストの分割ではなく、コードの構造的意味を保持した形でEmbeddingsが生成されます[5]。
エージェントとのコラボレーションをより強化するとして発表されたCursor 2.0では、エージェントはgrepなどのキーワード検索とセマンティック検索を組み合わせて利用し、ComposerというCursor上での低遅延なコーディングを可能なように強化学習されたモデルを利用してコード生成を行います。
大規模なコードベースの理解と操作においてより高速に動くことを目指して、モデルがツール使用において効率的な選択を行い、可能な限り並列処理を活用するように促す仕組みを採用しているとComposerの特徴がリリース時に紹介されています[6].
Windsurf
Windsurfは、コードベースをインデックス化したうえで独自のM-QueryによるRAGを実行していると語っています[7]。従来のEmbeddingsによるベクトル化されたチャンクの類似度に依拠するのではなく、M-Queryは検索クエリと各ファイルをLLMに並列で渡し、関連性を推論させることを並列で行い、リランキングするという独自の検索手法です[8]。
AI モデルの情報検索能力の限界 Needle in a haystack（干し草から針を見つける）から、M-Queryでは大量の計算資源と独自のインフラストラクチャを活用して、複数の関連ドキュメント（複数の針）を高速かつ高精度で特定するために設計されていると説明しています。
更に、Fast Contextという関連コードを検索する専用のサブエージェントも搭載しています。このサブエージェントに利用されるモデルは、SWE-grep/SWE-grep-miniというコード検索用に訓練されたカスタムモデルです[9]。
Greptile
Greptileは、検索精度を高めるためにコードをそのままEmbeddingsにするのではなく、関数ごとに自然言語の要約を生成してからベクトル化するパイプラインを採用しています。まずチャンクを意味的にまとめ、その説明文を embed した（埋め込んだ）上で類似度検索を実行することで、呼び出し側と定義が別言語で書かれていてもヒット率を維持できると報告しています[10]。
さらに、リポジトリ全体をファイル・関数・外部呼び出しといったノードで構成されたグラフに変換し、依存関係や利用箇所を高速にたどれるようにしています。レビュー対象の関数が変更された際には、グラフから呼び出し元や類似パターンを照会し、影響範囲の洗い出しやスタイルの差異を自動で指摘するワークフローが公開されています[11]。
セキュリティ面
インデックス化を行わない場合には問題となりませんが、コードベースから二次的なインデックス情報を生成して、外部クラウド上に保存する場合、機密情報の取り扱いは関心事として議題にあがります。企業のソースコードは知的財産であり、漏洩すると重大な損害を被る可能性があります。
Cursor はセマンティック検索を有効化すると、開いているフォルダの .gitignore / .cursorignore を除いてスキャンし、ファイルハッシュから構成されるMerkle treeを生成します。差分が検出されたチャンクだけをサーバーに送信してベクトル化し、ハッシュ付きで Turbopuffer に保存するため、同じコードベースを再インデックスする際はキャッシュが流用できます。
推論時は埋め込みベクトルを計算し、Turbopuffer上で最近傍検索を実行して、難読化されたファイルパスと該当行範囲をクライアントに返します。クライアントは該当ファイルを読み出し、チャンクをサーバーに送信して、回答生成を行います。そのため、プライバシーモードでは平文のソースコードがクラウド上で永続化されないよう配慮されています[12]。
おわりに
AI開発ツールにおいてコード検索は重要な要素技術であり、各ツールは独自のアプローチでこの課題に取り組んでいます。コードの構造理解や他のライブラリへの依存考慮が必要で自然言語のドキュメントとは大きく異なります。直近では検索ツールコールを強化学習したモデルが流行りを見せているなど、今後もどのような進化がみれるか楽しみな領域です。
-
https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/ ↩︎
-
https://github.com/openai/codex/blob/a1ee10b43815a10da3ac09111d793d3ded1b0dc7/codex-cli/scripts/install_native_deps.py ↩︎
-
https://docs.claude.com/en/docs/claude-code/overview#why-developers-love-claude-code ↩︎
-
https://docs.windsurf.com/context-awareness/overview#does-windsurf-index-my-codebase ↩︎
-
https://www.greptile.com/docs/how-greptile-works/graph-based-codebase-context ↩︎
Discussion