TencentDB Agent Memory入門：OpenClawでローカル記憶を試す方法

長く続く個人プロジェクトで面倒なのは、モデルの賢さよりも、再起動するたびにすべてを忘れてしまうことかもしれません。アーキテクチャや好み、進捗を毎回説明し直し、手作業で管理するMEMORY.mdは長くなる一方です。TencentDB Agent Memoryはこの問題を解こうとしていますが、「ローカル記憶」という言葉は誤解を招きやすい表現です。本記事は公式ドキュメントに基づいて整理しています。執筆時に実際のインストールは行っていないため、公式テストを実体験としては扱いません。

最初に対象読者を確認しておきましょう。自分でOpenClawやHermesを運用している人、またはGatewayを管理できる人向けです。ChatGPT、Claude、Notionの一般的な画面だけを使い、自分でAgentの実行環境を管理していない場合、このプラグインは現時点では手軽な記憶ツールではありません。

TL;DR

デフォルトのSQLiteは記憶データをローカルに保存できるという意味であり、抽出や検索で外部モデルを一切呼ばないという意味ではありません。
特徴は単にベクトルデータベースを追加することではなく、記憶をL0〜L3に分け、Personaから元の会話までたどれる点にあります。
最初は隔離したAgent、SQLite、キーワード検索だけで試します。セッションをまたぐ呼び出しが本当に役立つと確認してから、embeddingやクラウドのバックエンドを検討します。
短いタスク、低頻度の利用、またはMEMORY.mdで十分な場合は、状態を持つサービスをもう一つ管理する価値は低いでしょう。

「ローカル」なのはどこまで？

TencentDB Agent Memoryのローカルモードでは、記憶のバックエンドにSQLiteとsqlite-vecを使います。 これは「データをどこに保存するか」への回答であって、「どの内容をモデルが処理するか」への回答ではありません。長期記憶の抽出にはLLMが必要で、embeddingを外部へ送るかどうかは設定で決まります。

インストール前にデータの流れを4段階に分けると、local-firstという短い表現だけを見るより、リスクを判断しやすくなります。

段階	処理する内容	デフォルトまたは選択可能な送信先	インストール前に確認すること
会話の取得	元の会話	ローカルのL0ファイルとSQLite	顧客データを取得してよいか
記憶の抽出	会話をAtom、Scenario、Personaへ変換	OpenClawのホストモデル、または別途設定したLLM	モデルはリモートAPIか、どの文章を送るのか
記憶の保存	階層化した記憶とインデックス	デフォルトはSQLite、TCVDBも選択可能	データの場所、権限、バックアップ先はどこか
記憶の呼び出し	キーワード、embedding、ハイブリッドによる検索	ローカルのキーワード検索、または設定したembeddingプロバイダー	検索文が端末外へ出るか

どこか一つでも受け入れられない処理があれば、実際の顧客データでは試さないでください。まず機密性のない個人プロジェクトを使うのが、最も低コストなリスク対策です。

単なる会話ログではない、L0〜L3の仕組み

公式の設計では記憶を4層に分けています。L0は元の会話、L1は単独で使える原子的な記憶、L2は関連する記憶をまとめた状況、L3はPersonaです。上位層はAgentが背景をすばやく把握するために使われ、下位層には根拠を追跡するための情報が残ります。

層	主な内容	保存に向くもの	よくあるリスク
L0 Conversation	元の会話	文脈の復元、根拠の追跡	機密情報がそのまま残る
L1 Atom	一つの好み、事実、判断	技術選定、安定した好み	抽出ミス、情報の陳腐化
L2 Scenario	関連する状況のまとまり	プロジェクトの手順、繰り返す場面	異なる状況が誤って統合される
L3 Persona	高レベルの利用者像	長期的な協働方法	偏りが「あなたはこういう人だ」と固定される

実用上の利点は追跡可能性です。Agentが特定のフレームワークを好むはずだと言い張ったとき、PersonaからScenario、Atom、元のConversationへ戻れれば、読み違いか、要約ミスか、単に古い情報なのかを確認できます。Markdownだけなら人が読みやすい一方、読み込みと更新は自分で管理しなければなりません。4層のパイプラインでは自動化が増えますが、同時に管理すべき状態も増えます。

Agentの記憶方式を検討中なら、自動取得を有効にする前にAI Agentの記憶アーキテクチャ解説も参考にしてください。

導入すべき人と、MEMORY.mdで十分な人

まず3つの方式を分けて考えます。OpenClaw built-in memoryはMEMORY.mdとmemory/*.mdをインデックス化し、キーワード、ベクトル、ハイブリッド検索に対応します。TencentDB Agent Memoryは、さらに会話の取得とL0〜L3の抽出パイプラインを追加します。どちらもSQLiteを使う場合がありますが、解決する問題は同じではありません。

方式	記憶の作り方	検索方法	主な保守作業	向いている人
手動の`MEMORY.md`	人が整理、編集、削除	Agentがファイルを読む、またはホスト側でインデックス化	文章と読み込みルールの管理	記憶量が少なく、内容を完全に管理したい人
OpenClaw built-in memory	`MEMORY.md`と`memory/*.md`をインデックス化	キーワード、ベクトル、ハイブリッド	ファイル、embeddingプロバイダー、インデックスの管理	既存のMarkdown記憶があり、主に検索を改善したい人
TencentDB Agent Memory	会話を自動取得し、L0〜L3へ抽出	キーワード、embedding、hybrid	抽出、スケジュール、階層データ、バックアップ、バージョンの管理	セッションをまたぐ説明が多く、記憶の出典を追跡したい人

状況	おすすめ	理由
同じプロジェクト背景を週に何度も説明する	試してみる	反復コストが明確で、改善を測りやすい
長いセッションで初期の判断がcontext圧力により失われやすい	試してみる	履歴全体を再投入するより階層記憶のほうが管理しやすい可能性がある
好みの根拠となった会話を特定したい	試してみる	追跡可能な構造が要件に合う
1、2回で終わるタスク	まだ導入しない	データベースとスケジュールの追加負担を回収しにくい
短い`MEMORY.md`が安定して動いている	シンプルなままにする	人が読めてバージョン管理でき、障害点が少ない
バックアップ、権限管理、定期確認ができない	本番データには使わない	長期記憶は蓄積するため、管理しなければ問題を先送りするだけになる

GitHubでの人気は導入基準ではありません。実際に数えるべきなのは、1週間に背景を何回説明し直しているか、そしてバックアップ、削除、更新、誤った記憶の修正を引き受けられるかです。

OpenClawで最小構成を試す

現在の公式ドキュメントで最短のOpenClaw導入手順は、npmプラグインをインストールし、Gatewayを再起動してmemory-tencentdbを有効にする方法です。公開前に公式READMEとnpmページでパッケージ名を照合しました。ただしOpenClawとプラグインは更新されるため、実行前に最新のREADMEとCHANGELOGを確認してください。

openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart

次に、公式READMEで指定されている~/.openclaw/openclaw.jsonを編集します。enabled: trueだけを設定した場合、公式スキーマでは呼び出し方式のデフォルトがhybrid、embeddingプロバイダーのデフォルトがnoneです。本記事で測る純粋なキーワード検索の基準とは異なるため、最初は両方を明示します。

{
  "memory-tencentdb": {
    "enabled": true,
    "config": {
      "recall": {
        "strategy": "keyword"
      },
      "embedding": {
        "provider": "none"
      }
    }
  }
}

最初はテスト用プロファイル、デフォルトのSQLite、embeddingを無効にしたキーワード検索の3点だけに絞ります。short-term offload、TCVDB、リモートembeddingは変数を増やすため、基本的な書き込みと呼び出しが安定してから追加します。

Gatewayを再起動したら、新しいセッションでプラグインが読み込まれていることを確認し、その後に下記のセッション横断テストを行います。OpenClawのログ用コマンドや出力形式はバージョンによって変わる可能性があり、公式READMEには現時点で全バージョン共通の確認コマンドがありません。起動結果にプラグインが表示されない、または会話がまったく取得されない場合は、そのバージョンのREADME、マニフェスト、Issuesを確認してください。スタンドアロンやHermes向けのmemory-tencentdb-ctl healthをOpenClawの合格判定には使わないでください。

バージョン互換性は現実的な注意点です。2026年10月3日の再確認時点で、npmのlatestは1.0.3です。公式の1.0.3リリースノートによると、この版ではOpenClaw 9.5の初回インストールでenabledが書き込まれないことがある競合と、新しいパッケージ構成によるsqlite-vecの読み込み失敗が修正されています。1.0.1から更新する場合は、先にデータをバックアップして1.0.3へ固定し、再起動後にプラグインが有効で、ベクトル検索なしの状態へ降格していないことを確認してください。古い解説のパッチコマンドを新しい環境へそのまま貼り付けないでください。

セッションをまたいで記憶できるか、5段階で確認する

「plugin enabled」は読み込みの成功を示すだけで、取得、抽出、集約、呼び出しのすべてが正常とは限りません。機密性がなく、正誤を判断しやすい情報で試します。たとえば「このテストプロジェクトのリリース用ブランチはpilot-releaseで、マージ前に毎回ドライランを行う」と伝えます。

書き込む： テスト用Agentにプロジェクトのルールを明確に伝え、時刻とセッションを記録します。
抽出を待つ： 設定に従ってL1 pipelineの実行を待ちます。完了時間を推測せず、ログや読める記憶ファイルを確認します。
新しいセッションで呼び出す： 「このプロジェクトをマージする前に何をしますか」とだけ尋ね、質問の中に答えを入れないようにします。
根拠をたどる： 呼び出された結果からAtomと元の会話を見つけ、内容と出典が正しいかを確認します。
修正して無効にする： 意図的にルールを変更し、古い情報を識別できるか確認します。無効化した後、取得が続かないことも確かめます。

各テストでは、正しく呼び出せたか、呼び出し漏れ、誤った呼び出し、待ち時間、人による修正回数の5項目を記録します。1回成功しただけでは、安定して呼び出せたのか、たまたまキーワードが一致したのか判断できません。

キーワードとembedding、自分の10問で決める

embeddingを設定しなくてもキーワード検索は使えます。 OpenClawプラグインのマニフェストにはkeyword、embedding、hybridの3つの呼び出し方式があり、embedding.provider: "none"でベクトル検索を無効にできると記載されています。公式CTLドキュメントのBM25フォールバックとembedding無効化コマンドはスタンドアロンやHermes向けであり、OpenClawを直接操作するものではありません。そのため、まず複雑さの低い基準を作れます。

10問を用意しますが、すべてを元の文章と同じ表現にはしません。5問は元のキーワードを残し、残り5問は意味を保ったまま言い換えます。たとえば「release branch」を「正式公開前にどのbranchへマージするか」に変えます。次の項目を記録してください。

上位5件に正解が含まれるか
別のプロジェクトのルールが混ざらないか
検索にかかった時間
API費用が増えたか
検索文が外部providerへ送られたか

キーワード検索で安定して見つかるなら、「よりAIらしくする」ためだけにembeddingを有効にする必要はありません。意味を言い換えた質問が継続して失敗し、新しいデータ送信経路と費用を許容できる場合にだけハイブリッド検索を試します。embedding設定を切り替えるたびに既存インデックスの再構築が必須かどうかは、公式ドキュメントだけでは確認できませんでした。インストールしたバージョンの説明と実際の移行案内に従ってください。

本番運用の注意点、記憶の誤り・肥大化・漏えいに備える

長期記憶は導入後に放置できる機能ではありません。データを継続して集め、モデルによる抽出結果を後の会話へ取り込みます。本番で使う前に、少なくとも次の6項目を確認してください。

保存期間： l0l1RetentionDaysのデフォルト値が何を意味し、自分の保存方針に合うかを確認します。
呼び出し量： maxCharsPerMemoryとmaxTotalRecallCharsで1回の挿入量を制限し、記憶がcontextを埋めないようにします。
Agentの隔離： excludeAgentsを使い、取得や呼び出しの対象にすべきでないテスト用、評価用、機密性の高いAgentを除外します。
バックアップとロールバック： データディレクトリと設定ファイルをバックアップし、ファイルがコピーされたことだけでなく、複製から復元できることを確認します。
Gatewayの安全性： スタンドアロンGatewayを使う場合は、バインドアドレス、認証、CORS、認証情報の権限を確認します。
人による確認： PersonaとScenarioを定期的に開き、古い好みを削除し、出典のない結論を調査します。

公式CHANGELOGには、scene rollback、クリーナーの安全策、呼び出し文字数の上限、Bearer認証、OpenClaw互換性に関する修正が記録されています。修正内容が公開されているのは有益です。同時に、状態の整理とネットワーク境界をデフォルト設定だけに任せるべきではないことも示しています。

さらに、機能名だけでは判断できない境界が3つあります。公式スキーマから確認できるのは、プラグインが会話を取得し、ホストLLMを呼び出し、設定に応じてローカルSQLiteまたはリモートサービスを使うことです。一方、作業領域のサンドボックスは保証されておらず、一般利用者が自分の記憶だけを閲覧できることも証明されていません。公式の設定項目とCHANGELOGには、タイムアウト、警告ログ、バックアップ、ロールバックの手がかりがありますが、すべての中断に対する自動再試行、チェックポイント、重複書き込みの防止までは確認できません。監査記録、レコード単位のエクスポート、検証可能な削除が必要なら、本番導入前にこの3点を実際に試してください。一つでも通らなければ、機密性のない隔離Agentだけで使います。

公式benchmarkの読み方と、自分で行うA/Bテスト

公式npmページには、WideSearch、SWE-bench、AA-LCR、PersonaMemを使った長時間セッションのテストが掲載され、単発のタスクではないことも明記されています。これらはベンダー自身が報告した結果です。独立した再現データは十分ではなく、「あなたのプロジェクトで必ず何トークン減る」と一般化することはできません。

ベンチマークはテスト設計として使うほうが実用的です。同じモデル、タスクセット、temperature、初期データに固定し、プラグインを無効にした場合と有効にした場合を実行します。最低でも総トークン数、タスク成功率、誤った呼び出し、人による修正回数、運用費用を比較してください。トークンが減っても、誤った記憶の修正に時間がかかるなら節約とはいえません。

導入の本当の根拠は、自分の環境で同じタスクがより安定することです。 公式の数値は試す理由にはなりますが、本番導入の判断までは代行してくれません。

最終判断、継続・拡張・ロールバック

2週間試したら、次の3つから一つを選びます。

継続： セッションをまたぐ呼び出しが安定し、誤った記憶の出典を調べて修正でき、同じ説明が実際に減った場合です。
拡張： キーワード検索が意味の言い換えを明らかに取りこぼし、データ送信と費用を許容できるならembeddingを試します。複数人での利用や容量の要件が明確になってからTCVDBを検討します。
ロールバック： 誤った記憶を管理しにくい、説明の繰り返しが減らない、またはバックアップと更新のコストが効果を上回るなら、プラグインを無効にしてシンプルなMarkdown記憶へ戻します。

ロールバックでは、まず現在の設定と記憶データをバックアップします。~/.openclaw/openclaw.jsonのmemory-tencentdb.enabledをfalseに変更し、Gatewayを再起動します。新しいセッションを開いて、取得や呼び出しが行われないことを確認してください。無効化を確認してから、アンインストールするかを決めます。既存の階層記憶をMEMORY.mdへ完全に変換する共通の移行手順は公式ドキュメントにありません。また、特定のSQLiteパスをそのまま削除してよいと判断できる十分な根拠もありません。バックアップと無効化を確認する前にデータを消さないでください。

すでにOpenClawで長いタスクを動かしているなら、機密性のない個人プロジェクト一つで2週間試してみましょう。短いタスクや時々の会話だけなら、人が読めてバージョン管理できるMEMORY.mdのほうが安心です。記憶システムの価値は、記憶量の多さではありません。何を保存したかが分かり、間違えたときに元の経路をたどれることです。