GitHub Universe 2026、Copilotアプリと複数モデル使い分け「Fusion」を発表。EnterpriseはCopilot別契約なしで全機能へ

まず初めに

開発者の仕事が「コードを書く」から「エージェントの交通整理をする」に移っている、という話はもう珍しくない。今回のGitHubの発表は、その交通整理の場所そのものを自社で用意する、という宣言である。モデルは他社のものも含めて使い分ける、セッションは端末を渡り歩く、レビューは深さまで選べる。要するに「どのAIを使うか」ではなく「仕事をどこで回すか」の取り合いに、舞台ごと出てきたわけで、プラットフォーム屋の本気としては素直に強いと思う。料金の組み替えまで同時に打ってくるあたり、囲い込みの手際も相変わらず鮮やかである。

※個人の感想です

Copilotアプリと「仕事の置き場」の再定義

GitHub Copilotアプリは、エージェントによるソフトウェア開発のために一から設計されたアプリだとGitHubは説明しています。プロジェクトをまたいでエージェントとツールを接続し、すべての受け渡しを自分でやらなくても作業を指揮できる形を目指すもので、コードを書く以外にも、仕様の作成、設計の議論の提示、テレメトリの分析などを一つの画面で行えるとしています。

GitHubは今回の発表全体を、「アイデアから完成したソフトウェアまで」を一つの循環として扱う構想として位置づけています。開発者が方向と判断と責任を持ち、エージェントが実装と検証を担い、結果が次のサイクルを良くする学習の仕組みへ戻っていく、という描き方です。

Copilot Fusionとprojects、セッション継続

Copilot Fusionは、タスクごとに必要な能力（推論、コード生成、デバッグ、ツール利用）を見積もり、1つまたは複数のモデルにまたがって実行方法を選ぶ仕組みです。開発者がモデルの選択をいちいち管理しなくて済むようにする狙いだと説明されています。GitHubの公表では、Artificial AnalysisのCoding Agent Indexで、Fusion MaxがOpus 5.5 Maxに2ポイント差まで迫り、コストは半分、タスク当たりの時間は40%短かったとしています。これはGitHub側の公表値です。

Copilot projectsは、Copilotアプリから本日利用可能で、複数のリポジトリにまたがるエージェント作業を、完全に管理された並行セッションで実行できます。進捗の追跡と判断を一か所で行うための機能です。

セッションの継続（Session continuity）では、GitHubアプリ、VS Code、CLI、Webの間で、同じクラウドエージェントのセッションを開始・継続できます。会議でスマートフォンから始め、デスクでVS Codeから操り、昼にgithub.comで確認する、といった使い方をGitHubは例示しています。

レビューと自動化

Copilot automationsは、リポジトリ内でAIワークフローを作る仕組みで、手動の起動のほか、イベントへの反応やスケジュール実行ができます。今回、実行結果から学習し、改善案を提案して承認を受ける形が追加されました。Issueの仕分けやコードレビューといった作業の調整に使う想定です。

コードレビューでは、新しい「Copilot code review Max」が発表されました。GitHubの公表では、ReviewBenchにおいて高重大度の問題で最も高いF1スコアを記録したとしています。日常向けのLiteとBalancedに、深く見るMaxが加わる形です。

Enterprise向けの料金変更と基盤投資

GitHub Enterpriseの利用者は、本日から、別途のCopilot契約を買わなくても、Copilotアプリやコードレビュー、automationsを含む全Copilot機能を使えるようになります。支払いは、使ったAIクレジットの分です。当面はGitHubの営業経由で提供され、セルフサービスは近日とされています。既存のCopilot BusinessとCopilot Enterpriseの利用者は、現行プランの継続も、移行も選べます。

基盤面では、今年これまでに400万個のCPUコア、160PBの高速ストレージ、50Tb/sのネットワーク容量を追加したことや、Azureへのマルチリージョン展開を進めていることが公表されました。エージェントが開発の量と形を変えているため、容量の追加だけでなくアーキテクチャの変更が必要だった、とGitHubは説明しています。

初心者が知っておくべきこと

Q. GitHub Copilotアプリは、従来のCopilotと何が違うのですか。

A. 従来のCopilotがエディタ内での補完や対話を中心にした「道具」だったのに対し、Copilotアプリは、複数のエージェントやプロジェクトをまたいで作業全体を指揮する「置き場」として設計されています。仕様作成や設計議論、テレメトリ分析までを同じ画面で扱う想定です。

Q. Copilot Fusionを使うと、モデルを選ばなくてよくなるのですか。

A. GitHubの説明では、タスクの性質に応じて実行に使うモデル（1つまたは複数）をFusion側が選びます。利用者は結果とコストのバランスで水準（Maxなど）を選ぶ形が中心になります。公表された性能比較はGitHubの測定値なので、自社の作業での評価は別途必要です。

Q. Enterpriseの料金変更は、個人の利用者にも関係しますか。

A. 今回の変更の対象はGitHub Enterpriseの利用者です。個人向けのCopilotプランの条件は、この発表では変更されていません。

IT Postの見方——競争の単位が「モデル」から「作業場」に移った

IT Postでは、今回の発表の軸は、個々の機能よりも「開発の作業場そのものを押さえる」という設計思想だと考えます。Fusionが他社モデルまで含めて使い分ける前提に立った時点で、GitHubは「自社モデルで勝つ」競争からは降りて、「どのモデルで回しても、仕事はここで回る」という基盤の競争に全振りしたことになる。セッション継続やprojectsのような機能は、その基盤から離れにくくするための具体的な接着剤である。

Enterpriseの料金組み替えも同じ方向を向いている。別契約の壁を取り払い、利用量ベースに寄せることで、まず全機能を触らせる。便利さの先に囲い込みがあるのはいつものことだが、今回の囲い込みはモデルではなくワークフローに掛かっている分、外すときのコストも読みにくい。導入する側は、便利さと同時に「ここから出る時に何が残るか」を先に決めておくべき局面だ。

※個人の感想です

今後どうなりそうか

焦点は、Enterprise向け新料金のセルフサービス提供の開始時期と、CopilotアプリやFusionの実際の利用条件（対象プランや地域）の詳細です。マルチモデル前提の「作業場」モデルが他の開発基盤にも広がるかどうかも、次の確認点になります。

IT Postでは、提供条件の詳細が公表された場合は本記事を更新します。