Recall 詳細: カテゴリ別スコアと差別化項目

カテゴリ別加重スコア

各カテゴリの達成率を4段階で表示しています（◎ 60%以上 / ○ 30〜59% / △ 1〜29% / × 0%）。項目ごとの個別評価は3ページ目の付録を参照してください。cbm は初回（lib/ 6ファイルのみ）と設定後（router/finalhandler 追加）の2条件を併記しています。codegraph は初回（explore のみ）と設定後（node/callers 併用）の2条件を併記しています。cognee は Haiku 4.5（lib 6ファイル）と Sonnet 5（10ファイル）の2条件を併記しています。

Top 10: ツール間で最も差が出た項目

以下は75項目中、ツール間のスコア差が大きかった上位10件です（全項目は3ページ目の付録に掲載）。

読み方: cbm (初回) は lib/ 6ファイルのみのデフォルト構成、cbm (設定後) は index_repository で依存パッケージ追加後（84.7%）。cg (初回) は explore のみの初回計測、cg (設定後) は node/callers 併用（96.0%）。grep は Express v5 の外部 router パッケージの壁で多くの項目が不到達。

インデックス範囲の設計

Express v5.2.1 は router を外部パッケージ（router@2.2.0）に分離しています。エラーハンドリングとミドルウェアの核心ロジック — Layer.handleError、Route.dispatch、Router.handle — はすべて node_modules/router/ 配下にあります。

初回ベンチマーク（v1）では codebase-memory-mcp が Express 本体（lib/）のみをインデックスしており、全75項目のうち58項目（77%）が不到達でした。到達できたのは res.format() の 406 エラー生成、createApplication() のファクトリパターン、mounted_app ラッパーの prototype 復元、getrouter の遅延初期化など17項目（◎4, ○7, △6）で、加重スコアは 17.3% でした。そこで index_repository で node_modules/router と node_modules/finalhandler を明示的にインデックスに追加して再計測したところ、加重スコアは 17.3% から 84.7% に跳ね上がりました。

codegraph でも同様のパターンが確認できました。explore（関連ファイルのソースコードを広く返すコマンド）のみでの計測では 28.3% でしたが、node（単一シンボルのソース＋callers/callees を返すコマンド）を併用したところ 96.0% に到達しました。codegraph はプロジェクトルート配下の src/router/ をインデックスしており、router のコードには到達可能でしたが、explore がデフォルトで返す4〜5ファイルでは75項目の大半をカバーできなかったのです。node handleError のような精密なクエリで初めて、fn.length !== 4 のチェックや try/catch → next(err) の変換といった細部が出力に含まれます。

cognee でも同じ構造が確認できました。初回計測（Haiku 4.5、lib 6ファイルのみ）では 34.7% でしたが、LLM を Sonnet 5 に変更し、インデックス対象を router 3ファイル + finalhandler 1ファイルを加えた10ファイルに拡大したところ 65.7% に到達しました。cognee のエンティティ抽出は LLM に依存するため、モデルの品質がグラフの粒度に直結します。加えて、cbm や codegraph と同様にインデックス範囲の拡大も効いています。ただし cognee は概念レベルの要約（○）が中心で、コード根拠を伴う◎は0件のままです。これは cognee が「コードの意味」を LLM で抽出・圧縮するアーキテクチャに起因する構造的な特性です。

この結果が示す教訓は、ツールの性能はデフォルト設定やデフォルトコマンドだけでは測れないということです。codebase-memory-mcp ではインデックス範囲の設定が、codegraph ではクエリ戦略の選択が、cognee では LLM モデルの品質とインデックス範囲の両方が、それぞれスコアを劇的に変えました。逆に言えば、どのツールも適切に設定・運用すれば高い精度を発揮できます。

codebase-memory-mcp の論文は、トークン10分の1の代わりに回答品質が 0.92 → 0.83（約10%低下）になることを報告しています。トークン削減と網羅性は本質的にトレードオフであり、どのツールを選んでも万能ではありません。

また、codebase-memory-mcp と codegraph はいずれも tree-sitter による静的解析でグラフを構築するため、DI コンテナの実行時バインディング、リフレクション、起動時の動的ルート登録といったランタイムで確定するワイヤリングは原理的にグラフに含まれません。しかもツールはそれが見えていないことを通知しないため、グラフの情報だけで回答を組み立ててしまう可能性があります。今回のベンチマーク対象（Express.js、Hono）は動的登録が少ないフレームワークのため、この限界は顕在化しませんでした。DI を多用するフレームワーク（Spring Boot、NestJS 等）では結果が異なりうる点に注意してください。

計測していないこと

本ベンチマークには以下の限界があります。

• 大規模モノレポ（10万行超）: 今回は21K〜25K LOC の中規模 OSS で検証。10万行超のモノレポではインデックスサイズ・クエリ応答・メモリ使用量が非線形に増加する可能性があります
• Java / Python / Go 等: 検証は JavaScript と TypeScript のみ。言語ごとに tree-sitter パーサの成熟度が異なるため、他言語では結果が変わりえます
• 長期運用時の DB 肥大化: codegraph の SQLite DB、cognee のグラフ DB が数ヶ月の運用でどの程度肥大化するかは未計測です
• マルチユーザー環境: チーム全員が同一インデックスを共有するシナリオは未検証。ファイルロック競合やインデックス更新の排他制御は各ツールのドキュメントを確認してください
• 修正タスクの成功率: 本ベンチマークは「調査タスク」（コードの仕組みを説明する）のみ。「バグを直す」「リファクタリングする」といった修正タスクでの効果は別途検証が必要です
• MCP ツールがエージェントを混乱させるリスク: MCP ツールの出力（構造化 JSON やグラフデータ）がエージェントのコンテキストを圧迫し、かえってトークン消費が増えるケースがありえます。Hono での codebase-memory-mcp（-1.6%、ほぼ効果なし）はこの傾向を示唆しています。プロジェクト構造が単純で grep + Read で十分到達できる場合、MCP ツールの追加は逆効果になりうる点に注意してください
• インデックスコストの償却: 本ベンチマークはインデックス構築コストを1回分だけ計測しています。1セッションで1タスクしか実行しない場合、cognee の7分は明らかに割に合いませんが、同一インデックスで10タスクを連続実行すれば1タスクあたり42秒に薄まります。導入判断では「1セッションで何タスク実行するか」を考慮してください

言語・構造による差: TypeScript リポジトリでの検証

1ページ目の Express.js の実測結果だけでは言語やプロジェクト構造による偏りが残ります。そこで Hono（TypeScript Web フレームワーク、186 TS ファイル、~25,000 LOC）でも同じセッション単位のトークン計測を実施しました（各条件3回、計9セッション）。Hono は Express.js と同じルーティング + ミドルウェアの設計を持ちますが、全コードが単一パッケージ（src/ 配下）に収まっている点が大きく異なります。

プロジェクト構造が効果を左右します。Express.js ではルーターが node_modules/ に分離されており、grep では発見しにくい構造でした。codebase-memory-mcp のグラフ検索はこの分散を補完し、-27% の効果を出しました。一方 Hono は単一パッケージのため、grep + Read で十分効率的に探索でき、codebase-memory-mcp の追加効果はほぼゼロでした。

codegraph は両方のリポジトリで一貫した効果を示しました。特に Hono では explore が TypeScript のソースコードを正確に返すため、平均ターン数が 13回 → 5.7回（56%減） と大幅に削減されました。

パッケージが分散し grep では見つけにくい構造ほど MCP の恩恵が大きく、整理された単一パッケージでは効果が限定的です。ただし Hono では recall 評価を実施していないため、トークン削減と回答品質の関係は Express.js の結果のみに基づいています。

計測環境

• ハードウェア: Apple M2 Max (arm64), 64 GB RAM, macOS 14.6.1
• 対象リポジトリ: Express.js v5.2.1（コミット 18e5985、141 JS ファイル、~21,000 LOC）— 出力バイト数・Recall・セッション計測の全指標で使用。Hono（コミット 82b321b、186 TS ファイル、~25,000 LOC）— セッション単位のトークン計測のみ（プロジェクト構造による効果差の検証用）
• codebase-memory-mcp: v0.8.1（C バイナリ、CLI モード）
• codegraph: v1.2.0（TypeScript、CLI モード）
• cognee: v1.2.2（Python、LLM: Bedrock Haiku 4.5 → 再計測で Anthropic API Sonnet 5、Embedding: Ollama nomic-embed-text → 再計測で fastembed BAAI/bge-small-en-v1.5）

出力バイト数の比較はローカル環境のスペックに依存しません。応答速度計測はローカル環境に依存します。セッション単位のトークン消費計測は Claude Sonnet 4.6 を使用し、各条件3回実行しています（入力トークンは中央値、ターン数は平均値）。MCP サーバーの接続方法は Claude Code 公式ドキュメント を参照してください。

参考リンク

• codebase-memory-mcp — 公式リポジトリ・ドキュメント
• codegraph — 公式リポジトリ
• cognee — 公式リポジトリ・ドキュメント
• Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP — codebase-memory-mcp の論文
• Claude Code 公式ドキュメント — MCP サーバーの接続方法