codebase-memory-mcp（開発元: DeusData、GitHub ⭐39,699）は、コードベースをtree-sitterで解析して永続的なグラフに索引化し、Claude Code・Codex CLI・OpenCodeなど複数のAIエージェントに検索・追跡ツールをMCP経由で渡すサーバーだ。多くのMCPコード検索サーバーが「毎回ファイルを読み直す」都度読み込み型なのに対し、本OSSは索引を常駐デーモンに保持し、複数のエージェントセッションが同じグラフを共有する。この記事では、その仕組みと、実際にインストール・索引化して測った実測値を、公式リポジトリと実機検証だけを根拠に整理する。

codebase-memory-mcpのグラフ可視化UI。コードベースの構造がノードとエッジで表示されている
codebase-memory-mcp付属のグラフ可視化UI（デフォルトでポート9749）。出典: DeusData/codebase-memory-mcp 公式README
30秒でわかる codebase-memory-mcp（2026年9月時点）
  • ・正体：DeusData製のMCPサーバー。tree-sitterで158言語を解析し、コードベースをSQLite/Cypher風の永続グラフへ索引化する
  • ・何ができる：index_repositoryで索引化した後、search_code・trace_pathなど15種のMCPツールで定義検索・呼び出し追跡・アーキテクチャ俯瞰ができる
  • ・何が他と違う：Session Coordination Daemonという常駐プロセスが索引を保持し、Claude Code・Codex CLIなど43のクライアントsurfaceが同じ索引を共有できる
  • ・実測：本記事の検証環境でこの ai-archive-jp リポジトリ自体を索引化したところ、約22秒でノード29,426・エッジ41,576のグラフが生成された
  • ・注意：最新版はv0.10.8とpre-1.0。ライセンスはMIT

MCPサーバーの実装そのものを一から学びたい場合は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照してほしい。本記事はその応用として、コードベースを永続的な知識グラフに変える具体的なMCPサーバーを1本掘り下げる。

codebase-memory-mcpとは何か｜pre-1.0のtree-sitter索引エンジン

codebase-memory-mcpは、GitHubリポジトリ DeusData/codebase-memory-mcp として公開されているMCPサーバーだ。GitHub API実測で⭐39,699・フォーク3,191（フォーク/スター比は約8%で、star買いなど不自然な増幅の兆候は見られない）。ライセンスはMITで、LICENSEファイルの記載とREADMEの宣言も一致している。

主要言語はC言語（GitHub API language フィールド）で、tree-sitterの文法定義を158言語分バイナリに同梱している。コードベースを解析した結果はSQLiteベースのストレージにCypher風クエリで問い合わせられるグラフとして保存される。開発は非常に活発で、直近30日のコミット数はGitHub APIのページング上限（100件）に張り付いており正確な総数は取得できないほど。contributor数もAPI上限の100名を超えている。バージョニングは30本のリリースを経て最新はv0.10.8（2026-08-19公開）、本記事執筆時点のpushed_atは2026-08-20と、当日プッシュがある現役開発中のプロジェクトだ。

・何ができる：コードベース全体をグラフとして索引化し、エージェントがMCPツール経由で検索・追跡できるようにする
・何を解決する：エージェントがコードを理解するたびに全文を読み直す非効率（トークン消費・レイテンシ）
・何を代替できる：ファイル読み込み・grep型の素朴なMCP検索サーバー。ただし後述の通り、永続グラフや複数エージェント間の共有まで持つ設計は同種のOSSでも珍しい

一点注意したいのは、開発元「DeusData」が企業なのか個人／小規模チームのハンドルなのかは、GitHub Organizationの情報以上には確認できていない。ホームページ（deusdata.github.io）もGitHub Pagesで公開されたOSSプロジェクトサイトの体裁であり、商用サポートの記載はREADMEの範囲では見当たらなかった。

こうした「コードベースをグラフ化してエージェントに渡す」設計は、MCP コードインテリジェンスやMCP コード検索という文脈で語られることが多く、Claude Code コードベース記憶という使い方をされることもある。tree-sitter MCPという括りで見た場合、158言語という対応の広さも本OSSの特徴の一つだ。

バス係数（bus factor）の観点でも、contributor数100超・直近30日のコミット100件超（いずれもGitHub APIのページング上限に達するほど）という活発さから、特定の1人に開発が集中している様子は見られない。個人プロジェクトが失速して止まるリスクに比べると、継続性の観点では安心材料と言えそうだ。

実機でconfig listを確認するとui_enabledはデフォルトでtrue、ui_portは既定9749になっており、索引化したコードベースをブラウザで見られるグラフ可視化UIが標準で立ち上がる設定になっている。本記事冒頭のスクリーンショットはこの可視化UIで、索引化されたコードベースの構造がノードとエッジのグラフとして描画されている。

Session Coordination Daemon｜43クライアントが1つの索引を共有する仕組み

codebase-memory-mcpの技術的な核心は、README・公式CLIヘルプで「Session Coordination Daemon」と呼ばれる常駐プロセスだ。バイナリの--help出力を実機で確認したところ、「自動／条件付きで対応するクライアントsurface」として43種が列挙されていた：Claude Code・Codex CLI・Gemini CLI・Zed・OpenCode・Antigravity・Aider・KiloCode・VS Code・Cursor・Windsurf・Augment/Auggie・OpenClaw・Kiro・Junie・Hermes・OpenHands・Cline・Warp・Qwen Code・GitHub Copilot CLI・Factory Droid・Crush・Goose・Mistral Vibe・Qoder CLI・Kimi Code CLI・GitLab Duo CLI・Rovo Dev CLI・Amp・Devin CLI/Local・Tabnine・Continue/cn・Visual Studio・TRAE・Roo Code・Amazon Q Developer IDE・CodeBuddy Code CLI・IBM Bob IDE・IBM Bob Shell・Pochi・Pi・Sourcegraph Cody。これに加えて、Qodo・Warp・JetBrains AI/ACP・Replit・Plandex・SWE-agent・BLACKBOX・GitHub cloud agents・Jules・CodeRabbitは「手動／UI経由のMCP境界」として別枠で挙げられている。エージェント界隈のほぼ主要どころを網羅する対応範囲の広さが、複数エージェント共有という設計と噛み合っている。

flowchart LR A["コードに変更が入る
git commit等"] --> B{"auto_watch は
有効か？"} B -- "true（既定値）" --> C["Session Coordination
Daemonが差分を検知"] C --> D["tree-sitterで再解析し
グラフ索引を更新"] D --> E["Claude Code / Codex CLI /
OpenCode等が同じ索引を参照"] B -- "false" --> F["index_repositoryを
手動で再実行するまで古いまま"]
codebase-memory-mcpの4層アーキテクチャ図。tree-sitter索引の上にDaemon、MCPプロトコル、複数エージェントが重なる構成
codebase-memory-mcpの構成イメージ（本記事作成・実機検証結果に基づく自作図）

実機でconfig listを実行すると、デフォルト値は次の通りだった（検証環境: Linux amd64、バイナリ配布版 v0.10.8）。

Configuration:
  auto_index                = false
  auto_index_limit          = 50000
  auto_watch                = true
  ui-lang                   = auto
  ui_enabled                = true
  ui_port                   = 9749

設定名から読み取れる範囲では、auto_watch（既定でtrue）はgitの変更を監視して索引を追従させる仕組み、auto_index（既定でfalse）は初回の索引化を自動では行わない設定だと考えられる。いずれも実機で確認した「値」であり、内部動作の詳細な仕様までは本記事では踏み込まない。

MCPツールは--helpの出力で数え上げると次の15種類だった：index_repository・search_graph・query_graph・trace_path・get_code_snippet・get_graph_schema・get_architecture・search_code・list_projects・delete_project・index_status・check_index_coverage・detect_changes・manage_adr・ingest_traces。エージェントが/mcpコマンドで確認した際に見えるツール数も、この15個と一致する想定だ。

なお--helpには--tool-profile=analysis|scoutという起動オプションも記載されており、エージェントに見せるツールの範囲を制限した「inspection surface」に絞ることもできるようだ。全15ツールをフルに使わせたくない場面（読み取り専用のレビュー用途など）を想定した設計と考えられる。

codebase-memory-mcpのインストールと基本コマンド｜Docker・言語ランタイム不要のネイティブバイナリ

README記載の通り、Docker・Node.js・Python等の言語ランタイムを別途用意する必要はなく、OS別のネイティブバイナリをワンライナーで取得できる。実機（Linux amd64）で実際にインストールした際の手順とログは以下の通り。

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

このインストーラはHTTPS以外のダウンロード元を拒否し、取得したバイナリのチェックサムを検証してから展開する作りになっていた（実機確認）。実行するとcodebase-memory-mcp 0.10.8のバイナリが取得され、--versionで確認したバージョンもbriefで裏取りした最新リリース番号と一致した。バイナリの更新もcodebase-memory-mcp update一行で行える構成で、Dockerイメージの差し替えのような重い手順を必要としない自前のセルフアップデート機構を持っている（--helpのUsage欄に記載）。

インストール後は、CLIサブコマンドでツールをローカル実行して動作確認できる。実際に本記事の検証環境でこのai-archive-jpリポジトリ自体を索引化したログ（一部抜粋、所要時間はコマンドの実測値）：

codebase-memory-mcp cli index_repository --repo-path "$(pwd)" --progress
# → Completed index_repository (21936 ms)
# → {"nodes":29426,"edges":41576, ... "status":"indexed"}

Windows環境ではREADMEに、Microsoft DefenderがリリースバイナリをTrojan:Script/Wacatac.B!mlとして誤検知することがある既知のfalse positiveだと記載されている。実際に踏んだ場合は慌てず、公式リポジトリのIssue・Releaseページで同種の報告が無いかを確認するのが妥当だろう。

index_repositoryの--helpを見ると、--modeで索引の粒度を切り替えられることも分かった。全ファイルを対象に類似度・セマンティックエッジまで解析するfull、フィルタ済みファイルに絞って類似度/セマンティック解析を行うmoderate、フィルタ済みファイルのみで類似度/セマンティック解析を省くfast、複数プロジェクト間でルートやチャネルを突き合わせるcross-repo-intelligenceの4種類だ。また--persistenceを指定すると索引結果を.codebase-memory/graph.db.zstという圧縮アーティファクトとして書き出せ、チームメイトはこれを取り込めば自分のマシンで索引を作り直さずに済む、とヘルプに明記されていた。

実際に索引化してみた｜検証環境での実測結果

ai-archive-jpリポジトリを索引化した結果。ノード29,426・エッジ41,576・所要時間約22秒
本記事の検証環境（Linux amd64・バイナリ配布版 v0.10.8）でai-archive-jpリポジトリを索引化した実測値

このai-archive-jpリポジトリ（Jekyllの静的サイトで、Markdown・YAML・HTML・少量のJS/Pythonが主体）を対象にindex_repositoryを実行したところ、ツール内部の計測で21,936ミリ秒（コマンド全体のwall timeは23.7秒）でグラフ29,426ノード・41,576エッジが生成された。.wolf・.git・credentials・tmp・.claudeの5ディレクトリは索引から除外され、拡張子ベースで5,524ファイルが「ignored-suffix」として除外対象になった。

出力にはもう一つ興味深い情報があった。索引化した中の13ファイルがparse_partial（部分パース）として記録されており、docs/_data/related.ymlやdocs/_includes/ad-unit.htmlなど特定の行範囲でtree-sitterが構文を完全には追いきれなかった可能性がある、という注記付きだった。YAML/HTMLが主体のリポジトリでも一部の構文を見落とす余地がある、という実測上の限界として素直に書いておく。

README側の自己申告ベンチマークでは、Linuxカーネル（2,800万行・75,000ファイル規模）を3分で索引化できるとしている。これは公式の主張であり、第三者による独立検証は確認できていない。参考までに、今回のai-archive-jpリポジトリはコード量としてはLinuxカーネルよりも遥かに小さく、内容もMarkdown・YAML中心でC言語のような複雑な構文解析が要る場面は少ない。ツールも対象言語構成も異なるため単純比較はできないが、少なくとも中規模のリポジトリでは実用的な速度で索引が完了することは、今回の実測で確認できた。同様に、トークン削減効果についてはGitHubのリポジトリ説明文が「99% fewer tokens」、README「Why」セクションが「120x fewer tokens」と、表記が食い違っている。どちらか一方を断定的な数字として引用せず、両方を「公式マーケティング文言」として紹介するのが実態に忠実な書き方になる。

類似ツールとの比較｜Code Review GraphやGitHub公式MCPとの違い

「コードをグラフ化してエージェントに渡す」という発想自体は珍しくないが、目的レイヤーが異なるツールと混同しやすい。当サイトで既に扱ったCode Review Graphとは｜Tree-sitter ASTのコード知識グラフでトークンを中央値65倍削減はTree-sitter ASTでコード知識グラフを構築する点は共通するが、こちらはMCPサーバーではなくCLIツールで、目的はコードレビュー支援に絞られている。またGitHub MCPとは｜公式MCPサーバーの使い方・86ツール・リモート/ローカル版と権限設計を解説はGitHub上のIssue・PR・リポジトリ操作が主眼で、ローカルのコードベースを永続グラフへ索引化する機能は持たない。

観点 codebase-memory-mcp Code Review Graph 素のgrep/ファイル読み込み型MCP
提供形態 MCPサーバー（常駐デーモン） CLIツール MCPサーバー（都度読み込み）
索引の永続化 あり（SQLite/Cypher風グラフ、tree-sitter 158言語対応） あり（Tree-sitter AST） 基本的になし
セッション間の共有 Session Coordination Daemonで複数エージェントが共有 単発のCLI実行が前提 サーバー実装に依存
対応クライアント数 43種（README記載） ー（本記事では未確認） ー
ライセンス MIT ー（本記事では未再確認） ー
バージョン v0.10.8（pre-1.0） ー ー

永続化と共有が効いてくるのは、1回のタスクで終わらず同じリポジトリに何度も戻ってくる状況だ。都度読み込み型のMCPサーバーは、Claude Codeのセッションを立ち上げ直すたびに同じファイルを読み直す。codebase-memory-mcpは索引をSession Coordination Daemonに保持するため、2回目以降の呼び出しはグラフを参照するだけで済む。さらに同じマシン上でClaude Code・Codex CLIなど複数のエージェントを併用する場合も、索引を作り直す作業を1エージェント分に集約できる。

逆に言えば、単発のちょっとした質問や、リポジトリを二度と触らないような使い捨てのタスクでは、常駐デーモンを立てるオーバーヘッド自体が不要になる。索引化に約22秒（本記事の検証環境・このリポジトリの規模で）かかることを踏まえると、「継続的に同じコードベースへ戻ってくるか」が導入の分かれ目になりそうだ。

読者の3つの問いへの答え
① 何ができる：コードベースを永続的なグラフに索引化し、MCP経由で複数のAIエージェントに検索・追跡ツールを提供する。 ② 何を解決する：エージェントが毎回コードを読み直す非効率と、複数エージェントが同じ調査を重複して行う無駄。 ③ 何を代替できる：都度ファイルを読み込むだけの素朴なMCP検索サーバー。ただし索引の永続化やセッション間共有まで求めない用途では、シンプルなgrep型サーバーで十分な場合もある。

導入前に知っておきたい注意点

・pre-1.0であること：最新版はv0.10.8で、バージョニング上はまだ1.0未満。README記載の6,768件のテスト通過やLinux kernelでの索引化実績（3分・2,800万行規模）は公式の自己申告であり、第三者検証は確認できていない
・数値表記の食い違い：トークン削減効果はGitHub説明文「99%削減」とREADME「120倍削減」で表記が異なる。どちらかを断定引用せず両方を公式主張として紹介するのが妥当
・開発元の実体が未確認：「DeusData」が企業か個人/小規模チームのハンドルかは、GitHub Organization以上の情報は取得できなかった
・Windowsでの誤検知：Microsoft Defenderがリリースバイナリを既知のfalse positiveとして検知することがある（README記載）
codebase-memory-mcpは、コードベースを都度読み直すのではなく永続的なグラフとして索引化し、Session Coordination Daemonで複数のAIエージェントに共有するという設計が最大の特徴だ。本記事の検証環境では実際にこのリポジトリを約22秒で索引化でき、公式の主張と実機での挙動は少なくとも矛盾しなかった。一方でpre-1.0段階であることや、公式ベンチマーク数値の食い違いは導入前に把握しておきたい。

参照ソース

・DeusData/codebase-memory-mcp（公式リポジトリ・README） — インストール手順・設計思想・ベンチマーク主張・config値を取得
・codebase-memory-mcp 公式サイト — プロジェクトホームページ