実際に移行されるもの
スキルはそのまま移行されます。 これは良いニュースであり、ほとんどのツールの組み合わせよりも優れています。Windsurf はワークスペースのスキルを .windsurf/skills/ に、グローバルなスキルを ~/.codeium/windsurf/skills/ に保持しますが、そのドキュメントには「エージェント間の互換性のために、Devin Desktop は .agents/skills/ および ~/.agents/skills/ にあるスキルも検出します」と付け加えられています。Zed は、グローバル用の ~/.agents/skills/ とプロジェクトローカル用の <worktree>/.agents/skills/ の、まさにこれら2つの場所からスキルを読み込みます。スキルがすでに .agents/skills/ にある場合、両方のツールは変換なしで同じファイルを読み込みます。
また、どちらも同じ2つのフィールドを使用した段階的開示（progressive disclosure）を採用しています。Windsurf：「デフォルトでは、スキルの名前と説明のみがモデルに表示されます。完全な SKILL.md のコンテンツとサポートファイルは、Cascade がスキルの呼び出しを決定したとき（または @mention したとき）にのみ読み込まれます。」 Zed：「システムプロンプト内でインストールされているすべてのスキル（名前と説明）のカタログを表示し、タスクがスキルの説明と一致したときに skill ツールを呼び出します。」 同じメカニズム、同じ name と description のフロントマター、同じ disable-model-invocation フラグが両側に存在します。
ルールファイルはバイトデータとして移行されますが、意味が変わります。 Windsurf のワークスペースルールは、.devin/rules/*.md（推奨）または .windsurf/rules/*.md（フォールバック）に1ファイルにつき1つずつ配置され、そのドキュメントでは「ワークスペースのルートにあるレガシーな単一ファイル .windsurfrules も引き続き読み込まれます」と確認されています。ルートの AGENTS.md は「同じルールエンジンによって処理されます。ルートレベル = 常にオン、サブディレクトリ = そのディレクトリに対する自動 glob」となります。
Zed のプロジェクト指示の読み込みは、これとは異なります。そのドキュメントには次のように記載されています。「プロジェクト指示ファイルは現在のプロジェクトに適用されます。Zed はこのリストの中で最初に一致したファイルを使用します。」
.rules,.cursorrules,.windsurfrules,.clinerules,.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,GEMINI.md
位置を数えてみてください。.windsurfrules は3番目です。AGENTS.md は7番目です。最初に一致したものが優先され、1つのファイルのみが使用されます。2025年からの .windsurfrules をまだ保持しているリポジトリでは、Zed はそのファイルを読み込み、今朝作成した AGENTS.md を無視します。警告もエラーもなく、確認しようと思うようなログへの記録もありません。
アクティベーションモードは移行されません。 Windsurf は trigger フロントマターフィールドで宣言される4つのモードをドキュメント化しており、その表にはそれぞれのコンテキストコストが示されています：always_on（「すべてのメッセージのシステムプロンプトに完全なルールコンテンツが含まれる」）、model_decision（「システムプロンプトには説明のみが表示される。Cascade は説明が関連していると判断したときに完全なルールファイルを読み込む」）、glob（「Cascade が glob パターンに一致するファイルを読み込みまたは編集するときにルールが適用される」）、および manual（「ルールはシステムプロンプトに含まれない。@rule-name と入力してアクティブにする」）。
これら4つのモードは、Windsurf ユーザーが最も細かく調整するコントロールサーフェスであり、この区別が失われることが、Windsurf がプロジェクトルールを忘れる問題 でドキュメント化した不満の最も一般的な原因です。ただし、ここではルールはまだディスク上に存在し、それらが宣言されていたモードがもはや存在しないという点が異なります。
Zed には4つではなく2つのサーフェスがあります。指示（Instructions）は「Zed Agent の常にオンのコンテキスト」です。スキル（Skills）は、カタログからエージェントによって呼び出されるか、スラッシュコマンドまたは @skill メンションによって手動で呼び出されます。Zed のスキルフロントマターは name、description、disable-model-invocation の3つのフィールドをドキュメント化しており、ページには「近い将来、Agent Skills 仕様で推進されている他のフィールドも導入する予定です」と記されています。そのため、glob パターンでスコープ定義された Windsurf のルールは、現在 Zed 側でそのスコープを引き継ぐフィールドを持っていません。エージェントがマッチングするための説明（description）として再表現する必要があります。
ディレクトリでスコープ定義された指示は、そのスコープを失います。 Windsurf では、サブディレクトリ内の AGENTS.md は「<directory>/** の自動生成パターンを持つ glob ルール」になるため、モノレポではエリアごとに1つの指示ファイルを無料で保持できます。Zed の指示ページでは、その優先順位リストから選択された単一のプロジェクト指示ファイルについて説明されており、サブディレクトリ内の指示ファイルの検出については説明されていません。4つのレベルにある4つの AGENTS.md ファイルが Zed に届いても、そのうちの3つにはドキュメント化された役割がありません。
自動生成された記憶（メモリ）はその場に留まります。 Windsurf 自身のガイダンスはこれについて率直です。自動生成された記憶は「それらが作成されたワークスペースに関連付けられ、ローカルの ~/.codeium/windsurf/memories/ に保存されます」、「リポジトリにはコミットされません」、そして「自動生成された記憶はあなたのマシン上にのみ存在します」。Windsurf の推奨事項は、どこかへ移行する前に、依存しているものをルールまたは AGENTS.md に昇格させることです。Zed のドキュメントでは、エージェントコンテキストの永続化サーフェスとして指示とスキルが説明されていますが、自動生成された記憶ストアについては説明されていません。そのため、Zed 側にはそれらのファイルが着地する場所がありません。これらに依存していた場合は、まずそれらを昇格させてください。このアドバイスの背景にあるワークスペーススコープの動作は、Windsurf の Cascade がコンテキストを失うのを防ぐ方法 のテーマです。
ソースドキュメントを読む際、ブランディングに関する注意点が1つあります。Windsurf のドキュメントには現在、全体にわたって Devin Desktop の名前が使われており、その記憶（memories）ページでは依然として Cascade が現在形（present tense）で説明され、「Devin: Open Cascade Migration Wizard」コマンドを指し示しています。しかし、Devin Desktop の変更履歴では、2026年9月8日に Cascade が削除されています。そのページに従っている場合、お使いのビルドにはもはや存在しないエージェントについて説明されていることを想定してください。この移行のルールフォルダに関する半分については、Windsurf と Devin のルールフォルダの統合 で別途カバーしました。このガイドは、Windsurf 内部での再編成ではなく、Zed への移行に関するものです。
手動移行の手順
ステップ 1: 1つのプロジェクト指示ファイルを選択し、おとりを削除する
新しいものを書く前に、リポジトリのルートにある、Zed の優先順位リストに表示されているすべてのファイルをリストアップします。Windsurf の履歴があるリポジトリでは、少なくとも .windsurfrules、場合によっては .rules、以前のツールからの .cursorrules、そして AGENTS.md が存在することが予想されます。
どれを信頼できる唯一の情報源（オーソリティ）にするかを決定します。AGENTS.md が妥当な答えです。これは Windsurf も処理するファイルであり、他のツールも認識するもので、Zed のリストでは7番目です。つまり、それより上にあるものはすべて削除する必要があります。より上位のファイルを削除するか、名前を変更してください。名前の変更の方が安全です。.windsurfrules を docs/legacy-windsurf-rules.md に移動すれば、ローダーからは見えなくなりつつ、コンテンツは引き続き読み取ることができます。
その後、統合します。Windsurf では、それぞれ12,000文字の制限があるルールごとに1つのファイルが提供されていましたが、Zed では合計で1つのファイルが提供されます。.devin/rules/*.md の中身を AGENTS.md にマージし、各ルールの見出しを維持して区別できるようにします。Windsurf で always_on だったルールは、ここに配置します。そうでない場合は、次のステップのために取っておきます。
読み直すのではなく、矛盾によって検証します。普段は使用しない命名規則など、意図的に珍しい行を AGENTS.md に追加し、エージェントにそれを適用するよう依頼します。エージェントがそれを無視する場合、より上位のファイルがまだ優先されています。これは、エージェントが指示ファイルを無視する理由 で推奨しているのと同じチェック方法であり、ツリーを監査するよりも迅速です。
ステップ 2: 3つの条件付きモードをスキルに変換し、カタログの容量制限に注意する
always_on ではなかったものはすべてスキルになります。Zed 自身の移行ノートでも、廃止されたルール（Rules）機能について同様のことが述べられています。「再利用可能でオンデマンドなルールはスキル（Skills）になり、デフォルトで常にオンのルールは個人の AGENTS.md になります。」
変換は、どのモードから開始したかによって異なります。manual ルールはきれいにマッピングされます。スキルになり、/skill-name または @skill-name と入力すると、@rule-name と同様に呼び出されます。model_decision ルールもきれいにマッピングされます。どちらのツールも説明から判断するため、説明のテキストをそのまま再利用できます。書き換えが必要なのは glob ルールです。パターンを文章にする必要があります。**/*.test.ts は、テストファイルの作成または修正時にこのスキルが適用されることを示す説明に変換します。Zed のガイダンスでは、その表現方法について「具体的なタスクタイプやトリガーフレーズを含めること」と明記されています。
Zed 側には、Windsurf には相当するものがなく、すべて静かに失敗する3つの制約があります。
カタログには容量制限（予算）があります。「すべてのスキルの名前と説明の合計サイズは 50KB に制限されています。収まらないスキルは、UI に警告が表示された上でカタログから除外されます。」 説明は「1024バイト未満」に抑える必要があります。冗長な Windsurf のルール説明を何十個も移植するチームは、この制限を超える可能性があります。
レイアウトはフラットでなければなりません。「スキルはスキルルートの直接の子でなければなりません。~/.agents/skills/group/my-skill/ のようなネストされたフォルダは検出されません。」 Windsurf のスキルをサブフォルダに整理していた場合は、それらをフラットにしてください。
そして、プロジェクトローカルのスキルには信頼が必要です。「プロジェクトローカルのスキルは、信頼されたワークツリーからのみ読み込まれます。新しくクローンされたプロジェクトや信頼されていないプロジェクトからのスキルは、信頼を付与するまでカタログやスラッシュコマンドから除外されます。」 新規クローンでは、信頼を付与するまでプロジェクトスキルは単に存在しない状態になります。これは賢明なセキュリティのデフォルトですが、最初の1時間は混乱の原因になります。
知っておく価値のある2つの小さな違い。Zed は、グローバル優先の習慣が予想するのとは逆の方向で名前の衝突を解決します。「グローバルスキルとプロジェクトローカルスキルが同じ名前を共有している場合、プロジェクトローカルスキルが優先されます。」 そして、プロジェクトの指示は個人の指示よりも優先されます。「プロジェクトの指示と個人の AGENTS.md が競合する場合、プロジェクトの指示が優先されます。」 これは、個人の設定を最も高く評価するツールとは逆です。
より良い方法：両方のエディタが読み取れる1つの意思決定レイヤー
上記の移行はファイルを移動するだけです。ルールが存在する背後にある理由が、そもそもファイルの中に存在しなかったという根本的な問題は解決しません。
作成した AGENTS.md には、特定の HTTP クライアントを使用するように記載されているかもしれません。しかし、もう一方のクライアントが試行され、誰も望まないリトライ動作のために断念されたという経緯は記載されていません。統合の過程でルールがドロップされると（12個のファイルを1つにまとめれば、確実にいくつかのドロップが発生します）、ルールはその存在理由とともに消え去り、次のエンジニアがまた一から議論をやり直すことになります。
MemoryLake は、その2番目のカテゴリ、つまり決定事項、却下された代替案、どのエディタが開いているかに関係なく真である制約を保持します。これは両方のツールの外部に存在するため、このような移行を行っても設定は移動し、意思決定の背景はそのまま残ります。ここから始めましょう。
ステップ 1: API キーを作成する
プロジェクト用のワークスペースを作成し、API キーを生成します。エディタではなくプロジェクトにスコープを限定することで、このレイヤーは今回のツール変更だけでなく、次のツール変更時にも存続します。
ステップ 2: 最初の記憶（メモリ）をアップロードする
これは統合した後ではなく、統合する前に行ってください。.devin/rules/*.md ファイルを1つずつ確認し、各ルールが存在する理由を記録します。AGENTS.md に入るルール自体ではなく、その背後にある決定事項です。Windsurf の自動メモリがキャプチャした、実際に依存しているものも追加してください。それらのファイルは1台のマシン上にあり、どこにもコミットされていません。
ステップ 3: AI とエージェントを接続する
Zed のエージェントを接続し、移行期間中に両方を実行している場合は Windsurf も接続します。両方が同じ決定セットを読み取るため、まだ移植していないルールであっても、すでに切り替えたエディタでその意思決定の背景を利用できます。
実務における変化
サイレントオーバーライド（静かな上書き）の問題が一度可視化されます。優先順位リストを確認し、おとりを削除すれば完了です。3ヶ月後に、古い .windsurfrules がすべてのセッションを静かに支配していたことに気づくようなことはありません。
統合による情報の損失がなくなります。意思決定の背景が別の場所に存在していれば、12個のルールファイルをルールごとのセクションに分けた1つの AGENTS.md に折りたたんでも問題ありません。ファイルが唯一の記録であった場合、それは本当の損失になります。そしてそれこそが、クリーンな切り替えと、Zed がプロジェクトコンテキストを忘れる問題 で説明されているパターンの違いです。後者では、エディタは正しく設定されているものの、知識が単にそこに存在していません。
移行中に両方のエディタを実行しても、乖離（ドリフト）が発生しなくなります。チームが1日の午後に一斉に切り替えることは稀であり、誰かしらはスプリントの間 Windsurf に留まります。1つの共有レイヤーがあれば、指示ファイルが異なっていても、チームの両半分が同じ決定セットに基づいて作業できます。
Zed 導入初月のベストプラクティス
テストしたリポジトリだけでなく、すべてのリポジトリで優先順位リストを監査してください。.cursorrules や .clinerules も AGENTS.md より優先され、3つのツールを経由してきたモノレポには、それらすべてが含まれている可能性があります。
スキルの説明は、要約ではなくトリガー条件として記述してください。Zed のガイダンスでは、「PDF の処理、テキストの抽出、またはフォームの入力を行う場合に使用する」の方が「PDF に役立つ」よりも優れているとされています。説明は、以前 glob パターンが行っていた役割を担うことになるため、これは各スキルにおいて最も効果的な文章になります。
カタログは意図的にスリムに保ってください。すべての説明が同じ 50KB の枠を争い、ドロップされたスキルは UI の警告としてしか表示されません。網羅的なスキルよりも、数が少なく鋭いスキルの方が優れています。
Zed のローダーは他のエージェントを支配しないことを覚えておいてください。その指示ページには直接こう書かれています。「外部エージェントやターミナルスレッドは、独自のネイティブ指示ファイルを直接読み取ることがあります。Zed の指示ローダーがそれらのエージェントを制御していると仮定しないでください。」 Zed を介して外部エージェントとして Claude や Codex を実行する場合、それらは独自のファイルを読み込みます。これは、Zed の外部エージェントに継承されないコンテキストを与える方法 でマッピングした境界線です。
スキルの編集におけるキャッシュの詳細に注意してください。「スキルの name または description を変更すると、現在のセッションにおけるモデルのプロンプトキャッシュが無効になります。」 セッションの途中で中身（body）は自由に編集し、説明（description）の書き換えはまとめて行いましょう。
結論
Windsurf と Zed は、ほとんどのツールの組み合わせよりも多くの点で一致しています。スキルのパス、スキルのフォーマット、そして段階的開示モデルを共有しているため、この移行のスキルに関する半分はほぼコストなしで行えます。
彼らは、人々の数日分に相当するコストを発生させる1つの点において意見が異なります。Windsurf は多くのルールファイルを検出し、ファイルごとに挿入するかどうかを決定しますが、Zed は固定された9つのエントリのリストから最初に一致したものを読み込みます。このガイドから1つだけ行動を起こすなら、リポジトリのルートにある AGENTS.md より優先順位の高いすべてのファイルを削除することにしてください。そして2つ目の行動を起こすなら、12個のファイルを1つにマージする前に、ルールが存在する理由を書き留めることにしてください。