実際に移行されるもの
memory-bank/ ディレクトリはそのまま移行されます。 projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、そして progress.md は、リポジトリ内の通常の Markdown ファイルです。Cline 特有の要素は何もありません。Cline のドキュメントでは、これらを「あなたと Cline の両方がアクセスできる、プロジェクト内の通常の markdown ファイル」と説明しています。これらは完全にそのままの場所に残しておいてください。
AGENTS.md がある場合は、それも移行されます。 Cline は AGENTS.md および ~/.agents/AGENTS.md を「ツール間互換性のための標準フォーマット」として読み込みます。Kilo Code はプロジェクトのルートにある AGENTS.md を読み込み、それがなければ AGENT.md にフォールバックします。ドキュメントでは「ファイル名は小文字ではなく、大文字（AGENTS.md）でなければならない」と警告されています。すでにこれをお持ちの場合、このファイルについては何も心配する必要はありません。
.clinerules/ ディレクトリは、自動検出されるソースとしては移行されません。 Kilo Code がドキュメントで規定している指示ソースは、プロジェクトルートの AGENTS.md および AGENT.md、プロジェクトおよびグローバルの kilo.jsonc 内の instructions キー、.kilo/rules/ ファイル、そして（後方互換性のための）.kilocode/rules/ ディレクトリとレガシーな .kilocoderules ファイルです。CLI は「他のツールとの互換性のために .claude/ および .agents/ ディレクトリもサポート」していますが、.clinerules/ はそのリストに含まれていません。
ここが重要な分岐点です。なぜなら、Cline のセットアップに従っていた場合、Memory Bank の指示は .clinerules/memory-bank.md に配置されているからです。これに対処せずに Kilo Code に移行すると、memory-bank/ ファイルは完全かつ最新の状態でリポジトリに存在し続けるものの、誰もそれを読み込まなくなります。Cline 自身の指示テキストには、これがなぜこのパターンにおいて致命的なのかが明記されています。「私はすべてのタスクの開始時に、すべての memory bank ファイルを読み込まなければならない（MUST） — これは必須である。」この指示を削除してしまうと、これらのファイルは誰も開かない単なるドキュメントになってしまいます。
条件付きルールは移行されません。 Cline は YAML フロントマターの paths 配列によるスコープ指定をサポートしており、実際の作業コンテキストに照らし合わせて評価します。「現在の作業（開いているファイル、表示されているタブ、言及されたパス、編集されたファイル）からコンテキストを収集し、各ルールの条件を評価して、一致するルールを有効化します。」一方、Kilo Code の instructions キーはファイルパスと glob パターンを受け取りますが、これらの glob はどのファイルをロードするかを選択するものであり、いつロードするかを決めるものではありません。Kilo Code がドキュメント化している唯一の条件付き動作は、性質が異なります。ディレクトリごとの AGENTS.md ファイルは「エージェントがそのディレクトリ内のファイルを読み取るときに動的にロードされ、セッション開始時にはプリロードされない」ようになっており、その内容は「<system-reminder> タグとして会話に注入」されます。これは便利ですが、glob ベースではなくディレクトリベースであるため、ツリー全体で **/*.test.ts にスコープされたルールに直接相当するものはありません。
ルールの組み合わせの挙動が異なります。 Cline は「.clinerules/ 内のすべての .md および .txt ファイルを処理し、それらを統合されたルールセットに結合」し、オプションの順序付け規則として数値プレフィックスを使用します。また、「ワークスペースルールは、グローバルルールと競合する場合に優先」されます。これに対し、Kilo Code は明確な優先順位リストを公開しています。設定内のエージェントごとのプロンプトが最も高く、次に kilo.jsonc 内のプロジェクト instructions キー、次にプロジェクトルートの AGENTS.md、次にグローバル instructions キー、そしてオンデマンドでロードされる Skills と続きます。ルートの AGENTS.md がどこに位置しているかに注意してください。プロジェクトの instructions キーの上ではなく、下です。
両方のツールに共通して欠けているものがあります。 どちらのツールも、プロジェクトやメンバーを超えてチームが学んだことを蓄積するストアについてはドキュメント化していません。Cline の解決策は、ユーザー自身が維持するドキュメント手法であり、Kilo Code の解決策は、ユーザー自身が維持する AGENTS.md とルールファイルです。Memory Bank が存在する理由こそが、まさにこのギャップが現実にあるからです。これこそが、適切に設定されている場合でも AIアシスタントが物忘れしがちだと感じる 理由です。そのコンテンツをどこに配置すべきかを決定する際には、このことを念頭に置いておくとよいでしょう。
手動での移行
ステップ 1: コンテンツではなく、指示を再接続する
Kilo Code で Memory Bank パターンを実行させるには、2つの明確な方法がありますが、これらは同等ではありません。
最もシンプルな方法は、プロジェクトの kilo.jsonc にある instructions キーを使用することです。すでに持っているルールファイル（同じ .clinerules/memory-bank.md、または Cline という名前のディレクトリを残したくない場合は .kilo/rules/memory-bank.md に移動したコピー）を指すように設定します。Kilo Code のドキュメントによると、instructions は明示的なパスと glob の両方を受け取ることができるため、1つのエントリでルールフォルダ全体をカバーできます。これは優先順位の2番目に位置し、ルートの AGENTS.md よりも上にあるため、他の何よりも先に実行する必要がある指示を置くのに適した場所です。
もう1つのオプションは、指示テキストを AGENTS.md に記述することです。これは Kilo Code の非推奨に関する注意書きが示唆している方法であり、実際に機能します。ただし、この場合、指示は次のステップで説明する Kilo Code のファイル保護の対象となり、AGENTS.md の他の記述とスペースを争うことになります。
どちらを選択する場合でも、コマンドの語彙を調整してください。Cline の Memory Bank 指示は、「follow your custom instructions（カスタム指示に従う）」、「initialize memory bank（メモリバンクを初期化する）」、「update memory bank（メモリバンクを更新する）」という3つのフレーズを中心に書かれています。最初のフレーズは Cline の概念に依存しているものです。これを、「タスクを開始する前に memory-bank/ 内のすべてのファイルを読み込む」という直接的な表現に書き換えてください。他の2つはエージェントに対する平易な英語の指示であるため、そのまま引き継ぐことができます。
その後、新しいタスクを開始し、エージェントがどのガイダンスをロードしたかを尋ねて確認します。確認したいのは、memory-bank/ のファイルリストです。Cline では「Conditional rules applied（条件付きルールが適用されました）」という通知で視覚的なシグナルが表示されましたが、Kilo Code におけるディレクトリごとのファイルに対する同等のシグナルは <system-reminder> の注入であるため、想定するのではなく直接エージェントに尋ねるようにしてください。
ステップ 2: memory-bank のコンテンツを AGENTS.md に流し込まない
Kilo Code の非推奨に関する注意書きでは、自社ツール独自のメモリバンクについて、2ステップの移行方法が示されています。「.kilo/rules/memory-bank/（またはレガシーな .kilocode/rules/memory-bank/）の内容を確認する」こと、および「その内容をプロジェクトの AGENTS.md ファイルに移動する（または Kilo Code に移動を依頼する）」ことです。このアドバイスは、そこで説明されている内容（Kilo Code のメモリバンクはルールディレクトリ内に存在していたため、それを AGENTS.md に統合して簡素化する）に対しては正しいものです。
しかし、これを Cline の Memory Bank に適用すると、それが機能する仕組み自体が壊れてしまいます。その理由は、Kilo Code 自身の言葉を借りれば次の通りです。「Kilo Code において、AGENTS.md と AGENT.md はどちらも書き込み保護されたファイルです。」つまり、「AI エージェントは、ユーザーの明示的な承認なしにこれらのファイルを変更することはできず」、「これらのファイルへの変更を確認するよう求められます。」
Memory Bank は静的なドキュメントではありません。activeContext.md は、Cline のドキュメントで「最も頻繁に更新される」とされ、「各セッションの後に」更新することが推奨されているファイルです。progress.md はマイルストーンを追跡します。このパターン全体は、あなたが「update memory bank（メモリバンクを更新する）」と指示したときに、エージェントがそれらのファイルに書き込めるかどうかに依存しています。これらを AGENTS.md にマージしてしまうと、書き込みのたびに承認プロンプトが表示されるようになります。その結果、プロジェクトの設定ファイルに対するプロンプトをただクリックして進める癖がつくか、あるいは更新の実行自体をやめてしまうかのどちらかになります。
したがって、役割を分割したままにしてください。指示は指示ソースに記述し、コンテンツは特別な保護のない通常のプロジェクトファイルである memory-bank/*.md に残します。この分割は、Kilo Code に依存しない観点からも、より健全な管理方法です。エージェントが頻繁に書き換えるファイルを、プロジェクトのガードレールを定義するファイルから切り離しておくことができます。標準的な AGENTS.md も用意したい場合は、migrating CLAUDE.md to AGENTS.md でそのファイルの構成について解説しています。
もう1点、想定される挙動として、心配する必要のないことがあります。Kilo Code は「[Memory Bank: Active] や [Memory Bank: Missing] などのレガシーな Memory Bank ステータス表示が引き続き表示されることがありますが、これらはすべてのクライアントやモードで保証されているわけではありません」と述べています。パターンが有効であることを確認するためにバッジを頼りにしていた場合は、それをやめましょう。代わりに、エージェントが何をロードしたかを直接尋ねてください。
より良い方法：メモリバンクにリポジトリ以外の保存先を提供する
Memory Bank の洞察は正しいものです。エージェントには永続的な記録が必要であり、Markdown のフォルダは最初の実装として完全に合理的です。しかし、その限界も構造的なものであり、あなたもすでにそれを実感しているかもしれません。
それはリポジトリ単位であるため、サービスをまたぐ知識は複製されるか失われるかのどちらかになります。また、それを有効にする指示がツール固有であるため、実質的にツール単位となります（これこそが、この移行に手順が必要な理由そのものです）。検索機能がないため、関連性があるかどうかにかかわらず、すべてのタスクで6つのファイルすべてを読み込みます。そして、それは「update memory bank」を実行することを覚えている人に依存するため、チーム内で陳腐化しやすく、メンバーの離職とともにコンテキストが失われる原因になります。この問題については、keeping AI context when someone leaves で詳しく解説しています。
MemoryLake は、これら4つの制限を取り除いた同じコンセプトのサービスです。リポジトリやエディタの外部にある単一のストアであり、MCP または API 経由で読み取り可能で、一括読み込みではなく必要な情報を検索して取得でき、チーム全体で共有できます。あなたの memory-bank/ ファイルは、そのための優れたシード（初期データ）になります。
ステップ 1: API キーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。1つのキーで、Kilo Code からも、チームメンバーがまだ使用している場合は Cline からも、そして次に登場するどのようなツールからでも動作します。
ステップ 2: 最初のメモリをアップロードする
すでにお持ちのドキュメント、画像、ファイルをドロップします。まずは、README の焼き直しではなく、実際の決定事項が保持されていることが多い systemPatterns.md、techContext.md、progress.md の3つから始めるのがおすすめです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他のエージェントに MCP または API 経由でアクセスを許可します。Kilo Code では、これにより「タスクごとに6つのファイルすべてを読み込む」動作が、「目の前のタスクに関連する2つの重要な事実を検索して取得する」動作へと変わります。
実務における変化
必須のフル読み込みが不要になります。 Cline の指示テキストがすべてのタスクの開始時にすべてのメモリバンクファイルを読み込むよう要求するのは、検索レイヤーが存在しないためです。関連するファイルを確実に含めるには、そうするしかありません。検索機能があれば、エージェントに セッションごとにコードベースを再読み込みさせる 必要がなくなるのと同様に、この要件は不要になります。
activeContext.md の乖離がなくなります。 Cline が最も頻繁に変更されると指摘するファイルは、最も古くなりやすいファイルでもあります。なぜなら、その更新は、すでに頭の中では終了しているセッションの最後に行う手動のステップだからです。修正を行ったその瞬間に記録をキャプチャする方が、後からセッションを再構築するよりもはるかに小さなアクションで済みます。
ツールの移行が知識に影響を与えなくなります。 今回の移行が煩雑なのは、有効化の指示がツール固有の形状をしているためです。コンテンツが外部に存在していれば、ツールを変更する際に必要なのは新しい指示を1つ書くことだけであり、何がまだ読み込まれているかを監査する必要はありません。
そして、6ファイル構成は必須の構造ではなく、オプションになります。 これは、フォルダ全体を読み込む必要がある場合には合理的なスキーマでした。検索機能が導入されれば、その構成を維持することも、単に事実のみを保持することも自由です。
Cline から Kilo Code への移行後のベストプラクティス
信頼する前に検出を確認する。 .clinerules/ は Kilo Code のドキュメント化されたリストにはありません。タスクを開始し、何がロードされたかを尋ねてください。
書き込み頻度の高いファイルは AGENTS.md から除外する。 このファイルは設計上書き込み保護されています。これはガードレールとしては優れていますが、実行ログとしては不適切です。
スコープ指定にはディレクトリ配置を使用する。 Kilo Code のディレクトリごとの AGENTS.md ファイルは、エージェントがそのディレクトリ内のファイルを読み取るときに遅延ロードされます。これは Cline の条件付きルールに最も近いものであり、glob ではなくディレクトリに対して機能します。
優先順位に注意する。 kilo.jsonc 内のプロジェクト instructions は、ルートの AGENTS.md よりも優先されます。2つのソースが矛盾している場合、通常はこれが原因です。
リロードを想定する。 Kilo Code は「AGENTS.md への変更は新しいタスクで有効になります（リロードが必要な場合があります）」と述べています。タスクの途中で編集したルールをデバッグしようとしないでください。
ステータスバッジに依存しない。 レガシーな Memory Bank インジケーターは、明示的に「すべてのクライアントやモードで保証されているわけではない」とされています。
結論
この移行は、一見すると対立的なもの（メモリバンクを非推奨にしたツールに Memory Bank を移行する）のように思えるかもしれませんが、実際はそうではありません。Kilo Code が非推奨にしたのは機能のラッパーであり、Cline 自身のドキュメントには、この手法は「ドキュメントを読み取ることができる任意の AI で動作する」と記載されています。ファイル自体に問題はありません。
注意が必要なのは2点です。Kilo Code のドキュメント化された指示ソースには .clinerules/ が含まれていないため、パターンを実行させるルールを再接続する必要があります。理想的には、ルートの AGENTS.md よりも優先される kilo.jsonc の instructions キーを使用します。また、メモリバンクのコンテンツを AGENTS.md に移動するという Kilo Code の非推奨アドバイスは、Cline のバージョンには適用すべきではありません。なぜなら、AGENTS.md は書き込み保護されており、エージェントはこれらのファイルに絶えず書き込む必要があるからです。指示は指示ソースに、コンテンツは外部に。
これらを正しく行えば、何も失われることはありません。その上で、より興味深い問いは、タスクごとにリポジトリ単位のフォルダを丸ごと読み込む方法が、チームの知識の保存先として今でも最適なのか、それとも、今朝どのエディタを開いたかに関係なく、検索可能で共有された別の場所に配置すべきなのか、ということです。