copilot-instructions.md を分割したい？applyTo パターンで解決

はじめに

ども！GitHub Copilotの設定ファイルの設計にいそしんでいる龍ちゃんです。

前回の記事では、GitHub Copilotの設定ファイル5種類を整理しました。今回はその中でも特に重要な「Instructions ファイル」の設計にフォーカスします。

まだInstructionsを使っていない方へ：いきなり設計から入る必要はありません。まずは copilot-instructions.md に思いつくルールをどんどん書いていけばOKです。使っていくうちに「あれも追加したい、これも追加したい」となって、気づいたら肥大化している…というのは自然な流れです。

本記事は、その肥大化に直面したときに読む記事です。現在筆者が検証中の分割パターンを共有しますので、参考にしてみてください。「もっとこうしたほうが良いよ」というフィードバックも大歓迎です！

検証環境

• 検証日: 2026年1月30日
• 環境: VS Code + Dev Container
• GitHub Copilot: 2026年1月時点の機能

*.instructions.md とは

copilot-instructions.md が肥大化してきたとき、救世主となるのが *.instructions.md です。

配置場所: .github/instructions/

このディレクトリに配置したMarkdownファイルは、applyTo で指定したパターンにマッチするファイルを編集するときだけ自動適用されます。

「全員に適用するルール」と「特定のファイルにだけ適用するルール」を分けられるわけです。

押さえておくべきポイント

*.instructions.md を使う前に、知っておくべき挙動が3つあります。

applyTo の基本

ファイルの先頭にYAML形式で applyTo を指定します。

---
applyTo:
  - "**/*.ts"
  - "**/*.tsx"
---

# TypeScript コーディング規約

- strict mode を使用
- any 型の使用禁止
- ...

グロブパターンで指定するので、**/*.py（全ディレクトリのPythonファイル）や src/frontend/**/*（特定ディレクトリ配下すべて）といった柔軟な指定が可能です。複数パターンを指定した場合は、いずれかにマッチすれば適用されます。

複数ファイルはマージされる

ここが重要なポイントです。複数の Instructions がマッチした場合、競合ではなく結合されます。

編集対象: src/components/ui/Button.tsx

マッチする Instructions:
├── frontend-common.instructions.md   (applyTo: src/**/*.tsx)
├── frontend-ui.instructions.md       (applyTo: src/components/ui/**/*.tsx)
└── frontend-types.instructions.md    (applyTo: **/*.ts, **/*.tsx)

→ 3つすべてマージされて適用

「上書き」ではなく「結合」です。つまり、3つのファイルに書かれたルールがすべて有効になります。

矛盾を避ける設計が必須

マージされるなら、矛盾するルールを書いたらどうなるの？という疑問が浮かびます。

調べたところ「わかりません」、でした。公式ドキュメントにルールが記載されていませんでした。（もし見つけたら教えてください）

GitHubのコミュニティでも議論されていますが、現時点で優先順位のルールは公開されていません。

• Discussion #162201: 選択的ロードは未サポート
• Issue #12878: 設定に関係なく全ファイルが読み込まれる

結論: 矛盾しない設計が唯一の解決策です。

具体的には：

• 各 Instructions は独立した関心事を扱う（UIルール、APIルール、テストルールなど）
• 重複するルールを書かない（同じことを複数ファイルに書かない）

「優先順位でなんとかする」という発想は捨てて、そもそも矛盾が起きない設計を心がけましょう。

分割パターン

では、実際にどう分割すればいいのか。2つのパターンを紹介します。

基本形: 言語別

最もシンプルで始めやすいパターンです。

.github/instructions/
├── python.instructions.md      # applyTo: **/*.py
├── typescript.instructions.md  # applyTo: **/*.ts, **/*.tsx
└── markdown.instructions.md    # applyTo: **/*.md

言語ごとに固有のルール（命名規則、型ヒントの書き方、フォーマットなど）を分離できます。複数言語を扱うプロジェクトでは、この基本形から始めるのがおすすめです。

筆者が採用しているパターン（ミックス系）

筆者は現在、モノレポ構成のプロジェクトで「ディレクトリ別 + 関心事別」のミックスパターンを検証しています。

設計のポイント:

1. ディレクトリ単位で大まかな責務分担（frontend / tools など）
2. 関心事別にさらに細かくルールを分割（UI / API / 状態管理など）
3. 別ディレクトリではノイズとなる情報を分離

copilot-instructions.md（おおもと）

おおもとの copilot-instructions.md はルーター役に徹します。

# Project Overview

Monorepo with multiple applications.

| Path                  | Stack        |
|-----------------------|--------------|
| application/tools/    | Python 3.12+ |
| application/frontend/ | Next.js 15   |

## Path-scoped Instructions

アプリケーション固有のルールは `.github/instructions/` で定義。

モノレポ構成であることを伝え、詳細は分割ファイルに任せます。共通禁止事項（.env をコミットしないなど）もここに書きますが、それ以外は軽量に保ちます。

Instructions ファイル（application 単位 + 関心事別）

.github/instructions/
├── python-tools.instructions.md      # application/tools/**/*
├── frontend-common.instructions.md   # application/frontend/**/*
├── frontend-ui.instructions.md       # .../components/ui/**/*
├── frontend-api.instructions.md      # .../generated/**/*
├── frontend-store.instructions.md    # .../store/**/*
└── frontend-feature.instructions.md  # .../features/**/*

frontend-common.instructions.md にはフロントエンド全体のルール（技術スタック、コードスタイル、命名規則）を書き、frontend-ui.instructions.md には shadcn/ui 専用のルール（npx shadcn@latest add で追加、CVA でバリアント定義など）を書く、という具合です。

このパターンのメリット

Python を触っているときに Next.js のルールがノイズになる、といった問題も解消します。

まとめ

*.instructions.md を活用した分割設計のポイントをまとめます。

まずは使ってみて、肥大化を感じたら分割を検討する。そのときに本記事を思い出していただければ幸いです。

参考リンク

公式ドキュメント

• Adding custom instructions for GitHub Copilot

GitHub Issues / Discussions

• Discussion #162201 – 選択的ロードは未サポート
• Issue #12878 – 全ファイルが読み込まれる問題

関連記事

• GitHub Copilot設定5種を網羅！生産性を最大化する使い分け術

ここまで読んでいただき、ありがとうございました！

Instructions も設計対象です。肥大化を感じたら、ぜひ分割設計を試してみてください。