技術・研究 · · Team LATENT
ColGrep-Agentでコード探索をローカル2Bへ任せる
大型モデルが計画と編集を担い、ローカルの2Bモデルがコードを探す。ColGrep-Agentの分業、APIトークン削減と時間・正答率の交換条件、既存のローカルLLM構成との違いを読む。
AIに不具合の修正を頼むと、変更箇所を探すだけで何度も検索とファイル読み取りが走る。その探索まで大型モデルへ任せると、候補のコードや検索履歴がAPIの入力に積み重なる。LightOnが2026年10月12日に公開したColGrep-Agentは、この工程を手元の2Bモデルへ分ける仕組みだ。
小型モデルに任せるのは、質問に関係するコードの特定だ。計画、編集、テスト、採用の判断は上位のエージェント側に残る。大型LLMを丸ごと手元へ移す構成と比べると、ローカルで引き受ける範囲がはっきりしている。
この記事の要点
- ColGrep-Agentは、20億パラメータのローカルモデルにコード探索を任せる仕組みだ。必要なファイル・行・コードを上位エージェントへ返す。
- LightOnの52問・13リポジトリの評価では、APIトークンが34.3%減った。一方、所要時間は13.0秒から21.6秒に延び、正答率は83.3%から80.8%になった。
- コード探索をローカルに分担しても、上位エージェントまでローカル化されるわけではない。クラウドモデルへ返すコードの範囲と、トークン削減に対して許容する待ち時間・正答率を見て導入を判断する。
大型モデルとローカル2Bの分担
質問を渡し必要なコードだけを受け取る
1 上位エージェント
不具合の説明を読む → 探索する問いを渡す。計画と編集を担当する。
2 手元のColGrep-Agent
ColGrepで検索 → 候補を読む → 参照をたどる。探索を繰り返す。
3 上位へ返す結果
ファイル名＋行範囲＋コード → 上位が確認し修正とテストへ進む。
探索を任せると何が変わるか
ColGrepはコードの意味を使う検索ツールで、内部の検索基盤がNextPlaidだ。ColGrep-Agent-2Bは、その検索を呼び出して候補を読むモデルを指す。実行コマンドのcolgrep --agentは、モデルと検索ツール、読み取り専用の端末操作を組み合わせる。
たとえば「再試行の回数はどこで決まるか」と聞く。名前を一度検索して終えるのではなく、候補を読み、設定を参照する別のファイルも探す。上位へ戻るのは説明だけでなく、確認できるコードの場所だ。上位モデルが同じ探索を一から繰り返す負担を減らせる。
モデルカードでは、検索、読み取り専用terminal、結果を確定するfinishの三つを使い、10ターン以内で場所を特定する構成が示される。SWE-bench Liteなどの評価も、修正パッチの完成ではなくファイルや行の特定へ変換している。元のベンチ名だけを見て、不具合修正の成功率と受け取ると範囲を広げすぎる。
トークンと時間と正答率を一緒に読む
Claude Codeとの統合評価は、Sonnet 5.5で52問を解く比較だ。13リポジトリで各問を3回ずつ、検索構成を変えた4条件で実行している。合計624セッションであり、624件の独立した課題ではない。
| 条件 | APIトークン削減 | 正答率 | 1問の時間 |
|---|---|---|---|
| 標準Grep | 基準 | 83.3% | 13.0秒 |
| ColGrepを直接使用 | 24.6% | 79.5% | 15.0秒 |
| ColGrep-Agentへ委譲 | 34.3% | 80.8% | 21.6秒 |
| 両方を使うBalanced | 21.2% | 83.3% | 17.7秒 |
削減率の対象はClaude Codeが使うAPIの入力・出力トークンだ。ローカル2Bの生成トークンは含まない。34.3%の削減率の95%信頼区間は28〜40%で、検索途中の情報を大型モデルの会話へ何度も載せない設計と対応している。
減った量と増えた時間を並べる
公式のGrep対ColGrep-Agentの観測値
APIトークン
約142k → 約93k。削減率は34.3%。ローカル側の計算は別。
待ち時間
13.0秒 → 21.6秒。平均的な探索が速くなった結果ではない。
正答率
83.3% → 80.8%。有意差なしという説明は同等性の証明にならない。
開発元は正答率に統計的な有意差がないと説明するが、低下を除外できないことも明記している。キャッシュを考慮したAPI費用も1問7.3セントから4.4セントへ減った。ただし手元の計算資源、待ち時間、人の確認、失敗後の再探索を含む総費用とは区別したい。
2Bを動かす容量とローカルの範囲
既定のcolgrep-agent-2B-Q8_0.ggufは約2.5GBで、初回に取得する。モデルファイルの容量と、実行中の最大メモリは別の数字だ。公式ブログはM3 ProのMetal使用時に1問約20秒、ピーク3〜4GBと記している。WindowsのGPUやCPUだけで動かした場合の必要量を、この値から確定することはできない。
GPUを利用できる場合は加速し、利用できなければCPUへ切り替える。Apple SiliconではMetal、ほかの対応GPUではVulkanの経路が案内される。索引や他のアプリに使うメモリもあるため、空き容量の確認はモデルの2.5GBだけでは済まない。
検索と2B推論は端末内で動かせる。ただしクラウドのCodexやClaude Codeへ結果を戻せば、そのコードは上位側の入力になる。機密コードを扱う場合は、検索の実行場所と結果の送信先を分けて確認する必要がある。
CodexやClaude Codeへどう組み込むか
公式にはmacOS・Linux・Windows向けの導入経路がある。ColGrepの導入後にモデル取得、索引作成、単独の質問、エージェント統合という順で確かめられる。以下は公式コマンドの紹介で、この記事の制作時にはモデルの取得もベンチマークも実行していない。
colgrep --install-agent
colgrep init
colgrep --agent --json "where are retries configured"
colgrep --install-codex
最初の行は約2.5GBの取得を伴う。Claude Code向けはcolgrep --install-claude-codeで、hookが検索手段を提案する。必ずその道具を使わせる設定ではない。GitHubの説明ではClaude Codeはhookを全面的に扱い、Codexなどの統合は現時点では基本的なものとされる。同じ統合の深さを前提にしない方がよい。
ローカルLLMと小型モデルの分業をつなぐ
LATENTのローカルLLM構成の記事では、どの大きさのモデルを、どのメモリへ置いて日常的に使うかを考えた。ColGrep-Agentでは問いが少し変わる。上位の大型モデルを維持しつつ、検索という繰り返しの工程を小型モデルへ渡せるか、という判断になる。
Strataは大きなMoEモデルの重みを扱う構成の話で、ColGrep-Agentは別のモデルへ仕事を委譲する話だ。小型モデルが選択を返すStrands Deciderとも役割は異なる。Deciderが候補を選ぶのに対し、ColGrep-Agentは検索と読み取りを何度か実行し、根拠となる場所を返す。小さいモデルという共通点から、同じ処理方式や速度を期待することはできない。
試すなら探索と修正を分けて測る
導入を判断するなら、まず自分のリポジトリで、答えを確認できる探索問題を用意したい。記号名が分かる問題と、振る舞いだけを説明する問題を混ぜる。標準検索と委譲検索で、APIトークン、待ち時間、必要な場所の見落としを比べれば、探索の交換条件を評価できる。これは導入時の検証案であり、LATENTの測定結果ではない。
その後に、修正がテストを通るか、レビューの負担が減るかを別に測る。探索費用が減っても、誤った場所を修正して手戻りが増えるなら効果は変わる。コードの場所を返す小型モデルとして評価すると、任せる範囲と戻す条件を決めやすい。
出典と確認範囲
2026年10月13日時点の公式ブログ、モデルカード、GitHubを照合した。図はLATENTによる概念図で、独自のモデル実行、速度測定、日本語の探索精度検証は行っていない。M3 Proの値をほかの機材へ一般化せず、統合の使いやすさも実機確認済みとは扱っていない。