Copilot code reviewの実行環境とcustom instructionsの扱いが変わった。PRのhead branchにある指示をmerge前に試せ、専用workflowで依存やrunnerを準備できる一方、レビュー対象branchが実行条件へ影響する範囲も広がる。firewallはGitHub-hosted環境で既定有効だがself-hosted runnerには適用されない。利便性だけでなく、誰が指示・setup・networkを変更できるかを再設計する更新である。
何が変わったか
Copilot code reviewはcopilot-instructions.md、*.instructions.md、agent skills、AGENTS.mdをPRのbase branchではなくhead branchから読むようになった。REVIEW.md、GEMINI.md、CLAUDE.mdにも対応する。.github/workflows/copilot-code-review.ymlでreview専用のsetup stepsとrepository-level runnerを定義でき、存在しない場合はcopilot-setup-steps.ymlへfallbackする。network firewallは既定有効でcloud agentとは別に設定できる。
変更前後の差
従来はbase branchの指示が前提で、feature branchでreview instructionを試すにはmergeが必要だった。runnerとnetwork設定もcloud agentと共有する部分があった。新仕様ではreviewだけを独立調整できる。ただしhead branch由来のfileを信頼してよいか、外部contributorのPRでsetupがどう扱われるか、self-hosted runnerで同じ隔離が得られるかを判断する必要がある。
誰に影響するか
repositoryごとにreview基準、build tool、code generator、static analysis、private packageを使うteamが対象である。organization管理者はrunner typeとinternet accessをcloud agentから分離して設定する。security部門はPR作者が変更できるinstructionと、保護されたworkflow・secret・runnerの境界を確認する。OSSではfork PRと内部PRを同じ信頼度で扱わない設計が必要になる。
対応期限
強制移行期限はない。firewallは既定有効のため、外部package registryや社内serviceへ接続するreviewが失敗していないか確認する。self-hosted runnerはfirewall非対応なので「既定で保護された」と誤認しない。organization画面でcode reviewとcloud agentのrunner設定が分割されたため、現在値を早期に棚卸しする。
必要な対応
instruction fileをcodeとしてreviewし、CODEOWNERSやbranch protectionで重要変更を承認制にする。copilot-code-review.ymlは必要なtoolだけを導入し、version pin、checksum、最小権限を使う。internet accessはallowlistで評価し、不要なら閉じる。self-hosted runnerはephemeral化、network segmentation、credential cleanupを行い、fallback workflowも確認する。
実装・移行手順
- instruction、setup workflow、runner、internet accessを一覧化する。
- review専用workflowをcloud agent設定から分離する。
- head branchでinstruction変更のtest PRを作る。
- firewall有効状態で依存解決と解析を試す。
- fork PR、内部PR、bot PRでsecret挙動を比較する。
- self-hosted runnerへ隔離・消去・監査logを追加する。
失敗しやすい点
複数のinstruction fileが読まれるため、矛盾した指示が残るとreview品質が不安定になる。head branchから読むことを、PR作者へ自由にsystem instructionを与えることと解釈してはいけない。fallbackのcopilot-setup-steps.ymlが古い依存を導入する場合もある。firewallでpackage downloadを許可せず、reviewが浅くなることにも注意する。
リスク
setup stepはsupply-chain攻撃、dependency confusion、credential exposureの入口になり得る。self-hosted runnerでfirewallがないままuntrusted PRを処理すると内部networkへの到達範囲が広がる。逆にnetworkを過度に閉じるとcompilerやregistryへ接続できず誤ったreviewを返す。AI reviewを唯一の承認者にしてはならない。
評価方法
代表的なbug、security issue、style違反、generated file、large diffを含むGolden PRを用意し、指摘精度、false positive、見逃し、実行時間、network request、runner costを比較する。instruction変更前後を同じPRで再実行し、firewall logとsetup logを保存して許可domainと実際の通信を照合する。
ロールバック
専用workflowを削除すると既存のcopilot-setup-steps.ymlへfallbackする可能性があるため、削除前に内容を確認する。問題があればrunnerをGitHub-hosted標準へ戻し、internet accessを既知の設定へ復元し、instruction変更をrevertする。self-hosted runner利用を止めても、人間reviewと必須CIを維持する。
編集部の見解
この更新はcustomization強化であると同時に、Copilot code reviewが本格的なCI workloadへ近づいたことを示す。精度向上の鍵は長い指示ではなく、再現可能なsetupと狭いnetwork、評価用PRである。特にself-hosted runnerのfirewall例外は導入速度より先に監査すべき論点だ。
実務チェックリスト
- instruction fileの所在と優先関係を確認した
- 重要instructionをCODEOWNERS対象にした
- 専用workflowを最小構成にした
- 依存versionとdownload元を固定した
- firewallの実効allowlistを確認した
- self-hosted runnerの隔離と消去を確認した
- fork PRで権限・secret挙動を試験した
- 人間reviewと必須CIを残した