cogneeとは何か——GitHubスター15,000超の「6行AIメモリエンジン」
cogneeは「6行のコードでAIエージェントに長期記憶を与えるナレッジエンジン」として、2026年4月現在GitHubスター15,474・フォーク1,591を記録するOSSだ。
開発元はtopoteretes。ライセンスはApache 2.0で商用利用も可能。最新バージョンはv1.0.1.dev1（2026年4月15日リリース）。公式説明は “Knowledge Engine for AI Agent Memory in 6 lines of code” だ。
AIエージェントが会話をまたいで情報を「覚え」「思い出し」「忘れる」能力を、ベクトルDB単体ではなくナレッジグラフ＋ベクトル検索＋セマンティックルールの組み合わせで実現する。
インストールはPython 3.10〜3.13で動作し、以下のワンライナーから始められる：
pip install cognee
最小限のコードで動作を確認できる：
import cognee
import asyncio
async def main():
# データをナレッジグラフに記憶
await cognee.remember("cogneeはAIエージェントに長期記憶を与えるOSSです。")
# 自然言語で検索・想起
results = await cognee.recall("cogneeとは何ですか？")
for result in results:
print(result)
asyncio.run(main())
コアAPIは4つの操作に集約されている：
| 操作 | メソッド | 説明 |
|---|---|---|
| 記憶 | cognee.remember() |
データをナレッジグラフに格納（add + cognify の一括実行） |
| 想起 | cognee.recall() |
自然言語クエリでメモリを検索 |
| 削除 | cognee.forget() |
指定データをグラフから削除 |
| 改善 | cognee.improve() |
フィードバックでメモリ品質を向上 |
cogneeは公式サイト・READMEで「次世代メモリ」という表現は直接使っていないが、「AIエージェントのメモリを根本的に再設計する」というコンセプトで開発されている。単純なRAGを「ナレッジグラフ推論」へ昇華させるアプローチが、研究・実務コミュニティで高い評価を受けている。
この章のポイント
- cogneeは「6行でAIエージェントに長期記憶」を実現するApache 2.0のOSS（スター15,000超）
- remember / recall / forget / improve の4操作がコアAPI
- Python 3.10〜3.13対応、ワンラインインストール可能
なぜ従来のRAGやベクトルDBでは足りないのか
AIアプリケーションでよく使われる「RAG（Retrieval-Augmented Generation）」は、文書をチャンクに分割してベクトル化し、クエリに近いチャンクをLLMに渡す手法だ。RAGFlowのようなエンタープライズRAGエンジンを含む多くのフレームワークがこの手法を実装している。
しかし、ベクトル検索型RAGには根本的な限界がある：
| 課題 | ベクトルRAGの問題 | cogneeのアプローチ |
|---|---|---|
| 文脈断絶 | チャンク間の関係を保持しない | エンティティ間関係をグラフで保持 |
| 多段推論 | 複数チャンクを繋いだ推論が苦手 | グラフトラバーサルで多段推論可能 |
| 情報更新 | 全件再インデックスが必要なことがある | ノード単位での更新が可能 |
| セマンティック曖昧性 | キーワードの類似度が主 | エンティティ型・関係型で構造化 |
| メモリ永続化 | セッション間の記憶保持が困難 | グラフDBに永続化、セッション横断で利用可能 |
最大の違いは「関係性の保持」だ。たとえば「Aliceは機械学習エンジニアで、プロジェクトXに携わっている」という情報をベクトルRAGに格納しても、「プロジェクトXのエンジニアは誰か」という複合クエリには弱い。cogneeはこれをグラフのノードとエッジとして保持し、関係性を軸にした精度の高い検索が可能だ。
RAGFlowとcogneeは競合ではなく補完関係にある。RAGFlowは高精度な文書解析・OCR処理に強みを持ち、cogneeはその後段のエージェント長期メモリ管理に特化している。
この章のポイント
- ベクトルRAGは「文書チャンクの類似検索」に過ぎず、関係性・多段推論・永続化が弱い
- cogneeはナレッジグラフでエンティティ間関係を保持し、セッション横断のメモリを実現
- RAGFlowとは文書解析（RAGFlow）＋エージェントメモリ（cognee）で組み合わせ可能
cogneeのアーキテクチャ：ECLパイプラインの仕組み
cogneeのコアは ECLパイプライン（Extract-Cognify-Load） だ。名前はETL（Extract-Transform-Load）から着想を得ており、生データをAIが推論できる知識構造へ変換するプロセスを定義している。
(テキスト・PDF・URL・コード)"] --> B["Extract
エンティティ抽出"] B --> C["Cognify
意味付け・関係構築"] C --> D["Load
グラフDB + ベクトルDB"] D --> E["Recall
マルチ戦略検索"] E --> F["LLM
応答生成"] style A fill:#f0f4ff,stroke:#4a6cf7 style B fill:#f5f0ff,stroke:#7c3aed style C fill:#fff4e0,stroke:#f59e0b style D fill:#f0fff4,stroke:#22c55e style E fill:#fff0f5,stroke:#ec4899 style F fill:#fdf4ff,stroke:#a855f7
各ステージの詳細：
Extract（抽出）：入力データ（テキスト・PDF・URL・コードなど）からエンティティ・概念・固有表現を抽出する。LLMを活用して「この文書に登場する人物・組織・概念を列挙せよ」のような処理を行う。
Cognify（認知化）：抽出したエンティティ間の関係を推論・構築するステージ。これがcogneeの最も重要な特徴だ。単純なキーワード抽出ではなく意味的な関係グラフを構築する。処理コストはかかるが、後の検索精度を大幅に向上させる。
Load（格納）：構築した知識グラフをグラフDB（KuzuDB・Neo4j・PostgreSQLなど）に、埋め込みベクトルをベクトルDB（LanceDB・ChromaDB・PGVectorなど）に格納する。デフォルトはローカルファイルベースで動作する。
remember() が高レベルAPIとして add + cognify + 保存を一括実行する一方、低レベルAPIでは処理ステップを分けて制御できる：
import cognee
import asyncio
async def main():
# Step 1: データセットを指定してデータを追加
await cognee.add("docs/", dataset_name="my_project")
# Step 2: ECLパイプラインを実行（エンティティ抽出・グラフ構築）
await cognee.cognify()
# Step 3: セマンティック検索
results = await cognee.search("プロジェクトのアーキテクチャは？")
for r in results:
print(r)
asyncio.run(main())
remember() は add + cognify + 保存を一括実行する高レベルAPI。素早く試したい場合に便利。cognify() は add済みデータを明示的に処理するローレベルAPI。多量データを一括 add してから一括 cognify したいバッチ処理では後者を使う。
この章のポイント
- ECL = Extract（抽出）→ Cognify（認知化）→ Load（格納）の3ステップ
- Cognifyステップでエンティティ間の意味的関係グラフを構築（これがRAGとの最大差）
- グラフDB（KuzuDB/Neo4jなど）とベクトルDB（LanceDBなど）の両方に格納する二重インデックス
ナレッジグラフ×ベクトル検索×ルールベースの三層構造
cogneeの検索（Recall）は単純なベクトル類似検索ではなく、3層の検索戦略を組み合わせている。
戦略選択"} R --> V["ベクトル検索
LanceDB / ChromaDB
意味的類似度"] R --> G["グラフ検索
KuzuDB / Neo4j
関係トラバーサル"] R --> S["セマンティックルール
オントロジー定義
スキーマ制約"] V --> M["マージ・ランキング"] G --> M S --> M M --> C["コンテキスト構築"] C --> L["LLM 応答生成"] style Q fill:#fdf4ff,stroke:#a855f7 style R fill:#fff4e0,stroke:#f59e0b,font-weight:bold style V fill:#f0f4ff,stroke:#4a6cf7 style G fill:#f0fff4,stroke:#22c55e style S fill:#fff0f5,stroke:#ec4899 style M fill:#f5f5f5,stroke:#666
ベクトル検索（Vector Search）：LanceDB（デフォルト）やChromaDB、PGVectorを使った意味的類似検索。従来のRAGと同様の手法だが、cogneeではナレッジグラフと組み合わせてコンテキストを豊かにする。
グラフ検索（Graph Traversal）：KuzuDB（デフォルト）やNeo4jを使ったグラフトラバーサル。「AはBに関連し、BはCである」という多段推論が得意。複雑な関係クエリに対して特に有効だ。
セマンティックルール（Ontology）：v1.0からユーザーカスタムオントロジーをサポート。エンティティの型定義（例：「PersonはNameとRoleを持つ」）を与えることで、データの格納・検索精度を向上させる。ユーザーごとのオントロジーはv1.0.1でサポートされ、アップグレードをまたいで保持される。
デフォルトのデータベース構成（すべてローカルファイルベース、外部サービス不要）：
# デフォルト構成（追加設定なしで動作）
GRAPH_DATABASE_PROVIDER=kuzu # グラフDB（ローカルファイル）
VECTOR_DB_PROVIDER=lancedb # ベクトルDB（ローカルファイル）
DB_PROVIDER=sqlite # リレーショナルDB（ローカルファイル）
この章のポイント
- 3層（ベクトル・グラフ・ルール）の組み合わせが従来のRAGより高精度な検索を実現
- グラフ検索で多段推論・関係クエリに対応
- デフォルト設定はすべてローカルファイルベース——外部DBサービス不要で即起動
ローカルセットアップ：PythonとDockerの両手順
Pythonでのインストール
Python 3.10〜3.13が必要だ。推奨はuvまたはpipを使った仮想環境へのインストール。
# 最小インストール（ローカルDB使用）
pip install cognee
# Anthropic Claude連携に必要な追加パッケージも含めてインストール
pip install "cognee[anthropic]"
# uvを使う場合（推奨）
uv pip install "cognee[anthropic]"
cogneeはモジュール型でインストール時に依存をExtraで指定する。
[anthropic]以外にも[neo4j]（Neo4j対応）、[postgres]（PostgreSQL対応）、[fastembed]（ローカル高速埋め込み）、[api]（REST APIサーバー）、[codegraph]（コードベース解析）などが用意されている。
Dockerでの起動
リポジトリにdocker-compose.ymlが同梱されており、コンテナで試すこともできる：
# リポジトリをクローン
git clone https://github.com/topoteretes/cognee.git
cd cognee
# 環境変数ファイルを作成
cp .env.example .env
# .envを編集してAPIキーを設定（次節参照）
# Docker Composeで起動
docker compose up
Dockerで起動するとポート8000でREST APIサーバー、ポート3000でWebフロントエンドが立ち上がる。ブラウザから http://localhost:3000 でGUIを操作できる。
環境変数の設定（.envファイル）
# .env ファイル（Anthropic Claude使用時）
LLM_PROVIDER=anthropic
LLM_MODEL=claude-3-5-sonnet-20241022
LLM_API_KEY=sk-ant-xxxxxxxx
# 埋め込みモデル（Anthropicは埋め込みAPIを持たないため別途設定が必要）
# オプション1: OpenAI埋め込みを使う場合
EMBEDDING_PROVIDER=openai
EMBEDDING_MODEL=text-embedding-3-small
EMBEDDING_API_KEY=sk-xxxxxxxx
# オプション2: ローカル埋め込みモデルを使う場合（pip install "cognee[fastembed]"が必要）
# EMBEDDING_PROVIDER=fastembed
# EMBEDDING_MODEL=BAAI/bge-small-en-v1.5
# データ保存先（デフォルトはカレントディレクトリ）
# DATA_PATH=./cognee_data
LLM_PROVIDER=anthropic に設定するとLLM（推論）はClaudeを使うが、埋め込み（Embedding）はAnthropicが独自APIを提供していないため別プロバイダーの設定が必要だ。設定しないと埋め込み処理でエラーが発生する。OpenAI埋め込み（text-embedding-3-small）か、[fastembed]オプションのローカルモデルを推奨する。
この章のポイント
pip install "cognee[anthropic]"でAnthropicサポート付きインストール- Dockerで起動するとGUIも付いてくる（ポート3000）
- Anthropic使用時は
EMBEDDING_PROVIDERを必ず別途設定する
Claude APIとの連携設定——Anthropicプロバイダーの実装例
cogneeはAnthropicをファーストクラスのLLMプロバイダーとしてサポートしている。.envファイルの設定でも、Pythonコード内での動的設定でも動作する。
# cognee_with_claude.py
import os
import asyncio
import cognee
# 環境変数で設定する場合は .env に以下を記述してから実行：
# LLM_PROVIDER=anthropic
# LLM_MODEL=claude-3-5-sonnet-20241022
# LLM_API_KEY=sk-ant-...
# EMBEDDING_PROVIDER=openai (or fastembed)
# EMBEDDING_API_KEY=sk-...
async def main():
# ナレッジグラフにデータを記憶
documents = [
"プロジェクトのバックエンドはFastAPI（Python 3.12）で実装されている。",
"データベースはPostgreSQL 16を使用。本番環境はAWS RDSに配置。",
"フロントエンドはNext.js 15とTailwindCSSを採用。Vercelにデプロイ。",
"チームはバックエンド3名、フロントエンド2名の5名構成。",
]
for doc in documents:
await cognee.remember(doc)
print("✅ ナレッジグラフへの記憶完了")
# 関係クエリで想起
queries = [
"バックエンドの技術スタックは？",
"デプロイ先のインフラは？",
]
for q in queries:
print(f"\n🔍 質問: {q}")
results = await cognee.recall(q)
for r in results:
print(f" → {r}")
asyncio.run(main())
対応するClaudeモデルはAnthropicのAPIで有効なモデルIDを指定できる：
# 高精度・バランス重視
LLM_MODEL=claude-3-5-sonnet-20241022
# 最高性能（Cognifyの精度最大化）
LLM_MODEL=claude-opus-4-6
# 高速・低コスト（大量データのCognifyに）
LLM_MODEL=claude-haiku-4-5-20251001
Cognify（インデックス構築）は初回に処理コストがかかる。一方、Recall（検索）は安価に運用できる。大量の文書を取り込む場合は、Cognifyのコストを考慮してモデルを選択すること。開発・テスト時は claude-haiku-4-5-20251001 で試し、本番で claude-3-5-sonnet-20241022 に切り替えるアプローチが現実的だ。
この章のポイント
- 環境変数
LLM_PROVIDER=anthropic/LLM_MODEL/LLM_API_KEYでClaude連携 - Cognify（インデックス）は初回コストがかかる——開発時はHaikuで試すのが経済的
claude-opus-4-6でCognifyの精度最大化、claude-haiku-4-5-20251001でコスト最適化
cognee + Anthropic SDKでエージェントにメモリを持たせる実装例
cogneeを「Anthropicエージェントの長期メモリストア」として使う実装例を示す。LangChainのMemoryモジュールと発想は似ているが、cogneeはグラフDBバックエンドにより関係性の複雑なクエリにも対応する点が異なる。
# memory_agent.py
import os
import asyncio
import anthropic
import cognee
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
async def remember(content: str) -> None:
"""情報をナレッジグラフに記憶する"""
await cognee.remember(content)
async def recall_context(query: str) -> str:
"""ナレッジグラフから関連情報を想起する"""
results = await cognee.recall(query)
if results:
return "\n".join(str(r) for r in results[:5])
return "関連情報なし"
async def chat_with_memory(user_message: str) -> str:
"""cogneeのメモリを活用してClaudeと会話する"""
# 関連メモリを取得してシステムプロンプトに注入
memory_context = await recall_context(user_message)
system = f"""あなたは長期記憶を持つAIアシスタントです。
以下は過去に記憶された関連情報です：
{memory_context}
この情報を参照しながら質問に答えてください。"""
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
system=system,
messages=[{"role": "user", "content": user_message}]
)
answer = response.content[0].text
# 会話内容を次回のためにメモリに保存
await remember(f"Q: {user_message} / A: {answer[:200]}")
return answer
async def main():
# 事前知識をナレッジグラフに蓄積
await remember("プロジェクト名はAI-HUBで、AIニュースキュレーションサービスです。")
await remember("技術スタックはPython + FastAPI + PostgreSQL + Redis。")
await remember("本番環境はAWS ECSにデプロイ。インフラはTerraformで管理。")
await remember("毎朝8時にGitHub Actionsで自動クロールが走る設定。")
print("=== メモリ付きエージェントデモ ===\n")
questions = [
"このプロジェクトのインフラ管理ツールは何ですか？",
"自動処理はいつ実行されますか？",
]
for q in questions:
print(f"Q: {q}")
answer = await chat_with_memory(q)
print(f"A: {answer}\n")
asyncio.run(main())
このパターンのポイントは3つだ：
- recall() でコンテキスト取得 → システムプロンプトに注入してClaude APIを呼ぶ
- 会話後に remember() → 次回のための長期記憶として保存
- cogneeがセッション間の記憶を管理 → アプリを再起動してもグラフDBに保持される
この章のポイント
- recall()でコンテキスト取得→システムプロンプト注入→会話後にremember()が基本パターン
- cogneeがグラフDBにセッション横断で記憶を保持、アプリ再起動後も利用可能
- Anthropic SDKとの組み合わせはライブラリレベルで疎結合——他のSDKとも同様に使える
Claude Desktop × MCP連携でノーコード活用
cogneeはリポジトリ内の cognee-mcp/ ディレクトリにMCP（Model Context Protocol）サーバー実装を含んでいる。これを使うとClaude DesktopやClaude Codeから直接cogneeのメモリ機能を呼び出せる。
cognee-mcpが提供するMCPツール：
- remember — データをナレッジグラフに記憶
- recall — 自然言語でメモリを検索・想起
- forget — 指定データを削除
- improve — フィードバックでメモリを改善
- ingest_local_file — ローカルファイルをナレッジグラフに取り込み
- run_background_pipeline — バックグラウンドでECLパイプラインを実行
MCPのトランスポートはstdio（デフォルト）、SSE、Streamable HTTPから選択できる。
Claude Desktopへの接続設定の概要（詳細はcognee-mcp公式READMEを参照）：
// claude_desktop_config.json の設定例（概要）
{
"mcpServers": {
"cognee": {
"command": "uvx",
"args": ["cognee-mcp"],
"env": {
"LLM_PROVIDER": "anthropic",
"LLM_MODEL": "claude-3-5-sonnet-20241022",
"LLM_API_KEY": "sk-ant-xxxxxxxx",
"EMBEDDING_PROVIDER": "openai",
"EMBEDDING_API_KEY": "sk-xxxxxxxx"
}
}
}
}
cognee-mcpはv1.0.x時点でアクティブに開発中だ。設定オプション・コマンド名はバージョンによって変わる可能性がある。必ずcognee-mcp公式READMEで最新の設定方法を確認してから使用すること。
MCPサーバーをDockerで起動するオプションもある：
# cognee-mcpディレクトリで
cd cognee-mcp
# Dockerfileからビルドして起動
docker build -t cognee-mcp .
docker run -p 8000:8000 \
-e LLM_PROVIDER=anthropic \
-e LLM_MODEL=claude-3-5-sonnet-20241022 \
-e LLM_API_KEY=sk-ant-xxxxxxxx \
cognee-mcp
MCP設定の詳細はMCPサーバー構築ガイドも参考になる。
また、公式の cognee-integrations リポジトリにはClaude Code専用の統合プラグインも含まれており、Claude Codeのセッション間でメモリを永続化するフック設定が可能だ。
この章のポイント
- cognee-mcp（リポジトリ内）でMCPサーバーとして動作、Claude Desktopに接続可能
- remember/recall/forget/improve/ingest_local_fileがMCPツールとして提供される
- cognee-integrations にClaude Code専用の統合プラグインあり
実践ユースケース：cogneeの活用シナリオ
公式READMEとGitHubの情報に基づく活用シナリオを整理する。
Slack・PR・仕様書"] A3["研究論文・PDF"] A4["コードリポジトリ"] end subgraph cognee B["ECL Pipeline
抽出・認知化・格納"] C["ナレッジグラフ
+ ベクトルDB"] end subgraph 活用 D["自然言語クエリ"] E["マルチエージェント
共有メモリ"] F["Claude Desktop
via MCP"] end A1 --> B A2 --> B A3 --> B A4 --> B B --> C C --> D C --> E C --> F style B fill:#fff4e0,stroke:#f59e0b,font-weight:bold style C fill:#f0fff4,stroke:#22c55e,font-weight:bold
個人ナレッジ管理（PKM）：読んだ記事・会議メモ・アイデアをcogneeに取り込み、後から「あの会議でXについて何が決まったか」を自然言語で検索できる。cognee.add()はテキスト文字列だけでなくファイルパスやURLも受け付ける。
チームナレッジベース：ドキュメント・仕様書・過去の意思決定記録をcogneeに格納し、「この機能の設計根拠は？」といった質問に答えられるナレッジベースを構築できる。
研究ノート・論文管理：PDF論文を cognee.add("paper.pdf") で取り込み、Cognifyでエンティティ（手法名・評価指標・データセット）と関係を抽出。「手法Xを使っている論文は？」と横断的に検索できる。
コードベース解析：pip install "cognee[codegraph]" でコードリポジトリを解析し、関数間の依存関係グラフを構築。「この関数はどこから呼ばれているか」をナレッジグラフとして把握した状態でコーディングができる。
マルチエージェント共有メモリ：複数のAIエージェントが同一のcogneeインスタンスを共有することで、エージェント間でコンテキストを引き継ぎながら協調作業が可能になる。
この章のポイント
- PKM・チームナレッジ・研究管理・コード解析・マルチエージェントと幅広いユースケース
- テキスト・ファイルパス・URLを直接ingestion可能
cognee[codegraph]でコードベースの関係グラフ構築も対応
他ツールとの比較：cognee vs mem0・MemGPT・LangChain Memory
AIメモリ・RAG領域のツールとcogneeの特徴を比較する。
| ツール | アプローチ | グラフDB対応 | 自己ホスト | Claude対応 | 特徴 |
|---|---|---|---|---|---|
| cognee | GraphRAG + Vector + Ontology | ✅ | ✅ | ✅ | ECLパイプライン、エンティティ関係グラフ、MCP対応 |
| mem0 | Embedding + 構造化メモリ | 一部 | ✅ | ✅ | シンプルなAPI、メモリ層の差し替えに特化 |
| MemGPT | OS型メモリ階層管理 | ❌ | ✅ | ✅ | コアメモリ/外部メモリの階層管理 |
| LangChain Memory | バッファ/サマリ/Vector | ❌ | ✅ | ✅ | LangChainエコシステムへの統合 |
| RAGFlow | Document RAG + OCR | ❌ | ✅ | 設定依存 | 高精度文書解析・エンタープライズRAG |
| MemPalace | 圧縮メモリ + Graph | ✅ | ✅ | ✅ | 170トークンで全記憶呼び出す超高効率圧縮 |
cogneeが最も差別化されているのは「ナレッジグラフ＋ベクトル検索＋オントロジーの統合」だ。mem0はよりシンプルなAPIでメモリ差し替えに特化し、MemGPTはOS比喩のメモリ階層管理に特化している。用途によっては他ツールが適切な場合もある。
MemPalaceの超高効率圧縮メモリと比較すると、MemPalaceは「トークン効率の最大化（LongMemEvalスコア96.6%）」に特化し、cogneeは「関係性の精度とクエリの複雑さへの対応」に強みがある。どちらを選ぶかはユースケース次第だ。
cogneeを選ぶべき場面：
- 文書間・概念間の関係性を重視するクエリが多い
- 多段推論が必要なエージェントを構築したい
- グラフDBを使ったオントロジー管理をしたい
- MCPでClaude Desktopと統合したい
この章のポイント
- cogneeはグラフDB活用で関係クエリ・多段推論が得意、mem0はシンプルさが強み
- 「複雑な関係推論」ならcognee、「軽量メモリ層追加」ならmem0が適する
- RAGFlowとは文書解析（RAGFlow）＋エージェントメモリ（cognee）で役割分担が可能
よくある疑問・つまずきポイント
Q. cognifyに時間がかかりすぎる
→ Cognifyはエンティティ抽出・関係推論に複数回のLLM呼び出しを行う。大量データの初回インデックスは時間・コストがかかる。まず小さなデータセットで動作確認し、本番では段階的にデータを追加する運用を推奨する。
Q. Anthropicで埋め込みエラーが出る
→ AnthropicはOpenAI互換の埋め込みAPIを持たない。EMBEDDING_PROVIDER を別途設定する必要がある（OpenAI、Voyageなど）。または pip install "cognee[fastembed]" でローカル埋め込みモデルを使う方法もある。
Q. recall()が空のリストを返す
→ add() 後に cognify() を実行していない可能性がある。remember() を使えばadd+cognifyが自動実行される。または await cognify() の完了を確認する。
Q. Neo4j・PostgreSQLを使いたい
→ 環境変数 GRAPH_DATABASE_PROVIDER=neo4j と接続情報を設定し、pip install "cognee[neo4j]" を追加インストールする。本番環境ではKuzuDB（デフォルト）からNeo4jへの移行も選択肢だ。
Q. Docker起動後にポート3000にアクセスできない
→ フロントエンドのビルドが必要な場合がある。docker compose logs cognee-frontend でエラーを確認する。また、ファイアウォール設定でポート3000が開いているか確認する。
2026年4月時点でリリースされている v1.0.1.dev1 はプレリリース版（dev=開発版）だ。本番環境への導入前に、GitHubリリースページで安定版のリリース状況を確認することを推奨する。
この章のポイント
- Anthropic使用時は埋め込みモデルを別途設定——これが最も多いつまずきポイント
- recall()が空なら cognify() の実行漏れを確認
- v1.0.1.dev1はプレリリース版——本番導入は安定版リリース後を推奨
