複数のエージェントを協調させるシステムを作ろうとすると、ある時点で「プロンプトに詰め込む」アプローチが機能しなくなる瞬間が来ます。
その限界を突破するための設計思想として、Tencentがオープンソース公開した TencentDB-Agent-Memory が面白い切り口を提示しています。
チーム構成のエージェントで「メモリをどこに持たせるか」という設計判断を中心に、同ライブラリが提示する4種類のメモリ資産の役割と使い分けを整理します。
エージェントが「チームで動く」ようになると、メモリ問題の性質が変わる
単体エージェントのメモリ問題——コンテキストウィンドウの上限、セッション終了時の消失——はすでに広く認識されています。
でも複数エージェントが協調するチーム構成になると、もう一段階別の問題が生まれます。
エージェント間の知識断絶 です。
具体的に想像してみてください。
コードレビューエージェントとドキュメント生成エージェントが同じリポジトリを対象に動いているとします。
レビューエージェントは「このモジュールの認証まわりはJWTで有効期限15分、セキュリティ要件上の制約がある」という背景を把握しています。
でもドキュメント生成エージェントはその背景を知らず、コードだけを見て「有効期限15分」とだけ書いたドキュメントを生成します。
設計判断の 理由 が伝わらない。
これは片方のコンテキストウィンドウを大きくしても解決しません。
問題の本質は「メモリがエージェントに閉じている」という構造にあるからです。
エージェントをまたいで知識が循環しない——これがチーム構成で顕在化する固有の問題です。
「プロンプトに詰め込む」アプローチで対処しようとすると、別の壁にぶつかります。
コンテキストが大きくなるほどトークン消費は増え、大量のテキストを詰め込むとモデルが中間の重要情報を見落としやすくなる「lost in the middle」問題も複数の研究で確認されています。
チームメンバー（エージェント）が増えるたびに詰め込む量が線形に増えていく点も見逃せません。
「もっと大きなコンテキストを用意する」という方向では根本的には解決しません。
設計の発想を変える必要があります。
TencentDB-Agent-Memoryが提示する「共有メモリハブ」という設計思想
TencentDB-Agent-Memoryが提示する答えはシンプルです。
メモリをエージェントの内部状態として持たせるのではなく、 外部の共有ハブとして切り出す という発想の転換です。
リポジトリのREADMEにある設計哲学を引用すると、「Memory doesn't run the Agent loop; it ensures the next iteration inherits the previous one's results」とあります。
メモリはループを動かすものではなく、ループをまたいで経験を引き継がせるものだ、ということです。
エージェントがタスクをこなすたびに知識が蓄積され、次のエージェントがゼロから学習しなくて済む状態を作る——これが設計の核心です。
この思想が実務で効いてくるポイントを整理すると、次のようになります。
- コールドスタート対策：新しいエージェントが既存の知識資産を引き継げる。ゼロから学習させるコストがかからない。
- フレームワーク非依存：LangChain・LangGraph・AutoGenをまたいで同じメモリ資産を参照できる。既存の構成を壊さずに導入でき、フレームワーク移行時にメモリ資産を持ち越せる。
- 資産の自動抽出：会話やタスクの結果からChat MemoryやSkillを自動的に抽出・蓄積する仕組みがある。手動管理のコストを下げる。
- ループをまたいだ経験継承：あるエージェントが得た知見が、別のエージェントの次の実行に反映される。
フレームワーク非依存という特徴は、地味に重要です。
実務では「LangChainで作り始めたけど途中でLangGraphに移行した」「チームによってフレームワークがバラバラ」という状況がよくあります。
メモリ資産がフレームワークから切り離されていれば、そういった移行コストが大幅に下がります。
4種類のメモリ資産——何を、どんな形で覚えるのか
TencentDB-Agent-Memoryは、記憶の種類を4つに分けて管理します。
Chat Memory は会話履歴の蒸留です。
生の会話ログをそのまま保存するのではなく、やり取りから価値ある情報を抽出して保持します。
「3ヶ月前に認証の有効期限を15分に決めた理由」のような設計判断の背景が、ここに残ります。
Skill は再利用可能な手順の蓄積です。
「このプロジェクトのPRレビュー手順」「このシステムへのデプロイ手順」のような、繰り返し使われる作業フローをスキルとして登録します。
業務システム開発であれば、「このDBのマイグレーション手順はこの順番でやる」といったプロジェクト固有のルールをSkillに蓄積しておくと効果的です。
LLM-Wiki は業務ドメイン知識の集約です。
業務ルール・仕様書・用語集のような「エージェントが参照すべき知識」をここに置きます。
Web制作の現場なら、クライアントのブランドガイドライン・コーディング規約・デザインシステムのルールをLLM-Wikiに集約して、コード生成エージェントもレビューエージェントも同じ基準で動かす、という使い方が考えられます。
Code-Graph はコード構造の理解です。
コードベースをグラフ構造として保持し、モジュール間の依存関係や呼び出し関係を記憶します。
コードレビューエージェントとドキュメント生成エージェントが同じCode-Graphを参照すれば、「同じコードベースについて別々に理解を構築してしまう」問題が解消されます。
RAGとの違いを一言で言うと、RAGが文書をチャンク単位で引っ張ってくるのに対して、これらの資産は意味的に構造化された単位として保持されます。
Code-Graphがその最たる例で、コードをテキストの塊として検索するのではなく、構造として理解している点が異なります。
「どの資産から試すか」を考えるときは、 チームの知識断絶がどこで起きているか を診断する視点が有効です。
エージェントが同じコードベースを別々に理解しているならCode-Graph、業務ルールの解釈がブレるならLLM-Wiki、確立した手順を毎回説明し直しているならSkill——どこが一番痛いかを起点に選ぶのが現実的です。
実際に組み込むとき——最小構成と現実的な落とし穴
組み込みのイメージを掴むために、npmパッケージ（@tencentdb-agent-memory/memory-tencentdb）を使った最小構成を見てみます。
import { TencentDBMemory } from "@tencentdb-agent-memory/memory-tencentdb";
const memory = new TencentDBMemory({
connectionString: process.env.TENCENTDB_CONNECTION_STRING,
});
// Skillの登録（例：PRレビュー手順）
await memory.skill.save({
name: "pr-review-flow",
description: "このプロジェクトのPRレビュー手順",
steps: [
"型チェックとlintを確認する",
"マイグレーションファイルの順序を確認する",
"APIの破壊的変更がないか確認する",
],
});
// 別のエージェントからSkillを取得
const skill = await memory.skill.load("pr-review-flow");
LangChainと接続する場合は、メモリハブをLangChainのメモリインターフェースに差し込む形になります。
sessionIdを複数エージェントで共有することで、Chat Memoryが共有ハブとして機能します。
import { TencentDBChatMemory } from "@tencentdb-agent-memory/memory-tencentdb";
import { ConversationChain } from "langchain/chains";
import { ChatOpenAI } from "@langchain/openai";
const chatMemory = new TencentDBChatMemory({
connectionString: process.env.TENCENTDB_CONNECTION_STRING,
sessionId: "project-alpha", // 複数エージェントが同じsessionIdを参照
});
const chain = new ConversationChain({
llm: new ChatOpenAI(),
memory: chatMemory,
});
Tencentが公開している評価数値として、WideSearchベンチマークで正解率が33%から50%へ（+51.52%）、トークン消費が−61.38%、SWE-benchで58.4%から64.2%へ（+9.93%）、トークン消費が−33.09%という結果があります。
ただしこれらはTencent自身の評価であり、自社のOpenClaw環境との統合で計測されたものです。
自分たちの環境でそのまま再現できるとは限らない点は添えておきます。
現実的な落とし穴として、 メモリの鮮度管理 は最初から設計に組み込んでおく必要があります。
古い情報が残り続けると、エージェントが誤った前提で動く「コンテキストポイズニング」が起きます。
更新トリガーをどこに置くか（タスク完了時・スプリント終了時・仕様変更時など）を事前に決めておかないと、ハブが古い知識の墓場になります。
もう一つが ノイズ混入リスク です。
自動抽出の便利さと、誤情報が広がるリスクはトレードオフです。
「自動抽出されたSkillは人間がレビューしてから有効化する」といったガバナンスを最初から考えておく必要があります。
「このライブラリを使う」か「同思想で自前設計する」か
TencentDB-Agent-Memoryを採用するかどうかは、TencentDBへの依存を許容できるか、TypeScriptスタックと整合するか、エージェント数や知識資産の複雑さがライブラリの恩恵を受けるほどの規模か——これらが主な判断軸です。
一方で、 「共有メモリハブ」という設計思想自体は汎用的 です。
PostgresやElasticsearchを使って同じ発想で自前実装することは十分に現実的です。
ライブラリを使わないとしても、この思想を持ち帰ることに価値があります。
自前設計の場合、最低限考えるべき構造は「資産の種別分離」「書き込み権限」「更新トリガーの設計」の3点です。
Postgresで共有メモリハブを作るとしたら、最小限のスキーマはこのようなイメージになります。
CREATE TABLE agent_memory_assets (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
asset_type TEXT NOT NULL CHECK (asset_type IN ('chat_memory', 'skill', 'llm_wiki', 'code_graph')),
project_id TEXT NOT NULL,
name TEXT NOT NULL,
content JSONB NOT NULL,
status TEXT NOT NULL DEFAULT 'pending'
CHECK (status IN ('pending', 'approved', 'archived')),
created_by TEXT NOT NULL,
reviewed_by TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_memory_project_type
ON agent_memory_assets (project_id, asset_type, status);
statusカラムで「pending（自動抽出済み・未レビュー）」「approved（レビュー済み・有効）」「archived（古くなって無効化）」を管理するのがポイントです。
エージェントが参照するのはapprovedのものだけにする、という運用ルールをスキーマレベルで強制できます。
ノイズ混入リスクへの対処も、このstatusの仕組みで一定カバーできます。
次のアクションとして考えられるのは2つです。
まずリポジトリ（ TencentCloud/TencentDB-Agent-Memory ）を手元で動かして、4種類の資産の実際の挙動を確かめること。
もう一つは、今動かしているエージェントの「知識断絶がどこで起きているか」を診断して、どの資産種別から試すかを決めること。
思想を理解した上で小さく試すのが、一番コストの低い始め方です。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AIエージェント活用の支援をしています。
エージェント設計やメモリ設計まわりで「自分たちのケースに当てはめるとどうなるか」を相談したい場合は、お気軽にご連絡ください。
お問い合わせはこちら