mjcreativelab memory dream（記憶の整理 / consolidation）
git 管理された記憶階層を定期的に再編し、重複・矛盾・陳腐化を除去する作業の手順書。Anthropic Managed Agents の Dreams（Claude Code では Auto Dream / /dream）を、これらが使えない環境（手動・git ベースの記憶階層）で再現する。
引数の解析
$ARGUMENTS を解析する:
--codex-review-loopまたは-cdxrl→{レビューモード}=standard、{レビュー系統}=codex--claude-review-loopまたは-cldrl→{レビューモード}=standard、{レビュー系統}=claude- 両方指定された場合 →
{レビュー系統}はcodexを優先し（別系統モデルの独立性がより高い）、その旨を 1 行通知する - 指定がない場合 →
{レビューモード}はoff
例: /memory-dream --codex-review-loop → レビューモード: standard、系統: codex
例: /memory-dream -cldrl → レビューモード: standard、系統: claude
これは何か / なぜ必要か
エージェントはセッションごとに記憶へ追記する。追記は局所的・増分的なので、20〜30 セッションを超えると memory store に重複・矛盾・陳腐化エントリが溜まり、ノートが「思い出す助け」から「混乱させるノイズ」へ転落する（相対日付の意味喪失、削除済みファイルを指す古い手順など）。
Dreams は人間の REM 睡眠による記憶定着のメタファ。過去セッションと既存 store を読み、重複をマージ・古い/矛盾する値を最新で置換・繰り返しパターンを簡潔な知見として抽出した新しい store を生成する。本家 API では入力 store を決して書き換えず、出力は別 store としてレビューしてから採用する（opt-in）。
原則
- 入力非破壊: 変更は論理単位ごとの commit に分離し、revert 可能な状態を保つ。push はユーザーの明示指示まで保留する
- 採用前レビュー必須: consolidation の出力には hallucination が混入しうる。commit をユーザーがレビューしてから採用する（
{レビューモード}がstandardの場合は、その前段に独立レビューループ〔codex 系 / claude 系〕を挟む） - 記憶の再編であって fine-tune ではない: 変わるのは外部記憶のみ。モデルは変わらない
Phase 0: 対象階層の確認（ゲート）
以降のフェーズに進む前に、次をすべて満たすこと。
- 記憶階層のルートを特定する。環境の常時ロード指示（AGENTS.md / CLAUDE.md / MEMORY.md 等）が記憶階層とその場所を定義していれば、それに従う。特定できない場合はユーザーに確認して止まる（推測で進めない）
- ルートが git 管理下であり、
git status --shortが clean であることを確認する。未コミット変更が残っている場合はユーザーに扱いを確認する - レイヤ一覧と各レイヤの役割（ロード順・更新可否）を列挙し、
更新禁止のレイヤを対象外として明示する - 確認結果（記憶階層ルートの絶対パス・開始時 HEAD の commit hash・レイヤ表と対象/対象外）を
${TMPDIR:-/tmp}/memory-dream-inventory.mdに書き出す。このファイルが無い状態で Phase 1 以降へ進まない（物理ゲート）
構成例（agents-share 環境。上 5 行は毎セッション自動ロードされる順、末尾 2 行は on-demand・参照時のみ）:
| レイヤ | 役割 | dream での扱い |
|---|---|---|
AGENTS.md |
世界のルール（最上位） | 更新禁止。対象外、ただしルールの定義元として参照する |
MEMORY.md |
チーム共通知識 | 対象 |
auto-memory/MEMORY.md（索引）+ auto-memory/*.md |
索引 + 関連時に想起される個別記憶 | 対象（索引は 1 ファイル 1 行のフック） |
session-start で読む notes（例: notes/ghq.md, notes/specs.md） |
起動時ロードのメモ | 対象 |
projects/<project>.md |
プロジェクト固有 | 対象 |
notes/*.md（on-demand） |
随時参照のメモ | 対象 |
specs/ |
設計文書（プロジェクト固有） | 原則触らない（ルール重複の対象外） |
4 フェーズ手順
Phase 1: Mine（採掘）
前提: ${TMPDIR:-/tmp}/memory-dream-inventory.md が存在すること（無ければ Phase 0 へ戻る）。
直近セッションの transcript や作業内容から、繰り返し出た指摘・確定した方針・新事実を抽出する。
- transcript の場所は環境による（例: Claude Code は
~/.claude/projects/<project>/、Codex は~/.codex/sessions/）。参照できない場合は、現在の会話と既存記憶の内部矛盾だけを材料にする - 一回限りのデバッグメモは拾わない
Phase 2: Consolidate（統合）
抽出物を既存記憶へマージする。
- 相対日付（「昨日」等）は絶対日付に変換する。基準日（そのメモが書かれた日）は
git log -p -- <file>やgit blameで当該行が追記された commit 日時から特定する。特定できない場合は変換せず、真の矛盾と同様にユーザー確認（Phase 3）へ回す - 矛盾は最新の値で解決し、古い記述を置換する。新旧は git 履歴（当該行の追記日時）で判定する
- 存在しないファイル・関数・フラグを指す記述は、参照先がどのリポジトリ・パスを指すかを特定してから現存確認し、更新するか除去する。参照先にアクセスできない・特定できない場合は除去せず、そのまま残すかユーザーに確認する
- 編集のたびに
git diffで実差分を確認する（ツールの成功応答は「意図どおり書けた」ことを保証しない）。環境によっては記憶ハーネスが Write/Edit 時にファイルを自動書き換えする。実例: Claude Code の auto-memory（~/.claude/projects/<project>/memory/）は frontmatter を再付与し、node_type: memoryを復活させoriginSessionIdを現行セッション ID で上書きする。この環境では frontmatter の正規化（node_type / originSessionId の除去）は不可能なので対象外とし（ハーネス管理のスキーマとして受容）、本文編集で汚染されたoriginSessionIdは編集後に Bash（perl -pi等、ツール書き込みを経由しない経路）で開始時 HEAD の値へ復元する
Phase 3: Dedup & Resolve（重複排除・矛盾解消）
階層をまたいだ重複を除去する。
- 最重要原則: 上位レイヤが定めるルールを下位で再掲しない。 下位は重複を黙って消し、そのレイヤ固有の知見だけ残す（残し方は後述「成果ファイルの書き方」に従う）
- どちらが正か判断できない真の矛盾はユーザーへ確認する（Claude Code では
AskUserQuestion、他エージェントではテキストで確認する）
Phase 4: Prune & Index（剪定・索引化）
索引（
MEMORY.md系。存在するもののみ）は lean に保つ（目安 200 行未満）冗長な節・完了済みで価値のない記述を削除する。削除で内容がすべて失われたファイル（完了済みプロジェクトのメモ等）はファイルごと削除してよい（commit で revert 可能）。削除したら索引・notes 一覧からも除去する
notes/ディレクトリがある環境では、MEMORY.mdの「notes 一覧」セクションを毎回再生成して同期する（差分がなければ no-op。セクションが無ければ新設する）。notes は階層化され on-demand では発見されにくいため、常時ロードされるMEMORY.mdに全パスを置く:# 記憶階層ルートで実行し、出力で「notes 一覧」セクション内のコードブロックを置換する find notes -type f -name '*.md' | sort
論理単位の編集が完了するたびに commit する（複数フェーズが同一ファイルを触るため、フェーズごとに commit を挟むとよい）。全フェーズ完了後、チェックリストで自己検証し、{レビューモード} が standard なら「レビューループ（codex 系 / claude 系）」を実施してから、ユーザーへレビューを依頼する（push はしない）。
重複排除の判定ルール
- 重複は常に「下位 → 上位」方向で発生する。修正は下位レイヤ側で行い、最上位レイヤ（AGENTS.md 等・自己整合）は触らない
- 各情報の定義箇所を一つに保つ。上位が定めるルールは下位から単に消す。必要なら手順の所在だけを 1 句で指す（例: 「PR 本文は
notes/playbook/github-pr.mdに従う」） - ディレクトリ構造・コミット運用・記憶貢献ルールなどの「世界のルール」は最上位レイヤが定める。notes / projects には固有情報のみ書く
成果ファイルの書き方（重要）
判断のメタと経緯はこの playbook 側に置き、成果ファイル（MEMORY.md / projects / notes）には書かない。成果ファイルから除くもの:
- 重複回避の注記（「これは X が定める、ここでは重複させない／再掲しない」等のメタ説明）。重複は黙って消すだけでよい
- 経緯・履歴（Why: 行、失敗談、「繰り返し外している」「同じ指摘を N 回受けた」、学習日・セッション ID など）
残すのは、現行で正しい知見・ルール・再現手順だけ。理由が行動を変える技術的因果（「A だと B が壊れるので C する」）は知見の一部として残してよいが、誰がいつ何を指摘したかは残さない。
例外: 環境の常時ロード指示が成果ファイルの書式を明示的に定めている場合（例: feedback メモに Why: を必須とする運用）は、そちらを優先する。
チェックリスト
ユーザーへレビューを依頼する前（{レビューモード} が standard の場合はレビューループの前）に全項目を確認する:
- 相対日付をすべて絶対日付へ変換した（基準日は git 履歴で特定。特定できないものは変換せずユーザー確認へ回した）
- 上位が定めるルールを下位から削った（重複回避の注記自体も残していない）
- 成果ファイルから経緯・履歴（Why / 失敗談 / 再発回数 / 学習日 / セッション ID）を除いた
- 矛盾を最新値で解決した（曖昧なものはユーザー確認済み）
- 存在しないファイル・シンボルへの参照を、参照先リポジトリで現存確認のうえ更新 or 除去した（確認できないものは残した）
- 索引（
MEMORY.md系。存在するもののみ）が lean（目安 200 行未満） -
notes/がある環境では「notes 一覧」を再生成・同期した - 編集ごとに
git diffで意図した差分だけが入ったことを確認した（記憶ハーネスの自動書き換え〔frontmatter 再付与・originSessionIdの現行セッション ID 上書き等〕を検出し、汚染があれば開始時 HEAD の値へ復元した） -
git diff --name-only <開始時 HEAD>..HEADの出力に更新禁止レイヤ（inventory で列挙したもの）が含まれないことを確認した - 変更を論理単位ごとに commit した（push はしていない）
- ユーザーレビューを経てから採用する（dream 出力は hallucination 混入の懸念があるため鵜呑みにしない）
レビューループ（--codex-review-loop / --claude-review-loop）
{レビューモード} が standard の場合、チェックリストの自己検証後・ユーザーへのレビュー依頼前に実施する。目的は dream 実施の文脈から独立したレビュー。codex 系は別系統モデル（Codex）が、claude 系はコンテキスト隔離した Sonnet エージェント（effort max）がレビューを担う。Claude 自身（オーケストレーター）がレビューを模擬・代行してはならない。返ってきた指摘の採用 / 不採用（過剰対応かどうか）の判定は、いずれの系統でもレビュイーである Claude（オーケストレーター）が行う。
- レビュー取得 —
{レビュー系統}に応じて取得する:- codex 系 — assets/codex-review-prompt.md のテンプレートを埋め、Skill ツールで
codex:rescueを呼び出す。Codex が dream の全差分（git diff <開始時 HEAD>..HEAD）を記憶階層の git 履歴と照合してレビューする - claude 系 — 雛形
md-dream-review（references/agent-orchestration.md）を Workflow ツールで起動する（1 起動 = 1 ラウンド。レビュー観点は codex 系と同一）。返却がstatus: 'agent-failed'の場合は 1 回だけresumeFromRunIdで再開し、それでも失敗ならフォールバック（claude 系）へ
- codex 系 — assets/codex-review-prompt.md のテンプレートを埋め、Skill ツールで
- 妥当性判定 — 指摘を 1 件ずつ「採用 / 不採用」に分類する。不採用（妥当性がない・過剰対応・スコープ外）の理由は 1 行で記録する
- 修正 — 採用指摘を反映し、修正 commit を積む（既存 commit は書き換えない）
- 収束判定 — 採用が 0 件ならループ終了（収束）。1 件以上なら手順 5（上限チェック）へ進む（必ず上限チェックを経由する。直接手順 1 へ戻らない）
- 上限チェック — ラウンド数が 3 の倍数（3, 6, …）に達したら、残指摘の要約を提示して AskUserQuestion で「続行 / 打ち切り / 中止」を確認する。達していなければラウンドを +1 して手順 1 へ戻る
ループが収束・打ち切りとなっても、ユーザーの採用前レビュー（原則 2）は省略しない。レビュー依頼時に系統・ラウンド数・採用/不採用件数の要約を添える。
claude 系の独立性はコンテキスト隔離で担保する（レビュワーは dream を実施していない fresh エージェント）。codex 系のような別系統モデルの独立性はないため、利用できる環境では codex 系を推奨する。
フォールバック（codex 系: codex:rescue 利用不能時）
以下のいずれかに該当する場合に実施する:
- 呼び出し不能 — Codex プラグイン未導入・Codex CLI 未設定・他エージェント環境などで
codex:rescueが呼び出せない - 復旧不能なハング — レビューが返らず（silent death）、assets/codex-review-prompt.md の「運用ノート」に従った復旧（cancel →
--resume再投入）を 2 回試みても完了しない（ハング時は即フォールバックせず、必ず先に復旧を試みる）
該当した場合:
- Claude 自身でレビューを代行しない
- claude 系へ勝手に切り替えない（ユーザーは別系統モデルのレビューを選んでいる）。「Codex レビュー未実施」とユーザーに明示し、必要なら
-cldrlでの再実行を案内して、通常どおりユーザーの採用前レビューへ進む
フォールバック（claude 系: Workflow 利用不能時）
Workflow ツールが無い環境、または resumeFromRunId での再開後も status: 'agent-failed' の場合:
- Claude 自身（オーケストレーター）でレビューを代行しない
- 「Claude レビュー未実施」とユーザーに明示し、通常どおりユーザーの採用前レビューへ進む
いつ実施するか
- 大規模リファクタ直後（リネーム多数・フレームワーク移行・API 構造変更）— 古いエントリが混乱を増やすため最優先
- セッション数の蓄積時 — 本家デフォルトの目安は 24h かつ 5 セッション以上、実務的には 20〜30 セッションでノイズ化する
- ユーザーが「記憶を整理して」「dream して」と指示したとき
参考
- Dreams — Claude Platform Docs（公式。
managed-agents-2026-04-01+dreaming-2026-04-21beta header、最大 100 セッション） - What Is Claude Dreaming? (MindStudio)
- Claude Code Dreams: Auto Dream guide (Supalaunch)
- Auto-dream mechanics (claudefa.st)
- grandamenium/dream-skill（4 フェーズ consolidation の OSS 再現）