自動メモリの保存先変更とオフ設定 — autoMemoryDirectory/Enabled

Claude Codeの自動メモリは、プロジェクトごとに~/.claude/projects/<project>/memory/へ自動保存されます。この保存先を変えたい、またはそもそも自動メモリ自体を止めたいときに使うのがautoMemoryDirectoryとautoMemoryEnabledの2つの設定キーです。どちらもsettings.jsonに1行足すだけで効きます。

autoMemoryDirectory/autoMemoryEnabledでできること

autoMemoryDirectoryは自動メモリの保存先ディレクトリを変更し、autoMemoryEnabledは自動メモリそのもののオン/オフを切り替えます。どちらもスコープはAny fileで、ユーザー設定・プロジェクト設定・ローカル設定・管理設定のどれに書いても有効です。

保存先を変えるautoMemoryDirectory

既定では、Claude Codeはプロジェクトごとに~/.claude/projects/<project>/memory/へ自動メモリを保存します。この既定のディレクトリを使わず、任意の場所にまとめたいときはautoMemoryDirectoryに絶対パスか~/始まりのパスを文字列で指定します。

{
  "autoMemoryDirectory": "~/my-memory-dir"
}

値は文字列型で、未設定なら既定のプロジェクト別ディレクトリが使われます。autoMemoryDirectoryはuser設定・project設定・local設定・policy(管理)設定に加えて、--settings起動オプションで読み込んだ設定ファイルからも有効になります。

保存先ディレクトリの中身は、MEMORY.mdという索引ファイルと、メモリ1件につき1つのトピックファイルです。

~/.claude/projects/<project>/memory/
├── MEMORY.md           # 索引。1メモリ1行、毎セッション読み込まれる
├── user_role.md        # トピックファイルの例
├── feedback_testing.md # トピックファイルの例
└── ...                 # Claudeが作成するその他のトピックファイル

MEMORY.mdはセッション開始時に必ず読み込まれる索引で、Claude Codeはこのファイルを手がかりに個々のトピックファイルを読み書きします。自動メモリはmachine-local(その端末に固定)で、同じGitリポジトリのworktreeやサブディレクトリ間では共有されますが、別のマシンやクラウド環境とは共有されません。また、Claude Codeは古いセッションのtranscriptをcleanupPeriodDaysの保持期間で削除しますが、メモリディレクトリ内のファイルはこの削除処理の対象から除外されており、編集や削除をするまで残り続けます。

プロジェクト設定・ローカル設定で使うときの注意: autoMemoryDirectoryをプロジェクト設定(.claude/settings.json)やローカル設定(.claude/settings.local.json)に書いた場合、Claude Codeはこのキーをhooksと同じワークスペース信頼ルールの下で扱います。クローンしてきたリポジトリがこれらの設定ファイルを同梱している可能性があるためで、信頼していないフォルダでは指定した保存先が有効になりません。チーム共有のリポジトリにautoMemoryDirectoryを含めるときは、この信頼確認が挟まることを前提に運用します。

保存先を変える2つの理由

自動メモリの既定の保存先はGitリポジトリから導出されるため、同じリポジトリのworktreeやサブディレクトリはどこから起動しても既定のまま1つの自動メモリディレクトリを共有します。「worktreeごとに別々のメモリができてしまう」という問題は既定では起きません。autoMemoryDirectoryが効くのは、それとは別の2つの場面です。

1つ目は、CLAUDE_CONFIG_DIRと一緒にCLAUDE_CODE_PROJECT_DIR_NAMEを設定し、<project>ディレクトリ名をリポジトリから自動導出させず固定で運用している場合です(Claude Code v2.1.234以降)。この設定を使うと、どのリポジトリで起動しても同じ設定ディレクトリの配下では1つの自動メモリディレクトリが使われます。複数プロジェクトの自動メモリを1か所に集約したいときの主な手段はこちらです。

2つ目は、保存先をホームディレクトリの外へ明示的に移したい場合です。既定の~/.claude/projects/<project>/memory/はホームディレクトリ配下にあるため、端末を入れ替えるとその端末の自動メモリはそのままでは引き継がれません。autoMemoryDirectoryで同期用フォルダを指定しておけば、ファイル自体を新しい端末へコピーして引き継ぐことはできます。ただし前述のとおり自動メモリの仕組み自体はmachine-localで、複数端末間でリアルタイムに共有されるわけではない点は変わりません。

社内のセキュリティポリシー上、自動メモリの内容をどこに置くかを固定したい組織もあります。監査対象のストレージ内に限定したい、あるいは特定のドライブより外には出したくないといった要件がある場合は、次に述べる管理設定と組み合わせてautoMemoryDirectoryを運用する形になります。

自動メモリを止めるautoMemoryEnabled

自動メモリ自体が不要ならautoMemoryEnabledをfalseにします。falseにすると、Claude Codeは自動メモリのディレクトリから読み込みも書き込みも行わなくなります。

{
  "autoMemoryEnabled": false
}

型はBoolean、既定値はtrueです。true(または未設定)の場合、セッション側で自動メモリを無効化する要因が何も無ければ自動メモリは有効のままになります。

セッション中に切り替えたいだけなら、設定ファイルを直接編集しなくても/memoryコマンドで自動メモリのオン/オフを切り替えられます。この操作はユーザー設定のautoMemoryEnabledを書き換える形で反映されます。/memoryはCLAUDE.mdの編集も兼ねているコマンドで、自動メモリのオン/オフ切り替えに加えて、現在保存されている自動メモリのエントリーを一覧で確認する用途にも使えます。設定ファイルを直接開かなくても、セッション内から「今何が保存されているか」を見られる点がsettings.jsonを直接編集する方法との違いです。

管理者がmanaged settingsで強制する場合

autoMemoryDirectoryとautoMemoryEnabledはどちらもAny fileスコープなので、ユーザー設定・プロジェクト設定・ローカル設定に加えて管理設定(managed settings)にも書けます。Claude CodeはBoolean型のキーを「読み込んだ設定ファイルのうち最も優先順位が高いものの値」で確定させる仕組みを持っており、これはautoMemoryEnabledのようなBoolean型キーにも同じ原則が働きます。組織として自動メモリを一律オフにしたい場合、管理設定にautoMemoryEnabled: falseを配布すれば、ユーザー設定や個々のsettings.jsonでは上書きできません。逆に保存先を統制したい場合は、管理設定側でautoMemoryDirectoryを固定する運用もできます。個人開発でこの2つのキーを触るだけなら意識する必要はありませんが、チームや組織で導入するときは「誰の設定が勝つか」をこの優先順位で確認しておくと、想定と違う挙動に悩まずに済みます。

優先順位早見表 — --bare・safe modeとの関係

autoMemoryEnabledだけを見ていると、--bare起動時やCLAUDE_CODE_DISABLE_AUTO_MEMORYを使ったときに「設定通りに動かない」と感じることがあります。自動メモリの有効/無効は複数の要因が重なって決まるため、優先順位を早見表にまとめます。

CLAUDE_CODE_DISABLE_AUTO_MEMORYはセッション単位の環境変数で、1を渡すと自動メモリを無効化し、0を渡すと--bareやautoMemoryEnabled: falseが無効化しようとしていても強制的に有効化します。どちらの向きでもautoMemoryEnabledキーより優先されるのは、この環境変数が「今回の起動だけ挙動を変えたい」というその場限りの上書きを想定しているためです。設定ファイルの値を恒久的に変えたいだけならautoMemoryEnabled、CIや一時的な検証で挙動を変えたいだけなら環境変数、という使い分けになります。

--bareは起動を高速化するための最小モードで、hooks・skills・カスタムコマンド・サブエージェント・プラグイン・MCPサーバー・自動メモリ・CLAUDE.mdの自動探索をまとめてスキップします。--safe-modeは設定起因の不具合を切り分けるためのモードで、CLAUDE.md・skills・plugins・hooks・MCPサーバー・カスタムコマンドとエージェント・出力スタイル・ワークフロー・カスタムテーマ・キーバインド・ステータスライン・ファイル候補コマンド・LSPサーバー・自動メモリを丸ごと無効化します。どちらも自動メモリを止める点は共通ですが、目的が「起動を速くする」か「カスタマイズが原因かを切り分ける」かで別物です。--bareは内部的にCLAUDE_CODE_SIMPLEという環境変数もセットするので、スクリプトから起動を制御している場合はこの環境変数の有無でも--bare相当の状態かどうかを判定できます。

CLAUDE_CODE_DISABLE_AUTO_MEMORYはシェルの環境変数として、その回の起動にだけ渡す使い方が基本です。

CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 claude

settings.jsonのautoMemoryEnabledをfalseにしたまま、この起動だけ自動メモリを有効に戻したいときに使います。設定ファイルは変更しないので、次回以降の起動には影響しません。

CLAUDE.mdやセッションメモリとの違い

自動メモリという言葉自体の位置づけ(CLAUDE.mdやセッション内メモリとの違い)はClaude Code memoryの三層構造で扱っています。本記事が扱うのは、その自動メモリレイヤーをsettings.jsonの2つのキーでどう制御するかという設定面です。三層構造の全体像を先に押さえたい場合はそちらを、保存先の変更やオフ設定だけを知りたい場合は本記事の内容で足ります。

settings.json全体の構成やスコープの考え方はClaude Code settings.json完全ガイドにまとめてあります。autoMemoryDirectoryとautoMemoryEnabledもこのAny fileスコープの一部として、ユーザー・プロジェクト・ローカル・管理設定のどこに書くかで効く範囲が変わります。

よくあるつまずき

プロジェクト設定に書いたのにautoMemoryDirectoryが効かない: 前述の通り、プロジェクト設定・ローカル設定に書いたautoMemoryDirectoryはhooksと同じワークスペース信頼ルールの対象です。フォルダを信頼していない状態では反映されません。Claude Code設定が反映されない原因の探し方で扱っている配置・信頼状態の見落としと同じパターンなので、まずそちらの手順で信頼状態を確認すると早く原因が絞れます。

--bareで動かしたらメモリが消えたと思った: --bareは自動メモリの読み込み・書き込みを含む自動探索をスキップするだけで、保存先のファイルを操作するものではありません。Claude Codeは古いセッションのtranscriptをcleanupPeriodDaysの保持期間で削除する一方、メモリディレクトリ内のファイルはこの削除処理から除外しており、編集や削除をするまで残り続けます。通常起動に戻せば、autoMemoryDirectoryで指定した保存先(または既定のプロジェクト別ディレクトリ)から引き続き読み込まれます。

CLAUDE_CODE_DISABLE_AUTO_MEMORYを設定したのにオフにならない: この環境変数は1と0で意味が逆になります。1で無効化、0で強制的に有効化なので、値を0のまま残していないか確認します。

まとめ

自動メモリの保存先を変えたいだけならautoMemoryDirectoryに絶対パスか~/始まりのパスを指定します。自動メモリ自体が不要ならautoMemoryEnabled: false、セッション単位で一時的に切り替えたいだけなら/memoryコマンドかCLAUDE_CODE_DISABLE_AUTO_MEMORY環境変数を使います。プロジェクト設定・ローカル設定にautoMemoryDirectoryを書くチームは、ワークスペース信頼ルールが挟まることも合わせて確認しておくと、想定通りに反映されないという迷いを避けられます。組織として保存先やオン/オフを統制したい場合は、個々の設定ファイルではなく管理設定側に寄せておくのが確実です。