実際に移行できるもの
プロジェクトルール（Project Rules）はほぼそのまま移行できます。 Warpのプロジェクトルールは、リポジトリのルートまたはサブディレクトリにある「AGENTS.md ファイル（または後方互換性のための WARP.md）」に保存されています。Claude Codeは、同じ形式の CLAUDE.md を読み込みます。内容はそのまま移行でき、ファイル名と解決順序だけが変更されます。
ファイル名に関する1つの詳細に注意が必要です。 Warpのドキュメントには、「Warpが認識できるように、ファイル名はすべて大文字にする必要があります（例：agents.md や Agents.md ではなく AGENTS.md）」と明記されています。Claude Codeは CLAUDE.md を探します。ファイルをコピーした後に名前を変更し忘れると、Warpは読み込みを停止し、Claude Codeは読み込みを開始しません。
グローバルルール（Global Rules）はユーザー指示（user instructions）になりますが、注意点があります。 Warpのグローバルルールは「すべてのプロジェクトとコンテキストに適用」され、Warp DriveのRulesペインで管理されます。各ルールにはオプションの名前と「ルールが何を行い、いつ適用されるか」の説明があります。Claude Codeの最も近い機能は ~/.claude/CLAUDE.md で、「すべてのプロジェクトに対する個人設定」と説明されています。内容はマッピングされますが、メタデータはマッピングされません。ルールごとの説明フィールドを保持する場所がないため、適用タイミングを説明に依存していたWarpのグローバルルールは、無条件の指示になってしまいます。
ルールの優先順位の仕組みが変わります。 Warpは競合を次の順序で解決します。「1. 現在のサブディレクトリのプロジェクトルールファイル内のルール、2. ルートディレクトリのプロジェクトルールファイル内のルール、3. グローバルルール」。Claude Codeは4つのスコープを「読み込み順（最も広いスコープから最も具体的なスコープへ）でロードするため、プロジェクトの指示はユーザー指示の後にコンテキストに表示されます」— 管理ポリシー、ユーザー、プロジェクト、そして CLAUDE.local.md の順です。意図は同じですがメカニズムが異なり、Claude Code'sのドキュメントには「2つのルールが矛盾する場合、Claudeはどちらかを任意に選択することがあります」と、その失敗パターンが率直に記載されています。
サブディレクトリの読み込みは似ていますが、同一ではありません。 Warpは「ルートおよび現在のディレクトリにある AGENTS.md（または WARP.md）を自動的に適用」し、その他のサブディレクトリについては「そのサブディレクトリのルールファイルも含めるようベストエフォートで試みます」。Claude Codeは起動時に「作業ディレクトリより上のディレクトリ階層にある」ファイルをロードし、「サブディレクトリ内のファイルは、Claudeがそれらのディレクトリ内のファイルを読み込む際にオンデマンドでロード」されます。どちらもサブツリーに対しては遅延ロード（Lazy load）を行いますが、トリガーが異なります。
コードベースコンテキスト（Codebase Context）は移行できません。 Warpは「エージェントがコードを理解できるように、Gitで追跡されたコードベースをインデックス化」し、特に「Warpのサーバーにはコードは保存されません」。無視ファイルで調整したり、Synced、Discovering files、Failed、Codebase too largeなどのステータスを確認したりできます。これはインデックスでありドキュメントではないため、エクスポートするものはありません。Claude Codeは代わりにオンデマンドでファイルを読み込みます。失われるのはそのインデックスが提供していた検索品質であり、得られるのは同期を待つ必要がなくなることです。
Agent Memoryが最大のポイントであり、その境界線は明確です。 WarpのAgent Memoryは「Warpのエージェントに、Warp Agent、Claude Code、Codexを含むサポートされているハーネス間で永続的な記憶を提供」します。これは本格的で成熟しており、個人、エージェント、チームのストア、新規エージェントでデフォルトでオンになる「自動記憶（Auto-memory）」、会話終了後の自動抽出（「新しい知識は既存の記憶とマージされるか、競合時には上書きされる」）、ストアごとの読み取り専用または読み書きアクセスとストアごとの指示、さらに「各記憶はどこから来たかを記録する」トレーサビリティ、そして「記憶へのすべての変更が記録される」監査可能性など、多くの機能を備えています。
これが移行に追従するかどうかは、2つの事実によって決まります。第一に、これは「リサーチプレビュー段階であり、デザインパートナー向けにチームごとに有効化されている」ため、ウェイトリストがあり、ほとんどの読者はそもそもこれを利用していません。第二に（これがデザインパートナーを驚かせる点ですが）、サードパーティ製ハーネスのサポートは「クラウドエージェントとして実行されている場合」に適用され、ドキュメントには「リサーチプレビュー期間中、サードパーティ製ハーネスをローカルで実行することはサポートされていません」と明記されています。
したがって、Agent Memoryを使用していて、自身のローカルターミナルで実行するClaude Codeに移行する場合、サポート対象外のパスになります。記憶自体はその場所に留まり（「記憶は、どのハーネスが読み書きするかに関係なく、その所有者（ユーザー、エージェント、またはチーム）に紐づいたままになります」）、Warpがそれを保持するシステムのままとなります。
手動での移行手順
ステップ 1: ルールの移動とスコープの設定
まずは、実際にコピーできるファイルから始めましょう。
リポジトリ内の各 AGENTS.md（または WARP.md）を、同じパスに一致する CLAUDE.md として作成します。ルートファイルはルートの CLAUDE.md へ、ui/AGENTS.md は ui/CLAUDE.md へ移行します。内容は変更しません。
次に、すべてを1つのファイルに詰め込むのではなく、スコープごとに分割します。Claude Codeのドキュメントでは、「CLAUDE.md ファイル1つあたり200行未満」に抑えることを推奨しています。なぜなら、「ファイルが長くなると、より多くのコンテキストを消費し、ルールの遵守率が低下する」ためです。Warpのルートファイルがそれを超えて肥大化している場合は、今が分割のタイミングです。Claude Codeの .claude/rules/ ディレクトリはトピックファイルを受け入れ、「すべての .md ファイルが再帰的に検出」されます。また、ルールは paths フロントマターでスコープを設定できるため、「指定されたパターンに一致するファイルをClaudeが操作している場合にのみ適用」させることができます。
このマッピングは意図的に行う価値があります。Warpのサブディレクトリのルールファイルが存在していた理由の一つは、Warpにガイダンスのスコープを制限する他の方法がなかったからです。Claude Codeでは、ネストされた CLAUDE.md として保持することも、パススコープのルールに変換することもできます。後者は、「すべてのAPIハンドラーは入力を検証しなければならない」といったルールに最適です。
グローバルルールは ~/.claude/CLAUDE.md に移動します。特定のプロジェクトに完全に個人的な内容については、プロジェクトルートの CLAUDE.local.md がその役割を果たし、.gitignore に追加します。
最後に、思い込みではなく実際に検証します。セッション内で /context を実行し、Memory files の下にあるリストを確認してください。これが、実際に何がロードされたかを確認するためのClaude Codeの公式な方法です。上記の移行ステップはどれも「中途半端に動いてしまう」類のものであり、これが Claude Codeがプロジェクトのコンテキストを忘れる理由の背景にある一般的なパターンです。
ステップ 2: ファイルに依存しない知識の扱いを決める
ここからは、コピーできない部分の対応です。
Agent Memoryを使用していた場合は、Warpの使用を停止する前に、それらのストアに何があるかを整理（インベントリ化）してください。トレーサビリティ機能（各記憶のソースが記録されている）がここで役立ちます。通常、価値のある素材はチームストアにあります（デプロイ手順書、レビュー規約、オンコール手順など）。それらを読み、現在も重要なものを書き留めてください。WarpのストアをClaude Codeのメモリディレクトリに変換するエクスポートパスは存在しないため、これは手動での読み取りと書き直しの作業になります。
Claude Codeには、その一部を受け取るための独自の自動レイヤーがあります。自動記憶（Auto memory）はデフォルトでオンになっており、Claudeは type フィールドでタグ付けされた4種類のノートを書き込みます。user（あなたの役割、専門知識、作業の好み）、feedback（あなたがClaudeに与えた修正や確認したアプローチ）、project（コードやGitの履歴からClaudeが導き出せない進行中の作業、期限、決定事項）、reference（プロジェクト外の情報を見つける場所）です。
これに依存する前に、その仕組みを理解しておきましょう。これは ~/.claude/projects/<project>/memory/ の下に MEMORY.md インデックスとともにプレーンファイルとして保存され、ロードされる範囲は制限されています（「セッションごとに最初の200行または25KB」）。そのスコープはGitリポジトリから派生した「リポジトリごと、ワークツリー間で共有」です。そして、Claudeは意図的に重複を避けます。「Claudeはコードベースから導き出せるものはすべてスキップ」し、「CLAUDE.md ファイルにすでに記載されている内容もスキップ」します。
2つのシステム間のギャップは品質ではなく、トポロジー（構成）にあります。Warpのストアはホスト型で、複数のエージェントにアタッチでき、チーム全体が使用するエージェントにストアをアタッチすることでチームと共有できます。Claude Codeの自動記憶はローカルで、リポジトリごと、そしてあなた個人のものです。前者から後者へ移行するということは、チームの共有知識が複数人のプライベートファイルになることを意味します。これは、誰かが辞めたときにチームのAIコンテキストを維持する方法で説明されている失敗パターンそのものです。
より良い方法：両方のツールが読み込める単一のストア
上記の手順はすべて1回限りの変換であり、手元にはローカルファイルが残り、チームで共有されていたレイヤーは失われてしまいます。変換作業を減らし、結果をより永続的なものにする第3の選択肢があります。それは、どちらのツールにも属さないストアに永続的な知識を保持することです。
これにより、移行の枠組みが再定義されます。Warpの記憶をClaude Codeの記憶に翻訳する代わりに、両方のツールから同じレイヤーを参照させ、ツール固有のファイルは小さく、ツール固有のままにしておきます。これは、次の移行（必ずいつか発生します）の際に、過去の遺物を発掘するような作業ではなく、単なるルールファイルの名称変更で済むことを意味します。MemoryLake は3つのステップでセットアップできます。
ステップ 1: APIキーの作成
サインインし、ダッシュボードからAPIキーを生成します。この資格情報はハーネスではなくあなた自身に紐づきます。これが重要な特性です。WarpのAgent Memoryがサードパーティ製ハーネスをサポートするのはWarpのクラウドエージェントとして実行されている場合のみですが、この方法であれば、ローカル環境を含め、どこで実行しているClaude Codeでもカバーできます。
ステップ 2: 最初の記憶のアップロード
手動移行のステップ2で整理した内容をここに保存します。デプロイ手順書、レビュー規約、アーキテクチャの決定とその理由、新しいチームメンバーが必要とするドメイン用語など、Warpのチームストアから読み取って失いたくなかったすべての情報が対象です。
ツール固有の設定は適切な場所に残します。ビルドコマンドやファイルレイアウトは CLAUDE.md に残し、事実情報（ファクト）をここに移動します。
ステップ 3: AIとエージェントの接続
Claude Codeをこのストアに向けます。両方のツールを並行して実行している場合は、Warpもこのストアに向けます。移行途中のチームは通常、しばらくの間両方を使用しますが、この期間こそが共有レイヤーが真価を発揮するタイミングです。これは、一般的な クロスエージェントメモリの背後にある考え方と同じです。
実務における変化
最初の変化は、移行に伴う情報の損失がなくなることです。ファイルはどちらの方法でもコピーできますが、失われるのはファイル化できない知識であり、共有ストアが保持するのはまさにその部分です。
2つ目は、チームの知識がチームの知識として維持されることです。Warpは、チーム全体が使用するエージェントにストアをアタッチすることで、共有を容易にしました。Claude Codeの自動記憶は、設計上リポジトリごと、かつローカルです。共有レイヤーを使用することで、2つ目のツールを採用しつつ、前者の共有特性を維持できます。
3つ目は、両方のツールを実行することによるメンテナンスコストがなくなることです。Warpの /init は、既存の外部ルールファイル（サポートされているリストには CLAUDE.md、.cursorrules、AGENT.md、GEMINI.md、.clinerules、.windsurfrules、.github/copilot-instructions.md が含まれます）をリンクすることさえできるため、指示レイヤーを完全に1つのファイルに統合できます。知識レイヤーにも同様の処理が必要であり、それこそが Warpのプロジェクトルール設定が単独でできること、そしてできないことです。
WarpからClaude Codeへの移行におけるベストプラクティス
- 単にコピーするだけでなく、名前を変更する。 Warpでは
AGENTS.mdをすべて大文字にする必要があります。Claude CodeはCLAUDE.mdを求めます。コピーしただけで名前を変更していないファイルは、どちらのツールからも読み込まれません。 - 移行前に分割する。
CLAUDE.md1つあたり200行未満を目指します。スコープ設定されたWarpのサブディレクトリのルールは、.claude/rules/の下のpathsスコープのエントリに変換します。 /contextで検証する。 ファイルがロードされたと思い込まず、Memory files のリストを確認してください。- 移行前にWarpのストアを読み取っておく。 トレーサビリティ機能により各記憶のソースがわかります。自動でエクスポートしてくれる機能はありません。
- 自動記憶は選択的であることを想定する。
CLAUDE.mdにすでに記載されている内容や、コードから導き出せる内容はスキップされ、最初の200行または25KBがロードされます。 - 矛盾を排除する。 Claude Codeは競合するルールの間で任意に選択を行う可能性があるため、ネストされたファイルやルールを定期的に見直してください。
- 厳格に適用すべきルールにはフックを使用する。 指示はコンテキストであり、強制力はありません。アクションを完全にブロックするには、ドキュメントに記載されている
PreToolUseフックを使用するのが公式な方法です。 - Agent Memoryが追従すると思わない。 これはデザインパートナー向けにチームごとに有効化されているリサーチプレビューであり、プレビュー期間中、ローカルのサードパーティ製ハーネスはサポート対象外のパスとなります。
結論
この移行におけるファイル側の作業は、名前の変更とスコープの決定だけであり、Claude Codeのルールディレクトリは、サブディレクトリファイルの山よりも条件付きガイダンスをはるかに適切に処理できます。
問題となるのは、誰もエクスポートしてくれないもう半分の要素です。Warpはホスト型でチーム共有され、監査可能な記憶システムを保持していますが、Claude CodeはリポジトリごとのローカルMarkdownを保持します。移行する前にストアを読み取り、永続的な事実情報をどちらのツールにも属さない場所に保存しておけば、移行にかかるコストは、再学習のための数ヶ月ではなく、わずか半日で済みます。