実際に移行できるもの
ルールの内容はほぼそのまま移行できます。 Windsurf のルールは Markdown で書かれたモデルへの指示書です。Claude Code は CLAUDE.md を読み込みます。翻訳レイヤーは必要ありません。テキストの配置場所が変わるだけで、中身は変わりません。
Windsurf の歴史の中で仕様が変化してきたため、収集するデータの形式を把握しておく価値があります。コミュニティのドキュメントによると、2つのシステムが共存しています。プロジェクトルートにあるレガシーな `.windsurfrules` プレーンテキストファイルと、スコープ指定された Markdown ルールを格納する新しい `.windsurf/rules/` ディレクトリです。現在の Devin Desktop ビルドでは .devin/rules/ が優先され、.windsurf/rules/ はフォールバックとして維持されます。これらのファイル全体のルールは、合計で約12,000文字に制限されていると報告されています。これらの詳細は公式リファレンスではなく実践者のガイドに基づいているため、ご自身の環境で確認することをお勧めします。
このフォールバック動作があるため、移行作業が任意であるかのように感じられます。古いルールが読み込まれ続けるため、見た目の劣化がなく、棚卸しが行われないままになってしまうのです。
Cascade のメモリは移行できません。これこそが本当の損失です。 コミュニティガイドが指摘するように、重要な違いは次の点にあります。ルールはユーザーが記述してバージョン管理にコミットする静的な指示であるのに対し、Cascade のメモリは自動生成かつローカルなものです。エージェントはセッションからコンテキストを記録して同じ質問を繰り返さないようにしますが、メモリはチームメンバーと共有されず、意図的な規約を記述する場所でもありません。
これをよく理解しておく必要があります。これは一長一短だからです。つまり、Windsurf には確かにメモリレイヤーが存在し、あなたが意識しなくなった「エージェントはすでにそれを知っている」という瞬間のすべてにおいて、実際に機能していたということです。同時に、そのレイヤーはセッションから自動生成され、1台のマシンに閉じ閉じ、エクスポートを想定して設計されていなかったことも意味します。Claude Code に渡せるファイルは存在しません。
MCP 接続は変換ではなく、再追加が必要です。 Windsurf から Devin へのリブランド時には自動的に引き継がれましたが、別のエディタには付いてきません。Claude Code は MCP サーバーをサポートしているため、何かを書き直すのではなく設定を再入力するだけですが、各サーバーが必要としていた資格情報や環境変数は、再度設定し直す必要があります。
拡張機能、キーバインド、プランは一切引き継がれません。 これらがリブランド時に引き継がれたのは、同じエディタだったからです。Claude Code は VS Code のフォークではなく CLI であるため、この部分は移行ではなく、ツールのカテゴリ自体の変更です。驚かないように、あらかじめ明記しておきます。
スクリプトと自動化の監査が必要です。 リブランドにより .windsurf/tools/ は .devin/tools/ に移動しました。この移行に関する一般的な報告では、エディタ自体は移行されたものの、スクリプトは移行されなかったとされています。Windsurf のパスを呼び出すシェルスクリプトなどは、すでに潜在的に破損しています。Claude Code への移行は、新たな破損の原因を作るのではなく、そうした問題を検出する良い機会になります。
手動移行の手順
ステップ 1: ルールを収集し、メモリの内容を再構築する
まずはファイルから始めましょう。この部分は機械的に行えます。プロジェクトルートで .windsurfrules を探し、次に .windsurf/rules/ や .devin/rules/ でスコープ指定された Markdown ファイルを探します。存在を忘れていたものも含め、すべて収集してください。合計文字数制限があるため、古いルールは削除されるのではなく切り詰められていることが多く、中途半端なルールは無い方がマシです。
見つかったものを実際のスコープごとに分類します：
- 作業全体でグローバルなもの — 出力のフォーマット方法、デフォルトで使用する言語やバージョン、すべてのプロジェクトに共通する事項。
- このリポジトリでグローバルなもの — 規約、アーキテクチャの制約、テスト要件。
- 特定の領域に限定されるもの — API レイヤー、データレイヤー、テストにのみ適用されるルール。
次に、機械的ではない部分を行います。Cascade（または Devin Desktop）を開き、どこにも書かれていないのにエージェントが知っていると思われる内容を読み取ります。これを表面化させる現実的な方法は、直接質問することです。「どのような規約に従っているか」「このプロジェクトについて何を指示されたか」「何を避けているか」などです。メモリはセッションから自動生成されるため、その回答は、かつて雑談交じりに一度だけ伝えて明文化しなかった内容であることがよくあります（ベンダーの癖、触れてはいけないディレクトリ、最初に実行する必要があるビルドステップなど）。
これらを普通のテキストとして書き留めておきます。この作業こそが、移行において唯一代替の利かない時間です。それ以外は単なるファイルのコピーに過ぎません。また、エディタの便利さのどれほど多くが、バックアップしたことのないローカルのマシンごとのストアに蓄積されていたかに気づく瞬間でもあります。
ステップ 2: 適切なレベルで CLAUDE.md として再構築する
Claude Code は CLAUDE.md を読み込み、その配置場所によってスコープが決定されます：
- グローバルな設定は
~/.claude/CLAUDE.mdに配置します。 - リポジトリの規約はプロジェクトルートの
CLAUDE.mdに配置してコミットし、チーム全体で共有できるようにします。 - 領域固有のルールは、そのサブディレクトリ内の
CLAUDE.mdに配置するか、参照するドキュメントとして残します。
3つ目のケースで役立つ習慣として、長い領域固有のルールをインラインで書くのではなく、docs/ 内のファイルとして保持し、ルートの CLAUDE.md に「src/api/ 以下のものを変更する前に docs/api-conventions.md を読むこと」という1行を追加する方法があります。また、常に読み込ませるのではなく、関連するタイミングで @path インポートを使用して特定のファイルを取り込むこともできます。
白紙のファイルから始めたくない場合は、/init を実行するとリポジトリから CLAUDE.md の雛形が生成され、/memory を実行するとメモリファイルを直接編集できます。どちらもゼロから書くより早く、生成されたものをベースに削ぎ落としていくことができます。
簡潔に保ちましょう。スコープ内にあるものはすべてのタスクで読み込まれるため、ルートファイルが長いと、すべてのリクエストで永続的にコスト（トークン）を支払うことになります。Windsurf の合計文字数制限とは異なり、ファイルを長くしすぎることを防ぐ仕組みはありません。あの制限は、実は親切な設計だったのです。
そして、期待値を正しく設定してください。ここで多くの人が失望するからです。ルールファイルは知識を 利用可能 にするだけであり、ツールに記憶させるわけではありません。Claude Code はセッションごとにファイルから新しく開始し、長いセッションではコンテキストを圧縮します。そのため、優れた CLAUDE.md があっても セッション間でプロジェクトのコンテキストを忘れてしまい、先週行った修正が元に戻ってしまう のです。あなたはルールを移行しました。しかし、失った自動生成のメモリレイヤーを置き換えたわけではなく、Claude Code にはメモリレイヤーが標準搭載されていません。
より良い方法：エディタに依存しない単一のメモリレイヤー
今起こったことの構造に注目してください。メモリレイヤーがマシンローカルであり、製品と密結合していたために、製品の変更（最初はリブランド、次に使用していたエージェントの終了）によってメモリを失うことになりました。
これは Windsurf の欠陥ではありません。ツール内部に存在するあらゆる知識に起こる共通の現象です。ツールが変更されるまでは素晴らしいものですが、変更された瞬間に回収不能になります。Cascade のメモリは設計上、自動生成かつローカルなものでした。Cascade より長生きするとは誰も約束していません。
代替案は、そのレイヤーをエディタの完全に外側に保持することです。MemoryLake は、ツールが読み込むためのメモリレイヤーです。規約、決定事項、制約を1つのストアに集約し、Claude Code からは MCP 経由で、その他のツールからは API 経由でアクセスできます。次回、エディタがリブランドされたり、エージェントが終了したり、あるいは単に新しいツールを試したくなったときでも、知識は再構築の作業ではなく、設定項目を1つ追加するだけで済みます。
ファイルについて公平に言うと、CLAUDE.md にはストアにはない本質的な利点があります。プレーンテキストであり、バージョン管理下にあり、プルリクエストでレビューされ、チームに自動的に引き継がれます。永続的なルールにはこれを使用してください。それが本来の用途です。メモリレイヤーは、蓄積されていくもの（ベンダーの癖、決定の背景にある理由、アンインストールする前にエージェントに問い詰めて初めて判明するような事柄）のためにあります。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。設定ファイルにインラインで記述するのではなく、環境変数やシークレットマネージャーに保管してください。今回の移行で MCP の資格情報を再入力しているはずですので、次回探さずに済む場所に保管しておきましょう。
ステップ 2: 最初のメモリをアップロードする
ステップ1で再構築した内容を含むドキュメント、画像、ファイルを投入します。さらに、ルールが指し示していた参照資料（理由付きのアーキテクチャ決定、ビルドの癖、制約など）も追加します。可能な限り、要約ではなくソース自体をアップロードしてください。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API 経由でメモリへのアクセス権を付与します。Claude Code は MCP サーバーをサポートしているため、設定項目は1つだけです。そして、同じストアは他のどのツールからでも読み取ることができます。これこそが、一度だけ設定すればよいという最大のメリットです。
実務における変化
最初の違いは、ステップ1で行った「エージェントへの問い詰め」作業がこれで最後になるということです。ご自身のプロジェクトについて学んだ内容は、エクスポートできないマシンごとのストアに眠るのではなく、いつでも読める記録として残ります。
2つ目は、マシンへの依存がなくなることです。Cascade のメモリはローカルにあり、それに代わるものの多くも同様です。Claude Code 自体の知識は、チェックアウトしたファイル内に存在します。外部ストアを使用することで、2台目のノート PC、コンテナ、あるいはチームメンバーのセッションでも、ゼロからではなく同じ知識ベースから開始できます。
3つ目は、複数のセッションを実行するときに現れます。Claude Code ではセッション間でメッセージを送り合えるようになり、連携に便利ですが、メッセージは実行中の2つのセッション間で渡されるテキストに過ぎず、共有された基盤ではありません。ストアがあれば、来週実行する4回目のセッションでも、最初のセッションが学んだ内容を把握できます。
そして、次のツール変更のコストが劇的に下がります。Cascade の EOL は事前に予告された明確な期日がありましたが、それでも多くの人が蓄積されたコンテキストを失いました。二度と繰り返したくない移行作業とは、移行先のツール内部に再び知識を閉じ込めてしまうことです。
移行のベストプラクティス
アンインストールする前に古いエージェントを問い詰める
これは誰もがスキップしがちで、かつ唯一、本当に取り返しのつかないステップです。自動生成されたメモリは、あなたがかつて一度だけ口にしたことの蓄積です。エージェントがプロジェクトについて何を知っているか、どのような規約に従っているか、何を避けているかを尋ね、アンインストールする前にその回答を書き留めておきましょう。
フォールバックを移行と勘違いしない
Devin Desktop がフォールバックとして .windsurf/rules/ を読み込むことは、古いルールがまだ機能していることを意味し、何もする必要がないと錯覚させがちです。別のエディタに移行する場合、そのフォールバックは無意味です。Claude Code はそれらのパスを一切読み込みません。
12,000文字の制限をガイドラインとして維持する
Windsurf の合計ルール制限は、強制的に内容を厳選させる効果がありました。CLAUDE.md にはそうした強制力がないため、結果としてモデルがすべてを処理しきれないほどファイルが肥大化しがちです。文字数の予算を決めて、意図的にそれを維持してください。
移行のついでにスクリプトを監査する
リブランドによってツールのパスが移動し、スクリプトは追従しませんでした。Windsurf のパスを参照しているものは、すでに破損しているか、間もなく破損します。計画的な移行のタイミングで修正する方が、CI で破損を発見するよりもはるかに低コストです。
再構築時にルールと知識を分離する
CLAUDE.md は、すべてのタスクで読み込まれる短い永続的なルールのためのものです。理由、履歴、参照資料は、ドキュメントや、関連するタイミングで取得されるストアに配置すべきです。すべてを1つの長いルールファイルとして再構築すると、かつて文字数制限が防いでくれていた問題が再発することになります。
結論
Windsurf から Claude Code への移行は、コストの全く異なる2つの作業から成り立ちます。ルールの移行は機械的です。.windsurfrules、.windsurf/rules/、.devin/rules/ を収集し、スコープごとに分類して、~/.claude/CLAUDE.md、コミットされたルートの CLAUDE.md、およびサブディレクトリのファイルや参照ドキュメントとして配置します。一方、Cascade のメモリの置き換えは、決して機械的ではありません。自動生成かつローカルに保存され、エクスポート機能もないため、回収する唯一の方法は、離れる前にエージェントが何を知っているかを直接尋ねることです。
7月1日の Cascade のサービス終了から学ぶべき教訓は、Windsurf に限った話ではありません。製品の内部に存在するメモリレイヤーの寿命は、その製品の寿命と運命を共にします。エディタが読み込む外部ストアにメモリを保持しておくことで、次のリブランド、サービス終了、あるいは心変わりがあったとしても、再構築ではなく単なる設定変更で済むようになります。