【2026年4月最新】GitHub Copilot × VS Code Chat 完全攻略ガイド — 基礎から応用テクニックまで
はじめに
GitHub Copilotは、もはや「コード補完ツール」ではありません。2026年4月現在、VS Codeはエージェント駆動のAI開発プラットフォームへと進化し、ほぼすべてのCopilot操作がエージェンティック（agentic）に統合されました。
本記事ではVS Code Chatを中心に、「これ1本で基礎から応用まで全部わかる」をテーマに、筆者が実務で培ったナレッジを体系的にまとめます。特にカスタムインストラクションの設計思想、マルチエージェントオーケストレーターの試行錯誤、そして自己改善ループによるナレッジ蓄積など、公式ドキュメントだけでは見えてこない実践知にも踏み込みます。
0. 最初の一歩 — インストールとセットアップ
ここではGitHub Copilotを使い始めるまでの手順を説明します。すでに使っている方は読み飛ばしてください。
Step 1: プランを選ぶ
| プラン | 料金 | 主な特徴 |
|---|---|---|
| Free | $0 | 月2,000回の補完 + 50回のプレミアムリクエスト。お試しに最適 |
| Pro | $10/月 | 無制限の補完 + 300回のプレミアムリクエスト。個人開発者の定番 |
| Pro+ | $39/月 | 1,500回のプレミアムリクエスト + 全モデルアクセス。ヘビーユーザー向け |
| Business | $19/ユーザー/月 | IP補償 + 組織管理。企業向け |
| Enterprise | $39/ユーザー/月 | Business + ナレッジベース + カスタムモデル |
Step 2: VS Code に Copilot をインストール
- VS Code をインストール（すでに入っている方はスキップ）
- VS Code を起動し、拡張機能パネル（
Ctrl+Shift+X）を開く - 「GitHub Copilot Chat」を検索してインストール
- 旧「GitHub Copilot」拡張機能は非推奨になっています。Copilot Chat のみで OK です
- VS Code の左下にある人型アイコンから GitHub アカウントでサインイン
- Copilot のサブスクリプションがないアカウントの場合、自動的に Free プランにサインアップされます
Step 3: 最初の体験
- チャットを開く:
Ctrl+Alt+I（Mac:Ctrl+Cmd+I） - 何か聞いてみる: 「JavaScriptで配列の重複を除去する方法を教えて」
- インライン補完を試す: 適当なファイルを開いてコードを書き始める → 薄いグレーの候補が表示されたら
Tabで確定
これだけで Copilot を使い始められます。ここからは、この体験を何倍にも引き上げるためのテクニックを解説していきます。
1. Copilot Chat の全体像 — エージェント中心のアーキテクチャ
現在のモード構成
VS Code の Chat view では、エージェントドロップダウンからペルソナ（役割）を選択します。以前は Ask / Edit / Agent の3モードでしたが、現在は以下の構成に変わっています。
| エージェント | 用途 | 特徴 |
|---|---|---|
| Agent | 自律的タスク実行（デフォルト） | ファイル探索・編集・コマンド実行・自己修正を自動で行う |
| Plan | 実装計画の策定 | コードは変更せず、構造化された計画を生成 |
| Ask | 質問・調査 | コード変更なし。概念理解やブレストに最適 |
| カスタムエージェント | 独自定義のペルソナ |
.agent.mdで自由に定義可能（後述） |
使い分けの判断基準
初心者の方は最初にこの判断基準を意識するだけで、Copilotの体験が大きく変わります。
「G1GCのRemarkフェーズが遅い原因を教えて」 → Ask
「JDK21移行の影響範囲と修正計画を出して」 → Plan
「OAuth2.0のリフレッシュトークン処理を実装して」 → Agent
「セキュリティ＆パフォーマンス観点でレビューして」 → カスタムエージェント
初心者が陥りがちなミス: 単純な質問にAgent modeを使ってしまうこと。Agentはファイルを探索しにいくのでレスポンスが遅くなるうえ、プレミアムリクエストを余計に消費します。「コードを変更してほしいのかどうか」を判断基準にしましょう。
権限レベル — Agent modeの自律性をコントロール
Agent modeでは、セッションごとに権限レベルを選択できます。
| レベル | 挙動 | 推奨シーン |
|---|---|---|
| Default | ツール実行・ターミナルコマンドの都度、確認を求める | 初めてのタスク、慎重に進めたい場面 |
| Bypass Approvals | 特定のツールを自動承認 | 繰り返し実行するタスク |
| Autopilot (Preview) | すべて自動承認。エラー時の再試行も自動 | 信頼できるカスタムエージェントとの組み合わせ |
2. コンテキストの与え方 — Copilotの回答品質を決める最重要スキル
Copilotの回答品質は**「どれだけ的確なコンテキストを渡せるか」**で決まります。これは初心者も上級者も変わりません。
コンテキスト変数一覧
チャット入力時に # を入力すると利用できます。
| 変数 | 説明 | 使用例 |
|---|---|---|
#file |
特定ファイルを参照に追加 | #file:src/auth/AuthService.java |
#selection |
エディタで選択中のコード | コードを選択してからチャットへ |
#editor |
現在開いているエディタの表示内容 | 今見ているコードについて質問 |
#codebase |
ワークスペースのセマンティック検索 | プロジェクト全体から関連コードを探索 |
#git |
Gitの変更差分 | 「この変更のレビューをして」 |
#problems |
問題パネルのエラー・警告 | 「このエラーを修正して」 |
#terminalSelection |
ターミナルの選択テキスト | ビルドエラーの解析 |
#fetch |
Webページの内容を取得 | ライブラリのドキュメント参照 |
#codebase の進化
#codebase は純粋なセマンティック検索ツールに刷新されました。以前はローカルインデックスとリモートインデックスが分かれていましたが、現在は単一の自動管理インデックスに統合されています。数十万ファイル規模のコードベースでも高速かつ一貫した結果を返します。
Agent modeでは、Copilotが必要に応じて自動的に #codebase を呼び出すため、明示的に指定しなくても関連ファイルを見つけてくれます。ただし、Askモードでは明示的に #codebase を指定しないとワークスペース検索は行われないので注意してください。
実践テクニック — プロンプトのBefore / After
❌ 悪い例 1: コンテキスト不足
ログイン機能を作って
→ プロジェクトの技術スタックもわからず汎用的なコードが生成される
✅ 良い例 1: ファイル参照で具体化
#file:src/auth/AuthService.java を参考に、
OAuth2.0のリフレッシュトークン処理を追加してください。
エラーハンドリングは #file:src/common/ErrorHandler.java の
パターンに従ってください。
❌ 悪い例 2: 要求が曖昧
このコード直して
✅ 良い例 2: 問題と期待を明確化
#selection のコードで、fetchUser が null を返した場合に
NullPointerException が発生します。
Optional<User> を使って安全に処理するようリファクタリングしてください。
戻り値の型も合わせて変更してください。
❌ 悪い例 3: テスト生成の丸投げ
テスト書いて
✅ 良い例 3: テスト方針を明示
#file:src/service/UserService.java のユニットテストを生成してください。
## テスト方針
- JUnit 5 + Mockito + AssertJ を使用
- 正常系: ユーザーが正常に登録されるケース
- 異常系: メールアドレスが重複した場合に BusinessException が投げられるケース
- 境界値: 名前が空文字・null・最大長（255文字）のケース
- メソッド名: should_期待結果_when_条件（英語）
ポイント: ファイルのドラッグ&ドロップ、コードシンボルのコピー&ペーストでもコンテキスト追加が可能です。画像やスクリーンショットの添付にも対応しているので、UIの修正指示に「こう直して」とスクリーンショットを添えるような使い方もできます。
3. Agent Mode 徹底活用
Agent modeはCopilotの真骨頂です。計画→実行→検証→修正のループを自律的に回します。
Agent modeが使うツール
Agent modeは内部的に以下のツールを自動で使い分けます。
- ファイル編集: コード変更の提案・自動適用
- ターミナルコマンド: パッケージインストール、ビルド、テスト実行
- コードベース検索: 関連ファイルの自動探索（セマンティック検索含む）
- ブラウザ: Webページの取得、統合ブラウザデバッグ（v1.112〜）
- MCP サーバー: 外部サービス連携（後述）
効果的なプロンプト — 実践例集
例1: API実装（構造化プロンプト）
以下の要件でREST APIエンドポイントを実装してください。
## 要件
- POST /api/users でユーザー作成
- バリデーション: メールアドレス形式チェック、名前は必須
- エラーレスポンスは RFC 7807 Problem Details 形式
- 既存の #file:src/common/BaseController.java を継承
## 制約
- Spring Boot 3.x + JDK 21
- テストは JUnit 5 + MockMvc で作成
- 既存のコーディング規約に従うこと
## 進め方
実装前にファイル構成の計画を提示してください。
承認後に実装を開始してください。
例2: リファクタリング（段階的アプローチ）
#file:src/service/OrderService.java をリファクタリングしてください。
## 問題
- processOrder メソッドが200行を超えている
- バリデーション・計算・永続化・通知が1メソッドに混在
## 方針
- 単一責任原則に基づいて private メソッドに分割
- 各メソッドは30行以内
- 既存のテストが全て通ることを確認してからコミット
まず現在の構造を分析し、分割案を提示してください。
例3: バグ調査（コンテキストを最大活用）
本番環境で以下のエラーが発生しています。
## エラーログ
#terminalSelection
## 調査依頼
1. #codebase からエラーの発生箇所を特定してください
2. 根本原因を分析してください
3. 修正案を提示してください（修正はまだ適用しないで）
4. 同様の問題が他の箇所にないか横展開調査してください
チェックポイントとUndo
Agent modeでファイル変更が行われると、自動的にチェックポイント（スナップショット）が作成されます。Agentが暴走したと感じたら、チャット上のチェックポイントから「Restore」を選択するだけで即座にロールバックできます。
コツ: 大きな変更の前に「まず計画を提示して」と指示する癖をつけると、チェックポイントに頼る場面が減ります。もしくはPlanエージェントで計画→Agentにハンドオフという流れも有効です。
4. インライン補完とNext Edit Suggestions（NES）
従来のインライン補完
タイプ中にゴーストテキスト（薄いグレーの候補）が表示されます。Tab で確定、Esc で却下です。
-
部分確定:
Ctrl + →で1単語ずつ、Ctrl + ↓で1行ずつ確定可能 - 特定言語だけインライン補完をオフにすることもできます（Markdownを書くときにゴーストテキストが邪魔な場合など）
Next Edit Suggestions（NES）— Tab連打の新体験
NESは**「次にどこを編集するか」を予測**する、Copilotチームが独自に訓練した専用モデルによる機能です。従来の補完がカーソル位置の続きを予測するのに対し、NESはファイル内の別の場所の編集まで提案します。
活用シーン:
- クラス名を
Point→Point3Dに変更 → 関連するプロパティ・メソッドの変更を自動提案 - 変数のリネーム → ファイル内の他の箇所も自動的に提案
- コピペしたコードを周囲のスタイルに合わせる変更を提案
- タイポの検出と修正提案、ロジックの論理ミス（
&&と||の取り違えなど）の検出
設定: github.copilot.nextEditSuggestions.enabled を有効化
ガターに矢印アイコンが表示されたら Tab で移動 → もう一度 Tab で確定。Tab連打でリファクタリングが完了する体験は、地味ですが一度味わうとやめられません。
5. インラインチャット — エディタから離れない編集
Ctrl+I（Mac: Cmd+I）でエディタ内に直接チャットを開けます。Chat viewを開くほどではない小さな修正に最適です。
使いどころの例:
// コードを選択して Ctrl+I →
「このメソッドにJavadocを追加して」
「nullチェックを Optional に書き換えて」
「この条件分岐を早期リターンに変えて」
「このfor文をStream APIに変換して」
ターミナル上でも Ctrl+I でインラインチャットが使えます。「このコマンドの結果をJSONでパースするワンライナーを教えて」のような使い方ができます。
6. カスタムインストラクション — Copilotを「チームの一員」にする
ここからが中級者→上級者への分岐点です。
なぜインストラクションが重要なのか
インストラクションの種類と優先度
個人インストラクション（最高優先度）
↓
リポジトリインストラクション（.github/copilot-instructions.md）
↓
組織インストラクション（Enterprise設定）
すべてのレベルのインストラクションが結合されてモデルに渡されます。矛盾がある場合は優先度の高いものが勝ちますが、非決定的な動作になる可能性があるため、矛盾するルールは書かないことが重要です。
/init でプロジェクトをAI最適化する
チャットで /init と入力すると、Copilotが以下を自動実行します。
- 既存の
copilot-instructions.mdやAGENTS.mdを検出 - プロジェクト構造とコーディングパターンを分析
- プロジェクトに最適化されたカスタムインストラクションを生成
まだ copilot-instructions.md がないプロジェクトでは、最初にこれを実行しましょう。ゼロから書くより遥かに効率的です。生成されたものをベースに、チーム固有のルールを追記していくのがおすすめです。
インストラクション設計の鉄則
筆者が試行錯誤の末にたどり着いた、効果的なインストラクション設計のポイントです。
鉄則1: 「なぜ」を書く
理由を添えると、エッジケースでの判断精度が格段に上がります。AIは「なぜそのルールが存在するか」を理解することで、ルールに書かれていない類似ケースにも正しく対応できるようになります。
❌ moment.js を使わないこと
✅ moment.js ではなく date-fns を使うこと（moment.js は非推奨で、バンドルサイズが大きいため）
❌ PowerMock は禁止
✅ モックは Mockito を使用。PowerMock は禁止
理由: PowerMockはstatic mockでテストの信頼性を下げ、JDK17以降で互換性問題が発生するため
鉄則2: 具体的なコード例を添える
抽象的なルールだけでは、AIの解釈にブレが出ます。
## エラーハンドリング
業務例外と基盤例外を区別すること。
### 良い例
✅ throw new BusinessException(ErrorCode.USER_NOT_FOUND, "ユーザーが見つかりません: " + userId);
✅ throw new SystemException("外部API接続エラー", cause);
### 悪い例
❌ throw new RuntimeException("エラー");
❌ throw new Exception(e.getMessage());
鉄則3: 簡潔に保つ
インストラクションが長すぎると、モデルのコンテキストウィンドウを圧迫し、逆に指示が無視されやすくなります。1つのインストラクションは1つの明確な文にしましょう。標準的なリンター/フォーマッターが強制するルールはインストラクションに書く必要はありません。
.github/copilot-instructions.md の実践例
# プロジェクト共通ルール
## 言語・フレームワーク
- バックエンド: Java 21 + Helidon MP
- フロントエンド: Vue.js 3 (Composition API) + TypeScript
- テスト: JUnit 5 + Mockito + AssertJ (バックエンド), Vitest (フロントエンド)
- ORM: JPA (Hibernate) on Oracle Database
## コーディング規約
- メソッド名は動詞で始める（例: fetchUser, validateInput, calculateTotalAmount）
- 例外は業務例外（BusinessException）と基盤例外（SystemException）を区別する
理由: 障害調査時にログレベルとアラートの切り分けが即座にできるため
- DTO ↔ Entity の変換には MapStruct を使用する
理由: 手書き変換コードの保守コスト削減とコンパイル時の型安全性確保のため
- SQL文のハードコーディング禁止。JPA Criteria API または Native Query を使用
## テスト方針
- テストメソッド名: should_期待結果_when_条件（例: should_throwException_when_emailIsInvalid）
- Arrange-Act-Assert パターンで構造化
- テストデータはテストメソッド内で完結させる（共有フィクスチャ禁止）
理由: テスト間の依存を排除し、テストの独立性を担保するため
- モックは Mockito を使用。PowerMock は禁止
## コメント・ドキュメント
- Javadoc は public メソッドに必須
- TODO コメントには起票者名と日付を記載（例: // TODO(handa 2026-04-13): リファクタ対象）
パス固有インストラクション（.instructions.md）
プロジェクト全体のルールとは別に、特定のファイルやディレクトリにだけ適用するルールを定義できます。copilot-instructions.md が肥大化するのを防ぐ重要な仕組みです。
---
applyTo: "src/api/**/*.java"
---
# API層のルール
- Controller は BaseController を継承すること
- リクエスト/レスポンスDTOは record 型で定義
- バリデーションは Jakarta Bean Validation アノテーションを使用
- エンドポイントには @Operation (OpenAPI) アノテーションを必ず付与
---
applyTo: "**/*.vue"
---
# Vue.js コーディングルール
- script setup 構文を使用
- コンポーネント名は PascalCase
- emit は defineEmits で型定義必須
- props は withDefaults + defineProps で定義
- Composition API の composables は use プレフィックス（例: useAuth, useFetch）
---
applyTo: "**/*.test.ts"
---
# フロントエンドテストルール
- テストフレームワークは Vitest を使用
- describe ブロックでテスト対象のコンポーネント/関数名を記述
- it ブロックは英語で振る舞いを記述
- Vuex の store は createMockStore ヘルパーを使用してモック化
AGENTS.md / CLAUDE.md / GEMINI.md
AGENTS.md をリポジトリルートに配置すると、copilot-instructions.md と同等の「常時適用」インストラクションとして機能します。VS Codeは AGENTS.md, CLAUDE.md, GEMINI.md をワークスペースルートから自動検出します。
複数のAIエージェント（Copilot、Claude Code、Gemini CLI等）を併用する場合は、AGENTS.md に共通ルールを書き、各ツール固有のルールは個別ファイルに分けると管理しやすくなります。
7. プロンプトファイル（.prompt.md）— 再利用可能なワークフロー
プロンプトファイルはよく使うプロンプトをMarkdownで定義して、スラッシュコマンドとして呼び出せる機能です。チームで共有すれば、プロンプトの品質を属人化させずに標準化できます。
ファイル構成
.github/
prompts/
create-api.prompt.md
write-tests.prompt.md
code-review.prompt.md
fix-bug.prompt.md
実例: テスト生成プロンプト
---
agent: 'agent'
description: '対象クラスのユニットテストを生成する'
tools: ['search/codebase', 'vscode/editFiles']
---
# テスト生成ガイドライン
対象のクラスに対するユニットテストを生成してください。
## テストフレームワーク
- Java: JUnit 5 + Mockito + AssertJ
- TypeScript: Vitest
## テスト設計方針
- 正常系・異常系・境界値の3パターンを必ず網羅
- テストメソッド名: should_期待結果_when_条件
- Arrange-Act-Assert パターンで構造化
- テストデータはテストメソッド内で完結させる（共有フィクスチャ禁止）
## 参照
- テストユーティリティ: [TestHelper](../src/test/util/TestHelper.java)
- テストの書き方ガイド: [testing-guide](../docs/testing-guide.md)
実例: バグ修正プロンプト
---
agent: 'agent'
description: 'バグの調査と修正を体系的に行う'
tools: ['search/codebase', 'vscode/editFiles', 'vscode/runCommand']
---
# バグ修正ワークフロー
## Step 1: 調査
- エラーメッセージからスタックトレースを分析
- #codebase で関連コードを特定
- 根本原因を特定し、仮説を提示
## Step 2: 修正
- 最小限の変更で修正する
- 既存のコーディング規約に従う
## Step 3: 検証
- 修正に対するユニットテストを追加
- 既存テストが全てパスすることを確認
- 同様の問題が他の箇所にないか横展開調査
## Step 4: 報告
修正内容のサマリーを以下の形式で出力:
- **原因**: 根本原因の説明
- **修正内容**: 変更したファイルと内容
- **テスト**: 追加したテストの概要
- **横展開**: 同様のリスクがある箇所の有無
チャットで /fix-bug と入力するだけで、この体系的なワークフローが実行されます。
活用のコツ:
-
${input:variableName:プレースホルダー}構文でユーザー入力を促せる -
/create-promptで進行中の会話からプロンプトファイルを自動生成できる - Markdownリンクでワークスペース内のファイルを参照可能（例:
[設計書](../docs/design.md)）
8. カスタムエージェント（.agent.md）— AIにペルソナを与える
旧称「Chat Modes（.chatmode.md）」から名称変更された機能です。特定の役割を持つAIペルソナを定義でき、ツール制限・モデル指定・ハンドオフまで設定可能です。
基本構造
---
name: エージェント名
description: 説明文
tools: ['使用可能なツール']
model: ['優先モデル', 'フォールバックモデル']
handoffs:
- label: "ボタンラベル"
agent: 遷移先エージェント
prompt: "遷移時のプロンプト"
send: false
---
# ここにインストラクション本文（Markdown）
実例: コードレビューエージェント
---
name: Reviewer
description: セキュリティとパフォーマンスに特化したコードレビュー
tools: ['search/codebase', 'search/usages', 'web/fetch']
model: ['Claude Sonnet 4.5', 'GPT-5.4']
handoffs:
- label: "修正を実装"
agent: agent
prompt: "上記のレビュー指摘を修正してください"
send: false
---
# コードレビュー指針
あなたはシニアエンジニアとしてコードレビューを行います。
コードの変更は一切行わず、レビューコメントのみを出力してください。
## レビュー観点（優先度順）
1. **セキュリティ**: SQLインジェクション、XSS、認証・認可の不備
2. **パフォーマンス**: N+1問題、不要なループ、メモリリーク
3. **保守性**: 単一責任原則の違反、マジックナンバー、命名
4. **テスタビリティ**: DIの欠如、密結合、テスト困難な設計
## 出力形式
各指摘事項は以下の形式で記載:
- 🔴 Critical / 🟡 Warning / 🔵 Suggestion
- 該当コードの場所
- 問題の説明
- 改善案（コード例付き）
レビュー完了後に「修正を実装」ボタンが表示され、ワンクリックでAgent modeに切り替わります。
9. 【応用】マルチエージェントオーケストレーター — 筆者の試行錯誤
ここからは筆者が実際に構築・運用したマルチエージェントオーケストレーターパターンを、成功も失敗も含めて共有します。
基本構成
筆者のプロジェクトでは、以下のエージェント構成を基本としました。
orchestrator.agent.md（オーケストレーター）
├── java-researcher.agent.md ← 調査・設計
├── java-coder.agent.md ← Java実装
├── java-reviewer.agent.md ← Javaコードレビュー
├── frontend-coder.agent.md ← Vue.js/TypeScript実装
├── frontend-reviewer.agent.md ← フロントエンドレビュー
└── quality-reviewer.agent.md ← 横断的な品質チェック
オーケストレーターがタスクを受け取り、適切なサブエージェントにハンドオフで委譲する設計です。
ハマったポイント① — サブエージェントがオーケストレーターの指示を無視する
最初に直面した問題がこれでした。オーケストレーターが「Javaの実装だけやって」と委譲しているのに、サブエージェントが勝手にフロントエンドのコードまで変更してしまうケースが発生しました。
原因: サブエージェントのインストラクションにスコープの制約が明確に書かれていなかったこと。エージェントは与えられたツール（ファイル編集等）を使える限り、良かれと思って越権行為をします。
解決策: 各サブエージェントに「何をしてはいけないか」を明示的に書く。
---
name: JavaCoder
description: Javaバックエンドの実装に特化
tools: ['search/codebase', 'vscode/editFiles']
---
# Java実装エージェント
## 担当範囲
- src/main/java/ 配下の Java ファイルのみ
- テストは src/test/java/ 配下のみ
## 禁止事項
- フロントエンド（*.vue, *.ts, *.tsx）ファイルの編集は絶対に行わないこと
- pom.xml への依存追加は提案のみ行い、実際の編集はしないこと
- データベースのマイグレーションファイルの作成・編集は行わないこと
## 完了時
実装が完了したら、変更内容のサマリーを出力して終了すること。
ハマったポイント② — サブエージェント間のコンテキスト引き継ぎ
2つ目の問題は、オーケストレーターからサブエージェントAに委譲し、完了後にサブエージェントBに委譲したとき、AがやったことをBが知らないという問題でした。
原因: ハンドオフでエージェントが切り替わると、前のエージェントの会話コンテキストが引き継がれない場合がある。
解決策: 各サブエージェントに成果物をファイルに書き出すルールを定義する。
## 完了時の成果物出力
実装が完了したら、以下の情報を docs/agent-output/ に Markdown で出力すること:
- 変更したファイルの一覧と変更概要
- 追加した公開APIの一覧（メソッドシグネチャ）
- 後続の実装者への引き継ぎ事項
こうすることで、次のエージェントがファイルを参照して前工程の結果を把握できます。
ハマったポイント③ — トークン消費が肌感と合わない
エージェントを細かく分けすぎた結果、オーケストレーターが各エージェントのインストラクションを全部読み込むため、肝心のコード生成に使えるコンテキストウィンドウが圧迫されるという問題に直面しました。
解決策: エージェントの粒度を見直す。
❌ 過度に細かい分割（7エージェント）
orchestrator → researcher → designer → coder → tester → reviewer → documenter
✅ 適度な粒度（4〜5エージェント）
orchestrator → java-coder → frontend-coder → quality-reviewer
学び: エージェントの数は「多ければ良い」わけではありません。各エージェントの責務が明確で、かつインストラクションの総量がコンテキストウィンドウを圧迫しない程度に収まるバランスが重要です。筆者の経験では4〜5エージェントが実用的な上限でした。
高度な設定オプション
user-invocable: false # ドロップダウンに非表示（サブエージェント専用）
disable-model-invocation: true # 他エージェントからの自動呼び出しを禁止
サブエージェントは user-invocable: false を設定して、ユーザーが直接呼び出せないようにするのがおすすめです。オーケストレーター経由でのみ利用させることで、意図しない単体利用を防げます。
10. 【応用】自己改善ループ — 使えば使うほど賢くなるCopilot
筆者が最も効果を実感しているのが、ナレッジ蓄積による自己改善ループパターンです。
仕組み
エージェントのワークフローに「学んだことをファイルに記録する」ステップを組み込むことで、Copilotが同じ失敗を繰り返さなくなります。
Plan（計画）
→ Implement（実装）
→ Review（レビュー）
→ Test（テスト実行）
→ Coverage 確認
→ Knowledge 記録 ← ここがポイント
実装方法
インストラクションまたはカスタムエージェントに、以下のようなナレッジ記録ルールを追加します。
## 自己改善ルール
タスク完了時に、以下の条件に該当する場合は docs/knowledge.md に学びを追記すること:
1. 実装中にエラーが発生し、自己修正した場合
→ 「何が原因で」「どう解決したか」を記録
2. レビューで指摘された問題パターンを発見した場合
→ 再発防止のためのルールを記録
3. プロジェクト固有の制約を新たに発見した場合
→ 制約の内容と対処法を記録
### knowledge.md のフォーマット
- 日付、カテゴリ（Bug/Pattern/Constraint）、内容
- 既存エントリと重複する場合は追記しない
docs/knowledge.md の例
# プロジェクトナレッジベース
## 2026-04-10 [Bug] WebLogicのJDBC fetchSize問題
WebLogicのJDBCラッパーは `setFetchSize()` を無視する。
大量データ取得時は Native CURSOR + FETCH文を使うこと。
参照: src/infrastructure/CursorBasedReader.java
## 2026-04-08 [Pattern] Helidon MPのDI スコープ
HK2のRequestScopedサービスはWeakReferenceを大量生成し、
G1GCのRemark STWスパイクの原因になる。
Singletonスコープへの統一が推奨。
## 2026-04-05 [Constraint] Oracle DB の VARCHAR2 上限
Oracle の VARCHAR2 は最大4000バイト（AL32UTF8の場合は実質1333文字）。
これを超えるテキストは CLOB 型を使用すること。
なぜこれが効くのか
docs/knowledge.md はワークスペース内のファイルなので、Copilotが #codebase やファイル検索で自動的に参照します。つまり、過去の失敗や発見がCopilotのコンテキストに自然に組み込まれるのです。
筆者のプロジェクトでは、このナレッジファイルの導入後、同じ種類のバグの再発率が目に見えて減りました。特にプロジェクト固有の制約（特定のミドルウェアの癖、DBの制約など）は公式ドキュメントにもStack Overflowにも載っていないことが多く、自前でナレッジを蓄積する価値が非常に高いです。
使えば使うほど knowledge.md が育ち、Copilotが賢くなる — この好循環が、自己改善ループの本質です。
11. MCP（Model Context Protocol）— Copilotに外部ツールの力を与える
MCPは、Copilotに外部サービスへのアクセス能力を追加するオープンプロトコルです。
設定方法
.vscode/mcp.json に定義します。
{
"servers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/"
},
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
}
}
}
おすすめMCPサーバー
| サーバー | 用途 | 備考 |
|---|---|---|
| GitHub MCP | Issue・PR管理、リポジトリ検索 | ゼロ設定・認証不要。最も統合度が高い |
| Playwright | ブラウザ自動操作、E2Eテスト生成・実行 | Microsoft公式メンテナンス |
| Context7 | 最新ライブラリドキュメントの自動注入 | APIキー不要。古い学習データによる誤り防止に効果大 |
| Filesystem | スコープ限定ファイルアクセス | サンドボックスと併用推奨 |
| Sentry | エラートラッキング情報の取得 |
${input:} 構文でトークン安全管理 |
MCPサーバーのサンドボックス化（v1.112〜）
macOS/Linuxでは、ローカルMCPサーバーをサンドボックス内で実行し、ファイル・ネットワークアクセスを制限できます。チームで共有するMCPサーバーには設定しておくと安心です。
MCP共有（v1.113〜）
VS Codeで設定したMCPサーバーは、Copilot CLIセッションやClaudeエージェントセッションにも自動的にブリッジされます。一度設定すれば全エージェントタイプで使い回せます。
12. Chat Customizations エディタ＆便利ツール群
Chat Customizations エディタ（Preview）
コマンドパレットから Chat: Open Chat Customizations で開ける統合管理UIです。インストラクション、プロンプトファイル、カスタムエージェント、スキル、Hooks、プラグインを一元管理できます。
AIによる自動生成コマンドも充実しています。
| コマンド | 生成されるもの |
|---|---|
/create-instruction |
カスタムインストラクション |
/create-prompt |
プロンプトファイル |
/create-agent |
カスタムエージェント |
/create-skill |
エージェントスキル |
/create-hook |
Hook |
スマートアクション（右クリックメニュー）
コンテキストメニューから即座にアクセスできるプリセットAIアクションです。プロンプトを書く手間すら省けます。
- Fix: エラーの自動修正
- Explain: コードの解説
- Generate Docs: ドキュメント自動生成
- Generate Tests: テスト自動生成
- Optimize Selection: パフォーマンス・保守性・信頼性の最適化提案（インラインdiffで表示）
その他の新機能
- 画像・動画サポート（v1.111〜）: スクリーンショットや動画をチャットに添付可能。エージェントの変更結果もカルーセルUIで確認
- 統合ブラウザデバッグ（v1.112〜）: VS Code内でWebアプリのエンドツーエンドデバッグが可能
- Copy Final Response: 思考ステップやツール呼び出しをスキップしてエージェントの最終回答だけをコピー
- セッションのフォーク: 別のアプローチを試したい場合、元の会話を保持したまま分岐
- コンテキスト自動圧縮: コンテキストウィンドウ上限に達すると自動で会話履歴を圧縮
13. Agent Skills（SKILL.md）— 再利用可能な手続き的知識
Agent Skillsは、カスタムインストラクションやプロンプトファイルとは異なる**「手続き的知識パッケージ」**です。スクリプト、テンプレート、参考資料を含むフォルダ単位で定義され、Copilotが関連タスクを検出すると自動的にロードされます。
インストラクション / プロンプトファイル / スキルの違い
| 種類 | 目的 | 適用タイミング |
|---|---|---|
| インストラクション | コーディング規約・ガイドライン | 常時自動適用 |
| プロンプトファイル | タスク単位の再利用プロンプト |
/コマンド名 で手動起動 |
| スキル | 手続き・スクリプト込みの専門知識 | Copilotが自動判定 or /スキル名 で起動 |
スキルの構造
.github/skills/
webapp-testing/
SKILL.md # スキル定義（必須）
test-template.js # テンプレート
setup-script.sh # セットアップスクリプト
doc-generator/
SKILL.md
template.md
SKILL.md の例
---
name: webapp-testing
description: >-
Playwrightを使ったWebアプリケーションのE2Eテスト作成を支援する。
テスト、E2E、ブラウザテストに関する質問で使用する。
---
# WebアプリケーションE2Eテスト
## 手順
1. 対象のページ・機能を分析
2. テスト戦略を決定（正常系・異常系・境界値）
3. [テストテンプレート](./test-template.js) をベースにテストを作成
4. AAAパターン（Arrange-Act-Assert）で構造化
5. テストを実行して結果を確認
## テンプレート使用方法
`test-template.js` をコピーして、対象ページのURLとセレクタを置き換えてください。
スキルの配置場所
| 場所 | スコープ |
|---|---|
.github/skills/ |
リポジトリ固有（チーム共有向け） |
.agents/skills/ |
汎用エージェント互換 |
~/.copilot/skills/ |
個人（全プロジェクト共通） |
~/.claude/skills/ |
Claude Code 互換 |
ポータビリティ
Agent Skillsはオープンスタンダードとして設計されており、VS Code の Copilot だけでなく、Copilot CLI、Copilot coding agent（クラウド）、さらには Claude Code でも動作します。.claude/skills/ に配置したスキルはCopilotが自動検出するため、両方のツールで使い回せます。
14. Awesome Copilot — コミュニティの力を活用する
github/awesome-copilot は、GitHub公式が管理するコミュニティ主導のカスタマイズリソース集です。ゼロからインストラクションやエージェントを書く前に、ここを覗くことを強くおすすめします。
何が手に入るか
| リソース | 説明 | 例 |
|---|---|---|
| Instructions | 言語・フレームワーク別のインストラクション | Next.js + Tailwind、.NET Framework、Python PEP 8 |
| Agents | カスタムエージェント定義 | セキュリティレビュー、DBA、プロンプトエンジニア |
| Skills | 手続き的知識パッケージ | Terraformモジュール作成、リリースワークフロー |
| Prompts | 再利用可能なプロンプトファイル | コードレビュー、ドキュメント生成 |
使い方
- awesome-copilot のWebサイト にアクセス
- 自分の技術スタックに合うリソースを検索
- ファイルをコピーしてプロジェクトの
.github/配下に配置 - 必要に応じてカスタマイズ
VS Code の Chat Customizations エディタからもプラグインマーケットプレイス経由でインストール可能です。
その他のコミュニティリソース
- anthropics/skills: Anthropic公式のスキルリポジトリ。Claude Code向けだがCopilotでも動作
- awesome-copilot-chatmodes: カスタムエージェント（旧Chat Modes）のコレクション
-
Awesome Copilot の
llms.txt: AIエージェントが直接参照できる機械可読フォーマットも提供
15. Hooks — ライフサイクルイベントの自動化
Hooksを使うと、Agent modeのツール実行前後で自動的にコマンドを実行できます。
| フック | タイミング | 用途例 |
|---|---|---|
| preToolUse | ツール実行前 | ポリシー違反のブロック、ツール呼び出しの修正 |
| postToolUse | ツール実行後 | フォーマッター自動実行、lint チェック |
カスタムエージェントごとにスコープを限定したHooksも定義可能です。例えば「JavaCoderエージェントがファイルを編集したら自動で google-java-format を実行する」といった設定ができます。
16. デバッグ・トラブルシュート技法
Copilotが期待通りに動かないとき、原因を特定するためのツールがいくつか用意されています。
Agent Logs
Chat: Show Agent Logs でツール呼び出し、LLMリクエスト、プロンプトファイルの検出状況を時系列で確認できます。「なぜこのファイルを編集したのか」「なぜこのツールを選んだのか」がわかります。
Chat Debug View
Chat: Show Chat Debug View で、実際にモデルに送信されたシステムプロンプト・ユーザープロンプト・コンテキスト・ツールペイロードの生データを確認できます。カスタムインストラクションが意図通り適用されているか検証する際の必須ツールです。
/troubleshoot（v1.112〜）
エージェントのデバッグログをチャット内で直接分析できるコマンドです。「なぜインストラクションが無視されたのか」「なぜレスポンスが遅かったのか」を過去のセッションも含めて調査できます。
17. モデル選択戦略
Copilotは複数のLLMモデルから選択可能です。Auto を選ぶとCopilotが最適なモデルを自動選択しますが、手動で切り替えることもできます。Thinking Effortの調整もモデルピッカーから直接設定可能です。
2026年4月時点の主要モデル一覧
| モデル | プロバイダ | 特徴 | 推奨用途 |
|---|---|---|---|
| GPT-4.1 | OpenAI | バランス型。迷ったらまずこれ | 汎用的なコーディング |
| GPT-4o | OpenAI | 高速・低コスト | 軽量なタスク、日常的なチャット |
| GPT-5.4 | OpenAI | 最新・高い推論能力 | 複雑な設計、難易度の高いバグ修正 |
| Claude Sonnet 4 / 4.5 | Anthropic | コード品質が高い、指示追従性に優れる | リファクタリング、コードレビュー |
| Claude Opus 4.5 / 4.6 | Anthropic | 最高品質、大規模コンテキスト | 大規模な設計タスク（高コスト） |
| Claude Haiku 4.5 | Anthropic | 軽量・高速 | 簡単な質問、素早い補完 |
| Gemini 2.5 Pro | 推論に強い | 分析・調査タスク | |
| Gemini 3.1 Pro | 最新のGemini | 複雑な推論タスク | |
| Gemini 3 Flash | 高速 | 軽量なタスク | |
| Grok Code Fast 1 | xAI | 高速コード生成 | スピード重視のタスク |
BYOKモデル（Bring Your Own Key）
VS Codeでは、Azure OpenAI、Anthropic、OpenAI等のAPIキーを持ち込んで、デフォルト以外のモデルを追加することも可能です。
カスタムエージェントでは配列指定によるフォールバックが可能です。
model: ['Claude Sonnet 4.5', 'GPT-5.4'] # 利用可能なモデルを順番に試行
Claude エージェント統合
VS Code内でAnthropicのClaude Agent SDKを直接利用できます。Copilotと同一のサブスクリプションでClaudeモデルをエージェントとして使い分けられ、セッション中のステアリング（方向修正）やメッセージのキューイングにも対応しています。
18. チームでの活用戦略
リポジトリに含めるべきファイル一覧
.github/
copilot-instructions.md # プロジェクト共通ルール
instructions/
backend.instructions.md # バックエンド固有ルール
frontend.instructions.md # フロントエンド固有ルール
testing.instructions.md # テスト固有ルール
prompts/
create-api.prompt.md # API生成プロンプト
write-tests.prompt.md # テスト生成プロンプト
code-review.prompt.md # レビュープロンプト
fix-bug.prompt.md # バグ修正ワークフロー
agents/
orchestrator.agent.md # オーケストレーター
java-coder.agent.md # Java実装エージェント
reviewer.agent.md # レビューエージェント
.vscode/
mcp.json # MCPサーバー設定
docs/
knowledge.md # 自己改善ループのナレッジベース
AGENTS.md # AI共通インストラクション
チーム展開のステップ
-
/initでベースを生成 → 最初のcopilot-instructions.mdを作る - レビューで育てる → Copilotが生成したコードで規約違反があれば、インストラクションにルールを追加
- プロンプトファイルを共有 → 「テスト生成」「バグ修正」などよく使うワークフローを標準化
- knowledge.md を運用 → プロジェクト固有の制約や学びを蓄積
- カスタムエージェントを導入 → チームの開発フローに合わせたペルソナを定義
19. 総合Tips — 筆者が現場で学んだこと
Tip 1: 段階的に進める
1回の巨大なプロンプトより、小さなステップに分けて反復する方が品質が高くなります。Planエージェント → Agentへのハンドオフはこの思想と相性抜群です。
Step 1: 「まずファイル構成の計画を提示して」
Step 2: 「DTOを先に実装して」
Step 3: 「Service層を実装して。DTOの型を使ってください」
Step 4: 「テストを書いて」
Step 5: 「全テストを実行して、失敗があれば修正して」
Tip 2: チャットセッションを使い分ける
新しいタスクには新しいチャットセッションを。履歴が長くなると不要なコンテキストがモデルに渡されて精度が下がります。95%に達すると自動圧縮されますが、その前に区切る方が品質は安定します。
Tip 3: AI生成コードは必ずCIゲートで検証する
Copilotは強力ですが、「謎の安心感」に騙されてはいけません。特にセキュリティ・パフォーマンスに関わるコードは、CIゲート（Checkstyle、SpotBugs、ESLint等）と併用して品質を担保しましょう。
「人がレビューで見つける」から「機械がマージをブロックする」への転換が、AI時代のコード品質管理の鍵です。Copilotの出力を盲信せず、自動化されたゲートで確実に品質を守る仕組みを作りましょう。
Tip 4: インストラクションはリンターでは捕まらないルールに集中する
Checkstyleやprettierが強制するルールをインストラクションに書くのは冗長です。インストラクションには自動ツールでは検出できないプロジェクト固有のルール（設計方針、例外処理の使い分け、ライブラリ選定の理由など）を書くことに集中しましょう。
まとめ
GitHub Copilotを最大限活用するポイントを整理します。
- Agent modeがデフォルト — Edit modeは非推奨。Ask / Plan と使い分ける
-
コンテキストを的確に渡す —
#file,#codebase（セマンティック検索）を活用 -
カスタムインストラクションでチーム標準化 —
/initで初期生成 → 段階的に育てる -
プロンプトファイルでワークフロー再利用 —
.prompt.mdをチームで共有 - カスタムエージェント＋ハンドオフ — Plan → Review → Implement の流れを自動化
- マルチエージェントは4〜5体が実用的上限 — 粒度とトークンのバランスが重要
- 自己改善ループで knowledge.md を育てる — 使うほどCopilotが賢くなる好循環
- MCPで外部ツール連携 — サンドボックスで安全に運用
- NESでTab連打リファクタリング — 地味だが生産性インパクト大
- AIを信頼しすぎない — CI/CDゲートとの併用が必須
Copilotは「使い方を知っている人」と「知らない人」で、生産性に数倍の差が出るツールです。本記事が皆さんの開発体験向上の一助になれば幸いです。
参考リンク
Discussion