実際に移行されるもの
スキルは、ディレクトリを移動するだけです。 Zed のスキルは「グローバルで使用する場合は ~/.agents/skills/ に、プロジェクトローカルで使用する場合はプロジェクトの .agents/skills/ フォルダに」インストールされ、スキルとは「メタデータと指示を含む SKILL.md ファイルが格納されたフォルダ」を指します。Claude Code の構成もパスが異なるだけで同じ考え方です。個人用は ~/.claude/skills/<skill-name>/SKILL.md、プロジェクト用は .claude/skills/<skill-name>/SKILL.md に配置されます。フォルダをコピーし、親ディレクトリの名前を変更すれば完了です。
どちらのツールも、スキルのロード方法は同じです。Zed：「デフォルトでは、エージェントは自律的にスキルを検出します。システムプロンプト内でインストールされているすべてのスキル（名前と説明）のカタログを確認し、タスクがスキルの説明と一致したときに skill ツールを呼び出します。」Claude Code：「Claude は関連性がある場合にスキルを使用します。または、/skill-name で直接呼び出すこともできます。」
指示ファイルの内容は、名前を変更して移行します。 Zed が実際に読み込んでいたファイルの内容を CLAUDE.md にします。もしそのファイルがすでに CLAUDE.md であったなら、作業は完了です。ただし、次のセクションを再確認してください。なぜなら、それはリストのより上位にあるファイルが一切存在しなかった場合にのみ、Zed がそれを読み込んでいたことを意味するからです。
個人用レイヤーは、別の場所に移動します。 Zed の個人用指示ファイルは ~/.config/zed/AGENTS.md（Windows の場合は %APPDATA%\Zed\AGENTS.md）にあります。Claude Code におけるこれに相当するものは ~/.claude/CLAUDE.md であり、「すべてのプロジェクトに対する個人設定」として説明されています。
これ以外にきれいに移行できるものはなく、さらに2つの挙動が異なります。
優先順位が双方向で逆転します。 Zed は「競合が発生した場合、プロジェクトの指示が個人用の AGENTS.md を上書きする」と明記しています。一方、Claude Code は上書きを一切行いません。「検出されたすべてのファイルは、互いに上書きされるのではなく、コンテキストに結合されます」。ファイルシステムのルートから順に並べられ、2つのファイルの内容が矛盾している場合、「Claude は任意に一方を選択する可能性があります」。
そしてスキルに関しては、逆のルールが適用されます。Claude Code のルールは「レベル間において、エンタープライズは個人用を上書きし、個人用はプロジェクト用を上書きする」となっています。具体的な例として、「~/.claude/skills/ とプロジェクトの .claude/skills/ の両方に deploy スキルがある場合、/deploy は個人用のものを実行する」とされています。Zed ではプロジェクトスコープのファイルが競合に勝利していましたが、Claude Code では個人用のスキルが勝利します。あなたとチームメンバーが同じ名前のスキルを持っている場合、同じリポジトリであっても異なる挙動を示すことになります。
Zed の互換ファイルは読み込まれなくなります。 .rules、.cursorrules、.windsurfrules、.github/copilot-instructions.md は、すべて Zed がプロジェクトの指示として喜んで読み込むものです。Claude Code はデフォルトでこれらを一切読み込みません。.clinerules は唯一の部分的な例外で、CLAUDE_CODE_NEW_INIT=1 が設定されている場合にのみ /init がそれを検出し、それ以外の場合は黙ってスキップします。これまで指示を互換ファイル名で保存していた場合、それらは認識されなくなります。
Zed のスキル配布メカニズムは引き継がれません。 Zed では、自己完結型の zed://skill?data=… リンクとしてチームメンバーにスキルを渡すことができます。これは「SKILL.md の全内容を埋め込む（base64urlエンコード）ため、受信者はプロジェクトやレジストリへのアクセス権を必要としない」という特徴があり、「明示的に保存するまでディスクには何も書き込まれないため、共有リンクによって誰かのエージェントに指示が勝手にインストールされることはない」という優れた特性を持っています。また、コミュニティレジストリである skills.sh からインストールすることもできます。これらは配布経路であり、スキルそのものではありません。ファイルは移行できますが、共有ワークフローは移行できません。
スキルごとの権限の挙動が異なります。 Zed では、「エージェントが作成またはインストールしたスキルを呼び出す際、Zed は他のツールと同じ権限フローを使用して、許可または拒否を求めます」。また、スキルごとのデフォルト設定も可能です。Claude Code には独自の権限モデルがあり、Zed のスキルで設定していた可能性のある disable-model-invocation トグルに直接対応するものは、コピーするファイル内には存在しません。」
手動移行の手順
ステップ 1: Zed が実際に読み込んでいたファイルを確認する
これが移行のすべてであり、コマンド1つで確認できます。
リポジトリのルートにある候補ファイルを、Zed の優先順位に従ってリストアップし、最初に存在するものを確認します。
ls -1 .rules .cursorrules .windsurfrules .clinerules \
.github/copilot-instructions.md AGENT.md AGENTS.md CLAUDE.md GEMINI.md 2>/dev/null出力の最初の行が、現在有効な指示ファイルです。それより下にあるものはすべて、Zed においては無駄なデータ（デッドウェイト）となっていました。何ヶ月も放置されていたり、優先されていたファイルと矛盾していたりした可能性があります。
考慮すべき結果は3つあります。優先されたファイルが CLAUDE.md であれば、何もする必要はありません。AGENTS.md であった場合、Claude Code はそれを読み込まないため、名前を変更するかインポートする必要があります（次のステップ）。.cursorrules のような互換ファイルであった場合は、その内容を CLAUDE.md に移動する必要があります。移行先にはそのファイル名を読み込む機能がないからです。
また、~/.config/zed/AGENTS.md にある個人用ファイルも確認してください。Zed では「プロジェクト優先」のルールがあるため、プロジェクトファイルと競合していた内容は無視されていました。しかし、Claude Code ではそれらが結合されるため、上書きされていたと思っていた設定が再び有効になってしまいます。
ステップ 2: スキルを移動し、指示レイヤーを再構築する
まずは機械的に行えるスキルから進めます。 ~/.agents/skills/* を ~/.claude/skills/ にコピーし、プロジェクトの .agents/skills/* を .claude/skills/ にコピーします。ディレクトリ名が入力するコマンド名になり、Claude Code はフロントマターの description を読み取って自動ロードのタイミングを決定するため、同じ説明文がそのまま機能し続けます。
配置後に知っておくべきことが2つあります。カスタムコマンドとスキルは、Claude Code 側では同じものとして扱われます。「.claude/commands/deploy.md にあるファイルと、.claude/skills/deploy/SKILL.md にあるスキルは、どちらも /deploy を作成し、同じように動作します」。また、ネストされたスキルはコンテキストに応じてロードされます。「スキルは、作業ディレクトリ配下のネストされた .claude/skills/ ディレクトリからもロードされます」。これは「Claude がサブディレクトリ内のファイルを読み書きするとき」に利用可能になります。これは、最上位ディレクトリが示唆するよりも、Zed のプロジェクトスコープに近い挙動です。
同梱されているセットとの名前の衝突に注意してください。プロジェクトのスキルは、組み込みのスキルを置き換えることができます。「プロジェクトの .claude/skills/ にある code-review スキルは、同梱されている /code-review を置き換えます」。通常は問題ありませんが、予期せぬ挙動になることがあります。
次に指示ファイルです。以下の2つの方法から選択します。
そのリポジトリで今後 Claude Code のみを使用する場合は、CLAUDE.md に名前を変更します。あるいは、AGENTS.md を信頼できる唯一の情報源（Source of Truth）として残し、それをインポートする CLAUDE.md を追加します。ドキュメント化されているパターンは、ファイルの先頭に @AGENTS.md と1行記述する方法です。これにより、「Claude はセッション開始時にインポートされたファイルをロードし、その後に CLAUDE.md の残りの内容を追加します」。チームメンバーがまだ Zed を使用している場合や、他のエージェントが AGENTS.md を読み込む場合は、この方法が適しています。2つのファイルが別々に更新されて乖離するのを防ぎ、1つのファイルをマスターとして維持できるからです。
1つのファイルだったものを、スコープ付きのルールに分割します。 Claude Code には、Zed にはないコンテナが用意されています。.claude/rules/ 内のファイルにフロントマターの paths: フィールド（globパターン）を指定すると、「Claude が指定されたパターンに一致するファイルを操作しているときにのみ適用」されます。paths フィールドのないルールは、「起動時に .claude/CLAUDE.md と同じ優先順位でロード」されます。Zed の指示ファイルに「フロントエンドの作業をするときは…」といったセクションがあった場合、そのセクションは常に有効なテキストではなく、パススコープのルールとして定義できるようになります。
また、自動的に有効になる機能についても知っておきましょう。 Claude Code には、Zed にはない第2のメカニズムがあります。それが「自動メモリ（auto memory）」です。これはデフォルトで有効になっており、Claude が自身のために書き留めたメモを ~/.claude/projects/<project>/memory/ に保存します。記録されるメモには user、feedback、project、reference の4つの種類があり、「コードベースから推測できること」や「CLAUDE.md ファイルにすでに記載されていること」はスキップされます。1週間ほど使用した後に /memory を実行して内容を確認してみてください。一般的な仕組みについては、why Claude Code forgets project context（Claude Code がプロジェクトのコンテキストを忘れる理由）で解説しています。
実際に何がロードされたかを確認するには、/context を実行し、Memory files の下にあるリストを確認します。これが確実な答えであり、ドキュメントでも最初のデバッグステップとして推奨されています。なぜなら「そこにファイルが表示されていない場合、Claude はそれを認識できていない」からです。
より良い方法：ファイル名にエージェントの知識を左右させない
一歩引いて、この移行作業が実際には何であったかを見つめ直してみましょう。ファイル名が変更され、フォルダが移動されました。そして、挙動が静かに変化するという最もリスクの高い部分は、完全に「ローダーがどのファイルを選択したか」に起因していました。
これは Zed や Claude Code の問題ではありません。永続的な知識が、ツールごとに検出ルールの異なるファイルに保存されている場合に発生する問題です。Zed は9つのリストから最初に一致したものを採用します。Claude Code は見つかったすべてのファイルを結合し、矛盾がある場合は任意に選択します。どちらのツールも、リクエストごとに常に送信されるコンテンツの量に上限を設けています。
これこそが MemoryLake が保持するものです。プロジェクトの永続的な知識をツールがクエリできるレイヤーに保持するため、ファイル名は単なる設定の好みに過ぎなくなり、エージェントの理解がそれに依存することはなくなります。セットアップは3つのステップで完了します。
ステップ 1: API キーを作成する
MemoryLake にサインインし、API キーを作成します。接続するすべてのツールで共通の認証情報を使用できます。
ステップ 2: 最初のメモリをアップロードする
1つの項目につき1つの主張を含む、短いエントリを作成します。ステップ1の調査が新鮮なうちに書き留めておくべき内容は以下の通りです：
無視されていたファイルに埋もれていた決定事項。 もし .cursorrules が AGENTS.md によって半年間シャドーイング（無視）されていた場合、そこには誰も適用していなかった制約が含まれています。削除する前に必ず目を通してください。
理由が添えられた決定事項。 「負荷がかかるとリードレプリカに遅延が発生するため、マイグレーションは追加のみとする」。指示ファイルにはポリシーのみが記載されますが、理由を添えることで、代替案が再び提案されるのを防ぐことができます。
このコードベースですでに却下されたアプローチ。 指示ファイルにもコミットメッセージにも現れず、新しいセッションが始まるたびに繰り返し再提案されてしまうカテゴリーです。
どこにも明記されていない環境に関する事実。 CI でのみ失敗するテスト、ドキュメント化されていないレート制限、2つのマイグレーション間の順序要件などです。
ステップ 3: AI とエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセス可能です。そのため、Claude Code、Codex、OpenClaw などの MCP ネイティブなエージェントは MCP サーバーを指定することで接続でき、他のアシスタントは API を介して同じメモリを読み込むことができます。これにより、同じ推論プロセスのコピーを2つ維持することなく、同じリポジトリで Zed と Claude Code を並行して実行できます。
3つの率直な制限事項があります。MemoryLake は、あなたの CLAUDE.md、AGENTS.md、またはスキルを書き換えることはありません。 これらは各ツールを制御するためのものであり、上記のローダーの挙動はツール固有のものです。メモリレイヤーがそれを変更することはありません。MemoryLake は、あなたやエージェントが保存した内容のみを保持するため、ステップ2は手動で行う必要があります。また、指示は強制的な設定ではなくコンテキストとして機能します。常に強制したいルールがある場合、Claude Code 自体の解決策はファイルではなくフック（hook）を使用することです。
実際に何が変わるのか
「どのファイルが有効か？」の確認が1行で済むようになります。 Zed は9つの候補から最初に一致したものを採用します。これでリストとその順序が明確になりました。
シャドーイングされていたファイルが地雷にならなくなります。 優先されなかったファイルを読み、重要な内容をマージしてしまえば、次の人を混乱させるような、忘れ去られた .cursorrules が残ることはありません。
スキルがツール固有のものではなくなります。 同じ SKILL.md が Zed、Claude Code、Cursor、Codex で動作します。一度書くだけで済みます。
指示ファイルが短くなります。 パススコープのルールを使用することで、「Xの作業をするとき」といったセクションがすべてのメッセージでロードされるのを防ぐことができます。
異なるエディタを使用しているチームメンバーがフォーク（分岐）状態になりません。 1つの信頼できる指示ファイルとクエリ可能なメモリレイヤーの組み合わせは、2つのファイルが別々に乖離していく状態よりもはるかに優れています。この構成については、what persistent memory actually means（永続メモリが実際に意味するもの）で解説しています。
Zed から Claude Code へ切り替える際のベストプラクティス
何かを変更する前に、優先されているファイルを確認する。 Zed は .rules から GEMINI.md までの間で最初に一致したものを読み込みます。それ以降のファイルはすべて無効でした。
シャドーイングされていたファイルを読み、削除する。 何ヶ月も適用されていなかった制約が含まれている可能性があります。
CLAUDE.md に名前を変更するか、そこから AGENTS.md をインポートする。 他のエージェントやチームメンバーがまだ AGENTS.md を読み込む場合はインポートし、そうでない場合は名前を変更します。
スキルをフォルダごと移動し、名前の衝突を確認する。 Claude Code では個人用のスキルがプロジェクト用のスキルよりも優先されます。これは Zed の指示の優先順位とは逆です。
個人用ファイルの重要性が増すことを想定する。 Zed ではプロジェクトの指示が個人用ファイルを上書きしていましたが、Claude Code では両方が結合されます。
常に有効なテキストをパススコープのルールに分割する。 フロントマターの paths: フィールドは、Zed にはなかった便利なコンテナです。
メモリではなく /context で検証する。 実際にロードされたのは Memory files リストに表示されているものです。
1週間後に自動メモリフォルダを開いてみる。 デフォルトで有効になっており、指示ファイルにあえて記載しなかった内容が保持されています。
推論プロセスを指示ファイルに含めない。 どちらのツールも保持できる容量に上限があり、推論プロセスは最初にカットされる対象です。この一般的な問題については、why agents ignore the instruction files you wrote（エージェントが作成した指示ファイルを無視する理由）で解説しています。
結論
Zed から Claude Code への移行は単なる名前の変更のように見え、実際その通りですが、その名前変更にこそリスクが潜んでいます。Zed は AGENTS.md が CLAUDE.md よりも優先される9つの候補リストから、最初に一致したプロジェクト指示ファイルを選択します。一方、Claude Code は CLAUDE.md を読み込み、AGENTS.md は読み込みません。そのため、これまでエージェントを制御していたファイルが、明日エージェントを制御するファイルとは異なる可能性があります。Zed のドキュメントでも、そのローダーが他のエージェントを制御していると仮定しないよう警告されています。
スキルは簡単な方です。どちらのツールも SKILL.md を含むフォルダであるため、~/.agents/skills/ を ~/.claude/skills/ に変更するだけで、説明文はそのまま機能し続けます。優先順位の逆転（Zed ではプロジェクトの指示が優先されましたが、Claude Code では個人用のスキルが優先されます）に注意し、Zed の互換ファイル名は移行先では読み込まれないことを覚えておいてください。
どのファイルが有効だったかを調査し、無効だったものをマージし、名前変更かインポートかを選択し、常に有効なテキストをパススコープのルールに分割し、決定事項や却下されたアプローチを両方のエディタからクエリできる場所に配置しましょう。そうすれば、ローダーの優先順位リストを頭の中に留めておく必要はなくなります。