この記事のポイント
GitHub Copilotのカスタム指示は、AIコード生成の精度と一貫性を高めるための重要な仕組みです。
プロジェクトの技術スタック、命名規則、設計方針などを自然言語で明示的に伝えることで、Copilotはより実践的なコード提案を行います。
曖昧な指示やメンテナンスされない指示ファイルは逆効果となることもあり、導入・設計・運用までを含めた“情報設計”としての視点が求められます。
Copilotを単なる補助ツールから「チームの一員」へと進化させるために、カスタム指示は不可欠なステップです。

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
GitHub Copilotは、AIによるコード生成の可能性を広げる強力なツールです。 しかし、プロジェクトの設計方針や命名規則を反映させるには、AIに明示的な“前提共有”が必要です。 そこで注目されているのが、「カスタム指示(Custom Instructions)」という新機能です。
本記事では、GitHub Copilotのカスタム指示とは何か、なぜ必要なのか、どのように実装し、実務に活かすかを丁寧に解説します。 プロジェクトごとにAIを“チームの一員”として機能させたい開発者・エンジニアの方にとって、必見の内容です。AI総合研究所では企業のGitHub Copilot導入支援を行っています。請求書でのお支払いも可能です。ご興味ある方はお気軽にお問い合わせください。
GitHub Copilotのカスタム指示とは?
GitHub Copilotのカスタム指示とは、AIコード支援の挙動をプロジェクト単位で調整できる機能です。
GitHub Copilot は、AIがコードを予測・生成するアシスタントですが、従来はプロジェクトの文脈や設計方針を深く理解することが困難でした。そこで導入されたのが「カスタム指示(Custom Instructions)」です。
この機能では、リポジトリ内に .github/copilot-instructions.md という専用ファイルを設置することで、Copilot に対して次のような情報を与えることが可能になります。

実際のファイルイメージ
- プロジェクトで使用している技術スタック(例:Next.js、TypeScript)
- 命名規則やコーディングスタイル
- フォルダ構成や設計パターン(例:Atomic Design)
- よく使うライブラリや関数群
- チーム固有のルールや方針
Copilot はこの情報をもとに、より適切なコード補完や関数の提案を行います。
GitHub Copilot自体を知りたい人は以下の記事も参考にしてください。
関連記事:
なぜ「カスタム指示」が必要なのか

AIコード補完の精度と一貫性を保つには、プロジェクト文脈を明示的に伝える仕組みが必要です。
GitHub Copilot は、非常に高精度なコード生成能力を備えていますが、その出力内容は プロンプト(前後のコード文脈)や一般的な開発知識 に依存しています。つまり、プロジェクト固有のルールや構造を知らないまま、汎用的なコードを提案する傾向があります。
たとえば次のような課題が、従来のCopilot運用では頻繁に発生していました。
| よくある課題 | 内容の一例 |
|---|---|
| 命名規則のずれ | camelCase を使いたいのに snake_case で生成される |
| 技術スタックの認識不足 | Vue.js プロジェクトなのに React の構文を提案される |
| 設計方針との不一致 | ファイル分割ルールを無視して巨大な関数を生成する |
| コメントの形式が不統一 | JSDoc や Python Docstring の書き方が混在する |
こうした問題に対し、カスタム指示は「プロジェクトの文脈やルールを明示する手段」として機能します。開発チームが意図した設計方針やルールを、Copilot に事前に伝えることで、生成されるコードの一貫性が向上します。
Copilotは非常に柔軟な生成能力を持っていますが、その柔軟さゆえに「プロジェクトに合わないコード」を生成してしまうこともあります。カスタム指示は、その精度と再現性を保つためのブリッジとして、今後ますます重要性を増していくと考えられます。
実装方法と構成の基本
GitHub Copilotのカスタム指示は、.github/copilot-instructions.md ファイルの作成と記述によって簡単に導入できます。
この機能はGitHubリポジトリ単位で有効になるため、プロジェクトごとのルールをCopilotに伝えるための構造が自然に備わっています。以下に、導入手順とファイル構成の基本を示します。
1. ファイルの設置場所と名前
カスタム指示ファイルは、次の場所に作成します:
/.github/copilot-instructions.md
このファイルが存在することで、GitHub Copilotはその内容を自動的に読み取り、コード生成時の参考にします。現時点では copilot-instructions.md という名前と .github/ 配下の配置が必須です。
2. 書き方のルール
指示ファイルは Markdown 形式で記述できます。内容に厳密な構造は求められませんが、以下のような項目を意識的に整理しておくと効果的です:
-
プロジェクトの技術スタック
- 例:このプロジェクトは Next.js + TypeScript を使用しています。
-
命名規則
- 例:変数は camelCase、コンポーネントは PascalCase を使用します。
-
ファイル構成の方針
- 例:各 UI コンポーネントは
/componentsフォルダに配置します。
- 例:各 UI コンポーネントは
-
共通関数やユーティリティの利用指針
- 例:日付処理には
dayjsを使用します。標準のDateは使用しません。
- 例:日付処理には
-
テストやドキュメントのスタイル
- 例:JSDoc スタイルのコメントを関数ごとに記述してください。
3. 複数ファイルでの分割管理(上級者向け)
Copilotの拡張機能では、複数ファイルに分けて指示を管理する構成も可能です(VS Code拡張などが対応)。たとえば以下のように用途ごとに分割できます:
.github/
copilot-instructions.md # 全体概要
instructions/frontend.md # フロントエンド用の詳細ルール
instructions/backend.md # バックエンド用の詳細ルール
instructions/testing.md # テストルール
このように分割することで、指示ファイルの保守性が高まり、チーム内での共有やレビューも容易になります。
補足:モード別に「擬似的なモデル呼び出し」も可能に

vscodeカスタムチャットモードの作成
2025年現在、Visual Studio Code に統合された GitHub Copilot Chat では、モード(Chat Mode)の概念が拡張され、ユーザー自身が「目的別のエージェント」を定義できるようになっています。
具体的には、以下の3つのビルトインモードが提供されています:
| モード名 | 概要 |
|---|---|
| Ask モード | コードの説明や技術的質問への回答に特化 |
| Edit モード | 複数ファイルを直接編集する作業に特化 |
| Agent モード | あいまいなタスクを自律的に処理し、ターミナル操作や複雑な編集にも対応 |
加えて、カスタムチャットモード(Custom Chat Modes)を .chatmode.md ファイルで作成すれば、たとえば以下のような「目的特化型AIエージェント」が定義できます:
- 実装プランを作成する「Planモード」
- セキュリティレビュー用の「SecureReviewモード」
- ドキュメント生成に特化した「Writerモード」など
.chatmode.md ファイルには次のような内容を定義します:
---
description: Generate an implementation plan for new features or refactoring.
tools: ['search', 'fetch', 'findTestFiles']
model: Claude Sonnet 4
---
# Planning mode instructions
You are in planning mode. Generate an implementation plan only, no edits.
この構成によって、モードを切り替えるだけで、異なるAIの“人格”や“目的意識”を切り替えられるため、まさに「AIの使い分け」「エージェント設計」に近い運用が可能になります。
作成手順(抜粋):
- VSCodeの「Chat > Configure Chat > Modes」で新規モードを作成
.github/chatmodes/フォルダに.chatmode.mdを設置model:を指定すれば、モード単位で使用するAIモデルも切り替え可能(例:GPT-4 / Claude など)
このように、Copilotの「チャットモード構成」は、プロンプトとツール、モデルを組み合わせた高度な開発支援ワークフローの設計手段として活用できます。
参考:vscode
指示に記載すべき内容例とその効果
カスタム指示ファイルでは、技術スタックや命名規則など、AIに“開発の前提”を共有することが重要です。
Copilot のカスタム指示ファイルは、単なるメモではなく、「プロジェクトの文脈」を AI に理解させるための説明書です。記載する内容によって、生成されるコードの品質・整合性に明確な変化が現れます。
詳細はこちらの公式も参照してください:GitHub Copilotカスタム指示
主な記載項目と期待される効果
| 指示内容の種類 | 具体的な記載例 | Copilotの生成結果に与える影響 |
|---|---|---|
| 技術スタック | 「このプロジェクトは Next.js と TypeScript を使用しています」 | React Hooks + TS構文を前提としたコードが生成される |
| 命名規則 | 「変数は camelCase、コンポーネントは PascalCase で命名します」 | 指定した命名パターンで自動補完されるようになる |
| ライブラリ使用方針 | 「日付処理は dayjs を使用してください。Date型の直接使用は禁止です」 | Date を使わず dayjs() が初期提案されるようになる |
| 設計ルール | 「Atomic Design に基づき、UI は atoms/molecules/organisms に分けます」 | ファイル分割・ディレクトリ構造の例が設計方針に合致するようになる |
| テスト戦略 | 「ユニットテストは Jest を使い、React Testing Library を併用します」 | テストコード生成時に最適な構文・APIが選ばれる |
ビフォー/アフター例:命名規則の違い
指示なしのCopilot出力(React Buttonコンポーネント)
function my_button() {
return <button>Click</button>;
}
指示あり(PascalCaseルール明記後)
function MyButton() {
return <button>Click</button>;
}
チームルールの浸透にも有効
特に初学者や外部メンバーが加わるプロジェクトでは、カスタム指示が「非同期のコードレビュー」のような役割を果たす場面もあります。
明文化されたルールが Copilot 経由でコード生成に反映されることで、統一感のあるコーディングスタイルを自然に維持しやすくなります。
実務での活用ポイントと注意点
カスタム指示は、適切に設計・共有・運用することで、チーム全体の生産性とコード品質を向上させます。
GitHub Copilot のカスタム指示は単なる「ヒント」ではなく、実際の開発現場におけるAI活用の“設計図”になります。特にチーム開発や複数人による保守が必要なプロジェクトにおいて、その価値は非常に高くなります。
以下に、実務での活用にあたって意識したいポイントと注意点を示します。
チーム運用におけるベストプラクティス
| 項目 | 実務での工夫例 |
|---|---|
| 共通化 | .github/copilot-instructions.md を全プロジェクトに横展開。テンプレートを整備することで新規開発にもスムーズに導入可能。 |
| レビュー | Pull Request 時に「カスタム指示との整合性」をチェックする仕組みを導入。ルール逸脱の検知も自動化できる。 |
| 明文化 | スタイルガイドやドキュメントとの内容重複を避けつつ、Copilot向けに言語化を工夫。自然言語での記述が望ましい。 |
| 更新管理 | 技術スタックの変更に合わせて、定期的に指示ファイルを見直す体制を構築。 |
導入時の注意点
1. 曖昧な表現は逆効果になる
たとえば「わかりやすく書いてください」といった曖昧な指示は、Copilot にとっても曖昧です。ルールは具体的に書く必要があります(例:「関数ごとにJSDoc形式のコメントを記述」など)。
2. 指示の適用範囲はあくまで補完時のみ
Copilot はあくまで入力に対する補完支援を行うツールであり、強制的にルールを適用するわけではありません。指示があっても、常に期待通りの出力になるとは限らないことに注意が必要です。
3. Copilotのモデルやプランによって挙動が異なる
- Copilot Chat / Business / Enterprise で対応機能や精度が異なる可能性があります。
- 自社コードベースを元に学習できる機能は、Enterprise契約が前提となります。
Copilot のカスタム指示は「AI活用による組織的なナレッジ共有」という観点でも活用できます。指示ファイルが実質的に“開発文化の翻訳”となり、開発方針をAIに伝え、成果物に反映させる仕組みが完成します。
よくある誤解とFAQ
GitHub Copilotのカスタム指示は便利な機能ですが、その目的や制約を誤解しているケースも少なくありません。
導入前に想定される疑問や誤解を整理し、正しい理解のもとで活用を進めることが重要です。以下に、よくある質問とその回答をQ&A形式でまとめます。
Q1. 指示を記述すれば、必ず従ってくれるのですか?
A. いいえ。Copilotは指示を参考に補完を行いますが、絶対に従うわけではありません。
特に曖昧な表現や一貫性のない記述では、意図通りの動作にならない可能性があります。
命令ではなく「提案としての重み付け」であることを前提に、具体的で矛盾のない指示を心がけることが重要です。
Q2. 指示はどこまで細かく書いてよいのですか?
A. 技術的な制約は特にありませんが、実装ルールやスタイルガイドを「すべて移植」するような冗長な記述は非効率です。
たとえば「useEffectの代わりにuseLayoutEffectを使うべき」といった場面での方針など、生成に直接影響するものを優先的に記述すると効果が高くなります。
Q3. ユーザーごとに違う指示を使えますか?
A. はい。GitHub Copilotには個人設定ベースのカスタム指示(User Instructions)も用意されています。
ただし、リポジトリ単位のカスタム指示(.github/copilot-instructions.md)が優先されるケースもあるため、両者の整合性を意識して運用する必要があります。
Q4. 指示ファイルを設置すれば、チーム全員に自動適用されますか?
A. 原則としてはそのリポジトリを開いているユーザーに対して適用されます。
ただし、使用しているエディタや拡張機能(VSCodeのCopilot拡張など)が最新版であることが前提です。
Q5. 有料プランが必要ですか?
A. 現時点(2025年9月時点)では、GitHub Copilot Business または Enterprise の利用者であれば、リポジトリ単位の指示ファイル機能に対応しています。
無料プラン(Copilot Individualや一部旧プラン)では、指示ファイルを無視する挙動も確認されており、業務利用を前提とする場合は Business 以上の契約が推奨されます。
Copilotは「魔法のように賢いAI」ではなく、「賢く使えば力を発揮する支援者」です。
カスタム指示もその延長線上にあり、開発者側の設計力と運用知識が活用の成否を左右する点は、常に意識すべきでしょう。
GitHub Copilot導入をお考えの企業様へ
開発生産性を最大化するAI活用法を提案
GitHub Copilotの導入から、コーディング効率化の実現まで専門家が無料でご相談承ります。最新のAI開発ツールで、チームの生産性を飛躍的に向上させましょう。
まとめ
GitHub Copilotのカスタム指示は、AIによるコード生成の“精度”と“再現性”を高めるための重要な仕組みです。
プロジェクトやチームの方針・スタイルを自然言語で明示的に伝えることで、Copilotはより実践的で一貫性のあるコード提案を行うようになります。これは単なる「補完精度の向上」にとどまらず、開発現場のナレッジをAIに伝え、次世代のチーム開発を支える基盤となる可能性を秘めています。
一方で、曖昧な指示やメンテナンスされない指示ファイルは逆効果となることもあり、導入・設計・運用までを含めた“情報設計”としての視点が求められます。
Copilotを単なる補助ツールから「チームの一員」へと進化させるために、カスタム指示は不可欠なステップです。
今後さらに高度化するCopilotエージェント機能やレビュー支援機能とも連携する可能性があり、開発支援AIと人間の関係性を再定義する鍵として注目されます。
AI総合研究所は企業のGitHub Copilot導入支援を行っています。請求書でのお支払いも可能です。ご興味ある方はお気軽にお問い合わせください。








