TencentDB Agent Memoryとは チームで記憶を資産化する仕組み

チームの誰かが半日かけて突き止めた「この書き方は事故る」が、Slackのスレッドと一緒に流れていく。1週間後、別のメンバーが同じ罠を踏んでまた半日溶かす。Tencent Cloudが公開したTencentDB Agent Memoryは、この繰り返しをエージェント側で止めにいくOSSです。

チームの誰かが調べたことが誰にも残らない問題

今あるエージェントのメモリ機能は、ほぼ全部が個人単位です。使い手のClaude Codeはその人の癖を覚えてくれるけど、隣の席の人のClaude Codeは何も知らない。Mem0やZepみたいな系統も、狙っているのは個々のエージェントに記憶を持たせるところです。

でも実際にコストが高いのって、個人の好みじゃないんですよね。「この外部APIはレスポンスにnullが混ざる」「このマイグレーションは本番で詰まる」みたいな、誰かが一度痛い目を見て手に入れた知見のほうです。

その代わりに使われているのがCLAUDE.mdとかナレッジ用のリポジトリなんですが、あれは人力更新なので必ず腐ります。書いた人しか直さないし、直さないまま半年経つ。ここを設計から作り直してるのが今回のやつです。

TencentDB Agent Memoryとは 4つの記憶資産をチームで再利用する発想

リポジトリの自己紹介がそのまま設計思想になっていて、「AIエージェントのためのチーム単位のメモリハブ」と名乗っています。会話とドキュメントとコードを、再利用できる4つの記憶資産に変換する、と。

GitHub - TencentCloud/TencentDB-Agent-Memory: TencentDB Agent Memory is a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks.

TencentDB Agent Memory is a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed...

github.com

公開は2026年4月7日で、4ヶ月で18,000スターを超えました。TypeScript製です。

ここがマジで大事なんですが、会話ログを貯めるツールではないと明言しています。ログは検索しても使えない、資産に変換して初めてエージェントが装備できる、という立場です。Skillが単なるプロンプト片ではなく「バージョンと検証ルールを持つ」と書かれているあたりに本気度が出ています。

生の会話がL0からL3へ蒸留される流れ

記憶は4層に分かれています。L0が生の会話そのまま、L1がそこから抜き出した事実、好み、制約、イベント。L2はプロジェクト単位でまとめた知識ブロックで、L3が長期的なプロフィールや安定したパターンです。

検索の順番が良くできていて、まずL2とL3でざっくり文脈を立ち上げて、細かい事実が必要になったらL1とL0に降りていきます。全部をコンテキストに突っ込まない設計です。検索そのものもBM25とベクトル検索をRRFで合成しています。

リポジトリが出しているベンチマークもこの狙いを裏付けていて、PersonaMemが48%から76%、SWE-benchが58.4%から64.2%。同時にSWE-benchのトークン消費が33%落ちています。精度が上がってトークンが減る、という主張です。

ただしこれは開発元の自己申告で、第三者の再現はまだ見当たりません。数字は方向性の目安として見ておくくらいが妥当です。

ワンコマンドで起動 ただしLLMのキーは2セット要る

手順自体は拍子抜けするほど短いです。

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # LLMのパラメータを2セット埋める
./start-all.sh

起動したら http://localhost:8125 でパネルが開きます。前提はNode.js 22.16以上。

引っかかるとしたら .env です。ここ、LLMのパラメータを2セット書けと指示されています。つまり手を動かす前にモデルのエンドポイントとキーを2つ用意しておかないと、cloneした直後に止まります。ここだけ先に片付けてから始めるのをおすすめします。

対応しているエージェントはOpenClaw、Hermes、Claude Code、CodeBuddy、あとSDK統合です。

private team restricted agent で見える範囲を決める

記憶をチームで共有する仕組みは、権限設計を外した瞬間に事故ります。個人の雑談ログが全員に見えるようなものを、誰も本番のチームには入れません。

用意されている可視性は4段階です。

• private: 所有者だけが読める
• team: チームメンバーが読めて、所有者と管理者が管理する
• restricted: ユーザー、ロール、エージェント単位のACLで細かく指定する
• agent: 同じチーム内の特定のエージェントに装備させる

面白いのが agent です。人ではなくエージェントに対して資産を装備させるという発想で、「このレビュー用エージェントにはこのSkillとこのWikiだけ持たせる」という切り分けができます。

Memory Hubと呼ばれる管理パネルも、単なる一覧画面ではなくコントロールパネルとして設計されています。チームの作成とメンバー管理、資産のレビュー、エージェントの装備の変更、WikiとCodeGraphの処理状況の確認、所有者とバージョンとアクセス権の管理まで、ここから触ります。

CodeGraphがプライベートリポジトリにまだ弱い

で、ここが今回いちばん正直に書いておきたい罠です。公式の注意書きに、CodeGraphは現状パブリックなHTTPSリポジトリを優先していて、プライベートリポジトリとSSH認証の対応はまだ調整中、と書かれています。

チーム単位の記憶ハブを名乗っているのに、そのチームのコードはだいたいプライベートリポジトリにあるわけで、いちばん効いてほしい機能がいちばん未成熟という状態です。

なので今から入れるなら、Chat MemoryとSkillとWikiの3つで回すのが現実的です。CodeGraphは対応が固まってから乗せる。ここを分けて考えないと、導入直後に「思ってたのと違う」となります。

記憶を分けるか共有するか 入れて効くチームの条件

エージェントの記憶をどう扱うかは、今きれいに2つの方向へ割れています。個人ごとに記憶とツール権限を分離して混ざらないようにする方向と、チームで1つの記憶を共有して再利用する方向です。

分離は事故りにくい代わりに、知見が横に流れません。共有は流れる代わりに、権限を間違えると漏れます。TencentDB Agent Memoryは後者に全振りしたうえで、その弱点をACLで埋めにいった設計です。

刺さるのは、同じドメインを複数人で触っていて、新メンバーの立ち上がりに時間がかかっていて、しかも同じ調査が何度も繰り返されているチーム。逆に一人開発なら、既存の個人向けメモリツールで十分足ります。

心当たりがあるなら、まずは ./start-all.sh まで通してChat MemoryとSkillだけ動かしてみてください。CodeGraphの判断はそのあとで間に合います。