コンテキストを失わずに Claude Code から Claude Cowork へ移行する方法 (2026)

Claude Code には、そのドキュメントの表現を借りれば「2 つの補完的なメモリーシステムがあり、どちらもすべての会話の開始時にロードされます」。1 つはユーザーが書き、もう 1 つは Claude が書きます。これらはまったく異なる方法で移行されます。

あなたの CLAUDE.md は移行されますが、インポートに関する注意点があります。 Claude Code はデスクトップ上の Cowork セッション内で CLAUDE.md を読み込みます。変化するのは、その中の @ インポートの処理方法です。通常、ユーザースコープのファイルは信頼されます。「デスクトップ上の Cowork セッションを除き、Claude Code はダイアログなしでインポートをロードし、他の個人設定と同様に信頼します。」しかし Cowork 内では、その信頼の範囲が狭まります。ドキュメントには直接こう書かれています。「デスクトップ上の Cowork セッションでは、Claude Code はユーザースコープのファイル内にある、セッションの作業ディレクトリ外のパスに解決されるインポートをスキップし、ファイルの残りの部分をロードします。」

最後の句をもう一度読んでみてください。「ファイルの残りの部分をロードします」とあります。エラーは発生せず、目に見えるファイルから何かが欠けているようには見えません。単に、他の場所に存在していた部分が差し引かれたファイルが読み込まれるだけです。

シンボリックリンクされた個人用メモリーファイルは移行されません。 「それらのセッションでは、それ自体がシンボリックリンクまたはハードリンクである ~/.claude/CLAUDE.md や、作業ディレクトリ外を指すシンボリックリンクされた ~/.claude/rules/ ディレクトリまたはルールファイルもスキップされます。」dotfiles リポジトリに 1 つの正規のメモリーファイルを保持し、すべてのマシンでそこにシンボリックリンクを張るという、一般的で合理的なセットアップを行っている場合、そのファイルは Cowork セッションではマージされず、スキップされます。

これら 2 つは、見た目以上に重要です。なぜなら、Claude Code 自身のドキュメントが、まさにこの問題を引き起こすパターンを推奨しているからです。ワークツリー間で個人用の指示を共有するためのドキュメント化されたアプローチは、ホームディレクトリからのインポートです：- @~/.claude/my-project-instructions.md。このパスはセッションの作業ディレクトリ外で解決されるため、まさにスキップされる条件に合致してしまいます。

自動メモリーはいかなる形でも移行されません。 これは Claude が書いた半分、つまり「学習内容とパターン」であり、スコープは「リポジトリごと、ワークツリー間で共有」され、すべてのセッションに「最初の 200 行または 25KB」としてロードされます。これは ~/.claude/projects/<project>/memory/ に MEMORY.md インデックスと、メモリーごとのトピックファイル（user、feedback、project、または reference のタグ付き）として保存されます。そして、これはマシンに固定されています。「自動メモリーはマシンローカルです。同じ git リポジトリ内のすべてのワークツリーとサブディレクトリは、1 つの自動メモリーディレクトリを共有します。ファイルはマシン間やクラウド環境間で共有されません。」

Cowork のデフォルトの実行環境はクラウド環境です。アーキテクチャのドキュメントには、「Cowork セッションはデフォルトでクラウドで実行されます。エージェントループとコード実行は Anthropic のサーバー上で実行され、セッションとファイルはメンバーの Claude アカウントに保存されます」とあり、「既存のデスクトップ展開ではローカル実行も引き続き利用可能です」と付け加えられています。マシンローカルのストアとクラウドセッションの連携は解決が難しい問題ではありませんが、これらは単に 2 つの異なる場所であり、その間を繋ぐドキュメント化された手段はありません。

代わりに Cowork が提供するものは、異なる形をしています。 これには 3 つの永続レイヤーがあり、そのいずれも CLAUDE.md をドロップできるようなファイルではありません：

• グローバル指示（Global instructions） は、「すべての Cowork セッションに適用される常設の指示」であり、Cowork の設定で編集します。リポジトリ内のファイルではなく、テキストボックスです。
• フォルダー指示（Folder instructions） は、「デスクトップでローカルフォルダーを選択したときに、プロジェクト固有のコンテキストを Cowork に追加」し、通常の指示ファイルにはない特性を持っています。「Claude はセッション中にこれらを独自に更新することもできます。」
• プロジェクト（Projects） は、独自の指示、スケジュールされたタスク、コンテキスト、およびメモリーを保持します。「メモリーはプロジェクトにスコープされているため、Claude があるプロジェクトで学習した内容は他のプロジェクトには引き継がれません。」プロジェクトは自動的な蓄積ではなく、手動で追加していきます。「Cowork はプロジェクトの内容を変更しないため、保持したいものは自分でプロジェクトに追加してください。」

計画を立てる前にもう一つ知っておくべき境界線があります。これはプロジェクトメモリーが有効かどうかを決定するものです。「Cowork がクラウドで実行されている場合、チャットと Claude Cowork の間でメモリーが共有されます。コンピューター上でローカルに実行される Cowork セッションはメモリーを使用しません。」

2 つのステップがあります。どちらも難しくありませんが、最初のステップは多くの人がスキップしがちなものです。

ステップ 1: Cowork セッションが読み込む方法で指示ファイルを読み解く

CLAUDE.md を開き、すべての @ インポートを見つけます。それぞれについて、次の 1 つの質問を投げかけてください。「このパスは、Cowork セッションが作業を行うフォルダー内で解決されますか？」

リポジトリ内のファイルを指すインポート（@README、@package.json、@docs/git-instructions.md など）は問題ありません。ホームディレクトリを指すインポートは、ドロップされる対象です。作業ディレクトリ外を指すシンボリックリンクまたはハードリンクである場合の ~/.claude/CLAUDE.md や ~/.claude/rules/ も同様です。

次に、.claude/rules/ についても同様に確認してください。Claude Code のドキュメントには、ルールディレクトリは「シンボリックリンクをサポートしているため、共有ルールセットを維持し、それらを複数のプロジェクトにリンクできます」と記載されています。これは非常に優れたパターンですが、Cowork セッションがスキップする対象として明確に名指しされています。

インポートがドロップされる場合、2 つの現実的な選択肢があります。コンテンツをリポジトリ内の実際のファイルにインライン化し、チームメンバーやバージョン管理から見えるようにすること。あるいは、損失を受け入れて、そのガイダンスを Cowork のグローバル指示（どこにでも適用される設定用に設計されたレイヤー）として再表現することです。同僚が見て有益なものであれば、通常はインライン化する方が適しています。共有リポジトリに置く必要のない、自分自身の作業スタイルの好みについては、グローバル指示が適しています。

これは Cowork での作業を開始する前に行ってください。後からでは遅すぎます。削除されたインポートは、明らかに壊れた出力ではなく、規約から微妙に外れた出力を生成するため、最も気づきにくい失敗パターンとなります。

ステップ 2: 書かれたレイヤーを移動し、学習されたレイヤーの扱いを決める

書かれたレイヤーについては、Cowork の 3 つのスロットを上から順に処理していきます。

CLAUDE.md 内の、トーン、出力形式、役割、常設の制約など、本当に「あなた」に関するものはすべてグローバル指示に属します。特定の作業内容に関するものは、フォルダー指示またはプロジェクトの指示フィールドに属します。すでに同じ作業のために Claude チャットプロジェクトを維持している場合、Cowork はそこからシードを作成できます。「プロジェクトからインポート」を選択すると、「『作成』をクリックすると、既存の Claude プロジェクトからファイルと指示が転送され、新しい Cowork プロジェクトが作成されます」。なお、「一括アップロードはサポートされていません」ので、プロジェクトごとに 1 つずつ行う必要があります。

学習されたレイヤーについては、インポート機能はありません。存在するのは、ドキュメント化された読み出し方法のみです。Claude からメモリーを取り出すための Anthropic のガイダンスは、そのまま書き出すよう要求することです。「私に関するメモリーを、あなたのメモリーに表示されている通りに一言一句正確に書き出してください。」これは読み出しであり、引き渡しではありません。出力されたテキストを自分でどこかに配置する必要があります。また、これはアカウントレベルのメモリーであり、マシンの ~/.claude/projects/<project>/memory/ ファイルとは異なるストアであることにも注意してください。後者はプレーンな Markdown なので、直接読み取ることができます。

ここで 2 つの注意点があります。第一に、Claude のメモリー管理には「プロジェクトメモリーを含むすべてのメモリーを永久に削除する」という「メモリーのリセット」アクションがあり、「これは元に戻せません」。整理する前に必ず確認してください。第二に、フォルダーレベルのプロジェクトが重要な場合、Anthropic 自身のページで現在、プロジェクトのストレージに関する説明が 2 箇所で異なっていることに注意してください。プロジェクトに関する記事では「プロジェクトはデスクトップ専用で、ローカルに保存されます。現時点ではプロジェクトデータのクラウド同期はありません」と記載されている一方、利用可能なインターフェースのページでは、プロジェクトはデスクトップ、ウェブ、モバイルで利用可能とされ、「ローカルフォルダーに紐づいたプロジェクトはデスクトップ上の Cowork セッションのみをサポートします」という注意書きがあります。どちらのページも最新のものです。どちらの説明が自分の環境に当てはまるかを仮定するのではなく、ご自身のアカウントで動作を確認してください。

ステップ 1 とステップ 2 は、ファイル形式の半分を処理します。インポートパスを持たないもう半分は、構築に最も時間がかかった部分です。数ヶ月にわたって Claude に与えた修正、Claude が推測した好み、コードからは導き出せないプロジェクトの事実などです。Claude Code では、これはマシンローカルのディレクトリに保存されます。Cowork では、セッションがクラウドで実行されている場合にのみ適用されるアカウントレベルのストアに保存されます。どちらも、もう一方にそのまま渡せる場所ではありません。

解決策は、どちらか一方を選ぶことではなく、そのレイヤーを両方の外部に保持することです。MemoryLake は、あなたが所有するメモリーレイヤーであり、特定の製品のプライベートなストアを介するのではなく、API を通じて、そのとき使用しているアシスタントから読み取ることができます。3 つのステップで完了します。

ステップ 1: API キーを作成する

サインインし、ワークスペースの設定から API キーを作成します。これはインターフェースではなくあなたに紐づいているため、ターミナルとデスクトップの間を移動しても無効になりません。

ステップ 2: 最初のメモリーをアップロードする

先ほど読み出したコンテンツと、移行ステップでインライン化しなければならなかったインポートから始めましょう。好みや作業スタイル、繰り返し発生する修正、Claude がコードから導き出せなかったプロジェクトの事実（なぜサービスがそのような構造になっているのか、チームがすでに却下したアプローチは何か、締め切りが実際に何に依存しているかなど）です。ファイルはそのままの形で取り込まれ、マルチモーダルなファイルも処理されるため、規約をエンコードしたアーキテクチャ図やスプレッドシートを直接投入できます。

ステップ 3: AI とエージェントを接続する

Claude Code、Cowork、その他使用しているツールを接続します。それ以降、学習されたレイヤーはインターフェースごとに再構築されるのではなく、1 つの場所から読み取られるようになり、ターミナルとデスクトップアプリを切り替えてもリセットされることはなくなります。

率直に言って、3 つの制限があります。MemoryLake は Claude のメモリーを読み取り、エクスポート、または削除することはできません。手動移行のステップ 2 での読み出しが手動ステップであるのはそのためです。また、Cowork が外部インポートを削除する方法を変更することもありません。その動作は Claude Code のものであり、状況に関わらず適用されます。そして、CLAUDE.md の代替にはなりません。チームメンバーが見えるようにリポジトリ内に配置する必要がある指示については、引き続き CLAUDE.md が最適な場所です。

直接的な変化は、移行から 3 週間後に気づくような「情報の欠落」がなくなることです。削除されるはずだった部分をインライン化したため指示はそのまま届き、両方のインターフェースからアクセスできる場所から読み取られるため、学習されたレイヤーも引き継がれます。

より大きな変化は、インターフェースの選択が可逆的になることです。Cowork のクラウドセッションは設計上エフェメラル（一時的）です。「各セッションは独自のサンドボックスを取得し、セッション開始時に作成され、終了時に破棄されます。サンドボックスは、互いに、または組織間で状態を共有しません。」これはセキュリティの観点から正しい姿勢であり、セッション内に何かが蓄積されるわけではないことも意味します。永続的なレイヤーが外部にあれば、エフェメラルなサンドボックスを使用するコストはゼロになり、1 週間ターミナルに戻って作業するコストもゼロになります。

また、複数のマシンで作業する人にとって、繰り返し発生する特有の煩わしさも解消されます。自動メモリーがマシンローカルであることはドキュメント化されており意図的なものですが、これはラップトップが知っていることをデスクトップが知らないという状況を生み出します。これは、why Claude Code forgets across machines で取り上げられているのと同じ問題です。外部レイヤーであれば、どちらのマシンからでも同じように読み取ることができます。

CLAUDE.md は学習内容ではなく、指示のために使用し続けてください。 Claude Code のドキュメントには、自動メモリーを書き込む際、Claude は「CLAUDE.md ファイルにすでに記載されている内容はすべてスキップする」と明記されています。学習内容を指示ファイルに重複して記載すると、両方のレイヤーの質が低下します。

Cowork セッション内で必要なものは、インポートするのではなくインライン化してください。 パス解決のメンタルモデルを意識する代わりに、この 1 つのルールだけを覚えておいてください。

フォルダー指示は、自分専用のフィールドではなく、共有フィールドとして扱ってください。 Claude はセッション中にこれらを更新できます。これは便利ですが、失ってはならないものは、Claude が書き込みを行わない場所に置くべきであることを意味します。

プロジェクトには意図的にものを配置してください。 Cowork が自動的に追加してくれることはありません。

プロジェクトメモリーに依存する前に、Cowork セッションがクラウドで実行されているか確認してください。 メモリーは Cowork がクラウドで実行されている場合に適用され、ローカルセッションでは使用されません。

指示ファイルは四半期ごとに読み直してください。 Claude Code 自身のガイダンスでは、矛盾するルールがある場合、「Claude は任意に 1 つを選択する可能性がある」と警告しています。2 つのインターフェースが同じファイルを読み取る場合、古いファイルがもたらす悪影響は倍増します。what your assistants actually remember を定期的に見直すことは、20 分を費やす価値が十分にあります。

同じベンダー、同じアーキテクチャであっても、これは依然として本質的な移行作業です。なぜなら、Claude Code のメモリーの重要な部分は、マシンローカルのディレクトリとリポジトリ外に及ぶインポートグラフであり、Cowork のセッション境界はこれら両方を異なる方法で処理するからです。切り替える前にインポートを修正し、書かれたレイヤーを Cowork が実際に持つ 3 つのスロットに移動し、学習されたレイヤーを手動で読み出して、どちらのインターフェースにも属さない場所に配置してください。そうすれば、どちらのインターフェースを使用するかは、リセットを伴う選択ではなく、単なる好みの問題になります。