GitHub Copilotカスタムエージェント運用ランブック2026：.agent.md・MCP・レビュー導線を一気に整える

はじめに：エージェントの性能より「運用の設計」が効く時代です

2026年春のGitHub Copilotは、かなり実務向けの道具になりました。Visual Studioでは.agent.mdでカスタムエージェントを定義しやすくなり、MCP※連携やスキル活用も整ってきています。VS Code側もAutopilot（プレビュー）や権限設定、デバッグ補助が強化され、「人間が逐一クリックしなくても進む」方向に明確に舵を切っています。

この流れ自体は歓迎です。ですが、現場で起きる問題はいつも同じです。

便利なので設定を盛る
盛大に動く
どこが悪かったか追えない

私もこのループを何度か踏みました。結論から言うと、いま重要なのはモデル比較の暗記より、運用ランブックの整備です。速いエージェントに雑なルールを渡すと、雑な結果が高速で返ってきます。まさに高速道路で道案内を失う感じです。速い。迷う。つらい。

この記事では、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やモデル利用を統制できるが、適用範囲を誤解すると管理漏れが起きる

これを実務に翻訳すると、次の一文に尽きます。

機能を増やす前に、権限と責任の境界を先に決める。

この順序を逆にすると、導入初週は盛り上がるのに、2週目で疲弊します。エージェントが悪いのではなく、運用が未定義なだけです。

.agent.md設計の実務：キャラクターより「契約」を書く

カスタムエージェントは、つい「得意分野」「口調」「人格」から作りたくなります。もちろん大事です。ただ、運用品質に直結するのは次の4点です。

Goal: 何を達成したら完了か
Non-goal: 今回やらないこと
Constraints: 変更禁止領域、必須テスト、互換条件
Output: 返却フォーマット（見出し、項目、粒度）

私は最低でも以下のテンプレートを入れています。

---
name: impl-planner-ja
description: 実装前の設計とタスク分解を担当
tools: ["read", "search", "edit"]
---

あなたの責務:
- 要件を分解し、優先順位付きタスクリストを作る
- 失敗リスクと前提条件を明文化する
- 実装とテストの受け入れ条件を定義する

禁止:
- 実装コードを大量生成しない
- 不確かな前提を断定しない
- 論点が曖昧なまま結論を出さない

必須出力:
1. 背景
2. 方針
3. タスク分解
4. テスト観点
5. 未確定事項

toolsの絞り込みは特に効きます。設計担当にexecuteを許可しないだけで、無駄な実行ログが減り、レビュー時の認知負荷が下がります。逆に、全部許可すると「できるからやる」が始まります。AIは善意で動くので、境界が曖昧だと善意で遠回りします。

MCP運用の落とし穴：追加するより、減らすほうが難しい

Copilot cloud agentはMCPで拡張できます。公式情報でも、デフォルトのMCP（GitHubやPlaywright）と、リポジトリ設定・カスタムエージェント設定での追加が説明されています。

ただし、制約もあります。2026年4月時点でcloud agentはMCPのtoolsのみ対応で、resourcesやpromptsは非対応です。OAuthを使うリモートMCPについてもサポート制約があります。ここを見落とすと、設計が破綻します。

さらに重要なのは、MCPの設定順序です。カスタムエージェント設定は、デフォルトMCPのあと、リポジトリ設定の前に適用されます。つまり、期待どおりに上書きされないことがあり得ます。

私は以下の段階導入を推奨しています。

既定MCPのみで1週間運用し、失敗ケースを収集
追加MCPは1つずつ有効化
各MCPで許可するツールを個別指定
tools: ["*"]は検証用途に限定
秘匿情報は用途別secretで分離し、横展開しない

そして「使えるツール一覧」をPRに貼る運用をおすすめします。監査可能性が急に上がります。

## Agent Tool Manifest
- builtin: read, search, edit
- mcp.github: issues.read, pulls.read
- mcp.playwright: screenshot, navigate
- denied: execute, write-all

この1ブロックがあるだけで、レビュー担当が「何をされた可能性があるか」を短時間で判断できます。

50%高速化の活かし方：起動時間ではなく往復回数を削る

Copilot coding agentの起動高速化は、体感でも効きます。ですが全体最適で見ると、もっと効くのは往復回数の削減です。初回の依頼が曖昧だと、起動が速くても修正ループで時間が溶けます。

私はIssueとPRコメントを次の定型にしています。

# Goal
- 最終的に達成したい成果

# Non-goal
- 今回対象外の範囲

# Constraints
- 変更禁止ファイル
- 必須テスト
- パフォーマンス要件

# Done Definition
- PR必須成果物
- 受け入れ基準

# Failure Handling
- 失敗時の中断条件
- 再実行前に残すメモ

このテンプレート化で、PR品質が安定しました。エージェントが賢くなったというより、依頼が誤読しにくくなった効果です。人間同士でも同じですが、AIは文面の構造により強く反応します。

レビュー設計：3エージェント分離で「壊れ方」を見える化する

おすすめは、役割を3つに分離する方式です。

Planner（設計専用）
- tools: read/search/edit
- 出力: 設計、タスク、リスク
Implementer（実装専用）
- tools: read/search/edit/execute（必要時のみ）
- 出力: 差分、テスト結果、残課題
Reviewer（監査専用）
- tools: read/search
- 出力: リスク評価、逆戻りコスト、マージ判断

この分離の利点は、失敗時の切り分けが速いことです。1つの万能エージェントに全部任せると、成功時は快適ですが、失敗時に原因が混ざります。個人開発ほど復旧速度が重要なので、責任境界を先に分けたほうが結果的に速いです。

障害対応ランブック：うまくいかない日のための手順

最後に、実際に詰まったときの簡易ランブックを置いておきます。これがあるだけで、深夜の自分を救えます。

症状A: 想定外のファイルまで変更された

直ちにタスクを停止
変更範囲を分類（意図した変更／意図外変更）
.agent.mdのConstraintsに禁止パスを追加
同タスクを小さく分割して再実行

症状B: PRは出るが品質が不安定

GoalとDone Definitionを明確化
1タスク1目的を徹底
Plannerの出力を経由してからImplementerを動かす

症状C: MCP連携で挙動が重い・不安定

追加MCPを一時停止
Tool Manifestを見直し、不要ツールを除去
secrets注入とタイムアウト設定を確認

「失敗したら再実行」は短期的には楽ですが、同じ事故を量産します。再実行前に一行でよいので原因メモを残すと、翌日の自分が英雄になります。

運用チェックリスト：導入初日から30日目まで

ここまでの内容を、実務に落とすためのチェックリストにします。文章を読んで終わると、翌週には忘れます。私も忘れます。なので、チェック項目にしてしまうのが最強です。

Day 1-3（導入期）

カスタムエージェントを1体だけ作る（欲張って3体作らない）
toolsは最小セットに限定する
Goal / Non-goal / Constraints / Done Definitionをテンプレ化する
失敗時の中断条件を1行で決める

この段階の目的は「成功率を上げる」ではなく、「失敗の形を揃える」ことです。失敗が揃うと修正できます。失敗が毎回違うと、いつまで経っても運用が安定しません。

Day 4-10（安定化期）

PRごとにTool Manifestを添付する
変更範囲の逸脱件数を記録する
PlannerとImplementerを分離する
再実行前に原因メモを残すルールを徹底する

この時期は「速さ」より「再現性」を見ます。速くても再現しないなら、運用は資産になりません。逆に少し遅くても再現するなら、あとから最適化できます。

Day 11-30（拡張期）

MCPを1つだけ追加し、1週間監視する
不要ツールを削除して権限を再最小化する
Reviewer専用エージェントを導入する
月末に失敗ログを棚卸しし、次月ルールを更新する

ここでの罠は「うまく回ってきたので一気に拡張したくなる」ことです。気持ちは分かりますが、拡張は段階的にやるのが結局最短です。

よくある質問（FAQ）：実際に詰まりやすいところ

Q1. toolsを絞ると賢さが落ちませんか？

短期的には、できる作業が減るので不便に感じます。ですが実務では、不要な行動が減る効果のほうが大きいです。特にレビュー負荷は下がります。賢さはモデル性能だけでなく、探索空間の設計で決まります。

Q2. Autopilotは常時ONでよいですか？

私は常時ONにしません。Autopilotは強力ですが、対象タスクを限定したほうが安全です。具体的には、影響範囲が狭いリファクタやドキュメント更新には向きますが、依存更新や認証まわりの変更には慎重であるべきです。

Q3. MCPは何個まで増やしてよいですか？

明確な正解はありませんが、個人開発なら「1つ追加して1週間観測」を基本にすると事故率が下がります。増やす速度より、削る判断の速さのほうが成果につながります。

Q4. PRの説明文はどこまで書くべきですか？

最低でも、目的・変更範囲・未対応事項・検証方法の4点は必要です。AI生成PRは差分が整って見えるぶん、意図が抜けると後で事故ります。差分より意図を先に読む運用が安全です。

Q5. モデル選択は毎回変えるべきですか？

毎回変えるより、タスク種別ごとの既定を決めるほうが安定します。例として、設計タスクは思考重視モデル、軽微修正は速度重視モデルという切り分けが有効です。ルール化しておくと、迷いが減ります。

Q6. 失敗ログはどの粒度で残せばよいですか？

長文は不要です。1件あたり3行で十分です。

何をさせたか
どこで失敗したか
次回どう防ぐか

この3行があるだけで、同じミスの再発率がかなり下がります。

Q7. 人間レビューはどこまで必要ですか？

結論として、最終判断は人間が持つべきです。特にセキュリティ、課金、データ削除に関わる変更は必須です。AIが提案できることと、責任を負えることは同義ではありません。

Q8. 個人開発でもここまで厳密にやる価値はありますか？

あります。むしろ個人開発こそ効果が高いです。チームの誰かがカバーしてくれる前提がないため、運用の粗さがそのまま自分に返ってきます。最初に整えるほど、後半が楽になります。

まとめ：2026年に必要なのは、AI活用力よりAI運用力です

Copilotの進化はこれからも続きます。だからこそ、長く効くのは次の基本動作です。

指示を構造化する
権限を最小化する
MCPを段階導入する
監査可能なレビュー導線を作る
失敗ログを資産化する

AIエージェントは、一人開発の処理能力を本当に引き上げてくれます。ただし設計なしで使うと、混乱のスループットだけが上がります。技術は中立、運用だけが性格を持ちます。

便利さは正義です。正義にはログが必要です。ここまで整えておけば、未来の自分からの詰問をかなり減らせます。未来の自分はだいたい厳格なので、いまの自分が先回りしておきましょう。