GitHub Copilotは、コードの提案だけでなく「チームやプロジェクトのルールをどれだけ理解してくれるか」で使い勝手が大きく変わります。そのための仕組みが「カスタム指示(custom instructions)」です。本記事では、リポジトリ全体に効くcopilot-instructions.mdの基本から、ファイルの種類ごとに指示を出し分けるapplyToの使い方、そして「指示を書いたのに反映されない」という典型的なトラブルの対処法まで、公式ドキュメントをもとにまとめます。
GitHub Copilotの「カスタム指示」とは
カスタム指示とは、Copilotに「このプロジェクトではどんなルールでコードを書いてほしいか」をあらかじめ伝えておく仕組みです。設定しておくと、コーディングエージェントやCopilot Chatが提案・レビューを行う際に、そのルールを踏まえた回答を返してくれるようになります。
ここでのポイントは、Copilotに社内独自のコーディング規約やレビュー方針を、毎回説明し直さなくて済むという点です。プロンプトを都度書く手間を減らし、アウトプットの品質を安定させる効果があります。
なぜ必要なのか
カスタム指示を設定しないままだと、Copilotは会話ごとに文脈をゼロから推測することになり、プロジェクト固有のルール(命名規則、使用ライブラリ、禁止事項など)を無視した提案を出しがちです。指示ファイルを用意しておくことで、こうしたブレを減らし、レビューの手戻りを減らすことができます。
リポジトリ全体に効く「copilot-instructions.md」
作成方法
もっとも基本的な方法は、リポジトリのルート直下に.github/copilot-instructions.mdというファイルを作成することです。特別なスキーマは不要で、Markdown形式で自然言語のまま指示を書けます。このファイルはCopilot Chatに対してデフォルトで有効になっており、必要に応じて無効化・再有効化も可能です。
書き方のポイント(公式ブログのTipsより)
GitHub公式ブログでは、良いカスタム指示を書くコツとして以下のような点が挙げられています。
- プロジェクトの技術スタックや構成を簡潔に説明する
- テストの実行方法やビルド手順など、検証に必要な情報を含める
- 曖昧な一般論ではなく、具体的なルール・禁止事項を書く
- ファイル全体を長文にしすぎず、要点を絞る
2026年8月時点ではCopilotの利用可能モデルにGPT-5.1やClaude Opus 4.6、Gemini 3 Proなどが加わりコンテキストウィンドウも拡張されていますが、指示ファイル自体は簡潔に保つことが推奨されている点は変わりません。どのモデルを選ぶかという観点では、以前まとめたChatGPT・Claude・Gemini徹底比較も参考になります。
パスごとに指示を出し分ける「.instructions.md」+ applyTo
リポジトリ全体に一律の指示を出すだけでなく、「フロントエンドのコードにはこのルール」「テストコードにはこのルール」といったように、ファイルの種類やディレクトリごとに指示を切り替えたい場合もあります。そのために使うのがapplyToフロントマターを持つ.instructions.mdファイルです。
基本構文
.instructions.mdファイルは.github/instructions/配下(設定で変更可能)に配置し、冒頭のYAMLフロントマターにapplyToでglobパターンを指定します。
---
applyTo: "src/api/**"
---
このディレクトリはAPIサーバーのコードです。
認証周りの処理を変更する際は、必ずセキュリティレビューの観点を含めて提案してください。
Copilotはリクエストのたびに該当する.instructions.mdファイルをすべて集め、開いているファイルに対してapplyToのglobを評価し、一致した指示をまとめてモデルへの入力に反映します。複数のパターンが一致した場合は、それぞれの指示が重ねて適用されます。
活用例
**/*.py:Python全体の共通ルール(型ヒント必須、docstring規約など)src/api/**:APIディレクトリ限定のセキュリティ・認可ルール**/*.test.*:テストコード限定の書き方(モックの使い方、命名規則)
用途に応じて指示を分割しておくと、1つの巨大なファイルにすべて詰め込むよりも管理がしやすくなります。
個人指示・組織指示との優先順位
カスタム指示には、リポジトリ単位だけでなく、個人のユーザープロファイルに紐づく指示や、組織(Organization)単位で設定する指示もあります。これらは階層的に扱われ、リポジトリの指示・パス別の指示・個人の指示などが組み合わさって最終的な文脈がCopilotに渡される仕組みです。チームで運用する場合は、どのレイヤーに何を書くかをあらかじめ決めておくと、指示の重複や矛盾を防げます。
なお、GitHub Copilotには本記事で扱うCopilot Chat/コーディングエージェント以外にも、Copilot Studioなど用途の異なる製品群があります。それぞれの違いについてはGitHub Copilot・Copilot Studio・Microsoft 365 Copilotは何が違う?で整理していますので、あわせてご覧ください。
「指示が反映されない」時のトラブルシューティング
カスタム指示を設定したつもりでも、実際にはCopilotの回答に反映されないというケースがしばしば報告されています。よくある原因は次の通りです。
よくある原因
- 配置場所の間違い:
copilot-instructions.mdはリポジトリルートの.github/直下である必要があります。.instructions.mdも既定では.github/instructions/配下(またはユーザープロファイル)に置く必要があり、設定chat.instructionsFilesLocationsで変更していない場合はこの場所を外すと認識されません。 - .gitignoreによる除外:.github/ディレクトリ自体や.github/instructions/が.gitignoreに含まれていると、Copilotはその中の指示ファイルを読み込みません。意図せず除外設定に含めていないか確認が必要です。
- モノレポ・サブフォルダ構成の問題:1つのリポジトリ内に複数のサブプロジェクト用ワークスペースがある構成では、指示ファイルがリポジトリのルートでしか認識されないケースが報告されています。サブフォルダ単位で運用したい場合は、パス指定の
.instructions.md側で対応する方が確実です。
確認方法
VS CodeのCopilot Chatビューには、読み込まれている指示ファイルの一覧やエラーを確認できる診断(Diagnostics)機能があります。Chatビュー上で右クリックし「Diagnostics」を選択すると、実際にどの指示ファイルが有効になっているかを確認できるため、「書いたつもりが反映されていない」状態の切り分けに役立ちます。まずはこの診断結果を見て、ファイルが認識されているかどうかを確認するのが近道です。
まとめ
GitHub Copilotのカスタム指示は、copilot-instructions.mdによるリポジトリ全体のルール設定と、applyToを使った.instructions.mdによるパス別のルール設定を組み合わせることで、チームのコーディング規約をCopilotに継続的に理解させる仕組みです。反映されない場合の多くは配置場所や.gitignore設定に原因があるため、まずは診断機能で読み込み状況を確認することをおすすめします。エンジニア個人の生産性向上だけでなく、チーム全体でのレビュー品質の底上げにもつながる機能なので、まだ設定していない方はこの機会に試してみてください。
参考サイト
- Adding repository custom instructions for GitHub Copilot – GitHub Docs
- Adding repository custom instructions for GitHub Copilot in your IDE – GitHub Docs
- Use custom instructions in VS Code
- 5 tips for writing better custom instructions for Copilot – The GitHub Blog
- Troubleshoot common issues – GitHub Docs

