【実務・中級編】GitHub Copilot Chatの「カスタム・インストラクション」:チーム専用の回答スタイルを作る方法 – バージョン管理・CI/CD活用バイブル

GitHub Copilot Chatの「カスタム・インストラクション」:チーム専用の回答スタイルを作る方法

テックリードの皆さん、日々のコードレビューや設計議論でこんな消耗を感じていないか?

「また新人から『うちのプロジェクトの例外処理、どっちに合わせるんでしたっけ?』って聞かれたぞ…」
「Copilotに聞いたコード、便利だけど微妙にうちのアーキテクチャ(Clean Architecture)の流儀を無視してボイラープレートを吐きやがる…」

AIの能力はもはや疑いようがない。しかし、「汎用的な天才」であるCopilot Chatをそのまま使っているうちは、チーム全体の開発生産性は頭打ちになる。なぜなら、奴は君たちの「暗黙の了解」「プロジェクト固有の規約」「泥臭い歴史的背景」を知らないからだ。

ここで投入するのが、GitHub Copilot Chatの隠しマストアイテム「カスタム・インストラクション(Custom Instructions)」だ。

今回は、リポジトリにただ置くだけでチーム全員のAIを「うちのプロダクトを骨の髄まで理解したシニアエンジニア」へと変貌させる、極限のプロンプトエンジニアリング術を伝授する。

—

1. なぜ「カスタム・インストラクション」なのか?

個人設定でプロンプトをいじっても意味がない。チーム開発において重要なのは「全員が同じ基準のAIアシスタントを召喚できること」だ。

GitHub Copilot Chatは、リポジトリのルートに特定のファイルを配置することで、AIに対するシステムプロンプト(前提条件・制約事項)を自動読み込みする機能を持っている。

これを利用すれば、以下の問題が秒で解決する。

  • チームメンバー全員が、同じコーディング規約に準拠したコードをAIから出力させられる。
  • 「TypeScriptなら型を厳密に」「エラーは必ずResult型で包む」といった設計思想のブレが消滅する。
  • レビュー指摘で何度も繰り返していた「うちではこう書くんだよ」という説明コストがゼロになる。

—

2. 現場で即効性を発揮する設定ファイル構成

まずは、リポジトリのルートに置くべき設定ファイルの全体像を見てほしい。GitHub Copilot Chatは `.github/copilot-instructions.md` というファイルを自動的にコンテキストの最優先事項として読み込む。

以下に、実戦でそのまま使えるベストプラクティス構成を公開する。

実践設定ファイル: `.github/copilot-instructions.md`

GitHub Copilot Custom Instructions for [Project Name]

あなたは、当プロジェクト(TypeScript / Node.js / Clean Architecture採用)のシニアテックリードです。
以下のルール、設計思想、およびコーディング規約を絶対に遵守して回答・コード生成を行ってください。

1. アーキテクチャと設計思想

  • Clean Architectureを厳格に採用しています。依存性の方向は常に外側から内側(Domain層)に向かいます。
  • Domain層はいかなる外部フレームワーク(Express, TypeORM, AWS SDK等)にも依存してはなりません。純粋なTypeScriptのみで記述します。
  • ビジネスロジック内で発生するエラーは、例外(Exceptions)をスローせず、原則として関数型アプローチの `Result` 型(neverthrow等を使用)で返却してください。

2. コーディング規約 (TypeScript)

  • `any` 型の使用は完全禁止です。型推論が不可能な場合は `unknown` を使い、適切に型ガード(Type Guard)を実装してください。
  • すべてのパブリック関数・メソッドには、JSDoc形式で `@throws` を含む詳細なドキュメントを記述してください。
  • 破壊的変更を伴うユーティリティの追加は禁止です。既存の共通関数を流用できるかまず検討してください。

3. テスト駆動・品質

  • コードを生成する際は、必ずJestを用いた単体テスト(Unit Test)のコードも同時に提示してください。
  • テストはモックを多用せず、可能な限り実オブジェクトまたはテストダブル(Stub/Spy)を使用します。

4. 回答のトーンとスタイル

  • 冗長な挨拶や前置きは一切不要です。結論(コードまたは設計判断の理由)から端的に述べてください。
  • セキュリティ脆弱性(SQLインジェクション、XSS、秘匿情報のハードコード等)が含まれている可能性に常に警戒し、検出した場合は警告してください。

このファイルをリポジトリにコミットし、`main`(または `develop`)にマージする。たったこれだけで、チーム全員のIDE(VS Code / JetBrains)上のCopilot Chatが、このプロジェクト専用の厳格な番人へと進化する。

—

3. 開発スピードを劇的に高めるプロのハック&ショートカット

カスタム・インストラクションを導入したら、次はそれを極限まで使い倒すためのキーボードワークと機能を叩き込め。

① インラインチャット(`Cmd + I` / `Ctrl + I`)の爆速活用

わざわざサイドバーを開いてチャットする必要はない。コードを書いているその行でショートカットを叩き、以下のように短く指示を飛ばす。

> 入力例: `このバリデーション関数にカスタムインストラクションのルールを適用してResult型にリファクタリングして`

カスタム・インストラクションが背後で効いているため、「うちのプロジェクト流のResult型」で綺麗に書き換えてくれる。

② `#file` や `#selection` を使った文脈のピンポイント指定

Copilot Chatのポテンシャルを限界まで引き出すには、コンテキストのコントロールが命だ。

  • `#file:src/domain/user.ts` のように特定のファイルを指して、「これと同じドメインルールのバリデーションを新しいエンティティで作って」と指示する。
  • 複雑なロジックを選択した状態で `#selection` を使い、「この部分の計算処理をドメインサービスに切り出すためのインターフェースを定義して」と命じる。

—

4. チームへの導入と運用ルール(ガバナンス)

野良のカスタム・インストラクションを各個人がバラバラに作っては意味がない。これは「チームのインフラ」として管理する必要がある。

1. PRによるレビューの必須化

  • `.github/copilot-instructions.md` の変更は、必ずテックリードまたはアーキテクトの承認を必須とする(CODEOWNERSの設定を推奨)。

2. プロジェクトの進化に合わせたアップデート

  • ライブラリのバージョンアップや設計方針の変更(例:Zodの導入、State管理の変更など)があった場合は、即座にこのファイルを更新する。これを怠ると、AIがレガシーなコードを生成し始める技術負債の温床になる。

—

最後に:AIを「従属させる」のではなく「チームメイトにする」

多くの開発現場では、AIは「ガチャ」のようなものとして扱われている。運が良ければいいコードを書き、悪ければゴミを吐く。

しかし、カスタム・インストラクションを制したチームにおいて、AIはもはやガチャの対象ではない。「プロジェクトのコーディング規約を暗記し、絶対にそれを破らない、文句も言わずに秒でコードを書く超優秀なジュニア・プログラマー」なのだ。

さあ、今すぐ `.github/copilot-instructions.md` を書き、君のチームの開発生産性をネクストステージへと引き上げろ。

タイトルとURLをコピーしました