【AI開発】GitHub Copilotで自分用エージェントを作る考え方

前回は、エージェントAIの設計パターンを「ゴールと計画」「推論と自己改善」「協調」「安全性ガード」の4レイヤで整理しました。今回はその考え方を、GitHub Copilotで実際に使える形へ落とし込みます。ポイントは、Copilotを単なる補完ツールではなく、指示、ツール、権限、検証手順を与えた「開発ワークフロー用エージェント」として設計することです。

Copilotで作れるエージェントの種類

まず、Copilotには大きく2つの使い方があります。VS CodeなどのIDEで使うagent modeと、GitHub上で動くCopilot cloud agentです。GitHub Docsでは、cloud agentはリポジトリを調査し、実装計画を作り、ブランチ上で変更し、必要に応じてPull Requestを作れると説明されています。About GitHub Copilot cloud agent

一方、VS Codeのagent modeはローカル開発環境の中で動く自律的なペアプログラマです。VS Codeのブログでは、agent modeはコードベースを分析し、ファイル編集を提案し、ターミナルコマンドを実行し、コンパイルやlintエラーを見て修正ループを回せると説明されています。VS Code Agent mode

ざっくり分けると、ローカルで一緒に試行錯誤するならIDEのagent mode、IssueやPR単位で非同期に任せるならcloud agentが向いています。

1. ゴール定義はプロンプトとinstructionsで作る

エージェント設計の最初の層は、曖昧な依頼を実行可能なタスクへ変換することです。Copilotでは、ここをプロンプトとcustom instructionsで作ります。

リポジトリ全体の前提は .github/copilot-instructions.md に書けます。GitHub Docsでは、リポジトリ全体のcustom instructionsとしてこのファイルを作り、プロジェクト構造、ビルド方法、テスト方法、コーディング規約などをMarkdownで記述できると説明されています。Adding repository custom instructions

たとえばDevOps系リポジトリなら、次のような情報を入れておきます。

# Repository instructions

- 変更前に対象サービス、環境、影響範囲を確認する
- CI/CD関連の変更では `.github/workflows/` と `scripts/` を必ず確認する
- 破壊的操作や本番反映は実行せず、計画と差分だけ提示する
- 変更後は `make test` と `make lint` を実行する

これは、前回の記事でいうPassive Goal CreatorとGuardrailsを、Copilot向けの常時コンテキストとして実装しているイメージです。

2. パス別instructionsで役割を分ける

リポジトリ全体の指示だけだと、フロントエンド、バックエンド、インフラ、ドキュメントでルールが混ざります。そこで .github/instructions/*.instructions.md を使います。GitHub Docsでは、applyTo frontmatterで対象パスを指定するpath-specific custom instructionsを作れると説明されています。Adding repository custom instructions

たとえばHugoブログなら、記事用のinstructionsを次のように分けられます。

---
applyTo: "content/posts/**/*.md"
---

# Blog post rules

- frontmatterには title, slug, draft, date, tags, categories, description を含める
- 本文では h1 を使わず、h2/h3 で構成する
- 外部情報を使った場合はMarkdownリンクで出典を残す
- draft は明示がなければ false にする

これにより、Copilotは「記事編集時のエージェント」と「コード編集時のエージェント」で振る舞いを変えやすくなります。

3. custom agentsで専門エージェント化する

さらに踏み込むなら、custom agentsを使います。GitHubのcustomization cheat sheetでは、custom agentsは独自のinstructions、tool restrictions、contextを持つ専門ペルソナで、.github/agents/AGENT-NAME.md などに置けると整理されています。Copilot customization cheat sheet

たとえば、次のようなエージェントを用意できます。

  • docs-writer: README、ADR、ブログ記事、リリースノートを書く
  • test-generator: 既存コードを読んでユニットテストを追加する
  • ci-debugger: GitHub Actionsの失敗ログを読み、再現手順と修正案を出す
  • security-reviewer: 依存関係、権限、シークレット混入を確認する

これは、前回の4レイヤでいう「協調」レイヤです。最初から巨大な万能エージェントを作るより、役割ごとに分けるほうがレビューしやすくなります。

4. MCPでツールを増やす

Copilotを本当のエージェントらしくするには、外部ツールへのアクセスが重要です。GitHub Docsでは、MCPを使うとCopilot agent modeが外部データソース、API、ツールへアクセスでき、調査、計画、実装、検証のループを回しやすくなると説明されています。Enhancing GitHub Copilot agent mode with MCP

開発者向けには、まず次のようなMCPサーバから始めるのが現実的です。

  • GitHub MCP: Issue、PR、ブランチ、Actionsの情報を見る
  • Playwright MCP: UIを操作してE2Eやアクセシビリティを確認する
  • Figma MCP: デザイン仕様を読み、実装との差分を確認する
  • 独自MCP: 社内API、ログ、メトリクス、デプロイ情報を読む

MCPを足すときは、いきなり全部つなげないほうが安全です。公式ドキュメントでも、目的に合うサーバを選び、シンプルに始め、接続確認をしてからagent modeのタスクに使うことが推奨されています。Enhancing GitHub Copilot agent mode with MCP

5. 変更前にフェーズを分ける

Copilotにいきなり「全部直して」と頼むと、どの設計判断が正しかったのか追いづらくなります。おすすめは、Research、Plan、Implement、Validateの4フェーズに分けることです。

1. Research: まず関連ファイル、Issue、CIログを調べて、原因候補を列挙して。まだ変更しない。
2. Plan: 修正方針を2案出し、リスク、影響範囲、検証方法を比較して。
3. Implement: 採用した方針で最小差分を実装して。関係ない整形はしない。
4. Validate: テスト、lint、手動確認項目を実行し、結果をまとめて。

これはPlan & Execute、Prompt Chaining、Evaluator-OptimizerをCopilot上で手動フェーズ化したものです。特に本番系やCI/CD系の変更では、「まだ変更しない」「PRを作る前に計画だけ出す」「破壊的操作はしない」と明示するだけで事故を減らせます。

最小構成のおすすめ

まず作るなら、次の3点で十分です。

1つ目は .github/copilot-instructions.md です。リポジトリ概要、セットアップ、テスト、禁止事項、レビュー観点を書きます。

2つ目は .github/instructions/ です。frontend.instructions.md、backend.instructions.md、docs.instructions.md のように、パスごとのルールを分けます。

3つ目はMCPを1つだけ足すことです。GitHub連携かPlaywright連携のように、普段の開発で効果が見えやすいものから始めます。

この構成なら、単一エージェントでも「ゴール定義」「推論と実行」「安全性ガード」までかなり表現できます。必要になったタイミングで、custom agentsやagent skillsを追加し、docs-writer、ci-debugger、security-reviewerのような専門エージェントへ分割すればよいです。

Copilotでエージェントを作るとは、特別なAI基盤を最初から作ることではありません。自分の開発プロセスを、instructions、prompt、agent、MCP、承認フローとして明文化することです。設計パターンを意識してCopilotに渡す文脈を整えるほど、単なる補完ツールから、頼れる開発パートナーに近づいていきます。

関連記事