OPENCLAW_2026
MEMORY_
TOKEN_
CONTEXT_RUNBOOK.

// 課題:OpenClaw は応答するのに、スレッドが重くなったり古い前提が事実のように出たり、アップグレードのたびに記憶が飛んだように感じる。多くは MEMORY.md と workspace の境界が曖昧、取得がノイジー、隠れたプレフィックスによるトークン圧迫 が重なった結果です。要点メモリの層別マトリクス五ステップの導入、引用可能な閾値、トークン肥大の診断ラダーリモート Mac Gateway のパスと環境の整合です。構成:課題|マトリクス|手順|閾値|ラダー|FAQ|深掘り|可観測性|証跡|まとめ|補遺。関連:移行と再ペアリング無応答 Gateway ランブックGateway の常時稼働MCP のトークン予算オンボードとデーモンリモートデプロイ

自動化エージェントとナレッジワークフローのイメージ

1. 痛みの分解:メモリは「Markdown を増やす」ことではない

(1)境界の漂流:ログや下書き、安定した設定をすべて MEMORY.md に流し込むと、古い仮定が事実として取得されます。workspace 内の製品ドキュメントを「ペルソナ記憶」と混ぜると層が汚染されます。(2)取得ノイズ:素朴なキーワードや粗いチャンク分割では、似た語句だが別判断が合体し、モデルが誤ったスパンを「覚えた」ように振る舞います。(3)トークン肥大:システムプロンプト、チャネル別ルール、ツール JSON、MCP スキーマ、メモリ断片は同一予算を共有します。遅延の跳ね上がりは、ユーザーに見えるチャットより隠れたプレフィックス側に原因があることが多いです。doctor やチャネルが健全でも遅延が増えるときは、モデル交換の前にコンテキストを監査してください(ラダーは 無応答 Gateway の記事と併せて使います)。(4)リモート上のパスずれ:リモート Mac Gateway では ~/.openclaw と workspace が、手元ノート PC の感覚と一致しません。別ユーザーで編集したあとに「記憶喪失」に見えるのは、移行で扱うクラスの不整合です。

2. 層別:どこに何を置くか

保持するもの アンチパターン
長寿命の設定・用語集 安定した事実、組織用語、承認境界 一回きりの結論を昇格させる;版や日付がない
プロジェクト workspace 文書 版管理された設計、API 契約、ランブック 秘密情報、Cookie、webhook 秘密を平文で混在
セッション/短期バッファ スレッドの目的、未解決の問い、ツール中間結果 要約や TTL なしで無制限に増やす

3. 五ステップの導入

  1. MEMORY の契約を公開する:自動追記と人間ゲートの境界を決め、長期エントリにはスコープ(チャネル/プロジェクト)と最終確認日を付けます。
  2. 取得ゲートを固定する:まずチャネル/ディレクトリで絞り、その後にベクトル/キーワードへ進みます。ライブラリ全体をデフォルトで掃く動きは禁止します。
  3. ローリング要約を版管理する:要約に世代とハッシュを載せ、アップグレード後は重複注入がないか差分で確認します。
  4. ツール面を狭くする:タスクに必要なツールだけを公開し、スキーマや例示がプレフィックスコストを膨らませないようにします(MCP ランブック)。
  5. リモート環境を揃える:launchd で HOMEPATH、秘密のパスを明示し、再起動後にメモリの読み書きスモークを回します(オンボードガイド)。
# 提案する memory_record フィールド(スタックに合わせて調整) # { "scope": "channel:slack:xxx", "verified_at": "2026-04-11", # "source": "human|tool|import", "text": "...", "supersedes": "id-or-hash" }

4. 引用可能な閾値

社内メモにそのまま書ける数値(自社ログで再計測してください):

  • ツール返却+メモリ断片が合算でモデルウィンドウに対して例えば約 8k トークンを常習的に超え、p95 遅延が跳ねるなら、行を増やす前にツールを削るか取得を段階化します。
  • ローリング要約が同一結論を三回以上同系統のターンに注入するなら、重複排除が欠けているか、要約の世代が二重に載っている疑いがあります。
  • 三時間超を「誤記憶/コンテキスト爆発/アップグレード後の忘却感」に費やすなら、メモリと Gateway 設定をリリースゲートに上げ、MEMORY を手編集し続ける運用から抜けます。

5. トークン肥大の診断ラダー

見る場所 典型の根本原因
1) プレフィックスのプロファイル システムプロンプト、チャネルルール、固定の免責 マルチチャネル用ブロックをコピペで重複
2) ツールと MCP 呼び出しごとのペイロード、入れ子 JSON ページングなし、フィールド投影なし、スキーマが広い
3) メモリ取得 Top-K と断片あたりの上限 スコアが低いチャンクを「念のため」注入
4) セッション要約 ターン数に対する増加率 切り詰め・統合・失効ポリシーがない

6. FAQ:自己改善、チャネル、リモート Mac

Q: 自己改善の自動書き込みをそのまま適用してよいか。 人間ゲートを推奨します。低リスクは自動、高リスクはレビューに分けないと、誤りが「組織の記憶」に固定されます。

Q: 全チャネルでメモリプールを共有してよいか。 コンプライアンスとノイズで分割します。サポートとエンジニアリングが、メタデータフィルタなしで同一ベクトル空間を共有するのは避けます。

Q: リモート Mac 上のパスは何を信じるか。 SSH しているアカウントではなく、Gateway プロセスのユーザーの HOME を正とします。

Q: アップグレード後に記憶が飛んだように見える。 状態ディレクトリと workspace を plist やコンテナ移動とあわせて差分し、移行Gateway のロールバック手順を参照します。

7. 深掘り:チャットから運用へ

2026 年のエンタープライズ向けエージェントは、監査可能な記憶と予測可能なコンテキストで評価されます。セキュリティは、どの行が個人でどれが組織か、削除やエクスポートができるかを問います。スコープと保持期間が契約に無いと、ファイル削除だけで場当たり的に直すことになります。

エンジニアリングでは、メモリは RAG と境界が溶けやすいです。片側は Markdown、片側はベクトルという二層で、二重書き込みのずれが典型障害です。MEMORY は更新したのにインデックスを再構築していないと、取得は古いスパンを引き続けます。レビューでは単一の正か、再構築ランブックのどちらかを要求します。

24/7 の Gateway ホストとしてのリモート Mac では、ディスクとバックアップが絡みます。スナップショットは ~/.openclaw と workspace を含める必要があります。リストア後にメモリ索引を再構築するかは、可用性方針で決め、リモートデプロイで述べる安定性の考え方と同じ軸に置けます。

Gateway では、メモリ行数上限、行あたりバイト上限、劣化動作(取得タイムアウト時はセッション要約のみへフォールバック)を決め、テール遅延を説明可能にします。運用チームが「いつも遅い」と感じる前に、メトリクスでプレフィックスとツールと取得の内訳を見える化しておくと、インシデント時の切り分けが速くなります。

8. 可観測性

リクエストごとにログへ、注入メモリ件数とトークン空ヒット率ツール名別のペイロード p95要約の書き換え回数を残します。四指標が同時に漂い始めたら設定ドリフトを疑い、遅延だけが増えてメモリ件数が安定ならツール/MCPを疑います。

シグナル 取り方 疑う箇所
メモリ注入トークン 構造化したリクエストログ Top-K が広い、スパンが長い、重複排除なし
取得ヒット率 時間帯ごとのゴールデン質問 索引が古い、スコープフィルタが誤り
ツールペイロードサイズ ツール別パーセンタイル ページングなし、応答にトレースログを混在

9. 証跡パック

スクリーンショットだけでは足りません。MEMORY 契約の版取得パラメータ表アップグレード前後のプレフィックス差分期待する記憶があるのに失敗したスレッドを揃えます。失敗例のないレビューは、本番トラフィックの一週目を越えにくいです。社外ベンダへ渡す場合も、再現手順とログマスク方針を同梱すると往復が減ります。

10. まとめ:開発用ノート PC は寛容だが、本番は予測可能性が要る

(1)限界:デフォルトのメモリ方針はノイズを増やしやすく、ツールと MCP はプレフィックスを膨らませ、マルチチャネルとリモートパスはドリフトします。

(2)リモート Mac の利点:固定ユーザーと plist、統一したスリープとバックアップ姿勢、他の OpenClaw ガイドと同じ macOS 上の挙動です。

(3)MACGPU:Apple Silicon のレンタブルなリモートノードと、ログイン不要で辿れるヘルプ入口があり、変則な VPS スタックを抱えずに Gateway ホスティングを検討できます。下の CTA からプランとヘルプへ進めます。

11. 補遺:サブエージェントとスケジュール

サブエージェントやスケジュール実行では、親セッションと分岐セッションの書き込み所有者を定義し、同時更新による MEMORY の破損を防ぎます。重い取得はワーカーへオフロードし、Gateway のオーケストレーション側は狭いツール面のままにします。Webhook や無人実行の設計は、トリガー設計がメモリと結びつくため、本稿の層別ルールと整合させてください。