MEMORY と Docker メモリどちらから？

Exit 137 や再起動ループならリソース。プロセスが生きて遅延だけ増すなら文脈と MEMORY。

MEMORY.md はどのくらいで危険？

構造なしで 800～1200 行超は検索困難。章立てか外部化と週次マージ。

可観測性記事との違いは？

可観測性はプローブと JSONL。本稿は記憶とコンテキスト。同一 Runbook に並置。

2026 OpenClaw MEMORY.md とセッション文脈ガバナンス：Mac クラウド 7×24 の監査 Runbook

ゲートウェイが緑でも遅延・コスト・同じ確認の繰り返しは、しばしばMEMORY.md と会話コンテキストの無制御増加が原因です。本稿は誰が詰まりやすいか、層別記憶・週次マージ・ゲートウェイ JSONL との時間整合、数値目安と FAQ をまとめます。可観測性ガイド（プローブと JSONL 階段）とセットで Runbook に貼ってください。

1. 要約：静かなコンテキスト肥大

2026 年、doctor 合格とポート開放はオーケストレーションの健全性であり、プロンプトが常に瘦せていることの証明ではありません。各ターンは履歴・ツール出力・長期注入を連結します。MEMORY.md が構造なしに肥大すると検索ノイズが事実を押し潰し、遅延は会話の深さと強く相関します。運用はプロダクト衛生に近く、長期真実の所有、マージ頻度、JSONL に残すべきテレメトリの境界が要ります。以下で誤診を分解し、当番が印刷できる表と週次手順を示します。

運用者がこの平面を飛ばすと二極化します：有用な記憶を削りすぎて脆い応答になるか、会話ログを丸ごと MEMORY に流し込んで毎リクエストが高コストになるかです。短い耐久ファクト、明確な見出し、雑談の積極トリム——この中道が業務ワークフロー向け 7×24 エージェントの信頼に直結します。

2. 痛点：四つの誤診

モデル先責：十通目だけ遅いなら、まず注入規模を見てからエンドポイント交換。
繰り返し質問を知性不足とみなす：見出しのない巨大 MEMORY では方針が浮上しない。温度調整より再構成。
週次圧縮なし：追記だけの MEMORY は三ヶ月で発掘不能。プロセス欠落。
OOM と混同：Exit 137 は cgroup；プロセス生存で遅延だけ増すなら文脈面。

順序：ターンの肥満度 → MEMORY 構造 → モデル／通道。

3. 分岐表

症状	主平面	迅速な証拠	非根因になりがち
ターンごとに遅く新規スレッドは速い	セッション文脈	1 通目と 10 通目の遅延比、ツール JSON の丸ごと再掲	ベンダー遅延のみ
コスト増・出力短い	隠れた長コンテキスト	請求とログフィールドの対応	値上げ一辺倒
先週ルール破り	MEMORY 構造劣化	行数・見出し・古い節	モデル劣化
プロセス消失	リソース	終了コード・df・イベント	プロンプト
通道沈黙	ゲートウェイ	status／probe 階段	MEMORY 掃除

層の基準

耐久ファクト（監査が要る稀な変更）とセッション嗜好（捨ててよい頻繁な変更）を分ける。耐久層は見出しで固定し、一段落に詰め込まない。セッションから耐久へはレビュー付きでしか昇格させない。耐久は週次マージ、セッションはイテレーションまたはサイズ閾値でトリム。

ツール応答を会話にそのまま貼り続けるチームは、ツール JSON の要約ルール（何文字まで残すか、どのキーだけ保持するか）を先に決めると、モデル交換より遅延が下がることが多いです。複数オペレータが MEMORY を直編集する場合、週次マージの冒頭に一行チェンジログを残し、誰がセッション覚書を耐久層に昇格させたか追跡できるようにします。

4. 五ステップ

ベースライン固定：MEMORY 行数・更新時刻・長文化フラグをチケットへ。
週次マージ：章へ折り込み、矛盾削除、無題ダンプ禁止。
ドリフト監査プロンプト：有効ハードルール三件を列挙させ MEMORY と突合。
JSONL 整合：同じ時間窓で可観測性記事の順に tail。429 や spawn が静かでも遅いなら文脈へ戻る。
バックアップ：書き換え前に日付フォルダへコピーし、復元はファイル戻し＋リロード。

#!/usr/bin/env bash
set -euo pipefail
test -f MEMORY.md && wc -l MEMORY.md | awk '{print "memory_lines",$1}'
date -r MEMORY.md "+%Y-%m-%d %H:%M" 2>/dev/null || stat -f "%Sm" MEMORY.md
openclaw status 2>/dev/null | head -n 20 || true

5. 指標

設計レビューやインシデントでそのまま引用し、組織サイズに合わせて再調整してください。トークンダッシュボードを週次レビューに 5 分だけ組み込むと、エンジニアリングと財務が同じ説明軸を共有し、無制限コンテキストと緊急ハードリセットの間を行き来しにくくなります。

行数：構造なし 800～1200 行超は検索破綻しがち。章立てか外部 KB。
週 30～45 分：衛生の定例枠。
遅延比：同モデルで 10 通目 p95 が 1 通目の約 2～3 倍ならツール全量貼りを疑う。
ディスク：JSONL・バックアップ同居でも空き約 10～15GB 目安。
137：メモリ cgroup シグナル。純文脈問題は稀。
順序：リソース→ゲートウェイ→記憶。

6. Mac クラウドが記憶面に合う理由

過密 VPS のディスクジッターは巨大プロンプトに似た体感を作ります。Windows 常駐はスリープと GUI が邪魔をします。Docker はマウントと uid でパスがズレます。専用 Mac クラウドは SSH と launchd でログ・MEMORY アーカイブを一本化でき、既存の OpenClaw Mac 記事群と整合します。実験はコンテナでも、本番の記憶統制は IO と所有が読めるノードが有利で、プロンプト調整前に VPSMAC の Mac レンタルで土台を固めるのが現実的です。

Linux 汎用 VPS だけで OpenClaw を回すチームでも、記憶ファイルと JSONL を別ディスクに分け、ローテーションと空き容量アラートを先に敷けば「謎の遅さ」の半分は消えます。それでも近所ノイズを完全には排除できないとき、専用 Mac インスタンスへ移す判断がしやすくなります。