何が起きたか
Tencentは今週、オープンソースプロジェクト「Agent Memory」を拡張し、複数のAIエージェントが同一の管理された文脈を参照する共有ハブ「Team Memory」をベータ公開しました。同プロジェクトは、長時間セッションでエージェントが文脈を失う問題を半年かけて潰した経験から生まれたもので、リポジトリはGitHubのTypeScriptトレンドで1位に達したとしています。
中核にあるのは「ペルソナ層」です。ユーザーが何者で、どう仕事を進めるかを多数の会話から蒸留し、毎回組み立て直すのではなく安定した像として保持します。Tencent自身のベンチマーク（長時間利用後もペルソナを正しく適用できるか）では、ペルソナ層の追加で精度が48%から76%へ、相対で59%改善したと報告されています。
なぜ重要か：「1体の記憶」から「チームの記憶」へ
2026年のエージェント記憶研究の大半は、1エージェント・1セッション・1ユーザーの範囲に閉じてきました。LangChainのLangMem SDK、GoogleのAlways On Memory Agent、AnthropicのClaude Agent SDK内の取り組みも、基本線は「1体がより多く覚える」ことです。Team Memoryはここを外し、チームの全エージェントが同じハブを読む設計に踏み込みました。
これが刺さる理由は、失敗の実感が広く共有されているからです。VB Pulseの6月調査では、企業の57%が「自信満々に間違った回答」の原因を、欠落したあるいは不整合な文脈にまで遡って特定しています。一方で、共有される業務データに対する統制された文脈レイヤーを本番運用している企業は25%にとどまります。AWS、Couchbase、Oracle、Redis、Pineconeが今年そろって同種の機能を出しているのは、この差分が市場になっているためです。
共有プロンプトではなく「共有ハブ」
Team Memoryは4種類の再利用資産を登録し、各エージェントに必要なものだけを装備させます。会話から選好・事実・意思決定・履歴を4層で蒸留するChat Memory、完了した仕事から手順を抽出しバージョン管理とレビューを経て共有されるSkill、ドキュメントや仕様を構造化・相互リンクされたページに変えるLLM-Wiki、コードベースのシンボル・ファイル・呼び出し関係を索引化して変更の影響範囲を事前確認できるCode-Graphです。
この配り分けをTencentは「Agent Loadout」と呼びます。調査担当のScoutエージェントには市場調査と競合分析の資産を、実装担当のBuilderにはコードグラフとプロダクト仕様を渡す、という具合です。可視性はPrivate（所有者のみ）／Team（チーム全員）／Restricted（ユーザー・ロール・エージェント単位の制御）／Agent（チーム内の特定エージェントのみ）の4段階で、新規資産の既定はPrivate。共有は明示的な行為として設計されています。ドキュメントは自らの位置づけを「RAGは『何が見つかるか』に答える。Team Memoryは『誰が使ってよいか、どのバージョンが有効か、どのエージェントに渡すか』にも答える」と説明しています。
抜けているのは読み取りではなく「書き込み」の統制
公開直後からX上の実務者が指摘したのは、まさにその書き込みパスでした。Blake Murphy氏は「一度書かれた誤った事実が、自分だけでなく全員のエージェントに伝播する」として訂正と失効の扱いを問い、Austin Green氏は「2人のエージェントが同じモジュールについて矛盾する事実を書いたとき、どちらの記憶が勝つのか」をベンチマークすべき点に挙げ、単一エージェントの記憶はゆっくり劣化するが共有記憶は速く劣化すると述べています。Virgil Maro氏は「何を絶対に書き残さないかを誰かが決めなければならない」と、書かない設計の必要性を指摘しました。
Tencentのドキュメントは資産ごとの所有者・バージョン・ステータス追跡は定義していますが、他エージェントが既に読んで再利用した事実の訂正・失効手順も、矛盾する記憶の解決方法も記述していません。ベンダー非依存で2026年3月に出た論文「Governed Memory: A Production Architecture for Multi-Agent Workflows」も、ガバナンスの分断と、フィードバックループのない静かな品質劣化を、共有マルチエージェント記憶の構造的リスクとして挙げています。
最も近い先行例はAsana
比較対象として近いのはAsanaです。同社は社内のAIチームメイト間で共有記憶を構築し、別のエージェントが既に把握している文脈を再説明せずに済むようにしました。同社CPOも同じトレードオフに言及し、あるエージェントの記憶が、権限のないプロジェクトへ漏れないようにアクセス制御を設計したと説明しています。違いは実装形態で、Asanaが自社プラットフォーム内に閉じるのに対し、Tencent版はオープンソースかつフレームワーク横断で持ち運べます。
狙う効果と代償は表裏一体です。エージェントはチームが既に知っていることを学び直さずに済む。その代わり、1回の誤った書き込みは共有プールを読む全エージェントに継承され、いまのところ訂正・失効の仕組みはありません。
💼 事業会社視点：これは自社にどう効くか
受託開発・SIerにとっては即戦力の論点です。 Code-GraphとLLM-Wiki���分離は、レガシー改修で「この変更が何に波及するか」を人間の記憶に依存してきた現場に直接効きます。オープンソースかつフレームワーク横断のため、顧客環境に持ち込める提案材料にもなります。ただし複数案件の資産を1ハブに載せるなら、既定Privateと4段階の可視性だけでは足りません。顧客資産の混在は契約違反に直結するため、Restrictedの運用ルールを先に決めるべきです。
SaaS・EC事業者は「書き込み権限」を設計課題として切り出してください。 価格改定や在庫ルール、キャンペーン条件のように頻繁に変わる事実を共有記憶に書くと、失効の仕組みがない現状では古い前提のまま全エージェントが動きます。57%の企業が文脈起因の誤答を経験している以上、共有化の前に「変動する事実は書かず、都度参照する」線引きを引くのが現実的です。
役員が今週やるべきは、共有記憶の全社導入判断ではなく、書き込みポリシーの起案です。 誰が書けるか、何を書かないか、誤りを見つけた人はどう取り消すか。統制された文脈レイヤーを本番運用できている企業が25%にとどまるのは、技術より運用設計が難所だからです。Team Memoryはベータであり、まずは1チーム・1領域で書き込み監査つきの検証に留めるのが妥当です。