Github Copilotを標準機能の範囲で賢くしよう

結論

VSCodeでGithub Copilotを賢くするには以下を設定しておきましょう。

• チャットの指示を作成しよう
• カスタムエージェントを作成しよう
• サブエージェントを活用しよう

自分も一度、デフォルト設定でバイブコーディングをしてみて「こんなもんか」と失望したものですが、これらの設定をしておくと実践で使えるレベルになりました。

チャットの指示を作成しよう

役割

フォルダや拡張子単位でCopilotに以下のような前提を加える事ができます。

• リポジトリの全体像を前提や役割
• リポジトリに含まれない外部接続の仕様
• フォルダや拡張子のコーディング規約
• ユースケース

作り方

VSCodeでGithub Copilotのチャットを開くと、右上の⚙️マークから「チャットの指示」で作成を開始します。

---

新しいファイルを作成するか、エージェントの指示を生成するか確認されるので、「新しい命令ファイル」を選びましょう。

「エージェントの指示を生成」では現状のリポジトリの状態を読み取って自動で生成してくれる、という一見素晴らしいことをしてくれるんですが、実際に生成されたものを確認すると正直なところ使い物にならないことが多いです。

というのも自動で生成するのはリポジトリの内容を巨大な1ファイルにまとめます。このような巨大な1ファイルの処理はAIの苦手分野で、どれだけ頑張って傑作を作ったとしても、前提としてのインプットの段階でうまく認識できないからです。

なので、AIで生成するにしても、いきなりすべて任せるよりは後述するような大枠は人手で作って、それを埋めてもらった方が良いです。

---

どこに作成するか確認されるので「.github/instructions」を選択しましょう。

「.github/instructions」ではリポジトリ配下に作成されます。
「ユーザーデータ」はローカルのVSCodeの設定フォルダ内に作成れます。

「ユーザーデータ」に作成すると他のリポジトリで使用できる反面、リポジトリ外に作成されるのでリポジトリとして管理できなくなり、ソースコードとセットで更新できなくなります。
個人開発でリポジトリ管理を行っていない場合など、用途は限定的でしょう。

---

チャットの指示の名前を決めます。わかりやすければ何でも良いですが、最初に作るなら全体の共通設定の定義として common とでも入れておきましょう。

決定すると .github/instructions/<指定した名前>.instructions.md といファイルが出来上がって、エディタで開かれるはずです。

書くべきこと

規約

チャットの指示で決まっていることはたった1つで先頭に以下のように適用対象を記載するだけです。

.github/instructions/common.instructions.md

---
description: リポジトリ全体のガイドラインを提供します。
applyTo: "**/*"
---

設計書のフォルダの役割などを定義するのであれば以下のようなにフォルダを対象にするのが良いでしょう。

.github/instructions/docs.instructions.md

---
description: 設計書を作成する上でのガイドラインを提供します。
applyTo: "docs/**/*"
---

ソースコードに関するコーディング規約を作成したいのであれば、拡張子単位で指定することも可能です。

.github/instructions/python.instructions.md

---
description: Pythonをコーディングする上でのガイドラインを提供します。
applyTo: "**/*.py"
---

チャットの指示はいくつ作ってもいいので、適用したいルールに合わせてどのような applyTo が必要かでファイル分割を進めていきましょう。

指示の詳細

以降に関してはMarkdown形式である以上の規約はないので、前提で指示したいものを記載していきます。
ただ完全にフリーだと何を書いていいかわからないと思うので、書くことを推奨すべき内容を記載しておきます。
以下全てを書く必要はありません。書く必要があることだけ書きましょう。

例

例として、1つのリポジトリにフロントエンド、バックエンドすべて含むYAML/TOML/JSONを相互に変換するツールを作成したとしましょう。
その場合、以下の様なものを作成します。（あくまで例なので必要最低限レベルにとどめています）

.github/instructions/common.instructions.md

---
description: リポジトリ全体のガイドラインを提供します。
applyTo: "**/*"
---

# 概要

ソフトウェアを作成するうえで遵守すべきガイドラインを提供します。

# ユーザーシナリオ

本システムではユーザーがブラウザで入力したYAML/TOML/JSONをバックエンドで他のフォーマットへ変換し、ユーザーへ提供します。

# フォルダ構成

各フォルダは以下の役割を持ちます。

| フォルダ名 | 役割 |
| - | - |
| docs | すべての設計書を格納します |
| frontend | フロントエンドのプロジェクトを格納します |
| backend | バックエンドのプロジェクトを格納します |

# セキュリティ要件

- 通信はすべてTLSで行わなければいけません

.github/instructions/frontend.instructions.md

---
description: フロントエンドのガイドラインを提供します。
applyTo: "frontend/**/*"
---

# フロントエンドガイドライン

## 概要

フロントエンドを作成するうえで遵守すべきガイドラインを提供します。

## ユーザーシナリオ

ユーザーが入力したデータをバックエンドに送信し、変換データしたデータをユーザーに提供します。

## フォルダ構成

フォルダ構成は Atomic Design に従わなければいけません。

## 技術スタック

以下の技術を使用してください。

- TypeScript
- React
- Material UI

## コーディング規約

- 可読性、保守性を最も重視し、次に拡張性を重視してください
- 各ファイルは必ず500行以下とし、推奨は300行以下です
- 各関数、クラス、インターフェースは必ず100行以下としてください
- 型注釈は必須とし、any型の使用は禁止です

.github/instructions/backend.instructions.md

---
description: バックエンドのガイドラインを提供します。
applyTo: "backend/**/*"
---

# バックエンドガイドライン

## 概要

バックエンドを作成するうえで遵守すべきガイドラインを提供します。

## ユーザーシナリオ

REST APIで受信したYAML/TOML/JSON形式のデータを他のフォーマットに変換してします。

## 技術スタック

以下の技術を使用してください。

- Rust
- actix-web

## コーディング規約

- 可読性、保守性を最も重視し、次に拡張性を重視してください
- 各ファイルは必ず500行以下とし、推奨は300行以下です

.github/instructions/docs.instructions.md

---
description: 設計書のガイドラインを提供します。
applyTo: "docs/**/*"
---

# 設計書ガイドライン

## 概要

アプリケーション全体の設計書を作成するうえで遵守すべきガイドラインを提供します。

## フォルダ構成

各フォルダは以下の役割を持ちます。

| フォルダ名 | 役割 |
| - | - |
| docs/frontend | フロントエンドの設計書を格納します |
| docs/backend | バックエンドの設計書を格納します |

# 技術スタック

以下の技術を使用してください。

- Asciidoc
- PlantUML
- OpenAPI

# コーディング規約

- 設計書はAsciidocで作成してください
- 図はPlantUMLで作成してください
- REST APIの仕様はOpenAPIで作成してください
- 各ファイルは必ず500行以下とし、推奨は300行以下です
- 機能単位でファイルを分割し、includeで読み込むことで階層構造を形成してください

概要

数行程度でチャットの指示のファイルの概要を記載すると良いです。
例えば docs フォルダに対するチャットの指示であれば「設計書を記載する上で遵守すべきガイドラインを提供します」などです。

シナリオ/用途

AIの苦手なメタ認知的部分である「このプログラムが利用者のどんな課題をどんなアプローチで解決するか」を明記しましょう。

フォルダ構成

すべてのフォルダに対してチャットの指示を作成するのは現実的でないので、チャットの指示は1,2階層程度にとどめ、以降はフォルダ内に記載しましょう。
また、フォルダにデザインパターンがある場合、どのデザインパターンに従うべきか記載しましょう。

技術スタック

内部で利用しているフレームワークは何を使用するかを列挙しましょう。
利用しているすべてのOSSを記載するわけではなく、コンテキストが大きくなりすぎないようにプログラムの構造を決定づけるもののみに絞り込みましょう。

コーディング規約

ここで言うコーディング規約とはフォーマッタで制御するような機械的なものではなく、コーディングするうえで何を重視するかです。
例えば以下のようなのです。

• 可読性、保守性を何よりも重視し、次に拡張性を重視してください
• 一つの関数は必ず100行未満にして、大きな処理は分割しなければいけません
• 関数内に定数は埋め込まず、必ず外部から受け取らなければいけません

連携元/連携先

リポジトリ外に連携するAPIサーバーやDBが存在する場合、明記しましょう。
一般的に公開されているものでないのであればその仕様等が明記されたドキュメントのファイルパスを記載しましょう。

セキュリティ

満たす必要があるセキュリティ要件を記載しましょう。
通信は必ずTLSで暗号化されている必要がある、などの外部から見えるものだけではなく、コーディングするうえで、ユーザー名、パスワード、セキュリティトークンをソースコードに埋め込んではいけない、なども書いておくと良いでしょう。

カスタムエージェントを作成しよう

役割

デフォルトのAgentからとは異なる別の振る舞いをする特殊なAgentを作成する事ができます。

• ビルドやテストでリポジトリ固有の操作を定義する
• エージェントを特定処理に特化させる

より広い範囲の知識をもち、できることが多いほうがAIの性能が上がると勘違いされることがあります。しかし、基本的にコーディングエージェントのように用途がある程度絞られている場合、知識の範囲を専門化させ、できることが少ないほうが精度は上がります。
そのため、バックエンドもフロントエンドもできるAgentを一つ作るよりはバックエンド用とフロントエンド用でエージェントを作成し、これらを使い分けたほうが出力の精度は向上します。

作り方

VSCodeでGithub Copilotのチャットを開くと、右上の⚙️マークから「チャットの指示」で作成を開始します。

---

新しいカスタムエージェントを作成するか、既存のエージェントを変更するか選択可能なので「新しいカスタムエージェントを作成」を選択します。

PlanはVSCodeの新しいモードのように扱われていますが、実際にはカスタムエージェントです。
なのでここでPlanを選択すると、VSCodeに組み込まれているPlanをカスタマイズすることができます。

---

どこに作成するか確認されるので「.github/agents」を選択しましょう。

「.github/instructions」同様に「.github/agents」ではリポジトリ配下に作成されます。
「ユーザーデータ」はローカルのVSCodeの設定フォルダ内に作成れます。

コーディング用ではなく調査用や事務作業用のリポジトリの内容に紐づかないものは「ユーザーデータ」に作成すると良いでしょう。

---

Agentの名前を作成します。backend や frontend などの役割に応じて作成しましょう。

決定すると .github/agents/<指定した名前>.agent.md といファイルが出来上がって、エディタで開かれるはずです。

エージェントはソフトウェアの機能で分割し、エージェントが保有しなければいけない知識を削減するようにしましょう。
ユーザーシナリオやコーディング、テストなどの工程で分割するとどのエージェントも持たなければ行けない知識があまり減らずに精度が上がりません。
そのため、フロントエンド/バックエンドやAPIインターフェース/DBインターフェースなど専門知識に応じた分割を行いましょう。

書くべきこと

規約

主に指定しなければ行けないのは以下です。

---
description: "バックエンド開発エージェントは、バックエンド関連のタスクを支援します。"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

tools

エージェントが使用可能なツールを選択します。
どのような機能があるかわからなくてもGithub Copilot Chatの拡張機能が入っていれば、以下のように「ツールの構成」からチェックボックスで選択できます。

上記のツールの構成を押すと以下の様に選択することができます。

基本的には組み込みのみを指定し、拡張機能で追加されるものについては必要なもののみを追加しましょう。
これは権限管理の意味合いもありますが、前述した通りAgentはできることが少ないほうが精度は上がります。

model

AgentのAIのエンジンを指定します。
正式名称がわからなくてもGithub Copilot Chatの拡張機能が入っていればサジェストしてくれます。

description

Agentの説明を記載します。
これはカスタムエージェントのプレースホルダーなどに使用されます。

指示の詳細

以降に関してはMarkdown形式以上の規約はないので、前提で指示したいものを記載していきましょう。
ただ完全にフリーだと何を書いていいかわからないと思うので、書くことを推奨すべき内容を記載しておきます。
以下全てを書く必要はありません。書く必要があることだけ書きましょう。

例

.github/agents/frontend.agent.md

---
description: "フロントエンド開発エージェントは、フロントエンド関連のタスクを支援します"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

# フロントエンド開発エージェント

## 役割

このエージェントは、フロントエンド開発に特化したタスクを支援します。
作業内容としては以下のものです。

- コードの生成と修正
- バグの特定と修正
- パフォーマンスの最適化
- ドキュメントの作成と更新
- テストコードの作成と実行

## 行動ルール

役割を実行する場合は以下のルールを遵守してください。

- コードの生成を行った場合、必ず同期して設計書を修正しなければいけません
- コードを生成/修正した場合、必ずテストコードを生成し、テストを正常終了させなければいけません

## ビルド方法

ビルド時は `npm build` を使用してください。

## テスト方法

テスト時は `npm test` を実行してください

## 禁止事項

- `npm dev` を実行するとターミナルに応答がなくなるため、使用してはいけません。
- テストを実行する際はテスト実行コマンドに対して、grep, head, tail などでフィルタリングを直接行わず、`*.log` ファイルに1度出力してからその内容を解析し、必要な情報を抽出してください
- sedなどによるファイルの直接編集は禁止です。コマンドによるファイル編集を行った場合はAgentのキャッシュをクリアし、ファイルを再読込みしてください
- プロジェクトの初期化やパッケージの追加を行う場合は、設定ファイルを直接編集せず、必ずパッケージマネージャーのコマンドを使用してください

.github/agents/backend.agent.md

---
description: "バックエンド開発エージェントは、バックエンド関連のタスクを支援します。"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

# バックエンド開発エージェント

## 役割

このエージェントは、バックエンド開発に特化したタスクを支援します。
作業内容としては以下のものです。

- コードの生成と修正
- バグの特定と修正
- パフォーマンスの最適化
- ドキュメントの作成と更新
- テストコードの作成と実行

## 行動ルール

役割を実行する場合は以下のルールを遵守してください。

- コードの生成を行った場合、必ず同期して設計書を修正しなければいけません
- コードを生成/修正した場合、必ずテストコードを生成し、テストを正常終了させなければいけません

## ビルド方法

ビルド時は `cargo build` を使用してください。

## テスト方法

テスト時は `cargo test` を実行してください

## 禁止事項

- テストを実行する際はテスト実行コマンドに対して、grep, head, tail などでフィルタリングを直接行わず、`*.log` ファイルに1度出力してからその内容を解析し、必要な情報を抽出してください
- sedなどによるファイルの直接編集は禁止です。コマンドによるファイル編集を行った場合はAgentのキャッシュをクリアし、ファイルを再読込みしてください
- プロジェクトの初期化やパッケージの追加を行う場合は、設定ファイルを直接編集せず、必ずパッケージマネージャーのコマンドを使用してください

役割

このエージェントでどのような処理を行うか端的に箇条書しておきます。
記載しておくことで依頼をパターンに当てはめて処理してくれるようになります。

行動ルール

行動するときにどのような手順を踏むかなどを記載しておきます。
より精度を上げるなら役割ごとに手順を記載しておくと良いです。

ビルド方法/テスト方法

ビルド方法やテスト方法はリポジトリにより何を使うかが違うので明記しておきましょう。
テストパターンの絞り込みやログレベルの変更方法などの指定方法、テスト実行前に設定しておくべき環境変数や起動しておくべき環境などがある場合も記載しておきましょう。

禁止事項

エージェントで色々作業していると一般的にはそうすべきでも自身の環境ではしてほしくないことやAIと相性が悪いことが出てきます。
例えばgdbなどをインタラクティブに起動して、dgbを無限に待ち続けるなどですね。
これらを制限するため、記載しておきましょう。

サブエージェントを活用しよう

役割

精度を上げるために作成したカスタムエージェントを他のカスタムエージェントから呼び出し、カスタムエージェント全体をチームのように扱う事ができます。
これによりAIを使うために人間が頑張って処理を振り分ける、という本末転倒を解消します。

本機能は2026年2月現在でPreview機能である runSubagent機能を使用しています。
そのため、今後VSCodeのアップデートにより設定方法が変わる可能性があります。

作り方

通常のカスタムエージェント同様、.github/agents/manager.agent.md といったカスタムエージェントの割り振り専用のカスタムエージェントを作成します。

ただし、通常のエージェントよりも更にできること(tools)を絞り込み、agent/runSubagent のみを指定します。

---
description: "マネージャーエージェントは、プロジェクト管理関連のタスクを支援します"
tools: ["agent/runSubagent"]
model: Claude Sonnet 4.5 (copilot)
---

---

カスタムエージェントからカスタムエージェントを呼び出す機能は現在Preview機能であるため、デフォルトでは無効化されいるので有効化します。
VSCodeの設定を開き、chat.customAgentInSubagent.enabled で検索すれば「Chat > Custom Agent In Subagent: Enable」という設定が見つかると思うので有効化しましょう。

書くべきこと

例

---
description: "マネージャーエージェントは、プロジェクト管理関連のタスクを支援します"
tools: ["agent/runSubagent"]
model: Claude Sonnet 4.5 (copilot)
---

# マネージャーエージェント

## 概要

このエージェントは、プロジェクト管理に特化したタスクを支援します。
作業内容としては以下のものです。

- タスクの分解と各エージェントへの割り当て
- 各エージェントからの応答の統合とレビュー
- 各エージェントの作業結果から他のタスクへのタスクの再分配

## タスクの割り当て

マネージャーエージェントは #tool:agent/runSubagent を使用して、タスクを各専門エージェントに割り当てます。

- フロントエンド関連のタスク
  - agentName - frontend
- バックエンド関連のタスク
  - agentName - backends
- 品質保証関連のタスク
  - agentName - qa
- デプロイメント関連のタスク
  - agentName - deployer
- UXデザイン関連のタスク
  - agentName - ux_designer

## 工程

以下の工程を踏むように、マネージャーエージェントをタスクを分配してください。

### 新機能の作成

1. agentName - ux_designer が新機能のUXデザインを作成する
2. agentName - backend が新機能のバックエンド実装を行う
3. agentName - frontend が新機能のフロントエンド実装を行う
4. agentName - qa が新機能のE2Eテストの実装を行い、検証を行う
5. テストで不具合が見つかった場合は、バックエンド、フロントエンドにフィードバックする
6. agentName - deployer が新機能のデプロイメントを行う

### 障害修正の場合

1. agentName - qa が障害の再現手順を作成する
2. agentName - backend が障害の原因を特定し、修正する
3. agentName - frontend が障害の原因を特定し、修正する
4. agentName - qa が修正されたコードのE2Eテストを実行し、検証する
5. テストで不具合が見つかった場合は、バックエンド、フロントエンドにフィードバックする
6. agentName - deployer が修正されたコードのデプロイメントを行う

タスクの割り当て

どのタスクをどのカスタムエージェントに割り振るかを記載します。
ポイントとしては以下の2点です。

• #tool:agent/runSubagent で呼び出すことを明記すること
• 呼び出す先のカスタムエージェントの agentName を明記すること
  • agentName はカスタムエージェントの作成時に指定した名前です

工程

エージェントに依頼したい内容がある程度パターン化されているのであれば事前にそのパターンの工程を記載しておくと質の高いタスク振り分けになります。

特にエージェントは何も指示しなければテストを構築、実施してくれることは稀です。
工程の中にテストを組み込み、サイクルを回す仕組みを明示したほうがより品質の高いソフトウェアが出来上がります。

アンチパターン

上述の設定を行うことでCopilotのAgentはデフォルトに比べると大分ユーザーの想像に近い形で動作してくれます。
しかし以下のようなアンチパターンを踏むと、うまく動いてくれなかったり、運用が破綻しやすいです。

曖昧に書く

以下のような日本語的文言はCopilotに意図が伝わらないので避けましょう。

• ～～する必要はありません
• ～～するのは避けてください

人間に使うと少しきつめと取られるような文言で明確に「遵守してください」「禁止です」と記載しましょう。

完璧を求める

これらの設定ファイルを作成しようとしたとき、最初から完璧にすべてを埋めようとすると頓挫しがちです。
最初は2,3ファイル、1ファイル100行程度から始めて、いくつかプロンプトを実行し、うまく動かなかったところを徐々に補足、追記していきましょう。

書きすぎる

これらのファイルを1ファイル、1000行くらい大量に書いてもCopilotにはコンテキストが大きくなりすぎ、認識できなくなります。
実際の検証結果があるわけではないですが、長くても500行程度、300行未満が推奨、くらいの感覚です。

細かな仕様等については設計書などに起こして、「～～の場合はxxに存在する設計書を参照すること」のようなルールにしましょう。

副次的効果

気づかれた方もいらっしゃると思いますが、これらのAIを賢く動かすための設定はAIだから必要なのではなく、チームに人間の新しいメンバーが入ってきても必要なインプットです。

すでにこれらがまとまっているチームは既存のドキュメントを移管するだけでAIの精度は上がりますし、ドキュメントがないチームは暗黙知を明文化することが可能になります。
たとえこれでAIが賢くならなかったとしても、チームは明文化されたリポジトリのルールを手に入れるという最低限の成果を手に入れることができます。

もっと賢くしよう

ここに記載された内容以外にも以下の設定を行うとより賢くなります。
自身の環境にマッチするかを検討して導入してみてください。

Skills

agentに記載したビルド方法やテスト方法を分離し、共通の方法として定義することができます。
機能単位でカスタムエージェントを分割した際は、共通の方法として定義できるので便利です。

逆にエージェント単位で他のことをやらせたい場合、他のエージェントで使用する知識も入ってしまうので、混同してコンテキストが大きくなる場合もあります。
リポジトリ内にバックエンドとフロントエンドの両方が入っていたり、複数言語で作成されるような複数の技術要素が絡む場合は扱いに注意しましょう。

Hooks

セッションやプロンプト、コマンドの実行前後などをフックにしてコマンドを実行することができます。
テストなどで環境変数の指定などが必要な場合などに定義すると良いです。

MCPサーバー

役割としては大きく以下の2つです。

• リアルタイム専門書
  • Microsoft Learn MCP Serverなど特定のプロダクトの最新情報やFigma MCP Serverなどのクローズドな空間で定義した情報をCopilotが参照したい場合に使用します
• AI専用のツール窓口
  • Atlassian Rovo MCP ServerでJIRAのチケットを作成するように外部に対してCopilotから直接作業が依頼できるようになります

これらを利用するうえで気をつけなければ行けないのが、MCPサーバーはCopilot外なので例えCopilotでプロンプトを学習させないように設定していたとしても、MCPサーバーを指定しているとそちらで学習される可能性があります。
なのでMCPサーバーを利用する際はMCPサーバーのプライバシーポリシーなどを確認したうえで使用しましょう。
特に企業内で利用する場合はソースコードなどの流出に繋がる可能性があるので注意が必要です。