AI coding agent が codebase を読むとき、今でもよく使う道具は rg、grep、cat、そして複数 file の丸読みです。この流れは汎用的ですが、長い session ではあまり経済的ではありません。同じ import block、同じ helper function、同じ log fragment が、何度も context に入ってしまうことがあります。人間なら IDE で symbol に飛び、outline を見て、call graph をたどります。しかし agent は、まだ terminal text stream に近い読み方をしがちです。

今日紹介する hunhee98/pluck は、この code retrieval layer を agent の default infrastructure にしようとする project です。Rust 製の local daemon として動き、Model Context Protocol 経由で code read/search tools を公開します。Claude Code、Codex、Cursor などの agent が repository を読むとき、まず構造化 retrieval を使い、必要なときだけ raw read に戻る、という設計です。GitHub page では現在およそ 34 stars、0 forks。主な言語は Rust、license は MIT、latest release は v0.5.2 です。

プロジェクト概要

項目内容
リポジトリhunhee98/pluck
位置づけMCP-native code retrieval engine
Stars約 34
Forks0
主な言語Rust
ライセンスMIT
最新 versionv0.5.2

もう一つの grep ではなく、agent の読み取り protocol

pluck の README は、問題をかなり明確に書いています。Agent が standard cat と grep だけで codebase を探索すると、すでに読んだ内容や、今の task には不要な内容にも token を使ってしまいます。pluck の方向は developer 向け search command の置き換えではなく、agent と repository の間に retrieval protocol を置くことです。

この protocol では、agent はまず smart outline を受け取り、必要な function や class だけを追加で読むことができます。Concept search、caller impact、dependency graph、build log digest も同じ interface から使えます。一方で --raw fallback が用意されているので、byte-exact content、binary file、repository 外の path、unsupported format が必要な場面では、従来の読み方に戻れます。

ここが「より速い grep」とは違う点です。grep は text match を解決します。pluck は、context budget の中で agent が次に何を読むべきかを決める layer です。

MCP tools が細かく分かれている

README に載っている tools は、agent の探索 action をかなり細かく分けています。

  • mcp__pluck__read：file を読む。default は smart outline、raw read も可能。
  • mcp__pluck__grep：keyword / regex search。通常の grep/rg に近い用途。
  • mcp__pluck__search：BM25 と semantic rerank による ranked chunk search。
  • mcp__pluck__symbol：function や class の body だけを読む。
  • mcp__pluck__peek：signature と direct callees を見る。
  • mcp__pluck__expand：symbol と callees を指定 depth で展開する。
  • mcp__pluck__impact：ある symbol を呼んでいる caller を追う。
  • mcp__pluck__deps：file-level import graph の forward / reverse を見る。
  • mcp__pluck__digest：cargo、npm、pytest、CI log を圧縮し、error や panic を残す。
  • mcp__pluck__plan：task から次の retrieval calls を提案する。

個々の機能はまったく新しいものではありません。IDE、LSP、code search service には似た能力があります。pluck の価値は、それらを MCP tool としてまとめ、agent が統一された interface で呼び出せるようにする点です。読む前に plan し、読みながら重複を減らし、読んだ後に symbol や call relation で絞り込む、という流れを default にしようとしています。

Retrieval は AST chunk と hybrid ranking

Architecture の説明を見ると、pluck は Tree-sitter で code を AST level に chunking します。Query 時には単純な string match だけでなく、BM25F、symbol/signature/content weighting、semantic rerank を組み合わせます。Natural-language query は近い語彙で拡張され、candidate を広げてから rerank する two-stage cascade を使います。

Agent から見ると、「auth flow」「payment validation」「token expiry に影響する caller」のような query を、最初から exact function name を知らなくても投げられるのが利点です。その後で symbol、peek、impact、deps を使い、読み取る範囲を小さくできます。

ただし semantic search は、code を読まなくてよいという意味ではありません。関連しそうな chunk を見つける補助です。実際に修正する前には、具体的な symbol body、caller、test を読む必要があります。

smart outline は大きな file の読み取り cost を下げる

特に実用的なのは pluck.read の default behavior です。File 全体をそのまま返すのではなく、まず symbol map を出し、小さな helper body は inline し、大きな function は outline として見せます。Agent は file structure を見てから、必要な body だけを読む判断ができます。

これは人間の code reading に近いです。1000 行の file を開いたとき、普通は先頭から最後まで読まず、class、function、entry point、call path を先に見ます。Agent が毎回 file 全体を cat すると、context には一時的に関係の薄い情報が残り続けます。

README には project 自身の gated benchmark が載っています。Eligible code read では smart outline が token use を大きく減らし、CI log digest にも compression metric があります。ただし、これは project の測定 baseline として読むべきです。どの repository、どの task でも同じ結果になる保証ではありません。自分の codebase で試すなら、同じ修正 task に対して read count、duplicate context、final correctness を比べるのが現実的です。

Install は agent configuration とセット

pluck は Cargo または Homebrew で install できます。

cargo install pluck-mcp pluck-cli
brew tap hunhee98/pluck && brew install pluck

さらに agent ごとの initialization command も用意されています。

pluck init --target claude --mode aggressive
pluck init --target codex --mode strong
pluck init --target cursor --mode strong

ここはかなり実務的です。MCP server を入れるだけでは不十分で、agent が本当に「先に pluck、必要なら Bash fallback」という習慣を持つ必要があります。README には Codex、Claude Code、Cursor 向けに MCP registration、project rules、AGENTS.md policy の案が載っています。つまり pluck は tool だけでなく、agent の retrieval habit も固定しようとしています。

まずは personal repository や small team template で試すのがよさそうです。Initialization で生成された config を PR に出し、どの read scenario で pluck を優先するのか、どの scenario では raw shell を許すのかを明確にする。安定したら、より大きな monorepo に広げるのが安全です。

向いている場面

pluck が向いているのは、次のような project です。

  • Repository が大きく、agent が問題調査で rg と cat を何度も使う。
  • Team が MCP をすでに使っていて、retrieval tool を agent toolbox に入れたい。
  • Code structure がある程度安定していて、symbol、call relation、import graph が役に立つ。
  • CI、test、build log が長く、agent が key error を探すことが多い。
  • 複数 agent を同じ code retrieval layer で比較したい。

小さな script repository や、ほぼ single-file edit だけの project では、pluck は少し重いかもしれません。価値が出やすいのは long session、multi-file investigation、repeated queries、大きな log の処理です。

注意したい境界

第一に、pluck は engineering judgment の代わりにはなりません。関連 code を探す助けにはなりますが、design intent の理解が正しいことは保証しません。

第二に、MCP tools が増えるほど、agent behavior は prompt と tool selection policy に依存します。Server を install しただけでは不十分です。Agent が本当に mcp__pluck__* を先に使っているか、byte-exact content が必要なときに raw read へ戻れているかを観察する必要があります。

第三に、project はまだ新しいです。GitHub page から見ると、2026 年 5 月に public release が始まり、release cadence も速いです。Team workflow に入れる前に version を固定し、まず non-critical repository でしばらく使ってから、CI や shared template に入れるか決めるほうがよいです。

まとめ

hunhee98/pluck は、AI coding workflow のかなり実際的な問題を扱っています。Agent の code reading は、まだ IDE の構造化探索というより terminal text stream に近い。pluck は Rust daemon、Tree-sitter、hybrid retrieval、MCP tools を組み合わせ、outline、symbol read、impact analysis、dependency graph、log digest を agent が直接呼べる場所に置きます。

Agent を自動的に賢くする shortcut ではありません。しかし「何を読むか」「どれだけ重複して読むか」「次にどう探すか」の無駄は減らせます。Codex、Claude Code、Cursor、その他 MCP-capable agent を真剣に使っている team なら、code retrieval layer として小さく試す価値があります。

リポジトリ：https://github.com/hunhee98/pluck