チャットとエージェント間でメモリがつながり、リアルタイムで育つようになった。だが自分のリポジトリには、すでにCLAUDE.md・journal.md・facts.jsonという"自前の記憶装置"が動いている。両者は競合しない——境界線がどこにあるかを、実際の運用ファイルで確かめる。
公式クロスアプリメモリの仕様整理と、「個人の好み」と「プロジェクトの状態」を分けて記憶するという設計原則。すでにCLAUDE.md運用をしている人が、公式メモリ機能を導入するときに何を書き足して何を書き足さないかを判断する基準。
Claudeの公式メモリ機能が、チャットとエージェント（Cowork等）で共有される形にアップデートされた。ポイントは統合そのものより、更新のタイミングが変わったことにある。
これまでのメモリは「会話が終わったあとの要約」から作られる設計だった。今回のアップデートでは、会話の途中でリアルタイムに更新される方式に変わっている。途中で話題が変わっても、その場で拾われる。
Settings > Memory から、保存された内容をトピック単位で閲覧・編集・削除できる。1件を訂正すると、以降の全会話にその訂正が反映される。ブラックボックスの推測ではなく、確認可能な状態にある。
健康・政治信条などのセンシティブな話題は保存除外がデフォルト（オプトインで変更可）。身分証番号・犯罪歴・規約違反コンテンツはそもそも保存不可の対象として明記されている。
Free/Pro/Maxの全プランでweb・デスクトップ・モバイルに展開される一方、Team/Enterprise管理者は組織単位でメモリ機能自体を制御できる。個人の裁量と組織のガバナンスが両立する設計になっている。
このブログ自体を含む副業ポートフォリオのリポジトリでは、公式メモリが来る前から自前のファイルベース運用をしている。それがCLAUDE.md（Claudeセッション向けの起点）と、そこから参照されるauto memoryディレクトリだ。
auto memoryは1件1ファイルのMarkdownで、フロントマターにtypeを持つ。種類は4つ——user（自分の役割・知識・関心）、feedback（過去に修正された・確認された進め方）、project（進行中の意思決定とその理由）、reference（外部の参照先ポインタ）。ファイル一つ一つにnameとdescriptionがあり、索引役のMEMORY.mdが1行ずつリストしている。
# memory/model-cost-policy.md の先頭（例）
---
name: model-cost-policy
description: 既定Sonnet、探す/集める系サブエージェントはhaiku指定
metadata:
type: feedback
---これとは別に、プロジェクトの状態そのものを記録する層がある。_dashboard\facts.json（期限・未決事項の単一の正）、_dashboard\journal.md（複数のAIセッション間の引き継ぎ窓口）、各プロジェクトのtimeline\events.jsonl（マイルストーンの履歴）だ。この4層分担は別記事で詳しく書いた設計そのものになる。
公式メモリとauto memory（type: user/feedback）は、実はかなり近い場所にいる。両方とも「私（ユーザー）についての恒常的な情報」を扱う。境界線を引くとしたら、その情報がアプリを横断して使いたいものか、この1つのリポジトリでだけ意味を持つものかだ。
公式メモリ＝個人の好み・繰り返し使う文脈。自前ファイル＝プロジェクト固有の運用ルール・引き継ぎ情報。前者はどのアプリを開いても自分についてくる。後者はこのリポジトリを開いたセッションだけが必要とする。
project型・reference型の記憶（進行中の意思決定、外部システムの参照先）は、公式メモリには不向きだ。理由は単純で、それらは「自分についての事実」ではなく「あるプロジェクトの状態についての事実」だから。プロジェクトが終われば陳腐化するし、他のアプリのセッションに持ち出す意味がない。逆に、user型・feedback型の一部——たとえば作業の進め方の好み——は、公式メモリと重複しうる。
仮に公式メモリだけに一本化したらどうなるか、を考えると境界線がはっきりする。答えは「引き継ぎが壊れる」。
このリポジトリはClaude・Codexという複数のAIエージェントが同じ作業ディレクトリを触る運用をしている。ある日のセッションで進めた作業を、別の日・別のエージェントのセッションが正しく引き継ぐには、そのプロジェクトを開いた瞬間に読める場所に状態が置いてある必要がある。公式メモリはユーザーに紐づく記憶であって、特定のリポジトリ・特定のエージェントに紐づく記憶ではない。Codex側のセッションが、Claude用の公式メモリを参照できる保証もない。
実際、このリポジトリの運用規約（AGENTS.md）には「状態はリポジトリ内に置く。~/.claude/配下（Claudeのメモリ）には一切書き込まない」という一文がある。これは公式メモリを軽視しているのではなく、複数エージェント・複数セッションが共有するべき情報を、特定のAI一社の記憶領域に依存させないという設計判断だ。
どのアプリを開いても、どのプロジェクトを触っていても「自分」についてくる。プロジェクトをまたいで一貫させたい好みや文脈に向く。
そのプロジェクトを開いた誰か（別のAI・将来の自分）が同じ場所を読めば、同じ状態から再開できる。ベンダーが変わっても持ち運べる。
公式メモリの進化は歓迎しつつ、すでにCLAUDE.md的な運用ファイルを持っている人が今すぐやることは、実はそれほど多くない。
メモリの置き場所が増えるほど、「どこに何を書いたか忘れる」という新しい問題が生まれる。公式メモリと自前ファイルという2層構造を意識的に維持することが、当面のいちばん実用的な対処になる。