Zenn Claude Code 4layer Memory
Claude Codeに長期記憶を持たせる4層アーキテクチャ — 「毎回ゼロから説明」をやめた話
- URL: https://zenn.dev/bokuwalily/articles/f534402187bd07
- 日付: 2026-06-12
- Tier: Tier 3
- 要旨: Claude Codeのセッション間健忘問題に対し、記憶を「生ログ・揮発バッファ・確定事実・人間向けWiki」の4層に分けて一方向フローで管理する設計を実装・運用した実践記録。Stop hookでの自動ログ変換や落とし穴も詳述。
詳細
4層アーキテクチャ:
| 層 | 実体 | 役割 | 書き手 |
|---|---|---|---|
| 1 源泉ログ | ~/knowledge-base/raw/conversations/ | 全セッションの生ログ（不変・追記専用） | Stop hookスクリプトのみ |
| 2 揮発バッファ | ~/.remember/ | 直近作業の記憶。SessionStartで自動ロード | 公式rememberプラグインのみ |
| 3 確定事実 | ~/.claude/projects/<dir>/memory/ | 腐らない方針・プロフィール | Claudeが意図的に書く |
| 4 人間向けWiki | Obsidian Vault | 自分が読む整理済み知識 | Claude（ingest経由） |
原則: 下流は上流を上書きしない。食い違いは層(1)に照らして修正。
実装のポイント:
- Stop hookでJSONL→Markdown変換（tool_resultは捨てる、セッションIDをファイル名に含める）
- 層(3)はMEMORY.mdを索引にして1トピック1ファイル。腐らない情報のみ
- 層(4)のhot.mdはLLMを呼ばずに正規表現でマーカー領域に直近10セッションの表を注入（コストゼロ）
落とし穴:
- macOSのTCC問題: launchd配下でPython/git/claudeバイナリが
~/Documents等の保護領域に書けない（Full Disk Access要）。解決策: Vaultを保護領域の外に移設してsymlink - recent.mdの二重化: LLM用（
~/.remember/recent.md）と人間用（Obsidianのhot.md）は読み手が違うだけで統合しない方が良い - パイプライン死活監視:
now.mdに同一要約3回以上→consolidate遅延、索引が24時間以上古い→変換hook停止の疑い
結論: 記憶の「種類」（生ログ/揮発文脈/確定事実/人間知識）を分けて層ごとに書き手を固定することが健全な長期記憶設計の核心。