copilot-instructions.mdとは？書き方・配置場所とAGENTS.md・.instructions.mdの違いを解説

copilot-instructions.mdは、GitHub Copilotにリポジトリ共通のルール（コーディング規約・使用言語・技術スタックなど）を毎回自動で読ませるためのMarkdownファイルです。リポジトリ全体に効かせたい指示はリポジトリ直下の.githubディレクトリに置くcopilot-instructions.mdに、ファイル種別ごとに分けたい指示は◯◯.instructions.mdとapplyToで使い分けます。この記事では、copilot-instructions.mdの書き方・配置場所・サンプルと、混同しやすいAGENTS.mdや.instructions.mdとの違いまでまとめて整理します。

まとめ：copilot-instructions.mdの要点

• 配置場所：リポジトリ直下の.githubディレクトリにcopilot-instructions.mdを置くと、そのリポジトリでのCopilotの提案すべてに適用される。1リポジトリにつき1ファイル。
• パス別に分けたいとき：.github/instructions/配下に◯◯.instructions.mdを作り、先頭のapplyToで対象ファイルパターンを指定する。
• 書き方：見出しと箇条書きのMarkdownで、規約・技術スタック・よく使うコマンドなどの前提を簡潔に記述する。詰め込みすぎない。
• AGENTS.mdとの関係：CopilotはAGENTS.md（ツール横断の共通指示）も参照し、ディレクトリツリー上で最も近いものが優先される。Copilot固有の指示はcopilot-instructions.mdに書く。
• 対応環境：VS Code・Visual Studio・JetBrains製IDE・Neovim・GitHub.com・GitHub CLIなどでカスタム指示（copilot-instructions.md／.instructions.md）が利用できる。
• 組織単位：2026年4月に組織カスタム指示が一般提供（GA）となり、Copilot Business／Enterpriseの管理者が全リポジトリ共通の既定指示を設定できる。

.instructions.md（copilot-instructions.md）とは何か

「.instructions.md」ファイルは、GitHub Copilotに対して追加の指示やルールを伝えるための設定ファイルです[1]。リポジトリ全体に適用する指示は.github/copilot-instructions.mdという名前でプロジェクトに配置し、特定のディレクトリやファイル種別ごとに適用したい指示は○○.instructions.md（任意の名前＋.instructions.md）として用意します[2]。このファイルにプロジェクト固有の情報や方針を書いておくことで、Copilotはそれを毎回参照しながらコード提案や回答を行ってくれるようになります。

例えば、copilot-instructions.mdに「常に日本語で応答すること」と書いておけば、以降Copilotからの応答は自動的に日本語になります[3]。毎回プロンプトで指示しなくても、あらかじめ決めたルールに沿った応答やコードを得られるのが.instructions.mdの大きな特徴です。また、この仕組みはCopilot ChatやIDEのコード補完など、Copilotの様々な機能で利用されます（対応エディタ：VS Code、JetBrains製品、Neovim他）。事前に指示書を渡しておくイメージで、AIアシスタントにプロジェクトの「頭脳」を共有できる便利な機能です。

GitHub Copilot のカスタム指示（Custom Instructions）の概要

GitHub Copilotのカスタム指示 (Custom Instructions)とは、開発者がCopilotに対してあらゆるやり取りにおける挙動のガイドラインを提供できる機能です[4]。Copilotは本来、ユーザーから与えられたプロンプトや現在のコードコンテキストだけを元に提案を行います。しかしカスタム指示を使うことで、「普段はこういうコードスタイルを採用している」「このプロジェクトではこのフレームワークを使っている」といった前提をAIに教え込むことができます。結果として、よりプロジェクトやユーザーのニーズに沿った回答・コード補完を得やすくなります。

カスタム指示にはスコープの異なる種類があります。一般的なのはリポジトリにファイルを置く方法ですが、それ以外にもユーザー個人や組織単位で指示を設定する仕組みがあります[5]。たとえばGitHub上のCopilot Chatでは、ユーザープロフィールに「Personal instructions」を設定して自分専用の指示を記述できます。一方、今回テーマである.instructions.mdファイルはリポジトリ（もしくはフォルダ）に紐づく指示であり、プロジェクトごとの開発規約やコードベースの情報を共有する用途に適しています。これらのカスタム指示は、エディタでコード補完やチャット回答を生成する際に自動的に参照されます。特にチーム開発や大規模プロジェクトで威力を発揮する機能と言えるでしょう。

.instructions.md / copilot-instructions.md を設定するメリット

では、.instructions.mdによるカスタム指示をプロジェクトで設定すると、具体的にどのようなメリットが得られるでしょうか。主な利点をまとめます。

プロジェクト固有の背景をAIに共有して提案の手戻りを削減できる

プロジェクトの目的や過去の経緯、設計上の意図などをCopilotに理解させることで、AIから的外れな提案が出てしまうのを防げます。例えば歴史的経緯で敢えて特殊な設計になっている部分も、事前に「この設計は○○の理由で採用している」と説明を書いておけば、Copilotがそれを「ベストプラクティスではないから修正しよう」などと勝手に判断することが減ります[6]。毎回チャットで「この部分はこういう理由でこうなっている」と説明し直す手間が省け、結果としてAI提案に対する不要な手直し（手戻り）を減らすことができます。

ファイル構成や規約の情報を組み込み開発効率を向上できる

プロジェクト内のファイル構成やディレクトリ構造、各モジュールの役割などを記述しておけば、Copilotはそれを参照してより的確な提案やコードジャンプを行えるようになります。たとえば「services/ディレクトリにはビジネスロジック、utils/には共通関数がある」と教えておけば、AIは質問に答える際に該当箇所を優先して検討するでしょう。その結果、調査や実装にかかる時間の短縮につながります[7]。またコーディング規約（命名規則やインデントスタイルなど）を指示すれば、提案されるコードが自動的にその規約に沿ったものになり、後から修正する手間が減ります。これらの効果で開発効率の向上が期待できます。

自然言語ドキュメントとして機能し非エンジニアにも情報共有できる

.instructions.mdファイルはMarkdown形式で自由に文章を書けるため、プロジェクトのドキュメントとしても活用できます。実質的にはプロジェクト内のREADMEのようなもので、エンジニア以外のメンバーでも内容を読めばプロジェクトの概要やコーディング規約を理解しやすくなります[8]。Copilotへの指示という役割を果たしつつ、人間にとっても有益な情報源になる点は大きなメリットです。ドキュメントが充実すれば新メンバーの学習コストも下がり、結果的にチーム全体の生産性向上につながるでしょう。

.instructions.md ファイルの基本構成と書き方

.instructions.mdファイルの内容は基本的に自由記述ですが、Markdown形式で箇条書きや文章を並べる形で書くと見やすく管理しやすくなります。Copilotはファイル内の改行や空行を無視して一連の指示として解釈するため、複数行に分けて書いても問題ありません[9]。適宜見出しやリストを使い、人間が読んでも理解しやすいように整理するとよいでしょう。ただしCopilotはMarkdownの書式自体（見出しやリスト記号）は意味を持たずテキストとして扱うので、フォーマットは主に人間のためのものです。

リポジトリ全体に適用されるcopilot-instructions.mdファイルの場合、特に決まった構文はなく、単に先頭から箇条書きや文章で指示を書いていきます。一方、特定のパスにのみ適用する〇〇.instructions.mdファイルでは、ファイル冒頭にapplyToというYAMLフロントマター（---で囲むブロック）を記述し、その中で適用したいパスやファイルパターンを指定します[10]。例えば以下のように書きます。

---
applyTo: '**.py'
---

上記の例では「全ての.py（Python）ファイルに対してこの指示を適用せよ」という指定になります。YAMLブロックの下に続けて実際の指示内容をMarkdownで記述します。なお、パス固有ファイルの場合でもapplyToの指定以外は通常のMarkdownテキストです。複数の.instructions.mdファイルを使い分ける場合、それぞれに役割が分かる名前を付けると良いでしょう（例：database.instructions.md、frontend.instructions.mdなど）。

指示ファイルに盛り込む内容としては、プロジェクトの説明、採用技術やフレームワーク、コードのビルド方法やテスト手順、コーディング規約、禁止事項、使用してはいけない関数やAPI、セキュリティ上の注意点など、多岐にわたります[11]。プロジェクトに関するあらゆる「前提知識」を書き込むつもりで作成すると効果的です。

.instructions.md の導入手順（作成場所と設定方法）

リポジトリに .github/copilot-instructions.md ファイルを手動作成して設定する方法

最も基本的な導入方法は、対象リポジトリ内に直接ファイルを作成する方法です。プロジェクトのルートに.githubディレクトリを作成し、その中にcopilot-instructions.mdというファイル名で指示ファイルを置きます[12]。.githubフォルダが存在しない場合は新規作成してください。そのファイルに前述の形式で指示を書き込み、リポジトリに保存すれば設定完了です。以降、そのリポジトリを開いている開発環境（IDE）でCopilotは自動的にファイル内容を読み込んで提案を行います。

パス固有の指示を設定したい場合は、.github/instructionsディレクトリを作成し、その中に例えばfrontend.instructions.mdやutils.instructions.mdといったファイルを複数置きます。各ファイルの冒頭にapplyToで適用パスを指定しておけば、そのパターンにマッチするファイル上で作業する際にCopilotが該当指示を参照します。

VS Code上の設定UIから .instructions.md ファイルを生成・適用する方法

Visual Studio Codeを利用している場合、Copilot Chatの設定UIから指示ファイルを新規作成することも可能です。VS CodeでCopilot Chatパネルを開き、歯車アイコン（設定）から「指示」を選択すると、新しい命令ファイルを作成するオプションが表示されます[13][14]。そこで「.github/instructions」か「User Data（ユーザーデータ）」かを選ぶと、自動的にファイル名の入力プロンプトが出現し、例えば「dev指南」など任意の名前を入力するとその名前の.instructions.mdファイルが作成されます[15]。

「.github/instructions」を選んだ場合はリポジトリ内にファイルが生成され（ワークスペース固有の指示）、User Dataを選んだ場合はエディタのユーザープロファイルディレクトリ下にファイルが生成されます[14]。後者はグローバル指示（全てのプロジェクトに適用される個人用指示）となります。ファイルが生成されたら、あとは手動作成時と同様にMarkdownで内容を追記し、保存すれば即座にCopilotに適用されます。

なお、グローバル（ユーザーデータ）に配置した指示ファイルはすべてのプロジェクトに適用されてしまう点に注意が必要です[16]。特定のプロジェクトだけに通用する内容は、極力プロジェクト内（.github/instructions）に配置し、グローバルファイルを使う場合でもapplyToで対象を限定することをおすすめします。

applyTo などスコープ指定のやり方と注意点

applyTo フィールドで適用するファイルパターンを指定する方法

applyToは.instructions.mdファイルの先頭に記述するYAMLフロントマター項目で、その指示を適用する対象ファイルのパスや名前パターンを指定します[10]。一般的にはGlobパターン（ワイルドカード）記法でパスを記述します。例えば:

• "/*.tsx" : リポジトリ内のすべての.tsxファイルに適用
• "src/services/" : src/services以下の全ファイルに適用
• "/*.ts,/*.tsx" : 複数パターン（ここでは.tsと.tsx）をカンマ区切りで指定

というように記述します。applyToで指定したパターンにファイルパスがマッチした場合に限り、その.instructions.mdファイルの指示がCopilotに適用されます。逆に言えば、うまくパターンを設定しないと本来意図しない場面で指示が適用されなかったり、逆に広範囲に適用されすぎたりする可能性があります。対象が明確な場合はできるだけ具体的なパスを指定するのがポイントです。

excludeAgentフィールドでCopilotエージェントの種類を限定する方法

excludeAgentはapplyToと並んでYAMLフロントマターに記述できるオプションで、Copilotのどのエージェントに対して指示を適用するかを制御します。現在Copilotには大きく分けて「コーディング支援（補完）エージェント」と「コードレビューエージェント」が存在します。excludeAgent: "code-review"と設定すると、そのファイルの指示はコードレビュー用途のCopilot（Pull Requestの変更要約や指摘を行うAIなど）には無視され、コーディング支援時にのみ適用されます[17]。逆に"coding-agent"を指定すればコード補完には適用されずレビュー時のみに参照されます。特に理由がなければexcludeAgentは指定せず（省略すれば両方に適用）、どちらのエージェントにも指示が届くようにしておくと良いでしょう。

複数ファイルの競合とグローバル適用時の注意（意図しない指示の混入防止）

複数の指示ファイルを併用する際には、その競合に注意する必要があります。Copilotは該当する指示ファイルを全て読み込んで統合した上で応答を生成します。そのため、もし同じ範囲に適用されるcopilot-instructions.md（リポジトリ全体）と〇〇.instructions.md（パス固有）が存在する場合、両方の内容が適用されます[18]。指示同士が矛盾しているとAIがどちらを優先するかは不確定で、思わぬ動作になる可能性があります。指示ファイル間で重複や矛盾がないようにメンテナンスすることが重要です。

また前述の通り、グローバルスコープ（ユーザーデータ）に指示ファイルを置いた場合は全プロジェクト共通で内容が適用されます。その中に特定言語やプロジェクトにしか通用しない指示が含まれていると、別のプロジェクトでも無関係な指示がコンテキストに混入してしまい、トークンの無駄遣いやノイズの原因となります[16]。そうした事態を避けるため、グローバル指示ファイルを運用する際はapplyToで対象を限定したり、不要になった指示は削除・コメントアウトするなどして管理しましょう。一方で、リポジトリ内の指示ファイルでもapplyToを細かく設定しておくことで、曖昧な質問に対しても適切なルールが自動で適用されて余計な指示が混ざりにくくなり、結果としてコンテキストの節約や回答精度の向上につながります[19]。

回答精度を高めるための .instructions.md 記述のコツ

ここでは、実際に指示ファイルを書く際に押さえておきたいポイントやベストプラクティスを紹介します。

簡潔かつ明確な指示を心がけ、必要な情報に絞って記述する

Copilotに伝えたい指示はできるだけ簡潔に、しかし具体的に書きましょう。冗長な表現や曖昧な指示は避け、箇条書きなどでポイントを整理すると効果的です。「可能であれば～したほうが良い」よりも「常に～すること」と断言した方がAIは遵守しやすくなります。また一つの指示ファイルに盛り込む項目はテーマを絞り、関連性の低い内容は分割した別ファイルにする方が望ましいです[20]。指示が短く明瞭であるほどAIは理解しやすく、結果のブレも減ります。

プロジェクト固有の技術スタック・規約・コマンドなどを網羅してAIに前提を伝える

指示ファイルには、そのプロジェクト特有の前提知識をできるだけ網羅して記載しましょう。例えば使用言語やフレームワーク、依存パッケージのバージョン、デプロイ環境なども記述しておくと良いです。加えて、プロジェクトで採用しているコーディング規約（フォーマッターやリンターのルール、命名パターン）、ユニットテストやビルドの実行コマンド、ディレクトリ構成の説明など、開発に必要な情報を余すところなく盛り込みます。AIに「このプロジェクトでは何が標準で、何が重要か」を教えるイメージです。

モデルの制約を考慮して指示の量・詳細を適切に調整する（過度な詰め込みは避ける）

AIモデルには、一度に解釈できるプロンプト（コンテキスト）の容量に限りがあります。あれもこれもと盛り込みすぎると、重要な指示まで含め正確に実行できなくなる可能性があります[21]。特にGPT-4など高度なモデルでも、長すぎる指示リストは一部無視されてしまうことがあるため注意が必要です。指示ファイルの理想的な長さは一概には言えませんが、経験則では数百文字程度に抑えておくのが無難です（重要度の低い指示はREADME等で補足する）。一度作った指示ファイルが冗長だと感じたら、定期的に見直して整理・圧縮しましょう。

Markdownの箇条書きや見出しを使って指示内容を整理し読みやすくする

指示ファイルを人間が編集・閲覧する際の可読性も考慮しましょう。Markdown形式の利点を活かし、箇条書きリストや見出しで項目を分類すると見通しが良くなります。例えば「## コーディング規約」「## プロジェクト構成」という見出しを設け、その下にルールを箇条書きするといった具合です。Copilotはテキストとして処理するだけですが、チームで共同編集する場合などは書式を整えておくことでコミュニケーションコストが下がります。結果的に指示の品質向上（抜け漏れ防止や矛盾発見）にもつながるでしょう。

内容の陳腐化を防ぐため指示ファイルを定期的に見直しメンテナンスする

指示ファイルは一度作って終わりではなく、プロジェクトの変化に応じて更新していく必要があります。新しいライブラリを導入したりアーキテクチャが変更になった場合、その旨を指示に追記しましょう。逆に、既に廃止したルールが指示に残ったままだとAIが誤った提案をする恐れがあります。定期的（例えばスプリント毎）に指示ファイルを読み返し、最新の開発方針に合っているか確認してください。指示ファイルをプロジェクトドキュメントの一部と捉え、メンテナンスのプロセスに組み込むことが大切です。

実例で見る .instructions.md テンプレートとサンプル

基本テンプレートの例: コーディング規約や環境情報を記載した指示ファイル

典型的なリポジトリ用のcopilot-instructions.mdには、以下のような内容を盛り込むとよいでしょう。

• プロジェクト概要: プロダクトの目的や主要機能、想定ユーザーなど
• 技術スタック: 使用言語やフレームワーク、主要ライブラリのバージョン
• ビルド/テスト方法: 開発環境の起動方法、テスト実行コマンド、CIのルール
• コーディング規約: コードフォーマッターやリンターの設定、命名規則、ディレクトリ構成の方針
• 禁止事項: 使用しないでほしい関数・API、避けるべき設計、セキュリティ上の注意点

上記は一例ですが、プロジェクトに合わせて必要な項目を追加・削除してください。ポイントは、そのプロジェクトで開発者が頭に入れている前提知識を余すことなく書き出すことです。これによりCopilotが常にプロジェクトメンバーと同じ「前提」を持ってコード提案や回答をしてくれるようになります。

特定シナリオの例: E2Eテストでのガイドラインを示す指示ファイル

次に、具体的なシナリオに特化した.instructions.mdのサンプルを紹介します。例えばフロントエンドのE2Eテスト（Playwrightなど）に関するガイドラインをAIに伝えるための指示ファイルです。

--- applyTo: "*/tests/.spec.ts"
________________________________________
Playwrightテストのガイドライン
1.	信頼性の高いロケータを使用 - CSSセレクタではなく getByRole や getByText などを優先する
2.	テストは独立させる - 各テストケース間で状態を共有しない
3.	明確な命名 - テスト名やファイル名（*.spec.ts）は内容が分かるようにつける
4.	自動待機を活用 - 手動のsetTimeout()は避け、Playwrightの組み込み待機機能を利用する
5.	適切な前処理/後処理 - 共通の初期化や後片付けは beforeEach/afterEach で行う 

上記のように、テストコードに関するベストプラクティスを項目立てして記述しておけば、Copilotはテストコードを生成する際にこれらのルールに沿った出力を行おうとします。例えば従来であれば「Playwrightでテストを書いて。ロケータはなるべくgetByRoleを使って…」と都度プロンプトする必要があったかもしれませんが、指示ファイルにまとめて情報を渡してあることで一度のプロンプトで期待通りのコード提案が得られやすくなります[22]。このように、特定のタスク向けの詳細なガイドラインは.instructions.mdに記述しておくことで都度のプロンプトを簡潔にし、結果として開発のスピードアップに寄与します。

なお、コミュニティには様々な指示ファイルのテンプレートが共有されています[23]。自分のプロジェクトに近い事例があれば参考にしてみるのも良いでしょう。

他のプロンプトファイル（.prompt.md や AGENTS.md）との違い

.instructions.md以外にも、GitHub Copilotには関連する「プロンプトファイル」や「エージェントファイル」の概念があります。それぞれ目的が異なるため、使い分けについて理解しておきましょう。

.prompt.md ファイル: 特定タスク用の再利用可能なプロンプト定義（必要時に呼び出して使用）

.prompt.mdは、特定のタスク向けにあらかじめ用意したプロンプトを定義しておけるファイルです[24]。ファイル名は○○.prompt.mdとし、.github/promptsフォルダに配置します。例えばCreateAnalyzer.prompt.mdというファイルにコード解析ツールを作成するための手順を書いておけば、VS Code上のCopilot Chatで/CreateAnalyzerコマンドを実行することでそのプロンプトを呼び出せます[25]。つまり、.prompt.mdは「必要なときに呼び出す」専用プロンプトを定義する仕組みです。ある程度決まった手順や定型タスク（コードのリファクタ提案や特定処理の実装など）がある場合に、毎回プロンプトを手入力する代わりにファイル化しておくことで効率化できます。

ただし.prompt.mdはユーザーが明示的に呼び出さない限りCopilotから自動参照されることはありません。また現時点ではVS Codeや一部IDEでプレビュー機能として提供されている段階で、プロンプトファイル自体の管理もユーザー主体となります。したがって常時適用したい規約やプロジェクト前提は.instructions.mdに記述し、.prompt.mdは用途を絞って活用すると良いでしょう。

AGENTS.md ファイル: AIエージェントの役割や振る舞いを定義する設定ファイル（プロジェクトルートに配置）

AGENTS.mdは、AIエージェント（Copilotなど）がプロジェクト内でどのような役割・能力を持つかを定義するための設定ファイルです[26]。プロジェクトのルートディレクトリに配置し、MarkdownもしくはYAML形式で記述します。複数のAIエージェントを使い分ける高度なケースで威力を発揮する仕組みで、GitHub Copilotの場合はカスタムエージェント機能 (.agent.md)として一部提供されています[27]。

.agent.md（AGENTS.md）は、Copilotに対して「あなたは○○の専門家AIです」といった人格や振る舞いに関する指示を与える用途のファイルです[27]。例えば応答を常に敬体（ですます調）にする、Linuxのターミナル操作ではrmコマンド禁止といったルールを記述しておけば、以降そのエージェントとの対話全体にそれが適用されます[28]。これはCopilotを単なる補助ツールから、より人間に近い「エージェント」として振る舞わせるための機能です。

まとめると、.instructions.md（およびcopilot-instructions.md）は常時適用したい開発ルールやコンテキストの共有、.prompt.mdは必要時に呼び出す個別の指示、そしてAGENTS.md/.agent.mdはAIエージェント自体のキャラクターや制約の設定に使われます。それぞれ目的が異なるものの補完関係にあり、実際のプロジェクトでは「全体のガイドラインは.instructions.mdで設定しつつ、特定機能で.prompt.mdを用意し、さらにエージェントの人格は.agent.mdで調整する」といった組み合わせも可能です[29]。

チーム開発・オンボーディングでの .instructions.md 活用方法

最後に、チーム開発や新人オンボーディングの場面で.instructions.mdを活用する方法について考えてみます。

チーム全員で統一したコーディング標準・開発方針を共有し遵守を促せる

プロジェクトのコーディング標準やベストプラクティスを.instructions.mdに明文化しておくことで、Copilot経由で自動的にそれらがコードに反映されます。チームメンバー全員が指示ファイルを介して共通の規約を参照する状態になり、暗黙知だったルールも共有知にできます。結果として、誰がコードを書いても一定のスタイル・品質が保たれ、コードレビュー時にスタイルの指摘ばかりになる事態を減らせます。特に大規模チームでは、この仕組みにより規約遵守の徹底と平準化が図れます。

指示ファイルを活用して新メンバーのオンボーディングを効率化（知識の共有）

新しくチームに加わったエンジニアにとって、そのプロジェクト特有のコーディング規約や設計方針を一から覚えるのは大変です。しかし.instructions.mdに重要事項がまとまっていれば、Copilotが提案するコードや説明自体がお手本となります。新人開発者はCopilotの振る舞いを通じて「このプロジェクトではこう書くのか」と学ぶことができますし、指示ファイルそのものを読めば要点を把握できます。いわば生きたドキュメントとしてオンボーディング資料の役割も果たすわけです。これにより、新メンバーが戦力になるまでの時間を短縮できるでしょう。

開発フロー上の注意点を指示ファイルで事前提示しコードレビューの手戻りを減らす

開発プロセスにおける注意事項（例えば「プルリクエスト前に必ずnpm testを実行する」「秘密情報はコミットしない」等）も指示ファイルに書いておけば、Copilotが適宜それをリマインドしてくれる可能性があります。実際にCopilot Chatに「この変更をコミットしても良いか？」と尋ねた際、指示ファイルに基づいて「テストは通っていますか？」「APIキーが含まれていないか確認してください」と助言してくれる、といったケースです。たとえAIからの間接的な形でも開発フロー上のチェックポイントが提示されれば、レビュアーが指摘するまでもなく開発者自身が対応できるでしょう。その結果、コードレビュー後の修正サイクル（手戻り）が減り、スムーズに開発が進行します。

このように.instructions.mdは、単なるAIへの指示書に留まらず、チームの知識共有ツールや開発プロセス改善ツールとしても機能します。ぜひプロジェクトに導入し、継続的に活用・改善しながらチーム開発のクオリティ向上に役立ててみてください。

copilot-instructions.mdに関するよくある質問

copilot-instructions.md はどこに置けばよいですか？

リポジトリ直下の.github/copilot-instructions.mdに配置します。このパスに置くと、そのリポジトリで行うCopilotへのリクエスト全体に指示が適用されます。1リポジトリにつき1ファイルで、複数に分けたい場合は後述の.instructions.mdを使います。

copilot-instructions.md の書き方は？

特別な記法はなく、通常のMarkdownの自然言語で書きます。「回答は日本語で行う」「パッケージ管理はpnpmを使う」のように、コーディング規約・技術スタック・よく使うコマンドといった前提を箇条書きで簡潔にまとめるのがコツです。長文で詰め込むと精度が下がるため、必要な情報に絞ります。

.instructions.md と copilot-instructions.md の違いは？

.github/copilot-instructions.mdはリポジトリ全体に一律で適用される指示です。一方◯◯.instructions.mdは.github/instructions/配下に置き、ファイル先頭のapplyToで「どのパス・拡張子に適用するか」を指定するパス別の指示です。全体共通はcopilot-instructions.md、言語やフォルダごとに変えたい部分は.instructions.mdと使い分けます。

AGENTS.md と copilot-instructions.md はどちらを使うべきですか？

CopilotはAGENTS.mdにも対応しており、リポジトリ内の任意の場所に複数置けます（最も近い階層のものが優先）。ツールをまたいで共通の指示を1か所にまとめたい場合はAGENTS.md、Copilotに固有の細かい指示を書きたい場合はcopilot-instructions.mdが向きます。両方置いた場合はどちらも読み込まれます。

copilot-instructions.md のサンプルはどこで入手できますか？

GitHubが運営するgithub/awesome-copilotリポジトリ（コミュニティ提供の指示・プロンプト集）に、言語・フレームワーク別の指示ファイルやテンプレートが多数公開されています。まずは次のような最小構成から始め、運用しながら追記していくとよいでしょう。

# プロジェクト共通のCopilot指示
- 回答は日本語で行う
- パッケージ管理は pnpm を使う
- コンポーネントは src/components/ 配下に配置する
- コミット前に npm test を必ず実行する

関連記事

• GitHub Copilotエージェントモードの使い方｜Ask・Edit・Agentの違いと有効化・料金【2026年版】
• .cursorrulesとは？非推奨の旧形式と新Project Rules（.cursor/rules）の違い・書き方
• Claude Code Auto Memoryとは？MEMORY.mdの仕組みと有効化・無効化の設定方法
• Codex CLIとは？インストール・使い方・プロキシ設定・主要コマンドを解説