GitHub 在 Universe 2026 上正式提供 Copilot Fusion，并公测 Copilot…

GitHubは、2026年10月28・29日に開催した「GitHub Universe 2026」にあわせ、自動モデル選択と複数モデルの連携を統合したCopilot Fusionの一般提供を発表した。デスクトップ向けのGitHub Copilotアプリでは、資料とエージェントの作業をまとめるProjectsのパブリックプレビューを開始した。自動化やコードレビュー、セキュリティ対策の機能追加・一般提供に加え、GitHub Enterpriseの契約方式やGit・Actionsの基盤に関する変更も発表している。

GitHub Universe 2026: Evolving every layer of the stack - The GitHub Blog

今回の発表には、新機能のパブリックプレビューだけでなく、既存プレビューの一般提供や、対応するツール・実行環境の拡大も含まれる。以下では、作業を任せる入口から、モデルの選択、知識の引き継ぎ、自動化、成果の確認へと順に主要な変更を紹介する。

GitHub Universe 2026、1日目のオープニングキーノート

計画からリリースまでをつなぐ開発の構想

GitHubはUniverse 2026で、計画から実装、検証、リリースまでをつなぐ「software delivery system」の構想を示した。成果として重視するのは、機能の追加や不具合修正、セキュリティ修正といった変更を仕上げ、利用者に届けること。開発者が方向を定め、判断し、その成果に責任を持つ。エージェントは変更を実装し、検証する。

各工程は、決まった順序で進むとは限らない。コードの変更、同僚からの依頼、本番環境の指標などが、さまざまな工程で作業を始めるきっかけとなり、開発者とエージェントは課題に応じて工程を行き来する。そこで得た情報を継続的な学習に使い、次の作業の改善につなげる。

GitHubは、この構想で重視する点として次の3つを挙げている。

速度（Velocity）：アイデアを完成したソフトウェアにするまでの時間や費用を減らし、効率を高める。

知識の活用（Intelligence）：プラットフォーム上の開発に関する情報を組み合わせ、過去の作業から継続的に学び、次の作業を改善する。

品質（Quality）：安全性を最初から確保し、リリース前に不具合を見つける。

また、GitHubは、開発者が独自の仕組みを作れるよう、製品を支える技術も利用できるようにしている。たとえば、提供済みのCopilot SDKでは、共通のエージェント実行基盤を自分のアプリケーションに組み込める。どの作業をエージェントに任せ、どのツールを使い、いくら費用をかけるかは、開発者が決められるとしている。

Copilotで作業を始め⁠、ツールと成果物をつなぐ

Projectsで⁠、資料とエージェントの作業をまとめる

GitHub Copilotアプリ内のProjectsは、関連する資料やリポジトリ、エージェントの作業、成果物を一か所にまとめる機能。達成したいことを伝えると、Copilotが必要な作業を調整する。パブリックプレビューとして提供を始めた。

Copilot Projects 📋

Bring sessions, pull requests, and repositories together around one goal. Copilot Projects gives you one place to see where the work stands and direct what Copilot takes on next.https://t.co/4DDsl7Euf1 pic.twitter.com/fwCwfAbYHE— GitHub (@github) October 28, 2026

セッションは、エージェントに個々の作業を任せる単位。Projectsでは、目標に応じて必要なセッションを動かし、関連する資料や成果物、定期作業と一緒に管理する。たとえば、顧客の意見を調べ、改善案を検討し、実装へ進む一連の仕事を扱える。特定の不具合修正など、対象と作業が決まっている場合は、Projectsを作らずにリポジトリやフォルダから直接セッションを始めることもできる。

Projectsは、サイドバーの「Projects」横の「＋」から作成する。開始画面の選択肢を使わず、下部の入力欄に目標や最初の依頼を直接書いて始められる。入力欄の「＋」からローカルフォルダを渡すこともできる。フォルダやリポジトリの指定は必須ではなく、GitHub上のリポジトリを使う場合は、所有者名やリポジトリ名で検索して追加する。

図1 GitHub Copilotアプリで新しいプロジェクトを開いた画面。サイドバーの「Projects」横の「＋」を押すと「New project」が追加され、中央に開始画面が表示される。「Start with one or more repositories」はGitHub上のリポジトリの追加、「Work on parallel tasks」はIssueやPRに関する作業の並行実行、「Triage recent issues」は最近のIssueの確認・整理、「Automate routine work」は繰り返す作業の定期実行、「Research and work with docs and messages」はファイルやチャット、会議の情報を使った調査の入口となる。右側の「Overview」では進行状況を確認できる。ローカルフォルダの内容を把握するよう依頼したところ、「New project」という仮の名前が、内容に応じたプロジェクト名へ自動的に変わった。

作成したプロジェクトで目標と必要な資料を渡すと、Copilotが必要に応じて複数のエージェントを並行して動かし、作業を調整する。複数のリポジトリにまたがる変更も扱える。利用者は各セッションに指示を出し続けなくても、プロジェクト全体の進行を確認し、必要な判断やレビューに関われる。

Libraryは、利用者が追加した資料やエージェントが作った成果物を、プロジェクト内で保存・確認する場所。Libraryのタブが見えていない場合は、右側パネル上部の「＋」を押し、メニューの「Open tabs」にある「Library」を選ぶと開ける。

チャットの入力欄の「＋」からローカルフォルダを渡したところ、Libraryにも「Attached in chat」と表示された。そのフォルダを開くと、中の原稿や参考資料、画像の一覧を確認できた。

資料を使った作業では、たとえば機能の仕様書と顧客からのフィードバックを渡し、困り事を分類して次に調べる項目を挙げるよう依頼できる。保存した資料や成果物は、同じプロジェクトで作業を続ける際にも利用できる。プロジェクトの会話から、資料の週次要約などの定期作業も設定できる。

進行状況はOverviewで確認する。利用者の判断やレビューが必要な作業、開いているプルリクエスト（PR⁠）⁠、実行中の作業、完了した作業を分けて表示し、個々のセッションへ追加指示を送ることもできる。

プロジェクトの作成や資料の追加については、Projectsの公式ドキュメントで確認できる。

端末やツールを替えても⁠、同じクラウドセッションを継続

作業を続ける場所も広がっている。GitHubは、端末やツールをまたいで同じクラウドセッションを利用できる機能の一般提供を、28日から有料Copilotプラン向けに順次開始している。github.com、GitHub Mobile、GitHub Copilotアプリ、CLI、VS Codeなどからアクセスでき、スマートフォンで依頼した作業をPCで確認して追加指示を出せる。その間も、エージェントはクラウドで作業を続ける。

このクラウドセッションは、デフォルトではGitHubが管理するクラウドサンドボックスで動く。サンドボックスの停止時には作業状態をスナップショットとして保存し、後でセッションを再開できる。ただし、Actionsのセルフホストランナーやcopilot-setup-steps.ymlを使う場合は、クラウドサンドボックスではなく、Actionsをセッションの実行環境に選ぶ必要がある。

有料Copilotプランの料金とは別に、クラウドサンドボックスの計算資源も、2026年11月から利用量に応じた課金の対象となる。Actionsのワークフローを実行しなくても、クラウドサンドボックスを使えば利用分が計上される。ただし、Actionsと共通の付属利用枠を充てられるため、枠内であれば計算資源の追加請求は発生しない[1]。超過分は、料金や予算、支払い設定に従って扱われる。

VS Codeで⁠、複数エージェントの作業と成果の確認をまとめる

VS Codeでは、エージェントに作業を任せ、その進行や成果を確認するための機能を増やしている。28日公開の「VS Code Wrapped」は、今回の発表とともに、前回のUniverseから1年間の更新を振り返っている。

実行環境には、クラウドに加え、自分のPCや接続先のマシンも選べる。新しいAgent Hostは、セッションを個々のウィンドウから分離するため、ウィンドウを閉じても作業を続けられる。ただし、ローカルやリモートのマシンで動かす場合、そのマシンとAgent Hostは稼働している必要がある。

ハーネス（harness）は、エージェントの処理を進め、モデルがツールや作業に必要な情報を使えるようにする実行基盤。VS Codeでは、Microsoft Copilot SDKに基づくCopilotハーネスが、エディターとAgentsウィンドウで始める新しいセッションのデフォルトになった。CLIやGitHub Copilotアプリと共通の基盤を使い、製品間でエージェントの動作の違いを減らす。Agent Hostを通じてClaudeやCodexのハーネスも利用でき、それぞれの実行基盤や機能を使うセッションをVS Codeで扱える。

Agentsウィンドウでは、複数のセッションを並行して動かし、進行状況や変更内容をまとめて確認する。コードの編集やデバッグが必要になったら、同じCopilotセッションを保ったままエディターへ移り、再びAgentsウィンドウへ戻れる。また、複数のモデルやハーネスに同じ課題を任せ、結果を並べて比較する「Compare Models」もプレビューとして提供する。

作業結果を確認・修正する方法も広がっている。「⁠VS Code Wrapped」では、これまでに加わった機能として、利用者とエージェントが同じページを見て操作できる統合ブラウザーや、表示された計画書・文書を直接編集し、エージェント向けのコメントを残せるMarkdownエディターも紹介している。

Canvasesは、チャットの横に操作可能な画面を開き、利用者とエージェントが同じ情報を確認・更新するプレビュー機能。たとえば、利用者がカンバン形式のボードでカードを移動し、エージェントが作業を分解してカードを追加する、といった使い方ができる。VS Codeのデスクトップ版で、Copilotハーネスを使うローカルセッションが対象となる。「⁠chat.canvases.enabled」を有効にして新しいセッションを始め、「⁠/create-canvas」で必要な画面を依頼すると、エージェントがキャンバス用の拡張機能を作成し、その画面を開く。

IDE向けの更新では、JetBrainsについても、ローカルサンドボックスと次の編集候補を示すNext edit suggestionsの一般提供などを発表している。

外部サービス⁠、画像⁠、デスクトップアプリへ作業範囲を広げる

外部サービスの資料やツールをCopilotから利用するためのコネクターも、全Copilotプラン向けにパブリックプレビューとして順次提供する。GitHubは、同社が検証したMCPサーバーを「コネクター」と呼んでいる。MCPはAIが外部のツールや情報源を利用するための接続方式。コネクターを使えば、利用者が対応するサーバーを探して個別に設定しなくても、サービスを選んでサインインすることで接続できる。

開始時点ではSlack、Figma、Sentry、Linearなど26サービスに対応する。一度接続すればGitHub Copilotアプリ、CLI、VS Code、クラウド、GitHub Mobileで共用でき、それぞれで接続を設定し直す必要はない。BusinessとEnterpriseでは、管理者がプレビュー機能を許可する必要がある。[2]

画像生成・編集では、会話で依頼すると、選択中の会話用モデルが「GPT Image 2.5 Flare」を使う専用の画像生成ツールを呼び出す。生成した画像のプレビューを会話内に表示し、画像を作業フォルダに保存する。VS Code、GitHub Copilotアプリ、CLIで利用でき、発表ではPro、Pro+、Business、Enterprise向けのパブリックプレビューとして案内した。画像生成・編集の料金は会話用モデルの料金とは別に計算し、画像トークン数に応じてプランのAIクレジットを消費する。

GitHub CopilotアプリとCLIのComputer Useは、10月1日からmacOSとWindowsでパブリックプレビューを提供している。アプリの内容を読み、クリックや文字入力を行うことで、APIやMCPのないデスクトップアプリも操作対象にできる。操作開始前には利用者の承認を求め、組織は管理設定で無効化できる。28日のVS Code向け発表では、Agent Host上のCopilotセッションで使うComputer Useも実験的機能として案内した。

Issue artifactsで⁠、計画書や調査結果をIssueに残す

計画書や調査結果などを個別の成果物としてIssueに追加できるIssue artifactsも、パブリックプレビューになった。Issueの本文やコメントに説明を書くことに加え、関連する文書を独立して更新・参照できるようにする機能。たとえば実装計画を添付し、議論に応じて内容を更新すれば、チームや後続のエージェントが参照する計画と変更履歴をIssueに残せる。

成果物として追加できるのは、こうした計画書や調査報告を保存するMarkdown文書、外部サービスへのリンク、HTML文書。外部サービスへのリンクは、SlackやTeamsでの議論、公開したプロトタイプなどのURL自体を一つの成果物として登録する。HTML文書では、図やフローチャート、操作できる可視化などを扱え、github.com上で表示結果とHTMLソースを切り替えて確認できる。

成果物はgithub.com上で作成・編集・削除でき、成果物ごとのリンクで共有できる。GitHub CLIにもgh issue artifactコマンドを追加し、エージェントや開発ツールから成果物を管理できるようにした。

Replicaで⁠、製品の画面や操作を試すプロトタイプを作る

GitHubは、GitHub Designが開発したReplicaをMITライセンスで公開した。製品の画面や操作を試すプロトタイプの制作・共有に使うツール群で、GitHub Copilotアプリ向けのプラグインやアプリのひな型、共有用のサーバーなどを含む。デザイナーやプロダクトマネジャー、エンジニアが、案を実際に動かせる形にして検討するために使える。

ReplicaのREADMEでは、主な構成要素を次のように説明している。

Starters：プロトタイプの出発点となるアプリのひな型。Copilot用の共通スキルも含む。自分たちのデザインに合わせて作り替える小規模なひな型や、MicrosoftのCoreAIのUI部品を備えたひな型を用意する。

Replica plugin：GitHub CopilotアプリにReplica用のキャンバスを追加し、会話の横に実行中のプロトタイプを表示するプラグイン。

Replica Hub：制作したプロトタイプを公開し、チームのメンバーが操作してコメントを残せる共有用のサーバー。必要に応じて自分たちで導入・運用する。

GitHub build action：Hubへ公開するプロトタイプをビルドするためのGitHub Actions用アクション。ローカルでの制作には必要ない。

用意されているひな型は、JavaScriptのUIライブラリであるReactとTypeScriptを使うWebアプリで、見た目を整えるCSSも含む[3]。

ひな型の利用は必須ではなく、既存のWebアプリから始める方法も案内している。その場合は、既存アプリのファイルや構成、起動方法を維持し、Replicaのキャンバスへ接続するための設定を加えて表示を確認する。

ひな型または既存のWebアプリを起動できたら、チームのUI部品やデザインのパターン、ドキュメントを用意する。GitHub Copilotアプリで作りたい画面や動作を自然言語で伝えると、Copilotがそれらを手掛かりにコードやスタイルを編集し、プロトタイプを作る。キャンバスで動作を試しながら修正でき、Hubを導入せずに手元の環境だけで始められる。

モデルを選び⁠、組み合わせるCopilot Fusionを一般提供

Copilot Fusionは、課題ごとに使うAIモデルと、その組み合わせ方を決める仕組み。一般提供を開始し、VS Code、GitHub Copilotアプリ、CLI、JetBrains IDEで利用できる。

Route and orchestrate models with GitHub Copilot Fusion - GitHub Changelog

前身のProject HydraFusionは9月4日に研究プレビューを開始し、10月14日にはMaxを追加していた。今回、これまでの自動モデル選択とHydraFusionの複数モデル連携をFusionへ統合した。Auto、HydraFusion、HydraFusion Maxを選択していた場合は、対応するFusionの処理レベルへ自動的に切り替わる。

Copilot Fusion 🧬

Choose High or Max effort, and Copilot Fusion can coordinate multiple models and workflows when one model alone isn’t enough. In the @ArtificialAnlys Coding Agent Index, Copilot Fusion Max scored within two points of Claude Code with Opus 5.5 Max at about half… pic.twitter.com/QGsBwCkdw1— GitHub (@github) October 28, 2026

利用者はStandard⁠・High⁠・Maxの処理レベルを選ぶ

処理レベルは、品質、待ち時間、費用のバランスを指定する設定。Fusionのドキュメントによると、Standardは日常の作業向けで、一つのモデルを使う。Highは複雑だが範囲の定まった変更、Maxは深い推論や入念な分析が必要な作業に向き、必要に応じて複数モデルを組み合わせる。

GitHub Copilotアプリでは、入力欄の下にあるモデル名の表示をクリックして、モデル選択メニューを開く。「⁠Copilot Fusion」をONにするとStandard、High、Maxの処理レベルを選べ、OFFにすると個別のモデルを選べる[4]。アプリで選んだモデル設定は、その後に作成するセッションのデフォルトにもなる。

VS Codeでは、Copilotのチャット入力欄にあるモデル選択メニューからFusionを選ぶ。[4]

図2 VS Codeのモデル選択メニュー（左）と、Fusionの処理レベルを選ぶ画面（右）。「Copilot Fusion」を選び、「Effort Level」でStandard・High・Maxを切り替える。画面ではStandardを選択している。左側に並ぶ個別のモデル名は手動選択用の一覧で、Fusionの選択候補一覧を示すものではない。

使うモデルと実行方法はFusionが自動で決める

Fusionは、利用者が選んだ処理レベルとプロンプトの内容に応じて使うモデルを決め、実行方法を次の3つから自動的に選ぶ。実行方法は利用者がメニューで直接指定するものではなく、同じセッションでも依頼ごとに変わる場合がある[6]。

Single：一つのモデルが処理する。

Cascade：効率を重視したモデルがまず回答を作り、評価の結果に応じて、より高性能なモデルへ処理を引き継ぐ。

Critique：最初の回答を複数の別モデルが並行して検討し、指摘を集約したうえで元のモデルが修正する。

選択候補のモデルは固定ではなく、新しいモデルの登場やGitHubの評価に応じて更新される[5]。

Fusion MaxはTerminal-Bench 4.0で高い成績

GitHubによると、Artificial Analysis Coding Agent IndexでFusion Maxのスコアは60となり、Claude CodeでOpus 5.5 Maxを使った結果との差は2ポイント以内だった。その評価でのタスク当たり平均API費用は約半分、所要時間は約40％短かったとしている。

評価を実施したArtificial Analysisの28日付の記事によると、GitHub Copilot CLIでFusionのMax設定を使い、3つのベンチマークを均等に重み付けして総合スコアを算出した。内訳のTerminal-Bench 4.0では71％となり、この記事に掲載された比較対象の中で首位だった。

Artificial AnalysisのCoding Agent Index v2.0と評価内訳から、Fusion・Claude・GPTの主な構成を抜粋。2026年10月30日確認。いずれも数値が高いほど成績がよい。モデルと実行基盤を組み合わせた評価となる。

実行基盤 モデル・処理レベル 総合スコア Terminal-Bench 4.0 FrontierCode v1.1 SWE-Atlas-QnA-AA

Claude Code Claude Opus 5.5（Max） 62 63％ 56％ 66％

Claude Code Claude Sonnet 5.5（Max） 59 66％ 48％ 64％

Claude Code Claude Fable 5.1（Max） 58 58％ 49％ 66％

Codex GPT-6 Astra（Max） 55 56％ 49％ 59％

Codex GPT-6.1 Sol（Max） 54 53％ 49％ 60％

Codex GPT-6.1 Terra（Xhigh） 48 46％ 45％ 54％

総合スコアではClaude CodeのOpus 5.5が高く、FrontierCodeとSWE-Atlas-QnA-AAでもFusionを上回った。CodexのGPT-6 AstraやGPT-6.1 Solも、SWE-Atlas-QnA-AAではFusionより高い値となっており、評価項目によって強みが異なる。

Frontier performance at a fraction of the cost.

In the @ArtificialAnlys Coding Agent Index, Copilot Fusion Max scored within two points of Claude Code with Opus 5.5 Max at about half the API cost per task.

対象プランと利用料金

Fusion Standardは全Copilotプランで利用できるが、HighとMaxはCopilot Pro+、Max、Business、Enterpriseが対象となる。

Fusion自体の追加料金はなく、使用した各モデルの料金に応じて課金される。HighやMaxで複数のモデルが使われた場合、StandardよりAIクレジットの消費が多くなることがある。有料Copilotプランでは、2026年11月30日まで、Fusionで使用したモデルの費用を30％割り引く。

ローカルモデルへの振り分けは実験的プレビュー

Fusion Standardでは、対応するローカルモデルとクラウドモデルを選び分ける機能も、利用者が有効化して使う実験的プレビューとして提供する。依頼ごとにモデルを手動で切り替えずに、手元の端末の計算資源も利用できる。ただし、どのモデルに処理を任せるかはクラウドで判断するため、この自動選択にはインターネット接続が必要になる。

GitHub Copilotアプリでは、設定の「Model providers」で「Add provider」から「Windows ML」を選び、MAI Code 1.1 Flashの「Download」を押して取得する。利用には対応GPUや十分なメモリーなどの要件がある。続いて実験的機能の設定にある「Local model auto routing」を有効にし、新しいセッションでFusionのStandardを選ぶと、ローカルモデルも振り分け先になる。

CLIでは実験的モードを有効にして「/model」から設定を進める。Windows、macOS、Linux上で対応モデルを手動設定して使う方法もある[7]。VS Codeでは「chat.copilot.localModel.enabled」を有効にする。

GitHub intelligenceで⁠、過去の作業や関連コードを次の開発に活かす

GitHub intelligenceは、リポジトリのコードや開発履歴、チームの知識をエージェントが使えるようにする機能群。今回の発表では、知識を引き継ぐMemory、その内容や作業指針を見直すDreaming、関連リポジトリを横断するコード検索を紹介した。

GitHub intelligence puts your code, context, and history to work - GitHub Changelog

Memoryを一般提供⁠、Dreamingのプレビューを開始

1月からパブリックプレビューだったMemoryを一般提供するとともに、新たにDreamingのパブリックプレビューを開始した。Memoryは、個人の好みやリポジトリの決まりを記憶し、別のセッションやクライアントでも使えるようにする。Dreamingは、過去の会話や作業を振り返り、そのメモリーを整理・更新するとともに、エージェントが従うスキルや指示ファイルの改善も提案する。

Memoryは有料Copilotプランで提供する。たとえば、テストの実行コマンドやPRの説明文の書き方を覚えておけば、次の作業で同じ指示を繰り返す手間を減らせる。利用者が明示的に覚えるよう依頼するだけでなく、Copilotもセッション中のやり取りからメモリーを自動で作成・整理する。一般提供の発表では、GitHub Copilotアプリ、CLI、VS Code、クラウドエージェント、コードレビューに加え、Slack、Teams、GitHub Mobileでもメモリーを作成できると案内している。

保存した情報を使う範囲は、その種類によって異なる。リポジトリについての情報はそのリポジトリの作業に適用し、個人の好みはリポジトリをまたいで利用する。利用者や管理者は設定に応じて保存内容を確認・削除できる[8]。

Dreamingによる見直しでは、個人やリポジトリのメモリーを必要に応じて追加・更新・削除する。繰り返し採用されたコードレビューの指摘を、今後のレビュー用の指針に反映する機能もある。リポジトリに保存されたスキルや指示ファイルの変更は直接適用せず、チームが確認するPRとして提案する[9]。

Dreamingは有効化が必要で、実行にはAIクレジットを使う。組織や企業では管理者ポリシーも適用される。

関連リポジトリを横断してコードを検索

GitHub intelligenceには、関連する複数のリポジトリからコードや設定、ドキュメントを探す機能もある。手元にすべてをcloneしなくても、文字列やシンボルを検索でき、自然言語で処理の内容を指定する意味検索にも対応する。

発表では、決済サービス、共通ライブラリ、バックグラウンド処理にまたがるリトライ処理を調べる例を挙げている。「⁠/research」で依頼すると、各リポジトリの実装や呼び出し元を確認し、どこでリトライが重複する可能性があるかを調べられる。変更を始める前に、複数のリポジトリに分かれた処理の関係を把握するために使える。

Copilot Automationsに⁠、チームでの共有と改善支援を追加

Copilot Automationsをチームで管理

Copilot Automationsでは、作業を指示するプロンプト、開始条件、使用を許すツールを組み合わせて、クラウド上でCopilotを実行する。たとえば、Issueが作成されたら不具合の再現を試す、監視サービスから通知を受けたら障害を調べる、といった処理を設定できる。

Build shared workflows for your team with Copilot Automations - GitHub Changelog

これまでの個人用に加え、チームで管理する共有Automationsを順次提供する。リポジトリの読み取り権限を持つ人が設定を確認でき、書き込み権限を持つ人が編集する。GitHub上の操作はCopilot名義で記録され、AIクレジットとActionsの実行時間はリポジトリの所有者に課金される。共有Automationsはリポジトリに属するため、作成した担当者がチームを離れても処理を継続できる。

対象はCopilot Pro、Pro+、Max、Business、Enterprise。発表では、書き込み権限を持つ任意のリポジトリで作成できるとしている[10]。組織所有の共有Automationsでは、組織への課金を許可する管理者設定も必要になる。

開始条件とツールを追加し⁠、結果から改善を提案

Copilot Automationsで実行のきっかけに指定できるGitHubイベントが24種類増えた。PRの競合発生やセキュリティアラートの作成などを受けて、設定した処理を開始できる。

REST APIを使い、外部システムから関連情報を渡してAutomationを起動することもできる。また、あるAutomationの成功・失敗を別のAutomationの開始条件にすることで、複数段階の処理を組める。

使用できるGitHubツールには、ワークフローの再実行やPRのマージ、画像・動画の添付などを行う20種類が加わった。独自のMCPサーバーも接続でき、Automationごとに使用を許すツールを選ぶ。外部サービスに対して何ができるかは、接続先の設定と認証情報にも左右される。

Automationごとに、AIクレジットの使用量の上限を設定できる。実行1回あたりの上限に達すると、その実行を停止する。日次・週次・月次の上限も設定でき、上限に達した場合は、次の集計期間に切り替わるまで、新しい実行を開始しない。

さらに、実行結果から改善案を作る機能も加わった。Copilotに、自動化したい作業と、その結果を振り返って改善する仕組みの作成を依頼すると、作業用と改善用のAutomationを組み合わせられる。

たとえばPRのレビューでは、PRが作成されたときに変更を確認してコメントするAutomationと、そのコメントへの開発者の対応を週次で分析し、レビュー方法の改善案を作るAutomationを用意する。Issueを分類するAutomationなら、付けたラベルを人が修正したか、性能改善を行うAutomationなら、作成したPRがマージされたかが、結果を評価する手掛かりになる。

改善用のAutomationが、作業用のAutomationのプロンプト、ツール、開始条件の変更を提案すると、GitHubから利用者に通知が届く。利用者は提案を確認して受け入れるか却下するかを選び、受け入れた変更が適用される。

VS Codeでは、これまでローカルで動く個人用の定期実行に対応していたが、今回、クラウド用Automationsの作成・管理にも対応した。クラウドで実行するため、PCの電源を切っていても定期処理を実行できる。VS Code 1.144以降で設定「chat.automations.cloud.enabled」を有効にすると、Agentsウィンドウの「Automations」タブから作成・管理できる。

Agentic Workflowsを一般提供⁠、定義をコードと一緒に管理

GitHub Agentic Workflowsは、GitHub Actions内でコーディングエージェントを動かすオープンソースプロジェクトで、6月のパブリックプレビューを経て一般提供となった。自動化したい処理を自然言語のMarkdownで定義すると、標準のActions用YAMLへ変換し、既存のランナーグループやポリシーの下で実行できる。Issueの整理、CIの失敗分析、文書更新、テスト作成などに使える。

Copilot Automationsは、GitHub上のリポジトリの「Agents」タブなどで作成・管理する。設定はリポジトリ内のファイルとしてGitにコミットするものではなく、コードとは別に保存される。一方、Agentic Workflowsでは、Markdownの定義と生成した.lock.ymlを両方コミットするため、自動化の定義そのものをコードと同じ履歴で管理し、変更をPRで確認できる。

GitHubはパブリックプレビュー以降の更新として、Actions Runner ControllerとDocker-in-Dockerを使うセルフホスト環境への対応や、AI費用予測の改善を挙げている。費用予測コマンドのgh aw forecastは実験段階を終えた。予測には脅威検出で消費するAIクレジットも含め、月間のAIクレジット使用量の見積もりには幅を持たせるようになった。

また、ワークフローごとに、モデルを利用するサービスを選べるようにした。たとえばClaude Codeを動かす場合、AnthropicのAPIを直接利用する構成のほか、GitHub Copilot経由でClaudeモデルを利用する構成も選べる。課題の種類や難しさに応じてモデルを振り分ける仕組みも用意した。

エージェントを軽量な仮想マシンで動かす選択肢や、複数リポジトリを扱う際のデータ漏えいを防ぐ隔離機能も、パブリックプレビューからの改善点として紹介している。

Agentic Workflowsで動くエージェントのGitHubへのアクセス権限は、デフォルトで読み取り専用となる。実行環境はサンドボックスで隔離し、通信先も制限する。Issueの作成などGitHubへの書き込みはsafe outputsという仕組みを通し、エージェントの出力を検証したうえで、必要な権限を持つ別のジョブが実行する。脅威検出で問題が見つかった場合の扱いは、設定したモードによって異なる[11]。

提供対象はgithub.comのGitHub Free、Team、Enterprise。標準のCopilot CLIエンジンにはCopilotライセンスが必要で、ほかの対応エンジンを使う場合は、それぞれに必要な認証を行い、利用条件を満たす必要がある。

なお、Actions workflow dependency lockfilesも、14日のパブリックプレビューを経て28日に一般提供となった。これはAgentic Workflowsとは別の機能で、ワークフローから呼び出すアクションと、そのアクションが依存するアクションについて、実行するコミットをactions.lockに記録する。ワークフロー内には読みやすいタグやブランチ名を残せる。そのタグやブランチが後で別のコミットを指すようになっても、実行には記録済みのコミットを使うため、依存先の意図しない変更を防げる[12]。

コードレビューとPR⁠・Issueの管理を更新

CopilotのコードレビューにMaxを追加⁠、承認機能を一般提供

Copilot code reviewには、レビューの処理レベルとして、Lite、Balancedに続くMaxをパブリックプレビューとして追加した。一方、PRを承認するCopilot approvalsは、9月からのパブリックプレビューを経て一般提供となった。

Copilot code review: Merge with confidence with Max and approvals - GitHub Changelog

Maxでは、異なる提供元のモデルを使う複数のエージェントが独立してレビューする。その後、集約するエージェントが指摘の食い違いや正確さを確認し、一つのレビューにまとめる。LiteやBalancedでのレビューより処理に時間がかかり、AIクレジットの消費も多くなる。GitHubは、認証処理や複数サービスが使うライブラリなど、詳しい確認が必要な変更向けの処理レベルとして案内している。

Copilot approvalsはデフォルトでは無効だが、管理者が有効にすると、Copilotがレビュー結果に基づいてPRを承認できる。その承認をマージに必要な承認として数える設定も用意されている。[13]承認後に新しいコミットがpushされると承認は取り消され、新しい承認を得るには再レビューが必要になる。Maxとapprovalsは、Copilot Pro、Pro+、Max、Business、Enterpriseで利用できる。

Agent Mergeで⁠、Actionsの失敗やマージ競合を修正

レビューを終えても、CIの失敗や競合がマージを妨げる場合がある。こうした問題を監視・修正するAgent Mergeを、GitHub CopilotアプリとVS Codeに続き、GitHub上のPRにも統合した。

PRの「Watch and fix」で、Actionsワークフローの失敗、マージ競合、または両方を修正対象に選ぶ。選んだ問題が発生すると、Copilotがクラウド環境で修正を進める。さらにGitHubの自動マージ機能（auto-merge）を有効にしておけば、修正後、必要なレビュー承認やチェックなどの条件がそろった時点でGitHubがマージする。クラウドでのAgent Mergeは有料Copilotプランが対象で、組織や企業が設定したポリシーも適用される。

PR投稿制限の免除条件と⁠、Issue管理用の権限

共同作業の管理では、書き込み権限を持たない投稿者からのPR数を制限する機能に、免除条件を追加した。アカウント作成からの経過日数や、投稿者のPRがそのリポジトリでマージされた件数に基準を設け、有効にした条件の少なくとも一つを満たす人は、上限を超えてPRを作成できる。組織またはリポジトリの設定にある「Moderation⁠」⁠→「⁠Interaction limits」で条件と基準値を設定する。

また、コードへのアクセスを付与せずにIssueの編集・管理を任せるModerateロールも案内したが、28日付の追記によると未提供で、今後数週間以内に提供を始める予定としている。

セキュリティ対策は⁠、ローカルの修正から公開情報の監視まで

GitHub Advanced Securityの製品群は、コードの脆弱性を扱うCode Securityと、秘密情報の漏えいを防ぐSecret Protectionに分かれ、それぞれ個別に契約できる。

GitHub Copilotアプリで⁠、ローカル変更のレビューと既存アラートの修正

GitHub CopilotアプリのSecurity拡張を、パブリックプレビューとして提供する。PRを開く前のローカル変更をレビューする機能と、リポジトリの既存コードスキャンアラートを確認・修正する機能を備える。

Security extension for the GitHub Copilot app - GitHub Changelog

ローカル変更のレビューは全Copilotプランで利用でき、Code Securityの追加契約は不要。アプリの「Customize」で「github-security」を検索してインストールし、/security-reviewで依頼する。Business・Enterpriseでは、管理者が設定したアプリの利用許可やプラグインの制限も適用される。

既存アラートを扱うには、リポジトリでコードスキャンを有効にし、利用者がアラートの閲覧権限を持っている必要がある。非公開リポジトリではGitHub Code Securityのライセンスも求められる。アプリ内でアラートの説明や修正を依頼でき、修正時にはCopilotがローカルの作業コピーを変更する。コミットやpushは行わないため、利用者が変更を確認してから反映できる。

説明、修正、ローカル変更のレビューには、アプリで選択したモデルを使い、通常の依頼と同様にAIクレジットを消費する。アラートの閲覧や却下にはAIクレジットを消費しない。

AIアプリケーション向けコードスキャンは、間接的なプロンプトインジェクション、機密情報の開示、エージェントへの過剰な権限付与などを検出対象とする。たとえば、信頼していない文書中の指示が、外部ツールやデータへアクセスできるAIに届くコードの経路を調べる。コードスキャンとAIアプリケーション向けの検査を有効にすると、PR作成時に既存のCodeQL解析と並行して動き、検出した問題に対処するための情報も提供する。

パブリックプレビューで、github.com上のGitHub Advanced Securityライセンスが必要となる。公式Docsによると、検査の実行時にはAIクレジットも消費する。

一方、リポジトリ向けAI Scanは、AIを使ってデフォルトブランチの最新コミットを調べるパブリックプレビュー機能。CodeQLが対応していない言語・フレームワークも対象とし、規則に基づく解析では見つけにくい脆弱性の検出を補う。

リポジトリ向けAI Scanを有効にした後、コードスキャンの書き込み権限を持つ利用者が画面から検査を開始する。検査には実行時間の上限があり、脆弱性がありそうな箇所を重点的に調べる。結果はコードスキャンのアラート一覧に表示し、修正をマージした後は再スキャンで解消を確認する。

AI ScanにCopilotライセンスは不要だが、Code SecurityのAIクレジットを消費する。組織のprivate・internalリポジトリではCode SecurityまたはAdvanced Securityが必要で、個人所有の非公開リポジトリには対応しない。PRの変更を対象にするAI Scanは15日に一般提供済みで、今回のリポジトリ向け機能とは有効化の設定も異なる。

Dependabotで⁠、脆弱な関数を呼び出す可能性を分析

10月28日には、Dependabotの到達可能性分析のパブリックプレビューを開始した。アプリケーションのコードから、依存パッケージ内の脆弱な関数へ至る呼び出し経路を探す機能で、依存パッケージに脆弱性があるかだけでなく、その箇所をアプリケーションが呼び出す可能性も示し、対応の優先順位を付けやすくする。

対象はGitHub Enterprise CloudのJavaScript・TypeScriptで、npm、Yarn、pnpmのlockfileが必要となる。プレビュー期間は無料で、Advanced Securityのライセンスは不要。分析に使うActionsの実行時間も課金されない。結果はアラートの補足情報であり、自動的にアラートを閉じたり、対応不要と判断したりはしない。

秘密情報の流出を防ぎ⁠、公開リポジトリやIssueへの漏えいを見つける

AIで秘密情報を検出し、pushによる流出を防ぐ機能もパブリックプレビューになった。専用のAI分類器は、秘密情報の候補が周囲のコードでどう使われているかを調べ、既知の文字列パターンに一致しない秘密情報も検出できる。検出すると、GitHubはその変更を拒否し、該当箇所を知らせる。

このブロック機能はデフォルトでは無効。既存のpush protectionとAIによる秘密情報スキャンの両方を有効にしたうえで、AIで検出した秘密情報のブロックも有効にする必要がある。github.comのSecret ProtectionまたはAdvanced Securityを持つ組織が対象で、push時のAI検出にはAIクレジットを使う。

公開後の漏えいを調べるPublic monitoringは、7月からのパブリックプレビューを経て一般提供した。Enterprise CloudでSecret ProtectionまたはAdvanced Securityを利用する企業が、追加料金なしで使える。

企業が所有するリポジトリに限らず、個人のforkや公開Issueへの書き込みなど、github.comの公開コンテンツへ流出した秘密情報を探す。企業のメンバー情報や検証済みドメインを使って、漏えいをどの企業へ通知するか判断する[14]。

一般提供に先立ち、22日にはデータ所在地を選べるEnterprise Cloudに対応し、23日にはアラート管理、漏えいした認証情報の有効性の自動確認、API・Webhook対応を追加していた。これにより、漏えいの発見後の対応状況を管理し、APIやWebhookで既存のインシデント対応システムと連携できる。

GitHub EnterpriseにCopilotの利用資格を含める

これまでは、GitHub Enterpriseの契約とは別にCopilot BusinessやCopilot Enterpriseの利用席数を契約・管理していた。今回、GitHub Enterprise Cloudで、GitHub Enterpriseライセンスに各ユーザーのCopilot利用資格を含める契約方式を導入した。まずGitHubまたはMicrosoftの営業担当を通じて契約する企業が、新規契約や既存契約からの移行で利用できる。

GitHub Enterprise now includes access to GitHub Copilot - GitHub Changelog

この方式では、Copilotの席数とAI利用量を別々に管理する負担を減らし、企業のAI予算を中心に利用を管理する。機能とモデルはCopilot Enterprise相当だが、席ごとの月間AIクレジットは付属せず、AI利用分は最初のリクエストから企業の予算に計上する。予算を使い切ってもコード補完とNext edit suggestionsは利用できる一方、チャット、コードレビュー、クラウドのCopilotには利用可能な予算が必要となる。

セルフサービス契約への提供は今後段階的に進める予定で、現在のセルフサービス契約には影響しない[15]。

増える作業を支えるGit⁠・Actions基盤の更新

GitHubはUniverseの発表をまとめた記事で、エージェントによる開発の増加に対応するため、容量の増強に加えて基盤の設計自体を変える方針を説明した。Git基盤では、構成要素の単純化、保存と計算の分離、調整処理の最小化という3つの原則を掲げた。

MicrosoftでCoreAIを率いるJay Parikh氏は、Universeにあわせた投稿で、基盤への投資を進めていると説明した。進行中の取り組みの一つとして、現在の180倍の処理量に対応できる新しいGitアーキテクチャを挙げている。

また、GitHub CTOのVladimir Fedorov氏は、Git基盤の拡張についての投稿で、1リポジトリ当たりの処理量について「毎秒7200回のpushができるとしたら、どうだろう」と問いかけた。

エージェントが並行して変更を加える環境では、コードの読み取りだけでなく、pushやマージの集中も基盤への負荷となるため、GitHubは稼働を続けながらGit基盤を再設計している。

Building Git infrastructure for agent-scale development - The GitHub Blog

この記事によると、これまではリポジトリの完全なコピーを複数サーバーに置き、保存と読み取り処理の両方に使っていた。読み取り用のコピーを増やすと書き込み時に調整する相手も増えるため、読み取りと書き込みを同時に増強しにくい。

そこで新しい設計では、保存をAzure Blob Storageへ分離し、読み取りを受け持つワーカーを独立して増減するようにした。書き込み時には、ブランチなどの参照先を更新する部分でだけ、更新内容が食い違わないように調整する。データの保存や検査をほかの書き込みと並行して進められるようにし、重いデータ整理も通常のGitリクエストを処理するサーバーから切り離した[16]。

GitHubは稼働基盤をAzureの複数リージョンへ移行しており、Universeでは、この移行を2027年初めに終える見通しを示した。

Actionsは対象LinuxジョブをAzureとAWSへ分散

Git基盤の変更とは別に、GitHub Actionsのホスト型ランナーを複数クラウドへ広げる変更も発表した。GitHub Actionsが、対象のLinuxジョブを利用可能なAzureまたはAWSの実行環境へ自動的に割り当てる。実行先を増やすことで、混雑時の待ち時間や計算資源の不足を減らす。既存のランナーラベルやワークフロー構文は変わらない[17]。

対象は標準の2・4コアLinuxランナーと、特殊な構成を持たない対応する2・4コアの大型ランナー。Windowsランナーや、プライベートネットワークなどの特殊な構成を使うランナーは対象外。Free、Pro、Teamでは対象ランナーへ自動適用し、Enterprise Cloudでは管理者がAWSの利用を有効にする。

Universe関連発表の一覧は、GitHub ChangelogのUniverse ⁠’26タグから確認できる。