Microsoft Build 2026で、開発ツールの主戦場が静かに動いた。GitHubはAIエージェントを束ねるネイティブデスクトップアプリをプレビュー公開し、Copilotのデフォルトモデルも置き換えが予告された。

焦点は2つだ。1つは「IDE拡張」から「エージェントネイティブなアプリ」への器の移行。もう1つはGPT-4 Turboから新モデルへの中身の入れ替えである。

本記事は、GitHub公式・Microsoft公式の一次ソースを軸に、確報と報道ベースの推測を切り分けて整理する。そのうえでClaude Code・Cursor・Codexとの四強比較と、8月までの確認事項まで通しで示す。

この記事のポイント
  • GitHub Copilotがネイティブデスクトップアプリとしてプレビュー公開。各エージェントセッションがgit worktreeで隔離され並列実行される。
  • デフォルトモデルのProject Polaris（MoE・言語別specialist）置換と「2026年8月」はTechTimes報道ベース。GitHub公式ブログはモデル置換・期日に触れていない。
  • Microsoft公式が名前を出した自社コーディングモデルはMAI-Code-1。「Polaris＝MAI-Code-1」かは公式に明示されていない。
  • 競争軸は「IDE拡張」から「エージェントネイティブアプリ」へ。Claude Code・Cursor・Codexも同方向に動いている。
  • 既存ユーザーは8月の切替に備え、モデル固定の可否・回帰テスト・契約条件を先回り確認すべき。

30秒で理解する

まず全体像を箇条書きで押さえる。詳細は各H2で一次ソースとともに展開する。

・GitHub Copilotがネイティブデスクトップアプリとしてプレビュー公開され、git worktreeで複数エージェントを並列実行できる
・デフォルトモデルは2026年8月からGPT-4 Turbo → Project Polaris（MoE・言語別specialist）へ置換予定とされる（TechTimes報道、公式未確報）
・移行は自動適用だが、期限前のフォールバック設定で3か月はGPT-4 Turboを据え置けると報じられている
・Microsoft公式が確報したのはアプリの存在と自社モデル群（MAI-Code-1ほか）で、Polarisの名称・期日はGitHub公式ブログには出ていない
・Claude Code / Cursor / Codex / Copilotの「四強」の競争軸が、IDE拡張からエージェントネイティブアプリへ移っている

ここで一度、事実と推測の境界を明示しておく。アプリのプレビュー公開は公式確報、Polaris置換とその期日は報道ベースの情報だ。この区別は記事全体で保つ。

AIコーディング全体の俯瞰と各ツールの立ち位置は、ピラー記事 Vibe Codingとは？2026年完全ガイド に整理してある。本記事はその中の「Copilotの大型アップデート」を深掘りする位置づけだ。

何が発表されたか

Build 2026は「Be yourself at work」をテーマに、AIエージェントを業務へ溶け込ませる発表が並んだ。開発者にとっての中心はGitHub Copilotの器とモデルの刷新である。

Microsoft公式ブログは、GitHub Copilotアプリを「agentic developmentのためのnative desktop experience」と表現した。アイデアや既存Issueから着手し、複数エージェントセッションをオーケストレーションし、レビューとCI/merge workflowまでgit worktreeで回せる、というのが骨子だ。

同時にMicrosoftのAI Superintelligence Teamは7つの自社モデルを公開した。開発者に直接関わるのは、GitHub向けに最適化された推論効率重視のコーディングモデルMAI-Code-1で、CopilotとVS Codeで利用可能とされる。

注意したいのは、ここまでが公式の確報である点だ。GitHub公式ブログ「The agent-native desktop experience」も、アプリの機能は詳述するが、デフォルトモデルをPolarisへ置き換えるとも、2026年8月とも書いていない。

事実と推測の切り分け
本記事で「Project Polarisが2026年8月にデフォルトモデルを置換する」とする部分は、TechTimesの報道に基づく。GitHub公式・Microsoft公式の発表では、Polarisという製品名・置換・期日はいずれも確認できていない。組織導入の意思決定は、必ずGitHub公式のアナウンスで裏取りしてから行うこと。

開発者の現場感覚で言えば、Build 2026の意味は「補完エンジン」から「エージェントの司令塔」への移行だ。エディタの中で1行ずつ補完してもらう体験から、複数の自律エージェントを並べて差分をレビューする体験へと、Copilotの重心が動いた。

この移行は、認証情報やトークンの扱いがエージェント前提に変わることも意味する。エージェントが正規の資格情報で自動実行する時代の防御設計は、先行記事 トークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターン で扱った。同じ開発者層が次に踏むべき論点として接続しておきたい。

Copilotネイティブアプリの新機能

ここからはGitHub公式ブログの記述に沿って、アプリの中身を見る。最大の変化は、CopilotがVS Code拡張の外に独立したアプリとして立ったことだ。

・ネイティブデスクトップ実装：VS Code拡張に依存せず、複数エージェントの管理に特化した独立アプリとして動く
・「My Work」ビュー：接続済みリポジトリ横断で、稼働中セッション・Issue・PR・バックグラウンド自動化を一望できる
・git worktreeでの並列実行：各セッションが隔離されたworktreeで動き、複数エージェントが互いに干渉せず並走する
・Agent Merge：CIを監視し、レビュアーを追跡し、失敗したチェックに自動で対処する
・Canvas：人とエージェントの双方向作業面。編集・並べ替え・承認・軌道修正をこの面で行う
・コードレビュー：レビューの注力度を「low / medium」で調整でき、/security-review と /rubberduck の専用スキルを持つ
・サンドボックス：クラウド／ローカルの実行環境を選べ、ポリシー強制で実行範囲を縛れる

技術的に効くのはgit worktreeの採用だ。worktreeは1つのリポジトリから複数の作業ツリーを切り出す仕組みで、ブランチごとに独立した作業ディレクトリを持てる。

これにより、エージェントAがリファクタリングをしている横で、エージェントBがテスト生成を進めても、ファイルが衝突しない。並列エージェントの安全性は、このworktree隔離が土台になっている。

下図は、Copilotアプリが1つのリポジトリから複数エージェントセッションをworktreeで分岐させ、最後にAgent MergeがCIを介して統合するまでの流れだ。

flowchart TD R["GitHubリポジトリ
(main)"] --> APP["Copilotアプリ
My Work / Canvas"] APP --> W1["worktree A
エージェント1: リファクタ"] APP --> W2["worktree B
エージェント2: テスト生成"] APP --> W3["worktree C
エージェント3: ドキュメント"] W1 --> M["Agent Merge
CI監視・レビュアー追跡"] W2 --> M W3 --> M M --> PR["Pull Request
diffレビュー → merge"] PR --> R

既存のVS Code体験との違いも押さえておく。エディタ拡張は「いま開いているファイルを賢く編集する」道具だ。一方アプリは「複数の作業を同時に走らせ、進捗を俯瞰して差分を裁く」司令塔である。

使い分けの目安
日常の補完・1ファイルの編集はVS Code拡張、複数Issueを並列でエージェントに割り当てて進捗とdiffをまとめて見たいときはデスクトップアプリ——という二刀流が当面の現実解になる。アプリが拡張を「置き換える」わけではない点に注意。

なお、現状はテクニカルプレビューであり、Copilot Pro・Pro+・Business・Enterpriseの既存ユーザーが対象だ。GAではないため、本番ワークフローへの全面投入は段階的に判断したい。

Project Polaris：デフォルトモデル置換の意味

ここからはTechTimesの報道に基づくため、再度ことわっておく。以下のPolarisに関する記述は公式確報ではなく、置換・期日・性能はいずれも公式アナウンスでの裏取りが必要だ。

報道によれば、Project PolarisはMoE（Mixture of Experts）アーキテクチャを採り、プログラミング言語・フレームワークごとにチューニングしたsub-moduleを束ねる。RustやHaskellのような低リソース言語での精度改善が強調されている。

MoEは、入力に応じて巨大なモデルの一部の「専門家（expert）」だけを起動する方式だ。全パラメータを毎回使わないため、規模を上げつつ推論コストと速度を抑えやすい。言語別specialistという設計はこのMoEと相性がよい。

・アーキテクチャ：MoE。言語・フレームワーク別のspecialist sub-moduleを動的に選択
・切替時期：2026年8月にロールアウト開始とされる
・移行方式：全サブスクライバーへ自動適用。期限前にフォールバック設定をすれば3か月はGPT-4 Turbo継続
・性能主張：HumanEval・MBPPでGPT-4 Turboを上回るとMicrosoftが主張（独立監査は未確認）
・実行基盤：自社のMaia AIアクセラレータ上で動き、推論レイテンシとコスト低減を狙う

性能の読みかたには注意がいる。HumanEval・MBPPはいずれも関数単位の小さなコーディング課題で、実プロジェクトの巨大コードベースでの挙動を保証するものではない。しかも報道自身が「独立監査では未確認」と明記している。

ここで重要なのは、既存ユーザーが「気づかないうちに体験が変わる」リスクだ。自動移行が事実なら、8月以降にコメント生成の語り口やレビュー指摘の傾向が静かに変わる可能性がある。

「気づかないうちに変わる」を避ける
デフォルトモデルの自動置換は、プロンプトを一切変えなくても出力分布が動く。CIのスナップショットテストや生成物のレビュー基準を持たないチームは、品質の変化を検知できないまま受け入れてしまう。8月前に基準値（ベースライン）を取っておくこと。

利得の側面も公平に見ておく。Maiaアクセラレータでの低コスト・低レイテンシが本当なら、同じ料金で応答が速くなり、エージェントの反復ループが回しやすくなる。MoEの言語別specialistが効けば、RustやHaskellのような少数派言語の支援が厚くなる可能性もある。

つまりPolaris置換は「自動で降ってくる潜在的な改善」と「検知しないと事故る変化」の両面を持つ。後述の「8月までにやること」は、この両面を前提にした準備だ。

四強比較：Claude Code / Cursor / Codex / Copilot

エージェントネイティブ化は、Copilot単独の話ではない。Claude Code・Cursor・Codexも同じ方向——複数エージェントの並列実行とworktree隔離——へ動いている。客観比較のため、各ツールの公式情報をもとに軸を揃える。

軸 GitHub Copilotアプリ Claude Code Cursor 2.0 OpenAI Codex
形態 ネイティブデスクトップアプリ ターミナルCLI（＋IDE連携） IDE（VS Codeフォーク） ターミナルCLI＋クラウド
エージェント並列 複数セッション並列 サブエージェント並列 最大8エージェント並列 サブエージェントで並列化
worktree統合 各セッションをworktreeで隔離 git worktreeで並行作業 各エージェントが専用worktree クラウド環境＋ローカル
デフォルトモデル GPT-4 Turbo→Polaris予定（報道） Claude（Opus/Sonnet） Composer（＋他モデル選択可） GPT-5.x-Codex系
モデル選択自由度 プラットフォーム主導 Anthropic中心＋API 複数ベンダから選択可 OpenAI中心
エンタープライズ サンドボックス＋ポリシー強制 権限・監査・MCP チーム/組織管理 ChatGPT/組織管理
ローカル/クラウド比率 クラウド主体＋ローカルsandbox ローカル実行主体 ローカル＋Cloud Agents クラウド主体＋CLIローカル

表から見える各ツールの性格を、煽らず客観的に整理する。

・GitHub Copilotアプリ：GitHub・Issue・PR・CIとの密結合が最大の強み。Agent MergeまでGitHub内で完結する一方、モデル選定はプラットフォーム主導になりやすい
・Claude Code：ターミナル中心でローカル実行に寄り、git worktreeでの並行作業やサブエージェント、MCP連携が厚い。モデルはAnthropic中心
・Cursor 2.0：エディタ統合のまま最大8エージェントを各worktreeで並列実行。自社のComposerは「同等知能のモデル比4倍速」を謳い、Claude/GPT/Geminiなど複数モデルを選べる
・OpenAI Codex：CLIとクラウドを往復し、サブエージェントでタスクを分割。GPT-5.x-Codex系はSWE-Bench ProやTerminal-Benchで高い数値を更新している

ベンチマークの扱いには共通の注意がある。SWE-Bench Proは実際のGitHub Issue解決を測る現実寄りのベンチで、各社が更新を競っているが、数値はモデル・スキャフォールド・試行条件で大きく動く。単一スコアでツールの優劣を断じないほうがよい。

比較の結論を一言で
「どれが最強か」ではなく「自分の作業がどこに集まっているか」で選ぶのが正解だ。CI/PRがGitHubに集約されているならCopilotアプリ、ローカルとターミナル中心ならClaude Code、エディタを離れたくなければCursor、OpenAIエコシステム前提ならCodex——という重心の違いとして捉えるとよい。

各ツールのより詳しい突き合わせは Claude Code vs Cursor 徹底比較2026 を参照。本記事はそこにCopilotアプリとCodexの軸を足した俯瞰図と位置づけたい。

既存Copilotユーザーが8月までにやること

Polaris移行が報道どおりなら、8月は静かな分水嶺になる。何もしなければ自動で切り替わる前提で、検知と固定の準備を先回りしておく。

・切替挙動のテスト計画：Chat・Edits・Agentなど機能ごとに、8月前後で同じプロンプトの出力を比較できる手順を用意する
・モデル固定設定の可否確認：組織ポリシーでデフォルトモデルを固定（またはGPT-4 Turboへフォールバック）できるか、GitHub公式ドキュメントとアカウントチームに確認する
・社内コードベースでの回帰テスト：実プロジェクトの代表タスクでベースラインを取り、切替後に品質・速度・コストの差分を測る
・契約・SLAの確認：モデル変更に伴うデータ送信ポリシー・SLA・データ境界の変更がないか、契約条件を読み直す

ここで効いてくるのが、前述の「ベースラインを取る」だ。切替前に基準値がなければ、変化が改善なのか劣化なのか議論ができない。最低限、代表的な生成タスクの出力を保存しておくだけでも違う。

やりがちな失敗
「自動移行だから様子を見る」と放置すると、8月以降に品質が変わってから慌ててフォールバックを探すことになる。だが報道どおりならフォールバック設定は期限前に行う必要がある。期限を過ぎてからでは据え置けない可能性が高い。

組織で使っているなら、この準備はセキュリティレビューと一体で進めたい。エージェントが自律実行する範囲が広がるほど、資格情報の最小化と監査ログの重要性が増す。トークン窃取への多層防御の考え方は前掲のセキュリティ記事が詳しい。

新規導入検討者向けの選定軸

まだどのツールにも本格投入していないチームは、流行ではなく自社の条件で選ぶべきだ。判断軸は4つの掛け算で整理できる。

・コードベース規模：巨大モノレポなら、worktree並列とコンテキスト管理の強さが効く
・チーム規模：人数が増えるほど、組織ポリシー・監査・権限管理の成熟度が重要になる
・既存IDE/ワークフロー：作業がVS Codeかターミナルか、CI/PRがGitHubに集約されているか
・機密度：データ送信ポリシー・ローカル実行の可否・サンドボックスのポリシー強制

この4軸を踏まえ、よくある比較シナリオを示す。あくまで重心の話で、絶対的な優劣ではない。

・Copilot vs Claude Code：GitHubにCI/PR/Issueが集約され、チームで標準化したいならCopilotアプリ。ローカル中心でターミナル運用、任意モデルやMCPを自前で握りたいならClaude Code
・Copilot vs Cursor：GitHub統合とAgent Mergeまで一気通貫にしたいならCopilot。エディタを離れずに複数エージェントを並走させ、補完体験も重視するならCursor

選定のH2まとめ
  • 「規模 × 人数 × IDE × 機密度」の掛け算で重心を決める。最強ツール探しはしない。
  • GitHub集約度が高いほどCopilotアプリの統合メリットが大きい。
  • モデルを自前で握りたいほどClaude Code/Cursor寄り。エディタ常駐ならCursor。
  • 機密度が高いなら、デフォルトモデルの自動変更（Polaris）に蓋ができるかを最優先で確認。

よくある落とし穴

最後に、今回の発表で混同しやすい点を潰しておく。報道と公式、プレビューとGA、デフォルトの範囲——この3つの境界が曖昧だと判断を誤る。

・WorkspaceのGAとアプリのプレビューを混同しない：器(アプリ)はテクニカルプレビュー段階だ。GA前提で本番フローを全面移行すると、仕様変更に振り回される
・Polarisが「全機能でデフォルト」とは限らない：Chat・Edits・Agentで挙動が違う可能性がある。さらにPolaris自体が公式未確報である点を忘れない
・worktree未経験チームの学習コスト：並列エージェントの土台はgit worktreeだ。worktreeを使ったことがないチームは、隔離・マージの運用を先に習熟しておく
・ライセンス・データ送信ポリシーの読み違い：プラン（Individual/Business/Enterprise）で機能とデータ境界が異なる。クラウドサンドボックスに何が送られるかを必ず確認する

とくに2つ目は本記事の主旋律だ。「Polarisがデフォルトになる」という一文だけが独り歩きしやすいが、現時点でそれはGitHub公式の確報ではなく、適用範囲も期日も裏取り待ちである。

情報の出どころを確認する習慣
製品名・期日・性能数値は、必ず一次ソース（GitHub公式ブログ／Microsoft公式）に当たって確認する。本記事のPolaris関連は報道ベースで、公式アナウンスが出た時点で内容が変わり得る。導入判断は公式の確報を待つこと。

総じて、Build 2026が示したのは「AI開発ツールの主戦場が、補完からエージェント・オーケストレーションへ移った」という構図だ。器(ネイティブアプリ)と中身(デフォルトモデル)が同時に動くいま、ユーザー側に求められるのは、変化を検知できる基準値を先に持っておくことである。

参照ソース

・GitHub Blog（公式・アプリ発表）：The agent-native desktop experience built on GitHub
・Microsoft（公式・キーノート総括）：Build 2026 — Be yourself at work
・TechTimes（Polaris置換の報道）：GitHub Copilot replaces GPT-4, Project Polaris ships, multi-agent VS Code at Build
・Azure Blog（エージェント基盤）：Build 2026 — building agentic apps with Microsoft Fabric and databases
・Cursor（並列エージェント）：Changelog 2.0 — New Coding Model and Agent Interface
・OpenAI Developers（Codexのサブエージェント/クラウド）：Codex CLI