Project RAGとは？
Project RAG は、手元のマシンでコードベースをインデックス化し、MCP 経由でエージェントに提供します。コードは 12 の言語について Tree-sitter で関数、クラス、メソッドに分割され（それ以 外は 50 行のチャンク）、fastembed-rs と all-MiniLM-L6-v2 モデルでローカルに埋め込まれ、組み込みの LanceDB データベースに Tantivy の BM25 インデックスとともに保存されます。クエリは、2 つの順位を reciprocal rank fusion で組み合わせます。Qdrant はビルド時に選べるオプションのバックエンドです。
サーバーは stdio で 9 つのツールを公開します。index_codebase、query_codebase、search_by_filters、search_git_history、get_statistics、clear_index、find_definition、find_references、get_call_graph です。それに対応する 9 つのスラッシュコマンドのプロンプトもあります。API キーは不要で、初回の実行時に約 50 MB の埋め込みモデルをダウンロードします。
リポジトリは 2025 年 11 月に作成され、ライセンスは MIT、スターは約 33 で、すべてのコミットが 1 人のコントリビューターによるものです。バージョン 0.1.0 は 2026 年 1 月 24 日に crates.io に公開され、累計ダウンロード数は 77 です。GitHub のリリースはなく、最後のコミットは 2026 年 2 月 2 日で、外部からの 3 件のプルリクエストが 5 月と 7 月からメンテナーの返答を待っています。公式の MCP レジストリには登録されていません。
Project RAGのインストール方法
cargo install project-ragProject RAGは使う価値があるか？
Project RAG は、材料は正しくそろっていますが、台所はまだ未完成です。正確な識別子が意味と同じくらい重要なコードでは、ハイブリッド検索が正しい選択で、組み込みの LanceDB インデックスと BM25 を組み合わせてい るので、横で動かすものは何もありません。しかし開発は 2026 年 2 月に止まっており、未解決のプルリクエストには、利用者が初日にぶつかるバグが書かれています。
1 つ目はログ出力です。サーバーは Rust の tracing の出力を stdout に初期化しますが、stdio では stdout は MCP のメッセージ用に予約されています。5 月から未解決のプルリクエスト #20 は、その結果ログの行がストリームを壊し、ツールの呼び出しが空を返すと説明しています。README 自身の Claude Desktop と Claude Code の例では RUST_LOG=info を設定しており、それがまさにそのログ行を有効にします。2 つ目はプルリクエスト #21 にあるもので、include と exclude のパターンが単純な部分文字列として照合されることです。ソースもそれを裏付けています。**/vendor/** のようなグロブは実際のパスの部分文字列には決してならないので何にも一致せず、README 自身の除外の例は、.gitignore がすでに除外しているもの以上の効果を持ちません。
コードナビゲーションのツールは、実際に提供されているものより多くを約束しています。README は、Python、TypeScript、Java、Ruby で約 95% の精度を持つ stack-graphs のリゾルバーを説明していますが、Cargo.toml はその機能を準備済みだが完全には実装されていないとしており、ソースにはそのようなモジュールがありません。実際に動くのは AST ベースの代替手段で、README 自身がその精度を約 70% としています。CodeGraph と GitNexus は埋め込みなしで本物の呼び出しグラフを構築しますが、こちらでは定義と参照は識別子の照合から得られます。
性能の数値は作者自身のもので、方法を示さずに一般的なハードウェアでの値とし て挙げられています。1 分あたり約 1,000 ファイル、検索 1 回あたり 20 から 30 ms、基本のメモリが約 100 MB で、モデルにさらに 50 MB です。issue #11 では、ある利用者が、小さなプロジェクトのインデックス化に約 30 分、大きなモノレポでは CPU で数時間かかったと報告しています。README はトークンの節約については何も主張していません。ドキュメントには自己矛盾している箇所もあり、LanceDB がすでに既定であるのに、Qdrant をエンジンとして挙げ、組み込みのデータベースを今後の作業としています。
真価を発揮する場面
長年の履歴を持つ 5,000 ファイルの多言語リポジトリで働く開発者
ある挙動がどこから来たのか、どのコミットがそれを変えたのかをエージェントに尋ねる
search_git_history は既定で直近の 10 コミットをインデックス化し、必要に応じてさらに遡ります。作者、パス、日付で絞り込めます。README は 5,000 ファイルのプロジェクトで 500 MB 未満のメモリとしています。ある利用者の報告によれば、CPU での最初のインデックス化には数分から数時間かかると見込んでください。
社内のコード検索エージェントを構築する Rust のプラットフォームチーム
MCP サーバーを動かすのではなく、自社のサービ スに検索機能を組み込む
クレートはサーバーだけでなく RagClient というライブラリ API も MIT で公開しています。上流はどちらの修正もマージしていないので、部分文字列でのパターン照合と stdout へのログ出力を修正する時間を見込んでください。
チーム向けにローカルのコードコンテキストサーバーを比較するエンジニアリングマネージャー
チームが 1 年間頼れるものを選ぶ
コントリビューターは 1 人、crates.io のダウンロードは 77 回、1 月以降リリースなしという状況では、採用するのではなくフォークするプロジェクトです。CodeGraph は MIT で、活発にリリースされており、埋め込みモデルも不要です。
導入前に確認すること
- 導入
- Rust 1.88 以上と protobuf-compiler が必要です。cargo install project-rag（0.1.0）を実行するか、リポジトリから cargo build --release を実行し、バイナリのパスを指定して claude mcp add を実行します。README は Claude Code と Claude Desktop の手順を記載しています。初回の実行では、index_codebase が完了する前に埋め込みモデルをダウンロードします。
- 連携
- stdio で 9 つのツールが あります。index_codebase と clear_index はローカルのインデックスに書き込み、残りの 7 つは読み取りです。9 つの MCP プロンプトが、Claude Code で /project: のスラッシュコマンドとして表示されます。Rust のライブラリ API も同じ機能を提供します。
- データとプライバシー
- コード、埋め込み、BM25 インデックスはローカルに残り、既定ではプラットフォームのデータディレクトリの project-rag の下に置かれます。index_codebase はエージェントが渡すどのディレクトリパスでもインデックス化するので、サーバーのプロセスが読めるものは何でも読めます。モデルのダウンロードは Hugging Face から行われます。セキュリティアドバイザリは公開されていません。
- 大規模利用時のコスト
- 無料で、コストは CPU 時間とディスクです。README の見積もりでは、10,000 チャンクあたり約 40 MB のメモリ、1,000 ファイルのプロジェクトで約 75 MB のストレージで、GPU での埋め込みの手段はありません。
- 制限
- Qdrant の URL は、ハードコードされた localhost の既定値以外に設定できません。パスのフィルターはクエリの後に適用され、AST によるチャンク分割は 12 の言語だけです。README 自身によれば、100,000 ファイル以上のプロジェクトのインデックス化にはかなりの時間がかかります。
良い点
- ベクトル検索と BM25 のハイブリッド検索は、識別子にも文章にも合う
- 組み込みの LanceDB とローカルの埋め込みで、キーも外部サービスも不要
- コミットメッセージと差分を対象にした Git の履歴検索
- プロセス間のロックで、2 つのセッションが同時に 1 つのリポジトリをインデックス化するのを防ぐ
気になる点
- 2026 年 2 月以降コミットがなく、外部からの修正がマージされていない
- stdout へのログが MCP のストリームを壊すことがある（未解決の PR #20）
- グロブの include と exclude のパターンが一致しない（未解決の PR #21）
- 宣伝されている高精度のナビゲーションは実装されていない
おすすめの人
ローカルでのハイブリッドなコード検索のために、ソースからビルドし、未解決の修正を自分で適用する覚悟 のある Rust の開発者。
Project RAGの代替
Project RAG：よくある質問
- Project RAGは使う価値があるか？
- コード向けのハイブリッド検索として堅実な設計ですが、自身のログ出力と除外パターンを壊すバグの修正がマージされておらず、足を引っ張っています。 評価は5点満点中2.8点です。
- Project RAGの料金は？
- 無料で、ライセンスは MIT です。
- Project RAGの欠点は？
- 2026 年 2 月以降コミットがなく、外部からの修正がマージされていない; stdout へのログが MCP のストリームを壊すことがある（未解決の PR #20）; グロブの include と exclude のパターンが一致しない（未解決の PR #21）; 宣伝されている高精度のナビゲーションは実装されていない.
- Project RAGは誰に向いているか？
- ローカルでのハイブリッドなコード検索のために、ソースからビルドし、未解決の修正を自分で適用する覚悟のある Rust の開発者。
- チームや本番環境でProject RAGを使うと費用はいくらか？
- 無料で、コストは CPU 時間とディスクです。README の見積もりでは、10,000 チャンクあたり約 40 MB のメモリ、1,000 ファイルのプロジェクトで約 75 MB のストレージで、GPU での埋め込みの手段はありません。
- Project RAGは企業データを扱っても安全か？
- コード、埋め込み、BM25 インデックスはローカルに残り、既定ではプラットフォームのデータディレクトリの project-rag の下に置かれます。index_codebase はエージェントが渡すどのディレクトリパスでもインデックス化するので、サーバーのプロセスが読めるものは何でも読めます。モデルのダウンロードは Hugging Face から行われます。セキュリティアドバイザリは公開されていません。
- Project RAGの代わりになるものは？
- 当サイトでレビューした中で最も近い代替はCodeGraph, GitNexus, Serena 、 Sembleです。
回答確認日：2026年10月26日