shareuhack brand logo
shareuhack brand logo
AIエージェントの記憶ツール選び方：cognee vs codebase-memory-mcp 完全ガイド（2026）

AIエージェントの記憶ツール選び方：cognee vs codebase-memory-mcp 完全ガイド（2026）

July 3, 2026
LunaMiaEno
著者Luna·調査Mia·レビューEno·継続更新中·16 分で読了
この記事の改善に協力

AIエージェントの記憶ツール選び方：cognee vs codebase-memory-mcp 完全ガイド（2026）

Claude CodeやCursorを使い始めたところ、エージェントがセッションをまたぐたびに「記憶をなくす」ことに気づきます。コンテキストウィンドウを広げてみても、大きなコードベースだと数十万トークンがすぐに消費され、コストが跳ね上がり、回答品質もむしろ下がってしまいます。

問題はコンテキストウィンドウが小さいことではありません。構造化された記憶層、つまりエージェントが本当に必要な情報だけを取り出せる仕組みが欠けているのです。

このガイドでは、現在最も注目されている2つの記憶ツールを比較します。codebase-memory-mcp（コード構造記憶）とcognee（汎用知識グラフ記憶）です。「どちらが優れているか」ではなく、あなたのニーズはどんな形をしていて、どちらのツールが合っているかが本質的な問いです。

TL;DR

  • cognee：汎用AIエージェント長期記憶エンジン、Knowledge Graph+ベクトルアーキテクチャ、26.4k stars、$7.5Mシード（OpenAI共同創業者出資）、Apache 2.0。
  • codebase-memory-mcp：AIコーディングエージェント向けコード構造記憶、Tree-Sitter AST+LSP型解析、23.9k stars、MIT、完全ローカル実行・ゼロテレメトリー。
  • 核心の違い：一方は「知識」を覚え、他方は「コード構造」を覚えます。競合ではなく、まったく異なる問題を解くツールです。
  • クイック判断：Claude Code/Cursorでコードを書くならcodebase-memory-mcp。自分のエージェントシステムを構築するならcognee。両方が必要なら同時に使えます。

AIエージェントの記憶危機：なぜコンテキストウィンドウでは解決しないのか

AIエージェントが「忘れる」とき、多くの人の最初の反応は「もっとコンテキストを詰め込む」ことです。小規模では効果がありますが、これは根本的なアーキテクチャ上の問題を隠してしまいます。

コンテキストウィンドウは作業記憶であり、長期記憶ではありません。 人間の作業記憶には限界があり、海馬や長期記憶といった別のメカニズムに頼っています。AIエージェントにも同様のアーキテクチャが必要です。

問題は複数の層で起きています。

量の問題：中規模のコードベース（3,000ファイル）をコンテキストに全部入れると、100万トークンを超えることがあります。APIコストが急上昇し、レスポンス速度も落ちます。

質の問題：長いコンテキストではAIの注意が分散し、中間部に置かれた情報を見落とす傾向があります（ロスト・イン・ザ・ミドル現象）。詰め込めば詰め込むほど回答品質が上がるとは限りません。

セッションをまたぐ持続性の問題：コンテキストウィンドウは持続しません。新しい会話は毎回ゼロから始まります。昨日積み上げた理解は今日には消えています。

この2つのツールは後者2つの問題（質の問題とセッション間の持続化）を解決しますが、まったく異なるアプローチで、まったく異なるユーザーを対象としています。

codebase-memory-mcp：AIコーディングエージェント向けコード構造記憶

codebase-memory-mcp（v0.8.1、MIT）は、AIコーディングエージェントがコードベース全体を毎回スキャンする代わりに、事前に構築したコード構造インデックスをクエリできるMCPサーバーです。

技術コア：AST+LSP、単なるgrepではない

ツールのコアはTree-Sitter AST（構文木解析）とLanguage Server Protocol（LSP）意味解析です。158種類のプログラミング言語をサポートし、TypeScript、Python、Go、Rustなどの主要言語を含む11言語ではフルHybrid LSP意味解析が使えます。

インデックス作成後、エージェントは次のクエリが可能になります。

  • どの関数がどの関数を呼んでいるか
  • ある型がどの箇所で使われているか
  • どの2ファイルが一緒に変更されることが多いか（git co-changeカップリング）
  • 意味的に関連するコードブロック

これらは通常のgrepでは実現できない「構造的理解」です。

shareuhackリポジトリでの実測データ

shareuhackリポジトリでcodebase-memory-mcpの実際のパフォーマンスを検証しました。

  • インストール時間：npm install 33秒、バイナリ256MB（Mach-O x86_64）
  • インデックス速度：2,776ファイル、ウォール時間9.4秒（CPU時間50.6秒、マルチコア最大活用）
  • インデックス規模：72,647ノード+78,775エッジ
  • トークン節約：search_graphの戻り値1,427バイト対直接grep+catの354KB、実測99.6%の節約

arXivの論文（2603.27277）では31リポジトリ平均でトークン節約90%を報告。shareuhackの99.6%は単一構造クエリシナリオの数値であり、測定方法が異なります。この高い数値は「精密なクエリ対全体展開」の対比を示すものであり、エージェントセッション全体のトークン消費ではありません。

注目すべきエッジタイプにはFILE_CHANGES_WITH（639エッジ、gitのco-changeカップリング記録）とSEMANTICALLY_RELATED（128エッジ）があります。これらにより、従来の静的解析では実現できないカップリングクエリが可能になります。

重複排除効果も明確です。同じクエリでtotal_grep_matchesが106件あったのに対し、total_resultsは29件のみ（3.7倍の重複排除率）。エージェントはノイズではなく、精製された結果を受け取ります。

代表性についての注記：上記の数値はNext.jsコンテンツプラットフォーム型コードベース（markdownが多く、ビジネスロジック密度が比較的低い）に基づきます。バックエンド重視のmonorepoや純粋な関数型Pythonプロジェクトではグラフ密度とトークン節約率が異なる場合があります。自分のリポジトリで実際に試してから判断することをお勧めします。

対応AIコーディングエコシステム

公式サポートリストにはClaude Code、Codex CLI、Gemini CLI、Zed、OpenCode、Antigravity、Aider、KiloCode、Kiroが含まれます。実質的に主流のAIコーディングエージェントはすべてカバーされています。

cognee：エージェントシステム向け汎用知識グラフ記憶層

cognee（v1.2.2、Apache 2.0）は異なる問題を解決します。AIエージェントがセッションをまたいで会話履歴、ユーザー設定、文書知識を記憶し、必要なときに正確に呼び出せるようにする方法です。

3層アーキテクチャ：グラフ+ベクトル+リレーショナル

cogneeのストレージアーキテクチャは3層構造です。

  • Kuzu（グラフデータベース）：知識ノード間の関係を記録
  • LanceDB（ベクトルデータベース）：意味的類似性検索
  • SQLite（リレーショナルデータベース）：メタデータと構造化情報を格納

3層が同時に動作することで、「AとBの関係は？」（グラフクエリ）と「Xに似た知識は？」（ベクトル検索）の両方に答えられます。

4ステップのワークフロー

cogneeの使い方は比較的明快です。

  1. add：データソースを追加（文書、会話、PDF、Slackメッセージなど）
  2. cognify：知識グラフを構築（概念・関係・エンティティを抽出）
  3. memify：ユーザー記憶層を構築（セッション間の持続化）
  4. search：関連する知識を呼び出し

MCPツールはremember、recall、forgetを含む合計14個です。

プロダクショングレードの実績

cogneeは2026年2月に$7.5Mのシードラウンドを完了。投資家PebblebedにはOpenAI共同創業者のPamela VagataとFacebook AI Research創業者のKeith Adamsが含まれます。70以上の本番環境でデプロイ済み、BEAMベンチマークでは0.79（それまでの最高は0.735）を達成しています。

完全ローカルのスタンドアロンモード（クラウド不要）とクラウドAPIモードの両方をサポートします。

cognee対Mem0：もう一つのよくある比較対象

Mem0を評価したことがある方向けに、主な違いをお伝えします。Mem0のほうがコミュニティが大きく（48k+ stars、cogneeの約1.8倍）、情報が豊富で始めやすいです。ただし、Mem0のグラフ機能は月249ドルのProプランが必要です。cogneeのグラフ機能は全プランで利用可能です。

ユーザーマッチング梯子：あなたの記憶ニーズはどんな形？

これがこの記事の核心的な認識の転換です。この2つのツールは機能で競っているのではなく、まったく形の異なるニーズを解決しています。

まず自分に問いかけてみてください。あなたのエージェントが記憶すべきものは「コード構造」ですか、それとも「知識と設定」ですか？

段階1：AIコーディングエージェント（Claude Code、Cursor）のみを使用

主な用途はコードを書くことです。エージェントにコードベースを理解させ、セッションを切り替えるたびにアーキテクチャを再説明したくない。

codebase-memory-mcpを選びましょう。 「この関数がどこで呼ばれているか」「この型がどう渡されているか」を正確に検索でき、コードベース構造を説明する手間が省けます。

段階2：自分のAIエージェントシステムを構築中

Python SDKや他のフレームワークを使ってエージェントを構築していて、エージェントにセッションをまたいでユーザー情報を記憶させ、知識を蓄積し、会話履歴を持続化させたい。

cogneeを選びましょう。 この用途のために設計された知識グラフ構造を持ち、MCPインターフェースでエージェントからrememberとrecallを呼び出せます。

段階3：両方のニーズがある

自分のコーディングアシスタントエージェントを構築していて、かつユーザーの設定や知識ベースも記憶させたい。

両方のツールを同時に使えます。 独立したMCPサーバーとして動作するため、Claude CodeやCursorのMCP設定に両方を追加するだけです。役割が重複しないため、互いに干渉しません。

クイック決断テーブル

シナリオツール
Claude Code/Cursorでコーディング、トークンコストを下げたいcodebase-memory-mcp
Cursor標準のコードベースインデックスがあり、より細かい意味クエリが欲しいcodebase-memory-mcpを重ねることも可能。シンプルなクエリなら既存で十分
エージェントシステムを構築、長期記憶が必要cognee
PDF/Slack/マルチモーダルな知識取り込みが必要cognee
完全ローカル・ゼロテレメトリー・サプライチェーンセキュリティを重視codebase-memory-mcp（SLSA Level 3）
Pythonエコシステム、知識グラフが必要cognee
両方のシナリオがある両方使う

インストール前の注意点：codebase-memory-mcpのhotspots出力はconsole.log/console.errorなどの関数名で埋まりがちで、ビジネスアーキテクチャの素早い把握には向いていません。query_graph DSLは現状ドキュメントが不完全なため、フォールバックとしてsearch_graphを使いましょう。これらの制限はコア機能（関数クエリ・依存関係追跡）に影響しませんが、インストール前に知っておく価値があります。

技術的深掘り：認識の転換点と境界条件

選択の決断をする前に、落とし穴を避けるために事前に知っておくべき認識の転換点があります。

codebase-memory-mcpの境界条件

99%トークン節約には前提条件があります。 arXivの論文（2603.27277）が報告する数値：回答品質83%（100%ではない）、トークン節約90%、ツール呼び出し削減58%。shareuhackでの実測は99.6%でしたが、前提は同じインデックス済みコードベースを繰り返しクエリすることです。一回限りのスクリプトや非常に少ないクエリ数のセッションでは、256MBバイナリ+9秒インデックス時間のコストが回収できません。

hotspotsにはノイズがあります。 テストではtop-5のホットスポットが全部console.logとconsole.errorでした。意味のあるビジネスロジックではありません。手動でフィルタするか、クエリ戦略を調整する必要があります。

DSLドキュメントが不完全です。 query_graphは強力なDSLを提供しますが、完全なドキュメントがまだありません。試行錯誤で構文を把握する必要があります。

CLIパラメータ命名に一貫性がありません。 一部のCLIパラメータが異なるコマンド間で命名規則が不統一です。使用時に注意が必要です。

特定のディレクトリはデフォルトで除外されます。 .claude/やknowledge-base的なディレクトリはデフォルトでインデックスから除外されます。これらをインデックスしたい場合は、設定で明示的に追加する必要があります。

再インデックスは手動でトリガーが必要です。 コードベースに大量の追加や構造的変更があった場合、codebase-memory-mcp indexを再実行する必要があります。v0.8.1は増分更新をサポートしていません。日常的な小規模変更では既存インデックスで問題ありませんが、大きなリファクタリング後は再インデックスをお勧めします。

cogneeの境界条件

PythonがメインSDKです。 エージェントシステムをNode.jsや他の言語で構築している場合、統合の複雑さが増します。

グラフ構築にLLM呼び出しが必要です。 cognifyステップは概念と関係を抽出するためにLLMを呼び出します。大量の文書を一度に処理するとAPIコストが発生します。小さな文書10件でまず試して結果とコストを確認してから、バッチ処理に進みましょう。cognifyは10〜20の小さな文書で通常1〜2分かかり、進行状況が表示されます。5分待っても反応がない場合は調査が必要です。

Mem0よりコミュニティが小さいです。 26.4k stars対Mem0の48k+ — 問題が起きたときのコミュニティリソースが少なめです。

実践セットアップ：両ツールのクイックスタート

codebase-memory-mcpのインストール

# インストール
npm install -g codebase-memory-mcp

# コードベースのインデックス作成（プロジェクトルートで実行）
codebase-memory-mcp index

Claude CodeのMCP設定に以下を追加します。

  • グローバル設定（全プロジェクトに適用）：~/.claude/claude_mcp_config.json
  • プロジェクト設定（現在のリポジトリのみ）：.claude/mcp.json
{
  "mcpServers": {
    "codebase-memory": {
      "command": "codebase-memory-mcp",
      "args": ["serve"]
    }
  }
}

インデックス完成後、Claude Codeはsearch_graphなどのツールでコード構造をクエリできます。コードベース全体をgrepする必要がなくなります。

cogneeのインストール

# インストール
pip install cognee

# 基本的な使い方
import cognee

# 知識を追加
await cognee.add("あなたの文書や知識", dataset_name="my-knowledge")

# 知識グラフを構築（文書量とLLMの速度によって最初の実行は1〜2分かかります）
await cognee.cognify()

# 検索
results = await cognee.search("あなたのクエリ")

MCPモードではpip install cognee-mcpをインストールしてサーバーを起動後、Claude CodeのMCP設定に追加します。

{
  "mcpServers": {
    "cognee": {
      "command": "cognee-mcp",
      "args": []
    }
  }
}

起動後はremember、recall、forgetの3つのコアツールでcogneeの記憶層を操作できます。

リスク開示

両ツールとも活発に開発中のため、APIの安定性にはバージョンアップへの注意が必要です。codebase-memory-mcpのquery_graph DSLはドキュメントが不完全であり、頻繁に変更される大規模なコードベースのインデックス管理には自前の再インデックスフローが必要です。cogneeのcognifyステップはLLM API呼び出しを伴うため、大規模な知識ベースの初期化コストは事前に見積もってください。

結論：記憶の形がツールの選択を決める

多くの人はこの2つのツールを評価する際、「どちらが優れているか」という比較の罠にはまります。それは間違った問いです。

正しい問いは：あなたのエージェントは何を記憶する必要があるか？

コード構造ならcodebase-memory-mcp。知識・会話・設定ならcognee。両方必要なら両方インストールする。機能の境界が明確で、互いに競合しません。

Claude Codeでコーディングしていてcodebase-memory-mcpの実際の効果を確かめたい方は、自分のリポジトリでインデックスを実行して72,647ノードの構造グラフがどのように見えるかを確認し、普段手動で調べているような質問をエージェントに投げかけてみてください。トークン数と回答品質の違いを直接感じることができます。

自分のエージェントシステムを構築している方にとって、cogneeのBEAMベンチマーク0.79スコアと70以上の本番環境でのデプロイ実績が最も説得力のある証明です。まずはスタンドアロンのローカルモードから始めれば、クラウド依存なしに素早く試すことができます。

FAQ

cogneeとcodebase-memory-mcpは競合ツールですか？

いいえ。cogneeは汎用AIエージェント記憶エンジン（会話履歴・ユーザー設定・文書知識の記憶）で、codebase-memory-mcpはAIコーディングエージェント専用のコード構造記憶（関数呼び出し・依存関係・アーキテクチャ分析）です。解決する問題が異なるため、同時に使うことも可能です。

codebase-memory-mcpはコードを外部サーバーにアップロードしますか？

しません。ツールは完全ローカルで動作し、テレメトリーもゼロです。コード・クエリ・環境情報は一切外部に送信されません。また、SLSA Level 3のサプライチェーンセキュリティ認定も取得しています。

cogneeとMem0、どちらが始めやすいですか？

Mem0はコミュニティが大きく（48k+ stars対cogneeの26k）、情報も豊富で始めやすいです。cogneeの優位点はグラフ機能が全プランで利用可能なこと（Mem0は月249ドルのProプランが必要）と、OpenAI共同創業者の投資による信頼性です。

codebase-memory-mcpの「99%トークン節約」は本当ですか？

同じインデックス済みコードベースを繰り返しクエリする高頻度シナリオでは成立します（実測でも同レベルを確認）。初回インストールには256MBバイナリ+9秒のインデックス時間がかかるため、一回限りのスクリプトや少ないクエリ数のセッションでは元が取れません。arXivの論文では回答品質83%（100%ではない）と報告されており、複雑な意味推論にはフォールバックが必要です。

cogneeとcodebase-memory-mcpを同時に使っても競合しませんか？

競合しません。両ツールは独立したMCPサーバーとして動作するため、Claude CodeやCursorのMCP設定に同時に追加できます。役割も重複しません。codebase-memory-mcpはコード構造層、cogneeは知識記憶層を担当します。

この記事は役に立ちましたか？

次の記事

AIエージェントが再起動するたびに記憶喪失？ソロ開発者から企業まで、SQLite MCP・Mem0・scope-chainの3つのアーキテクチャでクロスセッション記憶を解決。月額$0から。

AIエージェント記憶アーキテクチャ実践ガイド：SQLiteからベクトルDBまで、3つのパスで最適な記憶方式を選ぶ（2026年版）

次の記事約 19 分

AIエージェントが再起動するたびに記憶喪失？ソロ開発者から企業まで、SQLite MCP・Mem0・scope-chainの3つのアーキテクチャでクロスセッション記憶を解決。月額$0から。

次の記事

他の関連記事

コミュニティが品質を守る

正確な情報をお届けすることに全力を尽くしています。お気づきの点があればお知らせください。

AIとテックツールの比較レポートを購読する