AI エージェントを本番で運用しはじめると、多くの開発現場が「セッションを跨いだ記憶」の欠如という壁にぶつかります。RAG（Retrieval Augmented Generation）を導入して外部ドキュメントを参照できるようにしても、ユーザー個別の文脈や過去のやり取り、業務知識同士の関係性までは扱いきれず、体験の質が頭打ちになりがちです。
こうした課題に対して、ここ数年で「AI エージェント向けメモリ基盤」というカテゴリが急速に整理されてきました。代表格は Mem0・Zep・Letta、そして本記事で取り上げる cognee の 4 つです。名前は聞いたことがあっても、それぞれのポジショニングや実装イメージ、セルフホスト前提での現実感までを俯瞰する情報はまだ少なく、「どれを選ぶべきか」で立ち止まっている方も多いはずです。
cognee は、GitHub リポジトリ（topoteretes/cognee） で公開されているオープンソースの AI メモリ基盤です。公式サイトは Cognee 公式サイト にあり、「セルフホスト型のナレッジグラフエンジンで、AI エージェントにセッションを跨いだ長期記憶を与える」というコンセプトを掲げています。ベクトル埋め込みとグラフ推論を組み合わせ、少ないコードで組み込める点が特徴です。
本記事では、cognee のポジショニングと主要機能、内部パイプライン、最小コード例、MCP サーバー経由の運用イメージ、そして Mem0 / Zep / Letta との違いまでを、公式ドキュメントと README をベースに整理します。実運用に載せるかどうかを判断するための材料を、1 記事で俯瞰できる形にまとめました。
cogneeとは｜AIエージェント向けオープンソース永続メモリ基盤
まずは cognee がどのような立ち位置のプロダクトなのか、README と公式サイトの記述から整理していきます。「初見でどこまで期待できるツールなのか」を最初に固めておくと、以降の比較や導入検討で判断がぶれにくくなります。
cogneeのポジショニングと解決課題
cognee は、GitHub リポジトリの説明にある通り「Cognee is the open-source AI memory platform for agents. Give your AI agents persistent long-term memory across sessions with a self-hosted knowledge graph engine.」というポジショニングで公開されています（出典: topoteretes/cognee）。要点は次の 3 つです。
- AI エージェント専用: 汎用のドキュメント検索エンジンではなく、AI エージェントの記憶層として設計されている
- セッションを跨ぐ長期記憶: 会話ごとにコンテキストがリセットされるのではなく、ユーザーやタスクを跨いで知識を蓄積できる
- セルフホストのナレッジグラフエンジン: SaaS だけでなく、自社インフラ上に丸ごと載せて動かすことを前提としている
「LLM に外部の知識を渡す」という点だけを見れば RAG と重なりますが、cognee は取り込んだデータをその都度検索するのではなく、事前にナレッジグラフとして構造化しておくアプローチをとります。ドキュメント同士のつながりや、そこから抽出したエンティティの関係性をグラフに蓄積するため、単純なベクトル類似検索では拾いにくい「文脈のつながり」を追える設計になっています。
リポジトリ基本情報（スター数・ライセンス・活発さ）
判断材料として重要なのが、リポジトリの健全性と活発さです。GitHub API から取得した基本情報は以下の通りです。
項目 | 値 |
|---|---|
リポジトリ | |
主要言語 | Python |
ライセンス | Apache-2.0 |
スター数 | 26,684 |
フォーク数 | 2,474 |
直近プッシュ | 2026-07-02 |
可視性 | public（archived: false / fork: false / disabled: false） |
スター数 26,684・フォーク数 2,474 と規模が大きく、かつ最新のコミットが直近日付（2026-07-02）で入っており、アーカイブ状態でもフォーク版でもない本家リポジトリです。ライセンスは Apache-2.0 のため、商用プロダクトへの組み込みや改変配布の自由度が高い点も、意思決定上のプラス材料と言えます。
より詳細な機能や設計思想は、Cognee 公式サイト や後述する公式ドキュメントに整理されています。まずは「アクティブに開発されている OSS のメモリ基盤で、Apache-2.0 でセルフホスト可能」という骨格をおさえておくと、以降の話が理解しやすくなります。
cogneeの主要機能｜4つのコアAPIとナレッジグラフ自動構築
cognee を採用するかどうかを検討するとき、最も知りたいのは「触った感じ、何ができるツールなのか」という粒度感です。この章では、上位 API のセットと、対応するバックエンドの広さを整理します。
4つのコアAPI（remember / recall / forget / improve）
cognee は上位 API として remember / recall / forget / improve の 4 つを提供しています。それぞれの役割は次の通りです。
上位 API | 役割 | 内部処理の概観 |
|---|---|---|
| ドキュメントを取り込み、ナレッジグラフとして構造化する |
|
| 質問を受け取り、意味検索・グラフ探索・チェーン推論を組み合わせて回答する | 14 種類の検索モードから自動ルーティング |
| 対象データセット単位、あるいは全体単位で忘却させる | 対象データの削除 |
| 使用頻度シグナルを踏まえてグラフを再重み付け・剪定する | グラフの強化・整理 |
低レベル API（.add() / .cognify() / .search() / .memify()）も公開されており、パイプラインをカスタムしたい場合に使えます。まずは 4 つの上位 API のイメージを掴んでおけば、要件と機能のマッピングは十分に取れます。
対応するグラフDB・ベクトルストア・LLMバックエンド
「セルフホストしたい」という要件があるときに気になるのが、自社が既に採用しているデータストアと組み合わせられるかどうかです。cognee は主要なグラフ DB とベクトルストアに一次対応しており、加えてコミュニティ拡張（cognee-community）でカバー範囲を広げています。
- グラフ DB（コア）: Postgres（グラフバックエンド）、Neo4j、Amazon Neptune
- ベクトルストア（コア）: pgvector、LanceDB、Qdrant、ChromaDB、Weaviate、Milvus
- キャッシュ・セッション: Redis、SQL 系セッションキャッシュ
- LLM: OpenAI（デフォルト）ほか各プロバイダ
- コミュニティ拡張: Azure AI Search、OpenSearch、Pinecone、Valkey、Memgraph、NetworkX、Google Cloud Spanner、TuringDB、pgGraph、DuckDB、FalkorDB など
特に注目したいのは、Postgres 単体で「グラフ・ベクトル・セッション・メタデータ」を賄える構成が公式でサポートされている点です。運用対象のデータストアを増やしたくない中規模プロジェクトにとっては、Postgres 1 台に集約できる選択肢は現実的な武器になります。
セッションキャッシュと永続グラフのハイブリッド設計
もう 1 つ、他のメモリツールと差がつきやすい特徴として、短期の「セッションキャッシュ」と長期の「永続グラフ」を同一 API で扱える点があります。
会話のたびに揮発してほしい情報（例: 直近のプロンプト文脈）と、長期に保持したい情報（例: ユーザーの好み・業務ルール・過去の意思決定）は、扱い方が本質的に違います。cognee では、session_id を渡すかどうかで両者を切り分けられる構造になっており、開発者は「短期メモリと長期メモリを別スタックで作る」必要がありません。この設計は、後述する最小コード例で具体的に確認できます。
cogneeの仕組み｜ナレッジグラフを自動構築するパイプライン
cognee を採用する技術的な根拠として重要なのが、remember の内部で何が起きているかです。「なぜ RAG 単体でなく、グラフを組み合わせるのか」という設計思想を確認しておくと、社内での稟議・レビュー時にも説明しやすくなります。
remember の内部処理（add → cognify → improve）
公式ブログや過去バージョンの解説によると、cognify は 6 ステージのパイプラインで構成されています。
- ドキュメント分類: 取り込むドキュメントを種別（テキスト・コード・ログ 等）に分類する
- パーミッションチェック: どのユーザー・データセットに紐づくかを確認する
- チャンク抽出: 検索・埋め込みしやすい単位に分割する
- エンティティ・関係抽出: LLM で人物・組織・イベント・概念とその関係を抽出する
- サマリー生成: ノード単位・チャンク単位でサマリーを作成する
- 埋め込みとエッジコミット: ベクトルストアにベクトルを、グラフ DB にノードとエッジを書き込む
この一連の処理により、取り込んだドキュメントは「単なるテキスト断片」ではなく、意味とつながりを持ったナレッジグラフとして再構成されます。単純な RAG との違いはここで、recall の際にベクトル類似検索だけでなく、グラフ探索やチェーン推論を組み合わせられるようになります。
recall の14種検索モードと自動ルーティング
recall は内部で 14 種類の検索モードを持ち、クエリの性質に応じて最適なモードを自動ルーティングします。単純な意味類似検索から、複数ホップのグラフ探索、チェーン推論を伴う質問応答まで、同じ関数呼び出しでカバーできる設計です。
BEAM ベンチマークにおいては、100K トークン設定で 0.79、10M トークン設定で 0.67 という SOTA 更新を報告しています（出典: Cognee 公式サイト）。この数値そのものよりも重要なのは、「グラフを持っているからこそ長いコンテキストで精度が落ちにくい」という設計上の狙いです。
memify による自己改善サイクル
cognee のもう一つの特徴が、memify による自己改善サイクルです。memify は次のような処理を担います。
- 陳腐化したノードの剪定
- 頻繁に一緒に参照されるノード間のエッジ強化
- 使用頻度シグナルによるエッジ再重み付け
- 検索結果から派生する事実の追加
エージェントが利用されるほど、グラフが「よく使われる知識」に最適化されていくため、時間経過とともに精度が落ちるのではなく、じわじわ改善していく方向に働きます。この「使うほど賢くなる」性質は、単発の RAG インデックスとの差別化ポイントの一つです。
cogneeの導入と最小コード例
ここまでで cognee の骨格は掴めたかと思います。次に気になるのは「触ってみるコストがどれくらいか」でしょう。この章では、公式ドキュメントに沿った導入手順と、最小の Python コード例を紹介します。詳細な最新版の手順は Cognee 公式クイックスタート を参照してください。
インストール（pip / uv / Docker）
Python パッケージとしてインストールできます。pip のほか、uv や Docker Compose での起動が公式で案内されています。環境変数として LLM_API_KEY（OpenAI API キー等）を設定するだけで、デフォルト構成では動作します。
Postgres・Neo4j 等のバックエンドを使う場合は、接続情報を環境変数で指定します。Docker Compose を使うと、cognee 本体と Web UI、必要なバックエンドをまとめて起動できます。
remember と recall の最小コード例
公式クイックスタートに掲載されている最小コードは、以下の形です。
import cognee
import asyncio
async def main():
await cognee.forget(everything=True)
text = "Cognee turns documents into AI memory."
await cognee.remember(text)
results = await cognee.recall(query_text="What does Cognee do?")
for result in results:
print(result.text)
if __name__ == '__main__':
asyncio.run(main())
forget でクリーンな状態にした後、remember でテキストを取り込み、recall で質問を投げるだけで、ナレッジグラフの構築と検索が一連の流れとしてつながります。「まず動くところを確認したい」というときに、意思決定コストがほぼゼロで済む API 設計になっている点は評価できます。
セッションIDを使い分けた例とCLI
長期記憶と短期記憶を切り分けるサンプルとして、README には次のコードが掲載されています。
import cognee
import asyncio
async def main():
await cognee.remember("Cognee turns documents into AI memory.")
await cognee.remember("User prefers detailed explanations.", session_id="chat_1")
results = await cognee.recall("What does Cognee do?")
for result in results:
print(result)
results = await cognee.recall("What does the user prefer?", session_id="chat_1")
for result in results:
print(result)
await cognee.forget(dataset="main_dataset")
if __name__ == '__main__':
asyncio.run(main())
session_id を指定した情報はそのセッションに紐づき、指定しない情報はグローバルなナレッジグラフに保持されます。会話文脈と長期知識の分離が、追加の設計なしで表現できる点が特徴です。
CLI も同梱されており、コード無しでも試せます。
cognee-cli remember "Cognee turns documents into AI memory."
cognee-cli recall "What does Cognee do?"
cognee-cli -ui
-ui オプションで Web UI が立ち上がり、ナレッジグラフの可視化や、取り込み済みドキュメントの確認ができます。技術検証の初期段階で「ステークホルダーに触ってもらう」用途にも活用できる構成です。
MCPサーバー同梱｜Claude CodeやCursorから直接使う
cognee のもう一つの実務的な強みが、Model Context Protocol（MCP）サーバーが公式に同梱されている点です。Claude Desktop・Claude Code・Cursor などの MCP 対応クライアントから、cognee のメモリエンジンを直接ツールとして呼び出せます。
cognee-mcpの概要と提供ツール
公式サブディレクトリは cognee-mcp（公式 MCP サーバー） にあります。対応トランスポートは以下の 3 種で、用途に応じて選択できます。
- stdio（ローカル CLI クライアント用のデフォルト）
- SSE（ブラウザ・エージェントランタイム向け）
- HTTP（Docker 経由での本番運用向け・README で推奨）
MCP サーバー経由で提供されるツールは、大きく次の 2 系統です。
- メモリ操作:
remember/recall/forget - UI 操作:
visualize_graph_ui/upload_file_ui/open_cognee_workspace/cognify_file
エージェント側からは「ツール呼び出し」の形で cognee にアクセスできるため、エージェントフレームワークを自作している場合でも、cognee 用のクライアントコードを書く必要がありません。
Claude Desktop / Cursor での設定例
Claude Desktop や Cursor から SSE で接続する場合、設定ファイルは次の形になります。
{
"mcpServers": {
"cognee": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}
出典: cognee-mcp
サーバー側の起動コマンドは、トランスポートごとに以下のように分かれています。
# stdio（デフォルト）
python src/server.py
# SSE
python src/server.py --transport sse
# HTTP（README で推奨）
python src/server.py --transport http --host 127.0.0.1 --port 8000 --path /mcp
出典: cognee-mcp
Docker で起動する場合は、次のコマンドで HTTP トランスポートを立ち上げられます。
docker build -f cognee-mcp/Dockerfile -t cognee/cognee-mcp:main .
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main
出典: cognee-mcp
「エージェント側にどう繋ぐか」という運用フェーズの疑問に対して、MCP を選択するだけで一段抽象化された答えが返ってくる構造になっています。既に Claude Code や Cursor を業務で使っているチームにとっては、cognee の導入コストが大幅に下がるポイントです。
cogneeと類似OSSの比較｜Mem0・Zep・Lettaとの違い
「AI エージェント メモリ」の文脈で頻繁に併記される OSS は、cognee のほかに Mem0・Zep・Letta の 3 つです。どれも似た問題を解こうとしていますが、狙いどころは明確に異なります。この章では、それぞれの位置づけと、cognee がどの領域で選ばれるのかを整理します。
各ツールのポジショニング
ツール | GitHub | ポジショニング |
|---|---|---|
cognee | topoteretes/cognee | セルフホスト前提のナレッジグラフ型メモリ基盤。ドキュメント横断のグラフ構築と GraphRAG に強い |
Mem0 | mem0ai/mem0 | 既存エージェントに後付けする「メモリレイヤー」。事実抽出中心で、グラフ機能は Pro プランに閉じ込められている |
Zep | getzep/zep | 会話履歴を「時間的ナレッジグラフ（Temporal Knowledge Graph）」として保持し、状態遷移を追跡 |
Letta（旧 MemGPT） | letta-ai/letta | 「エージェント自体が記憶」というランタイム型。長期タスクを継続実行するエージェント向け |
自社の tech-blog では過去に類似領域を扱ってきており、AIエージェントの永続メモリ基盤にagentmemoryが選ばれる理由や AIエージェントのメモリ基盤にSupermemoryが選ばれる理由｜Mem0との違い、ナレッジグラフで会話を記憶するAIコワーカーRowboatの導入と活用 といった記事で個別のプロダクトを掘り下げています。あわせて読むと、この領域のプロダクトが「何を主戦場にしているか」の相場感を掴みやすくなります。
「ナレッジグラフ特化」というcogneeの独自性
上表の 4 者を「メモリの主な形」で並べると、次のように整理できます。
- 単純なチャット履歴の要約と保存 → Mem0（既存エージェントに後付けしやすい）
- 時系列で変化する会話状態の追跡 → Zep（住所変更などの状態遷移を時間軸で追える）
- エージェント自体が長寿命で走り続ける → Letta（ステートフルなエージェントランタイム）
- 多様なドキュメントを横断したナレッジグラフ検索 → cognee（GraphRAG に一次対応）
cognee の独自ポイントを言語化すると、次の 3 点になります。
- GraphRAG を OSS のままフル機能で扱える: Mem0 のようにグラフ機能を有償プランに閉じ込めるのではなく、Apache-2.0 のまま利用できる
- Postgres 1 台でグラフ+ベクトル+セッションを賄える: 運用対象のデータストアを最小化しやすい
- MCP サーバー同梱でエージェントに直挿しできる: Claude Desktop / Claude Code / Cursor と接続コストがほぼゼロ
ユースケース別の選定ガイド
意思決定を最短にするために、ユースケース別の選定目安を挙げておきます。
やりたいこと | 第一候補 | 補足 |
|---|---|---|
ChatGPT 風のチャットに個人化メモリを載せたい | Mem0 | 会話履歴からの事実抽出が中心。導入が最も軽い |
顧客との継続会話・状態遷移を追跡したい（CRM 等） | Zep | 時系列グラフ・状態遷移に強い |
数時間〜数日規模でエージェントを走らせ続けたい | Letta | ステートフルなエージェントランタイム |
社内ドキュメント・ログ・コードを横断して「意味と関係」で引きたい | cognee | GraphRAG・セルフホスト・MCP 対応 |
「どれを選ぶか」で迷ったら、まず扱う対象が「会話」か「ドキュメント」か、そして運用形態が「SaaS で完結」か「セルフホスト」かの 2 軸で切ると判断が早くなります。cognee は「セルフホスト × ドキュメント横断」の象限で最初に検討される選択肢と言えます。
cogneeが向くケース・向かないケース
意思決定の最終ゲートとして、cognee が「向くケース」と「向かないケース」を整理します。読者が自分のプロジェクトに当てはめてチェックしやすいよう、条件を具体化しました。
cogneeが強みを発揮するユースケース
以下のいずれかに該当する場合、cognee は有力な選択肢になります。
- 複数ドキュメント横断のナレッジ検索を作りたい: 単一の RAG インデックスではなく、エンティティ・関係性を持ったグラフで引きたい
- セルフホストが要件になっている: 顧客データ・機密情報を SaaS に預けたくない、あるいはネットワーク隔離下で運用したい
- Postgres 中心のインフラで完結させたい: 追加のグラフ DB・ベクトル DB を増やしたくない中規模プロジェクト
- Claude Code / Cursor / Claude Desktop を業務で使っている: MCP 経由で cognee をツールとして呼び出せる恩恵が大きい
- エージェントの精度を「使うほど改善」させたい:
memifyの再重み付け・剪定を活かして、長期運用でグラフを鍛えていきたい
他ツールの方が適するケース
逆に、以下のケースでは cognee 以外のほうが素直な選択になります。
- 単純なチャット履歴の要約・保存で足りる: Mem0 のほうが後付けの手間が少ない
- 会話の状態遷移（顧客ステータス変更等）を時系列で追う必要がある: Zep の時系列グラフが直接刺さる
- フルマネージド SaaS で運用工数を最小化したい: セルフホスト前提の cognee とは方向性が逆になる
- 1 つのエージェントを長時間走らせ続けたい: Letta のようなランタイム型のほうが本旨に合う
なお、ライセンスは Apache-2.0 のため、商用組み込みや改変配布の自由度は高いですが、著作権表示・変更内容の告知など Apache-2.0 の一般的な条件は満たす必要があります。ライセンス条項の詳細は原文を確認してください。
まとめ｜cognee採用の判断ポイント
本記事の要点を、意思決定に使える形で再整理します。
- cognee の骨格: セルフホスト型のナレッジグラフエンジンで、AI エージェントにセッションを跨ぐ長期記憶を与えることに特化した OSS（Apache-2.0）
- 主要 API:
remember/recall/forget/improveの 4 つで、6 行程度のコードから GraphRAG が走る - バックエンド: Postgres 単体で「グラフ + ベクトル + セッション」を賄える構成が可能。Neo4j・Neptune・Qdrant・Weaviate 等の代表的な選択肢に一次対応
- MCP サーバー同梱: Claude Desktop / Claude Code / Cursor からツールとして直接呼び出せる
- 競合との差別化: Mem0（後付けメモリ）、Zep（時系列会話グラフ）、Letta（長寿エージェントランタイム）に対して、cognee は「ドキュメント横断のグラフ検索 × セルフホスト」を主戦場としている
- 選定の 2 軸: 扱う対象が「会話 or ドキュメント」、運用形態が「SaaS or セルフホスト」で切ると判断が早い
次のステップとしては、Cognee 公式ドキュメント や Cognee 公式クイックスタート を参照しつつ、自プロジェクトで最も価値が出そうなユースケース（例: 社内ドキュメント横断検索、エージェントのユーザー記憶）を 1 つ切り出して、最小構成で検証するのが現実的です。判断軸が固まった状態で PoC に入れば、投資対効果の議論もぶれずに進められるはずです。
なお、本記事の記述は公式ドキュメント・README・GitHub API から取得した公開情報に基づいています。実装や API シグネチャは今後変更される可能性があるため、導入時は必ず 公式ドキュメント と GitHub リポジトリ の最新版を参照してください。
