数万ファイル規模のリポジトリでエージェントに「この関数の呼び出し元を直して」と頼んだとき、見当違いの場所をいじられた経験はないでしょうか。原因の多くは、エージェントが探すべき場所を絞り込めず、無関係なコードまで文脈に取り込んでしまうことにあります。
Antigravity の最近のポイントリリースで部分文字列検索が高速化されました。これを「待ち時間が減って快適になった」で終わらせるのはもったいない話です。検索が速いということは、エージェントに渡す文脈を組み立てる前段で、何度でも安く絞り込めるという意味でもあります。速度はそのまま、グラウンディング（文脈の根拠付け）の精度に転化できます。
私自身、個人開発で大きくなったモノレポを抱えていて、エージェントに丸ごと読ませると的外れな提案が増える、という壁に何度もぶつかってきました。検索を文脈設計の道具として使い直したところ、修正の精度が体感で大きく変わりました。その考え方を共有します。
なぜ大規模リポジトリでエージェントは外すのか
巨大なコードベースでエージェントの精度が落ちる原因は、能力不足よりも文脈の与え方にあります。私が自分のリポジトリで失敗を振り返ると、的外れのおよそ80%は「渡した文脈が多すぎる」ことが引き金でした。
関連の薄いファイルを一緒に渡すと、エージェントはそれらを手がかりとみなして、似て非なる箇所を編集してしまいます。逆に、必要なファイルが欠けていると、想像で補おうとして辻褄合わせのコードを書きます。つまり、多すぎても少なすぎても精度は落ちます。狙うのは過不足のない一束です。
ここで速い検索が効いてきます。安く何度も絞り込めるなら、最初から完璧な検索語を当てる必要はありません。広く当てて、結果を見て、狭く絞る、という往復を許容できます。
2段構えで絞り込む
私は検索を1回で終わらせず、必ず2段に分けています。
第1段: シンボルで広く当てる
まずは関数名やクラス名そのもので全体を当て、分布を把握します。どのディレクトリに集中しているか、想定外の場所に飛び火していないかを見ます。
# 第1段: シンボル名で全体の分布を把握する
rg --no-heading -n "processPayment" \
| awk -F: '{print $1}' | sort | uniq -c | sort -rn
ファイル単位の出現数を集計すると、「どこを本丸とみなすべきか」が一目で分かります。出現が1〜2件のファイルは周辺、十数件のファイルは中心、と当たりを付けます。
第2段: 文脈語で狭く絞る
次に、本丸とおぼしき範囲だけに対象を絞り、修正の目的に直結する語で再検索します。たとえば「呼び出し元の引数を変える」のが目的なら、呼び出しパターンそのものを当てます。
# 第2段: 中心ディレクトリ内で呼び出しパターンだけを抽出
rg --no-heading -n "processPayment\(" src/billing/ \
--type ts -C 2
この2段構えにすると、エージェントに渡す候補が「全体」から「中心ディレクトリの該当呼び出し周辺」まで一気に縮みます。文脈の量を約90%削れる場面も珍しくありません。
検索ノイズを構造的に下げる
絞り込みの精度は、検索対象から無関係なものをあらかじめ除けているかにも左右されます。ビルド成果物や生成物が検索に混ざると、第1段の分布把握が歪みます。
私はリポジトリ直下に検索専用の除外設定を置いています。
# .ignore — 検索から外す対象（ビルド・生成物・巨大データ）
node_modules/
.next/
dist/
build/
*.min.js
*.map
public/content/ # 生成された HTML 出力
src/generated/ # ビルド時生成物
生成物を除くだけで、第1段の集計が実体のあるソースだけを反映するようになります。私の環境では、この除外を入れる前後で、分布上位に出てくるファイルの顔ぶれが入れ替わり、当たりの精度がはっきり上がりました。生成物が検索結果の上位を占めていたためです。
関連ファイルだけを束ねて渡す
絞り込んだ後は、エージェントに渡す文脈そのものを軽量に組み立てます。第1段の集計結果から、出現数が閾値を超えたファイルだけを束ねる小さなスクリプトが便利です。
#!/usr/bin/env bash
# focus-context.sh <symbol> <min-hits>
# 出現数が閾値以上のファイルだけを文脈候補として列挙する
set -euo pipefail
symbol="$1"; min="${2:-3}"
rg --no-heading -n "$symbol" \
| awk -F: '{print $1}' | sort | uniq -c \
| awk -v m="$min" '$1 >= m {print $2}' \
| while read -r f; do
echo "=== $f ==="
# 該当シンボル周辺だけを抜く（前後8行）
rg -n -C 8 "$symbol" "$f"
echo
done
このスクリプトは、出現数が閾値以上のファイルに限って、シンボル周辺の数行だけを抜き出します。ファイル全体ではなく該当箇所の前後だけを渡すことで、文脈量をさらに削れます。閾値は最初は3前後から始めて、結果を見ながら上下させるのを推奨します。広すぎれば上げ、取りこぼしがあれば下げる、という調整です。
ありがちな落とし穴と回避策
この手法で踏みやすい罠を3つ挙げ、それぞれの回避策を添えます。
第1段を飛ばさない
いきなり狭い検索を投げると、当たりが付いていない状態で絞ることになり、本丸が検索範囲の外にあったときに丸ごと見落とします。遠回りに見えても、分布把握の第1段は省かないのが回避策です。結局そのほうが速く着地します。
束ねた文脈を保存しない
検索結果をいったんファイルに保存してエージェントへ渡す運用にしていると、その後の編集で実体がずれます。古い文脈は沈黙したまま間違いを連れてくるので、対処としては、束ねた文脈はその場で生成して使い捨てにし、保存しないことです。
本番反映の前に範囲を再確認する
第2段で絞った範囲が、本番環境に効く修正の全体をカバーしているとは限りません。本番デプロイの前に第1段の分布へ戻り、絞り込みで落とした周辺ファイルに修正漏れがないかをもう一度確かめると、後追いの不具合を回避できます。私はこの再確認を、push 前の手順に組み込んでいます。
速度を精度に変える
部分文字列検索の高速化は、表向きは快適さの改善ですが、本質的には「絞り込みのコストが下がった」ことを意味します。コストが下がったなら、これまで一発勝負だった検索を、広く当てて狭く絞る往復に変えられます。その往復こそが、大規模リポジトリでエージェントに過不足ない文脈を渡すための土台になります。
Dolice Labs の運用でも、エージェントの精度を上げる近道は、賢いモデルを待つことよりも、渡す文脈を整えることでした。速い検索は、その文脈整備をほとんど無料にしてくれます。手元の巨大なリポジトリで、まず第1段の分布把握から試していただければと思います。