8月28日、Sourcegraphが「A smarter way to run code migrations with less LLM context」と題した記事を公開した。大規模なコードマイグレーションをAIエージェントで実行しようとすると、トークンコストがすぐに爆発する。標準的なアプローチでは、スキャンした数千ファイルの中間データをそのままLLMのコンテキストウィンドウに流し込む。しかしコンテキストが多ければ多いほど精度が上がるわけではない。Sourcegraphはこの問題をアーキテクチャレベルで解決する方法を提示している。

「全部LLMに渡す」がなぜ問題なのか

マイグレーションや監査タスクで本当に必要なのは、生の中間データではなく整理された最終結果だ。スキャン対象が数千ファイルに及ぶ場合、それらをそのままコンテキストウィンドウに流し込めば、コストが膨らむだけでなく、モデルが無関係な情報に引きずられて精度が落ちるリスクもある。

コスト効率はいまや技術的な関心事にとどまらず、AIツール選定の重要な評価軸になりつつある。

※編集部注：EYが2026年7月に実施した調査によれば、企業がAI活用をスケールさせるにつれ、トークンコストへの経営層の目線が厳しくなっているという。元記事には含まれていないが、背景として参照した。

Sourcegraphの解法：サンドボックス内でスクリプトを実行し、LLMには結果だけ渡す

SourcegraphのDeep Searchは、この問題をアーキテクチャレベルで解決する。サンドボックス環境でスクリプトを実行できるEvaluatorツール（Sourcegraph 7.3で導入）を使い、Sourcegraphの検索APIと組み合わせることで、以下の処理をLLMの外で完結させる。

• 複数の検索を横断して実行
• データのクロスリファレンスとフィルタリング
• 件数の集計
• CSV、JSON、SVGレポートといった構造化アーティファクトの生成

LLMが受け取るのは集約された結果と最終アーティファクトのみ。数千ファイルの生の内容はコンテキストウィンドウに入らない。

記事中では kubernetes/kubernetes リポジトリの pkg/ 配下でTODOコメントが最も多いファイルをスキャンし、CSVとSVGチャートを出力する例が示されている。スキャン時に読み込んだファイルの内容はLLMに渡らない。

なお、Deep SearchはSourcegraph Enterpriseで利用可能であり、Evaluatorツールはバージョン7.3以降が対象となる。試用を検討する場合は利用中のエディションとバージョンを事前に確認してほしい。

具体的なマイグレーションシナリオ

最もわかりやすい活用例がパッケージ移行だ。old/package から new/package への移行を進めたい場合、Deep Searchに「古いパッケージをまだインポートしているリポジトリを全件洗い出してCSVにまとめろ」と指示するだけで、チームがすぐ作業に入れる移行チェックリストが生成される。

この方法でコスト面で得られるメリットは3点だ。

1. 支払うのは高レベルなインサイトに対してのみ。中間ファイル処理のトークンは不要
2. モデルが無関係なコードに気を散らされない。精度の維持につながる
3. 構造化データがそのまま使える。チームが追加加工なしに作業を開始できる

マイグレーション以外の用途

記事では以下のユースケースも挙げられている。

• インベントリ管理：共有サービスが組織全体でどう利用されているかの把握
• コード健全性チェック：Log4jのバージョン2.17未満など、古い・脆弱な依存ライブラリを使うリポジトリの特定
• 実装パターンの比較：複数リポジトリ間の実装の一貫性チェック

いずれも「大量のファイルを読み込んで何かを探す」タスクであり、検索・集計をサンドボックス側に委ねることで同様のコスト削減効果が期待できる。

読者へ

「検索・集計・整形はサンドボックスで、推論だけLLMで」という役割分担は、AIエージェントのアーキテクチャ設計において汎用的な原則として応用できる。大規模マイグレーションや監査を計画しているチームはもちろん、エージェントのトークン消費を構造的に見直したいエンジニアにとっても参考になるアプローチだ。Evaluatorツールの詳細はchangelogのリリースノートも合わせて確認してほしい。

詳細はA smarter way to run code migrations with less LLM contextを参照していただきたい。