GitHub Copilotは「補完」からエージェント型開発基盤へ進む

これは、開発者の操作モデルを変える。単に「次の式を補完してもらう」のではなく、「このAPI呼び出しを新しい形に直して」「このコンポーネントをリファクタして」「このエラー経路を調べて」といった、まとまりのある作業を依頼する方向に近づいている。開発者の仕事は、タスクの切り分け、計画の確認、差分レビュー、テストによる検証へ重心を移す。

複数ファイル編集は「勝手に書き換える」機能ではない

オートコンプリートと本格的なエージェントの橋渡しになるのが、複数ファイル編集だ。GitHubは2024年10月のVS Code向けCopilot更新で、github.copilot.chat.edits.enabled設定による複数ファイル編集のプレビューを導入し、ワークスペース内の複数ファイルに対してCopilotが変更を提案できる編集セッションを説明している。

ここでの設計思想は、「Copilotがリポジトリを黙って丸ごと書き換える」ことではない。GitHubの説明では、Copilotは変更案を提示し、それをエディタ上に反映し、開発者が周辺コードの文脈とともに確認できる。 MicrosoftのVisual Studio向けドキュメントでも、Copilot Editsはチャットとインラインレビューを組み合わせ、影響を受けるファイルの要約、提案内容、インライン差分、個別変更の承認・拒否を提供すると説明されている。

このレビュー面が弱いと、複数ファイル編集は実務で使いにくい。なぜなら、1つのファイルの変更がimport、型、テスト、暗黙の前提を壊すことがあるからだ。少なくとも公開資料で見る限り、Copilotの編集体験は「プロンプトを出す、提案を受ける、差分を見る、採用または却下する、さらに修正する」というループに近い。

Copilot Workspaceは「タスク」からリポジトリを見る

Copilot Workspaceも、同じ流れをGitHub上の作業管理に近づけるものだ。GitHub Nextのユーザーマニュアルは、Copilot Workspaceを「タスク中心」のAIアシスタントと説明し、リポジトリ、Issue、Pull Requestといったタスクの文脈を理解する、GitHubに深く統合された存在として位置づけている。

2025年2月のCopilot Workspace更新では、複数ファイルのコード生成や、大規模リポジトリの複雑な依存関係を扱うための「follow ups」とファイル検索改善が示された。follow upsはコードベース全体を確認し、追加対応が検出された場合に必要なファイルを自動編集すると説明されている。

実務的に言えば、「このIssueを直す」という依頼が、タスク理解、関連ファイルの特定、計画の作成・修正、変更生成、関連箇所の追加確認という流れに分解される。これは、単なる補完よりも「意図駆動のリファクタリング」に近い。ただし、最終的な安全性は依然としてレビューとバージョン管理の規律に依存する。

VS Codeはエージェント型Copilotの操作盤になっている

VS Code側の更新を見ると、Copilotがリポジトリ全体の文脈を扱う方向はさらに明確だ。2026年4月分のVS Code向けCopilot更新では、任意のワークスペースで意味に基づく検索ができること、GitHubのリポジトリやOrganizationをまたいだgrep風クエリが使えることが説明されている。 同じ更新では、チャット履歴を問い合わせる実験的な/chronicle、トークン使用量を抑えるプロンプトキャッシュや遅延ツール読み込み、エージェント向けのチャット内インライン差分も挙げられている。

2026年3月分の更新でも、完全自律型のAgentセッション向けAutopilotがパブリックプレビューとして紹介され、#codebaseツールが単一の自動管理インデックスに対して純粋なセマンティック検索を行うと説明されている。

エージェント型の開発支援では、モデルそのものの賢さだけでなく、必要な文脈をどれだけ適切に取りに行けるかが重要になる。意味検索、関連ファイルの把握、差分表示、過去チャットの参照は、カーソル位置だけを見る補完よりも、リポジトリ単位の作業に向いた土台になる。

モデル選択も開発フローの一部になった

Copilotは、単一モデルに固定された補完機能ではなく、複数モデルを使い分ける開発環境にもなっている。GitHubのモデル比較ドキュメントは、Copilotが複数のAIモデルをサポートし、選択したモデルがCopilot Chatの回答やインライン提案の品質・関連性に影響すると説明している。 また、モデルによってレイテンシ、ハルシネーションの傾向、特定タスクでの性能が異なるともしている。

つまり、モデル選択は裏側の実装詳細ではなくなりつつある。日常的な補完には応答の速いモデルが向き、デバッグ、リファクタリング、複数ステップのAgent作業には推論能力の高いモデルが向く、という判断が必要になる。対応IDEのCopilot Chatでは、利用可能性に応じてモデルを自動選択するAutoモードがあり、手動で別モデルを選ぶこともできる。

BYOK、つまりBring Your Own Keyの動きも同じ方向を示している。ただし、ここも範囲を慎重に見るべきだ。VS Code 1.99のリリースノートでは、Copilot ProとCopilot Freeユーザー向けに、自分のAPIキーでAzure、Anthropic、Gemini、OpenAI、Ollama、OpenRouterなどのプロバイダーを使えるBYOKプレビューが説明されている。同時に、Copilot BusinessとEnterprise向けサポートは検討中とされていた。 これは、特定のVS Code/Copilot文脈でのBYOKプレビューであり、すべてのCopilotプランで任意のモデル持ち込みが一般提供されていることを意味するものではない。

モデル廃止は、もはや小さな変更ではない

Copilotがチャット、インライン編集、Ask mode、Agent mode、補完をまたぐようになるほど、モデル変更の影響範囲は広がる。GitHubの2026年5月のChangelogでは、Grok Code Fast 1が2026年5月15日にCopilot Chat、インライン編集、Ask mode、Agent mode、コード補完を含むすべてのGitHub Copilot体験で廃止されると説明されている。 同じChangelogでは、GPT-4.1も2026年6月1日に同じCopilot体験全体で廃止予定とされている。

これは一度きりの話ではない。GitHubは2026年1月のChangelogで、高速で高品質なCopilot体験のために古いモデルを定期的に評価・廃止し、より新しいモデルへ移すと説明し、Copilot Chat、インライン編集、Ask mode、Agent mode、コード補完にまたがるモデル廃止を示していた。

第三者のリリース要約では、GPT-4.1廃止に対する推奨代替としてGPT-5.5が挙げられている。 ただし、一次情報として確認しやすいのはモデル廃止そのものであり、すべての移行経路が同じ強さで確認できるわけではない。特に、GPT-5.2からGPT-5.5へ包括的に移行するという前提は、提供資料からは明確に裏づけられない。運用計画を立てるなら、GitHubのChangelogとCopilot管理設定で、利用可能モデルとポリシーを直接確認すべきだ。

品質への不安は、単なる気分の問題ではない

開発者がモデル変更を気にするのは、名前が変わるからではない。GitHub自身が、モデル選択はCopilotの出力品質と関連性に影響し、モデルごとにレイテンシ、ハルシネーション、タスク別性能が異なると説明している。 あるモデルがチャット、インライン編集、Agent mode、補完から外れるなら、日々の開発体験のあちこちで、提案の速さ、説明の信頼性、差分レビューの負荷が変わり得る。

だからこそ、モデルの入れ替えは単なるプロダクト更新ではなく、開発組織のガバナンス課題になる。Copilotをリファクタリング、テスト生成、AgentによるPull Request作成に使うチームほど、どのモデルが有効で、何が廃止予定で、自社のリポジトリ上で品質がどう変わるかを追跡する必要がある。

チームはどう向き合うべきか

個々の開発者にとっては、「任せる、ただし確認する」が最も安全な考え方だ。未知のコードを読む、リファクタ案を出す、複数ファイルの変更を作る、といった場面でCopilotを使いつつ、テスト、型チェック、コードレビュー、手動の差分確認は外さない。GitHubのリファクタリングガイドも、既存コードを変更する前に目的と動作を理解することから始め、選択したコードをCopilotのインラインチャットで説明させる流れを示している。

エンジニアリングリーダーにとっては、Agent modeや複数ファイル編集をどの範囲で使わせるかが論点になる。機械的な変更、移行作業、テスト更新には強力だが、変更範囲が広がるほどレビュー面も広がる。Copilotが複数ファイルを編集したり、ターミナルコマンドを実行したりするなら、モデルポリシー、監査可能性、段階的な展開計画は、単一行補完の時代より重くなる。

プラットフォームチームは、モデル廃止を依存関係のアップグレードに近いものとして扱うのが現実的だ。Changelogを確認し、重要な開発フローを代替モデルで試し、管理ポリシーを更新し、どのCopilot機能面に影響があるかを文書化する必要がある。GitHubのモデル廃止は、チャット、インライン編集、Ask mode、Agent mode、補完にまたがり得るため、影響範囲は単一のIDE機能にとどまらない。

結論：Copilotは「自動化」より「レビュー可能な委任」へ

GitHub Copilotは、エージェント型でリポジトリ文脈を扱う開発環境へ進化している。根拠として見えるのは、Agent mode、複数ファイル編集、Copilot Workspaceのfollow ups、セマンティック検索、インライン差分、BYOKプレビュー、複数モデル選択だ。

ただし、結論は「Copilotが安全に全部書き換えてくれる」ではない。より正確には、Copilotは開発者の意図を、レビュー可能なリポジトリ変更案に変換するシステムになりつつある。これから差がつくのは、プロンプトの上手さだけではない。タスクを小さく切る力、差分を見る力、モデル品質を測る力、そしてモデル移行を開発運用の一部として扱う力だ。