背景
Issueを割り当てるだけでPull Requestまで自律的に作成するGitHub Copilot Coding Agent（現在の正式名称：cloud agent）を調べたところ、エージェントモードとは実行場所も動き方も全く別物であり、暴走を防ぐための技術的な制約がいくつも組み込まれていることが分かりました。
1. 2026年4月1日に「coding agent」から「cloud agent」へ改称された
2025年〜2026年3月: GitHub Copilot coding agent
2026年4月1日〜: GitHub Copilot cloud agent（現行の正式名称）
互換性のため使用量メトリクスAPIでは旧フィールド名（used_copilot_coding_agent）が2026年8月1日まで残される予定ですが、現在の正式名称は「cloud agent」です。検索や研修資料では引き続き「Coding Agent」という呼称も広く使われているため、この名称のズレを知らないと同じ機能について調べているのに情報がかみ合わない、という状況が起こり得ます。
2. 1セッション最大59分・単一リポジトリ限定という実行時間・範囲の制約
- 1セッションの最大実行時間は59分
- 開始時に指定した単一リポジトリの中でのみ変更が可能（複数リポジトリ横断は不可）
- pushできるのは copilot/ から始まる名前のブランチのみ
これらの制約は意図しない大規模変更を防ぐガードレールとして機能しています。バックログの独立性の高いバグ修正や定型的なテスト追加には向きますが、59分を超える可能性がある大規模な実装や複数リポジトリにまたがる横断的な変更には不向きです。
3. Copilot自身は自分が作成したPRを承認・マージできない
- Copilot自身は自分のPRを承認・マージできない（第三者によるレビューが必須）
- Issueの作成者本人が最終承認者になることもできない、という運用が推奨されている
自己承認を構造的に禁止することで、AIが生成したコードが人間のレビューを経ずにマージされる事態を防いでいます。既存のブランチ保護ルール・必須ステータスチェック・CODEOWNERSもそのまま適用されるため、通常のPRレビューフローに自然に組み込まれる設計です。
4. FreeプランではCoding Agentが非対応、Business/Enterpriseは管理者の事前有効化が必須
Free: ✗ 非対応（コード補完・チャットのみ）
Pro以上: ✓ 対応（個人アカウントなので管理者設定不要）
Business/Enterprise: ✓ 対応（要：管理者による事前ポリシー有効化）
個人のPro/Pro+/Maxプランであれば組織の管理者設定を待たずすぐ使える一方、Business/Enterpriseでは自分のアカウントが有料でも組織側でポリシーがオフのままだと使えません。GHEC環境での研修・導入検討時は、事前に組織側のポリシー設定状況を確認しておく必要があります。
5. Enterprise ownerは4段階のポリシー状態から選択できる
1. Enabled everywhere → 全組織で有効化
2. Let organizations decide → 各組織の管理者に判断を委ねる
3. Enable for selected organizations → 特定の組織のみ有効化
4. （非表示/無効） → 全組織で無効化
2026年4月には組織のカスタムプロパティを使って条件に合致する組織だけを選んで有効化する機能も追加されており、部門やプロジェクトの属性に応じた段階的な展開が可能になっています。
まとめ
「59分」「単一リポジトリ」「自己承認不可」という3つの技術的制約が、cloud agentを安全に運用するための設計思想でした。エージェントモードが「隣に座って一緒にコードを書く同僚」だとすれば、cloud agentは「Issueを渡すと自分で調べて実装してPRを出してくる非同期の同僚」という区別が実務上のイメージとして分かりやすいです。