AIエージェントはセッションをまたいで何も覚えていない——この課題に正面から向き合うOSSが、正式版として姿を現しました。
この記事では、Cognee 1.0の新機能と性能・コスト面の特徴を整理します。
この記事でわかること
- Cognee 1.0で追加されたメモリネイティブAPIの全体像
- BEAMベンチマークでの精度と、フルコンテキスト方式とのコスト差
- Postgres単体運用や既存メモリツールからの移行方法
Cognee 1.0は何が変わったか
Cogneeは、AIエージェント向けのオープンソース記憶プラットフォームです。2026年6月26日にv1.0が発表され、開発者向けのAPI設計と本番運用の前提が大きく整理されました。
従来のadd・cognify・searchというパイプライン指向の呼び出しから、エージェントの動きに合わせた4つの動詞——remember・recall・improve・forget——が前面に出ています。公式ブログでは「記憶はエージェントに後付けする機能ではなく、欠けている基盤層だ」と位置づけられています。
なぜ長期記憶が必要なのか
LLMのコンテキストウィンドウは年々拡大していますが、セッションが終われば会話内容は消えます。毎回コーパス全体をプロンプトに詰め込むフルコンテキスト方式は、質問のたびに同じトークンコストが発生するため、繰り返し問い合わせるほど割高になります。
Cogneeはベクトル検索とナレッジグラフを組み合わせ、一度取り込んだ情報を構造化して保持します。remember()で記憶を構築し、recall()で必要な断片だけを引き出す設計です。公式のトークンコスト分析では、安定したコーパスに対する繰り返しクエリで、フルコンテキスト方式との損益分岐点はおよそ23〜26回に達すると報告されています。
メモリネイティブAPIの4つの動詞
Cognee 1.0の中心は、記憶のライフサイクルを4コマンドで扱える点です。
rememberはテキストやドキュメントを受け取り、エンティティと関係を抽出してグラフに接続します。session_idを付けるとセッション用の高速キャッシュに入り、会話の文脈を即座に参照できます。
recallは自然言語の質問に対し、グラフ走査・ベクトル検索・BM25のハイブリッド検索で関連記憶を返します。セッションキャッシュを先に見て、見つからなければ永続グラフへフォールバックします。
improveは利用・修正・フィードバックのシグナルで記憶の重みを更新します。誤った回答が訂正されても、その修正が次回の検索に反映される仕組みです。
forgetはデータセット単位や個別メモリの削除に対応し、不要になった情報をグラフから切り離します。
import cognee
await cognee.remember("Cogneeはドキュメントをエージェントの記憶に変換する")
results = await cognee.recall("Cogneeは何をするツールか")
await cognee.improve()
await cognee.forget(dataset="main_dataset")
Python SDKに加え、TypeScript SDK（npm i cognee）とエッジ向けのRustコアも提供されています。Claude Code、Cursor、OpenClawなどMCP対応エージェントからも接続できます。
BEAMベンチマークで示された精度
BEAMは長い会話の中で情報が変化・矛盾・更新される状況をテストするベンチマークです。針を探す型の長文テストより、エージェント記憶の評価に適しているとCognee側は説明しています。
Cogneeはデフォルト設定と標準のOSS機能のみでBEAMを実行し、カスタムモデルやベンチマーク専用パイプラインは使っていません。結果は次のとおりです。
| 設定 | Cognee | 従来のSOTA | RAGベースライン |
|---|---|---|---|
| 100Kトークン | 79% | 73.5% | 約33% |
| 10Mトークン | 67% | 64.1% | 約33% |
公式の深掘り記事では、100K設定でLlama-4上の標準RAGベースラインが32.3%だったのに対し、Cogneeが79%を記録したと説明されています。相対的には145%の改善に相当する数値として公開されています。ただしベンチマークは方向性の指標であり、実運用の品質をそのまま保証するものではありません。
1000億トークン相当のスケールとは
発表動画やSNSで「1000億トークン」という表現が使われましたが、これは単一のコンテキストウィンドウのサイズではありません。Cogneeが取り込めるデータ量をトークン数に換算した保守的な目安です。
公式の計算例では、500GBのデータを約5バイト/トークンで割ると1000億トークン相当になります。Cogneeは1テラバイト超のデータ取り込みにも対応しており、この数値は下限に近い位置づけです。並列・分散取り込みにより、単一モデルのコンテキスト上限に縛られずに記憶を蓄積できる点が強調されています。
コスト面での優位性
フルコンテキスト方式は毎回コーパス全体をモデルに送るため、クエリ回数に比例してコストが増えます。Cogneeはremember()で一度記憶を構築し、recall()では関連部分だけを取得するため、繰り返し利用するほど差が広がります。
公式の測定では、100Kトークンのコーパスに対し170回以上のクエリを重ねた時点で、メモリ方式のトークン消費がフルコンテキストの約14.4%（いわゆる7倍安い）に収束すると報告されています。50問の比較ではGPT-5.5のフルコンテキスト基準線が約420ドル、Cogneeが約60ドルで、トークン使用量は約85%削減されたとも示されています。
Postgres単体で記憶基盤を運用できる
従来のグラフメモリ基盤は、グラフDB・ベクトルDB・Redis・リレーショナルDBを別々に立てる構成が一般的でした。Cognee 1.0ではPostgres 1台にグラフ・ベクトル（pgvector）・セッション・メタデータをまとめて載せられます。CIベンチマークでは、分離構成よりPostgres検索が約10%高速だったと報告されています。
ローカル開発はSQLite・LanceDB・Ladybugの組み合わせで追加インフラなしに動き、本番ではPostgresへ切り替える流れが想定されています。Railway、Render、Fly.io、Modalへのワンクリックデプロイにも対応しています。
既存ツールからの移行とデータの持ち出し
Mem0、Zep、Lettaのエクスポートをremember()に渡すだけでCogneeへ取り込めます。逆にCOGX形式やGraphML、JSON、Cypherで記憶をエクスポートでき、ベンダーロックインを避ける設計です。
@agent_memoryデコレータを関数に付けると、実行前に関連記憶を注入し、実行後にトレースを永続化する一連の処理が自動化されます。1行の追加でセルフインプルーヴする記憶をエージェントに組み込める点が、v1.0の実用面での差分です。
誰に向いているか
Cognee 1.0は、セッションをまたいで文脈を保持したいエージェント開発者、自社データを自前ホストしたいチーム、MCP経由でClaude CodeやCursorに記憶を持たせたい個人開発者に向いています。月間約600万メモリの作成実績があり、Bayerなど100社以上で利用されていると公式は述べています。
Apache 2.0ライセンスでpip install cogneeから試せます。マネージドのCognee Cloudとセルフホストの両方に対応しており、同じAPIで切り替え可能です。長文を毎回丸ごと送る方式から、構造化された永続記憶へ移行する選択肢として、今後のエージェント開発の標準的な部品になり得るリリースです。