チームで AI コーディングエージェントを使い始めると、ほどなく同じ壁にぶつかります。ある開発者がエージェントとの長い対話の末にたどり着いた設計判断や、試行錯誤して固めた作業手順が、そのセッションの中にしか残らないという壁です。翌週、別のメンバーが同じ課題に取り組むとき、エージェントはまたゼロから同じ質問を繰り返します。
この問題は「チャット履歴を保存する」だけでは解決しません。履歴が残っていても、次にエージェントへ渡すべきなのは会話の全文ではなく、そこから抽出された事実・手順・制約だからです。かといって社内ドキュメントを RAG に載せても、「どのバージョンが有効か」「誰がこの知識を使ってよいか」「どのエージェントに配るべきか」までは面倒を見てくれません。
TencentDB Agent Memory は、この隙間を埋めることを狙った OSS です。会話・ドキュメント・コードを 4 種類の「記憶資産」に変換し、チーム単位で所有者・バージョン・可視性を管理しながら、複数のエージェントに配布します。2026 年 8 月にリリースされた v2.0 系で「個人向けのメモリパイプライン」から「チームレベルのメモリハブ」へと位置づけを大きく変えました。
一方で、日本語での解説はほとんど流通していません。スター数は 24,699 に達しているにもかかわらず、日本語圏の AI エージェントメモリ比較記事では Mem0・Zep・Letta・cognee が定番で、本リポジトリは比較対象にすら入っていないのが現状です。導入を検討するにも、README と INSTALL.md を自力で読み解くしかありません。
本記事では、公開されている README・INSTALL.md・CHANGELOG・GitHub API の取得値をもとに、TencentDB Agent Memory が何を解こうとしているのか、4 種の記憶資産と権限モデルはどう設計されているのか、Mem0 や OpenViking などの類似 OSS と何が違うのか、そして導入判断の前に確認しておくべき制約は何かを整理します。なお本記事はドキュメントベースの調査であり、実行環境での動作確認は行っていません。記述はすべて公式ドキュメントおよび GitHub API の取得値に基づきます。
- TencentDB Agent Memoryとは｜AIエージェントの記憶をチームで共有するOSS
- TencentDB Agent Memoryが解く課題｜個人の記憶がチームに残らない
- 4種の記憶資産（Chat Memory・Skill・LLM-Wiki・CodeGraph）の役割
- Chat MemoryのL0〜L3階層と検索の仕組み
- Memory Hubによる共有と権限統制の設計
- TencentDB Agent Memoryを既存エージェントに接続する構成
- 類似OSSとの違い｜Mem0・OpenViking・Supermemory・cogneeとの比較
- 導入を判断するチェックポイント
- まとめ｜向いているケースと見送るべきケース
- 関連情報
TencentDB Agent Memoryとは｜AIエージェントの記憶をチームで共有するOSS
TencentDB Agent Memory は、Tencent Cloud が公開している AI エージェント向けの「チームレベル メモリハブ」です。リポジトリの説明文では、会話・ドキュメント・コードを Chat Memory / Skill / LLM-Wiki / Code-Graph という 4 つの再利用可能な記憶資産に変換し、それらを統制（governed）・共有（shared）・装備（equipped）した状態で複数のエージェントやフレームワークにまたがって使えるようにする、と自己定義されています。
リポジトリの基本情報とメンテナンス状況
まず、判断材料になる基本情報を整理します。以下は GitHub API から取得した 2026 年 8 月 27 日時点の値です。
項目 | 値 |
|---|---|
リポジトリ | |
スター数 | 24,699 |
フォーク数 | 2,269 |
主要言語 | TypeScript |
ライセンス（API 判定） | NOASSERTION（GitHub 上の表示は「Other」） |
最終 push | 2026-08-26 |
公開状態 | public |
アーカイブ / フォーク | いずれも false（アーカイブされておらず、他リポジトリのフォークでもない本家） |
リポジトリの作成は 2026 年 4 月 7 日で、そこから約 4 か月半のあいだに v0.1.4 から v2.0.1 まで到達しています。リリース一覧を追うと、v0.x 系が 4〜5 月に断続的に刻まれ、6 月に v1.0.0、8 月 3 日に v2.0.0、8 月 25 日に v2.0.1 が公開されています。開発は明確に活発です。ただし、これは裏を返せば仕様が短期間で動きやすいということでもあり、この点はのちほど導入判断のところで改めて扱います。
アーカイブ済みでもフォークでもない現役の本家リポジトリであること、最終 push が調査時点の前日であることは、メンテナンス状況を見るうえでの前向きな材料といえます。
「チームレベルのメモリハブ」という自己定義
README は "Agents remember. Humans innovate." というキャッチコピーから始まり、出発点の問いを "How do you reduce repetitive work when using Agents?"（エージェントを使ううえで、繰り返し作業をどう減らすか）と置いています。
注目したいのは、記憶の定義を「会話を覚えること」よりかなり広く取っている点です。README は次のように書いています。
Any information that helps the next Agent avoid reinventing the wheel should be saved, organized, and reused.
「次のエージェントが車輪の再発明を避けるのに役立つ情報はすべて、保存し、整理し、再利用すべきだ」という立場です。この定義があるため、対象は会話ログにとどまらず、ドキュメントやコードベースまで含まれることになります。
ライセンス表記のねじれを先に確認しておく
社内で OSS を採用する際、最初に止まりやすいのがライセンスです。ここには注意すべきねじれがあります。
GitHub API が返すライセンス識別子は NOASSERTION で、GitHub のリポジトリページ上の表示も「Other」になっています。一方、LICENSE ファイル の本文は次のようになっており、実体は MIT の条文です。
Tencent is pleased to support the open source community by making TencentDB Agent Memory available.
Copyright (C) 2026 Tencent. All rights reserved.
TencentDB Agent Memory is licensed under the MIT.
Terms of the MIT:
--------------------------------------------------------------------
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software ...
出典: LICENSE
README にも License: MIT バッジがあり、末尾には [MIT](./LICENSE) © TencentDB Agent Memory Team と記載されています。冒頭に Tencent 独自の前文が挿入されているために GitHub の自動判定が MIT にマッチしていない、というのが素直な読み方ですが、これはあくまで推定であり、公式のアナウンスは確認できていません。
実務上の含意はシンプルです。GitHub のバッジ表示だけを根拠に「ライセンス不明」と判断しても、「MIT」と判断しても、どちらも一次情報の確認を飛ばしていることになります。社内の OSS 利用審査に出すときは、LICENSE ファイルの本文そのものを添付して判断を仰ぐのが確実です。
v0.x の単体メモリパイプラインから v2.0 のチーム基盤へ
このリポジトリを検索すると、時期によって説明の内容がかなり違う記事に当たります。これは製品の位置づけそのものが途中で変わったためです。
2026 年 5 月時点の紹介記事では、本リポジトリは「AI エージェント向けの 4 階層ローカルメモリパイプライン」として扱われていました。ツールログを記号的に圧縮する短期記憶と、L0 から L3 までの長期記憶ピラミッドを組み合わせたローカル志向の仕組み、という説明です（出典: MarkTechPost, 2026-05-23）。
対して 2026 年 8 月の記事では、v2.0 を「AI コーディングエージェント向けのチームレベル メモリハブ」として紹介しています。4 種の記憶資産がバージョン管理・権限管理され、特定のエージェントに装備される点が中心に据えられました（出典: MarkTechPost, 2026-08-07）。
つまり、個人のローカルメモリ層として評価するのか、チームのナレッジ統制基盤として評価するのかで、見るべき論点が変わります。本記事は後者、v2.0 系を前提に整理します。
TencentDB Agent Memoryが解く課題｜個人の記憶がチームに残らない
公式が示す「繰り返し作業の削減」というループ
README が提示している価値のループは次の形です。
Existing information → Reusable memory assets → Fewer turns → Less rework → More stable results and higher efficiency
出典: TencentCloud/TencentDB-Agent-Memory README
既存情報を再利用可能な記憶資産に変える。その結果、エージェントとのやり取りのターン数が減り、手戻りが減り、出力が安定して効率が上がる、という因果です。
この「記憶資産」という言い方が本リポジトリの中心概念です。ログでもインデックスでもなく、所有者とバージョンと可視性を持つ「資産」として扱う。Memory Hub はこの資産のライフサイクルを閉じる役割を担い、README では 3 つの柱が挙げられています。会話やタスクから Chat Memory / Skill を、ドキュメントやコードから Wiki / CodeGraph を自動抽出すること。記憶資産をエージェントフレームワークから疎結合に保ち持ち運び可能にすること。そして既存のドキュメント・コードベース・過去セッションを取り込めるコールドスタート対応です。
チャット履歴・標準RAGとの比較表の読み方
README には、チャット履歴・標準 RAG との対比表が置かれています。要点を整理すると次のようになります。
観点 | Chat History | Standard RAG | TencentDB Agent Memory |
|---|---|---|---|
セッション横断のユーザー理解 | △ | △ | Chat Memory で対応 |
蒸留された実行可能な経験 | — | — | Skill で対応 |
ドキュメントの構造・関係 | — | △（チャンク検索） | Wiki + リンクグラフで対応 |
コードの呼び出し関係・影響範囲 | — | △（テキスト一致） | CodeGraph で対応 |
所有者 / バージョン / ステータス | — | — | 対応 |
チーム共有・エージェントへの装備 | — | — | 対応 |
Private / Team / ACL | — | △ | 対応 |
出典: TencentCloud/TencentDB-Agent-Memory README
この表を README 自身が一文に要約しているのが、次の主張です。
RAG answers "what can be found?" Team Memory also answers "who can use it, which version is valid, and which Agent should receive it."
RAG は「何が見つかるか」に答える。チームメモリはそれに加えて「誰が使ってよいか」「どのバージョンが有効か」「どのエージェントに渡すべきか」にも答える、という整理です。
ここが判断の分岐点になります。手元の課題が「社内ドキュメントをエージェントに読ませたい」だけであれば、既存の RAG 構成で足りている可能性が高く、本リポジトリを導入する動機は弱くなります。逆に「知識の所有者と有効バージョンが曖昧」「個人のノウハウがチームに回らない」「誰にどこまで見せるかを制御したい」といった課題が前面に出ているなら、比較検討する価値があります。
4種の記憶資産（Chat Memory・Skill・LLM-Wiki・CodeGraph）の役割
TencentDB Agent Memory を理解するうえで中核になるのが、4 種類の記憶資産です。すべてを使う必要はなく、自チームに必要なものがこの中にあるかどうかが採用判断の実質的な基準になります。
Chat Memory｜選好・事実・決定・履歴を保持する
Chat Memory は、ユーザーの選好（preferences）、事実（facts）、決定事項（decisions）、やり取りの履歴（interaction history）を保持します。エージェントを作成すると自動的に専用のメモリが付与される設計です。
内部では、生の会話をそのまま保持するのではなく、L0 Conversation から L1 Atom、L2 Scenario、L3 Persona へと段階的に蒸留していきます。この階層構造は次の章で詳しく扱います。
Skill｜再利用可能な手順をバージョン付きで蓄積する
Skill は、会話やツール呼び出しから再利用可能な手順を抽出・管理し、指定したエージェントのコンテキストへ投入する仕組みです。
README が強調しているのは、Skill が単なるプロンプト断片ではないという点です。バージョン（version）、参照リソースファイル（resource files）、発火条件の境界（trigger boundaries）、実行ステップ（execution steps）、検証ルール（validation rules）といった属性を持ちます。要するに、プロンプトのメモではなく、レビューと更新の対象になる成果物として扱う設計です。
運用面では、個人が作成した Skill はデフォルトで private であり、レビューを経てからチーム共有・他エージェントへの割り当てに進む流れが想定されています。個人の試行錯誤をそのままチームの標準にしない、というワークフロー上の配慮が入っています。
LLM-Wiki｜ドキュメントをリンクグラフ付き構造化ページに変換する
LLM-Wiki は、製品ドキュメント・設計書・運用ランブックといった既存資料を、リンクグラフを備えた構造化ページに変換します。チャンク分割して埋め込むだけの RAG との差は、ページ間の関係が保たれる点にあります。
なお README の謝辞では、この Wiki レイヤの設計が Andrej Karpathy 氏の 「LLM Wiki」構想の gist から直接影響を受けたと明記されています。着想元が公開されているため、設計思想を先に読んでおくと理解が早くなります。
CodeGraph｜シンボル・呼び出し関係・影響経路をインデックスする
CodeGraph は、コードのシンボル・ファイル・呼び出し関係・影響経路をインデックスします。これによりエージェントは、コードを書き換える前に呼び出し元と呼び出し先を確認し、影響範囲を分析できます。
README はこの違いを次のように表現しています。
Wiki keeps Agents from reading every file list before getting to work. CodeGraph doesn't just tell them "the code is here" — it tells them "changing this might affect those."
「コードはここにある」ではなく「ここを変えるとあれに影響するかもしれない」を伝える、という差分です。既存のコード検索やテキスト一致ベースの参照との違いはこの一点に集約されます。
なお CodeGraph の資産モジュールは、謝辞に記載のとおり colbymchenry/codegraph のコードを利用しています。同様に Skill の資産管理は Nous Research の Hermes Agent の Skill 関連コードの一部を利用して最適化を加えたものとされています。完全な自前実装ではない点は、依存関係を洗う際に押さえておく価値があります。
4資産が「Memory Assets」として統一登録される意味
この 4 つは別々のサブシステムとして並んでいるのではなく、すべて Memory Assets として統一的に登録されます。だからこそ、後述する可視性・所有者・バージョンといった管理属性を、会話由来の記憶にもコード由来のインデックスにも同じ枠組みで適用できます。
「4 つの機能がある」ではなく「4 つの入力源を同じ資産モデルに載せた」と捉えるほうが、このリポジトリの設計意図に近いといえます。
Chat MemoryのL0〜L3階層と検索の仕組み
README の Technical Implementation 節では、解こうとしている問題を 3 つに整理しています。何を保存する価値があるか（what's worth keeping）、誰が使ってよいか（who can use it）、そして次回により少ない検索で正しいものを引くにはどうするか（how to retrieve less while retrieving the right things next time）です。
L0からL3への段階蒸留
記憶は 4 階層で保持されます。
Layer | 保持内容 | 主用途 |
|---|---|---|
L0 Conversation | 完全なコンテキスト付きの生会話 | 正確な文言・タイムスタンプ・出典の確認 |
L1 Atom | 会話から抽出した事実・選好・制約・イベント | 実行可能な情報の精密な想起 |
L2 Scenario | プロジェクト・シナリオ単位で組織された知識ブロック | 作業コンテキストの高速復元 |
L3 Core / Persona | 長期プロファイル・安定パターン・高次の認知 | ユーザーやチームの文脈への高速適応 |
出典: TencentCloud/TencentDB-Agent-Memory README
上の層に行くほど圧縮され、下の層に行くほど原文に近くなる構造です。エージェントが日常的に参照するのは主に L2 と L3 で、L0 は監査や出典確認のために残されている、と読めます。
検索の段階化とフォールバック
検索側もこの階層に対応した設計になっています。README の記述をまとめると、通常は L2 / L3 が素早いコンテキスト起動を担い、具体的な事実が必要になった段階で BM25 とベクトル検索を RRF（Reciprocal Rank Fusion）で統合し、L1 / L0 へフォールバックします。
キーワード検索と意味検索を併用してランク融合する構成自体は目新しいものではありませんが、それを「常に全層を引く」のではなく「上位層で足りなければ下位層に降りる」という段階制御に組み込んでいる点が特徴です。
コンテキスト圧迫を防ぐ3つの上限
エージェントにメモリを外付けするとき、実装者が最も気にするのは「記憶がコンテキストウィンドウを食い潰さないか」だと思います。README はこの点に明示的に触れており、検索結果は件数上限・文字数バジェット・タイムアウトの 3 つでさらに制限されると記載されています。
上限値そのものは README には書かれていないため、実運用でどの程度のトークンが system prompt に載るかは設定次第です。ただ、無制限に注入する設計ではないことがドキュメント上で明言されている点は、評価時の安心材料になります。
公表ベンチマーク（PersonaMem 48%→76%）の読み方
README の Benchmark 節には次の数値が掲載されています。
Benchmark | 無効時 | 有効時 | 相対改善 |
|---|---|---|---|
PersonaMem | 48% | 76% | +59% |
出典: TencentCloud/TencentDB-Agent-Memory README
PersonaMem は、長時間のやり取りのあとにエージェントがユーザー情報を正しく理解・適用できるかを測るベンチマークだと説明されています。
この数値の扱いには注意が必要です。第一に、開発元による自己申告値であり、第三者による再現報告は確認できていません。第二に、対象モデル・試行回数・評価条件が README に記載されていないため、他ツールとの横並び比較には使えません。第三に、対象は 1 ベンチマークのみです。「長期の対話でユーザー理解が改善する方向の設計になっている」という定性的な示唆として読み、意思決定の主根拠には置かないのが妥当です。
Memory Hubによる共有と権限統制の設計
ここが、多くの類似 OSS が扱っていない領域であり、本リポジトリを検討する最大の理由になり得る部分です。チームで記憶を共有するとき、真っ先に問題になるのは「個人の会話までチーム全員に見えてしまわないか」だからです。
private / team / restricted / agent の4可視性
Memory Hub は資産ごとに 4 種類の可視性を持ちます。
Visibility | セマンティクス |
|---|---|
| Owner のみが読める（チーム管理者であっても読めない） |
| チームメンバーが読める。Owner / Admin が管理する |
| User / Role / Agent の ACL による精密なアクセス制御 |
| 同一チーム内の特定エージェントへの割り当て用 |
出典: TencentCloud/TencentDB-Agent-Memory README
実務上いちばん重要なのは private の定義です。README は「チーム管理者でも読めない」と明記しています。管理者権限で全記憶を閲覧できてしまう設計だと、メンバーは率直な作業ログを残さなくなり、記憶資産の質が落ちます。その意味で、この線引きは運用の成否に直結します。
System Admin・Team Admin・Member と Owner の関係
ロールは 2 層構造です。グローバルな System Admin がユーザーとチームの管理（チーム作成、メンバー追加など）を担い、加えて Wiki / CodeGraph / Skill などの資産管理機能も利用できます。チームレベルでは Admin と Member が置かれ、チーム内での資産コラボレーションとアクセス制御を担当します。
これとは別に、資産の所有は Owner として追跡され、Owner は自分の資産に対する管理権限を自動的に持ちます。つまり「組織の管理者」と「その資産を作った人」が別の軸で管理されており、前者が後者の private 資産を勝手に開けられない構造になっています。
Agentロードアウト｜Fixed Binding + ACL で配布先を決める
4 種の資産はすべて Memory Assets として統一登録され、Memory Hub は Fixed Binding と ACL の組み合わせで、どのエージェントがどの資産を使えるかを決定します。
処理の順序も README に記載があります。まず Team / User / Agent / visibility によって権限スコープを絞り込み、そのうえで現在のクエリに基づいて検索する、という流れです。検索してから権限でフィルタするのではなく、権限で絞ってから検索する順序になっており、権限外の資産が検索結果の枠を消費しない設計です。
エージェント側は /v3/tools/list で利用可能な機能を発見し、/v3/tools/call で該当ページ・ソースコード・影響経路を読み取ります。
「共有は明示的な操作であり、既定の漏洩ではない」
この章の設計思想を README は一文で言い切っています。
New Chat Memory and Skills are private by default. Sharing is an explicit action, not a default leak.
新しく作られた Chat Memory と Skill はデフォルトで private であり、共有は明示的な操作であって既定の漏洩ではない、という宣言です。チーム導入の合意形成をする際、この 1 行はそのまま説明材料として使えます。
裏返せば、何もしなければチームには何も共有されないということでもあります。記憶資産をチームの財産にするには、レビューして共有する運用フローを人間側で設計する必要があります。ツールを入れれば自動的にナレッジが溜まる、という期待で導入すると噛み合いません。
TencentDB Agent Memoryを既存エージェントに接続する構成
導入検証にどれくらいの手間がかかるかを見積もるために、公式の INSTALL.md をもとに構成を整理します。手順の全列挙はここでは行いません。詳細な手順は公式ドキュメントを参照してください。
memory-core・memory-hub・proxy の3サービス
推奨構成はフルスタックの 3 点セットで、memory-core / memory-hub / proxy を一括起動します。Memory Core がすでに稼働している場合は Memory Hub のみの軽量デプロイも選択肢として案内されています。
デフォルトポートは次のとおりです。
Service | Port | 役割 |
|---|---|---|
Memory Core | 8420 | メモリの読み書き、認証、Skill / RAG のデータプレーン |
Panel UI | 8125 | チームメモリのコントロールパネル |
Knowledge | 8424 | Wiki / CodeGraph サービス |
Proxy | 8096 | LLM リクエストのプロキシ（Anthropic / OpenAI のデュアルプロトコル） |
出典: INSTALL.md
前提バージョンとして README のバッジには Node >= 22.16、OpenClaw >= 2026.3.13 が示されています。npm には @tencentdb-agent-memory/memory-tencentdb が公開されています。
base URLの差し替えだけで接続するProxy方式
接続方式は、この OSS のなかでも判断に効く特徴です。README は次のように述べています。
One Proxy, unchanged protocol, zero-code integration — point the Agent's base URL to the Proxy and it's done. No plugin, hook, or MCP server is required.
プラグインもフックも MCP サーバも不要で、エージェントの base URL を Proxy に向けるだけ、という主張です。既存のコーディングエージェントの設定を大きく変えずに済むため、検証の着手コストは低く見積もれます。一方で、すべての LLM リクエストが Proxy を経由することになるため、通信経路とレイテンシの評価は別途必要になります。
起動手順は README に次の形で記載されています。
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env # Fill in two sets of LLM parameters (memory group + proxy group)
./start-all.sh # Launch everything with one command; when finished, it prints a one-liner you can paste directly into Claude
出典: TencentCloud/TencentDB-Agent-Memory README
INSTALL.md 側は同じ手順をより短く示しています。
# 1) Fetch the scripts
git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
# 2) One-shot boot (interactive)
./start-all.sh
出典: INSTALL.md
なお、README 側の clone URL は Tencent/ という旧 organization 表記のまま残っており、INSTALL.md 側は TencentCloud/ になっています。旧表記でも GitHub 側でリダイレクトされて同一リポジトリに解決されますが、正規の表記は TencentCloud/TencentDB-Agent-Memory です。
起動時に求められる2系統のLLM設定
start-all.sh は対話形式で進みます。INSTALL.md によれば、.env が無ければ .env.example からコピーしたうえで、2 つの LLM グループの設定を求めます。
ひとつは memory グループ（MEMORY_LLM_BASE_URL / MEMORY_LLM_API_KEY / MEMORY_LLM_MODEL）で、memory-core と memory-hub が内部処理に利用します。もうひとつは proxy グループ（PROXY_UPSTREAM_URL / PROXY_UPSTREAM_API_KEY / PROXY_UPSTREAM_MODEL）で、Proxy が転送する先です。memory グループの設定を再利用することもできます。
重要なのは、各グループの設定直後に LLM への疎通を即時プローブし、失敗した場合は通るまで再入力を促す仕様になっている点です。検証を始める前に、利用可能な LLM エンドポイントと API キーを手元に用意しておく必要があります。起動せず検証だけを行う ./verify.sh（--skip-llm で LLM プローブをスキップ）も用意されています。
初回起動時は init-admin が admin ユーザーを作成し、ランダム 32 文字の user_key を ./.admin-key に永続化します。そのうえで、次のような貼り付け用のブロックが出力されます。
export ANTHROPIC_BASE_URL=http://127.0.0.1:8096/claude-code/default
export ANTHROPIC_AUTH_TOKEN='sk-mem-<random 32 chars>'
claude --model <whatever PROXY_UPSTREAM_MODEL is set to>
出典: INSTALL.md
INSTALL.md は運用上の注意として、admin キーでコーディングエージェントを駆動せず、ops 用と business 用のユーザーを分けることを推奨しています。admin が作成した business ユーザーの default_user_key は作成レスポンスでしか全文表示されないため、その場で保存が必要である点も明記されています。
セッション初回のTeam→Agent→Task選択
メモリは team / agent / task の三つ組に紐づきます。最低でも Team を 1 つ、Agent を 1 つ作る必要があり、Task は任意ですが、省略すると L2 / L3 が Task 次元を失うと説明されています。
新規セッションを開始すると、Proxy が Claude Code ネイティブの AskUserQuestion ツールを使って Team → Agent → Task の 3 連続選択を提示します。以降のターンでは、該当エージェントの L2 / L3 メモリ・スキル・知識が system prompt に自動注入されます。生の対話である L0 は memory-core の SQLite に取り込まれ、バックグラウンドワーカーが閾値に達した時点で L1 → L2 → L3 の抽出を行います。
つまり、日常の利用フローで開発者が意識するのはセッション冒頭の 3 択だけで、蒸留は非同期に進む設計です。
対応クライアントの広がり
対応するエージェントクライアントは README / INSTALL.md 上で、Claude Code、Codex、CodeBuddy、WorkBuddy、DeepSeek Harness、Hermes、OpenClaw などが挙げられており、そのほかは汎用の統合ガイドで対応する形になっています。
CHANGELOG によれば、v2.0.1 では OpenCode、DeepSeek Harness、Codex CLI、WorkBuddy への対応が追加されています。同バージョンでは、会話の途中でチーム / エージェント / タスクのバインドを切り替えられるようになった点、セッションバインドが再起動後も永続化される点、チームやユーザーの作成時にデフォルト Agent が自動生成されるようになった点なども挙げられています。v2.0.1 の主眼は、接続先クライアントの拡充とコールドスタートの簡素化にあると読み取れます。
コールドスタート｜既存資産の取り込み
導入直後は記憶がゼロのため、そのままでは価値が出ません。README はコールドスタート対応を柱のひとつに挙げており、既存のドキュメント・コードベース・過去セッションをインポートできると説明しています。v2.0.1 では、IDE 上の既存 Agent から資産をワンクリックで取り込む機能も追加されています。
検証計画を立てる際は、この取り込みにかかる時間を見込んでおく必要があります。Wiki と CodeGraph のビルドは非同期であり、この点はのちほど制約として改めて触れます。
類似OSSとの違い｜Mem0・OpenViking・Supermemory・cogneeとの比較
AI エージェントのメモリ基盤は選択肢が多い領域です。すでに何かを使っている場合、乗り換える理由があるのか、併用できるのかが判断の焦点になります。
主要OSS 6件の比較
以下は 2026 年 8 月 27 日時点の GitHub API 取得値に基づく比較です。
リポジトリ | スター | 言語 | ライセンス | 中心となる抽象 | TencentDB Agent Memory との主な差分 |
|---|---|---|---|---|---|
TencentCloud/TencentDB-Agent-Memory | 24,699 | TypeScript | NOASSERTION（本文は MIT 条文） | チーム単位の記憶資産ハブ | 記憶を資産として Owner・バージョン・可視性・エージェント割当まで管理する統制層を持つ |
mem0ai/mem0 | 64,131 | Python | Apache-2.0 | 汎用メモリレイヤー（SDK / API） | アプリに組み込む軽量なメモリ層。4 可視性やロール分離といったチーム統制、Skill / CodeGraph という資産型は持たない |
volcengine/OpenViking | 33,602 | Python | AGPL-3.0 | コンテキストデータベース（Memory / Knowledge RAG / Skills を統合） | 統合範囲は近いが、軸足がデータ表現と検索軌跡にある。ライセンスが AGPL-3.0 で自社プロダクト組み込み時の検討事項が異なる |
getzep/graphiti | 30,324 | Python | Apache-2.0 | リアルタイムのナレッジグラフ構築 | グラフ構築ライブラリとしての性格が強く、権限統制やエージェントへの配布は範囲外 |
topoteretes/cognee | 30,281 | Python | Apache-2.0 | ナレッジグラフによる永続メモリ | 知識のグラフ表現が中心。Skill（実行可能な手順の蒸留・バージョン管理・装備）という概念を持たない |
supermemoryai/supermemory | 29,089 | TypeScript | MIT | メモリ / コンテキストエンジン + アプリ | 個人・アプリ単位のメモリ API が主眼。コードの呼び出し関係やドキュメントのリンクグラフを一級の資産として扱う設計ではない |
letta-ai/letta | 24,455 | — | Apache-2.0 | ステートフルエージェントのプラットフォーム | エージェント自体をランタイム上で動かす方式。既存のコーディングエージェントをそのまま使いながら記憶だけ外付けする用途とは前提が異なる |
OpenViking と Supermemory については当ブログでも個別に扱っています。統合範囲やアーキテクチャを詳しく比較したい場合は、OpenVikingでAIエージェントの記憶と文脈を一元管理する方法とAIエージェントのメモリ基盤にSupermemoryが選ばれる理由も併せて参照してください。
「メモリ層」ではなく「記憶資産の統制層」であることの意味
比較表から浮かび上がる差分は、大きく 4 つに整理できます。
第一に、統制の有無です。Mem0 や cognee、Supermemory が主に「検索できる記憶」を提供するのに対し、TencentDB Agent Memory は「誰が使えるか」「どのバージョンが有効か」「どのエージェントに配るか」までを Memory Hub で扱います。
第二に、資産型の広さです。会話由来（Chat Memory / Skill）だけでなく、ドキュメント由来（LLM-Wiki）とコード由来（CodeGraph）を同じ資産モデルに載せています。
第三に、接続方式です。SDK 組み込みでも MCP サーバでもなく、Proxy への base URL 差し替えという経路を採っています。アプリケーションコードを触らずに済む一方で、LLM トラフィックが 1 か所を通る構成になります。
第四に、ライセンス条件です。OpenViking の AGPL-3.0 に対し、本リポジトリの LICENSE 本文は MIT 条文です（ただし GitHub 上の自動判定は Other）。自社プロダクトへの組み込みを想定する場合、この差は無視できません。
用途別の向き・不向き
用途に照らして整理すると次のようになります。
個人で 1 台の開発マシン上のエージェントに永続メモリを足したいだけであれば、本リポジトリは過剰です。3 サービス構成と 2 系統の LLM 設定、Team / Agent / Task の初期設計といった前提が、得られる価値に対して重くなります。この用途では、より軽量な選択肢のほうが噛み合います。判断軸を整理したい場合はAIエージェントの永続メモリにcogneeが選ばれる理由やAIエージェントの永続メモリ基盤にagentmemoryも参考になります。
複数人のチームで、個人の知見をレビューを通じて共有資産に昇格させたい、かつ誰にどこまで見せるかを制御したいという要件があるなら、本リポジトリの設計は正面から噛み合います。この領域を明示的に扱う OSS はまだ多くありません。
コードベースとの連携を重視する場合も候補になります。CodeGraph が呼び出し関係と影響経路を持つため、変更の波及を意識した支援を期待できます。ただし後述のとおり、現時点ではリポジトリの取得方式に制約があります。
ライセンス条件が厳しい組織では、LICENSE 本文と GitHub 表示の食い違いをどう扱うかを先に決める必要があります。AGPL を避けたいという理由で OpenViking を候補から外している組織であれば、本リポジトリの MIT 条文は選択の後押しになり得ますが、「Other」表記のままで審査を通せるかは組織のルール次第です。
導入を判断するチェックポイント
ここまでの整理を踏まえ、検証や社内提案に進む前に確認しておきたい点をまとめます。
ライセンス表記のねじれをどう扱うか
冒頭で触れたとおり、GitHub API 上は NOASSERTION、GitHub 表示は「Other」、LICENSE 本文は MIT 条文です。多くの組織の OSS 利用審査は、ライセンス自動検出ツールの出力を入口にします。その場合「ライセンス不明」として弾かれる可能性があります。
対処としては、審査に出す前に LICENSE 本文を確認し、MIT 条文である旨と Tencent 独自の前文が付されている旨を申請時に添えるのが現実的です。ここを飛ばすと、審査の差し戻しで時間を失います。
公式が明記している3つの制約
README の Notes には、開発元自身が現時点の制約として次の 3 点を挙げています。
ひとつ目は、Wiki と CodeGraph が非同期ビルドであることです。ready になるまで処理時間が必要であり、投入した直後にすべてが検索対象になるわけではありません。大規模なドキュメント群やコードベースを取り込む場合、この待ち時間を検証計画に織り込む必要があります。
ふたつ目は、CodeGraph が現状 public な HTTPS リポジトリを優先しており、プライベートリポジトリと SSH クレデンシャルへの対応は改善中とされている点です。社内のプライベートリポジトリを CodeGraph に載せることが導入目的の中心にある場合、ここは検証の最優先項目になります。
みっつ目は、Hub が手動での資産バインドをサポートしており、完全自動のメモリルーティングは反復中である点です。「エージェントに適切な記憶が自動で配られる」状態を期待していると、人間が資産とエージェントを紐づける運用が残ることになります。
これらは開発元が自ら公開している情報です。誇張のない現状認識として、社内提案の資料にもそのまま載せられます。
リポジトリ運用面で確認しておきたいシグナル
ドキュメントの内容とは別に、リポジトリの運用状況からも判断材料が得られます。
デフォルトブランチが main ではなく feat/server_team になっています（main と feat/server も存在します）。ドキュメントやファイルを参照するときは、どのブランチの内容を見ているかを意識する必要があります。本記事で示した公式リンクもデフォルトブランチのパスです。
README の記述とリリース状況にも食い違いがあります。README の Roadmap 節は「現行リリースは v2.0.0。次は v2.0.1 で、ゼロコンフィグのコールドスタート、Wiki 生成の高速化、ユーザー / チームのカスタムプロンプト、Skill エクスポート、Codex（IDE Plan mode）対応を予定」と書かれていますが、Releases 一覧では v2.0.1 が 2026 年 8 月 25 日にすでに公開されています。どちらが正しいかを断定する材料はありませんが、ドキュメントの更新がリリースに追いついていない状態であることは事実として押さえておく価値があります。今後の予定は ROADMAP.md にも記載があります。
open issues は 718 件です。スター 24,699 という注目度を考えれば不自然な数字ではありませんが、issue の内容と対応速度は着手前に一度目を通しておくとよい情報です。
そして冒頭でも触れたとおり、リポジトリ作成から約 4 か月半で v0.1 から v2.0.1 まで到達しています。開発が活発である一方、v0.x と v2.x では位置づけそのものが変わっているとおり、仕様が動きやすい段階にあります。本番の業務フローに深く組み込む前に、バージョン更新への追随コストを見積もっておくのが安全です。
非公式フォークとの混同を避ける
検索すると、baodq97/tencentdb-agent-memory（Claude Code プラグイン版）や VKirill/TencentDB-Memory-Claude-Code（英語ローカライズされた coder 向けフォーク）といった派生リポジトリが混ざって出てきます。いずれも本家とは別物です。
正規のリポジトリは TencentCloud/TencentDB-Agent-Memory です。前述のとおり README 内の clone URL には旧 organization 表記の Tencent/ が残っているため、この表記を見て「別プロジェクトでは」と迷う必要はありません。
検証を始めるならどこからか
公式手順を要約すると、検証の順序はおおむね次のようになります。まず利用可能な LLM エンドポイントと API キーを 2 系統分（memory グループ用と proxy グループ用、同一でも可）用意します。次に ./verify.sh で環境の前提を確認し、./start-all.sh でフルスタックを起動します。パネル（既定では 8125 番ポート）に admin の user_key でログインし、business ユーザーを作成して default_user_key を保存します。続いて Team と Agent を最低 1 つずつ作成し、コーディングエージェントの base URL を Proxy に向けます。
最初の検証としては、CodeGraph に public リポジトリを 1 本だけ登録して ready になるまでの時間を測ること、そして Chat Memory が L1 以降に蒸留されるまでの挙動をパネル上で確認することが、制約の実態を掴むうえで効率的だと考えられます。詳細な手順は公式の INSTALL.md を参照してください。
まとめ｜向いているケースと見送るべきケース
TencentDB Agent Memory は、AI エージェントの記憶を「検索できるデータ」ではなく「所有者とバージョンと可視性を持つ資産」として扱う設計の OSS です。この一点が、他のメモリ基盤との最大の違いになります。
採用候補として検証に進む価値が高いのは、次のようなケースです。
- 複数人のチームでコーディングエージェントを使っており、個人の知見がチームに回っていない実感がある
- 誰にどこまで記憶を見せるかを制御したい（private をチーム管理者からも守りたい要件がある）
- 会話由来の知見だけでなく、社内ドキュメントとコードベースも同じ枠組みで扱いたい
- 既存のエージェント設定を大きく変えずに評価を始めたい（base URL 差し替えで済ませたい）
一方、現時点では見送りが妥当なケースもあります。
- 個人利用で、単一マシン上のエージェントに永続メモリを足したいだけである
- 社内のプライベートリポジトリを CodeGraph に載せることが導入目的の中心にある（現状は public HTTPS リポジトリが優先で、SSH 対応は改善中）
- 記憶がエージェントへ完全自動でルーティングされることを前提にしている（資産バインドは手動が基本）
- OSS 利用審査でライセンス自動判定の結果をそのまま使う運用になっており、「Other」表記のまま通す余地がない
- 仕様変更への追随コストを許容できない（作成から約 4 か月半で v0.1 から v2.0.1 まで到達しており、位置づけ自体が v2.0 で変わっている）
判断に迷う場合は、ツール選定の前に「自チームのどの記憶が失われているのか」を切り分けるところから始めるのが近道です。業務活用の観点から判断軸を整理したい場合は、AIエージェントのメモリ機能とは｜業務活用に必要か見極める4つの判断軸も参考になります。
本記事の記述は、公式 README・INSTALL.md・CHANGELOG・LICENSE および GitHub API の取得値（2026 年 8 月 27 日時点）に基づくドキュメントベースの整理です。数値や仕様は更新される可能性があるため、導入判断の際は必ず公式リポジトリの最新情報をご確認ください。
関連情報
AI エージェントの社内活用やナレッジ基盤の設計についてご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。
