実際に移行されるもの
Copilot のカスタマイズ領域には5つのレイヤーがあり、そのうちファイルであるのは3つだけです。
個人用の指示（Personal instructions）。 ドキュメントでは、そのスコープと場所について明記されています。これらは「GitHub の GitHub Copilot Chat でのみサポート」され、「GitHub.com の Copilot Chat ページのポップアップで設定」し、Copilot はそれを「あなたにのみ適用」します。ファイルは存在しません。リポジトリもありません。個人ごとにウェブページ上のテキストボックスがあるだけです。
リポジトリのカスタム指示（Repository custom instructions）。 これには3つのタイプがあります。.github ディレクトリ内の copilot-instructions.md ファイルに記述するリポジトリ全体の指示。.github/instructions 内またはその配下にある、末尾が .instructions.md で終わる1つ以上のファイルに記述するパス固有の指示。そして、ドキュメントで「リポジトリ全体のカスタム指示に似ているが、現在はすべての Copilot 機能でサポートされているわけではない」と説明されている、AGENTS.md、CLAUDE.md、または GEMINI.md というファイルで指定するエージェント指示です。
組織のカスタム指示（Organization custom instructions）。 組織のオーナーが Copilot の設定で指定するもので、ドキュメントの言葉を借りれば、「その組織から Copilot のサブスクリプションを受け取っているかどうかにかかわらず、組織のすべてのメンバーに適用」されます。
これらが解決される順序は以下の通りです：
「Copilot に送信されるリクエストには、複数タイプのカスタム指示を適用できます。個人用の指示が最優先されます。次にリポジトリの指示が続き、組織の指示は最後に優先されます。ただし、関連するすべての指示セットが Copilot に提供されます。」
この最後の1文は、多くの人が見落としがちです。優先順位は競合を解決するものであり、レイヤーを削除するものではありません。適用可能なすべての指示は依然として送信されます。したがって、組織の標準と矛盾する個人用の指示は、それを置き換えるのではなく、両方がコンテキストに残ったまま、個人用の指示が上位にランクされるだけです。
Tabnine 側では、これに相当する領域は「ガイドライン（guidelines）」です。ドキュメントでは、これらを「プロジェクトの /.tabnine/guidelines/ ディレクトリに保存された Markdown ファイル」と説明しており、このディレクトリはホームディレクトリまたはプロジェクトごとに配置できるとされています。Tabnine 自身の例えとしては、「これらは、他のエージェントツールが使用する agents.md ファイルと同様のものと考えてください」とあります。サイズに関するアドバイスは「guidelines.md ファイルは500行以下に抑えること」です。
そして、移行を根底から覆す一文がこれです。管理コンソール（Admin Console）に入力されたガイドラインについての説明です：
「ここに入力されたガイドラインは、guidelines.mdファイルに記載されているガイドラインと同じ効果を持ちますが、guidelines.mdファイルに存在する個人用のガイドラインよりも優先されます。」
つまり、ファイルは移行できます。Tabnine は複数のガイドラインファイルをサポートしているため、パス固有のスコープ設定もおおむね移行できます。移行できないのは「解決の順序」です。そして、移行先がまったく存在しないのが「ポップアップ」です。これはリポジトリに存在せず、レビューもされず、他の誰にも見えなかった個人ごとの指示です。
これらすべてと区別しておくべき重要な点として、これらのレイヤーはいずれも「コードベースの認識（codebase awareness）」ではないということです。指示ファイルはアシスタントに「どのように振る舞うか」を伝えるものであり、コードに「何が含まれているか」を伝えるものではありません。だからこそ、Copilot がコードベースのコンテキストを忘れる問題 という不満は、Copilot がルールを無視するという不満とは別物なのです。最初の問題に対する Tabnine の回答は「パーソナライズ（Personalization）」と「接続（Connection）」機能であり、2番目の問題に対する回答は「ガイドライン」です。一方を解決することを期待して、もう一方を移行しないでください。
作業を計画する前に知っておくべき2つ目の構造的な違いがあります。これはチームを二分する可能性があるため重要です。Tabnine の CLI は、IDE プラグインのようにプロジェクトのガイドラインディレクトリを読み込みません。ドキュメントの冒頭には、その違いがはっきりと述べられています：
「エージェントのガイドラインは、Tabnine CLI と Tabnine IDE プラグインで管理方法が異なります。」
CLI には2つのフローがあります。組織およびサービスアカウントの指示は「エージェントの動作コンテキストに追加」され、CLI の起動時に認証済みアカウントに対して自動的に取得されます。これとは別に、コーディングガイドラインは、エージェントが言語固有のルールを必要とするときに呼び出す、組み込みの Tabnine Coaching Guidelines ツールを介してアクセスできます。ドキュメントでは、トグルスイッチが一方のみを制御するため、この2つを慎重に区別しています：
「この設定は、組織またはサービスアカウントの指示が取得され、セッションコンテキストに追加されるかどうかを制御するものではありません。」
手動での移行手順
ステップは2つありますが、最初のステップは誰もがスキップしがちなものです。
ステップ 1：ポップアップから個人用の指示を取り出す
ファイルに1つも触れる前に、チームの全員に GitHub.com の Copilot Chat ページを開いてもらい、個人用の指示を声に出して読んでもらいます。要約ではなく、そのまま読んでもらってください。
これは単なる雑用のように思えるかもしれませんが、移行作業全体の中で最も価値のある時間となります。理由は2つあります。第一に、個人用の指示は Copilot の優先順位の最上位にあるため、そこに書かれている内容は、リポジトリの標準や組織の設定との競合において、これまで密かに勝ち続けてきたからです。第二に、それらは目に見えません。grep できるファイルも、レビューする PR も、監査トレイルもありません。もし誰かが8ヶ月前に「常に古いクライアントライブラリを使用すること。新しいものはプロキシを破損させる」と書いていたとしたら、その指示はそれ以来ずっとその人の出力を左右し続けており、他の誰もその存在を知りません。
出てきた内容を2つの山に分類します。回答の言語、冗長性、1行に1つの概念を説明する、といった純粋な個人の好みは、個人の設定として残します。個人用の設定を装った「プロジェクトの事実」は、リポジトリに移動します。なぜなら、それらは本来リポジトリにあるべきものだからです。これは、エージェントが指示ファイルを無視する理由 の背後にあるのと同じ失敗パターンです。勝つ指示は、あなたが書いたと思っている指示ではないのです。
そのポップアップを確認する際、Copilot のもう1つのユーザーごとの領域である IDE 内のメモリ機能（VS Code での Copilot メモリの設定 で解説）も、個人ごとでありファイルではないことに注意してください。これらも合わせて確認しましょう。
ステップ 2：ファイルレイヤーをガイドラインとして再構築し、すべての競合を再決定する
ここからは、機械的なコピー作業と、そうではない作業に入ります。
リポジトリ全体の copilot-instructions.md は、.tabnine/guidelines/ 内のガイドラインファイルになります。パス固有の .instructions.md ファイルは、追加のガイドラインファイルになります。Tabnine はディレクトリから複数のファイルを読み込むため、マージせずに個別のままにし、対象とする内容に応じた名前を付けてください。AGENTS.md は、スタック内の他のツールが読み取るオープンな規約であるため、そのままの場所に置いておくことができます。ただし、Tabnine のドキュメントが指し示しているのは独自のガイドラインディレクトリであることに注意してください。もし指示ファイルが元々別の場所から始まったものであれば、CLAUDE.md を Copilot に移行する で、それらがどのような形で到着したかを解説しています。
ここで1つ、ちょっとした修正をしておきましょう。Tabnine のドキュメントでは、この例えを小文字の agents.md と表記しています。しかし、同じ規約を読み取る他のツールは、大文字のファイル名を要求し、小文字のものは黙ってスキップします。複数のツールで共有されるリポジトリでは、AGENTS.md と命名してください。
そして、ここからが本当の作業です。組織の標準と誰かの個人用の指示が矛盾していたすべての箇所について、どちらを優先するかを決定する必要があります。なぜなら、Tabnine の管理コンソールは自動的に一方を選択し、それは Copilot が選択した方とは真逆になるからです。競合を1つずつ確認し、各ルールをどのレイヤーに配置すべきかを決定してください。真に組織の標準であるものはすべて管理コンソールに配置します。これにより、管理コンソールの設定が全員のローカルファイルよりも優先されるようになります。なお、ドキュメントに記載されている反映の遅延に注意してください。変更は「15分後に IDE 拡張機能に適用されるか、IDE または拡張機能の再起動時に適用されます」。
このはまた、どのような移行ガイドでも代行できない事実に直面する場所でもあります。どのルールが勝つかを決定するには、各ルールが「なぜ存在するのか」を知る必要があり、その情報はどちらのツールにも含まれていないということです。
より良い方法：管理コンソールでも上書きできない決定レイヤー
ステップ2で解決しようとしている競合が難しいのは、その理由がどこにも書き残されていないからです。「古いクライアントライブラリを使用する」と「現在の SDK に標準化する」という2つの命令は、そのままでは解決できません。しかし、一方が「プロキシが壊れた週」に書かれたものであり、そのプロキシは「6月にリプレイス済み」であることを知れば、解決は極めて容易になります。
MemoryLake は、このレイヤー（決定事項、却下された代替案、およびその理由）を両方のツールの外部で保持し、MCP または API を介して要求してきたエージェントに提供します。ガイドラインは .tabnine/guidelines/ 内で短く命令的な状態を維持し、管理コンソールは標準を保持し、それぞれの背景にある「なぜ」は、誰でもどのツールからでもクエリできるようになります。
ステップ 1：API キーの作成
キーを生成し、約30秒で最初のリクエストを実行します。競合を解決しながら記録できるように、上記のステップ2を行う前にこれを実行してください。
ステップ 2：最初の記憶（Memories）をアップロードする
残したすべてのルールについて、何が決定され、何が除外され、それはなぜなのかを書き留めます。ステップ1で収集した個人用の指示は、ここでの最も豊富な情報源です。そのほとんどは、実際の障害や出来事を反映しています。サポートドキュメントやファイルも同じ場所に保存します。
ステップ 3：AI とエージェントを接続する
Tabnine、Claude、Codex、およびその他のエージェントに、MCP または API 経由でアクセス権を付与します。次に新しい標準が提案されたとき、「それ、以前試さなかったっけ？」という疑問に対する答えが、その理由とともに提示されます。
実務における変化
最初の変化は、目に見えなかったレイヤーが可視化されることです。Copilot の最優先の指示領域は個人ごとのテキストボックスでした。この移行後、それに相当する内容は、明示的な個人の好みか、記録されたプロジェクトの決定事項のいずれかになり、後者はチーム全体で閲覧可能になります。
第二に、管理コンソールの優先順位が、罠ではなく「機能」になることです。組織の標準が、レビューされ、理由付けされ、記録された、真に組織的なものになれば、それがローカルファイルよりも優先されることは望ましい挙動になります。この逆転現象が牙をむくのは、管理コンソールに「推測」しか入っていない場合だけです。
第三に、IDE と CLI の分裂によるチームの断片化が解消されることです。IDE を使う開発者はガイドラインファイルを読み込み、CLI を使う開発者は組織やサービスアカウントの指示、および Coaching Guidelines ツールを利用します。これらは異なる仕組みですが、双方がクエリできる共有の「理由付けレイヤー」があれば、両者の回答を一致させることができます。
第四に、次の移行は本当に「ファイルのコピー」だけで済むようになることです。今回の移行を困難にした部分（命令から意図を再構築する作業）は、一度行えば終わりです。これは、コーディングエージェントが実際に読んでいるもの が、特定のツールが好むファイル形式よりも重要であるのと同じ理由です。
Tabnine 移行後のベストプラクティス
ファイルを監査する前に、ポップアップを監査する。 個人用の指示は Copilot において最優先事項であり、ファイルの履歴が残りません。これらは、後から再構築できない唯一の古い設定部分です。
標準は管理コンソールに、好みはローカルファイルに配置する。 優先順位の仕組み上、この切り分けが有利に働きます。ローカルで標準を重複させてこれに抗おうとしても、どうせコンソール側が勝つため、競合が発生するだけです。
ガイドラインファイルは短く、個別に保つ。 ドキュメントでは1ファイルあたり500行以下を推奨しており、ディレクトリは複数のファイルをサポートしています。1つの長いファイルにするよりも、1ファイルにつき1つのトピックにする方が優れています。
反映の遅延を忘れない。 管理コンソールの変更が IDE 拡張機能に届くまでには、待機時間か再起動が必要です。標準が変更されたときは、相手が見たと思い込まずに、直接伝えるようにしましょう。
CLI がプロジェクトのガイドラインを読み込んでいると思い込まない。 CLI のドキュメント化されたフローは、組織およびサービスアカウントの指示、および Coaching Guidelines ツールです。チームが両方の環境に分かれている場合は、それぞれが実際に何をロードしているかを確認してください。
大文字の AGENTS.md を使用する。 あるベンダーの小文字の例は、別のベンダーにとっては黙って見落とされる原因になります。正しく設定するのにコストはかかりません。
ルールの隣に理由を書く。 今回の移行で解決したすべての競合は、誰かが「原因」を書かずに「命令」だけを書いたために発生しました。理由を保存する場所がない限り、次の移行でも同じことが起こります。
結論
GitHub Copilot から Tabnine への移行は、3つのファイルレイヤーをきれいに移動させますが、目に見えない1つの要素を逆転させます。Copilot は個人用の指示を最優先、組織の指示を最下位としてドキュメント化しつつ、適用可能なすべてのレイヤーをモデルに送信します。Tabnine は、管理コンソールが個人用の guidelines.md よりも優先されるとドキュメント化しています。これに対処せずにファイルをコピーするだけでは、これまで勝っていたルールが、静かに負け始めることになります。
移行を安全にする作業は、コピーではありません。ポップアップを空にし、純粋な好みとプロジェクトの事実を分類し、各ルールをどのレイヤーに持たせるかを決定することです。そして、それはルールが存在する「理由」を知っていて初めて可能になります。それを両方のツールの外部に一度記録しておけば、将来のあらゆる移行は、今回の移行が外から見えていた通りの姿（いくつかの Markdown を移動してサインインするだけ）になります。