実際に移行されるもの
.clinerules/ は移行可能であり、ドキュメント化された2つの仕組みがあります。
1つ目は /init です。Claude Code のドキュメントによると、これは「.cursor/rules/ または .cursorrules にある Cursor のルール、および .github/copilot-instructions.md にある Copilot のルールを読み込み、関連する部分を生成された CLAUDE.md に組み込みます。CLAUDE_CODE_NEW_INIT=1 が設定されている場合、/init は AGENTS.md、.devin/rules/、.windsurf/rules/ または .windsurfrules、そして .clinerules も読み込みます。」
条件に注意してください。.clinerules は、その環境変数が設定されている場合にのみ読み込まれます。 これを設定せずに /init を実行すると、Cline のルールは何も言わずにスキップされます。
2つ目は /import で、こちらはより多くの処理を行います。これは「サポートされているコーディングエージェントの設定を Claude Code に取り込み、AGENTS.md などの指示ファイルの1回限りのコピーを対応する CLAUDE.md に追加し、MCP サーバー、コマンド、サブエージェント、スキルを引き継ぎます。Claude Code v2.1.213 以降が必要です。」ここで覚えておくべきポイントは2つあります。それは、同期ではなく1回限りのコピーであること、およびバージョンの最低要件があることです。
常にアクティブなルールはきれいにマッピングされます。 Cline は「.clinerules/ 内のすべての .md および .txt ファイルを処理し、それらを統一されたルールセットに結合」し、「フロントマターのないルールは常にアクティブ」になります。Claude Code の CLAUDE.md も同じ論理で常にオンになるため、これらのルールは期待通りの場所に収まります。
条件付きルールはマッピングされません。 Cline のフロントマターで制限されたルールは、現在の作業コンテキスト（開いているファイル、表示されているタブ、言及されたパス、編集中のファイルなど）に基づいてアクティブになります。Claude Code の CLAUDE.md にはフロントマターによる条件分岐はありません。その代わり、ディレクトリツリーの挙動を採用しています。つまり、「現在の作業ディレクトリからディレクトリツリーを遡って CLAUDE.md ファイルを読み込み」ます。また、サブディレクトリ内のファイルは、起動時にロードされるのではなく、「Claude がそれらのサブディレクトリ内のファイルを読み込む際に含まれ」ます。これはパターンベースではなく、パスベースです。精神的には近いですが、仕組みが異なります。つまり、glob スコープの Cline ルールは、それが適用されるディレクトリの CLAUDE.md になります。
ルールの優先順位が重要な形で逆転します。 Cline の場合: 「ワークスペースルールとグローバルルールの両方が存在する場合、Cline はそれらを結合します。競合が発生した場合は、ワークスペースルールが優先されます。」 Claude Code の場合: 「検出されたすべてのファイルは、互いに上書きするのではなく、コンテキストに連結」され、「ファイルシステムのルートから作業ディレクトリに向かって」順序付けられ、各ディレクトリで CLAUDE.md の後に CLAUDE.local.md が追加されます。そのため、Claude Code には明示的な競合解決策はありません。後から出てくるテキストが単に後ろに配置されるだけです。Cline が優先順位によって解決していた矛盾は、Claude Code が両方をそのまま読み込む矛盾になってしまいます。移行時にこれらを整理してください。
Memory Bank には移行先がありません。 その6つのファイル（projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、progress.md）は通常の Markdown であるため、ファイルとしては残ります。しかし、残らないのはその「システム」です。Cline の口調で書かれたこの手法独自の指示は、「すべてのタスクの開始時に、すべてのメモリバンクファイルを必ず読み込まなければならない（これは必須である）」というものであり、「initialize memory bank（メモリバンクの初期化）」、「update memory bank（メモリバンクの更新）」、「follow your custom instructions（カスタム指示に従う）」といったコマンドによって駆動されていました。
これはプロンプトによって強制された儀式であり、それこそが機能していた理由です。Claude Code には同等のコマンドはなく、6つのドキュメントを CLAUDE.md に貼り付けることは代替手段にはなりません。それでは、リクエストのたびに6つのドキュメントが送信されることになってしまいます。
手動での移行
ステップ 1: ルールをインポートし、調整する
まずバージョンを確認してください。/import には Claude Code v2.1.213 以降が必要です。その後、以下を実行します。
CLAUDE_CODE_NEW_INIT=1 claude…そして /init を実行して .clinerules を生成された CLAUDE.md に折りたたむか、MCP サーバー、コマンド、サブエージェント、スキルも引き継ぎたい場合は /import を実行します。/import は1回限りのコピーを追加するだけであり、その後の Cline 側での編集は追跡されないことに注意してください。
その後、結果をそのまま信用するのではなく、内容を確認してください。手動で修正すべき点が3つあります。
無条件になってしまった条件付きルール。 .clinerules 内で glob スコープだったものは、すべて常にオンになります。それぞれを、実際に管理するディレクトリ内の CLAUDE.md に移動するか、特定の1つの領域にしか関連しなかった場合は削除してください。
以前は解決されていた矛盾。 「グローバルよりワークスペースを優先」は適用されなくなりました。2つのルールが矛盾しており、Cline が一方を選択していた場合、Claude Code は両方を読み込みます。
長さ。 Claude Code のガイドラインでは、ファイルが長くなるとコンテキストの消費量が増え、指示への準拠率が低下するとされています。これに対する構造化された代替案として、指示を整理するための .claude/rules/ があります。蓄積するのではなく、分割してください。
/context で検証し、CLAUDE.md が Memory files の下に表示されていることを確認します。
CLAUDE.md がプロジェクトの外部から何かをインポートすることになる場合の注意点：「Claude Code がプロジェクト内で外部インポートを初めて検出したとき、ファイルをリストした承認ダイアログが表示されます。拒否すると、インポートは無効のままになり、ダイアログは二度と表示されません。」 ~/.claude/CLAUDE.md のようなユーザースコープのファイル内のインポートは、ダイアログなしでロードされます。移行後に指示が不足しているように見える場合は、ダイアログを拒否してしまった可能性があります。
ステップ 2: Memory Bank をどうするか決める
6つのファイルを読み、その内容を3つの山に分類します。これが移行の本当の作業であり、約20分かかります。
規約と制約 → CLAUDE.md。 systemPatterns.md と techContext.md の大部分がこれに該当します。アーキテクチャパターン、コンポーネントの関係、技術スタック、セットアップ、依存関係などです。これらは安定しており、ルールに圧縮すれば短くなるため、指示ファイルに含めるべきです。
要件とプロダクトコンテキスト → リポジトリ（貼り付けるのではなく参照する）。 projectbrief.md と productContext.md は、エージェントだけでなく人間にとっても役立つドキュメントです。これらはドキュメントとして保持し、そこを指し示すようにします。インライン化は避けてください。
状態 → 行き先なし（これが問題です）。 activeContext.md（「現在のフォーカス、最近の変更、次のステップ」であり、ドキュメントには「最も頻繁に更新される」と記載されています）と progress.md（「機能しているもの、残っているもの、既知の問題」）は、実行状態（running state）です。これらは規約でもドキュメントでもありません。これらを CLAUDE.md に入れると、リクエストのたびに先週の火曜日のステータスを送信することになります。かといってファイルのままにしておくと、何も読み取られません。
この3つ目の山こそが Memory Bank が存在していた理由であり、Claude Code が格納場所を用意していない部分です。この習慣は、仕組みがなくても維持する価値があります。一般的なケースについては、why Cline forgets task history（Cline がタスク履歴を忘れる理由）を参照してください。
より良い方法：指示ファイルではない場所に状態の格納先を作る
Memory Bank は1つのことを正確に捉えていました。それは、プロジェクトの知識の一部は「ルール」ではなく「状態（state）」であり、書き留めて読み直す必要があるということです。限界に達したのは、その保存先がプロンプトによって整合性を保たれた6つの Markdown ファイルだった点です。つまり、エージェントが儀式に従うことに依存しており、1つのツールのための1つのリポジトリ内に閉じていました。
それこそが MemoryLake の目的です。エージェントが読み取る状態や推論を、ドキュメント丸ごと送信するのではなく、個別の検索可能なエントリとして保持します。セットアップは3つのステップで行えます。
ステップ 1: API キーを作成する
MemoryLake にサインインし、API キーを作成します。接続するすべてのツールで共通の認証情報を使用できます。
ステップ 2: 最初のメモリをアップロードする
すでに情報の抽出が行われているため、Memory Bank は非常に優れた出発点になります。ファイルをそのまま貼り付けるのではなく、1つの主張につき1つの短いエントリに分割してください：
progress.md から：機能しているもの、残っているもの、既知の問題。 各既知の問題は、その症状と原因を含む1つのエントリにします。これは Memory Bank 全体の中で最も価値の高いコンテンツであり、ドキュメントとしてよりもエントリとして検索する方がはるかに効果的です。
activeContext.md から：現在のフォーカスの背景にある決定事項。 「請求処理のリファクタリング作業中」ではなく（これは期限切れになります）、「プロバイダーが冪等性キーなしで再試行するため、請求処理のリファクタリングではアウトボックスパターンを使用する」とします（これは期限切れになりません）。
systemPatterns.md から：各パターンの背後にある理由。 パターン自体は CLAUDE.md に記述し、その根拠をここに記述することで、エージェントが想定外のケースにも対応できるようになります。
これまでに2回修正しなければならなかったすべてのこと。 却下されたアプローチが書き留められていない限り、Cline も Claude Code も再びそのアプローチを提案してきます。
エントリは短く保ち、廃止したシステムに関する記述はすべて削除してください。6つのファイルからなる Memory Bank からは、通常20〜40個のエントリが作成されます。もし200個も作成しているなら、それは単なる書き写しになってしまっています。
ステップ 3: AI とエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセスできるため、Claude Code、Codex、OpenClaw などの MCP ネイティブエージェントは MCP サーバーを指定することで接続し、他のアシスタントは API を介して同じメモリを読み取ります。つまり、移行が完全に完了する前にこれを設定でき、評価中も両方のツールが同じ状態を読み取ることができます。
率直な3つの制限事項。MemoryLake は CLAUDE.md や .clinerules の代替品ではありません — これらは各ツールを制御するためのものであり、上記のインポートはそれ自体で行う価値があります。また、MemoryLake はあなたやエージェントが書き込んだ内容のみを保持するため、ステップ2は手動の作業になります。さらに、これは強制力を持つ仕組みではありません。検索されたコンテキストがあるからといって、モデルが必ずそれに従って行動するとは限りません。
実務における変化
activeContext.md が「誰も読まないファイル」ではなくなります。 実行状態が検索可能なエントリとして保存されるため、丸ごと貼り付けられたり忘れられたりすることなく、オンデマンドで利用可能になります。
指示ファイルが短いまま維持されます。 CLAUDE.md は規約のみを保持します。6つのドキュメントを抱え込むことがないため、指示への準拠率が維持される長さに収まります。
儀式としての「update memory bank」が不要になります。 価値があったのは「書き留めること」であり、タスク開始のたびに6つのファイルを読み直すというセレモニーではありません。
インポートダイアログの拒否によってコンテキストが失われることがなくなります。 永続的な知識が外部にある場合、指示ファイルの読み込み失敗は単なる不便さに過ぎず、すべてがリセットされるわけではありません。
再びツールを切り替える際のコストが低くなります。 状態が Cline や Claude の形をしたコンテナに縛られないためです。この形状については、what AI memory is and isn't（AI メモリとは何か、何ではないか）で解説しています。
移行のベストプラクティス
/init を実行する前に CLAUDE_CODE_NEW_INIT=1 を設定する。 これを設定しないと、.clinerules は読み込み対象ファイルに含まれません。
/import を利用する前に v2.1.213 以降であることを確認する。 これがドキュメントに記載されている最低要件であり、/import によって MCP サーバー、コマンド、サブエージェント、スキルが引き継がれます。
インポートはスナップショットとして扱う。 これは1回限りのコピーを追加するものです。その後の .clinerules の編集は反映されません。
すべての条件付きルールのスコープを再設定する。 glob スコープの Cline ルールは、それが管理するディレクトリに移動しない限り、常にオンになります。
矛盾は自分で解決する。 Claude Code は上書きではなく連結を行うため、Cline が適用していた優先順位は失われます。
projectbrief.md はドキュメントとして保持する。 インライン化せず、参照するようにします。
絶対に activeContext.md を CLAUDE.md に貼り付けない。 Cline 自身のドキュメントにある通り、これは最も頻繁に変更されるファイルです。リクエストのたびに送信されるコンテンツとしては最悪の選択肢です。
変更を加えるたびに /context を実行する。 Memory files の下に CLAUDE.md があることを確認する作業は5秒で終わり、「ロードされたかどうか」という疑問のほとんどを解決します。関連する領域については、why Claude Code forgets project context（Claude Code がプロジェクトのコンテキストを忘れる理由）を参照してください。
結論
この移行におけるルールの部分はほぼ解決されています。CLAUDE_CODE_NEW_INIT=1 を指定した /init は .clinerules を読み込み、v2.1.213 以降での /import は MCP サーバー、コマンド、サブエージェント、スキルを含む広範な設定を引き継ぎます。代わりに、調整作業に時間を割いてください。これには、いつの間にか無条件になってしまった条件付きルールや、Claude Code が上書きではなく連結を行うために失われた「グローバルよりワークスペースを優先する」優先順位の整理が含まれます。
本当に考える価値があるのは Memory Bank の方です。その洞察は正しかったのです。一部の知識は状態であり、状態は書き留めて読み直す必要があります。しかし、その実装は1つのツールのための1つのリポジトリ内で、プロンプトによってまとめられた6つのドキュメントでした。規約は CLAUDE.md に移動し、概要（brief）は参照用ドキュメントとして保持し、既知の問題、決定事項、却下されたアプローチはエージェントがクエリできるレイヤーに配置してください。そうすれば、次にツールを切り替える際、6か月かけて蓄積した資産を失わずに済みます。