コンテキストを失わずに GitHub Copilot から Factory Droid へ移行する方法 (2026)

Copilot は、3つのタイプの リポジトリ カスタム指示と、それらの上下にあるさらに2つのレイヤーをドキュメント化しています。

リポジトリレベルの3つは以下の通りです：

"リポジトリ全体のカスタム指示。リポジトリのコンテキストで行われるすべてのリクエストに適用されます。これらは、リポジトリの .github ディレクトリにある copilot-instructions.md ファイルで指定されます。"

"パス固有のカスタム指示。指定されたパスに一致するファイルのコンテキストで行われるリクエストに適用されます。これらは、リポジトリ内の .github/instructions ディレクトリ内またはその下にある1つ以上の NAME.instructions.md ファイルで指定されます。"

"エージェント指示。リポジトリ全体のカスタム指示に似ていますが、現在はすべての Copilot 機能でサポートされているわけではありません。これらは AGENTS.md、CLAUDE.md、または GEMINI.md というファイルで指定されます。"

それらの上には、GitHub.com の Copilot Chat ページのポップアップで設定し、「Copilot があなたにのみ適用する」個人用の指示（personal instructions）が存在します。それらの下には、「Copilot Business または Copilot Enterprise サブスクリプションを持つ組織の組織オーナーのみが設定できる」組織のカスタム指示（organization custom instructions）が存在します。

優先順位のチェーンは、上から下へとドキュメント化されています：個人用の指示、パス固有、リポジトリ全体、エージェント指示、そして組織。そして、そのセクションには移行計画の立て方を変える一文があります：

"Copilot に送信されるリクエストには、複数のタイプのカスタム指示を適用できます。個人用の指示が最も高い優先順位を持ち、次にリポジトリの指示、最後に組織の指示が優先されます。ただし、関連するすべての指示セットが Copilot に提供されます。"

最後の文を注意深く読んでください。優先順位は競合を解決するものであり、何かを除外するものではありません。関連するものはすべて投入されます。

Factory のモデルは意図的により狭く定義されています。その AGENTS.md のドキュメントでは、特定の役割を持つ1つのファイルについて説明されています：

"AGENTS.md は、Droid がすべてのセッションに持ち込むべきプロジェクトの概要（インストール、実行、テスト、編集、検証の方法、およびリポジトリの境界内に留まる方法）を提供します。"

そして、構造とスコープについて明示しています：

"リポジトリのルートに AGENTS.md を追加します。まずは1つのファイルから始め、パッケージ、アプリ、またはサービスで異なるルールが必要な場合にのみ、ネストされたファイルを追加します。"

"Droid がコードを書く前にロードすべきガイダンスとして使用してください。短く、具体的で、検証しやすい内容に保ちます。"

したがって、移行されるものは以下の通りです。リポジトリ全体のファイルはほぼ直接移行されます。すでに Copilot のエージェント指示用に AGENTS.md を用意している場合、それはそのまま移行され、最も優先順位の低いものではなく、主要なインターフェースになります。パス固有の指示は、内容は移行されますが、仕組みが変わります。そして、個人用および組織の指示は、コピーするものが存在しないため、まったく移行されません。一方はあなたにスコープされたウェブのポップアップにあり、もう一方は会社にスコープされた組織設定にあるからです。

ステップ 1: ファイルではない2つのレイヤーを収集し、その移行先を決定する

これは見落とされがちなステップなので、最初に実行してください。

個人用の指示。 GitHub.com の Copilot Chat ページを開き、そのポップアップに何が書かれているかを確認します。ほとんどのチームにおいて、そこには2種類の内容が含まれています。1つは純粋な個人の好み（「1行につき1つの概念のみを説明する」、「常にポルトガル語で回答する」など、ドキュメント自体の例）、もう1つは、プロジェクトの動作方法を記述しており、チームメンバー全員が必要とするため、そもそも個人用にするべきではなかったルールです。

これらを分割しましょう。個人の好みは、macOS および Linux の ~/.factory/settings.json（およびオプションの settings.local.json）にある Factory のユーザーレベルの設定に配置します。個人用ポップアップに隠れていたプロジェクトのルールは、リポジトリの AGENTS.md に配置し、チームの他のメンバーも利用できるようにします。これは通常、移行全体の中で最も価値のある成果ですが、ファイルのみを移行している場合には見落とされてしまいます。

組織の指示。 これらは管理者に読み出してもらう必要があります。Factory の指示インターフェースには組織ごとの同等のレイヤーがドキュメント化されていませんが、キャプチャしておく価値はあります。Copilot 自身のドキュメントでは、その適用範囲が制限されていることに注意してください。それらは「現在、GitHub.com の Copilot Chat、GitHub.com の Copilot コードレビュー、および GitHub.com の Copilot クラウドエージェントでのみサポートされています」。そのため、組織の指示が IDE セッションにまったく影響を与えていなかった可能性が十分にあります。どれだけ引き継ぐかを決める前に、それを確認してください。

すべてのリポジトリに真に適用されるものは、ユーザーレベルまたはプロジェクトレベルの .factory/ 設定、およびリポジトリの AGENTS.md に配置します。IDE に届くことのなかったコンプライアンスの定型文などは、その理由をメモに残した上で破棄して構いません。

ステップ 2: Copilot が先送りにしていた競合を解決し、スコープを再構築する

Copilot は関連するすべての指示セットを提供し、優先順位は不一致を解決するためだけに機能するため、チームは互いに矛盾する2つのレイヤーを抱えたまま1年間気づかずに運用できてしまいます。優先順位の高い方が勝ち、低い方はただそこに置かれたままになります。

Factory のガイダンスは逆のアプローチを取ります。その AGENTS.md のドキュメントでは、「短く、具体的で、検証しやすい」ルールを求めており、正確なインストール、開発、テスト、型チェック、Lint、ビルドのコマンドを最初に記述することを推奨し、何がどこに属するかの明確な境界線を引いています：

"人間向けのオンボーディング、スクリーンショット、コントリビューターの背景情報は README.md に残してください。Droid 固有のコマンド、ガードレール、および完了基準は AGENTS.md に記述します。"

また、Copilot のフォーマットにはないもの、すなわち Droid が作業完了とみなす前に必要な証明を明記する「検証（verification）」セクションも求められます。ドキュメントでは、Droid の動作を変更する具体的なルールと、「チェックできない曖昧なルール」を対比させています。もし copilot-instructions.md に「良いコードを書く」といった行が含まれているなら、それは移植するのではなく、ここで削除すべきです。

したがって、まずコマンドを記述し、次にリポジトリマップ、規約、テストルール、生成ファイルに関するルール、セキュリティ境界、および検証ステップを記述した1つのルート AGENTS.md を作成します。古い2つのレイヤーが矛盾していた場合は、どちらか一方を選択してください。この決定は実際の作業であり、Copilot の優先順位チェーンがこれまでは代わりに吸収してくれていた作業です。すでに Copilot ファイルと並行して CLAUDE.md を維持している場合、converting a CLAUDE.md into Copilot's instruction format では、そのような統合で何が残り、何が残らないかをカバーしています。また、新しいファイルの長さを決める前に、what coding agents actually read を一読する価値があります。

次に、パス固有のファイルを処理します。Copilot の .github/instructions/NAME.instructions.md ファイルはファイルパターンをターゲットにしており、ドキュメントではその存在理由を次のように説明しています：「パス固有の指示を使用することで、特定のタイプまたは特定のディレクトリのファイルにのみ適用される情報でリポジトリ全体の指示を過負荷にすることを避けることができます。」

その目的は維持されますが、仕組みが変わります。Factory は、ネストされた AGENTS.md ファイルをディレクトリ単位でスコープします（「パッケージ、アプリ、またはサービスで異なるルールが必要な場合にのみ、ネストされたファイルを追加します」）。ディレクトリにスコープされたルールは、そのディレクトリに AGENTS.md を配置することで綺麗に移植できます。ツリー全体にわたるファイル タイプ にスコープされたルールには、配置する特定のディレクトリがないため、2つの現実的な選択肢があります。そのファイルタイプが特定の領域に集中している場合は、そこに配置します。リポジトリ全体に真にまたがっている場合は、ルールの最初の文でそのスコープを明記し、パターンマッチングではなく記述によって適用されることを受け入れます。

リポジトリ内で確認すべきことがもう1つあります。もし .droid.yaml が見つかった場合、それは非推奨のインターフェースです。Factory の設定ドキュメントでは、代わりに現在の .factory/ ファイルを使用し、「リポジトリの指示、規約、および検証コマンドには AGENTS.md を使用する」よう指示されています。

上記の2つのステップは、翻訳作業と一連の意思決定です。意思決定こそがコストのかかる部分であり、現時点では移行を行った人の頭の中にしか存在しません。

それこそが、永続的な場所に保管しておく価値のあるレイヤーです。個人用の指示とリポジトリの指示の間の競合を解決したとき、プロジェクトが実際にどの規約に従うかについての判断を下しました。「良いコードを書く」を削除したとき、それは検証不可能であると判断しました。半年後、誰かが残されたルールを見つけて、なぜそのような記述になっているのか疑問に思うでしょう。

MemoryLake は、これらの決定を両方の製品の外部に保持し、MCP または API を介して、要求するあらゆるエージェントに提供します。Copilot 独自のメモリ機能や Factory 独自の設定はそのまま残り、ベンダーのドキュメント通りに動作し続けます。

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

キーを生成し、約30秒で最初のリクエストを送信できます。上記のステップ2を開始する前にこれを行うことで、決定を下すごとにそれを保存する場所を確保できます。

ステップ 2: 最初のメモリをアップロードする

解決したすべての競合は、保持する価値のあるメモリです。どのルールが勝ち、どのルールが負け、それはなぜか。特定のインシデントから生まれたルールや、意図的に使用しないライブラリやパターンを追加します。ドキュメントやその他のサポートファイルも同じ場所に保存されます。

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

Claude、Codex、OpenClaw、および Droid に MCP または API 経由でアクセスを許可します。接続されると、「なぜこれが規約なのか」という疑問に対して理由が紐づいた形で回答されるため、ルートの AGENTS.md を Factory が推奨する通りに短く保つことができます。

最初の変化は、個人用の指示に関する問題が再発しなくなることです。1人のポップアップに隠れていたプロジェクトのルールがリポジトリに配置され、その推論が共有ストアに保存されれば、チームのルールを静かに上書きするプライベートなレイヤーは存在しなくなります。

2つ目は Spec Mode についてです。これは Factory が最も価値のある成果物を生成する場所であると同時に、耐久性のギャップが存在する場所でもあります。Spec Mode は、承認を求めて終了する読み取り専用の計画フェーズであり、その間 Droid は「ファイルの編集、設定の変更、コミットの作成、サービスの起動、または外部システムへの書き込みを行うべきではありません」。生成される計画は、まさに適切なタイミングで書き留められた変更の推論です。しかし、デフォルトの保存場所は ~/.factory/specs であり、これはリポジトリ外のユーザーごとのディレクトリです。これは妥当なデフォルトであり、specSaveDir を介して設定可能です。しかし、これが原因で、優れた計画が1台のノートPC上にのみ存在し、他の場所には存在しないという状況が発生します。specSaveDir をコミット対象の場所に向けるか、結論を共有ストアに移動する習慣をつけてください。

3つ目の変化は、次のツール移行の際に現れます。指示ファイルは再び書き直されることになります。これは避けられないことであり、ツールのフォーマットはそれぞれ少しずつ異なります。しかし、その背後にある決定事項は書き直す必要がありません。それらは誰の指示フォーマットにも依存していなかったからです。

ファイルに触れる前に、個人用の指示のポップアップを確認する。 これは最も優先順位が高く、最も視認性が低いレイヤーであり、そこに含まれる内容の一部はチーム全体で共有されるべきものです。

管理者に組織の指示を求め、それらが実際に適用されていたか確認する。 Copilot のドキュメントでは、それらのサポートを特定のインターフェースに制限しています。IDE に届くことのなかったルールを引き継ぐのは無駄な作業です。

移植するのではなく、検証不可能なものはすべて削除する。 Factory のドキュメントでは、チェック可能なルールを求めており、曖昧なルールと対比させています。誰も検証できないルールは、Copilot でも何も機能していませんでした。

コマンドを最初に記述する。 インストール、実行、テスト、型チェック、Lint、ビルド。Factory 独自のステップ順序でもこれが推奨されており、最初のセッションから効果を発揮する指示ファイルの部分です。

検証セクションを記述する。 Droid が作業完了とみなす前に必要な証明を明記します。Copilot の指示フォーマットではこれが求められていなかったため、まだ作成していない可能性が高いでしょう。

初日にスペックの保存場所を決定する。 デフォルトはリポジトリ外のユーザーごとのディレクトリです。specSaveDir を共有の場所に向けるか、手動で推論を移行してください。

Copilot から Factory Droid への移行は、ファイルのコピーに加えて、ファイルではない2つの要素の処理を伴います。個人用の指示は GitHub.com のポップアップに存在し、他のすべてに優先します。組織の指示は会社の設定に存在し、Copilot 自身のドキュメントによれば、特定のインターフェースにのみ適用されます。どちらも何かをコピーするだけでは移行できず、前者は通常、非公開にするべきではなかったプロジェクトのルールを含んでいます。

作業の後半は、Copilot の優先順位チェーンが吸収していた競合を解決することです。関連するすべての指示セットが提供され、優先順位は不一致を解決するためだけに機能するため、矛盾が長期間気づかれないまま放置される可能性があります。Factory は、具体的でチェック可能なルールを持つ1つの短いルートファイルを求めているため、誰かが実際に勝者（採用するルール）を選択する必要があります。

まずはファイルではない2つのレイヤーを処理し、競合を意図的に解決し、スペックの保存場所を決定し、指示フォーマットに依存しない場所に推論を保持してください。