copilot-instructions.mdはどこに何という名前で置くのか
.github/copilot-instructions.mdが読み込まれる仕組み
室谷代表取締役まず置き場所から固めましょう。リポジトリ全体に効かせたい指示は、リポジトリのルートにある .github ディレクトリの中に copilot-instructions.md という名前で置く。
GitHub 上の Copilot はこれをリポジトリ全体向けのカスタム指示として読み込む、というのが基本なんですよね。
GitHub 上の Copilot はこれをリポジトリ全体向けのカスタム指示として読み込む、というのが基本なんですよね。
テキトー教師DotAI 認定講師たしかに、ここが最初の分岐点ですね。初めて触る人は「リポジトリのどこに置いても拾ってくれるんだろう」と思いがちなんですけど、全体向けはこの1パスに決まってます。
室谷代表取締役中身は Markdown で自然言語の指示を書く。設定ファイルじゃなくて、人に読ませるのと同じノリの文章でいいんですよ。
テキトー教師DotAI 認定講師あ、でもターミナルで動かす Copilot CLI だと、同じファイル名でホームディレクトリ側にも置けるんですよね。全リポジトリ共通の指示にしたいとき用です。
CLI 側の話はGitHub Copilot CLIの使い方で解説してます。
CLI 側の話はGitHub Copilot CLIの使い方で解説してます。
ファイル名と置き場所を間違えると効かない理由
室谷代表取締役で、地味に詰まるのが .github のドット忘れとファイル名の綴りですね。公式に「この名前で作成する」と明記されているので、綴りは合わせるのが前提です。
テキトー教師DotAI 認定講師現場でよく聞くのは、リポジトリのルート直下にそのまま置いちゃったパターンですね。ルートの .github の中、という階層がポイントなんですよ。
室谷代表取締役あと、パスごとにルールを変える .instructions.md と混同するケース。あれは .github/instructions/ の下に別の名前で置く別系統なので、全体向けとは住み分けが要ります。
ツールごとに指示ファイルの流儀が違うのが、正直いちばん運用コストを食うところで。
ツールごとに指示ファイルの流儀が違うのが、正直いちばん運用コストを食うところで。
テキトー教師DotAI 認定講師そうなんですよね。1個のファイルに全部詰め込もうとして、どこに何を書いたか分からなくなる。
置き場所を分けること自体が整理になってるんですよ。
置き場所を分けること自体が整理になってるんですよ。
Markdownの書式はどこまで自由でいいのか
室谷代表取締役書式の自由度も気になるところで。指示と指示の間の空白は無視されるので、1段落でずらーっと書いても、改行や空行で区切ってもいいんですよね。
テキトー教師DotAI 認定講師ここは気楽でいいんですよ。箇条書きにするか文章にするかも好みで決められる。
大事なのは体裁より、何を守ってほしいかが伝わることですね。
大事なのは体裁より、何を守ってほしいかが伝わることですね。
室谷代表取締役あと、指示ファイルの中から @相対パス で別ファイルを読み込ませることもできます。共通の規約を1か所にまとめておいて、本体から参照する形にすると管理がラクなんですよ。
テキトー教師DotAI 認定講師それは知らないと損ですね。参照先はリポジトリ内かユーザー指示ディレクトリ内に限られるので、外の共有ドライブを指すような置き方はできないんですけど。
copilot-instructions.mdに何を書く？公式が挙げる5つの柱
プロジェクト概要と技術スタックは最初の数行で書く
copilot-instructions.md 公式が挙げる5つの柱
プロジェクト概要
何を作っているアプリかを数文で書く
技術スタック
バックエンド・フロントエンド・テストごとに箇条書き
コーディング規約
セミコロン・型ヒント・タブ/スペースなど。ファイル種別ごとに違うなら別ファイルに分ける
プロジェクト構成
ディレクトリと役割を一言ずつ(「ここはUI部品」「ここは純粋関数を置く」程度)
利用可能なリソース
セットアップ用スクリプト、テストコマンド、使えるMCPサーバーの一覧
室谷代表取締役公式ブログが挙げてる5つの柱、見てみるとかなりシンプルなんですよ。1つ目がプロジェクト概要、2つ目が技術スタック。
何を作っているアプリかを数文で、使うフレームワークはバックエンド・フロントエンド・テストごとに箇条書きで、という整理ですね。
何を作っているアプリかを数文で、使うフレームワークはバックエンド・フロントエンド・テストごとに箇条書きで、という整理ですね。
テキトー教師DotAI 認定講師ここが空欄のままの人が多いんですよね。ファイルは作ったのに中身が「丁寧に書いてください」だけ、みたいな。
初めて触る人が最初に戸惑うのはまさにそこです。
初めて触る人が最初に戸惑うのはまさにそこです。
室谷代表取締役概要がないと、Copilotは目の前のコードしか見ないんですよ。文脈を渡すコストって想像よりずっと安くて、リターンはでかい。
最初の数行を埋めるかどうかだけの話なんですよね。
最初の数行を埋めるかどうかだけの話なんですよね。
コーディング規約とディレクトリ構成の書き方
テキトー教師DotAI 認定講師3つ目がコーディング規約です。セミコロンを付けるか、型ヒントを書くか、タブかスペースか。
ファイル種別ごとに規約が違うなら、それは別ファイルに分けるのが公式のすすめ方ですね。
ファイル種別ごとに規約が違うなら、それは別ファイルに分けるのが公式のすすめ方ですね。
室谷代表取締役これ、現場だとレビュー工数の話になるんですよ。規約を書いておかないと同じ指摘が何度も往復する。
時給で換算すると、書く手間なんて一瞬で回収できる計算なんですよね。
時給で換算すると、書く手間なんて一瞬で回収できる計算なんですよね。
テキトー教師DotAI 認定講師4つ目のプロジェクト構成は、ディレクトリと役割を一言ずつで十分。「ここはUI部品」「ここは純粋関数を置く」ぐらいの粒度でちゃんと伝わります。
セットアップ・テスト用スクリプトやMCPサーバーの一覧
室谷代表取締役5つ目が利用可能なリソース。セットアップ用のスクリプト、テストコマンド、使えるMCPサーバーの一覧ですね。
ここは後回しにされがちなんですけど。
ここは後回しにされがちなんですけど。
テキトー教師DotAI 認定講師一番見落とされるのに、実は効くところで。テストの叩き方が書いてあると、エージェント側が自分で回して直す前提で動けるんですよ。
室谷代表取締役逆に書いてないと、存在しないコマンドを叩きにいく。実行環境の地図を渡すかどうか、それだけの差なんだと思います。
やりがちな悪い例｜曖昧な指示と重複だらけの指示
テキトー教師DotAI 認定講師よくある失敗は2つで、「いい感じに書いて」みたいな曖昧な指示と、同じルールを何箇所にも重複して書くこと。重複すると片方だけ直して食い違うんですよね。
室谷代表取締役指示ファイルって、書いた瞬間に完成した気になるんですけど、コードベースと同じで放っておくと腐るんですよ。ドキュメントと同じ扱いにした方が現実的だと思います。
テキトー教師DotAI 認定講師「まず規約から埋めよう」と力むより、概要と構成を先に置いて、規約は後から足す。その順番の方が詰まらないんです。
完璧を目指さず更新し続ける前提で運用する
テキトー教師DotAI 認定講師公式も「完璧である必要はない、何も書かないより不完全な指示の方が効果が大きい」と明言してます。まず10行書いてみる、でいいんですよ。
室谷代表取締役その10行があるチームとないチーム、半年後の差はかなり開くと思ってて。書き始めのコストが低いわりにリターンが大きすぎるんですよね。
テキトー教師DotAI 認定講師書いたら終わりではなく、ドキュメントと同じで継続更新。そこだけ意識しておけば大崩れしません。
ファイルごとにルールを変える.instructions.mdとapplyToの書き方
.github/instructions/NAME.instructions.mdの作り方
.instructions.md の作り方
- 01.github の下に instructions ディレクトリを作るサブディレクトリで整理してもよい
- 02NAME.instructions.md を作るNAME は対象が分かる名前にする（例: models.instructions.md）
- 03先頭の frontmatter に applyTo を書く行き先のパターンを指定。飛ばすとどのファイルに効くか決まらない
- 04本文にその範囲だけに効かせたい規約を書く
- リポジトリの
.githubの下にinstructionsディレクトリを作る（サブディレクトリで整理してもよい） - その中に
NAME.instructions.mdという名前でファイルを作る - ファイル先頭に frontmatter を置き、
applyToに行き先のパターンを書く - 本文にその範囲だけに効かせたい規約を書く
室谷代表取締役リポジトリ全体の指示が膨らんできたとき、言語ごと・ディレクトリごとに分けたくなるんですよね。そこで出てくるのが、ファイル単位で置くタイプの指示です。
テキトー教師DotAI 認定講師はい、最初に戸惑うのが置き場所で。
NAME の部分は自分で決めていいんですよ。
.github の直下に instructions フォルダを作って、その中に NAME.instructions.md で置きます。NAME の部分は自分で決めていいんですよ。
室谷代表取締役末尾が
地味に効くのはそこなんですよね。
.instructions.md ってところが肝で。models.instructions.md みたいに対象が分かる名前にしておくと、後から見た人が迷わない。地味に効くのはそこなんですよね。
テキトー教師DotAI 認定講師そうなんです。で、先頭の frontmatter に
ここを飛ばしたまま本文だけ書いちゃう人がいて、それだと「どのファイルに効かせる指示なのか」が決まらないまま終わってしまいます。
applyTo を書く。ここを飛ばしたまま本文だけ書いちゃう人がいて、それだと「どのファイルに効かせる指示なのか」が決まらないまま終わってしまいます。
applyToに書くglobパターンの具体例
| パターン | 一致する範囲 |
|---|---|
* | カレント直下の全部 |
** または **/* | 全階層 |
src/*.py | src の直下の .py のみ |
src/**/*.py | src 以下のすべての .py |
**/subdir/**/*.py | どの深さの subdir 配下でも一致 |
テキトー教師DotAI 認定講師globの書き方、ここが一番引っかかりやすいところです。
この2つを同じだと思って書く人がすごく多いんですよ。
* はカレント直下だけで、** や **/* は全階層。この2つを同じだと思って書く人がすごく多いんですよ。
室谷代表取締役src/*.py と src/**/*.py の違いも、最初は「同じじゃないの」ってなるんですよね。現場でよく聞くのはそこです。テキトー教師DotAI 認定講師前者はsrc直下の .py だけ、後者はsrcの下なら何階層でも、です。応用で
**/subdir/**/*.py と書けば、どの深さにある subdir の下でも拾えます。室谷代表取締役複数のパターンを当てたいときはカンマ区切りで
**/*.ts,**/*.tsx って並べる。1行で済むので、規約ファイルが無駄に増えないのがいいところですね。excludeAgentでcode reviewとcloud agentを切り分ける
室谷代表取締役そこで
excludeAgent ですよ。これを知らないと「なんで片方にしか効いてないんだ」ってなるやつです。テキトー教師DotAI 認定講師excludeAgent: "code-review" と書くとcode review側には使わせない、"cloud-agent" ならcloud agent側に使わせない。省略すると両方が使う、という挙動になります。室谷代表取締役つまり、レビューでだけ見てほしい観点と、実装時にだけ守ってほしい規約を、同じディレクトリで分けられるわけです。
テキトー教師DotAI 認定講師ただし注意点があって、いまGitHub.com上でパス別の指示が効くのはcloud agentとcode reviewの2つだけなんです。エディタ側の補完でも同じように効くと思っていると、そこからズレが出ます。
Copilot code reviewで個人のカスタム指示をOFFにする設定
- GitHub で対象のリポジトリ、または組織の設定を開く
- Copilot の code review に関する設定項目を探す
- 個人のカスタム指示を使うかどうかの切り替えを操作する（デフォルトはON）
テキトー教師DotAI 認定講師code review側で、個人が書いたカスタム指示を使うかどうかは設定で切り替えられます。初期値がONなので、チームで基準を揃えたいときは一度見にいった方がいいですね。
室谷代表取締役リポジトリのルールと個人の指示が混ざると、レビュー指摘の基準が人によって変わる。レビュー品質のばらつきって、後から直すのが一番面倒なんですよ。
テキトー教師DotAI 認定講師なので、まず個人の指示がONのままかを確認して、リポジトリ側に寄せたいならOFFにする、という順番が分かりやすいです。画面の細かい場所は公式ヘルプで確認してもらうとして。
室谷代表取締役要は「誰の指示をレビューに効かせるか」を決める話なんですよね。ファイルを分けるのと同じで、効かせる範囲を意識して設計するかどうか、なんです。
AGENTS.mdとcopilot-instructions.mdはどう使い分ける？両方に書いていい？
AGENTS.mdは何のために生まれたフォーマットなのか
室谷代表取締役AGENTS.md、Copilot専用のファイルだと思ってる人が多いんですけど、実はオープンな仕様なんですよね。Linux Foundation傘下の団体が管理していて、60,000以上のOSSプロジェクトが採用してると。
テキトー教師DotAI 認定講師初めて触る人が戸惑うのがまさにそこなんですよ。「Copilotの設定ファイル」という認識で入ると、なんでCursorの話に出てくるんだ？となるので。
室谷代表取締役仕様としての色が強いので、Copilot coding agent以外にもCodexやCursor、Gemini CLI、Aider、Windsurfなんかが対応してる。ツールを乗り換えても残る資産になるんですよね。
テキトー教師DotAI 認定講師なるほど。Copilot向けの設定というより、リポジトリ側の共通ルール置き場という扱いなんですね。
ツール間の違いはCursorとGitHub Copilot、どっちを選ぶ？違いや併用・設定を徹底比較でも整理されてます。
ツール間の違いはCursorとGitHub Copilot、どっちを選ぶ？違いや併用・設定を徹底比較でも整理されてます。
READMEに書く情報とAGENTS.mdに置く情報の線引き
テキトー教師DotAI 認定講師READMEと何が違うのか、が現場で一番聞かれるところで。READMEは人間が読む前提、AGENTS.mdはエージェントが読む前提なんですよね。
室谷代表取締役ビルドやテストの手順、コーディング規約みたいに、人間には「まあ分かるでしょ」で済むけどREADMEに書くと冗長になる情報を置く場所、という設計になってます。必須フィールドはなくて、Markdownで自由に書けます。
テキトー教師DotAI 認定講師逆に、プロジェクト概要を延々書く必要はないと。テストコマンドを書いておくとエージェントが実際に実行して、失敗したら直しにいくので効きます。
同じ内容を両方のファイルに書いてよいのか
室谷代表取締役両方に書くのはアリだと思いますけど、二重管理になるので範囲は決めたほうがいい。copilot-instructions.mdはリポジトリ全体向け、AGENTS.mdはツール横断の共通ルール、という住み分けですね。
テキトー教師DotAI 認定講師ここは注意が必要で、Copilot CLIの公式を見ると、複数の指示ファイルがあると内容を結合して使うけれど、ファイル間の一般的な優先順位は定義されていない、と書かれてるんですよ。同じ話を両方に書いて食い違うと、どちらが効くか保証がない。
室谷代表取締役じゃあ共通部分はAGENTS.mdに一本化して、Copilot固有の話だけcopilot-instructions.mdに足す。これがたぶん一番事故が少ない形です。
テキトー教師DotAI 認定講師現場感覚でもそこに落ち着く人が多いですね。重複を作らない、が合言葉でいいと思います。
モノレポでは各パッケージ内にネストして置く
室谷代表取締役モノレポのときはどうするんですか。
テキトー教師DotAI 認定講師AGENTS.mdは各パッケージ内にネストして置けるんですよ。複数置けて、エージェントは編集対象のファイルに最も近い階層のものを優先する。
指示が競合したら「最も近いAGENTS.mdが勝ち」で、チャットでの明示的な指示はそこより優先される、という仕様です。
指示が競合したら「最も近いAGENTS.mdが勝ち」で、チャットでの明示的な指示はそこより優先される、という仕様です。
室谷代表取締役ルートに全部書くと、フロントとバックエンドで規約が違うときに破綻するんですよね。OpenAIのリポジトリが88個置いているというのも、規模が大きくなれば自然にそうなるという話で。
ルートに共通、パッケージに固有、と分けるのが素直です。
ルートに共通、パッケージに固有、と分けるのが素直です。
テキトー教師DotAI 認定講師管理コストは増えますけど、1ファイルが膨らんで誰も読まなくなるよりは健全ですね。
優先順位はどうなっている？公式が決めていること・決めていないこと
決まっているルール｜編集対象に最も近いAGENTS.mdが優先される
室谷代表取締役AGENTS.mdの階層ルールは公式に明記されてます。Copilotは編集対象のファイルに最も近い階層のAGENTS.mdを優先して使う、と。
モノレポで各パッケージに置ける前提の設計なんですよね。
モノレポで各パッケージに置ける前提の設計なんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、そこが最初のつまずきで。ルートに1個置けば全ファイルに効くと思われがちなんですけど、実際はネストできるんですよ。
室谷代表取締役agents.md側の仕様を読むと、チャットでの明示的な指示はさらに優先される、とも書かれてる。つまりAGENTS.mdは無条件の最上位じゃないんですよ。
テキトー教師DotAI 認定講師たしかに。ファイルに書いたから絶対効く、ではないわけですね。
決まっていないルール｜copilot-instructions.mdとAGENTS.mdの優劣
公式が決めていること・決めていないこと
決まっているルール
- 編集対象のファイルに最も近い階層のAGENTS.mdが優先される
- モノレポで各パッケージに置ける前提の設計
- チャットでの明示的な指示はさらに優先される
- AGENTS.mdは無条件の最上位ではない
決まっていないルール
- copilot-instructions.mdとAGENTS.mdの優劣は公式に未定義
- 複数の指示ファイルは内容を結合して使う
- 指示ファイル間の一般的な優先順位は定義されない
- 公式の推奨は優劣を決めることではなく競合しないように書くこと
室谷代表取締役じゃあリポジトリ全体向けの指示ファイルとAGENTS.mdがぶつかったら、どっちが強いのか。これ、公式には決まってないんですよ。
テキトー教師DotAI 認定講師ここをはっきりさせたい人は多いですね。Copilot CLIの公式ドキュメントには、複数の指示ファイルは内容を結合して使うけれど、それらの間の一般的な優先順位は定義されない、と書かれてます。
室谷代表取締役で、公式が推奨してるのは「指示同士が競合しないように書く」という方針。優劣を決める話じゃなくて、ぶつけるなという話なんですよね。
テキトー教師DotAI 認定講師競合を避けるために書く側ができること
室谷代表取締役実務だと、同じルールを両方に書かない、がまず基本ですか。
テキトー教師DotAI 認定講師そうですね。リポジトリ全体の規約は片方に寄せて、もう片方からは参照させる形にすると衝突しにくいです。
copilot-instructions.mdやAGENTS.mdの中では@相対パスで他ファイルを読み込ませることもできます。
copilot-instructions.mdやAGENTS.mdの中では@相対パスで他ファイルを読み込ませることもできます。
室谷代表取締役それ、経営目線で言うと二重管理はだいたい腐るんですよ。片方だけ更新されて食い違う。
人が増えるほど効いてくる話で。
人が増えるほど効いてくる話で。
テキトー教師DotAI 認定講師現場でも「どっちが正しいんだっけ」が起きますからね。参照先を1本にしておくのが結局ラクです。
「優先される」と断定する記事を鵜呑みにしない
室谷代表取締役ネット上だと、こっちのファイルが優先される、と断定してる記事もあるんですけど。
テキトー教師DotAI 認定講師独自に試してそう見えた、という話で、公式がそう定義しているわけではないんですよね。環境によって挙動が変わる可能性は残ります。
室谷代表取締役うちでも「検証したらこうだった」は社内ルールにはするけど、外部に一般則として出さないようにしてて。再現条件が消えると後で事故るんですよ。
テキトー教師DotAI 認定講師公式ドキュメントを一度確認してから判断するのが安全ですね。
copilot-instructions.mdをCopilot自身に自動生成させる手順
github.com/copilot/agentsを開いてリポジトリを選ぶ
- ブラウザで
github.com/copilot/agentsを開く（任意のページの検索バー横のボタンから、サイドバーの「Agents」経由でも到達できます） - 対象のリポジトリを選ぶ
室谷代表取締役白紙から指示ファイルを書くの、正直しんどいんですよね。で、Copilot自身に下書きを作らせる入口がこの画面なんですよ。
テキトー教師DotAI 認定講師最初に戸惑うのが、どこから始めればいいのか分からない、という点なんですよ。「指示ファイルを書く画面」ではなく「エージェントに頼む画面」から入る、という発想の転換が要ります。
室谷代表取締役ここ、リポジトリを選ぶだけで対象が決まるので、複数リポジトリを持ってるチームだと「どのリポジトリから整備するか」の判断だけは人間がやることになります。
テキトー教師DotAI 認定講師たしかに。まず一番触られているリポジトリで試す、というのが現場では多そうですね。
公式テンプレのプロンプトを貼って実行する
- プロンプト欄に公式のテンプレを貼り付ける
- そのまま実行する
テンプレの趣旨は「このリポジトリをCopilot cloud agentに'オンボーディング'させるため、.github/copilot-instructions.md を追加してください。ビルド・テスト・検証の手順、プロジェクト構成、既知の落とし穴を網羅し、2ページ以内に収めてください」というものです。
室谷代表取締役ゼロから書くと、網羅しようとして逆に長くなるんですよね。2ページ以内という制約があるだけで、書く側の迷いが消えます。
テキトー教師DotAI 認定講師現場感覚で言うと、初めて触る人は「何を書くか」より「どこまで書くか」で止まるんですよ。上限が決まっているのは助かります。
室谷代表取締役それと、初めてそのリポジトリで cloud agent がPRを作るとき、この生成用のリンクをコメントで案内してくれるんですよ。気づかないうちに導線が張られている。
テキトー教師DotAI 認定講師なるほど、そこで存在を知るパターンも多いわけですね。
生成されたドラフトPRをレビューして仕上げる
室谷代表取締役実行すると、Copilotがドラフトのプルリクを作って、作成者にレビュー依頼が飛ぶ流れです。ここは人間の仕事が残る。
テキトー教師DotAI 認定講師ここが大事で、生成物をそのままマージすると実態とズレた指示が残るんですよ。ビルドやテストの手順は特に、本当に動くか確かめないと意味がないですから。
室谷代表取締役下書きがあるだけで初速が全然違うんですよね。MYUUUの現場でも、ゼロから書く時間より直す時間のほうが短いのは明らかで。
テキトー教師DotAI 認定講師たしかに。書かれたものを削るほうが圧倒的にラクですからね。
まずはドラフトを材料に、リポジトリの実態と突き合わせていくのが現実的だと思います。
まずはドラフトを材料に、リポジトリの実態と突き合わせていくのが現実的だと思います。
書いた指示が効かないときに確認すること
言い切り型で書く｜条件付き・禁止形より遵守されやすい
室谷代表取締役指示ファイルって、書けば効くと思われてるんですけど、実際は言い方で通りやすさが変わるんですよね。書き方を比べた研究でも、言い切り型のほうが条件付きや禁止形より遵守されやすいと言われてます。
テキトー教師DotAI 認定講師そこ、現場でよく聞くんですよ。「〜の場合は〜してください」って条件を足したほうが親切な気がするじゃないですか。
でも読む側からすると条件が増えるほど判断がぶれるんですよね。
でも読む側からすると条件が増えるほど判断がぶれるんですよね。
室谷代表取締役あと「〜しないでください」の禁止形。禁止って裏返しの指示だから、代わりに何をすればいいかが抜けやすいんですよ。
テキトー教師DotAI 認定講師なので「テストはVitestで書く」みたいに言い切る。禁止したいときは「anyは使わず、型を明示する」のように肯定形へ置き換えると、動きが安定します。
Copilot CLIが読む指示ファイルの一覧と、読み込み確認
指示が効かないときの確認手順
- 01セッションを終了して再開copilot --continue で再開、または /new で新しく始める
- 02/instructions で読み込み状況を確認検出された指示ファイルの一覧を確認し、個別に有効・無効を切り替える
- 03書き方を見直す条件付き・禁止形ではなく言い切り型にする。禁止は肯定形へ置き換える
- 04参照方法を確認@相対パスは .github/copilot-instructions.md・AGENTS.md・CLAUDE.md 内のみ有効。~/ の絶対パスは不可
室谷代表取締役CLIの場合、見に行くファイルが一箇所じゃないんですよ。リポジトリの
.github/copilot-instructions.md、AGENTS.md、CLAUDE.md、GEMINI.md、.github/instructions/ 配下のパス別ファイル、さらにユーザーレベルの $HOME/.copilot/copilot-instructions.md あたりまで対象になります。テキトー教師DotAI 認定講師で、複数あると内容を結合して使うけど、ファイル間の一般的な優先順位は公式には定義されてない。同じことを二箇所に違う書き方で置くと、ぶつかったときにどっちが効くか分からないんですよね。
室谷代表取締役それを確認するのが
/instructions です。セッションで検出された指示ファイルの一覧が出て、個別に有効・無効を切り替えられる。テキトー教師DotAI 認定講師読み込まれてるか怪しいときは、まずここを見るのが一番早いですね。ツール側がファイル形式を揃えにいってる途中なので、決め打ちで考えるより毎回確認したほうが確実です。
@相対パスで取り込める範囲と、反映されないときの落とし穴
室谷代表取締役@相対パス で別ファイルを引っ張れるのはあまり知られてないんですよね。ただし使えるのは .github/copilot-instructions.md、AGENTS.md、CLAUDE.md の中だけ。GEMINI.md や *.instructions.md の中では展開されません。テキトー教師DotAI 認定講師参照先もリポジトリ内かユーザー指示ディレクトリ内に限られて、
~/ から始まる絶対パスは読み込まれない。ここ、ハマる人多いんですよ。室谷代表取締役あともう一個、運用で一番刺さるのが反映タイミング。実行中のCLIセッションには、指示ファイルへの変更が即時反映されないんですよ。
テキトー教師DotAI 認定講師なので、書き換えたのに効いてないなと思ったら、セッションを終了して
CLI自体の設定はGitHub Copilot CLIの使い方にまとめてあるので、あわせて確認しておくと迷わないです。
copilot --continue で再開するか、/new で新しく始める。それでも挙動が変わらなければ /instructions で読み込み状況を見る、という順番ですね。CLI自体の設定はGitHub Copilot CLIの使い方にまとめてあるので、あわせて確認しておくと迷わないです。
よくある質問
Q1. 他社ツールのルールファイルから移行するとき、そのままコピーしていい？
室谷代表取締役他のエディタ用に書いたルールを、そのままコピーして持ってくる人いるんですけど、置き場所もファイル名も違うので、そこは合わせ直しなんですよね。中身の意図は流用できますけど・・・
テキトー教師DotAI 認定講師そうですね。現場でよく聞くのは「書いてある内容は悪くないのに、そもそも読まれてない」パターンです。
パスが違うと、存在しないのと同じなんですよ。
パスが違うと、存在しないのと同じなんですよ。
室谷代表取締役まず1個だけ動かして、効いたのを確認してから残りを移す。これが一番ケガしない順番なんですよ。
Q2. チーム開発で、指示ファイルは誰がメンテする？
テキトー教師DotAI 認定講師チームで使う場合、指示ファイルって地味に揉めるんですよ。「自分のところでは効くのに」みたいな話になりがちで。
室谷代表取締役だからコードと同じ扱いにするのが素直なんですよね。PRに含めて、差分で議論する。
属人化すると、誰も更新しなくなるんですよ・・・
属人化すると、誰も更新しなくなるんですよ・・・
テキトー教師DotAI 認定講師初めて触る人は、書くことより「消す基準」を決めるほうが難しかったりします。増える一方になりがちなので。
室谷代表取締役定例で棚卸し、くらいでちょうどいいんですよ。放置された設定ファイルは、だいたい嘘をつき始めますから。
Q3. 指示をたくさん書くと、コンテキストを圧迫したりしない？
室谷代表取締役指示ファイル、長ければ強いと思われがちなんですけど、毎回読まれる前提だと分量そのものがコストなんですよね。
テキトー教師DotAI 認定講師たしかに。現場感覚で言うと、30行くらいで足りてるケースが多いです。
あれもこれもと足すと、肝心のルールが埋もれます。
あれもこれもと足すと、肝心のルールが埋もれます。
室谷代表取締役読む側の注意力も有限なので。短く強い一行のほうが、結果的に効くんですよ。
テキトー教師DotAI 認定講師足すときは、ひとつ消す。くらいでちょうどいいかもしれませんね。
Q4. コード補完の精度も上がるの？
テキトー教師DotAI 認定講師「これ、チャットのときだけの話ですか？」と聞かれることがあります。補完の候補まで同じように変わるとは限らないので、そこは期待しすぎないほうが。
室谷代表取締役効いてるかどうかは、結局は実際に書いてみて判断するしかないんですよね。体感で「言うこと聞くなった」と思えれば儲けもの、くらいで。
テキトー教師DotAI 認定講師そうですね。あと補完は速さが命なので、指示を盛りすぎると重くなる可能性もあります。
まずは短く、ですね。
まずは短く、ですね。
Q5. モノレポや複数リポジトリで同じルールを使い回したいときは？
室谷代表取締役ルートに一つ置くか、パッケージごとに分けるか。ここは好みが分かれるところなんですよね。
テキトー教師DotAI 認定講師分けたけど、どれが効いてるのか分からなくなった、という声は多いです。重なると追えなくなるんですよ。
室谷代表取締役共通のものは上に、例外だけ下に。それで足りないなら、そもそも共通部分の書き方がぼんやりしてる可能性が高いんですよね。
テキトー教師DotAI 認定講師最初に戸惑うのが、どこまでが「共通」なのかの線引きです。そこは一度チームで言葉にしたほうが早いと思います。
まとめ
室谷代表取締役この話、結局は「書いて、効かなかったら直す」の繰り返しなんですよね。完璧な初稿を目指すより、30行でいいから置いてみる。
テキトー教師DotAI 認定講師そうですね。つまずきやすいのは「何を書けばいいか分からない」ところなんですけど、よくある失敗を一つ書くだけでも十分だったりします。
室谷代表取締役あと、AGENTS.md と併用するなら、どっちが何を持つかは最初に決めたほうがいいんですよ。後から整理するのは、だいたい面倒くさいので・・・
テキトー教師DotAI 認定講師現場感覚で言うと、一度決めたら月に一回眺めるだけでだいぶ違います。書いたこと自体を忘れてしまうのが、一番もったいないので。
室谷代表取締役まずは今日、リポジトリに一つファイルを足すところから。それが一番早いんですよね。
