GitHub Copilotカスタムエージェント実践ガイド2026：.agent.mdとMCPガバナンスで「便利だけど怖い」を卒業する

はじめに：Copilotが「賢い同僚」になったので、就業規則も必要になりました

2026年春、GitHub Copilotまわりのアップデートが一気に濃くなりました。Visual Studioでは.agent.mdでカスタムエージェントを定義しやすくなり、MCP※連携やスキル再利用も現実的になっています。VS Code側もAutopilot（プレビュー）など、自律実行を強める方向に進んでいます。

ここで出てくるのが、個人開発者あるあるの悩みです。

便利なのは分かる
でも、どこまで任せてよいか不安
速くなったのに、レビュー負荷は減っていない

私も最初は「とりあえず全部ON」で試したのですが、数日で気づきました。エージェントは優秀なインターンであり、放し飼いの魔法使いではないということです。手順と境界がないと、速さがそのまま混乱の速度になります。

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

※MCP（Model Context Protocol）: LLMと外部ツール・データをつなぐための標準仕様です。

2026年春の変化を3分で整理

まず押さえておきたい事実だけ並べます。

Visual Studioの2026年3月更新で、.agent.mdによるカスタムエージェント、エージェントスキル、MCPガバナンス対応が強化された
Copilot coding agentは2026-03-19時点で「作業開始まで50%高速化」と案内されている
VS Code側ではAutopilot（プレビュー）、権限レベル切り替え、統合ブラウザデバッグなど「自律＋観測」寄りの機能が増えた
カスタムエージェント設定では、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連携は便利ですが、最初に「道具の棚卸し」をしてください

Copilot cloud agentでは、MCPサーバーを通じて外部ツールを使えます。しかもデフォルトでGitHub系やPlaywright系の接続が用意されている部分があり、体験はかなり滑らかです。

ただし、ここで大事なのは「接続できる」ことと「接続してよい」ことは別、という点です。

公式ドキュメントにもある通り、Copilot cloud agentはMCPのtoolsのみを扱い、resourcesやpromptsは非対応です（2026年4月時点）。また、第三者MCPサーバーは性能や品質に影響し得るため、精査を推奨しています。これは遠回しに言うと「便利そうで入れたサーバーが、最終的に開発速度を落とすことがある」です。

私のおすすめは、MCP導入時に次の順で進めることです。

既定サーバーだけで1週間運用
ボトルネックが明確になってから追加
追加時はtoolsをワイルドカードにしない
1サーバー追加ごとに「失敗ログ」を見て評価

tools: ["*"]は最初の検証には便利ですが、本番運用の常用設定としては強すぎます。大抵の事故は「禁止されていないから実行された」パターンで起きます。

50%高速化をどう活かすか：待ち時間削減より、往復回数削減

Copilot coding agentの「作業開始50%高速化」は、体感として確かに効きます。ですが、ここでやりがちな失敗は、速くなった分だけ雑に投げることです。

開発フローで本当に効くのは、初回起動の数秒より往復回数です。つまり、1回でどれだけ「やり直しの少ない指示」を渡せるかが重要です。

私はIssueやPRコメントに次のテンプレートを使っています。

# Goal
- 何を達成したいか

# Non-goal
- 今回やらないこと

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

# Done definition
- PRに含むべき成果物
- 確認観点

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

ポリシーと権限の実務：個人開発でも「小さな管理者」になる

「組織向け機能でしょ」と思われがちですが、個人開発でもポリシー思考は効きます。

たとえばGitHub Docsでは、組織やエンタープライズでMCPやモデル利用ポリシーを制御できること、さらに適用階層によって上書き不可なケースがあることが説明されています。個人運用でもこれは翻訳できます。

リポジトリごとに許可ツールを変える
実験用と本番用でエージェント定義を分ける
モデルを固定する条件を決める
公開コード一致ポリシーやレビュー手順を明文化する

つまり、管理画面の有無より運用ルールが文書化されているかが本質です。

私は次のような運用メモをリポジトリ直下に置いています。

## Agent Policy (local rule)
- mainブランチ直更新は禁止
- 自動変更はPR経由のみ
- custom agentは用途別に分割
- MCP追加時は最初の3タスクを監査対象にする
- 失敗時は再実行前に原因メモを残す

地味ですが、この手のメモがあるだけで「なんとなく再実行」が減り、失敗の再現性が上がります。再現できる失敗は、半分解決したも同然です。

私の推奨構成：3エージェント体制で回す

2026年4月時点で、私が一番トラブル少なく回せているのは次の3体制です。

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

この分離のメリットは、失敗したときの責任範囲が明確になることです。1体に全部任せると、速いけれど「どこで壊れたか」が分かりにくくなります。人間のチーム設計と同じで、役割分担はデバッグ可能性を上げます。

まとめ：2026年は「AI活用力」より「AI運用力」

Copilotの進化はもう十分速いです。これから差を作るのは、モデル比較の暗記よりも、次の運用筋力だと考えています。

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

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

便利さは正義です。ただし、正義には監査ログが必要です。ここまでやっておけば、未来の自分に怒られる確率はかなり下げられます。未来の自分、意外と口うるさいですからね。