ワークスペースメモリ v2（オフライン）: 研究ノート

対象: Clawd型ワークスペース（agents.defaults.workspace、デフォルト~/.openclaw/workspace）。「メモリ」は日次のMarkdownファイル（memory/YYYY-MM-DD.md）と少数の安定ファイル（例: memory.md、SOUL.md）として保存される。

このドキュメントでは、Markdownを正規の確認可能なデータソースとして維持しつつ、派生インデックスによる構造化された想起（検索、エンティティ要約、確信度の更新）を追加するオフラインファーストのメモリアーキテクチャを提案する。

なぜ変更が必要か？

現在の仕組み（日次1ファイル）は以下に優れている:

  • 「追記のみ」のジャーナリング
  • 人間による編集
  • git管理による耐久性と監査性
  • 低摩擦の記録（「書き留めるだけ」）

以下が弱い:

  • 高い再現率での検索（「Xについて何を決めたか？」「前回Yを試したとき？」）
  • エンティティ中心の回答（「AliceについてCastle/warelayについて教えて」）— 多数のファイルを再読み込みしないと回答できない
  • 意見/嗜好の安定性（変化した際のエビデンス付き）
  • 時間制約（「2025年11月時点で何が真だったか？」）と矛盾の解決

設計目標

  • オフライン: ネットワーク不要。ラップトップ/Castle上で動作。クラウド依存なし。
  • 説明可能: 取得した項目は出典（ファイル＋位置）が示され、推論と分離可能。
  • 低コスト: 日次ログはMarkdownのまま、重いスキーマ作業なし。
  • 漸進的: v1はFTSのみで有用。セマンティック/ベクトル検索やグラフはオプションのアップグレード。
  • エージェントフレンドリー: 「トークン予算内での想起」が容易（事実の小さなバンドルを返す）。

北極星モデル（Hindsight x Letta）

2つの要素を融合:

  1. Letta/MemGPT型コントロールループ
  • 小さな「コア」を常にコンテキストに保持（ペルソナ＋主要なユーザー事実）
  • それ以外はコンテキスト外でツール経由で取得
  • メモリ書き込みは明示的なツール呼び出し（追記/置換/挿入）、永続化後に次のターンで再注入
  1. Hindsight型メモリ基盤
  • 観察したもの vs 信じていること vs 要約したものを分離
  • retain/recall/reflectをサポート
  • エビデンスとともに進化する確信度付きの意見
  • エンティティを意識した検索＋時間的クエリ（完全なナレッジグラフなしでも）

提案アーキテクチャ（Markdownソースオブトゥルース＋派生インデックス）

正規ストア（git対応）

~/.openclaw/workspaceを正規の人間可読メモリとして維持。

推奨ワークスペースレイアウト:

~/.openclaw/workspace/
  memory.md                    # 小規模: 永続的な事実＋嗜好（コア的）
  memory/
    YYYY-MM-DD.md              # 日次ログ（追記、ナラティブ形式）
  bank/                        # 「型付き」メモリページ（安定、レビュー可能）
    world.md                   # 世界に関する客観的事実
    experience.md              # エージェントの行動記録（一人称）
    opinions.md                # 主観的な嗜好/判断＋確信度＋エビデンスポインタ
    entities/
      Peter.md
      The-Castle.md
      warelay.md
      ...

注意:

  • 日次ログはそのまま日次ログ。JSONに変換する必要はない。
  • bank/ファイルはキュレーション済みで、リフレクションジョブによって生成され、手動編集も可能。
  • memory.mdは「小規模＋コア的」のまま: 毎セッションClawdに見てほしいもの。

派生ストア（機械的想起）

ワークスペース配下に派生インデックスを追加（必ずしもgit追跡不要）:

~/.openclaw/workspace/.memory/index.sqlite

バックエンド:

  • 事実＋エンティティリンク＋意見メタデータ用のSQLiteスキーマ
  • SQLite FTS5による語彙検索（高速、軽量、オフライン）
  • セマンティック検索用のオプションのエンベディングテーブル（こちらもオフライン）

インデックスは常にMarkdownから再構築可能。

Retain / Recall / Reflect（運用ループ）

Retain: 日次ログを「事実」に正規化

Hindsightの重要な知見: 短い断片ではなく、ナラティブで自己完結した事実を保存する。

memory/YYYY-MM-DD.mdの実用ルール:

  • 1日の終わり（または途中）に## Retainセクションを追加し、以下を満たす2〜5個の箇条書き:
    • ナラティブ（ターン間のコンテキスト保持）
    • 自己完結（後で単独で意味がわかる）
    • タイプ＋エンティティメンションでタグ付け

例:

## Retain
- W @Peter: 現在マラケシュに滞在中（2025年11月27日〜12月1日、Andyの誕生日）。
- B @warelay: Baileys WSクラッシュをconnection.updateハンドラーをtry/catchで囲むことで修正（memory/2025-11-27.md参照）。
- O(c=0.95) @Peter: WhatsAppでは簡潔な返信（1500文字未満）を好む。長いコンテンツはファイルに出力。

最小限のパース:

  • タイプ接頭辞: W（世界）、B（経験/伝記）、O（意見）、S（観察/要約、通常は生成）
  • エンティティ: @Peter、@warelayなど（スラッグはbank/entities/*.mdに対応）
  • 意見の確信度: O(c=0.0..1.0) オプション

著者が考えたくない場合: reflectジョブがログの他の部分からこれらの箇条書きを推論できるが、明示的な## Retainセクションが最も簡単な「品質レバー」。

Recall: 派生インデックスへのクエリ

想起がサポートすべきもの:

  • 語彙的: 「正確な用語/名前/コマンドを検索」（FTS5）
  • エンティティ: 「Xについて教えて」（エンティティページ＋エンティティリンク付き事実）
  • 時間的: 「11月27日頃の出来事」/「先週以降」
  • 意見: 「Peterの好みは？」（確信度＋エビデンス付き）

返却形式はエージェントフレンドリーで出典を引用:

  • kind（world|experience|opinion|observation）
  • timestamp（ソースの日付、または存在する場合は抽出された時間範囲）
  • entities（["Peter","warelay"]）
  • content（ナラティブの事実）
  • source（memory/2025-11-27.md#L12など）

Reflect: 安定したページの生成＋信念の更新

リフレクションはスケジュールされたジョブ（日次またはハートビートのultrathink）で以下を実行:

  • 最近の事実からbank/entities/*.mdを更新（エンティティ要約）
  • 強化/矛盾に基づいてbank/opinions.mdの確信度を更新
  • オプションでmemory.mdへの編集を提案（「コア的」永続事実）

意見の進化（シンプル、説明可能）:

  • 各意見は以下を持つ:
    • ステートメント
    • 確信度 c ∈ [0,1]
    • last_updated
    • エビデンスリンク（支持＋矛盾する事実ID）
  • 新しい事実が到着した場合:
    • エンティティの重複＋類似性で候補の意見を検索（まずFTS、後でエンベディング）
    • 小さなデルタで確信度を更新。大きなジャンプには強い矛盾＋繰り返しのエビデンスが必要

CLI統合: スタンドアロン vs 深い統合

推奨: OpenClawへの深い統合、ただし分離可能なコアライブラリは維持。

OpenClawに統合する理由

  • OpenClawは以下を既に知っている:
    • ワークスペースパス（agents.defaults.workspace）
    • セッションモデル＋ハートビート
    • ログ＋トラブルシューティングパターン
  • エージェント自身がツールを呼び出せるようにしたい:
    • openclaw memory recall "…" --k 25 --since 30d
    • openclaw memory reflect --since 7d

ライブラリとして分離する理由

  • gateway/ランタイムなしでメモリロジックをテスト可能に
  • 他のコンテキスト（ローカルスクリプト、将来のデスクトップアプリなど）から再利用

形式: メモリツーリングは小規模なCLI＋ライブラリレイヤーとして意図されているが、これは探索段階のみ。

「S-Collide」/SuCo: いつ使うか（研究）

「S-Collide」が**SuCo（Subspace Collision）**を指す場合: 部分空間での学習済み/構造化された衝突を利用して、再現率/レイテンシのトレードオフを狙うANN検索アプローチ（論文: arXiv 2411.14754, 2024）。

~/.openclaw/workspaceへの実用的な見解:

  • SuCoからは始めない。
  • まずSQLite FTS＋（オプション）シンプルなエンベディングから。ほとんどのUX改善はすぐに得られる。
  • SuCo/HNSW/ScaNN系のソリューションは以下の場合にのみ検討:
    • コーパスが大きい（数万〜数十万チャンク）
    • ブルートフォースのエンベディング検索が遅すぎる
    • 語彙検索で再現率品質が意味のあるボトルネックになっている

オフライン対応の代替案（複雑さの順）:

  • SQLite FTS5＋メタデータフィルター（ML不要）
  • エンベディング＋ブルートフォース（チャンク数が少なければ意外と遠くまで有効）
  • HNSWインデックス（一般的、堅牢。ライブラリバインディングが必要）
  • SuCo（研究レベル。組み込める堅実な実装があれば魅力的）

未解決の問題:

  • 「パーソナルアシスタントメモリ」に最適なオフラインエンベディングモデルは？（ラップトップ＋デスクトップ環境で）
    • Ollamaが既にある場合: ローカルモデルでエンベディング。そうでなければ、ツールチェーンに小規模エンベディングモデルを同梱。

最小限の有用なパイロット

最小限でも有用なバージョン:

  • bank/エンティティページと日次ログの## Retainセクションを追加。
  • SQLite FTSで引用付き想起（パス＋行番号）。
  • 再現率の品質やスケールが求める場合にのみエンベディングを追加。

参考文献

  • Letta / MemGPTのコンセプト: 「コアメモリブロック」＋「アーカイバルメモリ」＋ツール駆動型自己編集メモリ。
  • Hindsight技術レポート: 「retain / recall / reflect」、4ネットワークメモリ、ナラティブ事実抽出、意見確信度の進化。
  • SuCo: arXiv 2411.14754 (2024): 「Subspace Collision」近似最近傍検索。
arrow_back
前へ
Session Binding Channel Agnostic
次へ
Model Config
arrow_forward