コンテキストを失わずに Cline から Zencoder へ移行する方法 (2026)

まず、Memory Bank が実際に何であるかから始めましょう。ドキュメントには、多くの人が認識しているよりも明確に記載されています。

"Memory Bank は、Cline をステートレスなアシスタントから永続的な開発パートナーへと変貌させるドキュメント手法です。構造化された Markdown ファイルを通じて、Cline はセッションをまたいでプロジェクトの詳細を「記憶」することができます。"

ここで methodology（手法）という言葉に注目してください。セットアップ手順でも確認されています。カスタム指示のブロックをコピーし、「.clinerules/memory-bank.md などの Cline Rules ファイルに追加」します。オン/オフの切り替えスイッチはありません。この機能は、ルールファイル内に存在するプロンプトの規約と、その規約がエージェントに読み込むよう指示するドキュメントのフォルダにすぎません。setting up Cline's Memory Bank に従ってセットアップした場合、失おうとしているのはそのブロックを貼り付けたルールファイルであり、フォルダではありません。

フォルダ自体は普通のものです：

"Memory Bank ファイルは、あなたと Cline の両方がアクセスできる、プロジェクト内の通常の Markdown ファイルです。プロジェクトの全体像を構築するために階層的に整理されています。"

6 つのファイルがあり、それぞれに役割があります。基本ドキュメントとしての projectbrief.md、プロジェクトが存在する理由を示す productContext.md、現在のフォーカスと最近の変更を示す activeContext.md、アーキテクチャとデザインパターンを示す systemPatterns.md、スタックと制約を示す techContext.md、そして何が機能し何が残っているかを示す progress.md です。これらはフレーズで動かします。ドキュメントには、Cline にバンクを読み込ませて中断したところから再開させるための「follow your custom instructions（カスタム指示に従う）」や、「a full documentation review and update（完全なドキュメントのレビューと更新）」をトリガーするための「update memory bank（メモリバンクを更新する）」が挙げられています。

そのため、移行はきれいに 2 つに分かれます。ドキュメントは完全に移行できます。リポジトリ内の Markdown であり、リポジトリ内の Markdown のままであり続けます。仕組みはまったく移行できません。その理由は次のとおりです。

Zencoder のドキュメントでは、コンテキストはメッセージごとに 5 つのソースから組み立てられると説明されています。プロジェクトのファイル構造と依存関係のワークスペース分析、エディタで現在開いているファイル、一致したスキル、@ メンションで添付したもの、そして実行中にエージェントが独自のツールで収集したコンテキストです。これがコンテキストが届く方法の完全なリストであり、5 つのいずれも、常にロードされているリポジトリ指示ファイルではありません。

Zencoder が持っている、耐久性がありバージョン管理されたインターフェースは「スキル」です：

"スキルは .agents/skills/ 内に SKILL.md ファイルとして保存され、リポジトリとともにバージョン管理されます。"

これらは 3 つの場所から読み込まれます。プロジェクトスキルのための <workspace>/.agents/skills/、ユーザーレベルのスキルのための <user-home>/.agents/skills/、そしてドキュメントで「Claude 互換スキル」とラベル付けされている <workspace>/.claude/skills/ です。レガシーな .zencoder/skills/ パスは「非推奨ですが、引き続きサポートされています」と説明されています。

そして、移行計画を決定づける一文がこれです：

"スキルは、タスクのコンテキストに基づいてエージェントによって自動的に選択されます。手動でのスキル選択は現在サポートされていません。"

スキルは、エージェントがその description（説明）があなたの行っている作業と一致すると判断したときにロードされます。ドキュメントでは、説明がその役割を果たしていることが直接的に述べられています。それは「スキルが何をするかであり、エージェントはこれを使用していつロードするかを決定する」ものであり、ガイダンスとしては「明確なトリガー条件として記述する」ことが推奨されています。

この 2 つを組み合わせて考えてみましょう。Cline の Memory Bank は、すべてのタスクの開始時に無条件に実行される指示に依存しています。Zencoder の同等のインターフェースは説明の一致によって実行され、それを強制する手動のオーバーライドはありません。memory-bank/ を Zencoder プロジェクトにコピーしても、誰も開く義務のない 6 つのファイルが残るだけです。

逆の確認として、完全を期すために：Zencoder のドキュメントでは、スキル、メッセージごとのコンテキストの組み立て、および複数リポジトリの検索について説明されています。セッションをまたいで事実を蓄積する会話型メモリの保存については説明されていません。Zencoder 自身の推奨事項は逆の方向を指しています。「長時間の、複数のトピックにわたるチャットは、古いコンテキストを蓄積します。エージェントのコンテキストをクリーンに保つために、個別のタスクごとに新しいチャットを開始してください。」これは優れたアドバイスであり、すべてのタスクがリポジトリと、エージェントがロードすることを選択した何かから始まることを意味します。

ステップ 1: バンクを手順と永続的な事実に分割する

6 つのファイルを開き、ファイル名ではなく、その形式によって内容を並べ替えます。移行先には 1 つのコンテナしかなく、それは手順の形式をしているからです。

リリースの実行方法、マイグレーションの追加方法、レビューチェックリストの仕組みなど、一連の手順のように読めるものはすべて、スキルの候補になります。これらには自然なトリガー条件（「データベースマイグレーションを追加するときにこれを使用する」など）があるため、説明が確実に一致し、うまく機能します。

永続的な事実のように読めるものは、難しい分類になります。イベントバスがなぜそのような形状になっているのかを説明する systemPatterns.md、明らかなライブラリを除外する制約をリストした techContext.md、製品が実際に何のためのものであるかを説明する projectbrief.md などです。これらにはトリガー条件がありません。なぜなら、ほぼすべてのタスクに関連し、特定のタスクに限定されないからです。「常に」に一致する説明を書くことは、まさにこの仕組みが意図していないことです。

そして、そのどちらでもない activeContext.md と progress.md があります。これらは状況の進行状況ログです。この 2 つこそが、Memory Bank がドキュメントではなくメモリのように感じられた理由であり、移行先がまったく存在しない 2 つでもあります。これは、Cline forgetting task history（Cline がタスク履歴を忘れる）といった不満の背景にあるギャップですが、今回はコンテキストウィンドウの問題ではなく、構造的な損失です。

ステップ 2: 手順スキルを作成し、その説明を慎重に記述する

.agents/skills/ の下に手順ごとに 1 つのフォルダを作成し、それぞれに name と description を含む SKILL.md を配置します。説明に力を注いでください。それがアクティベーションの仕組みのすべてだからです。「API ヘルパースキル」では一致しません。「ユーザーが API エンドポイントの作成または変更を求めたときにこのスキルを使用する」であれば一致します。

知っておく価値のある 2 つのフィールドがあります。paths は、スキルを特定のファイルにスコープするための glob パターンを受け入れます。これにより、説明だけよりも条件付きロードに近づけることができます。また、disable-model-invocation を true に設定すると、エージェントがスキルを自動選択するのを停止します。手動選択がサポートされていないことを考えると、これは事実上そのスキルを使用不可にすることを意味します。意図的に使用するか、まったく使用しないようにしてください。

チームが Claude ベースのツールも実行している場合、Zencoder は <workspace>/.claude/skills/ も読み込むことに注意してください。2 つのコピーを維持する代わりに、1 つのフォルダで両方に対応できます。

やってはいけないのは、曖昧な説明を付けたスキルに永続的な事実を詰め込み、うまくいくことを祈ることです。それでは、why agent skills aren't memory（エージェントのスキルがメモリではない理由）にあるような失敗モードに陥ります。技術的には存在するものの、重要なときに決してロードされないドキュメントになってしまいます。

分類できなかった山こそが、価値のあるものです。アーキテクチャの理由、却下された代替案、奇妙なモジュールを説明する制約、プロジェクトの現在の状況などです。これらは Memory Bank を維持する価値を与えていたコンテンツですが、Zencoder のアクティベーションモデルはこれらに信頼できるトリガーを提供しません。

MemoryLake は、そのレイヤーをエディタの外部に保持し、MCP または API を介してそれに関する質問に答えます。エージェントは、説明からコンテンツが関連しているかどうかを推測する必要はありません。質問が生じたときに尋ねます。手順スキルは .agents/skills/ に残り、Zencoder はタスクの一致によってそれらをロードします。永続的な事実は、エージェントがこのターンに何をロードすることを選択したかに関係なく、回答可能な状態に保たれます。

ステップ 1: API キーを作成する

キーを生成し、約 30 秒で最初のリクエストを送信します。上記のステップ 1 の前にこれを行うことで、6 つのファイルを整理しながら、各事実を配置する場所を確保できます。

ステップ 2: 最初の記憶（memory）をアップロードする

分類できない山をファイルごとに処理していきます。systemPatterns.md からのアーキテクチャの決定、techContext.md からの制約、projectbrief.md と productContext.md からの製品の意図、そして activeContext.md と progress.md からの現在の状態です。それぞれを理由とともに決定事項として記述します。サポートドキュメントも同じ場所に配置します。turning project docs into AI memory では、すべてを書き直すことなくこれを行う方法を説明しています。

ステップ 3: AI とエージェントを接続する

Zencoder、Claude、Codex、およびその他のエージェントに MCP または API を介してアクセスを許可します。新しいチャットを開始するたびに（Zencoder 自身のアドバイスでも多数開始することが推奨されています）、プロジェクトがなぜそのようになっているのかに答えることができる状態で始まります。

最初の変化は、新しいチャットを開始することに何のコストもかからなくなることです。Zencoder がタスクごとに新しいチャットを推奨するのは、まさに古いコンテキストが害になるからであり、その推奨事項は、永続的な知識が最初からチャット内に存在しない場合にのみ快適に受け入れられます。

2 つ目は、スキルがより狭く絞り込まれるため、より優れたものになることです。永続的な事実が別の場所に配置されれば、各スキルは 1 つの明確な説明を持つ 1 つの手順になり、これはまさに説明のマッチングが機能する条件そのものです。

3 つ目は、ログファイルが失われなくなることです。activeContext.md と progress.md は、新しいツールでは移行先がありませんでした。日付付きの決定事項として記録されることで、新しいチームメンバーがチャット履歴をスクロールする代わりに読むものになります。

4 つ目は、次の移行が今回よりも簡単になることです。今回の移行が厄介だった理由は、Cline の仕組みがルールファイルであり、Zencoder の仕組みが説明の一致だったからです。どちらのツールにも属さないレイヤーは、次のツールがどの仕組みを採用しているかを気にしません。Cline forgetting project context（Cline がプロジェクトのコンテキストを忘れる）や、他のすべてのツールにおける同等の問題に同じ根本的な解決策があるのと同じ理由です。

説明を機能として扱う。 スキルの説明は、そのアクティベーションメカニズムのすべてです。トピックを命名するラベルとしてではなく、状況を指定するトリガー条件として記述してください。

1 つのスキルに 1 つの手順。 関連のない 3 つの手順をまとめると、どれにもきれいに一致しない説明になってしまいます。

ファイルスコープの作業では paths を意識する。 Glob によるスコープ指定は、条件付きロードに最も近いものであり、広範な説明よりも信頼性が高くなります。

disable-model-invocation を不用意に設定しない。 手動選択がサポートされていないため、自動選択を無効にすると、唯一のアクセス経路が失われます。

レガシーなスキルパスから移行する。 ドキュメントでは .zencoder/skills/ は非推奨ですがサポートされていると説明されており、現在の標準に合わせるために .agents/skills/ を推奨しています。

Claude ツールと 1 つのスキルフォルダを共有する。 Zencoder は .claude/skills/ も読み込むため、両方を実行しているチームは重複を作成する必要がありません。

スキルが常にオンのルールのように動作することを期待しない。 すべてのタスクで真である必要があるものは、タスクに一致するコンテナに配置すべきではありません。

Cline の Memory Bank は、Markdown のフォルダと、エージェントにそれを読み込ませるルールファイルです。Zencoder は .agents/skills/ でスキルをバージョン管理し、その説明から自動的に選択します。現在、手動での選択はサポートされていません。また、ドキュメント化されているコンテキストソースは、永続的な指示ファイルからロードされるのではなく、メッセージごとに組み立てられます。そのため、Memory Bank 内のドキュメントは完全に移行できますが、それらを読み込むという保証は移行できません。

移行する前に、バンクを形式ごとに分割してください。手順は、トリガー条件として記述された説明を持つスキルになり、うまく機能します。永続的な事実と実行状態には、マッチングを待つのではなく、質問に答える場所が必要です。この分割を一度行えば、タスクごとに新しいチャットを開始するという Zencoder のアドバイスは、本来の意図通り、コンテキストをクリーンに保つ方法になり、最初からやり直す方法ではなくなります。