AIエージェントに「昨日話した内容」や「前任者が作ったSkill」を覚えさせたい場面は増えているが、その多くは1人のユーザーか1つのエージェントに閉じた記憶にとどまる。TencentDB Agent MemoryはTencent Cloudが公開するOSSで、Chat Memory・Skill・Wiki・Code Graphという4種類の「記憶資産」をチーム単位で共有し、権限まで統制できる点が特徴だ。本記事ではDocker Composeで実際に起動して挙動を確認したうえで、既存の個人向け記憶OSSとの立ち位置の違いを整理する。

TencentDB Agent Memoryの技術構成図。Conversation/Workflow/Documents/CodebaseがChat Memory・Skills・Wiki・CodeGraphというMemory Assetsに変換され、Memory Hubで権限に応じてAgentへ組み立てられる
会話・ワークフロー・ドキュメント・コードベースが4種の記憶資産へ変換され、Memory Hubを介してAgentへ「装備」される（出典: TencentCloud/TencentDB-Agent-Memory 公式README）
30秒でわかる TencentDB Agent Memory（2026年8月時点）
  • ・正体：Tencent Cloud公式のチーム向けAIエージェント記憶基盤OSS。★19,856／MIT／contributor実測4名
  • ・何ができる：Chat Memory・Skill・Wiki・Code Graphの4資産をMemory Hub上で一元管理し、メンバー・Agent単位で共有範囲と権限を設定できる
  • ・何を解決する：「個人の記憶」止まりだったAIエージェントの経験を、チームで持ち運び・引き継げる資産に変える
  • ・実測：./start-all.shから3コンテナ（memory-core／memory-hub／proxy）が約110秒でhealthyに到達（本日Docker実測）
  • ・注意：READMEは「Team Memory Beta」と明記。defaultブランチも`feat/server_team`という開発中の名称のままで、正式リリース前の位置づけ

AIエージェントのフレームワーク全体を横断的に比較したい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 もあわせて参照してほしい。

TencentDB Agent Memoryとは——チームで共有するAIエージェントの記憶基盤

TencentDB Agent Memoryは、GitHub org TencentCloud 配下で公開されているOSSで、2026年8月11日時点の実測でスター約19,856・フォーク約1,790。今週だけで約+7,555というGitHub Trending掲載によるバイラル的な急伸があった一方、リポジトリ自体は2026年4月7日作成で4か月の開発実績がある。

READMEの一文を借りれば、このプロジェクトの出発点は「AIエージェントを使うときの繰り返し作業をどう減らすか」という実務的な問いだ。プロジェクトの背景説明が済んでいるなら次のセッションで繰り返す必要はないし、一度読んだドキュメントを毎回別のエージェントが最初から読み直す必要もない。TencentDB Agent Memoryは、こうした「次のエージェントが車輪の再発明をしなくて済む情報」を記憶資産として保存・整理・再利用する仕組みを提供する。

読者の3つの問いへの答え
① 何ができる：会話・Skill・ドキュメント・コードベースを4種類の記憶資産に変換し、チームとAgent群で共有する ② 何を解決する：個人・単一エージェントに閉じていたAIエージェントの経験をチーム資産化する ③ 何を代替できる：単一ユーザー向けの記憶MCPサーバーや、都度ゼロから読み直すRAGの一部

開発体制の面では、Tencent Cloudという企業公式リポジトリでありながら、GitHub API実測のcontributor数は4名（anon込み）と少人数だ。star数の規模（約2万）に対して開発者数はかなり少なく、「見た目の人気＝開発体制の厚さ」ではない点は正直に書いておきたい。直近（2026年8月11日）にもpushがあり、開発自体は現役で進んでいる。

なお参照先URLには注意が必要だ。README内のgit clone例や一部外部ページはTencent/TencentDB-Agent-Memoryという別orgのURLを使っているが、これはGitHub側でTencentCloud/TencentDB-Agent-Memoryへ301リダイレクトされる旧URLで、実際にcurlで確認するとどちらも最終的に同じリポジトリへ到達する。本記事ではリダイレクト先である正規org表記TencentCloud/TencentDB-Agent-Memoryに統一している。

インストールと起動——Docker ComposeでTencentDB Agent Memoryを動かす

インストール手順はREADMEのQuickstartに沿ってDocker Composeで完結する。実際に本記事執筆時点のリポジトリをgit cloneし、Docker Compose環境で起動して検証した。

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
# MEMORY_LLM_* / PROXY_UPSTREAM_* に利用するLLMのAPIキー等を設定してから
./start-all.sh

.env.exampleを見ると分かる通り、起動にはMEMORY_LLM_BASE_URL / MEMORY_LLM_API_KEY / MEMORY_LLM_MODEL（記憶のembed/summarize用）と、PROXY_UPSTREAM_URL / PROXY_UPSTREAM_API_KEY / PROXY_UPSTREAM_MODEL（proxy転送先用）という2系統のLLM接続情報が必須項目としてrequire_varsでチェックされる。ここが未設定だとスクリプトはproxy起動前に停止する仕組みで、「軽く触ってみる」だけでも外部LLMの接続先を用意する必要がある点は事前に知っておきたい。

起動は「memory-core → memory-hub → proxy」の順に、それぞれのヘルスチェックを待ってから次へ進む設計だった。実測では以下の通り、3コンテナすべてがhealthyになるまで約110秒だった。

$ docker ps --filter "name=tdai" --format "table \t\t"
NAMES              STATUS                        PORTS
tdai-proxy         Up 9 seconds (healthy)        0.0.0.0:8096->8096/tcp
tdai-memory-hub    Up 46 seconds (healthy)       0.0.0.0:8125->8125/tcp, 0.0.0.0:8424->8424/tcp
tdai-memory-core   Up About a minute (healthy)   0.0.0.0:8420->8420/tcp

起動が終わるとPanel UI（localhost:8125）・Panel API・Knowledge API（localhost:8424）・Memory Core（localhost:8420）・Proxy（localhost:8096）の5エンドポイントが立ち上がる。実際にcurlで疎通確認したところ、Panel UIとKnowledge APIのSwagger UI（/docs）はいずれも200を返した。

$ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8125/
200
$ curl -sI http://localhost:8424/docs | head -1
HTTP/1.1 200 OK
TencentDB Agent Memoryのログイン画面。Welcome Backの文字とuser_key入力欄が表示されている
起動直後のログイン画面（自環境での実キャプチャ）。HTMLの`lang`属性は`zh-CN`だが、ログイン画面自体の表示文言は英語だった

ここは brief で懸念されていた「UIが中国語のままではないか」という点の検証結果でもある。結論としては画面ごとに言語が違う。ログイン画面（Welcome Back / user_keyの入力）は英語表示だったが、ログイン後のPanel UI本体は後述の通りメニュー・ラベルが中国語のままだった。

4つの記憶資産とL0-L3階層——Chat Memory・Skill・Wiki・Code Graphの仕組み

TencentDB Agent Memoryが管理する記憶資産は4種類。READMEでは「Chat Memory, Skills, Wiki, and CodeGraph are all registered uniformly as Memory Assets」と説明されており、いずれも同じ枠組み（Fixed Binding + ACL）でAgentへの割り当てが管理される。

4つの記憶資産タイプ：Chat Memory・Skill・Wiki・Code Graphの一覧図
4つの記憶資産タイプ（自作構成図。各資産の説明は公式READMEに基づく）

・Chat Memory：会話から抽出した好み・事実・意思決定・やり取りの履歴。Agent作成時に自動で個別の記憶が割り当てられる
・Skill：ワークフロー実行から蒸留された再利用可能な手順
・Wiki：ドキュメントから構築される、リンクグラフでドリルダウン可能なナレッジベース
・Code Graph：コードベースを解析した、ファイル・シンボル・呼び出し関係を含む構造グラフ

Chat Memoryは単なるログの羅列ではなく、L0〜L3の4階層に分けて非同期パイプラインで精製される。

flowchart LR A["会話
Raw Conversation"] --> B["L0 Conversation
生ログをフル保持"] B --> C["L1 Atom
事実・好み・制約を抽出"] C --> D["L2 Scenario
プロジェクト/シーン単位に整理"] D --> E["L3 Persona
安定したプロファイル・傾向"] E --> F["Agentが装備
Fixed Binding + ACL"]
L0 Raw LogからL3 Personaまでの記憶ピラミッド図。それぞれの階層の役割を説明
L0（生ログ）→L1（事実の抽出）→L2（シーン単位の整理）→L3（安定したペルソナ）という4階層モデル（出典: TencentCloud/TencentDB-Agent-Memory 公式README）
通常はL2/L3が素早いコンテキスト復元に使われ、具体的な事実が必要な時だけBM25＋ベクトル検索＋RRFでL1/L0へフォールバックする（README記載の設計）。件数・文字数・タイムアウトで上限を切り、記憶がコンテキストウィンドウを圧迫しないよう制御している。

チームでのガバナンス——Memory Hubの権限・共有範囲

TencentDB Agent Memoryが個人向け記憶OSSと最も異なるのは、この資産を「誰が見られるか」「どのAgentに配るか」をチーム単位で統制する層を持つ点だ。READMEは可視性を4段階で定義している。

可視性 意味
private Ownerのみ閲覧可（チーム管理者も不可）
team チームメンバーが閲覧可、Owner/Adminが管理
restricted User／Role／AgentのACLで精密に制御
agent 同一チーム内の特定Agentへピンポイントで装備

新規のChat MemoryやSkillはデフォルトでprivate扱いになり、共有は明示的な操作でのみ行われる設計だという。実際にDocker Composeで起動したPanel UIのChat_Memory画面（README掲載のスクリーンショット）でも、「団队资产（チーム資産）」「Agent 资产（Agent資産）」「我的资产分配（自分の資産割当）」という3つのタブでスコープを切り替えられる作りになっていた。

Memory HubのChat_Memory画面。左にL0-L3の階層カウント、右にコア記憶（Team Operating Doctrine）の内容が表示されている
Memory HubのChat_Memory画面（公式README掲載のスクリーンショット）。ナビゲーション（Wiki知识库／Code_Graph／Skill技能／Agents管理／成员管理／任务看板）は中国語表記のまま
注意：Panel UI本体は中国語表記が残る
ログイン画面の文言は英語だったが、ログイン後のメニュー・ラベル（Wiki知识库・Code_Graph・Skill技能・Agents管理・成员管理・任务看板など）は中国語のままだった。国際化がどこまで進んでいるかは今後の更新を確認する必要がある。

Memory Hub自体の役割は「閲覧板」ではなく「管理パネル」だとREADMEは位置づけている。用意されている5つの役割は次の通り。

Hubでの役割 やること
Team Up チームを作成し、メンバーとAgentを追加、共有範囲を定義する
Asset Library Chat Memory・Skill・Wiki・Code Graphを閲覧・検索・レビュー・管理する
Agent Loadout Agentごとに異なる記憶資産を紐付け、優先度・利用モードを調整する
Knowledge Workshop Wiki・Code Graphを構築し、処理状況とメタデータを監視する
Access Control private／team／ACLベースのアクセスを切り替え、必要に応じて共有を取り消す

Wiki・Code Graphは一括でコンテキストに注入されるわけではない。READMEによれば、AgentはまずKnowledge APIの/v3/tools/listで使えるツールを発見し、必要なタイミングだけ/v3/tools/callで該当ページやソースコード、影響範囲を読みに行くオンデマンド方式になっている。ドキュメントとコードも「記憶の一部」として扱いつつ、本当に必要になるまではコンテキストに入れない設計だ。

対応フレームワークは2026年8月時点のREADMEで OpenClaw・Hermes・Claude Code・CodeBuddy・SDK統合が明記されている。中でもOpenClawはバッジで対応バージョン（>=2026.3.13）まで明記されている最有力の連携先で、OpenClawのメモリ機能をこのMemory Hubへ委譲する形で使う想定になっている。Hermesとの連携については、当サイトで別途解説している Hermes Agent 使い方｜Telegram・Discord・Slack対応、LLM300+種切替 も参考になる。

このように、個々のAIエージェントの記憶を単体で強化するのではなく、チームでAIエージェントのメモリを共有する運用そのものを主眼に置いている点が、TencentDB Agent Memoryをチームメモリ・AI基盤として捉えるべき理由だ。

個人向け記憶OSSとの違い——mem0・cognee・agentmemoryとの立ち位置

AIエージェントに永続的な記憶を持たせるOSSは既にいくつも存在する。多くは「1人のユーザー」または「1つのエージェント」に閉じた記憶を対象にしている点で、TencentDB Agent Memoryとは前提が異なる。README自身が公開している比較表がこの違いを端的に示している。

  Chat History（単純な履歴） 一般的なRAG TencentDB Agent Memory
セッションをまたいだユーザー理解 △ △ ✅ Chat Memory
蒸留された実行可能な経験 — — ✅ Skill
ドキュメント構造・関係性 — △（チャンク検索） ✅ Wiki＋リンクグラフ
コードの呼び出しグラフ・影響範囲 — △（テキストマッチ） ✅ Code Graph
所有者／バージョン／状態の管理 — — ✅
チーム共有・Agentへの装備 — — ✅
private／team／ACLの権限制御 — △ ✅
個人・単一エージェント型の記憶OSSとTencentDB Agent Memoryの違いを示す比較図
個人・単一エージェント型メモリOSSとの層の違い（自作構成図）

当サイトで扱ってきた agentmemory徹底解説｜Claude Code・CursorのAIエージェントに永続メモリを与えるMCPサーバー はMCPサーバー経由で単一エージェントに永続記憶を付与するアプローチであり、cognee（ナレッジグラフ型RAGメモリ）やsupermemory（アプリ組込み用Memory API）も基本的には個人・単一アプリケーションのメモリ強化が主眼だ。TencentDB Agent Memoryはこれらと競合するというより、「チーム・組織単位で記憶資産を保有し、複数エージェント・複数フレームワークで使い回す」という一段上のレイヤーを担っている。

なお、同じTencent Cloud発のAIエージェント関連OSSとしては、AIエージェントをMicroVMで安全に実行する CubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想 もある。実行環境の安全性を担うCubeSandboxと、経験の蓄積・共有を担うTencentDB Agent Memoryは、同じTencent Cloudが「AIエージェントをチーム/組織で本気運用する」ために公開している周辺OSS群として捉えると位置づけが分かりやすい。

ベンチマークで見るTencentDB Agent Memoryの効果

READMEが公開しているベンチマークはPersonaMemの1件のみだった。PersonaMemは、長期のやり取りのあとでAgentがユーザー情報を正しく理解・適用できるかを測るベンチマークだと説明されている。

ベンチマーク 未使用時 有効時 相対改善
PersonaMem 48% 76% +59%
この数値はTencentDB Agent Memory公式READMEの発表値であり、当サイトで追試したものではない。測定条件（テストセット規模やベースライン設定の詳細）はREADME上の簡潔な記述以上には開示されていないため、公式発表値として扱う。

導入前に知っておきたい注意点——ライセンス表記とdefaultブランチ

最後に、導入判断に関わる細かな注意点を5つ挙げておく。

・ライセンス表記の不一致：LICENSEファイル原文には「TencentDB Agent Memory is licensed under the MIT」と明記されており実体はMITだが、GitHubの自動SPDXライセンス判定はNOASSERTIONと表示される。LICENSEファイル冒頭にTencent独自の前文が付いており、標準MITテンプレートと完全一致しないため自動検出に失敗している可能性が高い。バッジや自動判定だけを見て「ライセンス不明」と判断しないよう注意したい
・defaultブランチがfeat/server_team：通常はmainやmasterが既定になるところ、本リポジトリのdefaultブランチは実際に確認した時点でfeat/server_teamという機能ブランチ名のままだった。企業公式リポジトリとしては珍しい状態で、正式リリース前の開発中という位置づけを裏付ける材料の一つといえる
・リリース数は11件：タグ数も11件と一致しており、完全なpre-release ではないが、READMEが「Team Memory Beta」と明記している通りベータ段階の機能として扱うのが妥当
・Wiki・Code Graphは非同期構築：README「Notes」欄によれば、Wiki・Code Graphの構築はバックグラウンドで進むためready状態になるまで多少の待ち時間がある。取り込んだ直後に検索してもヒットしないケースがあり得る
・Code GraphはパブリックHTTPSリポジトリ優先：プライベートリポジトリやSSH認証情報での取り込みは、READMEの「Notes」欄でまだ改善中と明記されている。社内の非公開リポジトリを対象にしたい場合は現状の制約として把握しておきたい

まとめ
TencentDB Agent Memoryは、個人・単一エージェント向けの記憶OSSが並ぶ中で「チーム単位の記憶資産ガバナンス」という一段上のレイヤーを担うOSSだ。Chat Memory・Skill・Wiki・Code Graphという4資産をMemory Hubで一元管理し、private/team/restricted/agentの4段階で共有範囲を統制できる設計は、複数のAgentやフレームワークを併用するチームにとって検討する価値がある。一方でTeam Memory Beta・feat/server_teamブランチという状態が示す通りまだ発展途上で、本番導入は今後のリリースを見ながら判断するのが無難だろう。

参照ソース

・TencentCloud/TencentDB-Agent-Memory（公式リポジトリ・README） — 実測値・4資産タイプ・quickstart手順・PersonaMemベンチマーク数値を取得
・TencentDB-Agent-Memory LICENSE — ライセンス原文（MIT）を確認