Claude Codeを使っていると、ある問題に直面します。
「認証処理について教えて」と質問すると、Claudeが30以上のファイルを読み込み始めるのです。
そして、目的のコードを見つける頃には、コンテキストウィンドウの半分が消費されている。
この問題を解決するために開発されたのがPommelです。
本記事では、Redditで話題になったPommelについて解説します。
その特徴と、既存ツールとの違いも紹介していきましょう。
コンテキストウィンドウの消費問題
Claude Codeで開発を進めていると、AIが関連コードを探すためにファイルを次々と読み込みます。
例えば「認証フローの仕組みを説明して」と依頼したとします。
すると、Claudeは15個以上のファイルを読み込むことがあります。
2000行以上のコードがコンテキストに入るわけです。
しかし、読み込まれたコードすべてが必要なわけではありません。
認証に関係するのは3〜4箇所だけかもしれない。
それでも、ファイル全体が読み込まれてしまいます。
結果として、後続の作業に使えるコンテキストウィンドウが圧迫されるのです。
Pommelの概要
Pommelは、この問題を解決するローカルのセマンティックコード検索ツールです。
「authentication flow」や「rate limiting logic」といった概念的な検索クエリを投げます。
すると、関連する関数やクラスだけをファイル名と行番号付きで返してくれます。
ワークフローの変化は明確です。
従来は「認証の仕組みを教えて」と質問すると、15ファイルがコンテキストに読み込まれていました。
Pommelを使えば、pm search “authentication flow” –json –limit 5で5件の結果を得られます。
そのうち本当に必要な3箇所だけを読み込めばよくなるのです。
技術的な仕組み
Pommelの動作原理を見ていきましょう。
コードのインデックスはローカルのベクターDB（sqlite-vec）に保存されます。
OllamaとJina embeddingsをローカルで実行します。
そのため、コードが外部サーバーに送信されることはありません。
プライバシーを重視する開発者にとって、この点は重要でしょう。
ファイルウォッチャーがインデックスを自動的に最新の状態に保ちます。
手動で再インデックスを実行する必要はありません。
コードを変更すれば、自動的にインデックスが更新されます。
検索の粒度はファイル、クラス、メソッドの3レベルから選べます。
ファイル全体ではなく、必要なメソッドだけを20行程度で取得できる。
この点が大きな特徴です。
現在サポートしている言語は、C#、Python、JavaScript、TypeScript、Go、Javaの6言語となっています。
LSPツールとの違い
Claudeの新しいLSP機能やSerenaなどのLSPツールとPommelは、何が違うのでしょうか。
LSPツールは構造的・シンボリックな検索を行います。
「AuthMiddlewareへの参照をすべて見つけて」といった操作が得意です。
ただし、シンボル名を事前に知っている必要があります。
構文木をナビゲートするツールだからです。
一方、Pommelはセマンティック・概念的な検索を行います。
「レート制限に関連するコードを探して」「認証フローはどこにある？」といった質問に答えられます。
シンボル名を知らなくても、意味で検索できるのがポイントです。
実際の使い方としては、両者を組み合わせると効果的でしょう。
- まずPommelで「authentication」を検索する
- src/middleware/auth.pyにあるAuthMiddlewareが関連コードだと特定する
- 次にLSPで「AuthMiddlewareへの参照を検索」する
- 使用箇所をすべて把握できる
LSPはコードベースを理解した後の操作に向いています。
Pommelは不慣れなコードベースで方向性を掴むのに役立ちます。
Exploreサブエージェントとの違い
「Exploreサブエージェントがメインのコンテキストウィンドウを保護してくれるのでは？」という疑問もあるでしょう。
確かにExploreサブエージェントは独自の約200kコンテキストウィンドウで動作します。
メインスレッドには要約だけを返す仕組みです。
しかし、いくつかの違いがあります。
まず、要約は情報の損失を伴います。
あるエンジニアが次のように指摘していました。
Exploreエージェントは要約を返しますが、これは損失圧縮です。 Opusが関連コンテキストを直接読む場合、どの詳細が重要かを把握しています
実際のコードが必要な場面では、要約では不十分なこともあるのです。
次に、Exploreはgrep基盤で動作しています。
並列化された文字列マッチングであり、セマンティック検索ではありません。
「rate limitingを探して」と検索しても、throttleRequests()という関数名は見つからないかもしれません。
レイテンシも考慮すべき点です。
Exploreは毎回ゼロから始まります。
エージェントの起動、複数のgrep/read呼び出し、要約生成といったプロセスを経るのです。
一方、Pommelのインデックス検索は100ms未満で結果を返します。
粒度の違いも重要です。
Exploreはファイルレベルの結果や要約を返します。
Pommelは必要なメソッドだけ、つまり500行ではなく20行だけを返せます。
類似ツールckとの比較
ckというツールも同様の問題を解決しようとしています。
両者の違いを見てみましょう。
検索アプローチが異なります。
ckはBM25とセマンティックのハイブリッド検索を採用しています。
キーワードマッチングと埋め込みの組み合わせです。
Pommelは純粋なセマンティック検索で、Ollama/Jina embeddingsを使用します。
チャンキングの粒度も違います。
ckはファイルレベルでチャンキングを行います。
Pommelはファイル、クラス、メソッドの複数レベルに対応しています。
メソッドレベルで検索すれば、ファイル全体ではなく必要な関数だけを取得可能です。
統合方法も異なるアプローチです。
ckはMCPサーバーを内蔵しており、Claude DesktopやCursorとの統合を想定しています。
PommelはCLIファーストでJSON出力を行います。
CLAUDE.mdの指示から呼び出す設計です。
MCPサーバーの指示文がコンテキストを多く消費することを避けるため、CLIベースを選択したとのことでした。
インデックスの鮮度も異なります。
Pommelはファイル監視デーモンで自動更新します。
ckは手動での再インデックスが必要なようです。
セマンティック検索への批判的視点
興味深い議論として、セマンティックインデックスの有効性に対する疑問が挙げられていました。
Clineチームは「なぜClineはコードベースをインデックスしないのか、そしてそれが良いことである理由」という記事を公開しています。
主な論点は、コードは他の種類のデータとは異なるというものです。
セマンティック検索があまり有効ではないと主張しています。
コードの意味は構造的かつ精密であり、自然言語のような曖昧さを許容しないためです。
この点については、開発者コミュニティでも議論が続いています。
セマンティック検索が有効なケースと、従来のgrep検索で十分なケースの両方が存在するでしょう。
実際のプロジェクトで試してみて、どちらが効果的か判断するのが現実的かもしれません。
CLAUDE.md統合のメリット
Pommelの設計で評価されている点の一つが、CLAUDE.md統合です。
多くのツールは単にCLIを追加するだけです。
そのため、エージェントがその存在を無視してしまうことがあります。
しかし、pm init –auto –claudeオプションでCLAUDE.mdに自動追加されます。
これにより、エージェントは最初からこのツールの存在を認識するのです。
盲目的にgrepを始める前に、まずPommelで検索するという行動パターンを形成できます。
あるコメント投稿者は次のことを指摘していました。
CLAUDE.md統合こそが重要な動きだ。 これがないと、エージェントはツールの存在を知らずにgrep検索を始めてしまう
まとめ
Pommelは、Claude Codeのコンテキストウィンドウ消費問題に対する一つの解決策です。
ローカルで動作するセマンティック検索により、関連コードを素早く特定できます。
主な特徴をまとめると以下のとおりです。
- メソッドレベルの粒度で必要な部分だけを取得可能
- ファイル監視による自動インデックス更新
- プライバシーを考慮したローカル完結設計
LSPツールやExploreサブエージェントとは異なるアプローチを取っています。
これらと組み合わせて使うことも可能です。
セマンティック検索がコードに対してどこまで有効かという議論はあります。
しかし、コンテキストウィンドウを節約したいという課題には正面から取り組んでいるツールと言えるでしょう。
現在v0.3.xとのことで、まだ荒削りな部分もあるようです。
大規模なコードベースを扱うClaude Codeユーザーにとっては、試してみる価値があるかもしれません。
興味のある方はGitHubリポジトリを確認してみてください。
GitHub: https://github.com/dbinky/Pommel
