GitHub Copilot in Visual Studio Code, June 2026 releases解説｜仕様差分・互換性・導入条件

「GitHub Copilot in Visual Studio Code, June 2026 releases」は、単なるチャット機能の追加ではありません。エージェントがブラウザを操作する範囲、並列作業の進め方、AIクレジットの確認方法、自動実行の権限、企業管理の配布方法まで変わる更新です。

結論から言うと、WebアプリのテストにCopilotを使う開発者、Agentsウィンドウで複数タスクを並行処理するチーム、CopilotをMDMやポリシーで管理する企業は、早めの対応が必要です。一方、コード補完を中心に使っている個人ユーザーは、緊急の移行作業こそ少ないものの、Autopilotやブラウザツールの既定動作は確認しておくべきです。

2026年7月9日時点で確認できるGitHub公式情報では、Changelogの掲載日は2026年7月8日です。対象は単一バージョンではなく、2026年6月から7月初旬に公開されたVisual Studio Code 1.123〜1.127です。(The GitHub Blog)

GitHub Copilot in Visual Studio Code, June 2026 releasesの全体像

今回の公式Changelogは、5つのVisual Studio Codeリリースに含まれるGitHub Copilot関連機能をまとめたものです。

以下は、各バージョンの公開日と主要な変更点を整理した表です。(Visual Studio Code)

VS Code	公開日	主なCopilot関連の変更
1.123	2026年6月3日	セッション同期、複数セッション表示、最大100万トークンのコンテキスト、ブラウザのスクリーンショット機能、MCP OAuth強化
1.124	2026年6月10日	Autopilotの既定有効化、完了判断の改善、バックグラウンド送信、ブラウザ履歴
1.125	2026年6月17日	Marketplaceからのモデルプロバイダー導入、リモートブラウザ、拡張機能更新の遅延設定、MDM管理
1.126	2026年6月24日	セッション単位のコスト表示、1セッション内の複数チャット、Workspace Trust変更
1.127	2026年7月1日	ブラウザツールの一般提供、サイト単位の権限、セッション整理、サブエージェントのコスト表示、ファイルベース管理

全機能を確認するなら、VS Code 1.127以降を基準にするのが分かりやすいでしょう。ただし、一般提供された機能とプレビュー機能が混在している点には注意が必要です。

対応を優先すべきユーザー

利用状況ごとの対応優先度は、次のように判断できます。

利用状況	優先度	取るべき対応
CopilotにWebアプリを操作・テストさせている	高	ブラウザツールの権限、Cookie、許可ドメインを再確認する
Copilot Business・Enterpriseを管理している	高	Autopilot、ブラウザ、セッション同期、MDM設定を小規模グループで検証する
Agentsウィンドウで並列作業している	高	同じファイルを複数チャットから編集しない運用を決める
組み込みOllamaプロバイダーを使っている	高	公式Ollama拡張機能への移行を進める
従来のEditモードに依存している	中〜高	Agentモードまたはカスタムエージェントへの移行を確認する
コード補完と通常のチャットだけを使っている	中	更新後の権限設定とコスト表示を確認する
リモート環境から統合ブラウザを使っている	中	リモートプロキシがプレビューであることを前提に検証する

特に企業利用では、機能追加そのものより、従来は無効またはプレビューだった機能が標準で利用可能になることが重要です。

統合ブラウザが「閲覧機能」から「自律テスト環境」へ変わった

今回の中心的な変更は、GitHub CopilotのブラウザツールがVS Code 1.127で一般提供になったことです。一般提供後は既定で有効となり、エージェントは外部MCPサーバーを用意しなくても、VS Codeの統合ブラウザを操作できます。(The GitHub Blog)

エージェントが実行できる代表的な操作は次のとおりです。

URLを開いてページ間を移動する
ボタンやリンクをクリックする
フォームへ文字を入力する
ダイアログを処理する
ページ内容やコンソールエラーを読み取る
スクリーンショットを取得する
Playwrightコードを実行する
結果を確認し、コードを修正して再テストする

従来は「画面のスクリーンショットをチャットに添付して相談する」という使い方が中心でした。現在は、Copilot自身がページを開き、操作し、不具合を発見して修正するところまでを一連の流れとして実行できます。(Visual Studio Code)

ユーザーが開いたタブとエージェントが開いたタブは扱いが異なる

ブラウザツールを評価するときは、タブの種類を分けて考える必要があります。

タブの開き方	Cookie・ログイン状態	エージェントからのアクセス
エージェントが自分で開いたタブ	原則として分離された一時セッション	そのセッションのエージェントが操作できる
ユーザーが開いたタブ	既存のCookieやログイン状態を利用	「Share with Agent」で明示的に共有するまで操作できない
別のエージェントセッションが開いたタブ	セッションごとに分離	他セッションからはアクセスできない

ユーザーが開いたタブを共有すると、ログイン済みのセッションやCookieも利用対象になります。社内システムや管理画面を共有するときは、閲覧だけを依頼したつもりでも、エージェントが操作可能な状態になる点を理解しておきましょう。

共有はいつでも解除できます。また、Autopilot中にエージェントから共有を要求された場合、その要求はプライバシー保護のため自動的に拒否されます。(Visual Studio Code)

カメラや位置情報は自動許可されない

統合ブラウザは、位置情報、カメラ、マイク、クリップボード、Bluetooth、USB、シリアル、HIDなどのサイト権限に対応しました。

これらの機密性が高い権限は、エージェントが勝手に許可することはできません。サイトごとに人が許可または拒否する必要があります。(The GitHub Blog)

ただし、権限ダイアログがあるから安全だと考えるのは危険です。ログイン済みページ上のボタン操作やフォーム送信など、サイト権限を必要としない操作もあります。本番環境でブラウザツールを試す場合は、削除、公開、決済、メール送信などの副作用を起こす操作を避けてください。

企業ではアクセス先ドメインを制限できる

管理者は、ブラウザツール自体を無効化するほか、エージェントが接続できるドメインを許可リスト・拒否リストで制御できます。

主な管理項目は次のとおりです。

目的	ポリシーまたは設定
ブラウザツールを無効化する	`BrowserChatTools`
ネットワークフィルターを有効化する	`ChatAgentNetworkFilter`
許可ドメインを定義する	`ChatAgentAllowedNetworkDomains`
拒否ドメインを定義する	`ChatAgentDeniedNetworkDomains`

拒否ドメインが許可ドメインより優先され、ワイルドカードも利用できます。ネットワークフィルターを有効にした状態で許可・拒否リストが空の場合は、エージェントのネットワークアクセスがすべて遮断されます。(Visual Studio Code)

企業での初期導入では、全面許可から始めるより、開発環境、テスト環境、必要な外部ドキュメントだけを許可する方が安全です。

Agentsウィンドウで並列処理できる範囲が拡大

Agentsウィンドウでは、複数のエージェントセッションを横に並べて表示できます。VS Code 1.127では、グループ化、並べ替え、ピン留めなど、セッションが増えたときの整理機能も追加されました。

ただし、Agentsウィンドウ自体は引き続きプレビューです。利用にはVS Code、GitHub Copilotへのアクセス、GitHub認証が必要です。(Visual Studio Code)

複数セッションと複数チャットは別の機能

混同しやすいのが、「複数セッション」と「1セッション内の複数チャット」の違いです。

機能	作業領域	会話履歴	主な用途
複数セッション	セッションごとに異なるワークスペースや作業単位を持てる	セッションごとに独立	複数プロジェクトや複数タスクの管理
複数チャット	同じセッションのワークスペースとワークツリーを共有	チャットごとに独立	実装、テスト、レビュー、文書作成の分担

複数チャットは、対応するエージェントホストセッションでのみ利用できます。公式ドキュメントでは、Copilot CLIやClaudeセッションなどが対象として挙げられています。通常のすべてのチャットで使えるわけではありません。(Visual Studio Code)

同じファイルを並行編集させない

複数チャットは会話こそ独立していますが、ワークスペースとワークツリーは共有します。そのため、次のような依頼は競合しやすくなります。

チャットAにAPI実装、チャットBに同じAPIのリファクタリングを依頼する
複数チャットから同じ依存関係ファイルを更新する
一方がデータベース定義を変更している間に、もう一方がマイグレーションを生成する
一方がテストを修正し、もう一方が古い仕様を前提に実装を変更する

並列作業を安定させるには、担当範囲をファイルやディレクトリ単位で分けます。

例えば、次のような分担であれば競合を抑えやすくなります。

チャットA：src/features/login/の実装
チャットB：tests/login/のテスト作成
チャットC：変更内容を基にしたドキュメント作成

VS Code 1.127では複数チャットの変更がまとめてChangesへ表示されますが、表示が集約されることと、編集競合が自動解消されることは別です。最終的な差分確認とテストは人が行う必要があります。(Visual Studio Code)

横に表示していてもアクティブなセッションは1つ

複数セッションを並べていても、アクティブ扱いになるセッションは1つです。Terminal、Files、Changesなどの表示内容は、現在アクティブなセッションに追従します。(Visual Studio Code)

別セッションの変更を確認しているつもりで、実際には直前のセッションのターミナルを操作していた、というミスが起こり得ます。コマンド実行前には、対象セッション名とワークスペースを確認してください。

AIクレジットをセッション単位・サブエージェント単位で確認できる

2026年6月1日から、GitHub CopilotではすべてのプランでAIクレジットを基準とした使用量課金が有効になりました。各プランには月ごとの利用枠が含まれ、追加利用の扱いはプランや予算設定によって異なります。(The GitHub Blog)

今回のVS Code更新では、利用量を確認できる場所が増えています。

バージョン	確認できる内容
1.125	追加利用予算に対して何％使用したか
1.126	チャットセッション全体のAIクレジット
1.127	サブエージェントが個別に消費したAIクレジット

VS Code内の表示は、どの作業が高コストだったかを発見するために有効です。一方、追加利用の上限や予算管理は、GitHub側のCopilot設定も合わせて確認する必要があります。(Visual Studio Code)

並列化すると利用量も増えやすい

複数チャットやサブエージェントを使えば処理時間を短縮できる可能性がありますが、それぞれがモデルへリクエストを送ります。

特に、次の組み合わせはAIクレジットが増えやすくなります。

複数チャットを同時に実行する
サブエージェントへ調査やレビューを委譲する
推論強度を高くする
大量のファイルをコンテキストへ含める
最大100万トークンのコンテキストを使う
ブラウザ操作と修正を何度も繰り返す

最大100万トークンのコンテキストは、対応するAnthropicおよびOpenAIモデルで利用できます。ただし、コンテキストを大きくするほど、1回の処理で消費するトークンやAIクレジットが増える可能性があります。(Visual Studio Code)

導入テストでは、単に「作業が完了したか」だけでなく、次の項目も記録すると判断しやすくなります。

使用モデル
コンテキストサイズ
推論強度
セッション全体のAIクレジット
サブエージェントの数
完了までの反復回数
人が修正したファイル数

Marketplaceからモデルプロバイダーを追加可能に

VS Code 1.125では、Language Modelsエディターから、モデルを提供する拡張機能を検索・インストールしやすくなりました。導入後のモデルは、既存のモデルやBYOKモデルと同じモデル選択画面に表示されます。(Visual Studio Code)

VS Code 1.126では、コンテキストサイズと推論強度の設定が、統合されたモデルカスタマイズ画面へまとめられました。(Visual Studio Code)

モデルが一覧に表示されることと、同じ条件で使えることは別

モデルプロバイダー拡張機能を導入すると選択肢は増えますが、次の項目はプロバイダーごとに確認が必要です。

認証方法
利用料金
データの送信先
ログや入力内容の保持方針
対応するコンテキストサイズ
ツール呼び出しや画像入力への対応
組織ポリシーとの整合性

同じプロンプトでも、モデルや推論強度が変われば、生成されるコード、変更範囲、処理時間、AIクレジットは変わります。回帰テストでは、モデルを固定して比較してください。

組み込みOllamaプロバイダーは非推奨

VS Code 1.127では、従来の組み込みOllamaプロバイダーが非推奨になりました。ローカルのOllamaモデルを継続利用する場合、公式Ollama拡張機能をインストールし、組み込みプロバイダーを削除する方法が推奨されています。(Visual Studio Code)

既存のOllama環境では、VS Code更新前に次を控えておくと移行しやすくなります。

利用中のモデル名
接続先URL
コンテキストサイズ
モデル固有の設定
カスタムプロンプトや指示ファイル
動作確認に使っている代表的な質問

Autopilotは既定で有効になったが、全チャットが無承認実行になるわけではない

Autopilotは、エージェントが各操作のたびに確認を求めず、自律的に作業を進めるための権限レベルです。VS Code 1.124では、Autopilot機能が既定で有効になりましたが、機能自体は引き続きプレビューです。(Visual Studio Code)

ここで注意したいのは、Autopilotが利用可能になることと、新しいチャットが必ずAutopilotで始まることは同じではない点です。

関連する設定は分かれています。

設定	役割
`chat.tools.global.autoApprove`	Autopilotや全体的な自動承認の利用可否
`chat.permissions.default`	新しいチャットで使う既定の権限レベル
`chat.autopilot.advanced.enabled`	高度な完了判断を試す設定

Advanced Autopilotを有効にすると、小規模なユーティリティモデルが会話履歴を確認し、タスクを続けるべきか、完了と判断するべきかを決めます。無制限にループするわけではなく、最大3回で停止します。(Visual Studio Code)

企業ではバイパスモードを禁止できる

企業管理設定では、disableBypassPermissionsModeを使用して、ユーザーがバイパスモードを有効にできないようにできます。

この設定を適用すると、VS Codeのグローバル自動承認設定をユーザーが再度有効にできなくなります。(GitHub Docs)

次のような環境では、Autopilotを全面的に許可する前に、承認を残した方が安全です。

本番データベースへ接続できる
クラウドや社内基盤の管理権限を持つ
シークレットを含む環境変数へアクセスできる
パッケージの公開やデプロイを実行できる
外部サービスへの書き込みAPIを利用できる

Autopilotの完了判断が改善されても、要件を正しく理解したことや、テストが十分であることまで保証されるわけではありません。

企業管理はMDM・サーバー・JSONファイルの3方式に拡大

GitHub Copilotの管理設定は、次の3つの経路から配布できるようになりました。

配布方法	向いている環境
Native MDM	Intune、Jamf、グループポリシーなどで端末を管理している
Server-managed	GitHub上で設定変更をレビューし、履歴を残したい
File-based	Linux、コンテナ、Codespaces、MDM未登録端末を管理したい

複数の経路から設定が提供された場合、優先順位は次のとおりです。

Native MDM
Server-managed
File-based

下位の設定を一部だけ補完するのではなく、優先順位が高いチャネルの設定が採用されます。(The GitHub Blog)

managed-settings.jsonの配置場所

ファイルベース管理では、OSごとに決められた場所へmanaged-settings.jsonを配置します。

OS	配置場所
Windows	`%ProgramFiles%\GitHubCopilot\managed-settings.json`
macOS	`/Library/Application Support/GitHubCopilot/managed-settings.json`
Linux	`/etc/github-copilot/managed-settings.json`

設定ファイルは、一般ユーザーが自由に書き換えられない所有権と権限にする必要があります。シンボリックリンクや、誰でも書き込めるファイルは管理設定として認められません。(The GitHub Blog)

反映タイミングも配布方法によって異なる

MDM管理では、クライアントが定期的に設定を確認します。VS Codeでは、テスト時にDeveloper: Sync Account Policyコマンドを使って同期を実行できます。

一方、ファイルベースの設定はクライアント起動時に読み込まれるため、変更後はVS Codeの再起動が必要です。公式ドキュメントでも、全社配布の前に小規模な端末グループで試験することが推奨されています。(GitHub Docs)

セッション同期はデータ管理の対象として確認する

VS Code 1.123では、チャットセッションをGitHubアカウントへ同期し、別の端末やワークスペースから検索できる機能が追加されました。

同期されるセッションには、会話だけでなく次の情報も含まれます。

操作したファイル
リポジトリ
ブランチ
タイムスタンプ
会話内で参照したPull Request
Issue
コミット

設定はchat.sessionSync.enabledで管理され、組織側から制御できます。(Visual Studio Code)

これは単なるエディター設定の同期ではありません。ソースコードそのものを送るかどうかだけで判断せず、会話、ファイル名、ブランチ名、Issue番号などが業務情報に該当しないか確認してください。

特に、顧客名を含むブランチ名、未公開製品のIssue、脆弱性対応の会話などを扱う組織では、利用規程と保存方針を決めてから有効化するのが安全です。

MCP利用者はOAuth設定の互換性を確認する

VS Code 1.123では、mcp.jsonのOAuth設定に、事前登録したクライアントIDを指定できるようになりました。

クライアントシークレットが必要な場合は、設定ファイルへ平文で記録するのではなく、OSに対応したVS Codeのシークレットストレージへ保存できます。(Visual Studio Code)

従来のDynamic Client Registrationを使うMCPサーバーは、直ちにすべて変更する必要はありません。事前登録クライアントを要求するサーバーで、明示的なclientIdを利用できるようになった変更です。

企業のIdPを利用するMCP認証もプレビューとして追加されていますが、基盤となる方式は新しい標準を利用しています。IdP、認可サーバー、MCPサーバーの組み合わせごとに検証し、既存認証を一斉に置き換えない方がよいでしょう。(Visual Studio Code)

既存環境で見落としやすい互換性変更

今回の更新には、明確なエラーにならず、挙動だけが変わる項目が含まれています。

項目	従来	更新後	必要な確認
`extensions.autoUpdate`	`true`、`false`、`delayed`など	`on`、`off`へ簡略化	自動移行されるが、配布元の設定テンプレートも新形式へ直す
無効化した拡張機能	自動更新される場合があった	有効化するまで自動更新されない	再有効化時に想定外の更新が入らないか確認
拡張機能更新の遅延	即時更新が中心	既定で2時間遅延	緊急修正を手動更新する手順を決める
Workspace Trust	初回に信頼確認ダイアログ	Restricted Modeで開き、バナーを表示	ダイアログ前提の手順書や自動テストを修正
Editモード	標準の編集モード	非推奨	Agentモードまたはカスタムエージェントへ移行
組み込みOllama	VS Code内蔵プロバイダー	非推奨	公式Ollama拡張機能へ移行
リモートブラウザ	ポート転送が中心	HTTP・HTTPSをリモート接続経由でプロキシ可能	プレビューとしてネットワーク経路を検証
ブラウザツール	プレビューまたは明示利用	一般提供・既定で有効	組織ポリシーと許可ドメインを確認

2時間の更新遅延をCopilotの段階導入策にしない

拡張機能の自動更新は既定で2時間遅延されますが、Microsoft、GitHub、OpenAIなどの信頼済み発行元は遅延対象外です。(Visual Studio Code)

そのため、GitHub Copilot関連の更新を段階的に検証したい場合、単にextensions.autoUpdateDelayを設定するだけでは不十分です。端末グループ、VS Code更新ポリシー、パイロットユーザーなどを使って配布範囲を分ける必要があります。

Workspace Trustのダイアログが出ないのは不具合ではない

VS Code 1.126では、未知のフォルダーを開いたとき、最初に信頼確認ダイアログを出すのではなく、Restricted Modeで開いてバナーを表示する動作へ変わりました。

security.workspace.trust.startupPromptの既定値は、onceからneverへ変更されています。以前のダイアログを戻す場合はonceへ設定します。(Visual Studio Code)

Restricted Modeでは、コードの自動実行や一部の拡張機能が制限されます。「Copilotのツールが表示されない」「テストコマンドが動かない」といった場合は、最初にワークスペースの信頼状態を確認してください。

EditモードはAgentモードへの移行を検討する

VS Code 1.126では、従来の組み込みEditモードが非推奨になりました。代替として、コード編集に加えてタスクやツールも実行できるAgentモードが推奨されています。

ただし、組織ポリシーによってAgentモードが無効化されているユーザーには、従来のEditモードが引き続き表示されます。(Visual Studio Code)

社内マニュアルや研修資料でEditモードを案内している場合は、画面名称だけでなく、承認範囲の違いも含めて更新してください。

導入条件を機能別に確認する

機能	主な導入条件	提供状態
ブラウザエージェントツール	VS Code 1.127以降、Copilotへのアクセス、ツールとポリシーが有効	一般提供
Agentsウィンドウ	Copilotへのアクセス、GitHub認証	プレビュー
1セッション内の複数チャット	VS Code 1.126以降、対応するエージェントホスト	Agentsウィンドウがプレビュー
最大100万トークンのコンテキスト	VS Code 1.123以降、対応モデル	モデル依存
リモートブラウザプロキシ	VS Code 1.125以降、設定の有効化	プレビュー
MDM管理	GitHub Enterpriseの管理権限、WindowsまたはmacOSのMDM環境	一般提供
ファイルベース管理	対応クライアント、管理者権限でのファイル配布	一般提供
MCPの企業管理認証	対応IdP、認可サーバー、MCPサーバー	プレビュー

VS Codeを1.127へ更新しただけでは、すべての機能が利用できるとは限りません。Copilotの利用資格、組織ポリシー、セッション種別、選択モデル、ネットワーク制限も影響します。(Visual Studio Code)

機能が表示されないときの確認順序

新機能が見つからない場合は、次の順番で確認すると原因を切り分けやすくなります。

VS Codeのバージョンを確認する
ブラウザツールの一般提供は1.127、複数チャットは1.126が基準です。
GitHubへ正しいアカウントでサインインしているか確認する
個人用と会社用のアカウントを切り替えている場合は、Copilotの利用資格があるアカウントか確認します。
ワークスペースがRestricted Modeになっていないか確認する
未信頼のフォルダーでは、ツールや拡張機能が制限されることがあります。
組織ポリシーを確認する
ブラウザツール、Autopilot、セッション同期、モデル、プラグインが管理者によって無効化されている可能性があります。
チャットのTools選択画面を確認する
ブラウザツールが設定上有効でも、現在のチャットで利用対象になっているかを確認します。
利用中のセッション種別を確認する
複数チャットは、対応するエージェントホストセッションでのみ表示されます。
拡張機能が無効になっていないか確認する
無効化された拡張機能は、自動更新されず、再有効化時まで古いバージョンのまま残ることがあります。

導入前に実施したいテスト

ブラウザツールのテスト

テスト内容	手順	合格基準
未共有タブの保護	ユーザーがページを開き、共有せずに内容を質問する	エージェントがページ内容を読めない
共有解除	ページ共有後に解除し、再度操作を依頼する	解除後はアクセスできない
Cookie分離	ログイン済みタブとは別にエージェントへ同一サイトを開かせる	エージェント側へログイン状態が引き継がれない
ドメイン制御	拒否ドメインへのアクセスを依頼する	ポリシーどおり遮断される
サイト権限	カメラや位置情報を要求するテストページを開く	人の承認なしに許可されない
フォーム操作	テスト環境のフォームを入力・送信させる	指定した値と遷移結果が一致する
コンソール確認	意図的なJavaScriptエラーを発生させる	エラーを検出し、修正後に再確認できる

テストには本番アカウントではなく、専用のテストユーザーとテスト環境を使います。

統合ブラウザで正常に動いたことだけを理由に、リリース可能と判断してはいけません。SafariやFirefox、実機ブラウザ、支援技術まで含めた互換性は、従来どおり別の自動テストや実機確認が必要です。

リモート環境のテスト

リモートブラウザプロキシはプレビューです。Dev Container、SSH、WSL、Codespacesなどで利用できますが、次の制約があります。

HTTP・HTTPS通信が対象
file://はプロキシされない
workbench.browser.dataStorageがglobalの場合は利用できない
エージェントが開くタブもリモート経由になる
無効時はポート転送後のローカルURLへ書き換えられる場合がある

リモートプロキシを利用する場合、ブラウザのストレージはworkspaceまたはephemeralで検証してください。(Visual Studio Code)

並列チャットのテスト

最初から同じファイルを複数チャットに編集させるのではなく、次の順番で検証します。

別ディレクトリを編集する2つのチャットを同時に動かす
Changesへ両方の差分が集約されることを確認する
一方の変更を参照して、もう一方がテストを作成できるか確認する
意図的に同じファイルを変更させ、競合時の挙動を確認する
変更後に全テストと静的解析を実行する
Pull Requestへ不要な差分が混入していないか確認する

Autopilotのテスト

Autopilotでは、結果だけでなく「どこまで無承認で進んだか」を確認します。

ファイルの作成・削除
ターミナルコマンド
パッケージの追加
ネットワークアクセス
Git操作
テストの自動修正
ブラウザ操作
サブエージェントへの委譲

テスト環境では成功しても、本番権限を持つ端末では同じ設定を使わない方がよいケースがあります。開発者端末の権限を一律に考えず、担当業務やアクセス可能なシステムに応じてポリシーを分けてください。

コストとモデルのテスト

同じ代表タスクを、条件を固定して複数回実行します。

記録する条件は次のとおりです。

VS Codeバージョン
利用モデル
コンテキストサイズ
推論強度
Autopilotの有無
サブエージェント数
セッションのAIクレジット
処理時間
生成・変更されたファイル
テスト成功率
人による修正量

モデルだけを変え、コンテキストや依頼内容も同時に変えてしまうと、コスト増加の原因を特定できません。

企業向けの安全な導入手順

現状を棚卸しする

最初に、次の利用状況を確認します。

VS Codeの配布バージョン
GitHub Copilot拡張機能の更新方法
ブラウザツールの利用有無
Autopilotや自動承認の利用有無
Agentsウィンドウの利用者
Ollamaの組み込みプロバイダー利用者
Editモードに依存する手順
セッション同期の有効化状況
MCPサーバーと認証方式
Copilotの追加利用予算

初期ポリシーを決める

少なくとも、次の項目は全社展開前に決めておきます。

ブラウザツールを許可する対象者
エージェントが接続できるドメイン
本番サイトへのアクセス可否
Autopilotを許可する端末
バイパスモードを禁止するか
セッション同期を許可するか
Marketplaceのモデルプロバイダーを自由に追加できるか
AIクレジットの追加利用上限
ファイルベース設定を配布する端末
設定競合時にどの配布チャネルを正とするか

小規模グループで試す

最初のパイロットには、次の異なる環境を含めると問題を見つけやすくなります。

ローカル開発だけを行うユーザー
Dev ContainerやSSHを使うユーザー
Webフロントエンド開発者
MCPを利用するユーザー
Agentsウィンドウを利用するユーザー
Windows、macOS、Linuxの各端末

パイロット中は、不具合だけでなく、AIクレジット、権限確認の回数、レビュー時間、競合したファイルも記録します。

人によるレビューとCIをリリース条件に残す

ブラウザツールが「ビルド、テスト、修正、再テスト」を自動化できても、Copilotの自己申告だけをリリース条件にはできません。

最低限、次の確認を残します。

人による差分レビュー
単体テスト
結合テスト
静的解析
セキュリティ検査
対応ブラウザでのテスト
必要に応じたアクセシビリティ確認
本番相当環境でのスモークテスト

よくある疑問

VS Code 1.127へ更新すれば、すべての機能を使える？

すべて使えるとは限りません。

VS Codeのバージョンに加えて、GitHub Copilotの利用資格、組織ポリシー、ワークスペースの信頼状態、チャットのツール設定、セッション種別、対応モデルが影響します。

統合ブラウザがあれば、Playwrightや外部MCPは不要？

一般的な画面操作やWebアプリの確認では、外部MCPサーバーなしでブラウザツールを使えます。

ただし、CI上で毎回同じ結果を出す自動テスト、複数ブラウザの互換性確認、専用サービスとの連携、複雑な認証基盤などでは、従来のPlaywrightテストや専用MCPが引き続き必要です。

Autopilotが既定で有効になったのは危険？

Autopilot機能が利用可能になったこと自体で、すべてのチャットが無条件に自動実行へ切り替わるわけではありません。新規チャットの既定権限や、組織の自動承認ポリシーを確認する必要があります。

管理者はバイパスモードを禁止できます。個人利用でも、現在のチャット入力欄に表示される権限レベルを確認してから、重要なリポジトリで使いましょう。

今回の更新をすぐ適用すべき？

セキュリティ修正を含むVS Code本体の更新は進めつつ、ブラウザツール、Autopilot、並列チャット、モデルプロバイダーは段階的に有効化するのが現実的です。

特に、Ollama組み込みプロバイダー、Editモード、企業管理設定を使っている場合は、互換性確認を先送りしない方がよいでしょう。

対応要否を判断するための最終チェック

今回のGitHub Copilot in Visual Studio Code, June 2026 releasesで、最初に実施すべきことは次の3点です。

VS Codeのバージョンと、Ollama・Editモード・Agentsウィンドウの利用状況を確認する
ブラウザツール、Autopilot、セッション同期、モデル追加に関する組織方針を決める
テスト環境と小規模な端末グループで、権限、並列編集、コスト、既存ワークフローへの影響を検証する

今回の更新は、GitHub Copilotを「質問に答える補助ツール」から、「複数の作業を進め、ブラウザで結果を検証する実行主体」へ近づけるものです。

便利になった分、確認すべき対象も、生成コードだけでは足りません。アクセス先、共有したログイン状態、実行権限、並列編集、利用コスト、設定の配布経路まで含めて管理することが、安定した導入につながります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。