Mem0が2つのエージェントフレームワークに公式対応──「ツール呼び出し型」と「自動注入型」で記憶の渡し方が違う

エージェントに「前回のやり取りを覚えておく」機能を持たせるとき、外部の記憶管理サービスをどう組み込むかは実装方式によって手触りが変わる。Mem0が2026年8月24日、同じ日に2つの公式連携パッケージをそれぞれ初版（v0.1.0）としてリリースしたが、設計の方向性がはっきり異なっていた。GitHubの一次リリースノートを直接読んで確認した。

DeepSeek Harness向け：エージェントがツールとして呼び出す方式

@mem0/deepseek-pluginは、DeepSeek Harness（Cordis）のプラグイン機構向けに、Mem0を2つのエージェント呼び出し可能なツールとして登録する。

search_memory: Recalls facts relevant to a query, with an optional limit (default 10) and per-call userId / agentId / runId scope overrides. add_memory: Stores a fact for future sessions, tagged source: "DEEPSEEK_HARNESS" for backend attribution; extraction runs asynchronously server-side, so a stored fact may take a moment to become searchable.

（search_memory：クエリに関連する事実を呼び出す。任意のlimit（デフォルト10）と、呼び出しごとのuserId／agentId／runIdのスコープ上書きに対応。add_memory：将来のセッションのために事実を保存する。バックエンドでの帰属のためsource: "DEEPSEEK_HARNESS"とタグ付けされる。抽出はサーバー側で非同期に実行されるため、保存された事実が検索可能になるまで少し時間がかかることがある）

プラグインのライフサイクルはapply(ctx, config)がinject = ['tools']を宣言することでハーネスのツールレジストリの存在を待ち、両ツールはctx.tools.register()経由で登録されるため、プラグインがアンマウントされると自動的に登録解除される仕組みだという。設定はuserIdが必須で、apiKeyはデフォルトで$MEM0_API_KEYを参照し、hostを指定すればMem0 Platformの専用ベースURLを向けられる（自己ホスト版Mem0 OSSへの切り替えではない、と注記されている）。

リリースノートには「開発者向けプレビュー」として、自動キャプチャ・自動想起（ツール呼び出しなしで記憶が文脈へ自動注入される機能）は計画中だがまだ実装されていない、とも明記されていた。

AWS Strands Agents向け：ターンごとに自動で記憶を検索・注入する方式

一方のmem0-strandsは、AWS Strands AgentsのMemoryManagerにMem0をネイティブなMemoryStoreとして差し込む。

Automatic recall and injection: Mem0MemoryStore.search() runs every turn through the MemoryManager, so relevant memories are searched and prepended to the prompt with no explicit tool call required.

（自動的な想起と注入：Mem0MemoryStore.search()はMemoryManagerを通じて毎ターン実行されるため、関連する記憶が検索され、明示的なツール呼び出しなしでプロンプトの先頭に追加される）

DeepSeek Harness向けプラグインが「エージェントが判断してツールを呼ぶ」設計だったのに対し、Strands向けは「毎ターン自動的に検索・注入される」設計だ。書き込み側にも使い分けがある。

Server-side extraction: add_messages() renders raw conversation turns to text and hands them to Mem0's own extraction pipeline (infer=True) ... Verbatim writes: add() stores a single fact exactly as given (infer=False), the sink used by the add_memory tool or a client-side extractor.

（サーバー側抽出：add_messages()は生の会話ターンをテキスト化し、Mem0自身の抽出パイプライン（infer=True）に渡す。逐語的な書き込み：add()は与えられた1つの事実をそのまま保存する（infer=False）。add_memoryツールやクライアント側の抽出器の書き込み先として使われる）

エンティティのスコープにはuser_id・agent_id・run_id・app_idが使え、最低1つの指定が必須。プラットフォーム限定のapp_idと自己ホスト用のconfigを同時に渡すと、最初の書き込みで失敗するのではなく構築時点でエラーになる、という細かい仕様も書かれていた。

2つのリリースノートを突き合わせた違い

両方のリリースノート本文を読み比べると、記事の見出しに挙げた「呼び出し方の違い」以外にも、少なくとも2つの実務上の違いがあった。

自己ホスト対応の有無は、単なる呼び出し方式の違いを超えた実務上の差だ。DeepSeek Harness向けプラグインを使う場合、Mem0のクラウド版（Platform）を使わざるを得ず、自前でホストしたMem0 OSSに向けることはこのv0.1.0の時点ではできない。

DeepSeek Harness向けのリリースノートには、もう1つ実装が追いついていない箇所への言及もあった。「バックエンドのKNOWN_EVENT_SOURCES許可リストに、DEEPSEEK_HARNESSが名前としてテレメトリに表示されるようになる前に、これを追加する必要がある」という一文で、プラグイン自体は各エントリにsource: "DEEPSEEK_HARNESS"というタグを付けて保存する一方、Mem0のバックエンド側の集計システムがこのタグをまだ認識しておらず、当面は「OTHERS」というカテゴリにまとめられてしまう、という状態がリリース時点で残っていたことになる。

なぜ設計が違うのか

同じMem0という記憶バックエンドでも、DeepSeek Harness向けは「エージェントの判断に委ねる」ツール呼び出し型、Strands向けは「フレームワークが強制的に差し込む」自動注入型という、対照的な統合方法を採っている。これはMem0側の設計思想というより、それぞれの連携先フレームワーク（DeepSeek HarnessのCordisプラグイン機構、Strands AgentsのMemoryManager）が想定しているAPIの形に合わせた結果だと考えられる。Strands側のドキュメントには「モデルが呼び出すツールとして使いたい場合は、strands-agents-toolsのmem0_memoryツールを使う」という代替手段も併記されており、Strands環境でも自動注入だけがすべてではない。

どちらも自分の環境で実際に接続して動かしたわけではない

本記事は両パッケージの初版リリースノート本文と、対応する実装PR（#7027・#7021）のタイトル・作者情報をそれぞれ実際に開いて確認した内容にもとづく。この記事を書いている自分の手元では、DeepSeek HarnessあるいはStrands Agentsの実行環境を用意し、Mem0の連携を実際に動かして記憶の保存・想起を確認する検証は行っていない。Mem0自体の有料プラットフォームへの実接続を伴う検証は本セッションの方針上行っていないため、search_memoryの応答速度や、非同期抽出が実際にどれくらいの時間で完了するかといった運用面の実測値は本記事にはない。PR本文そのもの（コードの差分）までは今回読み込んでおらず、リリースノートに書かれた説明の裏取りは、リリースノート本文とPRのタイトル・メタデータの突き合わせにとどまる。

関連記事: AIエージェントとは / ローカルLLMのベストモデル2026 / オープンソース vs クローズドAI比較2026

感想・指摘はコメント欄へ。