OpenClaw (Moltbot/Clawdbot) の永続メモリの仕組み

Ashley Innocent

Ashley Innocent

11 2月 2026

OpenClaw (Moltbot/Clawdbot) の永続メモリの仕組み

OpenClaw (旧Moltbot/Clawdbot)は、エージェントのUXにおける痛ましいギャップ、すなわち「継続性」を解決するため、トレンドになっています。ほとんどのアシスタントはインタラクション層でまだステートレスであるため、セッションがリセットされるたびにコンテキストが失われるように感じられます。OpenClawの永続メモリ設計は、その逆の方向性を推し進めています。つまり、有用な長期状態を維持しつつ、トークンコストの高騰や安全でないデータ保持を回避します。

これは、ハートビートループ(「まず安価なチェック、必要なときだけモデルを使用」)、nonoのような安全なエージェントサンドボックス、そしてNanobotのような超軽量の代替品との比較に関するコミュニティの議論で確認できます。中心となるエンジニアリング上の疑問は同じです。

エージェントを遅く、高価で、プライバシーリスクのあるブラックボックスにすることなく、永続的で有用なメモリをどのように維持するのか?

本記事では、OpenClawスタイルの永続メモリが、実装の詳細、トレードオフ、Apidogを使ったメモリAPIのテスト方法を含め、本番システムでどのように機能するかを詳しく解説します。

ボタン

OpenClawにおけるメモリ:実用的なメンタルモデル

システムレベルでは、OpenClawのメモリは通常、4つの層に分けられます。

一時的なコンテキスト (プロンプトウィンドウ)
現在の会話のやり取りとツールの出力。高速、揮発性、トークンに制約される。

セッションメモリ (短期)
進行中のタスク/セッションのための構造化された状態 (目標、アクティブなエンティティ、一時的な好み)。

永続的なユーザーメモリ (長期)
再起動後も維持されると期待される事実と好み (例:優先するコーディングスタック、タイムゾーン、通知習慣)。

知識メモリ (ドキュメント/タスクコーパス)
検索のためにインデックス化されたメモ、成果物、以前の作業成果物 (埋め込み + メタデータフィルタ)。

重要な詳細:すべてが永続化されるわけではありません。OpenClawは抽出とランク付けを使用し、価値が高く安定した情報のみが永続的なメモリになります。

コアアーキテクチャ:書き込みパスと読み取りパス

書き込みパス (メモリの作成方法)

堅牢なOpenClawのメモリパイプラインは通常、以下のシーケンスに従います。

イベントキャプチャ
チャットのやり取り、ツールの結果、ファイルの編集、カレンダーイベント、タスクの成果から候補となるシグナルを収集します。

候補の抽出
軽量なエクストラクタが「メモリに値する」主張を特定します。例となるクラス:

まず安価な検証
ハートビートパターンにインスパイアされ、モデル推論の前に低コストのチェックを実行します。

モデル検証 (必要な場合のみ)
不確実性が残る場合、LLM分類器を呼び出して永続性の価値と機密性のリスクを評価します。

正規化 + スキーママッピング
自由形式のテキストを型付きのメモリレコードに変換します。

競合ポリシーによるアップサート
新しさ、信頼スコア、ソースの優先度を使用して既存のレコードとマージします。

監査ログの追加
説明可能性とロールバックのために、不変の監査イベントを保存します。

読み取りパス (メモリの取得方法)

応答時:

  1. 現在のユーザーのやり取り + アクティブなタスク状態からクエリの意図を構築します。
  2. 構造化ストア + ベクターストアから候補を取得します。
  3. 関連性、鮮度、信頼度、ポリシー制約に基づいて再ランク付けします。
  4. 予算 (トークン + レイテンシ) を強制します。必要に応じて圧縮します。
  5. 選択されたメモリをシステム/開発者コンテキストに挿入します。

この分割は非常に重要です。書き込みパスは品質と安全性を最適化し、読み取りパスは関連性と速度を最適化します

データモデル:メモリレコードが含むべきもの

実用的なメモリエンティティはしばしばこのようになります。

{
  "memory_id": "mem_8f3c...",
  "user_id": "usr_123",
  "type": "preference",
  "key": "editor.theme",
  "value": "dark",
  "confidence": 0.91,
  "source": {
    "kind": "chat_turn",
    "ref": "msg_9981",
    "observed_at": "2026-01-10T09:20:11Z"
  },
  "sensitivity": "low",
  "ttl": null,
  "last_confirmed_at": "2026-01-10T09:20:11Z",
  "version": 4,
  "embedding_ref": "vec_77ad...",
  "created_at": "2026-01-01T10:00:00Z",
  "updated_at": "2026-01-10T09:20:11Z"
}

重要なフィールド:

ストレージ戦略:ポリグロット設計

OpenClawのメモリは一般的に複数のストレージから恩恵を受けます。

なぜ1つのストレージではないのか?それはワークロードが異なるためです。

一般的なパターンは次のとおりです。SQLに記録し、非同期で埋め込みを行い、その後embedding_refを介してリンクする

ハートビートとメモリの鮮度

ハートビートモデルは、最近のOpenClawの議論における最も実用的なアイデアの1つです。

常時重い推論を実行する代わりに、定期的なループは以下を行います。

  1. 安価な生存チェック
  2. 古いメモリの検出
  3. 異常時のみ高価なモデルチェックをトリガー

ハートビートタスクの例:

このアーキテクチャは、品質を維持しながらコストを劇的に削減します。また、予測可能なスケジューリング境界を作成し、可観測性とSLO管理に役立ちます。

検索ランキング:関連性だけでは不十分

堅牢なOpenClawリトリーバーは、埋め込み類似度だけでなく、以下の要素でスコア付けする必要があります。

最終スコア = 意味的関連性 × w1 + 新しさ × w2 + 信頼度 × w3 + ソース信頼度 × w4 − ポリシーペナルティ

ここで:

処理すべきエッジケース:高い関連性を持つ2つの矛盾するメモリ。
解決策:両方を含め、不確実性注釈を付けるか、明確化の質問をトリガーする。

安全性境界:データ保持、同意、サンドボックス化

永続メモリは攻撃対象領域です。ガードレールが必要です。

明示的なポリシーを持つメモリクラス

ユーザーが操作可能なメモリ制御

スコープ付き実行サンドボックス
メモリを安全なツール実行と組み合わせます (nonoのようなエージェントサンドボックスプロジェクトで議論されているように)。メモリは暗黙的に広範なツール権限を付与すべきではありません。

プロンプトインジェクション耐性
生の外部指示を、検証なしに信頼されたユーザーの好みとして永続化してはなりません。

暗号化 + アクセスログ
保存時に暗号化し、機密性の高いメモリの更新に署名し、読み書きの監査証跡を保持します。

実装の青写真 (参照API)

典型的なメモリサービスのエンドポイント:

ApidogでOpenClawメモリAPIをテストする

メモリシステムは、古い状態、競合状態、ポリシー漏洩、ランキングの劣化など、微妙な方法で障害を起こします。ここでApidogが自然にフィットします。

Apidogを使用すると、設計、デバッグ、自動テスト、モック、ドキュメントを1つのワークフローにまとめることができます。

1) まず契約を設計する

OpenAPIスキーマファーストのワークフローを使用して、メモリのエンドポイントと制約 (列挙型、機密性レベル、TTLルール) を定義します。これにより、エージェントロジックとメモリバックエンド間の乖離を防ぎます。

2) メモリの挙動に関するシナリオテストを構築する

以下のための自動化されたテストシナリオを作成します。

3) ランキング出力に視覚的アサーションを使用する

ステータスコードのチェックだけでなく、ランク付けされたフィールドとスコアの順序をアサートします。メモリのバグはしばしば「正しい応答だが、優先順位が間違っている」という形で隠れています。

4) 依存するツールをモックする

アップストリームのシグナル (カレンダー/タスクツール) にはスマートモック応答を使用し、抽出パスを確定的に再現できるようにします。

5) CI/CD品質ゲートを追加する

メモリのスコアリングやポリシーが変更されるたびにリグレッションスイートを実行します。ランキングの品質が低下したり、ポリシーチェックが失敗したりした場合は、デプロイをブロックします。

6) 内部メモリAPIドキュメントを自動生成する

永続メモリは、バックエンド、QA、セキュリティ、および製品チームに関わります。インタラクティブなドキュメントは、調整のオーバーヘッドを削減し、期待される動作を迅速に明確にします。

よくある障害モードとそのデバッグ方法

1. メモリの肥大化

症状: 数週間にわたってレイテンシとトークン使用量が増加する。
修正: TTLのデフォルト設定、コンパクションジョブ、より厳密な抽出閾値。

2. 好みの動揺

症状: アシスタントが矛盾するユーザーの好みの間で揺れ動く。
修正: 影響の大きい更新には確認を求め、安定したメモリを置き換える前にヒステリシスを追加する。

3. 静かなポリシー違反

症状: 機密データが検索コンテキストに表示される。
修正: 永続化前と検索前の両方でポリシーエンジンを適用し、レッドチームテストを追加する。

4. 検索の無関係性

症状: 意味的には似ているがタスクとは無関係なメモリがコンテキストを支配する。
修正: タスクを意識した再ランク付け機能とメタデータフィルタリングを強化する。

5. 同時書き込み競合

症状: 複数のワーカーが同じユーザーの流れを処理する際に更新が失われる。
修正: 楽観的ロック (`version`)、決定論的なマージキー、および冪等性トークン。

OpenClaw vs 軽量な代替品:メモリのトレードオフの概要

Nanobotのようなプロジェクトは、正当なトレードオフを浮き彫りにしています。より小さなシステムは高速で理解しやすいですが、永続的なパーソナライゼーションの深さを犠牲にすることがよくあります。

OpenClawの価値提案は、時間の経過とともに強化される継続性とエージェントの有用性です。その代償は、より複雑になることです。

ユースケースが短期的な自動化であれば、軽量な方が有利かもしれません。長期にわたって機能が積み重なるアシスタントの挙動が必要な場合は、永続メモリアーキテクチャにエンジニアリング投資する価値があります。

最終的なポイント

OpenClawの永続メモリは、以下の3つの原則がバランスしている場合に機能します。

  1. 選択的永続化 (少なく保存し、より良く保存する)
  2. コストを意識したオーケストレーション (まず安価なチェック、必要なときにモデル呼び出し)
  3. ポリシー優先の安全性 (同意、保持制御、監査可能なアクセス)

メモリをプロンプトのトリックとしてではなく、ファーストクラスのサブシステムとして扱ってください。契約を定義し、ランキングの挙動をテストし、ポリシーゲートを強制し、時間の経過による乖離を監視してください。

このスタックを実装する場合、ApidogはメモリAPIの標準化、シナリオベースのリグレッションテストの実行、アップストリームツールのモック、そして同じ信頼できる情報源からの内部ドキュメント公開を支援します。無料で試して(クレジットカード不要)、本番ユーザーに提供する前にメモリサービスを検証してください。

ボタン

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる