GitHub Copilot Cloud Agent Runner Governance: Enterprise Playbook

GitHub Copilot cloud agent の組織レベル Runner 制御は、企業運用にとって実装効率よりも統制面での価値が大きい更新です。組織側で既定 Runner を設定し、必要ならリポジトリ側の上書きを禁止できるため、「チームごとに勝手に実行基盤が変わる」状態を止められます。

参考: https://github.blog/changelog/2026-04-03-organization-runner-controls-for-copilot-cloud-agent/。

従来運用が抱えていた問題

リポジトリごとの copilot-setup-steps.yml は PoC では有効ですが、全社展開で次の問題が出ます。

• Runner 選択基準がチーム依存になる
• セキュリティ境界と性能要件が混在する
• 監査時に証跡追跡が重い
• 例外運用が恒常化して標準化が進まない

実務で使える3レーン設計

1. Aレーン（標準 hosted）: ドキュメント修正、静的解析、軽量変更
2. Bレーン（large hosted）: ビルドやテストが重い案件
3. Cレーン（self-hosted）: 内部 API 依存、規制対象、閉域必須ワークロード

この分類を先に決め、組織既定値とロック方針を組み合わせるのが安全です。

セキュリティ統制の必須セット

Runner 制御だけでは不十分です。以下を同時導入します。

• OIDC で短命資格情報化
• self-hosted の外向き通信先制限
• 参照資格情報とデプロイ資格情報の分離
• ジョブIDと承認IDの監査ひも付け

コスト管理にも効く

基盤を標準化すると、比較可能な指標が揃います。

• タスク単価
• PR マージあたりコスト
• 待ち時間と実行時間の分解
• 失敗ジョブの再実行コスト

感覚ではなくデータで例外判断できるようになります。

まとめ

今回の更新の本質は「AIエージェント実行場所の主導権を組織が取り戻すこと」です。CI 設定変更としてではなく実行基盤設計として扱うことで、導入速度と統制を両立できます。