GitHub Copilot code reviewに、組織単位のrunner type設定、content exclusion対応、repository custom instructionsの文字数制限撤廃が追加された。2026年6月12日のGitHub Changelogで告知された更新で、開発者個人の使い勝手よりも、組織管理者がレビュー実行環境と参照範囲をそろえやすくなった点が大きい。
ただし、これは「Copilotにレビューを任せれば終わり」という話ではない。Copilot code reviewはGitHub Actionsを使ってagentic capabilitiesを実行するため、private repositoryではActions minutes、runner type、larger runnerの分単価、self-hosted runnerの管理責任を分けて見る必要がある。content exclusionも、秘密情報対策の万能設定ではなく、Copilotがレビュー時に利用する文脈を制御するための設定として扱うのが安全だ。
本稿では、2026年6月14日JST時点のGitHub ChangelogとGitHub Docsをもとに、GitHub組織管理者、Enterprise管理者、リポジトリ管理者が最初に確認すべき順番を整理する。需要シグナルとしては、GitHub ChangelogでCopilotとActions関連の更新が6月11日から12日に続いていることが強い。コミュニティ上の課金不安や反応は、読者の関心を示す材料にとどめ、仕様確認の根拠には使わない。
3行まとめ
このテーマをもう少し広げて見るなら、GitHub Actionsのself-hosted runnerに最低バージョン適用へ：Data Residencyは7月31日、Enterprise Cloudは9月25日の確認ポイント と GitHub ActionsはNode 24既定へ：Node 20非推奨、runner更新、self-hosted確認ポイント も合わせて確認してください。Copilot code reviewのrunner設定を変える前に、self-hosted runner側の最低バージョンと30日更新条件を確認できます。
組織単位で既定runnerを設定し、必要に応じてリポジトリ側の上書きを止められます。
Copilot code reviewがrepository、organization、enterpriseの除外設定を尊重します。
文字数制限撤廃よりも、全体指示、パス別指示、agent向け指示の分け方が重要です。
3つの更新は同じCopilot code review周辺の話でも、費用、参照範囲、レビュー観点という別々の管理課題です。
- GitHub Copilot code reviewは、組織単位でrunner typeを設定し、必要ならリポジトリ側の上書きを止められるようになった。設定はCopilot code reviewだけでなくCopilot cloud agentにも関係し得る。
- content exclusionは、repository、organization、enterpriseレベルのCopilot除外設定をCopilot code reviewが尊重する更新だが、Copilot CLI、Copilot cloud agent、IDEのAgent modeまで同じように効くとは読まない。
- custom instructionsは文字数制限撤廃で長く書けるようになったが、重要なのは長文化ではなく、repository-wide、path-specific、agent向け指示の分割と、base branch側の指示を使う運用確認だ。
何が変わったかを3つに分ける
実行場所、Actions minutes、runner性能、cloud agentへの影響を確認します。
レビュー時にCopilotへ渡すrepository contextと、除外パスの境界を確認します。
レビュー観点、チーム標準、ファイル種別ごとの指示をどこに置くかを確認します。
runnerは実行基盤、content exclusionは参照範囲、custom instructionsは判断基準の話として分けると整理しやすくなります。
今回のGitHub Changelogは、Copilot code reviewの新しい構成と制御を3つに分けて説明している。組織単位のrunner controls、Copilot content exclusion support、repository custom instructionsのcharacter limit removalだ。
管理者目線では、この3つを一括で「Copilot code reviewの改善」と読まない方がよい。runnerは実行場所と費用に関わる。content exclusionはレビュー時に渡す文脈と境界に関わる。custom instructionsはレビュー観点、チーム標準、ファイル種別ごとの指示に関わる。それぞれ担当者も確認ログも違う。
runnerは実行場所と費用の話
GitHub Docsでは、Copilot code reviewがagentic capabilitiesを実行するためにGitHub Actionsを使うと説明している。既定ではGitHub-hosted runnerを使う。private repositoryのレビューでは、Actions minutesが既存のプラン枠から消費され、枠を超えると標準のGitHub Actions料金で請求される可能性がある。
根拠
2026年6月12日のChangelogでは、Copilot code reviewのrunner typeをorganization-levelで設定できるようになったと説明している。組織管理者は、全リポジトリで使うdefault runnerを設定でき、個別リポジトリの設定を上書きさせないlockも選べる。
注意点
runner typeの設定は、Copilot code reviewだけの孤立した設定ではない。GitHub Docsでは、organization-level runner typeがCopilot code reviewとCopilot cloud agentの両方に適用されると説明されている。cloud agentを使っているチームが別にいる場合、code review側の都合だけで変更すると、別のagentic workflowにも影響する。
content exclusionは参照範囲の話
content exclusion対応により、Copilot code reviewはrepository、organization、enterpriseレベルのCopilot content exclusion設定を尊重するようになった。リポジトリ管理者は、repository settingsでpath-based rulesを使って除外パスを設定できる。
根拠
GitHub Docsのcontent exclusionページでは、repository administrators、organization owners、enterprise ownersがcontent exclusion settingsを管理できると説明されている。Maintain権限のユーザーは表示できるが編集はできない。対象はCopilot BusinessまたはCopilot Enterpriseの組織向け機能として示されている。
注意点
content exclusionは「秘密情報が漏れないことを保証する機能」として雑に扱うと危ない。除外したファイルやディレクトリはCopilotのレビュー文脈から外れるため、レビュー品質にも影響する。たとえば設定ファイル、schema、生成コード、private API wrapperを除外すると、Copilot code reviewが変更の背景を読み取れず、浅いコメントになる可能性がある。
custom instructionsはレビュー観点の話
GitHub Changelogでは、Copilot code reviewが.github配下のcopilot-instructions.mdや*.instructions.mdを読む際、従来の4000文字制限で読み取りを止めていた制約がなくなったと説明されている。これにより、チーム固有のレビュー観点をより詳しく書ける。
評価基準
文字数制限が外れたからといって、1ファイルに長大な社内規約を貼るのがよいとは限らない。本文の目的は、長く書けるかではなく、何をrepository-wideに置き、何をpath-specificに分け、どのagentには使わせないかを決めることだ。
runner設定は組織既定から確認する
runnerの選択はレビュー品質だけでなく、Actions費用、ネットワーク境界、運用責任にもつながります。
runner設定は、最初に組織単位の既定を決めるか、リポジトリごとの設定に任せるかを分けて考える。GitHub Docsでは、organization ownersがCopilot code reviewとCopilot cloud agentのdefault runner typeを設定でき、個別リポジトリの上書きを許すかどうかも制御できる。
まず標準runner、larger runner、self-hostedを分ける
標準のGitHub-hosted runnerで十分な組織なら、設定変更の主目的は統制よりも可視化になる。一方、レビューに大きなリポジトリ文脈が必要なチーム、private networkingを使いたいチーム、処理性能を上げたいチームは、larger GitHub-hosted runnerを検討する余地がある。GitHub Docsでは、larger runnerはCPU、メモリ、ディスク、Azure private networkingなどの面で性能や機能を増やせるが、より高いper-minute rateで請求されると説明している。
確認項目
最初に見る項目は、対象組織、対象リポジトリ、review対象PRの頻度、private repository比率、既存のActions minutes使用量、larger runnerを使う場合の予算枠だ。ここを見ずにrunnerだけ先に強化すると、レビュー品質より先に費用監視が破綻する。
self-hosted runnerはARC前提で読む
Copilot code reviewをself-hosted runnerで動かす場合、GitHub DocsではARC、つまりActions Runner Controllerで管理されたscale setを使う手順が示されている。Docsには、ARCがCopilot code reviewのself-hostingで公式にサポートされる唯一の解だとする注意がある。互換性としてUbuntu x64 Linux runnerが求められる点も見落とせない。
注意点
self-hosted runnerを使う理由は、社内リソースへのアクセス、ネットワーク境界、性能、監査などが中心になる。ただし、runnerを自前にすると、runner image、OS、ネットワーク、更新、ログ、障害復旧まで管理対象になる。Copilot code reviewに広いネットワークアクセスを与えないためのfirewall設計も必要だ。
GitHub Docsでは、standard hosts required for GitHub Actions self-hosted runnersに加えて、api.githubcopilot.com、uploads.github.com、user-images.githubusercontent.comへの接続許可が示されている。閉域環境では、ここが最初の詰まりどころになる。
組織ロックは便利だが強い設定
organization-level runner typeの設定では、組織全体の既定を置ける。さらに、repositoriesがcopilot-setup-steps.ymlでrunner typeをカスタマイズできるかどうかを止められる。これは統制上は便利だが、いきなり全組織でlockすると、特殊なリポジトリや検証用runnerを使っていたチームが困る可能性がある。
評価基準
最初の1週間は、組織全体でlockする前に、代表的な3種類のリポジトリで試すのが現実的だ。標準的なアプリ、巨大なmonorepo、社内リソースに接続するリポジトリを分け、レビュー時間、失敗率、Actions minutes、ネットワーク遮断の有無を見てから、組織既定と上書き許可を決めたい。
このrunner文脈は、GitHub Actions側の運用とも近い。self-hosted runnerの最低バージョン適用を追っている組織は、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/msft-49-github-actions-self-hosted-runner-minimum-version-enforcement/">GitHub Actionsのself-hosted runner最低バージョン適用の確認ポイント</a>も合わせて見ると、runner更新とCopilot code review実行環境を同じ棚卸しに載せやすい。
content exclusionは除外パスの棚卸しから始める
- 1見せてはいけないファイル
秘密情報、社外に出せない設計、契約上制限される素材などを優先して確認します。
- 2レビューに不要なファイル
生成物、巨大なサンプル、古い移行コードなど、指摘品質に寄与しにくい対象を分けます。
- 3見せないと品質が落ちるファイル
migration、feature flag、認可方針、テスト基盤など、差分理解に必要な文脈を残します。
- 4機能ごとの参照範囲確認
Copilot code reviewに効く設定と、CLI、cloud agent、IDE Agent modeの扱いを混同しません。
content exclusionは安全性を高める一方で、周辺文脈を落とすとレビューが浅くなる場合があります。
content exclusion対応は、管理者にとって歓迎しやすい更新だ。ただし、実務で難しいのは設定画面を開くことではなく、何を除外し、何を残すかを決めることだ。
repository、organization、enterpriseを分ける
repository settingsで除外するものは、そのリポジトリ固有の事情に向く。たとえば、生成物、古い移行コード、巨大なサンプルデータ、レビュー文脈に不要なディレクトリなどだ。organization settingsは、複数リポジトリで共通する秘密情報パターン、社内標準の除外対象、特定のrepo pathの統制に向く。enterprise settingsは、複数organizationにまたがる方針に使う。
確認項目
棚卸しでは、次の4つを分けたい。Copilotに見せてはいけないファイル。レビューに不要なファイル。見せないとレビュー品質が落ちるファイル。別のセキュリティ統制で守るべきファイル。この分け方をしないと、除外対象が広がりすぎる。
除外はレビュー品質にも効く
Copilot code reviewは変更差分だけでなく、必要に応じて周辺のrepository contextを使う。content exclusionで周辺文脈を落とすと、レビューコメントが安全側に浅くなることがある。たとえば、database migrationを見せずにmodel変更だけを見せる、feature flag定義を見せずに利用箇所だけを見せる、security checklistを除外して認可コードだけを見せる、といった状態だ。
注意点
除外ルールを増やした後は、最低1つのPRでレビュー結果を見比べる必要がある。除外前後で、Copilotが同じ問題を指摘できるか、必要な文脈を誤っていないか、不要なコメントが増えていないかを見る。content exclusionは「設定して終わり」ではなく、レビュー品質の回帰確認まで含めて運用する。
対象外機能を混同しない
GitHub Docsのcontent exclusionページには、GitHub Copilot CLI、Copilot cloud agent、IDEのAgent mode in Copilot Chatではcontent exclusionをサポートしないという注意がある。一方、2026年6月12日のChangelogでは、Copilot code reviewがcontent exclusion設定を尊重するようになったと説明している。
切り分け
ここは誤読しやすい。Copilot code reviewに効くようになったからといって、Copilotのすべてのagentic機能に同じ除外設定が効くとは限らない。Copilot cloud agent、Copilot CLI、IDE Agent modeを併用する組織は、同じリポジトリでも機能ごとに参照範囲を確認する必要がある。GitHub Agentic WorkflowsやCopilot cloud agentの運用を並行して見ている場合は、<a href="https://msft-watch.blog.mo-gmo.com/msft-47-github-agentic-workflows-public-preview-actions-github-token-cost-controls/">GitHub Agentic Workflowsの権限と課金管理の確認ポイント</a>も近い文脈になる。
custom instructionsは長くする前に分ける
- 1repository-wide
`.github/copilot-instructions.md`に、全ファイル共通のレビュー方針や避けたい実装パターンを置きます。
- 2path-specific
`.github/instructions`配下で`applyTo`を使い、技術やディレクトリごとの観点を分けます。
- 3base branch
PRレビューではbase branch側のinstructionsが使われるため、導入順序を確認します。
- 4excludeAgent
code review向け、cloud agent向け、両方に効かせる指示を分けて扱います。
長いinstructionsを1か所に集めるより、利用先と対象パスで分ける方がレビュー結果を検証しやすくなります。
repository custom instructionsの文字数制限撤廃は、レビュー観点を丁寧に渡したいチームには便利だ。とはいえ、instructionsは長いほどよいわけではない。大事なのは、全体に効く指示、特定パスだけに効く指示、agent向けの指示を分けることだ。
repository-wideとpath-specificを分ける
GitHub Docsでは、repository-wide custom instructionsは.github/copilot-instructions.mdに置くと説明されている。これはrepository全体に共通する方針に向く。たとえば、レビュー時の言語、テスト方針、避けたい実装パターン、命名規則、セキュリティチェックリストへの参照などだ。
path-specific custom instructionsは、.github/instructions配下のNAME.instructions.mdに置く。frontmatterでapplyToを指定し、対象ファイルやディレクトリをglobで絞る。たとえば、app/models/*/.rb、*/.ts,*/.tsx、src/*/.pyのように、レビュー対象の種類で指示を変えられる。
評価基準
全体指示には、どのファイルにも当てはまる短い規約を置く。path-specificには、特定技術、特定ディレクトリ、特定責務のレビュー観点を置く。READMEや社内規約を丸ごと貼るのではなく、Copilot code reviewに期待する判断基準として書き直す。
base branch側のinstructionsを使う
Copilot code reviewは、pull requestをレビューするときにbase branch側のcustom instructionsを使う。たとえばmy-feature-branchからmainへmergeしようとするPRなら、main側のinstructionsが使われる。
注意点
これは導入初期に大事だ。feature branchでinstructionsを直しても、そのPRのレビューにすぐ効くとは限らない。まずbase branchにinstructionsを入れ、別PRで変更をレビューさせる、という順番にしないと「書いたのに効かない」という誤解が起きる。
excludeAgentで利用先を分ける
GitHub Docsでは、path-specific custom instructionsにexcludeAgentを指定し、code-reviewまたはcloud-agentで利用先を除外できると説明している。これは、Copilot code reviewとCopilot cloud agentの両方を使う組織で重要になる。
確認項目
レビューだけに効かせたい指示、cloud agentの実装作業だけに効かせたい指示、両方に効かせたい指示を分ける。たとえば、レビュー時の観点と、実装時の作業手順は似ているようで違う。reviewerに「この観点を見て」と伝える文と、agentに「この順に編集して」と伝える文を同じファイルに混ぜると、意図しないagentに強い指示が渡る。
code reviewの実行と再レビューの流れを押さえる
- Copilotをreviewerに選ぶ
GitHub.comのpull requestでReviewers menuからCopilotを選び、reviewを待ちます。
- Comment reviewとして受け取る
CopilotのreviewはApproveやRequest changesではなく、required approvalsには数えません。
- suggested changesを確認する
適用可能な提案は個別またはまとめてcommitでき、必要に応じてcloud agentへの実装依頼も検討します。
- push後に再レビューを依頼する
PRへ追加pushしても自動ではre-reviewされないため、必要なら手動で再依頼します。
Copilot code reviewは便利なreviewerですが、人間の承認、branch protection、CodeQLやSecret scanningのgateとは役割が異なります。
Copilot code reviewは、人間のレビューを置き換えるものではない。GitHub Docsでは、GitHub.com上のpull requestでReviewers menuからCopilotを選び、Copilotのreviewを待つ流れが説明されている。通常は30秒未満とされるが、組織のrunner type、リポジトリサイズ、利用状況で体感は変わる。
CopilotのreviewはComment扱い
Copilotはreviewを残すが、それはApproveやRequest changesではなくComment reviewだ。つまり、required approvalsには数えられず、mergeをblockしない。
注意点
この仕様は、導入時の期待値調整に効く。Copilotがコメントしたからといって、人間の承認が済んだわけではない。逆に、Copilotが重大な指摘をしていても、branch protection上はmerge可能な場合がある。Copilot code reviewを使うなら、人間reviewerの役割、required approvals、CodeQLやSecret scanningのgateを別に設計する必要がある。
セキュリティレビューと組み合わせるなら、<a href="https://msft-watch.blog.mo-gmo.com/msft-42-copilot-cli-security-review-public-preview-codeql-secret-scanning/">Copilot CLIの/security-review公開プレビューとCodeQL、Secret scanningの確認ポイント</a>も参照しやすい。Copilot code reviewは便利なreviewerだが、セキュリティ監査や静的解析そのものではない。
suggested changesとcloud agentを分ける
Copilotのfeedbackには、適用できるsuggested changesが含まれる場合がある。GitHub Docsでは、suggestionを個別またはまとめてcommitできると説明されている。さらに、toolsを有効にしている場合、Copilot cloud agentにsuggested changesの実装を依頼できる流れもある。
条件
cloud agentに実装させる場合、runner type、content exclusion、custom instructions、MCP servers、agent skillsなど、code review単体より多くの設定が絡む。今回のorganization-level runner設定がcloud agentにも関係し得るため、reviewだけの検証で終わらせず、agentがPRを作る運用まで使うかを分けて決めたい。
push後の再レビューは自動ではない
GitHub Docsでは、CopilotがreviewしたPRにpushしても、自動でre-reviewされないと説明されている。再レビューを求めるには、Reviewers menuのCopilot名の横にある操作から依頼する。さらに、re-review時には、解決済みやdownvote済みのコメントと同じ内容が再び出る可能性がある。
運用条件
レビュー運用では、初回レビュー、修正push、再レビュー依頼、コメント解決のタイミングを決めておく。特に、Copilotの同じコメントが再出現する可能性を知らないと、開発者が「解決したのにまた怒られた」と感じやすい。導入初期は、Copilotの指摘をCIの失敗と同じ扱いにせず、人間reviewerが採否を決める運用がよい。
費用と運用責任を分けて読む
self-hosted runnerはGitHub-hosted minutesを減らせても、基盤保守と監査の責任が残ります。
今回の更新は、レビュー品質と管理統制の話であると同時に、費用と責任の分担の話でもある。Copilot code reviewがGitHub Actionsを使う以上、runner typeを変えれば実行時間、待ち時間、Actions minutes、runner保守の見方が変わる。
Actions minutesとlarger runnerを分ける
GitHub Docsでは、private repositoryのreviewでActions minutesが消費され、included minutesを超えると標準のGitHub Actions rateで請求されると説明している。またlarger GitHub-hosted runnerは、標準runnerより高いper-minute rateで請求される可能性がある。
確認項目
管理者は、少なくとも次の表を分けて持つとよい。Copilot code reviewの利用回数。private repositoryでのreview回数。Actions minutesの消費量。larger runnerを使ったreview回数。self-hosted runnerを使う場合のインフラ費と保守工数。これを1つの「Copilot費用」としてまとめると、どこを抑えればよいのか分からなくなる。
Copilot code reviewの課金変更を広く見るなら、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/msft-14-github-copilot-code-review-actions-minutes/">GitHub Copilot code reviewのActions minutesとAI Creditsを分けて読む記事</a>も補助線になる。
self-hostedは無料化ではない
self-hosted runnerを選ぶと、GitHub-hosted runnerのminutesだけを見れば軽く見えることがある。しかし、実際にはrunner基盤の保守、Kubernetes、ARC、network egress、image更新、セキュリティ監視、障害対応が残る。reviewが増えたときにscale setがどう増えるか、失敗時に誰が見るかも必要だ。
評価基準
self-hostedを選ぶ理由が、費用だけなら慎重に見直したい。社内ネットワーク、private dependency、監査境界、性能要件があるなら合理性はある。だが、review workloadが軽い組織では、標準GitHub-hosted runnerのまま、content exclusionとcustom instructionsを整える方が先に効く場合もある。
AI CreditsやCopilot利用料とは別表で見る
GitHub Copilot全体ではAI Creditsやplanごとの利用枠を気にする場面が増えている。ただ、今回のrunner設定で直接見るべき費用は、Actions minutes、larger runnerのper-minute rate、self-hosted runnerの運用費だ。CopilotのplanやAI Creditsの話を同じ欄に混ぜると、レビューが高いのか、runnerが高いのか、agentic作業が高いのかが分からなくなる。
注意点
費用監視では、Copilot code review、Copilot cloud agent、Agentic Workflows、Copilot CLI、IDE利用を別の利用カテゴリとして見る。2026年6月はGitHub Copilot周辺の更新が多いため、月内の流れを追うなら<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">Microsoft 2026年6月重要トピックまとめ</a>に戻ると、GitHub、Windows、Azure、Microsoft 365 Copilotの動きを並べて確認できる。
最初の1週間で確認するチェックリスト
- 1日目: 現状を見える化
利用中リポジトリ、automatic review、private repository比率、Actions minutes、cloud agent利用の有無を一覧にします。
- 2-3日目: runnerを試す
標準runner、larger runner、self-hosted runnerの条件を比べ、review時間と失敗率を記録します。
- 4-5日目: 除外とinstructionsを試す
除外前後とinstructions追加後で、コメントの妥当性、誤検知、重複、修正しやすさを比べます。
- 6-7日目: 運用ルールに落とす
runner上書きの可否、除外ルールの承認者、instructions更新手順、再レビュー依頼の責任者を決めます。
最初から広いlock、広い除外、長いinstructionsを同時に入れると、どの設定が結果に効いたのか分かりにくくなります。
いきなり全組織でrunner lock、広いcontent exclusion、長いinstructionsを入れると、どれがレビュー結果に効いたのか分からなくなる。最初の1週間は、小さな検証リポジトリで設定を1つずつ変える方がよい。
1日目は現状を見える化する
最初に確認するのは、現在Copilot code reviewをどのリポジトリで使っているか、automatic reviewを有効にしているか、private repositoryでどれくらいreviewされているか、Actions minutesにどの程度影響しているかだ。さらに、Copilot cloud agentを使っているチームがいるかも確認する。
初動
組織管理者は、対象組織、対象リポジトリ、runner type、automatic reviewの有無、content exclusionの有無、custom instructionsの有無を一覧にする。ここで「誰も使っていないはず」と決めつけない。PRのreviewerにCopilotが入っているか、repository settingsに設定があるかを見れば、実際の利用が見えてくる。
2日目から3日目はrunnerを試す
次にrunner typeを試す。標準GitHub-hosted runnerで問題がないか。larger runnerに変えた場合にreview時間や費用がどう変わるか。self-hosted runnerにする場合にARC、Ubuntu x64、network allowlist、copilot-setup-steps.ymlがそろっているかを確認する。
評価基準
検証PRは、軽い差分だけでなく、複数ディレクトリにまたがる差分も1つ含める。Copilot code reviewが必要な文脈を拾えるか、review時間が極端に伸びないか、runner側で失敗しないか、Actions minutesやrunner rateの見方が明確かを記録する。
4日目から5日目は除外とinstructionsを試す
content exclusionは、最初から広く設定しない。まずは明確に不要なファイル、明確に見せたくないファイル、レビュー品質に必要なファイルを分ける。custom instructionsは、repository-wideに短い共通方針を置き、path-specificで一部ディレクトリだけに効く指示を試す。
確認項目
同じPRに対して、除外前、除外後、instructions追加後でCopilotのコメントを比較する。コメント数だけを見ず、指摘の妥当性、誤検知、重複、修正しやすさを見る。instructionsがbase branch側に入っているか、path-specificのapplyToが意図したファイルに当たっているか、excludeAgentで利用先を絞る必要がないかも確認する。
6日目から7日目は運用ルールに落とす
最後に、設定を運用ルールへ落とす。どのリポジトリは組織既定runnerを使うか。どのリポジトリは上書きを許すか。content exclusionの承認者は誰か。instructionsの変更は誰がreviewするか。Copilotのコメントをrequired checkのように扱わないことを、どこに書くか。
完了条件
1週間の検証が終わったら、組織向けの短い記録を残す。runner type、lockの有無、content exclusion方針、instructions配置、再レビュー依頼の手順、費用監視の見方、問い合わせ先。この記録がないまま機能だけ有効にすると、数週間後に「誰が何を決めたか」が分からなくなる。
GitHub Copilotの実行環境や隔離の考え方をもう少し広く見るなら、<a href="https://msft-watch.blog.mo-gmo.com/msft-23-github-copilot-sandboxes-public-preview-local-cloud-billing/">GitHub Copilot sandboxesのローカル、クラウド、課金の確認ポイント</a>も近い。code reviewだけでなく、agentic作業全体の実行場所を整理しやすくなる。
管理者向けの結論
Copilot code reviewだけでなく、Copilot cloud agentを使うチームへの影響も見ます。
content exclusionを広げる前後で、必要な指摘が落ちていないかをPRで比べます。
長文化する前に、repository-wide、path-specific、excludeAgentの使い分けを決めます。
Actions minutes、larger runner、self-hosted runner運用費を別々に追います。
Copilot code reviewは組織で管理しやすくなった分、設定変更の前後比較と責任分担がより重要になります。
今回の更新で、Copilot code reviewはチームごとの小さな設定から、組織で管理する機能へ一段進んだ。runnerを組織既定でそろえ、content exclusionで参照範囲を制御し、custom instructionsでレビュー観点を整えられるようになったからだ。
ただし、強い設定が増えた分、管理者の判断も増えている。runnerをlockする前にcloud agentへの影響を見る。content exclusionを広げる前にレビュー品質を比べる。instructionsを長くする前にpath-specificとexcludeAgentで分ける。Actions minutes、larger runner、self-hosted runner運用費を分けて見る。この順番を外さないことが大事だ。
Microsoft Watch JapanはMicrosoftおよびGitHubの非公式・非提携サイトであり、本稿は公開されているGitHub公式情報をもとにした整理です。Docs更新やChangelogの追跡を継続したい場合は、<a href="https://msft-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>と<a href="https://msft-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>をあわせて使えます。
次に読むなら
参照した主な情報源
- GitHub Changelog「Copilot code review: New configurations and controls」（2026年6月12日公開、2026年6月14日JST確認）
Copilot code review: New configurations and controls
- GitHub Docs「Configuring runners for GitHub Copilot code review」（2026年6月14日JST確認）
https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-runners
- GitHub Docs「Excluding content from GitHub Copilot」（2026年6月14日JST確認）
https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot
- GitHub Docs「Using GitHub Copilot code review」（2026年6月14日JST確認）
https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review
- GitHub Docs「Adding repository custom instructions for GitHub Copilot」（2026年6月14日JST確認）
https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
- Microsoft Watch Japan「2026年6月 重要トピックまとめ」
2026年6月 重要トピックまとめ