なぜ別のマシンで Claude Code の記憶が消えるのか
自動メモリはディレクトリであり、そのディレクトリはローカルにある
自動メモリはデフォルトで有効になっており、重要な役割を果たしています。Claude は作業を進めながら、ビルドコマンド、デバッグの知見、発見した規約などの独自のメモをプロジェクトごとのディレクトリに書き込みます。そして、各会話の開始時に MEMORY.md インデックスが読み込まれ、必要に応じてトピックファイルが参照されます。
これらはすべて、1台のコンピュータのホームディレクトリ配下に存在します。ドキュメントには、リポジトリのすべてのワークツリーとサブディレクトリが1つの記憶ディレクトリを共有すること、およびそのファイルはマシン間やクラウド環境間で共有されないことが明記されています。したがって、「Claude がビルドコマンドを学習した」というのは、そのノートPC1台においてのみ真実となります。
各マシンが独自のバージョンを保持し、乖離していく
各マシンが個別に学習するため、記憶の量に差が出るだけでなく、内容に矛盾が生じることもあります。ノートPCは Dockerfile を修正する前にビルドコマンドを学習し、デスクトップは修正した後に学習したとします。お互いの存在を知らないため、競合に気づくことも、同期・調整するステップもありません。
これが信頼性に与える影響に注意してください。セッション中、欠落している事実が「一度も学習されていない」のか、それとも「別の場所で学習された」のかを判断することはできません。会話の内部からは、どちらもまったく同じに見えるからです。
ワークツリー間では共有されるが、マシン間では共有されない
あなたにとって有利に働く境界線が1つあります。それを知ることで、もう一方の境界線がより明確になります。ドキュメントによると、リポジトリ内のすべてのワークツリーとサブディレクトリは、単一の記憶ディレクトリを共有します。そのため、3つのブランチに対して3つのワークツリーを保持している場合、それらは1つの記憶として扱われ、フィーチャーブランチでの作業中に学習された内容は main ブランチでも利用可能です。
これは適切な設計であり、記憶の「単位」が何であるかを示しています。それは「このファイルシステム上のリポジトリ」です。そのファイルシステムを越えると別の記憶領域になるため、1台目のマシンで5つのワークツリーがあっても記憶が共有される一方で、2台目のマシンの同じリポジトリでは空の状態から始まるのです。
クラウドやウェブのセッションも「別のマシン」である
これは、問題を解決したと思っていた人々を驚かせる部分です。Claude Code のセッションは、あなたのターミナル以外の場所でも実行できます。ウェブやモバイルのクライアント、Remote Control、そして v2.1.224 以降では、自身のマシンやコンテナをセッションの実行環境にする claude self-hosted-runner などがあります。
記憶の観点から見れば、これらはすべて個別のファイルシステムです。ドキュメントにある「マシンまたはクラウド環境」という表現の通り、コンテナ内のセルフホスト型ランナーはまさにこれに該当します。あなたのノートPCではないため、ノートPCの記憶は引き継がれません。
クリーンアップ処理の対象となるフォルダでもある
ローカルファイルには、ローカルファイルのライフサイクルが伴います。~/.claude ディレクトリの保持期間は、セッションの履歴を削除するのと同じ cleanupPeriodDays 設定によって管理されています。そのため、記憶ディレクトリは特別な保護対象ではなく、通常のクリーンアップ処理の対象となります。
また、バグの影響を受ける可能性もあります。これについては、大げさに言うのではなく正確に述べる価値があります。2026年8月11日にリリースされた v2.1.228 の変更履歴には、「プロジェクトのメモリフォルダ内のコンテンツをセッションクリーンアップが削除してしまう問題を修正」とあります。このリリースで修正されましたが、構造的な教訓は変わりません。ツールのクリーンアップロジックによって管理される自動生成ディレクトリは「キャッシュ」であり、「記録」ではありません。バグがない場合でも、そのように扱うべきです。
セッション間のメッセージングでも知識は移動しない
Claude Code のセッション間で、マシンをまたいでメッセージを送信できるようになりました。これで解決するように思えるかもしれませんが、設計上、解決しません。メッセージはテキストであり、履歴やファイルそのものではありません。マシン間のメッセージングは返信専用（別のマシンのセッションがあなたに返答することはできますが、新規に呼び出すことはできません）であり、検出はローカルファイルとソケットに依存しているため、コンテナとそのホストは互いを認識することすらできません。
これは、意図通りに機能している連携チャネルに過ぎません。移動するのは「文章」であり、「記憶」ではないのです。
よく試されるアプローチとその限界
`CLAUDE.md` のコミット。 これは正しい方法であり、全員がやるべきです。プロジェクトファイルはバージョン管理されているため、リポジトリとともにすべてのマシンやチームメンバーに共有されます。限界としては、これはあなたがメンテナンスするファイルであるという点です。ここには永続的なルールが保持されますが、Claude が作業中に発見した無数の細かい知見までは保持されません。
新しいマシンで再度 `/init` を実行する。 リポジトリから初期状態の CLAUDE.md を取得できます。これは確かに便利ですが、コードからすでに読み取れる内容を再生成しているに過ぎません。不安定なテストに関する知識などはリポジトリに存在しなかったため、復元することはできません。
`~/.claude` を Dropbox や dotfiles リポジトリで同期する。 最もよく試される方法ですが、注意が必要です。ツールが排他的に所有していると想定しているパス上で、セッションデータや認証情報とともに、自動生成された状態を同期することになります。さらに、2台のマシンが同時に書き込みを行う可能性もあります。実践している人もいますが、これはドキュメントに記載されていない構成であり、「エージェントのメモリフォルダが別のホストによって中途半端に上書きされた」という最悪の事態を招くリスクがあります。もし試す場合は、同期対象を厳密に絞り、セッションがアクティブな間は絶対に同期しないでください。
エージェントに再学習を依頼する。 機能はしますが、探索のためのセッションコストがかかり、もう一方のマシンとは微妙に異なるメモが生成されます。すでに所有しているものを再構築するために、無駄にトークンを消費することになります。
Remote Control を使用して、セッションを常に1つにする。 有効な戦略です。作業を1つのホストに集約し、他の場所から接続します。これにより乖離を確実に防ぐことができますが、知識が1台のノートPCに依存することになり、紛失、初期化、またはクリーンアップによって失われるリスクが生じます。
これらのアプローチはすべて、ローカルキャッシュを管理しているに過ぎません。知識をマシンから独立して存在させることはできません。
解決策：共有可能な半分を、マシンに依存しない場所に配置する
そのフォルダ内の情報を、誰が必要としているかに応じて分割しましょう。2つの情報にはそれぞれ適した保存場所があります。
マシン固有の状態は、マシン固有のままにする。 ローカルパス、実行中のコンテナ、自身の環境の癖などです。これらは自動メモリに任せ、使い捨て可能なものとして扱いましょう。
2台目のマシンや他のメンバーが必要とするものはすべて、マシンの外部に置く。 実際に動作するビルドコマンド、特定のディレクトリが立ち入り禁止である理由、決定事項とその日付、不安定なテストとその理由。これらはあなたのノートPCに関するものではなく、プロジェクトに関するものです。
これを実現するための2つのステップがあります。まず、すでにバージョン管理されているスコープを活用します。リポジトリのルートにコミットされた CLAUDE.md、パススコープのルールのための .claude/rules/、およびサブエージェントを使用している場合は、ホームディレクトリではなくリポジトリ内の .claude/agent-memory/<name-of-agent>/ に書き込まれ、バージョン管理を通じて共有可能な memory: project を使用します。次に、ルール形式ではない知識を、すべてのマシンから読み取り可能なストアに配置します。
MemoryLake は、この2つ目の部分（決定事項、インシデントの報告書、ソースドキュメントなど）を1つのストアに集約する記憶レイヤーです。あらゆるマシンの Claude Code から MCP 経由で、また Codex や API 経由の ChatGPT からもアクセスできます。ノートPCはキャッシュを保持し続け、知識そのものはノートPC上には依存しなくなります。
ステップ 1: API キーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。セッションに直接貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。これにより、新しいマシンのセットアップが再学習の手間なしで、わずか5分で完了するようになります。
ステップ 2: 最初の記憶をアップロードする
別のマシンが再発見しなければならなかったドキュメント、画像、ファイルを投入します。ランブック、アーキテクチャの決定事項、インシデント報告書、API コントラクト、「このテストが不安定な理由」のメモなどです。要約ではなく、ソースそのものをアップロードしてください。要約はローカルのメモリフォルダがすでに保持しているものであり、他の環境への移行には適していません。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他の AI エージェントに、MCP または API 経由で記憶へのアクセスを許可します。マシンごとに MCP サーバーを一度設定すれば、ノートPC、デスクトップ、ウェブセッション、コンテナ内のセルフホスト型ランナーのいずれであっても、すべてのセッションが同じストアを読み込みます。これこそが、ローカルメモリには不可能な特性です。
実務における変化
最初の違いは、新しいマシンの導入が「オンボーディング（再学習）」ではなく、単なる「プロビジョニング（設定）」になることです。リポジトリをクローンし、ストアを指定するだけで、エージェントはそのコンピュータがたまたま覚えていることではなく、チーム全体が知っている知識を持ってスタートできます。
2つ目は、クラウドやコンテナのセッションが「二流の市民」ではなくなることです。セルフホスト型ランナー上のセッションには引き継ぐべきローカルメモリがないため、現状ではワークフローの中で最も情報が不足している参加者になってしまいます。共有ストアを読み込むことで、ノートPCと同じ情報量を持つことができます。これは、人間が監視する可能性が最も低い自動実行において最も重要になります。
3つ目は、フォルダが失われても問題なくなることです。クリーンアップ処理、マシンの初期化、コンテナの再インストールなど、これらすべてが「損失」ではなく、単なる「一時的な不便」になります。なぜなら、永続化すべき重要な情報は最初からそこにはなかったからです。
また、これは Claude Code が本来持つ機能とも調和します。自動メモリはリポジトリごとにローカルメモを書き込み続け、CLAUDE.md はバージョン管理を通じて永続的なルールを伝達し続けます。どちらも「信頼できる唯一の情報源（System of Record）」になる必要はありません（それらは本来その役割に適していません）。これは、複数のエージェントで1つの記憶を共有する際の一貫性を保つための役割分担と同じです。
マルチマシン環境における Claude Code のベストプラクティス
コミットできるものはすべてコミットする
リポジトリルートの CLAUDE.md、スコープ付きルールのための .claude/rules/、プロジェクトスコープのサブエージェントのための .claude/agent-memory/。バージョン管理下にあるものはすべて、自動的にマルチマシン対応となり、チームメンバーと自動的に共有されます。CLAUDE.local.md やローカルスコープのメモリは、本当に自分のマシンから出すべきではない情報のために残しておきましょう。
メモリフォルダをキャッシュとして扱う
今夜 ~/.claude/projects/<project>/memory/ が消滅した場合、何を失うことになるか自問してみてください。もし失って困るものがあるなら、そのコンテンツは間違った場所にあります。リポジトリに書き込むか、共有ストアに保存してください。v2.1.228 の修正は、そのことを思い出させるきっかけに過ぎず、本質的な理由ではありません。
MEMORY.md はインデックスに留める
セッション開始時に読み込まれるのは、MEMORY.md の最初の200行または25KBのいずれか早い方のみです。1エントリにつき1行に抑え、詳細はトピックファイルに記述することで、インデックスをこの制限内に収めることができます。肥大化したインデックスは警告なしに切り捨てられるため、気づきにくい失敗パターンとなります。
安易に ~/.claude を同期しない
もし同期する場合は、範囲を絞り、慎重に行ってください。アクティブなセッション中は絶対に同期せず、2台のマシンから同時に書き込まないようにし、自動生成された状態が安全にマージできるとは決して想定しないでください。サポートされているマルチマシン対応のパスは、バージョン管理と共有ストアであり、ツールが所有するディレクトリのファイル複製ではありません。
自動セッションにターミナルと同じコンテキストを提供する
ウェブセッション、Remote Control、およびセルフホスト型ランナーは、ローカルメモリがない状態で開始されます。これらの実行が重要である場合は、共有ストアとコミットされたファイルに必要な情報がすべて含まれていることを確認してください。そうしないと、最も監視の目が届かないセッションが、最も少ないコンテキストで動作することになってしまいます。
強制力があるとは期待しない
Claude Code のドキュメントでは、指示ファイルや自動メモリは、強制される設定ではなく「コンテキスト」として説明されています。フォーマッタ、保護されたパス、main への直接プッシュの禁止など、すべてのマシンで強制されるべきルールは、コミット可能でマルチマシン対応となる Git フックや CI に記述すべきです。
結論
別のマシンで Claude Code の記憶が消えるのは、その記憶がローカルディレクトリに保存されているためであり、ドキュメントにも「ファイルはマシン間やクラウド環境間で共有されない」と直接記載されています。すべてのホストが個別に学習し、クラウドやコンテナのセッションは追加のホストとして扱われ、フォルダは通常の保持期間クリーンアップの対象となります。8月11日の変更履歴にある「プロジェクトのメモリフォルダ内のコンテンツをセッションクリーンアップが削除してしまう問題を修正」という項目は、自動生成されたディレクトリが単なるキャッシュに過ぎないことを思い出させてくれます。
したがって、キャッシュは保持しつつも、それに依存するのはやめましょう。コミットできるものはコミットします（CLAUDE.md、.claude/rules/、プロジェクトスコープのエージェントメモリ）。そして、ルール形式ではない知識（理由、決定事項、苦労して得た運用の詳細など）を、すべてのマシンが読み取る単一のストアに配置します。そうすれば、2台目のマシンは「ゼロからのスタート」ではなく、単なる「もう1つの入り口」になります。