GitHub Copilotをチーム開発で活用する｜カスタムインストラクションの設定と運用ポイント

GitHub Copilot カスタムインストラクションとは

GitHub Copilot のカスタムインストラクション（Custom instructions）は、GitHub Copilot に対して、プロジェクト固有のルールやコーディング規約、利用するツールや開発手順などの追加コンテキストをあらかじめ設定できる機能です。設定した指示は、対応する Copilot のチャットやコードレビューなどの応答生成時に追加コンテキストとして参照されるため、毎回同じ前提条件をプロンプトに書き直す手間を減らせます。

たとえば「TypeScript を優先する」「変数名はキャメルケースにする」「このリポジトリでは特定のテストフレームワークを使用する」といった方針を事前に定義しておくことで、Copilot がプロジェクトの前提に沿った提案を行いやすくなります。指示を毎回のプロンプトに書き足す必要がなくなるため、開発者ごとに指示内容がぶれる問題も抑えられます。

チーム開発では、コーディング規約や技術スタックがプロジェクトごとに異なるのが一般的です。カスタムインストラクションを活用することで、開発者がCopilotに毎回文脈を伝え直す手間を省き、プロジェクトの方針に沿った一貫性のあるコード生成を実現できます。特にレビュー段階で発生していた「規約に沿っていないコードの手戻り」を、生成時点である程度抑えられる点が実務的な価値になります。

GitHub Copilot カスタムインストラクション　イメージ（参考：GitHub ブログ）

GitHub Copilotのカスタムインストラクションの種類

GitHub Copilot のカスタムインストラクションには、適用範囲の異なる3つの種類があります。以下の表で、それぞれの適用範囲と主な利用場面を整理しました。この表の内容を踏まえたうえで、次の項から各種類の詳細を順にご説明します。

この3種類は「どこまでの範囲でCopilotの挙動を制御したいか」で使い分けます。個人の生産性を上げたいのか、チームの規約を統一したいのか、組織全体でガバナンスを効かせたいのかによって、選ぶ種類が変わってきます。

個人カスタムインストラクション

個人カスタムインストラクションは、ユーザー個人の好みに合わせて Copilot の応答を調整するための機能です。たとえば、使用したい言語、説明のトーン、出力スタイルなど、個人の作業スタイルに関する方針を反映できます。

「常に TypeScript で例を示してほしい」「簡潔に説明してほしい」「日本語で応答してほしい」といった個人向けの要望を継続的に反映したい場合に向いています。

開発者ごとに扱う言語やフレームワークの得意分野が異なる場合や、複数の案件を掛け持ちしている場合に、自分のワークフローに合わせて調整できるのが利点です。

個人設定はGitHubアカウントに紐づくため、同一アカウントで別のリポジトリを扱う際にも設定が引き継がれます。そのため、リポジトリごとに設定を切り替える必要がなく、開発者本人のCopilot体験を統一できます。

リポジトリカスタムインストラクション

リポジトリカスタムインストラクションは、特定のリポジトリに対して Copilot に追加コンテキストを与えるための機能です。チームで共通化したいコーディング規約、技術スタック、ディレクトリ構成、推奨パターンなどを共有する用途に適しています。

このインストラクションはリポジトリ内のファイル（.github/copilot-instructions.md）として管理されるため、対応するCopilot機能では、リポジトリ内の指示ファイルが参照される仕組みになっています。実際に反映されるかはCopilot機能・IDE・設定・権限に依存するため、利用環境ごとに動作を確認しておくことが重要です。新規メンバーに口頭で規約を説明する手間や、README・Wikiで別途参照させる手間を減らせるのが特徴です。

リポジトリカスタムインストラクションには、以下の3種類があります。

• リポジトリ全体に適用する指示: リポジトリ内のすべてのファイルに一律で適用
• 特定のファイルパスに限定する指示: フロントエンド・バックエンドなど、パスごとに異なる規約を適用
• エージェント向けの指示: Copilot coding agent など特定のエージェントに向けた指示

同一リポジトリでも、フロントエンドとバックエンドで言語や規約が異なるモノレポ構成では、パス別インストラクションで細かく指示を分けられるのが実務的な強みです。

組織カスタムインストラクション

組織カスタムインストラクションは、GitHub 組織全体で共通の方針を反映したい場合に利用する機能です。複数のリポジトリにまたがって、セキュリティ、開発方針、レビュー観点などの共通ルールを持たせたい場面に向いています。

たとえば「秘密情報をコードに直書きしない」「Pull Requestには必ずテストコードを含める」「特定のライブラリの利用を推奨/禁止する」といった、リポジトリを問わず組織全体で守りたいルールを一元管理できます。組織で新しいリポジトリを作るたびに同じ指示を書き直す運用から脱却でき、ガバナンス面のコストを下げる効果が期待できます。

なお、組織カスタムインストラクションはGitHub Copilot BusinessまたはGitHub Copilot Enterpriseの組織のみで利用できる機能です。導入検討時には契約中のプランが対応しているか確認しておく必要があります。

3種類の優先順位

個人・リポジトリ・組織のカスタムインストラクションが同時に存在する場合は、優先順位を踏まえて扱われます。以下の表で、各種類の優先順位と適用対象を整理しました。

個人の指示は最も高い優先順位で扱われますが、これは組織・リポジトリの指示を完全に上書きするわけではなく、関連する指示セットとしてまとめてCopilotに渡されます。

そのため、個人設定がリポジトリや組織の方針と大きく矛盾する場合、Copilotがどちらの指示を優先するかは実行内容によって変わる可能性があります。運用上は、個人設定・リポジトリ設定・組織設定のあいだで、できるだけ矛盾しないよう整理しておくことが重要です。

カスタムインストラクションの設定方法

ここでは、カスタムインストラクションの具体的な設定方法をご説明します。それぞれの種類で設定場所が異なるため、目的に合わせて選択してください。

個人カスタムインストラクションの設定

個人カスタムインストラクションは、GitHub.comのCopilot Chatから設定します。設定はアカウントに紐づき、GitHub.comのCopilot Chatなど、対応している環境で反映されます。対応範囲はサーフェスごとに異なるため、詳細は公式ドキュメントをご確認ください。

GitHub.comでCopilot Chatを開きます。

Copilot Chatを開く

プロフィール画像をクリックし、「Personal instructions」を選択します。

Personal instructionsを選択

テキストボックスに自然言語で指示を入力します。必要に応じてテンプレートを選択します。テンプレートには「使用言語の設定」「応答トーンの設定」など、代表的なパターンが用意されているため、慣れないうちはテンプレートから始めるのがおすすめです。

個人カスタムインストラクションの入力

「Save」をクリックして保存します。保存後は即座に反映されるため、Copilot Chatを再起動する必要はありません。

個人カスタムインストラクションを保存

設定例としては、以下のような指示が挙げられます。実務でよく使われるパターンをいくつかご紹介します。

• 「Always respond in Japanese」（常に日本語で応答）: 説明文を日本語で受け取りたい場合の基本設定
• 「Use a helpful, collegial tone. Keep explanations brief」（親しみやすく協調的なトーンで、説明は簡潔にする）: 長文の説明が不要で、要点だけ知りたい場合
• 「Use TypeScript rather than JavaScript」（JavaScript より TypeScript を優先する）: 型安全性を重視するプロジェクトで作業する場合

これらの指示は組み合わせて設定することも可能です。自分の作業スタイルに合わせて、段階的に指示を追加していくとよいでしょう。

リポジトリカスタムインストラクションの設定

リポジトリ全体に適用する指示は、リポジトリ内の.github/copilot-instructions.mdファイルに記述します。このファイルをリポジトリのルートから相対パスで配置することで、Copilotが自動的に読み込む仕組みです。

以下は、コーディングガイドラインを記述したサンプルです。

# コーディングガイドライン

- 可能な限り型情報を明示すること
- JavaScript / TypeScript ではセミコロンを付けること
- 必要に応じて関数の意図が分かるコメントを補足すること
- このリポジトリで採用しているテストフレームワークに従うこと

自然言語でMarkdown形式で記述し、インストラクション間の空白は無視されるため、箇条書き、段落、空白区切りのいずれの形式でも記述できます。書式に神経質になる必要はなく、チームメンバーが読みやすい形で記述することが優先されます。

リポジトリカスタムインストラクションの記述例

このファイルはリポジトリの一部として管理されるため、Gitの通常のワークフローで変更履歴を追跡できます。規約が変更された場合はPull Requestとしてレビューを経て反映することで、チーム全員に変更内容を可視化できる点も利点です。

パス別インストラクションの設定

特定のファイルやディレクトリに限定した指示を追加する場合は、.github/instructions/ディレクトリにNAME.instructions.md形式のファイルを作成します。パス別インストラクションは、モノレポ構成や、フロントエンド・バックエンドで技術スタックが分かれるプロジェクトで特に有効です。

ファイルの冒頭にフロントマターでapplyToキーワードを記述し、glob構文で対象ファイルを指定します。

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

# TypeScript コーディング規約

- 型やインターフェースは PascalCase で命名する
- 変数名と関数名は camelCase で命名する
- 必要に応じて定数の命名規則を統一する
- `any` の使用はできるだけ避け、具体的な型を明示する

上記の例では、TypeScriptファイル（.ts と .tsx）にのみ規約が適用されます。同じリポジトリの別のパスに、Pythonバックエンド用の規約ファイル（applyTo: "server/**/*.py"など）を並行して置くことも可能です。この仕組みにより、リポジトリ全体で一律の規約を強制するのではなく、ファイル種別ごとに最適な規約を反映できるようになります。

組織カスタムインストラクションについて

組織カスタムインストラクションは、GitHub.com上の組織設定から追加できます。組織全体で共通方針を反映したい場合に有効で、設定できるのは組織オーナーです。設定内容は組織配下のすべてのリポジトリに適用されるため、変更する際は影響範囲を事前に確認することが重要です。

対応環境

主要な開発環境（GitHub.com、VS Codeなど）では、カスタムインストラクションに対応しています。ただし、種類ごとに対応する環境が異なるため、意図した環境で機能するかを事前に確認しておく必要があります。対応範囲は環境によって異なるため、詳細は公式ドキュメントをご確認ください。

カスタムインストラクションの書き方のコツ

カスタムインストラクションの効果は、書き方によって大きく変わります。ここでは、GitHubが公式に推奨しているベストプラクティスを紹介します。書き方の観点を押さえることで、Copilotに指示を正しく反映させやすくなります。

プロジェクトの概要を記述する

インストラクションの冒頭に、プロジェクトの目的や対象ユーザーを簡潔に記述します。Copilotがプロジェクトの文脈を理解する手がかりとなり、より適切な提案を生成しやすくなります。

# プロジェクト概要
顧客管理システム（CRM）向けのバックエンド API。
中小企業向けに、顧客情報、商談情報、請求関連データを管理する機能を提供する。

記述量はエレベーターピッチ程度の簡潔さが推奨されています。長すぎる説明は重要な指示が埋もれやすいため、要点を絞って記載するのが適切です。プロジェクトの概要が明確になっていると、Copilotがコードを提案する際に「このプロジェクトで想定される用途に沿ったコード」を返しやすくなります。

技術スタックを明記する

使用しているフレームワーク、言語、ツールをリスト形式で記載します。Copilotが適切なライブラリやAPIを前提としたコードを提案するために有効です。

# 技術スタック
- Backend: Python (FastAPI), PostgreSQL, SQLAlchemy
- Frontend: Next.js, TypeScript
- Testing: pytest, Playwright
- CI/CD: GitHub Actions

技術スタックを明記していない場合、Copilotは類似プロジェクトから推測してコードを提案するため、実際に採用しているライブラリと異なるものを提案されることがあります。特にPythonのWebフレームワークやテストライブラリのように選択肢が複数ある領域では、明示することで手戻りを大きく減らせます。

コーディングガイドラインを明示する

命名規則、フォーマットルール、テスト方針など、チームで統一したい規約を箇条書きで記述します。

# コーディングガイドライン
- 可能な限り関数や変数の型を明示する
- 変数名は camelCase、定数名は UPPER_SNAKE_CASE を基本とする
- 新機能を追加する場合は、必要に応じてテストを整備する
- コミットメッセージは、チームで定めた命名規則に従う

コーディングガイドラインは、レビュー時に指摘の多い項目から順に記載していくと効果的です。「毎回同じ内容でレビュー指摘が発生している」項目をインストラクションに落とし込むことで、レビュー工数の削減につながります。

プロジェクトの構造を説明する

ディレクトリ構成と各ディレクトリの役割を記述することで、Copilotがファイルの配置先やインポートパスを正しく提案しやすくなります。

# プロジェクト構造
- server/ : FastAPI バックエンド
  - models/ : データモデル
  - routers/ : API エンドポイント
  - services/ : ビジネスロジック
- client/ : Next.js フロントエンド
  - components/ : UI コンポーネント
  - hooks/ : カスタムフック
- tests/ : テストコード

ディレクトリ構造の情報がないと、Copilotが独自の推測で新規ファイルの配置場所を提案してしまうケースがあります。プロジェクトの構造を記述しておくことで、既存のディレクトリ規則に沿ったコード提案を得られやすくなります。

分量は簡潔に保つ

インストラクションは 重要な指示を短く整理する ことが推奨されています。短いインストラクションのほうがCopilotに完全に処理されやすく、指示の抜け漏れが発生しにくくなります。

インストラクションが長くなりすぎると、後半の指示がCopilotに十分反映されない可能性が高まります。最初は最小限の指示から始め、使いながら段階的に追加・改善していくアプローチが効果的です。運用の中で「Copilotが従わない指示」があれば、その部分をより明確な表現に書き直すか、重要な指示を冒頭に移動する運用が推奨されます。

GitHub Copilotの料金プラン

ここでは、カスタムインストラクションを運用する際に確認したい契約と料金をご説明します。

組織運用を支えるGitHubの管理基盤

リポジトリカスタムインストラクションはリポジトリ内のファイルとして管理され、組織カスタムインストラクションはGitHub.comの組織設定から管理します。そのため、チームや組織へ展開する際は、Copilotライセンスだけでなく、リポジトリ、利用者、アクセス権限を管理するGitHub本体のプランも検討対象となります。

特に、複数の部門やOrganizationにまたがって共通ルールを運用する法人では、SAML SSOやSCIM、監査ログ、複数Organizationのポリシーと請求の一元管理に対応するGitHub Enterpriseが推奨されます。共通ルールを適用する範囲だけでなく、将来のリポジトリや利用部門の拡大も見据え、導入初期からGitHub側の統制レベルを整理しておくことが重要です。

利用範囲に合わせた法人向けプラン

法人向けには、GitHub Copilot BusinessとGitHub Copilot Enterpriseが提供されています。組織カスタムインストラクションはいずれのプランでも利用でき、Copilot EnterpriseはGitHub Enterprise Cloud向けのプランです。

リポジトリカスタムインストラクションは、Business／Enterpriseを含むCopilotの各プランで利用できます。一方、組織全体へ共通の指示を設定する組織カスタムインストラクションには、Copilot BusinessまたはCopilot Enterpriseが必要です。

カスタムインストラクションは、Copilot ChatやCopilot cloud agentなど、対応する機能の応答に追加コンテキストとして利用されます。これらのAIモデルを利用する機能では、選択したモデルと処理されたトークン量に応じてAIクレジットを消費します。コード補完とNext Edit Suggestions（NES）はAIクレジットの対象外で、有料プランでは無制限です。

各ライセンスに含まれるAIクレジットは、組織やエンタープライズなどの請求単位で共有プールに合算されます。共有プールを使い切った後は、管理者の設定に応じて利用をブロックするか、1 AIクレジットあたり$0.01 USDの従量課金で継続できます。

AIクレジットの消費や予算管理については、GitHub Copilotの料金体系ガイド｜AIクレジットの仕組みと予算管理の進め方で解説しています。

GitHub Copilot カスタムインストラクションの活用シーン

ここでは、カスタムインストラクションを活用しやすい具体的な場面をご紹介します。それぞれのシーンで、どのような効果を期待できるのかを含めて解説します。

チーム開発での規約統一

複数の開発者が同じリポジトリで作業する場合、コーディングスタイルや命名規則にばらつきが生じることがあります。リポジトリカスタムインストラクションにチームの規約を定義しておくことで、Copilot の提案を共通方針に寄せやすくなり、レビュー時の観点統一にも役立ちます。

たとえば命名規則、コメントスタイル、エラーハンドリング方針などをインストラクションに落とし込むと、レビュー時に同じ指摘が繰り返される事態を減らせます。開発者ごとのスタイルの違いを、レビューではなく生成の段階で吸収できるようになる点が大きなメリットです。

コードレビューの品質向上

GitHub Copilotのコードレビュー機能は、カスタムインストラクションの内容を考慮してレビューコメントを生成します。セキュリティ上の確認事項や、プロジェクト固有のルールをインストラクションに記述しておくことで、Copilot code review に持たせたい観点を共有しやすくなります。

たとえば「認証情報を直接コードに記述していないか」「例外処理でエラー情報を過剰に外部に返していないか」といったセキュリティ観点をインストラクションに含めておくと、Copilotが該当箇所を指摘するようになります。人間のレビュアーが見落としがちな観点を機械的に補完できる仕組みとして活用できます。

言語やフレームワーク別のルール分割

パス別インストラクションを使うことで、同じリポジトリ内でもファイルの種類ごとに異なるルールを適用できます。たとえば、フロントエンド（TypeScript）とバックエンド（Python）で異なるコーディング規約を持つモノレポ構成のプロジェクトでは、それぞれに専用のインストラクションファイルを用意することで、適切な指示をCopilotに渡すことができます。

技術スタックが分かれるプロジェクトで、単一の規約ファイルにすべてを詰め込むと、指示の量が増えすぎてCopilotが指示を十分に反映しなくなる恐れがあります。パス別に分割することで、それぞれの言語・フレームワークに関する指示を短く保ちつつ、必要な部分にのみ確実に反映できる状態を作れます。

新規メンバーのオンボーディング

プロジェクトのカスタムインストラクションに技術スタックやディレクトリ構成を記述しておくと、新しく参加したメンバーが Copilot を利用する際にも、プロジェクトの前提に沿った提案を受けやすくなります。コーディング規約や推奨パターンを毎回個別に説明する手間を減らしやすくなり、結果としてオンボーディングの効率化につながる可能性があります。

新規メンバーがプロジェクトに慣れるまでの学習曲線は、開発生産性に直結する課題の一つです。Copilotの提案がプロジェクトの規約に沿った内容になっていれば、新規メンバーは自然と規約を身につけていく学習効果も期待できます。

組織横断でのガバナンス

企業内で複数のリポジトリにまたがる共通ルールがある場合、組織カスタムインストラクションを使うことで、組織全体に共通の方針を共有しやすくなります。リポジトリごとに同種の方針を繰り返し記述する手間を減らしやすく、組織横断で共通ルールを周知する際にも有効です。

特にセキュリティポリシー、コンプライアンス要件、ライブラリ選定方針など、組織全体で守るべきルールは、組織カスタムインストラクションで一元管理する運用が向いています。ルール変更が発生した際も、一箇所で更新すれば組織全体に反映される仕組みは、ガバナンス運用のコスト削減にも寄与します。

GitHub Copilot カスタムインストラクション設定時のポイント

カスタムインストラクションを導入する際に留意すべき点をまとめます。運用開始前に押さえておくことで、想定と異なる挙動によるトラブルを避けられます。

コードレビューにおけるインストラクションの反映範囲

以前はCopilotのコードレビュー機能がインストラクションから読み込むのは先頭4,000文字までという制限がありましたが、2026年6月12日にGitHubがこの制限を撤廃したことをChangelogで告知しています。現在はインストラクション全体がコードレビューで参照される形になっています。

ただし、指示が長文になるほど個々のルールが埋もれやすくなる傾向は残ります。コードレビューで特に重視したいルール（セキュリティ要件、命名規則など）は、ファイルの冒頭に配置しておくと、レビュー品質の観点で有利です。書き方のコツでも触れたとおり、指示は簡潔にまとめる方針が引き続き推奨されます。

組織カスタムインストラクションの対応範囲

組織カスタムインストラクションは、2026年4月2日に一般提供（GA）が開始されました（GitHub Changelog）。対応範囲はGitHub.com上のCopilot Chat、Copilot code review、Copilot cloud agentです。

多くの開発者はIDE上でCopilotを利用するケースが多いため、組織カスタムインストラクションだけでは開発現場の全てをカバーできない点に留意が必要です。IDEでも組織方針を反映させたい場合は、リポジトリカスタムインストラクションと併用する運用が現実的です。最新の対応環境は公式ドキュメントをご確認ください。

指示の矛盾に注意

個人・リポジトリ・組織の3つの階層で異なる指示を設定した場合、優先順位を踏まえて扱われます。ただし、関連する指示セットはあわせて Copilot に渡されるため、単純に一方が完全に無視されるとは限りません。

たとえば、組織方針で「関数コメントは英語で記述する」と定めているのに対し、個人設定で「日本語で応答してほしい」と設定していると、Copilotがどちらを優先するか一貫しないケースがあります。特にチーム開発では、個人設定がリポジトリや組織の方針と矛盾しないよう運用ルールを定めておくことが推奨されます。開発チームで運用ガイドラインを整備する際、個人設定の記述例を共有しておくことも有効です。

インストラクションは補助的なものである

カスタムインストラクションはCopilotの応答傾向を調整する機能であり、指示どおりの出力を100%保証するものではありません。Copilotが指示を反映しないケースや、部分的にしか反映されないケースもあり得ます。

そのため、インストラクションで指示している内容であっても、生成されたコードのレビューを省略することはできません。最終的なコード品質は、開発者自身のレビューによって担保する必要があります。カスタムインストラクションは「レビューを不要にする機能」ではなく「レビューの負担を減らす補助機能」として捉える視点が重要です。

機密情報を記載しない

インストラクションファイル（.github/copilot-instructions.mdなど）は、リポジトリ内のファイルとして管理されます。パブリックリポジトリの場合、このファイルは誰でも閲覧できる状態にあります。プライベートリポジトリであっても、リポジトリのアクセス権を持つ全員が閲覧可能です。

機密情報を扱う必要がある場合は、ファイルに直接記載するのではなく、GitHub Actions のシークレットなど適切な方法を利用するべきです。少なくとも、API キーやパスワードのような秘匿情報をカスタムインストラクションに記載する運用は避けるのが安全です。加えて、社内システムのURL、内部のインフラ構成など、外部に漏れると影響のある情報も記載しないよう運用ルールを定めておくことが推奨されます。

プロンプトファイルとの違い

GitHub Copilot には、カスタムインストラクションとは別に Prompt files という機能があります。これはパブリックプレビューとして提供されており、.github/prompts/ディレクトリに.prompt.mdファイルを配置して利用します。

両者の違いは、指示が呼び出されるタイミングにあります。カスタムインストラクションが継続的な追加コンテキストとして常時参照されるのに対し、Prompt files は特定のチャット操作で明示的に呼び出して使う想定です。「常時反映したい規約」はカスタムインストラクションに、「特定のワークフロー（レビュー観点、テスト生成、ドキュメント作成など）で使いたい定型プロンプト」はPrompt filesに、と使い分けることで、より柔軟に Copilot をカスタマイズできます。

まとめ

本記事では、GitHub Copilot カスタムインストラクションの概要、3つの種類（個人・リポジトリ・組織）、設定方法、書き方のコツ、料金プラン、活用シーン、注意点についてご紹介しました。

カスタムインストラクションは、Copilotの応答をプロジェクトやチームの方針に合わせてカスタマイズするための機能です。リポジトリの.github/copilot-instructions.mdにコーディング規約や技術スタックを記述するだけで、チーム全体のCopilot利用品質を底上げできます。組織レベルでの統制が必要な場合は、Copilot BusinessまたはCopilot Enterpriseで利用できる組織カスタムインストラクションも選択肢となります。

一方で、インストラクションは補助的な機能であり、最終的なコード品質は開発者のレビューによって担保する必要がある点、簡潔な記述を心がけないと後半の指示が反映されにくくなる点、機密情報を記載してはいけない点など、運用上の注意点も理解したうえで導入することが重要です。

東京エレクトロンデバイスでは、GitHub Copilotを活用したAI駆動開発環境の構築を、導入計画の策定からカスタムインストラクションを含む社内ガイドラインの設計、組織全体のガバナンス整備、セキュリティ設計までワンストップでサポートしています。

チーム開発でCopilotを本格活用したい方や、組織全体で共通ルールを整備したいご担当者様は、ぜひお気軽にご相談ください。

お問い合わせはこちら