AIコーディングエージェントに「このファイルを読んで」と何度も頼むたびに、トークンがどんどん消えていく感覚があります。大きなリポジトリになるほど、ファイルを一つひとつ探索させる方法は現実的ではなくなってきます。コードベース全体の構造を、エージェントが一度で把握できる形に変換できれば、もっとスムーズに動くはずです。今回紹介する codebase-memory-mcp は、その問題にまっすぐ向き合ったMCPサーバーです。機能の紹介だけでなく、設計上の工夫についても一緒に見ていきます。
どんなMCPサーバーか
codebase-memory-mcp(略称: CBM)は、コードベースをAST解析して永続的な知識グラフに変換し、AIコーディングエージェントが構造的なクエリを高速に実行できるようにするMCPサーバーです。対応言語は158言語。tree-sitterによるASTパースを軸に、Python・TypeScript・Go・RustなどではLSPとの連携でより精度の高い型解決も行います。生成されるグラフには関数・クラス・呼び出しチェーン・HTTPルート・サービス間リンクが含まれ、15種類のMCPツール経由でエージェントから参照できます。
インフラ寄りのコードベースでも、DockerfileやKubernetesマニフェスト、Kustomizeオーバーレイをグラフノードとして取り込みます。バイナリ1本で動作し、言語ランタイムもDockerも不要です。macOS・Linux・Windowsそれぞれのネイティブバイナリが配布されていて、インストールはシェルスクリプト1行で完了します。
設計でここが上手い

トークン消費の抑え方
READMEによると、5つの構造クエリで約3,400トークンで済む処理が、ファイル単位の探索では約41万2,000トークンかかるとされています。単純計算で120倍の差です。この数字の大きさよりも、なぜそうなるかを考えると面白いところがあります。ファイル単位の探索は「どのファイルに答えがあるかわからないまま読む」という行為を繰り返します。一方でCBMは、インデックス時点でコード全体の構造を把握したグラフを作っておき、クエリ時はそこに問い合わせるだけです。探索の不確実性をエージェントではなく事前処理に押しつける設計です。
コンテキストウィンドウを節約する構造が、エージェントの応答精度にも好影響を与える可能性があります。arXivに掲載されたプレプリント(arXiv:2603.27277)では、31のリポジトリを対象に評価して83%の回答品質、ファイル単位探索と比較してツール呼び出し回数が2.1分の1になったと報告されています。
インデックス速度の実現方法
Linuxカーネル(2800万行、7万5000ファイル)を3分でインデックスするというのは、ツールのスケール感を伝えるわかりやすい数字です。RAMファーストのパイプライン設計で、LZ4圧縮・インメモリSQLite・Aho-Corasickパターンマッチングを組み合わせています。インデックス完了後にメモリを解放する点も、長時間起動するMCPサーバーとして堅実な判断です。クエリの応答は1ms以下を目標としており、エージェントの待ち時間としてほぼ無視できる水準を狙っています。
ゼロ依存バイナリという選択
純粋なC実装、言語ランタイムなし、外部サービスなし。コードは手元のマシンを一切出ません。これは信頼の問題でもあります。コードベースにはビジネスロジックや認証情報が含まれることが多く、クラウドに送るツールに対しては導入のハードルが上がります。CBMはすべてローカルで処理するため、その判断を回避できます。VirusTotalでのスキャン結果をリリースノートにリンクする運用も、セキュリティ意識を示す取り組みとして目を引きます。
セッション協調デーモンの設計
Claude Code・Codex・OpenCodeなど複数のエージェントが同時に走る環境でも、CBMはアカウントごとに1つの協調デーモンを共有します。複数セッションが重複してHTTPサーバーを立ち上げたり、インデックス作業が二重に走ったりしない仕組みです。デーモンの起動・終了・アップデート中の排他制御まで設計に織り込まれています。この種のデーモン管理を自前でここまで丁寧に作り込むのは、実際の利用環境を踏まえた判断でしょう。
こういう人に向くかも
CursorやClaude Code、Windsurf、aiderなどのAIコーディングエージェントを日常的に使っていて、大きなリポジトリでのコンテキスト消費を課題に感じている人には試してみる価値があります。特に、関数の呼び出しチェーンやクラス間の依存関係を把握するような作業をエージェントに任せているとき、CBMがあれば「まずどのファイルを読むか」という探索ステップを省けます。
逆に、小さなスクリプトや数ファイル程度の作業がメインであれば、インデックスを作る手間に見合わないかもしれません。READMEでは43の自動/条件付きクライアントサーフェスに対応するとされていますが、自分が使うエージェントが対応リストに入っているかを先に確認するのが現実的です。
設計の良し悪しをどこで見るか
機能の単一性
CBMがやることは「コードベースを知識グラフにして、MCP経由でクエリに答える」に尽きます。その一点に機能が集中しているため、エージェント側での使い方が予測しやすくなっています。MCPツールが15種類あるのは多めに見えますが、search・trace・architecture・impact analysisなど用途ごとに分かれていて、それぞれが単一の目的を持っています。ツールの数が多くても整理されていれば、エージェントがどれを呼ぶか迷うコストは下がります。
ドキュメントの深度
READMEは相当な分量があり、セキュリティポリシー・セッション協調の仕組み・アップデート手順・アンチウイルスの誤検知対応まで書き込まれています。特にアップデートの仕組みについて「なぜバイナリ内でアップデートを完結させないか」を説明している箇所は、設計判断の背景を示す良い例です。Windowsでは実行中のバイナリを置き換えられないという制約があるため、インストーラースクリプト経由でのアップデートに統一した、という理由が書かれています。こうした背景まで書いてあると、運用時のトラブルで判断に困る場面が減ります。
想定外の使われ方への備え
複数バージョンの混在を防ぐOSレベルの排他制御、インデックス変更時のプロジェクトロック、アップデート中の新規プロセス受け付け停止など、エッジケースへの備えが丁寧です。セキュリティについてはSLSA Level 3に準拠しており、ビルドの再現性と成果物の改ざん検証を担保しています。ただし、ツールの性格上コードベースを読みエージェント設定ファイルを書き換えるため、初回導入時はソースコードを確認してから使うのが安全です。リポジトリには全ソースが公開されています。
メンテナンスの継続性
スター数が4万弱、CIとテストが整備されていて6768ケースが通過している状態です。arXivへのプレプリント掲載は、単なるOSSプロジェクト以上の研究的な裏付けがあることを示しています。一方で組織名がDeusDataという比較的新しい名前で、長期メンテナンスの実績はまだ限られています。活発に開発されている現時点での導入はリスクが低いですが、1〜2年後の継続性については注目していく必要があります。
自分が書くなら、どこを変えるか
セッション協調デーモンの設計は完成度が高い反面、仕組みが複雑なためトラブル時の原因特定が難しくなる可能性があります。デーモンの状態を手軽に確認できるCLIコマンドがあると、エージェント環境での問題調査がやりやすくなりそうです。現状はログファイルを直接見る方法が基本で、エージェントに不慣れな開発者には少しハードルが高いかもしれません。
158言語対応はインパクトがある数字ですが、tree-sitterのASTパースだけでは言語ごとの解析精度に差があります。Python・TypeScript・Goなど主要言語ではLSP連携による型解決が入りますが、残りの言語では構造の抽出精度が下がる場面も出てくるでしょう。対応言語数の見せ方として、「LSP連携ありの言語」と「AST基本解析のみの言語」の区分けをもう少し前面に出すと、導入前の期待値調整がしやすくなります。
導入を検討するときのチェック観点
- 使っているAIコーディングエージェントが43の対応サーフェスに含まれているか確認する
- コードベースのサイズと言語が、高精度解析(LSP連携)の対象に入っているかを把握する
installスクリプトがエージェントの設定ファイルをどこにどう書き込むか、事前に確認する- ローカル完結で動くことを確認し、CI環境や共有サーバーで使う場合は排他制御の挙動を把握する
- 複数のエージェントを同一マシンで並行して動かしている場合、デーモン共有の動作を理解してから導入する
- auto_index を有効にする前に、インデックス対象にしたくないリポジトリが設定に含まれないか確認する
- アップデートはバイナリ内でなくインストーラースクリプト経由となるため、更新フローをチームに共有しておく
知識グラフという選択肢の位置づけ
コードベースの探索方法として「都度ファイルを読ませる」アプローチは手軽ですが、リポジトリが育つほど非効率になります。CBMはそのトレードオフに対して、事前インデックスと構造クエリという答えを出しています。インデックスの初期コストと引き換えに、以降のクエリが高速かつ低トークンで動く設計です。AIコーディングエージェントとの組み合わせを本格的に活用したい場面で、選択肢として手元に置いておく価値があるツールです。

