共有メモリを整理しない技術

CC BY 4.0

「簡潔に書け」は、なぜ効かなかったか

私が実際に辿った順で書きます。舞台は typingtube という個人運営の Web サービス（YouTube の音楽動画でタイピング練習ができます）で、チームではありません。それでも複数のセッションを並列実行するので、この回の症状は同じ形で出ました。

まず私は「メモは簡潔に書け。同じ対象のメモは統合しろ」をルールに書きました。AI は守りませんでした。次に太字にして、ファイルの先頭に移しました。変わりませんでした。ここまでは序論の「薄まる」で説明が付きます。

次に、保存の直前に方針を読ませて止める仕組み（保存前の hook）を置きました。これも駄目でした。保存の瞬間、AI の中では「保存を完了させる」が最優先のタスクです。その最中に差し込まれた方針は、従うべきものではなく「どう書けば通るか」の攻略対象として読まれます。実際、AI は語を言い換えるだけで、私の保存前 hook を素通りしました。

ルールが負ける相手は、序論の薄まりと、第 1 回からの染み付いた習慣だけではありませんでした。目の前のタスクとの優先順位でも負けます。しかも保存は、その優先順位が一番高くなる瞬間です。ここは、このシリーズで一番「置く場所」で結果が変わるところです。

理解したことは一文にできます。

メモリ保存は最優先で走る。だから保存前に読ませた方針は保存に負ける。方針は保存の後にしか効かない。

仕組み: 同じ方針を、保存の後に置く

置くものは同じ方針ファイルです。変えるのは位置だけ——保存が完了した後に、実際に書かれた差分と並べて AI に突きつけます。第 1 回の hook はコマンドの直前（PreToolUse）に割り込みましたが、これは完了の直後（PostToolUse）に割り込む形です。保存は済んでいるので「通したい」圧は消えていて、同じ方針が今度は「この書き込みを直すかどうか」の判断基準として読まれます。

# 保存後に差分を突きつける hook（実物からの簡約版・PostToolUse）
import difflib, glob, json, os
SNAP_DIR = os.path.expanduser("~/.claude/.memory-snapshot")  # ⚠️ 監視対象の外に置く

def added_lines(before, after):
    diff = difflib.unified_diff(before.splitlines(), after.splitlines(), n=0, lineterm="")
    return [l[1:] for l in diff if l.startswith("+") and not l.startswith("+++ ")]

def collect_changes(paths):
    # 実ファイルをスナップショットと比べる（保存コマンドの文字列は解釈しない——
    # 変数・パイプ経由の書き込みを見逃すから）。比べたら次回のために撮り直す
    changes = []
    os.makedirs(SNAP_DIR, exist_ok=True)
    for path in paths:
        snap = os.path.join(SNAP_DIR, path.replace("/", "_"))
        before = open(snap).read() if os.path.exists(snap) else ""
        after = open(path).read()
        changes += [f"{os.path.basename(path)}: +{l}" for l in added_lines(before, after)]
        open(snap, "w").write(after)
    return changes

changes = collect_changes(glob.glob(os.path.expanduser("~/.claude/projects/*/memory/*.md")))
if changes:
    print(json.dumps({
        "decision": "block",   # ツールは成功済み。これは失敗ではなく「読ませる」ための差し込み
        "reason": "Memory changed. Added lines:\n" + "\n".join(changes) + "\n"
                  "Policy: merge notes on the same subject into one / discard notes nobody read /\n"
                  "copies of steps and commands belong in documents, not in memory.\n"
                  "Judge this diff against the policy and say whether to keep, merge, or move it.\n"
                  "If you did not write it, say that it is another session's change.",
    }, ensure_ascii=False))

作りの急所は三つあります。実ファイルを比べること（保存コマンドの文字列を解釈する方式は、変数やパイプで書かれた瞬間に見逃します）。モデルに届く経路で返すこと（画面向けの通知はモデルに届かず、AI は「書き込み完了」しか受け取りません）。そして方針は数行に抑えること。「統合する・破棄する・文書へ移す」程度で止め、第二の指示ファイルに育てはじめたら、この回の意味がなくなります。

最後の 1 行にも役があります。共有メモリでは別のセッションの書き込みも差分に混ざるので、「自分が書いたものか確かめ、違えばそう言う」を方針に含めておきます。黙って他人の保存を自分の成果として扱わせないためです。

一つ残る抜け穴も言っておきます。メモリの保存はセッションの終わり際に起きがちで、突きつけた直後に AI に「あとは要約を書いて終わり」と流されると報告が落ちます。私の環境では、未報告の差分が残ったまま終了しようとしたら一度だけ引き戻す仕掛けを足しています。一度だけなのは、毎回止めるとセッションが終われなくなるからです。

CC BY 4.0 はここまで

CC BY 4.0

検証手順: 重複を保存させて、統合されることを確かめる

前提

• 保存の後に割り込む hook（PostToolUse に当たるもの）を登録し、方針ファイルを数行で置き終えていること
• セッションを 2 つ同時に立てられること——チームなら別のメンバーの端末、1 人なら同じメモリを共有する別のセッションを 2 つ開きます

所要時間: 15 分

手順

1. 1 つ目のセッションの AI に、ある対象についてメモを 1 件保存させます（「X の再起動順序は A → B」のような、あなたのプロジェクトに実在する話題で）
2. 2 つ目のセッションの AI に、同じ対象について、少し違う表現のメモを保存させます（「X を再起動したら B も必ず」）。⚠️ 語を変えてください。まったく同じ文だと、統合すべきかどうかの判断が起きません

合格条件（2 つ目のセッションの、保存した直後の応答が、すべて満たすこと）

• 保存が済んだ後に方針が届いている
• AI が統合するか、統合を提案する（「1 つ目と同じ対象なので 1 件にまとめます」）
• 突きつけられた差分の中で、1 つ目のセッションが書いた行が「別のセッションの変更」として区別されている

合格しなかったとき

• 保存の前に止まった —— それは保存前の hook です。位置が違います。⚠️ 保存の前だと、方針は「どう書けば通るか」として読まれます
• 別のセッションの変更が区別されていない —— AI は他人の保存を、自分の成果として報告します。方針に「自分が書いたものか確かめ、違えばそう言う」の 1 行を足します

後始末

• 手順 1・2 で作ったメモを、要らなければ消します。索引に足した行も一緒に消します

CC BY 4.0 はここまで