Copilot CLIの/fleet時代に必要な実務ガバナンス: 単体支援から複数エージェント運用へ

GitHub Blogで続いているCopilot CLIの更新（モデルのセカンドオピニオン、/fleetによる複数エージェント実行）は、AI支援を「1対1の補助」から「並列作業の調整」へ進化させています。

ただし、速度だけを見て導入すると、品質事故はほぼ確実に増えます。典型的には、重複実装、責任不明なコミット、レビュー漏れです。複数エージェント運用は、機能導入より先にガバナンス設計が必要です。

なぜ従来プロセスでは足りないのか

単体のAI補助では「最後に人が見る」で回る場面がありました。しかし並列化されると、1人のレビュアーが全差分を意味理解するのは現実的ではありません。結果として、

• マージ後に設計不整合が顕在化
• テストは通るが運用境界を壊す変更が混入
• 誰がどの条件で生成した変更か追跡不能

という問題が起きます。

実装すべき4つの統制

1) タスク契約（Task Contract）

各エージェントに渡す指示は、最低でも以下を含めます。

• 目的と非目的
• 変更可能なファイル範囲
• 必須テスト
• 中断条件

「直して」だけの指示は最短で不具合に繋がります。

2) ブランチ命名と出自管理

エージェント作業用ブランチ規約を定義し、コミットメッセージに生成条件（タスクID、使用モデル、制約）を残します。

3) レビューの多層化

• 静的チェック（lint/test/security）
• 構造ルール検証（境界違反検知）
• 人間レビュー（重要ファイル限定）

これにより、人間レビューの負荷を「全部確認」から「重要判断」に変えられます。

4) 同時実行上限（Concurrency Budget）

リポジトリごとに同時エージェント数を定義します。上限がないと、PR渋滞と再作業で逆に遅くなります。

セカンドオピニオン活用の勘所

モデル比較は常時ではなく、次の高リスク領域に限定するのが現実的です。

• 広範囲リファクタ
• 根本原因が曖昧な障害調査
• セキュリティ境界に触れる変更

全タスク二重実行はコストだけ増えて効果が薄くなりがちです。

観測すべき指標

• エージェント生成差分の障害流出率
• PRレビュー平均時間
• ロールバック率
• 出自情報付きコミット比率

指標が悪化したら、ツール追加より先に並列度を落とす判断が有効です。

導入ロードマップ（4週間）

• Week1: docs/test限定で試験運用
• Week2: 低リスクコードへ拡張
• Week3: 高リスク領域のみセカンドオピニオン
• Week4: 運用スコアカードを公開しルール更新

まとめ

/fleetは開発速度を上げる強力な武器ですが、統制なしでは品質を下げます。エージェントを「超高速なジュニア開発者」と捉え、境界・検証・責任追跡を先に整備することが、持続的な導入の条件です。