GitHub Copilot の organization custom instructions が 2026年4月2日に一般提供になりました。Copilot Business / Enterprise の組織オーナーは、GitHub.com 上の Copilot Chat、Copilot code review、Copilot cloud agent に、組織共通の既定指示を流し込めます。つまり、これまで開発者ごとのプロンプト運用に分散していた「返答言語」「レビュー観点」「セキュリティ時の案内先」を、チーム標準として持たせやすくなったということです。 (The GitHub Blog)
ただし、うまく使うコツは「何でも organization に集約しない」ことです。GitHub Docs では、organization custom instructions は会社全体の言語やスタイル、セキュリティ方針に向き、リポジトリ custom instructions はプロジェクト固有の規約やツール、パス別 instructions は言語やディレクトリ別の細則に向くと整理されています。さらに優先順位は個人 > リポジトリ > organization なので、organization は“強制ルール集”ではなく“組織の既定値”として設計したほうが運用しやすいです。 (GitHub Docs)
GitHub Copilot の organization custom instructions が GA で変わったこと
organization custom instructions は、2025年4月17日に GitHub.com の Copilot Chat 向け機能として登場しましたが、その時点では Copilot Enterprise 向けでした。今回の 2026年4月2日の GA では、Copilot Business / Enterprise の組織向け機能として案内され、適用先も GitHub.com 上の Chat だけでなく、Copilot code review と Copilot cloud agent まで広がっています。設定場所は組織設定の Copilot > Custom instructions です。 (The GitHub Blog)
| 項目 | 2025年4月の初回公開 | 2026年4月2日のGA |
|---|---|---|
| 対象プラン | Copilot Enterprise | Copilot Business / Enterprise |
| 主な適用先 | GitHub.com の Copilot Chat | GitHub.com の Copilot Chat / Copilot code review / Copilot cloud agent |
| 設定場所 | 組織設定の Copilot 画面 | 組織設定の Copilot 画面 |
上の差分を見ると、今回の価値は「チャットの話し方をそろえる」だけではありません。レビューコメントの観点や、cloud agent が作業するときの既定の考え方まで、組織単位で薄く広くそろえられるようになった点が重要です。 (The GitHub Blog)
さらに GitHub Docs では、組織設定で定義した custom instructions は、その組織のメンバーであれば、Copilot サブスクリプションの付与元に関係なく使われると説明されています。自社付与ライセンスと個人契約が混ざる環境でも、GitHub.com 上の組織コンテキストでは同じ既定指示に寄せやすいのは、地味ですが実務上かなり効きます。 (GitHub Docs)
何を organization custom instructions で統一できるのか
custom instructions は、毎回プロンプトに同じ前提を書く代わりに、Copilot に自動で追加される“見えない文脈”です。組織レベルでは、会社全体でぶれさせたくない前提を入れるのが向いています。GitHub Docs の例でも、会社の使用言語、回答スタイル、セキュリティ関連の参照先といった organization-wide な指示が挙げられています。 (GitHub Docs)
| organization に置くと効きやすいもの | 具体例 |
|---|---|
| 返答言語と説明のトーン | ユーザー向け説明は日本語、コード内識別子は原語を維持する |
| セキュリティ時の案内先 | リスクが絡む場合は社内 Security Handbook や専用窓口を優先する |
| レビューの優先順 | セキュリティ、性能、データ整合性、保守性の順で重大度を判断する |
| ドキュメントの最低基準 | 公開 API 変更時は説明文や README 更新も確認する |
| 組織の回答作法 | 抽象論より次のアクションを先に示す |
一方で、プロジェクトのビルド方法、テストコマンド、採用フレームワーク、特定ディレクトリだけの設計ルールは organization ではなくリポジトリ側に置くべきです。GitHub Docs は repository custom instructions を「プロジェクトをどう理解し、変更をどうビルド・テスト・検証するか」を伝える用途として説明しており、cloud agent でも repository-wide instructions が優先されます。 (GitHub Docs)
チームのコーディング規約に効かせるなら「3層」で分ける
チーム標準を Copilot に埋め込むときは、organization だけで完結させるより、スコープで三層に分けたほうが長持ちします。特に GitHub Docs では、organization / repository / path-specific instructions の役割と優先順位が明確に分かれているので、その設計に合わせるのが無理がありません。 (GitHub Docs)
| 層 | 置き場所 | 主な役割 | 入れる内容の例 |
|---|---|---|---|
| 組織共通 | organization custom instructions | 会社全体の既定値 | 回答言語、レビューの優先観点、セキュリティ時の案内先 |
| リポジトリ共通 | .github/copilot-instructions.md | そのリポジトリの標準 | スタック、ビルド手順、テスト方針、命名・例外処理の基本方針 |
| パス・言語別 | .github/instructions/*.instructions.md | 部分最適 | api/** の入力検証、frontend/** の UI 規約、**/*.py の書き方 |
実務で一番ハマりやすいのは、organization に細かい技術ルールを入れすぎて、リポジトリごとの差分を吸収できなくなることです。優先順位は個人 instructions が最上位、その次に path-specific / repository-wide / agent instructions、最後に organization instructions なので、organization は「全社ベースライン」、repo 側は「現場の実装ルール」と切り分けたほうが衝突しにくくなります。 (GitHub Docs)
設定画面のテキストボックスは自由形式ですが、実務では Markdown で見出しを切り、短い箇条書きで書くのが無難です。GitHub Docs でも organization instructions は自然言語で自由に書けるとされ、code review 向けのチュートリアルでは、短く具体的で、見出しと箇条書きで整理した instructions のほうが有効だと説明されています。 (GitHub Docs)
たとえば、organization custom instructions の叩き台は次のように作れます。
## Organization defaults
- ユーザー向けの説明やレビューコメントは日本語で書く。
- セキュリティ上の懸念がある場合は、まず影響範囲と再現条件を説明し、その後に修正案を示す。
- コードレビューでは、セキュリティ、性能、データ整合性、保守性の順で重要度を判断する。
- 組織標準が不明な場合は、社内 Engineering Handbook を参照すべきと案内する。
- 新しい依存関係や外部サービスを勧める場合は、既存標準との整合性にも触れる。この上で、リポジトリ側には実装ルールを置きます。
## Repository defaults
- このリポジトリは Next.js と TypeScript を使う。
- パッケージマネージャーは pnpm を使う。
- 変更提案では `pnpm lint`、`pnpm test`、`pnpm build` を前提に考える。
- 入力値検証は zod を使う。
- ビジネスロジックを変更した場合は単体テスト追加を優先する。さらに、部分ルールは path-specific に切り出します。
---
applyTo: "api/**/*.ts"
---
## API rules
- リクエストボディとクエリは必ず検証する。
- 外部 API 障害時は利用者向けメッセージと内部ログを分離する。
- 例外をそのままレスポンスに返さない。既存のレビュー運用にどう載せるか
organization custom instructions が刺さるのは、新しいルールをゼロから作る場面より、すでに人間が回しているレビュー運用を Copilot に移す場面です。PR テンプレート、レビュアーの口ぐせ、オンボーディング資料、社内ハンドブックに散っているルールを拾い、スコープで振り分けるのが最短です。GitHub Docs でも、code review の instructions は最初から盛り込みすぎず、まずは少数の具体的な指示から始め、実際の PR で検証して増やす進め方が勧められています。 (GitHub Docs)
| 手順 | やること | 判断基準 |
|---|---|---|
| ルールを棚卸しする | PR テンプレート、レビューコメント、設計ガイド、Slack 回答を集める | 複数リポジトリで共通なら organization 候補 |
| 最初の指示を絞る | 最初は 10〜20 個程度の具体的な指示に絞る | 頻度が高く、判断がぶれやすい項目を優先 |
| 置き場所を分ける | organization / repo / path-specific に分配する | ビルド・テスト・言語別は repo 側へ |
| 実 PR で試す | Copilot にレビューを依頼し、効き方を観察する | 見逃し・誤解が多い指示は書き換える |
| 小さく改訂する | 一度に大量修正せず、1 ルールずつ追加・調整する | 何が効いたか追える状態を保つ |
設定そのものは難しくありません。organization 側は Organizations > Settings > Copilot > Custom instructions で追加し、repo 側は .github/copilot-instructions.md や .github/instructions/*.instructions.md を作成します。リポジトリ instructions は保存後すぐに使われ、チャットの応答参照から使われたファイルを確認できます。 (GitHub Docs)
検証では、少なくとも「新機能追加の PR」「バグ修正の PR」「依存関係更新の PR」の 3 パターンで見ると、instructions の効き方が分かりやすくなります。レビュー観点が薄いのか、説明のトーンだけが変わっているのか、repo ルールとの衝突があるのかを切り分けやすいからです。
導入で失敗しやすいポイント
IDE の Copilot まで自動で統一されると思わない
現時点で organization custom instructions が明示的にサポートされているのは、GitHub.com 上の Copilot Chat、Copilot code review、Copilot cloud agent です。VS Code や Visual Studio、JetBrains などの IDE 側は、support matrix 上では repository custom instructions が中心です。開発者が日常的に IDE Chat を使うチームほど、organization だけでなく repo 側の instructions 整備が必要です。 (GitHub Docs)
organization custom instructions を“強制ポリシー”と誤解しない
GitHub Docs は、AI の性質上、Copilot が custom instructions に毎回まったく同じ形で従うとは限らないと明記しています。しかも優先順位は個人 instructions や repository instructions のほうが上です。organization custom instructions は一貫性を高める仕組みであって、厳密なポリシーエンジンではありません。 (GitHub Docs)
長い社内規約をそのまま貼らない
code review 向けドキュメントでは、instructions は短く具体的にし、まずは最小セットから始めることが勧められています。さらに、Copilot code review は custom instruction file の先頭 4,000 文字しか読まず、ファイルが長すぎると品質が落ちやすいとも案内されています。社内標準の全文をそのまま流し込むより、レビューで本当に必要な判断基準へ圧縮したほうが効きます。 (GitHub Docs)
外部リンク任せや抽象論にしない
code review の tutorial では、外部リンクを参照させる指示や、「もっと正確に」「見落とさないで」といった曖昧な指示は有効ではないとされています。Copilot にやってほしいことは、リンク先に飛ばすのではなく、必要な要点を instructions に直接書いたほうが再現性が上がります。 (GitHub Docs)
feature branch にだけ rules を置かない
Copilot code review は、プルリクエストのベースブランチにある custom instructions を使います。つまり、feature branch にだけ instructions を追加しても、その PR のレビューには効かないことがあります。まず main や develop など、レビュー元になるブランチへ反映してから試すのが安全です。 (GitHub Docs)
まずやるべきこと
最初の一歩として現実的なのは、organization custom instructions に全社共通ルールを 5〜10 個だけ入れ、代表的な 1 リポジトリに .github/copilot-instructions.md を追加し、必要なら .github/instructions/*.instructions.md で言語別ルールを切る流れです。とくに code review を改善したいなら、10〜20 個程度の具体的な指示から始め、実際の PR で効き方を観察しながら増やすのが遠回りに見えて最短です。 (GitHub Docs)
GitHub Copilot の organization custom instructions が GA になったことで、Copilot を「個人の便利機能」から「組織の標準をまとわせた開発支援」に一段引き上げやすくなりました。成果が出るのは、ルールを大量投入したときではなく、organization・repository・path-specific の責務を分けて、チームの判断基準をそのまま Copilot に渡せたときです。まずは 1 つの組織標準と 1 つのパイロットリポジトリから始めるのが、失敗しにくい導入方法です。 (The GitHub Blog)
コメント