実際に移行されるもの
Copilotのカスタマイズサーフェスには3つのレイヤーがあり、GitHubはそれらの正確な優先順位をドキュメント化しています。まず個人用指示、次にリポジトリ指示、そして組織用指示の順で、「関連するすべての指示セットがCopilotに提供されます」。
リポジトリレイヤーの内部には、以下の順位で3つのサブタイプが存在します：
.github/instructions/**/*.instructions.md内のパス固有の指示.github/copilot-instructions.md内のリポジトリ全体の指示AGENTS.md、CLAUDE.md、またはGEMINI.mdというファイルで指定されるエージェント指示
これとは別に、Copilotにはメモリシステムがあります。Copilot Memoryは「現在パブリックプレビュー中であり、変更される可能性があります」とされており、2種類の内容を保存します。1つは「コーディング規約、アーキテクチャの決定、ビルドコマンド、プロジェクト固有のルール」などの「リポジトリレベルの事実（Repository-level facts）」、もう1つは「ユーザーがCopilotとどのように対話したいかに関する、暗黙的または明示的な個人的好み」と説明される「ユーザーレベルの好み（User-level preferences）」です。
それでは、インベントリ（移行対象の整理）を確認しましょう。
そのまま移行可能。 AGENTS.md。両方のツールがこれを読み込むため、変換は不要です。これは唯一の「労力なしの勝利」であり、非常に実用的です。
書き換えを伴って移行可能。 .github/copilot-instructions.md とパス固有の .instructions.md ファイル。コンテンツはポータブルなMarkdownですが、変更されるのは後述するアクティベーションメカニズムです。
移行不可。 以下の3つは、それぞれ異なる理由で移行できません。
個人用指示（スコープの理由による）：「個人用のカスタム指示は、GitHub上のGitHub Copilot Chatでのみサポートされています。」そもそもエディタに届いていなかったため、移行するものはありません。ただし、書き留めておく価値のある好みが含まれている可能性はあります。
組織のカスタム指示（組織レベルのGitHub設定であるため）：「現在、GitHub.com上のCopilot Chat、GitHub.com上のCopilotコードレビュー、およびGitHub.com上のCopilotクラウドエージェントでのみサポートされています。」組織がこれらに依存している場合、1つのチームでCopilotの使用をやめても、他のメンバー向けの設定が削除されるわけではないことに注意してください。
Copilot Memory（保存場所と密結合の理由による）。リポジトリレベルの事実は「そのリポジトリのCopilot Memoryへのアクセス権を持つすべてのユーザーが利用できますが、それらの事実は同じリポジトリでの操作でのみ使用できます」。ユーザーレベルの好みは「同じユーザーのその後の対話でのみ利用可能」です。他社ツールへのエクスポートパスはドキュメント化されていません。これらを表示することは可能で、リポジトリ所有者はリポジトリレベルの事実を確認および削除できますが、手動で読み出すこと自体が移行作業となります。
この作業を思ったよりも苦痛でなくする詳細が1つあります。Copilot Memoryの適用範囲は、多くの人が想定しているよりも狭いということです。GitHubによると、「Copilot Memoryは現在、Copilotクラウドエージェント、Copilotコードレビュー、およびCopilot CLIで使用されています」。チームのCopilotの使用が主にエディタ内での補完とチャットであった場合、懸念していたよりも保存されている内容ははるかに少ない可能性があります。時間を割り当てる前に確認してください。Copilotがコードベースのコンテキストを忘れる理由を疑問に思わせるのと同じサーフェスの混乱が、ここでも当てはまります。
本ガイドでは、Copilot自体のレイヤーの仕組みについては再説明しません。まずそれを知りたい場合は、VS CodeでのCopilotメモリの設定で移行元について詳しく解説しています。以下では、移行を決定し、マッピング方法を知りたいという前提で進めます。
手動移行の手順
ステップ 1：各ルールが実際にどのCopilotレイヤーから来ていたかを特定し、インベントリを作成する
Devin側で何かを記述する前にこれを行ってください。優先順位によって、実際に有効だった動作がわかるからです。
Copilotの完全な優先順位（高い順）は、個人用指示、パス固有の指示、リポジトリ全体の指示、AGENTS.mdなどのエージェント指示、そして組織のカスタム指示です。もしある規約がcopilot-instructions.mdとAGENTS.mdの両方に存在していた場合、前者が優先されていました。両方をDevinの常時オン（always-on）レイヤーに移行すると、優先されていなかった規約が復活してしまいます。
以下の4つを収集します：
.github/copilot-instructions.mdの全内容- すべての
.github/instructions/**/*.instructions.mdとそのパスパターン。パターンこそが価値のある部分です。 AGENTS.md、CLAUDE.md、またはGEMINI.md（存在する場合）- 手動で読み出したCopilot Memoryの内容。リポジトリレベルの事実は労力をかける価値があります。ユーザーレベルの好みは個人ごとのものであり、単に再設定する方が簡単です。GitHubは「ユーザーはCopilotプランに関係なく、自身のユーザーレベルの好みを表示および削除できる」としているため、各自で行うことができます。
リポジトリレベルの事実を読み出す際、それらがどのように正確に保たれていたかについて、役立つ点に注意してください。それらは「それを裏付けるコードを指す引用とともに保存」されており、Copilotがそれを使用する際、「現在のブランチに対してそれらの引用をチェックし、情報が依然として正確であることを確認します。検証された事実のみが使用されます」。Devinにはこれを自動で行う機能はありません。移行した事実は、今後は自己責任で管理する必要があります。
ステップ 2：すべてのルールのアクティベーションモードを選択する（Devinでは必須）
これが実際の作業であり、大雑把な移行を行うとコンテキストウィンドウが肥大化する原因になります。
Devin Desktopのルールは.devin/rules（推奨され、.windsurf/よりも優先されます）に配置され、「現在のワークスペースディレクトリ」、「ワークスペースの任意のサブディレクトリ」、および「gitルートまでの親ディレクトリ」で検索されます。各ワークスペースルールは、フロントマターのtriggerフィールドを介してアクティベーションモードを宣言します：
| モード | trigger: | Cascadeへの到達方法 | コンテキストコスト |
|---|---|---|---|
| 常時オン (Always On) | always_on | すべてのメッセージのシステムプロンプトにルール内容全体が含まれる | すべてのメッセージ |
| モデルの決定 (Model Decision) | model_decision | 「システムプロンプトにはdescriptionのみが表示される」 | 常にdescription、必要に応じて全内容 |
| Glob | glob | globsに一致するファイルが読み込まれるか編集されたときに適用される | 一致するファイルが操作されたときのみ |
| 手動 (Manual) | manual | システムプロンプトには含まれず、@rule-name と入力して有効化する | @メンションされたときのみ |
Copilotからのマッピングはほぼ機械的に行えます。パス固有の.instructions.mdファイルはglobルールになります（パターンをそのまま移行します）。リポジトリ全体のcopilot-instructions.mdの内容は分割します。常に適用する必要がある部分はalways_onにし、状況に応じた部分はmodel_decisionにします。個人の好みはグローバルルールファイルに記述します。
考慮すべき2つの制限があります。「ワークスペースルールファイルはそれぞれ12,000文字に制限されています。グローバルルールファイルは6,000文字に制限されています。」また、そのグローバルファイルがどこにあるか注意してください。memoriesディレクトリ内の ~/.codeium/windsurf/memories/global_rules.md です。多くの人がグローバルルールがまったく存在しないと誤解しているのはこのためです。
そして、フロントマターの例外があります。「グローバルルールファイル（global_rules.md）とルートレベルのAGENTS.mdファイルはフロントマターを使用しません。これらは常にオンです。」これが導入部で触れた罠です。Copilotでは最優先度の低かったリポジトリ指示であるAGENTS.mdが、Devinでは無条件で適用されます。
最後に、移行を試みるべき内容自体を左右する重要な警告があります。Devin DesktopのMemoriesのドキュメントは、次の言葉で始まっています。「MemoriesはレガシーなCascadeエージェントにのみ適用されます。」さらに、「新規タブのデフォルトエージェントであるDevin Localエージェントは、Memoriesを永続化しません。」Copilot MemoryをDevinのMemoriesに移行する計画だった場合、デフォルトエージェントはそれを引き継ぎません。開発元の推奨事項は別の方向を指しています。「Cascadeに確実に再利用させたい知識については、自動生成されるMemoriesに頼るのではなく、ルールとして記述するか、リポジトリのAGENTS.mdに追加してください。ルールはバージョン管理可能で、チームと共有でき、アクティベーションを明示的に制御できます。」
このアドバイスに従いましょう。移行されたCopilot Memoryの事実の移行先は、Memoryではなく「ルール（Rule）」です。
より良い方法：アクティベーションモードが適用されない場所に事実を保管する
ステップ1と2を行えば、正しいDevinのセットアップが完了します。しかし同時に、6,000文字のグローバル制限、ファイルあたり12,000文字のワークスペース制限、およびプロジェクトに関して把握しているすべての事柄に対するアクティベーションモードの決定を迫られることになります。
アクティベーションモードは、ルール（どのように動作すべきかという指示）にとっては優れた設計です。しかし、事実（ファクト）には適していません。「npmではなくbunを使用する」にはトリガーが必要です。しかし、「チケット4471に記載されているアップストリームの挙動のため、決済サービスは3回リトライする」にはトリガーは不要です。必要なのは、関連する場面でいつでも見つけられることであり、すべてのメッセージでシステムプロンプトを消費することではありません。
これこそがメモリレイヤーが埋めるギャップであり、次の移行を低コストにする理由でもあります。MemoryLakeは3つのステップでセットアップできます。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。この認証情報はCopilotやDevinではなく、あなたのチームに属しているため、目の前にあるどのエージェントからでもストアを読み取ることができます。これには、独自のMemoriesを永続化しないDevin Localエージェントも含まれます。
ステップ 2：最初のメモリをアップロードする
ここに、読み出したCopilot Memoryの内容が入ります。リポジトリレベルの事実（アーキテクチャの決定、ビルドコマンド、プロジェクト固有のルール、およびその背景にある理由など）です。さらに、各自が回収したユーザーレベルの好みや、GitHub.com上のCopilot Chatにしか届いていなかった個人用指示もここに追加します。
本来の動作ルールは適切なトリガーを設定して.devin/rules/に残し、常に真である事実はAGENTS.mdに保持します。この切り分けが重要です。ルールを十分に小さく保つことで文字数制限内に収まり、事実がその制限枠を奪い合うこともなくなります。
ステップ 3：AIとエージェントを接続する
Devin Desktopをストアに向けます。ストアは外部にあるため、現在のタブがCascadeを実行しているか、Devin Localエージェントを実行しているかを気にする必要はありません。これが、DevinのMemoriesページのトップにある警告に対する実用的な解決策です。
実務における変化
最初の変化は、文字数制限が知識の設計上の制約にならなくなることです。6,000文字という制限は、エージェントがどのように動作すべきかを規定するには妥当な予算ですが、エージェントが何を知っておくべきかを規定するには不合理な制限です。
2つ目は、事実に対してアクティベーションモードの「税金」を支払う必要がなくなることです。model_decisionはすべてのメッセージのシステムプロンプトに説明（description）を配置し、関連性がありそうな場合に本体を取得します。これはルールとしては合理的ですが、個別に説明を記述しなければならない200個のドメインの事実に対して行うのは無駄です。
3つ目は、CascadeとDevin Localの分裂が他人の問題になることです。ベンダーがエージェントを再編成しても、コミットしたファイルと所有しているストアはどちらも存続します。すでにこれを実施していたチームは、ナレッジベースに手を加えることなく、WindsurfからDevin Desktopへの名称変更を乗り切りました。
CopilotからDevinへの移行におけるベストプラクティス
- コピーする前に優先順位を確認する。 規約が2つのCopilotレイヤーに存在していた場合、上位のレイヤーのみが有効でした。
- まずCopilot Memoryに実際に何が保持されているかを確認する。 これはCopilotクラウドエージェント、Copilotコードレビュー、およびCopilot CLIに対応しており、すべてのサーフェスをカバーしているわけではありません。移行する内容は予想よりも少ない可能性があります。
- パスパターンをそのまま移行する。 Copilotのパス固有の指示は、Devinの
globトリガーにきれいにマッピングされます。 - アクティベーションモードを意図的に割り当てる。 すべてをデフォルトの
always_onにすると、最初のプロンプトを送信する前にコンテキストウィンドウがいっぱいになってしまいます。 - memoriesディレクトリ内の
global_rules.mdを探す。 これは~/.codeium/windsurf/memories/global_rules.mdにあり、フロントマターなしで常にオンになります。 .windsurf/rulesよりも.devin/rulesを優先する。 こちらが推奨される場所であり優先されます。また、ワークスペースルートにあるレガシーな単一ファイル.windsurfrulesも依然として読み込まれるため、古い場合は削除してください。- 自動生成されるMemoriesに事実を移行しない。 Devinの公式ドキュメントでは、確実に再利用したいものについてはルールまたは
AGENTS.mdを推奨しており、デフォルトエージェントはMemoriesを一切永続化しません。 - 1週間後に何が残っているかを監査する。 誰も検証していない移行されたルールセットは、静かに半分無視されているルールセットです。AIが記憶している内容を監査することは、クリーンなセットアップから始めるための優れた習慣です。
結論
AGENTS.mdのおかげでこの移行は非常に簡単に見えますし、実際にそれが移行作業の最も優れた部分です。残りの作業は、2つの異なる哲学の間の翻訳作業です。Copilotは指示ソースに優先順位を付けてモデルにすべてを渡すのに対し、Devinはすべてのルールにいつロードされるべきかを宣言させます。
優先順位を手元に置きながら、この翻訳作業を一度、慎重に行ってください。そして、事実（決定事項、ドメイン知識、理由など）は、それぞれにトリガーを選択する必要のない場所に保管しましょう。