【エンタープライズ向け】GitHub Copilotを組織仕様にカスタマイズするCustom Instructionsの推奨テンプレートおよび運用方法

はじめに

GitHub Copilotは、開発者の生産性を向上させるAIペアプログラマーとして、多くのエンタープライズ企業で導入が進んでいます。しかし、組織全体でGitHub Copilotを活用する際、「生成されるコードの品質がバラバラ」「プロジェクトのコーディング規約に沿わない提案が多い」「毎回同じ説明をプロンプトに書く必要がある」といった課題に直面することが少なくありません。

これらの課題を解決するのが、Custom Instructions です。Custom Instructionsを適切に設定することで、GitHub Copilotは組織のコーディング規約やプロジェクト固有のルールを理解し、一貫性のある高品質なコードを生成するようになります。

本レポートでは、Custom Instructionsの解説から始め、エンタープライズ企業において効果的に活用するための推奨テンプレートと運用方法を解説します。具体的には、Custom Instructionsの概要と種類、導入によるメリット、効果的な記述方法、そして組織全体での運用・メンテナンス方法について取り上げます。

Custom Instructionsとは何か

Custom Instructionsとは、ユーザーの設定や要件に合わせてGitHub Copilotの動作や応答をカスタマイズするための仕組みです。これは、AIがコード生成や開発タスク処理において、共通のガイドラインやルールを自動的に反映させることを可能にします。

主な目的は、開発者がプロンプトに毎回コンテキストの詳細を追加する手間を省き、カスタム指示によって必要な情報を自動的にGitHub Copilotに提供することです。追加されたコンテキスト情報はチャットのテキストエリアには表示されませんが、GitHub Copilotがより質の高い応答を生成するために利用されます。

この機能を使えば、GitHub Copilotは単なるコード補完ツールから、組織やチームの開発スタイルやプロジェクトのルールを理解した、真のAIペアプログラマーへ成長します。

なぜCustom Instructionsが必要なのか

GitHub Copilotを導入しただけでは、AIは世の中の一般的なベストプラクティスに基づいた提案しかできません。しかし、エンタープライズ開発において求められるのは一般的な正解ではなく 「その組織、そのプロジェクトにおける最適解」 です。

この「一般的な正解」と「組織固有のルール」の乖離は、開発現場において 「生成されたコードの手直し（修正コスト）」と「規約遵守を確認するための目視チェック（レビューコスト）」 という2つの大きな負担を生みます。Custom Instructionsは、AIを組織やプロジェクトのコンテキストに適応させることで、これらの課題を解決するための手段として重要視されています。

プロジェクトやチーム固有の暗黙知を自動で適応

Stack Overflowの2025年調査解説によると、AIツールの利用率が約80%に達する一方で、正確性への信頼度はわずか29%に留まっています。開発者の不満の最大の要因（45%）はこの 「almost right（ほぼ合っているが、そのままでは使えない）」 な出力であり、66%もの開発者がその修正に時間を奪われている と回答しています。

Custom Instructionsに単体テストの書き方、アーキテクチャの制約、ディレクトリ構造、命名規則などを組み込むことで、AIにプロジェクト固有のコンテキストを与えます。

これにより、GitHub Copilotが「一般的な正解」ではなく「自分たちのプロジェクトやチームにおける最適解」を提案するようになり、現場を疲弊させる「almost right」なコードの修正コストを抑えることが可能になります。

レビューコストの削減

エンタープライズ開発において、品質基準の遵守は妥協できない領域です。しかし、GitHub Copilotが生成したコードが自分たちのプロジェクトや組織のセキュリティガイドラインや命名規則に沿っているかを人間が一点ずつチェックしていては、かえってレビュー負荷が増大してしまいます。

Custom Instructionsに、単体テストの記述スタイルやセキュリティ上の禁止事項、関数の命名規則などプロジェクト固有の様々なコンテキスト情報を明文化しておくことで、「ガードレール」としての機能をGitHub Copilotに持たせることができます。

これにより、GitHub Copilotが最初から規約に沿ったコードを生成、あるいは不適切な実装に対してその場で指摘を行うようになります。

結果として、レビュアーは「実装がビジネス要求を満たしているか」「アーキテクチャに破綻がないか」といった、人間が介在すべき本質的な作業に集中できるようになります。

Custom Instructionsの種類

Custom Instructionsには、適用範囲に応じて主に以下の3つの種類があります。

• Personal instructions

  • 適用範囲: GitHub.com上のCopilot Chatでのすべての会話に適用されます。

  • 目的: 個人の好み（優先言語や応答スタイルなど）を指定し、Copilotの応答を個人のニーズに合わせて調整します。

  • 優先順位: すべてのカスタム指示の中で最も高い優先順位を持ちます。

• Repository custom instructions

  • 適用範囲: 特定のリポジトリのコンテキスト内の会話に適用されます。

  • 目的: プロジェクト固有のコーディング標準、フレームワーク、またはツール（例: TypeScriptや特定のライブラリの使用）を定義し、リポジトリへの貢献者全員に対して一貫した応答を保証します。

  • 構成: リポジトリ全体に適用されるファイル（例: リポジトリの.githubディレクトリ内のcopilot-instructions.md）や、特定のファイルやディレクトリに条件付きで適用されるパス固有の指示（*.instructions.mdファイル）など、複数のタイプが含まれます。

• Organization custom instructions

  • 適用範囲: Organizationのコンテキスト内の会話に適用されます。

  • 目的: Organization全体の好み（共通言語やセキュリティガイドラインなど）を強制します。

  • 利用条件: OrganizationオーナーがCopilot BusinessまたはCopilot Enterpriseプランを持つOrganizationで設定可能です。

  • 優先順位: 個人用指示やリポジトリ指示よりも優先順位は低いです。

複数の指示が適用される場合、すべてがCopilotに結合されて提供されますが、競合を避けるために優先順位（個人用 > リポジトリ > Organization）が定められています。

Repository custom instructionsのさらに詳細な分類

Repository custom instructionsは、リポジトリ内での適用範囲に応じてさらに細かく分類できます。

• Repository-wide instructions: リポジトリのルートにある.github/copilot-instructions.mdファイルで指定します。ここに記述された指示は、リポジトリ内のすべてのリクエストに適用される最も基本的な指示です。

• Path-specific instructions: .github/instructions/ディレクトリ内にNAME.instructions.mdという形式のファイルで指定します。ファイルのヘッダーで適用対象のパスを指定することで、特定のディレクトリやファイルタイプ（例：src/components/ 内のTypeScriptファイル）にのみ指示を適用できます。

• Agent instructions: AGENTS.md、CLAUDE.md、GEMINI.mdなどのファイルで指定される指示です。これは、GitHub Copilot coding agentのように、Issueを解決したりプルリクエストを自律的に作成したりできるAIエージェントが使用するためのものです。これにより、エージェントがリポジトリのビルド方法やテスト方法を正確に理解できるようになります。

Galirageで推奨しているCustom Instructionsのテンプレート

GalirageではCustom Instructionsのテンプレートを作成しています。

テンプレート（公開リポジトリ） https://github.com/galirage/gg-template-rules

テンプレートの構成

このテンプレートは、GitHub Copilotに必要な情報を必要な分だけ渡せるように、Instructionの役割ごとにフォルダやファイルを分けて管理しています。

全体像

.github/copilot-instructions.md（Repository-wide instructions）

ここには、どのファイルを触る場合でも守ってほしい基本方針だけを書きます。

• コミュニケーション方針: 返答は日本語、コメント/Docstringも日本語

• 変更範囲の方針: 無関係な変更をしない

• 技術前提の宣言: バックエンドの技術概要（Python/FastAPI/Pydantic/uv、オニオンアーキテクチャ）

• 品質チェックの案内: コミット前に実行するコマンド（lint/test等）を記載

.github/instructions/（Path-specific instructions）

詳細な実装ルールは、ここに用途別、オニオンアーキテクチャの層別で分割して配置しています。 層によってこのように書いて欲しいと言う方針が異なるため、このようにファイルを分けています。 各ファイル先頭の applyTo: によりどのパスに対する指示かを指定しています（例: app/backend/src/domain/**/*.py）。

代表例:

• 全体共通: common.instructions.md（applyTo: ""）

  • DRY/KISS、命名方針、コメントは日本語、Docstring必須、品質チェック、テストはAAAパターン（Arrange/Act/Assert）…など

• バックエンド共通: backend.instructions.md（例: app/backend/**/*.py,app/backend/**/*.toml）

  • 採用バージョン、責務分離、依存関係の原則、Pythonの型ヒント/Docstring方針…など

• オニオンアーキテクチャの層別:

  • backend-domain.instructions.md（domain）: Entity/ValueObjectの方針、検証、Repository抽象…など

  • backend-usecase.instructions.md（usecase）: execute で調停、DI、想定内エラー変換、構造化ログ…など

  • backend-infrastructure.instructions.md（infrastructure）: DB、外部API、ORMとドメインの変換、制約エラー分類…など

  • backend-presentation.instructions.md（presentation）: ルータ・スキーマ、responses、Depends、HTTPステータスコードの変換…など

• 横断的な関心事:

  • backend-error-handling.instructions.md: エラー分類と層間変換のルール

  • backend-logging.instructions.md: print() 禁止、構造化ログ、レベル運用

• テスト: backend-tests.instructions.md

  • 目標カバレッジ、pytest/anyio、AAAパターン、テスト命名は日本語で行う…など

• Git運用: git-commit.instructions.md

  • Conventional Commits、コミット文は日本語、type/scope、よくある誤り…など

.github/prompts/（作業手順を型として呼び出す定型プロンプト）

日常作業の手順を、毎回ゼロから組み立てずに済むように型として配置します。ワークフローのようなイメージです。

• commit-and-push.prompt.md: 品質チェック→差分確認→必要分だけステージ→Conventional Commitsでコミット→main/master直push禁止でプッシュ

• create-pull-request.prompt.md: PRテンプレに沿ってタイトル/本文を組み立て、不足情報（Issue番号など）があれば確認

• create-unit-test.prompt.md: 対象特定→ケース設計→AAAで実装→カバレッジ目安確認

• review-codes.prompt.md: 品質/セキュリティ/保守性の観点を重要度（必須/推奨/任意）で整理

• update-documents.prompt.md: 実装差分とドキュメント差分を突き合わせて更新し、更新点一覧と要約を出す

Custom Instructionsの運用とメンテナンス

Custom Instructionsは一度設定して終わりではありません。プロジェクトのフェーズや技術スタックの進化に合わせて継続的に改善していく必要があります。効果的な運用の鍵は、 「どこに何を記述し、誰がその品質に責任を持つか」 というルールを明確にすることです。

どのようなタイミングでCustom Instructionsを更新すべきか

どのようなタイミングでCustom Instructionsを更新すべきか、チーム内で基準を設けておくと運用がスムーズになります。例として以下のようなトリガーが考えられます。

• 「3回ルール」の適用: 同じ指摘をGitHub Copilotに対して3回以上行ったら、それは個人ではなくチームのルールとして copilot-instructions.md に追加すべきサインです。

• コードレビューのフィードバック: 人間によるレビューで繰り返し指摘される事項（例：エラーハンドリングの漏れ、命名規則違反）は、レビュアーが指摘する前にAIに守らせるべき項目です。これらをInstructionsに反映させることで、レビューの手戻りを防ぎます。

• 技術スタックの変更: ライブラリのバージョンアップや新しいフレームワークの導入時は、その公式ドキュメントや推奨される実装パターンをInstructionsに反映させます。

誰が変更に責任を持つのか

Custom Instructionsの更新は、通常のアプリケーションコードと同様に プルリクエスト（PR）ベース で行います。

「指示を直接書き換える」運用は避けましょう。「改善案をPRとして起票し、チームのレビューと承認を経てマージする」プロセスを徹底することで、指示の矛盾や品質低下を防げます。

このレビュープロセスを確実なものにするために CODEOWNERS 機能を活用し、ガバナンスを自動化します。具体的には、リポジトリのルートや .github/ ディレクトリに CODEOWNERS ファイルを作成し、設定ファイルに対する責任者を割り当てます。

CODEOWNERSによる品質管理のメリット

• 自動レビュー割り当て: Custom Instructionsが変更された際、オーナーが自動的にレビュアーとして追加されます。

• マージブロック: ブランチ保護ルールと組み合わせることで、オーナーの承認（Approve）がない限り、指示内容の変更をマージできないように制限できます。

• 属人化の防止: 誰がそのルールに責任を持っているかが可視化され、議論の場が明確になります。

実例として、OSSのAzure SDK for Goでは、以下のようにCODEOWNERSを用いて、特定のメンテナーがCustom Instructionsの品質を担保する運用を行っています。

"/.github/copilot-instructions.md @richardpark-msft @praveenkuttappan @maririos"

このように、技術的なリーダーやアーキテクトをオーナーに指名することで、GitHub Copilotが常にプロジェクトの正解を提示し続ける「信頼できるガイド」としての品質を維持することが可能になります。

おわりに

本記事では、エンタープライズ開発におけるGitHub Copilot活用の要となる「Custom Instructions」について、その概要から具体的なテンプレートや運用方法までを解説しました。

Custom Instructionsを適切に整備し、CODEOWNERSによるガバナンスを効かせることで、GitHub Copilotは単なるコード補完ツールから、組織やチームの開発スタイルやプロジェクトのルールを理解した、真のAIペアプログラマーへと成長します。これは、日々のコーディング生産性を上げるだけでなく、新しいメンバーがチームにジョインした際のオンボーディングコストを下げることにも直結します。

まずは、.github/copilot-instructions.md を作成し、プロジェクトの基本方針(技術スタック等)を記述するところから始めてみてください。