自動メモリの保存先変更とオフ設定 — autoMemoryDirectory/Enabled
Claude Codeの自動メモリはsettings.jsonのautoMemoryDirectoryとautoMemoryEnabledで保存先変更とオン/オフを制御できます。--bareや環境変数との優先順位もまとめます。
Claude Codeの自動メモリは、既定ではプロジェクトごとに~/.claude/projects/<project>/memory/へ保存されます。保存先を変えるのがautoMemoryDirectory、自動メモリ自体を止めるのがautoMemoryEnabledです。どちらもsettings.jsonに1行足すだけで効き、スコープはAny fileなので、ユーザー・プロジェクト・ローカル・管理設定のどこに書いても読まれます。
自動メモリの保存先を変えるには
autoMemoryDirectoryには、絶対パスか~/で始まるディレクトリパスを文字列で指定します。未設定なら既定のプロジェクト別ディレクトリが使われます。
{
"autoMemoryDirectory": "~/my-memory-dir"
}読み込み元はuser・project・local・policyの各設定に加えて、--settingsで渡した設定ファイルです。
保存先の中身は、索引のMEMORY.mdと、メモリ1件につき1つのトピックファイルです。トピックファイルは起動時には読まれず、Claudeが必要になった時点で通常のファイル操作ツールで読みます。
~/.claude/projects/<project>/memory/
├── MEMORY.md # 索引。1メモリ1行
├── user_role.md # トピックファイルの例
├── feedback_testing.md # トピックファイルの例
└── ... # Claudeが作成するその他のトピックファイルトピックファイルのfrontmatterには、メモリの種類を示すtypeが入ります。種類は4つです。userは役割や得意分野、feedbackは受けた訂正と了承された進め方を指します。projectはコードやGit履歴から導けない進行中の作業や決定、referenceは課題管理やダッシュボードなど外部の参照先です。コードベースから導ける設計やファイルパス、CLAUDE.mdに書いてある内容は保存の対象外とされています。
MEMORY.mdの読み込み上限
セッション開始時に読まれるのは、MEMORY.mdの先頭200行か25KBの、先に届いたほうまでです。超えた分は起動時には読み込まれません。書き込みのたびに上限に対する大きさが測られ、近づくとClaudeに短くするよう促すメッセージが返ります。上限を超えていても書き込み自体は成功しますが、次の読み込みでは超過分が落ちるため、索引を書き直すよう求めるエラーが返ります。
この上限はMEMORY.mdだけに掛かります。CLAUDE.mdは4MiBまで全文を読み込み、それより大きいファイルは読み飛ばします。
保存先が変わらない・共有されない場面
自動メモリの<project>はGitリポジトリから導かれるので、同じリポジトリのworktreeやサブディレクトリはどこから起動しても1つのディレクトリを共有します。「worktreeごとにメモリが別れる」という事態は既定では起きません。ファイルはmachine-local(その端末に固定)で、別のマシンやクラウド環境には共有されません。
複数プロジェクトのメモリを1か所に集めたいなら、CLAUDE_CONFIG_DIRとCLAUDE_CODE_PROJECT_DIR_NAMEの組み合わせが使えます。両方を設定すると、どのリポジトリで起動しても<config dir>/projects/<指定した名前>/が使われます(v2.1.234以降)。その設定ディレクトリを使う起動は、1つの自動メモリを共有します。CLAUDE_CONFIG_DIRが未設定だとCLAUDE_CODE_PROJECT_DIR_NAMEは無視されます。
Gitリポジトリの外で起動した場合は、リポジトリの代わりにプロジェクトルートから<project>が決まります。
古いセッションのtranscriptはcleanupPeriodDaysの保持期間で削除されますが、メモリディレクトリ内のファイルはこの掃除の対象外です。--bareは自動メモリを読み書きしないだけで、ファイルを消す操作ではありません。
プロジェクト設定に書くときの信頼ルール
autoMemoryDirectoryを.claude/settings.jsonや.claude/settings.local.jsonに書くと、hooksと同じワークスペース信頼ルールで扱われます。クローンしたリポジトリが設定ファイルを同梱している可能性があるためです。
もう1つ条件があります。permissions.blockReadsOutsideWorkingDirectoriesがオンの間は、自動メモリの扱いが変わります。リポジトリが持ち込んだ設定ファイルの指す保存先からは、読み込みも保存もされません。保存先がどこにあっても同じです。チームのリポジトリにautoMemoryDirectoryを含めるときは、この2つの条件を踏まえて動作を確かめる必要があります。
自動メモリを止めるautoMemoryEnabled
autoMemoryEnabledはBoolean型で、既定はtrueです。falseにすると、自動メモリのディレクトリからの読み込みも書き込みも止まります。特定のプロジェクトだけで止めたいなら、そのプロジェクトの設定に書きます。
{
"autoMemoryEnabled": false
}trueや未設定は「常にオン」ではありません。--bare・safe mode・CLAUDE_CODE_DISABLE_AUTO_MEMORYのように、このキーより優先されるものが無効化していれば、そのセッションではオフのままです。
設定ファイルを開かずに切り替えるなら、セッション内の/memoryです。トグルを操作すると、ユーザー設定のautoMemoryEnabledが書き換わります。/memoryはCLAUDE.mdの編集、保存済みの自動メモリの一覧表示、自動メモリフォルダを開く操作も兼ねています。保存の動きは、画面に「Saved 2 memories」「Recalled 2 memories」のような表示でも出ます。
トグルでオンに戻せないセッション
/memoryのトグルがオフにしかできないセッションがあります。バックグラウンドセッションと、別のClaude Codeセッションが起動したセッション(ClaudeがBashツール経由でclaudeを実行した場合など)です。こうしたセッションでは、トグルにoff · can't be turned on here; use a session started outside Claude Codeと表示されます。オンに戻すには、ターミナルでclaudeを直接起動し、その中で/memoryのトグルを使います。
セルフホスト環境のセッションは、Claude Tagのセッションを除き、既定で自動メモリがオフです。
組織で一律に止めたい場合
autoMemoryDirectoryとautoMemoryEnabledは管理設定(managed settings)にも書けます。組織として自動メモリを止める、あるいは保存先を固定するときは、管理設定に配布する形になります。
ただし、autoMemoryEnabledは環境変数CLAUDE_CODE_DISABLE_AUTO_MEMORYより下の位置にあります。組み合わせごとの結果は、次の節の表のとおりです。
起動オプションと環境変数が優先される場面
自動メモリの有効・無効は、設定キーだけでは決まりません。次の表は、それぞれの状態での結果と、どう上書きできるかです。
| 状態 | 自動メモリ | 上書き |
|---|---|---|
| 未設定 | 自動メモリ有効 | 上書きautoMemoryEnabled: false、--bare、--safe-modeで無効になる |
autoMemoryEnabled: false | 自動メモリ無効 | 上書きCLAUDE_CODE_DISABLE_AUTO_MEMORY=0でそのセッションだけ有効にできる |
--bare起動 | 自動メモリ無効 | 上書きCLAUDE_CODE_DISABLE_AUTO_MEMORY=0でそのセッションだけ有効にできる |
--safe-mode起動 | 自動メモリ無効 | 上書きautoMemoryEnabledの値より優先される |
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 | 自動メモリ無効 | 上書きautoMemoryEnabledの値より優先される |
値を0のまま環境に残していると「オフにしたのにオンのまま」という状態になります。
止め方の使い分け
設定キー
autoMemoryEnabledをfalseにします。次回以降の起動にも残ります。
環境変数
CLAUDE_CODE_DISABLE_AUTO_MEMORYをその回の起動にだけ渡します。設定ファイルは変わらないので、次の起動には影響しません。
settings.jsonでfalseにしたまま、この起動だけ有効に戻すなら、次のように渡します。
CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 claude--bareと--safe-modeの違いは--helpの文面にも出る
どちらも自動メモリを止めますが、目的が違います。--bareはスクリプト呼び出しを速く起動するための最小モード、--safe-modeは設定が壊れているときに全カスタマイズを無効にして切り分けるモードです。--bareはCLAUDE_CODE_SIMPLE=1を立てます。--safe-modeは環境変数CLAUDE_CODE_SAFE_MODE=1でも指定できます。
v2.1.287のclaude --helpでは、--bareの説明にこう出ます。
--bare Minimal mode: skip hooks (those defined in settings and by installed
plugins; ...), LSP, plugin sync, attribution, auto-memory,
background prefetches, keychain reads, and CLAUDE.md auto-discovery.
Sets CLAUDE_CODE_SIMPLE=1.CLIリファレンスのページでは、--bareの説明にhooks・skills・カスタムコマンド・サブエージェント・プラグイン・MCPサーバー・自動メモリ・CLAUDE.mdの自動探索が並びます。列挙される項目が--helpとページで違うので、--bareで何が止まるかを厳密に知りたいときは、使っているバージョンの--helpを一度見ると確実です。--safe-modeの説明は、--helpにもCLAUDE.md・skills・plugins・hooks・MCPサーバーなどが並びます。--safe-modeは認証・モデル選択・組み込みツール・権限が通常どおり動く点で--bareと異なります。
動かないときの切り分け
「自動メモリが保存されない」「設定したのに効かない」は、原因が複数の層にまたがります。表の優先順位を踏まえ、手前から順に疑うと絞れます。
自動メモリが動かないときの確認順
- 1
/memoryのトグル表示を見る
トグルの表示を見ます。
off · can't be turned on hereなら、前の節の2種類のセッションのどちらかです。 - 2
環境変数を調べる
CLAUDE_CODE_DISABLE_AUTO_MEMORYの値をechoなどで確かめます。 - 3
起動オプションを調べる
--bare、--safe-mode、CLAUDE_CODE_SIMPLEやCLAUDE_CODE_SAFE_MODEが起動スクリプトに入っていないかを見ます。 - 4
autoMemoryEnabledがどのスコープで効いているか見る
ユーザー設定の
falseが、プロジェクト設定のtrueと食い違っていないかを見ます。管理設定が入っている環境では、管理者側の値も確認対象です。 - 5
autoMemoryDirectoryをプロジェクト設定に書いていたら信頼状態を見る
フォルダが信頼済みか、
blockReadsOutsideWorkingDirectoriesがオンでないかを確認します。
設定がそもそも読まれていない問題はClaude Code設定が反映されない原因の探し方にまとまっています。配置と信頼状態の見落としパターンも載っています。
CLAUDE.mdやセッションメモリとの関係
自動メモリはClaude自身が書くメモで、CLAUDE.mdは人が書く指示です。CLAUDE.mdはプロジェクト・ユーザー・組織のスコープがあり、毎セッション全体を読み込みます。自動メモリは索引の先頭だけが起動時に入る点で、読み込み範囲が違います。サブエージェントにはメインの自動メモリは渡されず、サブエージェント自身の自動メモリは別のディレクトリです。三層の役割の違いはClaude Code memoryの三層構造に詳しくあります。
settings.jsonのスコープや優先順位はClaude Code settings.json完全ガイドにあります。autoMemoryDirectoryとautoMemoryEnabledも、そこで言うAny fileスコープのキーです。Claude Code全体の機能はClaude Code完全ガイドから辿れます。
まとめ
「効かない」ときに最初に見るのは、設定ファイルの中身より、環境変数と起動オプションと/memoryのトグル表示です。この順で当たれば、設定キー側の原因にたどり着く前に、上書きしている側が見つかります。