各サーフェスでどのCopilot指示ファイルが読み込まれるかを解決する方法（2026年版ガイド）

GitHubはリストの全文を公開しており、「以下のリストは完全な優先順位を示しており、このリストの上位にある指示は下位にある指示よりも優先されます」と紹介しています。その順序は以下の通りです。まず個人用の指示、次にリポジトリのカスタム指示（これ自体は「該当する .github/instructions/**/*.instructions.md ファイル内のパス固有の指示」、「.github/copilot-instructions.md ファイル内のリポジトリ全体の指示」、「エージェントの指示（例：AGENTS.md ファイル内）」の順に並びます）、そして最後に組織のカスタム指示です。

このリストの中で、人々を驚かせる点が3つあります。

個人用がすべてに勝る。 ソフトウェアのほとんどの指示システムでは、組織が最上位に位置し、個人が最下位になります。Copilotはその逆を行っており、これは意図的なものです。常に特定の言語で回答するという組織の指示はデフォルト設定であり、強制力はなく、個人がそれを上書きできます。GitHubは、組織の指示が「その組織からCopilotのサブスクリプションを受け取っているかどうかにかかわらず、組織のすべてのメンバーに適用される」と明記しています。つまり、広く適用されるにもかかわらず、優先順位は最後になります。

エージェントファイルはリポジトリファイルの下に位置する。 AGENTS.md、CLAUDE.md、GEMINI.md は、.github/instructions/**/*.instructions.md と .github/copilot-instructions.md の両方の下にリストされています。ベンダーに依存しないエージェントファイルに移行し、古いリポジトリファイルをそのまま残したチームは、意図せず新しいファイルの優先順位を下げてしまっています。移行の方向性自体は、独自のトレードオフを伴う実際の作業であり、これについては moving a CLAUDE.md into AGENTS.md や、この特定の移行先については moving a CLAUDE.md into Copilot で詳しく解説しています。

何も破棄されない。 これこそが、リスト全体の読み方を変える一文です。「ただし、関連するすべての指示セットがCopilotに提供されます。」ここでの優先順位は、敗者を切り捨てるフィルターではありません。適用可能なすべてのセットがモデルに渡され、競合が発生した場合にどちらが勝つかを順序が示しているに過ぎません。そのため、削除し忘れた矛盾するルールもプロンプト内に残り続け、コンテキストを消費し、予期しない表現で時折優先されてしまうことがあります。GitHubの推奨事項はこれに直結しています。「可能な限り、矛盾する指示セットを提供することは避けてください。」

これらすべての根底にあるのが、カバー範囲の問題です。エージェントの指示について、GitHubは「リポジトリ全体のカスタム指示と似ていますが、現在はすべてのCopilot機能でサポートされているわけではありません」とし、それらは「AGENTS.md、CLAUDE.md、または GEMINI.md というファイルで指定されます」と書いています。組織の指示については、サポートに関する注記はさらに限定的です。「組織のカスタム指示は、現在、GitHub.com上のCopilot Chat、GitHub.com上のCopilotコードレビュー、およびGitHub.com上のCopilotクラウドエージェントでのみサポートされています。」

これら2つの注記を合わせて読むと、実質的な全体像が見えてきます。どのファイルが回答を制御するかは、使用しているCopilotのサーフェスによって異なり、同じリポジトリであっても、エディタ内、GitHub.com上のチャット、プルリクエストのレビューで動作が異なる場合があります。しかも、どのルールが読み込まれたかを示すメッセージはどこにも表示されません。これは、why agents quietly skip your instruction files で説明した一般的な失敗パターンです。

ルールを1つ上のレベルで再追加する。 ルールが無視されたとき、それをエスカレーションしたくなるのが本能です。リポジトリファイルが機能しないなら、組織設定に入れてしまおう、というように。しかし、公開されている順序を考えると、これはルールを優先順位リストの下に移動させることになります。個人用の指示が矛盾している場合、エスカレーションは矛盾をさらに悪化させます。

すべてを1つのファイルに統合する。 合理的であり、競合を排除できます。しかし、パススコープの指示が得意とする唯一のメリットを捨てることにもなります。.github/instructions/**/*.instructions.md は一致する場所にのみ適用されるため、フロントエンドの規約がバックエンドの回答に混ざるのを防ぐことができます。すべてを単一のリポジトリ全体のファイルにまとめると、すべてのルールがグローバルになってしまいます。

どのサーフェスがどれを読み込むか確認せずに古いファイルを削除する。 答えを知っている場合にのみ安全な方法です。エージェントの指示はすべてのCopilot機能でサポートされているわけではないとドキュメントに明記されているため、AGENTS.md を優先して .github/copilot-instructions.md を削除すると、一部のサーフェスで何も適用されなくなる可能性があり、そのことは通知されません。

間違った場所でテストする。 エディタでリポジトリの指示を検証して「どこでも機能する」と結論付けたり、GitHub.comのチャットでテストしてその逆だと結論付けたりします。サーフェスごとのサポート状況を考慮すると、1つのテストは1つのサーフェスを証明するに過ぎません。

プルリクエストがマージされた状態を読み込むと仮定する。 そうではありません。GitHubは明確に述べています。「プルリクエストをレビューするとき、Copilotはベースブランチではなく、ヘッドブランチ（変更が含まれるブランチ）からリポジトリのカスタム指示、エージェントの指示、およびエージェントのスキルを読み込みます。」このメリットは同じ注記に「同じプルリクエスト内でそれらへの変更をテストできる」と記載されていますが、デメリットはその裏返しです。main から乖離したブランチは、それ自体の古いルールに基づいてレビューされてしまいます。

指示ファイルをメモリレイヤーとして扱う。 これらは再読み込みされる設定ファイルであり、蓄積される記録ではありません。永続的なメモリ側のセットアップは別の作業であり、setting up Copilot memory in VS Code で解説しています。

ゴールは、唯一の「正しい」ファイルを選ぶことではありません。特定の回答をどのファイルが制御しているかを、5秒で答えられるようにすることです。

ステップ 1：順序を書き出し、実際にどのファイルが存在するか確認する

まずはリポジトリに何が存在するかをリストアップすることから始めます。パススコープの指示ディレクトリ、リポジトリ全体のファイル、エージェントファイル、またはそれらの組み合わせです。そして、その横に個人用の指示を並べます。なぜなら、公開されている順序では、個人用の指示がこれら3つすべてを上回るからです。

この段階でよく発見されるのが、誰も追加した覚えのないファイルです。適用可能なすべてのセットはフィルターされずにCopilotに提供されるため、放置されたファイルも無効にはなっていません。プロンプト内に残り続けています。調整を始める前に、メンテナンスしていないファイルを削除しましょう。

ステップ 2：ファイルごとではなく、ルールごとにスコープを決定する

GitHub自身のガイダンスもスコープに関するものです。カスタム指示は「短く、自己完結した記述である場合に最も効果的」であり、「指示を個人、リポジトリ、または組織レベルのいずれに追加するかを選択する際には、指示を適用するスコープを考慮する」必要があります。

これが正しい判断軸です。言語の好みは個人用です。フレームワークの規約はリポジトリ全体です。特定のディレクトリにのみ適用されるルールはパススコープのファイルに属します（これは統合によって失われる唯一の機能です）。すべてのメンバーがデフォルトで受け取り、上書き可能なポリシーは組織レベルのものです。これは、優先順位が最後であり、GitHub.comの3つのサーフェスでサポートされていることを理解した上で作成する価値があります。

ステップ 3：サーフェスごとに検証し、レビュー対象のブランチで検証する

チームが実際に使用している各サーフェスで同じプロンプトを実行し、ルールがどこで適用されるかを記録します。これは、繰り返される議論を終わらせるための10分間の作業です。

プルリクエストについては、ヘッドブランチのルールを思い出してください。指示ファイルを変更し、レビューにそれを反映させたい場合は、レビュー対象のブランチで変更を行ってください。長期にわたるブランチで、先月全員が合意したルールを無視したレビューが生成されている場合は、そのルールがそのブランチに反映されているか確認してください。リポジトリ全体で競合するレイヤーは、それ自体がメンテナンス上の問題となります。これについては reconciling contradictory instruction layers で取り上げています。

指示ファイルは「どのように振る舞うべきか」に答えるものです。しかし、人々がそこに保存しようとしがちな「私たちは何を、なぜ決定したのか」を保存するには不向きな場所です。MemoryLakeは、それらの決定事項を意図的に書き込むためのストアであり、特定のツールの設定とは切り離され、接続したすべてのAIアシスタントから読み取ることができます。エントリーはあなた自身の言葉で書き込みます。GitHubのシステムや他のベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。リポジトリファイルやCopilotの設定は、完全に独自の制御下に置かれたままになります。

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

ダッシュボードからキーを生成します。これにより、Copilot、ターミナルエージェント、チャットアシスタントが、それぞれ独自のファイルを必要とすることなく、同じ事実のセットにアクセスできるようになります。

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

ルールの背景にある決定事項から始めましょう。なぜその規約が存在するのか、何に代わるものなのか、どのアプローチがどのような理由で除外されたのか。指示ファイルはルールを伝えますが、その理由を伝えることはほとんどありません。理由こそが、次の人によってルールが覆されるのを防ぐものです。

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

ツールをこのレイヤーに向けることで、ルールファイルから推測させるのではなく、セッションの開始時にそれらの事実を読み込ませることができます。そして、唯一の確実な方法でテストしてください。別のアシスタントに、以前の決定事項の1つを尋ねてみてください。回答が得られれば、あなたの意思決定の根拠は特定のベンダーのファイル形式に縛られなくなったことになります。

第1の変化は、優先順位に関する議論が終わることです。順序は公開されており、個人が組織を上回り、適用可能なすべてのセットが提供されます。チームでこのリストを一度確認すれば、議論のほとんどは簡単なクリーンアップ作業へと変わります。

第2に、カバー範囲が人々が実際に問いかける質問になることです。「どのファイルが優先されるか」よりも「ここではどのファイルが読み込まれているか」の方がはるかに重要であり、サーフェスごとのサポートに関する注記には驚きが隠されています。

第3に、放置されたファイルが無害ではなくなることです。適用可能なすべてのセットがモデルに届くため、古いファイルもアクティブに機能してしまいます。削除を単なる「片付け」ではなく「メンテナンス」として扱うことで、行動がすぐに変わります。

第4に、プルリクエストのレビューが予測可能になることです。ヘッドブランチから指示を読み込むのは合理的な設計であり、同じプルリクエスト内でルールの変更をテストできます。これが罠になるのは、その仕様を知らない場合だけです。

スコープごとに1つのファイルを保持し、残りは削除する。 ディレクトリのルールにはパススコープ、プロジェクトのルールにはリポジトリ全体、他のツールが必要とする場所にはエージェントファイル、自分用には個人用を使用します。

短く、自己完結した記述にする。 GitHub自身のガイダンスであり、複数のセットが組み合わされる場合にさらに重要になります。

個人用の指示が優先されることを想定する。 チームのルールが無視され続ける場合は、リポジトリファイルを書き換える前に、誰かの個人設定が矛盾していないか確認してください。

各サーフェスを個別に検証する。 エージェントの指示はすべてのCopilot機能でサポートされているわけではなく、組織の指示はGitHub.comの3つのサーフェスでサポートされているとドキュメントに記載されています。

レビュー対象のブランチで指示ファイルを変更する。 プルリクエストのレビューは、ベースブランチではなくヘッドブランチから指示を読み込みます。

意思決定の根拠は別の場所に保管する。 履歴まで含んだルールファイルは短く保つことができなくなります。短く保つことこそが、ルールを機能させる鍵です。

GitHubはCopilotの指示に関する完全な優先順位を公開しており、その全体像を把握しておく価値は十分にあります。まず個人用の指示、次にパススコープのリポジトリ指示、続いてリポジトリ全体のファイル、そして AGENTS.md などのエージェントファイル、最後に組織の指示となります。適用可能なすべてのセットがCopilotに提供されるため、優先順位は敗者を排除するのではなく、競合を解決するために使用されます。

多くの午後を無駄にする原因となるのは、順序よりもカバー範囲です。エージェントの指示は「現在はすべてのCopilot機能でサポートされているわけではない」とされ、組織の指示はGitHub.comの3つのサーフェスでサポートされているとドキュメントに記載されており、プルリクエストのレビューはヘッドブランチからこれらのファイルを読み込みます。ルールが完璧に書かれ、正しく配置されていても、テストした場所で単に読み込まれていないだけということがあります。

これらは欠陥ではなく、GitHubはすべてをオープンにドキュメント化しています。実用的なアプローチは、保持するファイルを減らし、各ルールのスコープを意図的に決定し、チームが使用する各サーフェスで検証し、ルールの背景にある意思決定の根拠を設定ファイル以外の場所に保管することです。