PRが届いた。Copilotが書いて、Copilotが自分でレビューして、それから人間に送ってきた。
これはSFの話ではない。2026年2月26日のGitHub Blogで発表されたCopilot Coding Agentの新機能だ。AIが実装し、AIがレビューし、修正してからDraft PRとして人間に渡す——このループが実際に動いている。何が変わって、何が変わらないのかを整理する。
Workspace廃止からCoding Agent GAまで
経緯を1段落で整理しておく。
GitHub Copilot Workspaceは2024年に技術プレビューが始まった「ブラウザ上でコードを編集する」実験的プロダクトだったが、2025年5月30日に廃止された。後継のCopilot Coding Agentは2025年9月25日に一般提供（GA）となった。Issueに「Copilot」をアサインするだけで自律的にコーディングし、Draft PRを出してくれるエージェントだ。基本的な仕組みは先行記事で詳しく解説しているため、ここでは2026年2月のアップデートに絞って掘り下げる。
セルフレビューの仕組み——AIがAIにダメ出しする
今回のアップデートの核心は「PR提出前のセルフレビュー」だ。
従来のCoding Agentは、Issueをもとにコードを書いてDraft PRを出す——それだけだった。新しいフローはこうなる。コードを書く。自分でCopilot code reviewを実行する。フィードバックを受ける。必要であれば修正する。その後、人間にタグ付けしてDraft PRを提出する。
GitHubの公式ブログには実際の例が載っている。あるタスクで、エージェントが自分の文字列連結コードが過度に複雑だと検出し、PR提出前に修正した。タスクログからその瞬間——「Copilot code reviewを実行してフィードバックを適用した」——が確認できる。
「採点した自分の答案を先生に提出する」と聞くと疑わしく思えるかもしれない。答案を書いたのも採点したのも同じAIだ。見えないものは変わらず見えない。この限界については後述する。ただ、従来は「書いたものをそのまま出す」だったのが、「一度見直してから出す」に変わったことは事実だ。
6000万件——Copilotコードレビューの規模感
数字の話を先にしておく。
2026年3月5日のGitHub Blogによると、Copilotコードレビューは2025年4月のローンチ以来6000万件を突破した。10倍の成長だ。GitHub上のコードレビュー全体の5件に1件以上（20%超）がCopilot code reviewになっている。
興味深いのは設計思想だ。レビューの71%で実行可能なフィードバックを提示しているが、残り29%は何もコメントしない。「ノイズより沈黙を優先する」という判断だ。コメントするときは1レビューあたり平均5.1コメント。少なく見えるが、大量のどうでもいい指摘を出すより、本質的なものだけ出すほうが実用的だという方向性が見える。
高度な推論モデルを採用した結果、ポジティブフィードバック率が6%向上した。一方でレビュー速度は16%遅くなった。このトレードオフを「許容できる」と判断したことがわかる。精度を取って速度を犠牲にする選択だ。
12,000以上の組織がすべてのPRに自動レビューを設定している。「試した」ではなく「全PRに組み込んだ」組織がこれだけある。
モデルピッカーという選択肢
2026年2月初旬にPro/Pro+向け、2月19日にBusiness/Enterprise向けにモデルピッカーが提供された。Coding Agentが使うAIモデルをユーザーが選べるようになった。
利用可能なモデルは以下だ（2026年3月時点）。
| モデル | 特徴 |
|---|---|
| Auto | 可用性に基づいて自動最適化（管理者未設定時のデフォルト: Claude Sonnet 4.6） |
| Claude Opus 4.5 / 4.6 | 高精度。複雑な推論タスク向け |
| Claude Sonnet 4.5 / 4.6 | 精度と速度のバランス |
| GPT-5.1-Codex-Max | OpenAI高精度モデル |
| GPT-5.2-Codex / GPT-5.3-Codex | OpenAI系モデル |
どのモデルを選ぶかは、タスクの複雑さに応じて判断することになる。
❌ モデルをAutoにしたまま複雑なリファクタリングを依頼する
→ 可用性優先で軽量モデルが選ばれ、精度が出ないケースがある
✅ タスクの難易度に応じてモデルを使い分ける
- ユニットテスト追加: AutoまたはSonnet系（速度重視）
- 複雑な設計変更: Opus系（精度重視）
- 判断が難しい場合: Auto（自動最適化に任せる）
Autoにするとモデルの可用性に基づいて自動最適化される。管理者がモデルを有効化していない場合のデフォルトはClaude Sonnet 4.6だ。
セキュリティスキャン——無料で動くAdvanced Security
今回のアップデートではセキュリティスキャンも追加された。
コードスキャン、シークレットスキャン（APIキーやパスワードが混入していないか）、依存関係の脆弱性チェックがエージェントのワークフロー内で自動実行される。
公式ブログが明記しているのは、コードスキャンは通常GitHub Advanced Security（有料）の機能だが、Copilot Coding Agentでは無料で利用できるという点だ。AIが書いたコードに潜在するセキュリティ問題を、PR提出前に自動チェックする仕組みが無料で入ってくる。
ただしここでも「セルフレビューと同じ視点」の問題は残る。エージェントが書いたコードをエージェントが検査する。見落とした設計上の認可問題は、セキュリティスキャンでも検出できない。
セルフレビューが見えないもの——diff-basedの限界
「AIが自分でレビューする」と聞いて信頼しすぎるのは危険だ。構造的な限界がある。
Copilot code reviewはdiff-based（差分ベース）の分析だ。変更された部分を見る。変更されていない部分との整合性は確認しない。DEV Communityの分析が指摘するように、アーキテクチャ問題やクロスファイルの依存関係ミスは見逃しやすい。
PRの規模でも精度に差が出る。変更量が小さいほど有効なフィードバックを出しやすく、大規模なdiffになるほどノイズになりがちだ。ツールの問題ではなく、入力の複雑さの問題だ。
コードで見るとこうなる。
// ❌ Copilotが書き、Copilotがセルフレビューしたコード（例）
async function getOrderData(orderId: string) {
const order = await db.orders.findOne({ where: { id: orderId } });
return order;
}
// セルフレビューで検出: 型安全性、エラーハンドリング欠如
// セルフレビューで見逃す: userId と order.userId の一致確認（認可チェック）
// ✅ 人間のレビューで加えるべき視点
async function getOrderData(orderId: string, requestUserId: string) {
const order = await db.orders.findOne({ where: { id: orderId } });
if (!order) throw new NotFoundError("Order not found");
if (order.userId !== requestUserId) throw new ForbiddenError("Access denied");
return order;
}
// 「誰がこの注文データを取得していいか」はコードの外側（仕様）の問題
// diff-basedのレビューではコードの外側は見えない
「校正した自分の原稿を著者が自分で読む」状況に似ている。文法的な誤りは見つける。でも「この章の論旨がそもそも違う」には気づかない。同じ視点から見ているからだ。
セルフレビューを通過したPRは「スタイルと基本的なエラーハンドリングが一定水準に達している」と解釈するのが正確だ。「安全で設計として正しい」とは別の話になる。認可チェック、ビジネスロジックの整合性、クロスファイルの依存関係は人間が見る必要がある。
人間に残された役割——「確認者」から「設計判断者」へ
「AIがレビューするなら、人間は何をするのか」という問いに答えておく。
工場の品質チェックを組み立てた人が行う体制に近い。スピードは上がる。だが組み立てた人には見えないものがある。外から見た人間にしか気づけないものが残る。
人間のレビュアーに残る役割は「確認」ではなく「判断」だ。
「この機能をここに足すべきか」という問いに、AIは答えられない。コードに書かれていない仕様、チームの方針、ユーザーの期待——それらを総合して「この実装方針でよいか」を判断するのは人間だ。
セルフレビューが拾う問題と、人間が拾う問題を整理するとこうなる。
AIが「確認者」として機能することで、人間は「確認」から解放される。解放された分を「判断」に使う。これが理想的な分担だ。
カスタムエージェントとCLIハンドオフ
今回のアップデートには他にも追加がある。
カスタムエージェントだ。.github/agents/ 以下にファイルを置いて、チーム固有のワークフローを定義できる。例えばパフォーマンス最適化エージェントを定義して、変更前後でベンチマークを計測・比較させる——そういったことが可能になる。
# .github/agents/performance-optimizer.yml の概念例
name: performance-optimizer
description: "変更前後のベンチマーク計測を自動化する最適化エージェント"
steps:
- name: benchmark-before
run: npm run benchmark
- name: implement-changes
agent: copilot
- name: benchmark-after
run: npm run benchmark
- name: open-pr-with-results
CLIハンドオフも追加された。クラウドとローカル環境間で、コンテキストとセッションデータを保持したまま移行できる。「クラウドで始めた作業を、手元の環境に引き継いで続ける」という使い方が可能になる。
次に来る機能
公式ブログにはcoming soonとして記載がある。
private mode（リポジトリを参照せずに動作するプライバシー重視モード）、コーディング前のplanning（実装前に計画を立てて確認させる段階）、PR不要タスク（Issue要約やレポート生成のような、コードを書かずに完結するタスク）が対応予定だ。
PRを出さないタスクへの対応は興味深い。コーディング以外の作業——ドキュメント整理、調査、要約——をCoding Agentが担う方向に広がっていく。
「自分でレビューした」の重みを測る
Copilot Coding AgentがPRを出す前にセルフレビューを行うようになった事実は、一定の意味がある。粗い実装がそのまま人間に届く確率は下がる。基本的なエラーハンドリングやスタイル問題は事前に処理される。
ただ「AIが自分でレビューしたPRが来た」と聞いて、確認を省いてよい理由にはならない。見えないものは変わらず見えない。認可チェックはdiffの外にある。設計の判断はビジネスの文脈を要求する。
6000万件のコードレビュー実績が示すのは、AIレビューが「使われている」という事実だ。71%のレビューで実行可能なフィードバックが出る——逆に言えば29%は何も言わず、出てくるフィードバックも「コードの外側」は見えない。
「AIが自分でレビューした」と「人間がレビュー不要になった」は別の話だ。その区別を持った上で使うと、このツールの価値がはっきりする。
