GitHub Copilot code review は、2026年7月29日に agent skills と MCP server 連携が一般提供になり、Pull Request のレビュー時に社内標準や外部システムの読み取りコンテキストを持ち込めるようになりました。今回の更新で重要なのは、単にレビュー精度が上がることではありません。どの設定をどこで管理するか、MCP が read-only に制限される点、レビュー利用時の課金が AI credits と GitHub Actions minutes の二段で発生する点まで押さえないと、情シスや開発基盤チームの運用設計がぶれやすいことです。この記事では、7月29日時点の公式情報だけを前提に、導入前に確認すべき論点を整理します。
7月29日のGAで何が変わったか
GitHub公式Changelogでは、Copilot code review で agent skills と MCP servers が Copilot Pro、Pro+、Business、Enterprise 向けに general availability になったと案内されています。skills は `.github/skills` 配下の `SKILL.md` を読み込み、リポジトリ固有のレビュー観点や社内標準を追加する仕組みです。MCP は issue tracker、documentation systems、service catalogs など第三者・社内システムの情報をレビュー時に引くための接続で、既存の Copilot cloud agent 用設定をそのまま code review にも適用できます。今回のGAで、preview利用中の設定は基本的にそのまま継続し、新規利用者は repository settings 側で MCP を設定し、Secrets and variables の Agents に認証情報を置く流れが公式化されました。
導入前に最初に確認すべき3項目
1つ目は、レビューで参照させたい情報が何かを決めることです。コーディング規約や設計原則を読ませたいなら skills や `AGENTS.md`、ファイル別の追加ルールなら `.github/instructions` が向いています。2つ目は、MCP に渡す対象が本当に read-only で足りるかの確認です。公式Changelogでは、Copilot code review が実行する MCP tool call は read-only に制限されると明記されています。レビュー中にチケット更新やコメント書き込みまでさせたい設計は、そのままでは成立しません。3つ目は、誰負担でコストが立つかです。GitHub Docs では code review が AI credits に加えて GitHub Actions minutes も消費すると説明されており、請求の見え方を事前に決めておかないと、リポジトリ管理者と経理の認識がずれやすくなります。
レビュー観点の標準化や、既存の issue・障害番号とPull Requestをつないだ確認導線を整えたい場合は、先に要件を整理したうえで導入設計できます。詳細の相談は HelloCraftAIのお問い合わせページ から受け付けています。
agent skillsはどこまで効くのか
GitHub Docs の agent skills 概念ページでは、skills は instructions、scripts、resources を束ねたフォルダとして定義されています。Copilot code review でも relevant と判断されれば自動で使われますが、レビュー用途だと伝わる名前や説明にした方が使われやすいと明記されています。たとえば `code-review` のようなディレクトリ名にして、セキュリティ観点、テスト観点、可読性観点を `SKILL.md` に分けると、単なる長い copilot-instructions より運用しやすくなります。また、Docs では pull request の head branch にある instructions や skills が読まれると説明されています。つまり本番反映前に、同じPRの中で review skill の効き方を試せるのが実務上の利点です。
MCP連携で押さえるべき制約
MCP 側の強みは、コード差分だけでは分からない周辺文脈を PR レビューに持ち込めることです。Issue key が PR 説明に書かれていれば、関連チケットやインシデント情報を参照した上でコメントさせやすくなります。ただし、GitHub Docs と Changelog の両方で共通している注意点は、code review の MCP は repository-level 設定で cloud agent と共通管理されること、そして PR review 用の MCP 利用は既定で有効だということです。cloud agent では使いたいが PR レビューには使わせたくない場合、repository settings の『Allow Copilot to use MCP tools when reviewing pull requests』を明示的に切る必要があります。セキュリティ・法務レビューでは、この切り分けを見落としやすいです。
課金と運用責任はどう見るべきか
GitHub Docs の models and pricing では、Copilot code review は利用モデルをユーザーが選べず、レビューごとに token consumption が AI credits として課金され、さらに agentic infrastructure 分の GitHub Actions minutes も消費すると説明されています。しかも code review で使うモデルは自動選択で非開示のため、チャットのように『このモデルだからこの単価』と単純には読めません。Business や Enterprise で自動レビューを有効化する場合は、誰がレビューを要求したか、PR author に課金が乗るのか、Copilot seat を持たない利用者の追加利用をどう扱うかまで設計しておくべきです。利用部門にコスト配賦したい組織では、AI credits だけでなく `copilot-pull-request-reviewer` ワークフローの GitHub Actions metrics も合わせて見る運用が現実的です。
導入時に失敗しやすいパターン
失敗パターンは大きく4つあります。第1に、instructions と skills と AGENTS.md の役割分担を決めずに全部へ同じルールを書くことです。公式Docsは、repository-wide のCopilot向け指示、path-specific instructions、共有エージェントルール、task-specific skills を分けて考える前提です。第2に、MCP をつないだだけで精度が上がると期待することです。Docs では、PR description に issue key や incident ID を書くなど、Copilot が参照先を判断しやすいシグナルが必要だとされています。第3に、read-only 制約を忘れて『レビュー時に自動でチケット更新までやる』設計にしてしまうことです。第4に、GA だから人手レビューを減らしすぎることです。GitHub Docs 自体が、Copilot はすべての問題を見つける保証はなく、人間のレビューで補完すべきだと明記しています。
中堅企業がまず取るべき導入手順
最初の一歩としては、1つのリポジトリで review-focused な skill を1個だけ置き、`AGENTS.md` にはレビュー全体の原則、`.github/instructions` には言語やディレクトリ別ルールを書く形が扱いやすいです。MCP は issue tracker か社内ドキュメントのどちらか一系統から始め、PR description に参照IDを必ず入れる運用を決めると、使われ方の検証がしやすくなります。次に、リポジトリ設定で MCP の PR review 利用が有効なままになっているか、逆に止めるべきリポジトリでは無効化されているかを確認します。最後に、1週間だけ pilot 期間を置き、attribution 付きのレビューコメントが実際にどの skill や MCP から生成されたかを見て、期待した観点が効いているかを調整すると失敗しにくいです。
よくある質問
Q. Copilot code review で使うモデルは選べますか。A. いいえ。GitHub Docs では purpose-built な product として、モデル切替はサポートされず、自動選択かつ非開示と説明されています。Q. MCP は既存の cloud agent 設定を流用できますか。A. はい。repository-level の MCP 設定は cloud agent と code review に共通適用されます。Q. PRレビュー中に MCP で外部システムを書き換えられますか。A. できません。code review の MCP tool call は read-only に制限されます。Q. これで人間レビューは不要になりますか。A. なりません。GitHub Docs でも、人間による検証と補完を前提に使うよう案内されています。
いま確認しておくべき結論
今回のGAは、『Copilotに社内文脈を読ませる』流れがPRレビューまで正式拡張された更新です。実務では、skill の配置、MCP の read-only 制約、PR説明への参照ID記載、AI credits と GitHub Actions minutes の二重コスト、この4点を同時に設計できるかで導入成否が分かれます。GitHub Copilot を全社展開する前に、まずは1リポジトリで review skill とMCPの効きを測り、コメント attribution とコスト計測が回る状態を作るのが安全です。設定整理やPoC設計を急ぎたい場合は、
→ HelloCraftAIに相談する から要件整理や導入設計の相談ができます。
