GitHub Copilot CLIチームは
どうやってCopilot CLIを
開発しているのか?

本日の出典

GitHub Product Roadmap Webinar（2026年3月）

• Mario（GitHub CPO）と Evan（CLI エンジニアリングマネジャー）が登壇
• GitHub自身がCopilotをどう使って開発しているかを紹介

今日はそのチームの取り組みとトレンドをお伝えします。

チームの全体像

• 週末もPRはマージされる
• PR増加でモノレポがボトルネックに → 別リポジトリに分離

トレンド① DX → Agent Experience

「開発者の生産性」から「エージェントの生産性」を最適化する時代へ

具体的にチームがやったこと:

エージェントがCI上でPRを開き、macOS/Linux/Windows横断で
E2Eテスト → 変更 → バグ発見を自動的にイテレーション。

トレンド② 技術的負債の増加

エージェント時代の技術的負債は「複利」で増える

eslint-ignoreをレガシーファイルに残したら…

→ エージェントがgrepでパターンを読み取り、新しいコード全体に複製

エージェントは統計的パターンマッチングマシン。
コードベースに存在する悪いパターンは増幅される。

結果: 1,500個のeslint-ignoreを手動 + エージェント支援で除去

→ コードベースの衛生状態がエージェントの出力品質を直接決める。
負債の放置コストは、エージェント利用で飛躍的に高くなる。

トレンド③ コードレビューが仕事の半分

チームは勤務時間の約50%（4〜5時間/日）をコードレビューに使っている

レビュー観点の変化

トレンド④ PRの形が変わる

エージェント時代では、PRの量が増え、形が変わる。

• 大きなPRは理解不能 → 5,000〜10,000行のPRは原則マージしない
• PRごとに「何を変えたか・なぜ変えたか・テストは十分か」を評価できるサイズに分割
• すべてのPRを人間がレビュー — 盲目的にマージしない
• 著者自身がまずセルフレビュー — レビュアーに投げる前に責任を持つ

以前より小さく、以前より多く、以前より意図を明確に。

トレンド⑤ テストこそが安全ネット

54%がテストコードである理由

エージェントが変更を検証するためのフィードバックループを作るため

問題 → 仮説 → コード変更 → テストで検証 → イテレーション

• エージェントがバグを繰り返し入れるエリア → 極端なレベルまでテストカバレッジを追加
• 本番に近い環境 + 適切にスコープされた認証情報が必須

トレンド⑥ プロトタイプ > 設計ドキュメント

3つの設計案で迷ったら？

1週間かけて設計ドキュメントを書く
3つ全部を1〜2時間でプロトタイプ → 実物で比較・検証

コードを書くこと自体は安い。捨てる前提で学ぶ。