2026年版 GitHub Copilotカスタムエージェント設計書：.agent.md、MCP、権限ガバナンスを個人開発で回す実務

はじめに：AIエージェントは優秀な同僚、ただし「就業規則」なしだと暴走しがちです

2026年に入ってから、GitHub Copilotの進化がかなり実務寄りになってきました。Visual Studio側では.agent.mdを使ったカスタムエージェント定義やMCP※連携、エージェントスキルの活用が進み、VS Code側ではAutopilot（プレビュー）や権限レベル切り替えなど、「任せる前提」の機能が増えています。

ここで個人開発者として悩むのが、次の3点です。

速くなったのは嬉しいが、どこまで任せてよいか分からない
ツール連携が強力すぎて、設定ミス時の被害が読みにくい
PRは増えるのに、レビュー負荷が下がらない

私も最初は「便利そうな機能を全部ON」にしていました。結果は、はい、想像どおりです。AIは速く、私は混乱し、コーヒーだけが減っていきました。そこで運用を作り直し、いまは役割分担＋権限制御＋監査可能性の3点セットで落ち着いています。

この記事では、2026年4月時点の公開情報をもとに、Copilotカスタムエージェントを「速い」「壊れにくい」「説明できる」状態で運用するための具体策をまとめます。

※MCP（Model Context Protocol）: LLMと外部ツール・データソースを接続するための標準仕様です。

まず押さえるべき2026年春の更新ポイント

先に結論だけ整理します。

Visual Studio 2026年3月更新で、.agent.mdによるカスタムエージェント定義、エージェントスキル活用、MCPガバナンス対応が強化された
Copilot coding agentは2026-03-19の案内で、作業開始が50%高速化された
VS Codeの2026年3月リリース群ではAutopilot（プレビュー）、セッション権限設定、統合ブラウザデバッグ、サンドボックスMCPなど運用系の改善が進んだ
カスタムエージェント設定ではtoolsで許可ツールを制御でき、MCP設定には処理順序（デフォルト→カスタムエージェント→リポジトリ設定）がある
組織ポリシーではMCPやモデル利用の可否を制御できるが、適用スコープを理解しないと「設定したつもり」事故が起きる

つまり、2026年は「AIを使うかどうか」より、どの権限で、どのツールを、どの条件で使わせるかが勝負です。モデル性能差より、運用設計差のほうが成果を左右します。

.agent.mdの実務設計：人格設定より「契約設計」を優先する

カスタムエージェントを作るとき、つい「口調」や「キャラ」から入りたくなります。もちろん悪くはありません。ただ、運用品質に効くのは先に契約を定義することです。

私が最初に固定するのは次の4項目です。

目的: 何を達成したら完了か
非目的: 今回やらないこと
出力フォーマット: 何をどの粒度で返すか
許可ツール: 必要最小限は何か

特にtoolsは重要です。設計専用エージェントならread/search/editだけで十分なケースが多く、executeを最初から許可すると「試行ログは立派だが結論が薄い」状態になりやすいです。速いのに疲れる、あの現象です。

以下は、設計担当エージェントの最小構成例です。

---
name: implementation-planner-ja
description: 実装前の設計と分解に特化
tools: ["read", "search", "edit"]
---

あなたの役割は実装の前工程を整えることです。
必須出力:
1. 要件分解
2. 前提とリスク
3. 実装タスク（優先度付き）
4. テスト観点

禁止:
- 実コードの大量生成
- 依存追加提案だけで終わる回答

ポイントは「賢く動いてください」ではなく、「この範囲で仕事してください」を明文化することです。これをやるだけで、再現性とレビュー効率が目に見えて上がります。

MCP導入の現実解：1回で完璧を狙わず、段階導入で事故を減らす

Copilot cloud agentのMCP連携は非常に強力です。公式ドキュメントでも、デフォルトでGitHubやPlaywright系のMCPが扱えること、リポジトリ設定やカスタムエージェント設定で拡張できることが説明されています。

ただし、2026年4月時点の制約として、cloud agentはMCPのtoolsのみ対応で、resourcesやpromptsは非対応です。また、OAuthを使うリモートMCPに制約がある点も押さえる必要があります。ここを理解しないと「できるはずなのに動かない」を量産します。

私のおすすめ導入手順は次です。

既定MCPだけで1週間運用し、詰まりポイントを記録
追加MCPは1つずつ有効化し、失敗ログを必ず残す
tools: ["*"]は検証時のみ、本番は個別許可
secretsやenvの注入は用途別に分離し、使い回しを避ける

実際、トラブルの多くは「危険ツールを使った」よりも「不要ツールを許可した」ことで起きます。禁止リスト運用より、許可リスト運用のほうが管理が楽です。

高速化を本当に活かす方法：初回起動時間より、往復回数を減らす

Copilot coding agentの50%高速化は確かに嬉しいです。ただ、開発全体で効くのは起動秒数より往復回数です。

言い換えると、最初の依頼が曖昧だと、どれだけ起動が速くてもPR修正の往復で時間を失います。私はIssueやPRコメントを次のテンプレートに固定して、往復を減らしています。

# Goal
- 達成したい成果

# Non-goal
- 今回やらない範囲

# Constraints
- 変更禁止ディレクトリ
- 必須テスト
- 互換性条件

# Done Definition
- PRに含む成果物
- 受け入れチェック項目

この形式にしてから、初回PRの品質がかなり安定しました。エージェントが急に人格者になったわけではなく、依頼が機械可読になった効果です。人間チームでも同じですが、AI相手だと差がより極端に出ます。

ガバナンス設計：個人開発でも「ミニ管理者」になる

公式の組織向けポリシー機能は、個人開発には関係ないように見えます。しかし実務上は、考え方をそのまま持ち込めます。

リポジトリごとに許可ツールを変える
実験用エージェントと本番用エージェントを分離する
モデル選択条件（速度重視／精度重視）を文書化する
公開コード一致やレビュー条件を固定化する

要するに、管理画面の機能差より「ルールが文章で存在するか」が重要です。私は次のようなAGENT_POLICY.mdを各リポジトリに置いています。

## Agent Policy
- mainへの直接変更は禁止
- すべてPR経由で反映
- custom agentは用途別（設計・実装・レビュー）で分離
- MCP追加時は最初の3タスクを監査
- 失敗時は再実行前に原因メモを残す
- 1タスク1目的。複数目的は禁止

地味ですが、これだけで「なんとなく再実行」が激減します。再現できる失敗は半分解決したようなものです。

推奨アーキテクチャ：3エージェント分離でデバッグ可能性を上げる

私が現在いちばん安定している構成は、次の3ロール分離です。

Planner（設計専用）
- tools: read/search/edit
- 出力: 設計書、タスク分解、受け入れ条件
Implementer（実装専用）
- tools: read/search/edit/execute（必要時のみ）
- 出力: 差分、テスト結果、未解決課題
Reviewer（監査専用）
- tools: read/search
- 出力: リスク、逆戻りコスト、マージ判断材料

この分離の利点は、失敗時に責任範囲を切り分けられることです。1体に全部任せると、速いですが「どこで壊れたか」が追いづらくなります。役割分担は、開発速度より先に障害復旧速度を改善します。

最後に：2026年は「AI活用力」より「AI運用力」で差がつく

Copilotのモデルや機能は、これからも高頻度で更新されます。だからこそ、長く効くのは次の運用筋力です。

指示を構造化する
権限を最小化する
MCPを段階導入する
PR運用を監査可能にする
失敗ログを知見化する

AIエージェントは、一人開発の同時並行数を増やしてくれる強力な相棒です。ただし設計なしで使うと、一人で混乱する速度だけ上がります。技術は中立で、運用だけが性格を持ちます。

便利さは正義です。正義には監査ログが必要です。ここまで整えておけば、未来の自分に「なぜこれをマージしたの？」と詰められる確率をかなり下げられます。未来の自分、だいたい正論で殴ってくるので、先に防御しておくのがおすすめです。