追記: 2026年6月12日の最新情報
VS Code 1.124が2026年6月10日に公開され、この記事で扱ったAgents windowまわりの確認点が少し進みました。公式リリースノートでは、Autopilotが既定で有効になり、組織側はchat.tools.global.autoApproveで利用可否を管理できると説明されています。個々のチャットではchat.permissions.defaultで新規チャットの既定権限を調整できます。
Agents windowでは、新しいセッションをバックグラウンドに送って次の依頼を続けて書けるBackground sessionsも追加されました。複数セッションを並行して扱いやすくなる一方、レビュー、権限、モデル選択、実行ログの見方をチーム内でそろえる必要があります。
企業管理の観点では、Enterprise-managed Copilot plugin policiesがExperimentalとして追加され、VS CodeがCopilot CLIのenterprise plugin standardsと同じ設定ファイルを読むようになりました。プラグインの許可リスト、追加マーケットプレイス、信頼するマーケットプレイスの制限を、VS Code側だけでなくCLI側の運用とも合わせて確認してください。一次情報はVisual Studio Code 1.124 release notesで確認できます。
このテーマをもう少し広げて見るなら、Copilot CLIに/security-reviewが公開プレビュー：CodeQL・Secret scanningと併用する確認ポイント と GitHub CopilotのEnterprise-managed pluginsがVS Codeでpublic preview：MCP、hooks、skillsを企業で標準化する確認ポイント も合わせて確認してください。VS Code 1.124の企業管理ポリシーがCopilot CLIの標準化とつながるため、CLI側の安全確認も続けて読める。
3行まとめ
previewやexperimentalの表記を外さず、試せる範囲と本番運用の判断を分けて読むのが前提です。
GitHubは2026年6月3日、Visual Studio CodeにおけるGitHub Copilotの5月更新を、VS Code 1.120から1.123までの流れとして整理しました。中心は、Agents windowのStable preview、remote agentsとAgent Host Protocol、BYOK、ターミナル安全機能です。
利用者目線では、VS CodeのCopilotが「質問に答える補助」から、複数セッション、遠隔実行、独自モデル接続、MCP、ターミナル操作を含むエージェント作業面へ広がっている点が重要です。
ただし、すべてが本番運用前提で使えるわけではありません。Agents windowとremote agentsはpreview、ターミナルのrisk assessmentはexperimentalであり、BYOKもGitHubサインインなしで使える範囲と、なおサインインが必要な範囲を分けて読む必要があります。
今回の記事は、GitHub Changelog、VS Code 1.120、1.121、1.122、1.123の公式リリースノート、VS CodeのCopilot設定リファレンスを2026年6月8日に確認して書いています。Visual Studio MagazineやGitHub CopilotコミュニティでBYOKやAgents windowへの反応が出ていることは需要シグナルとして見ましたが、本文の事実認定には使っていません。2026年6月のMicrosoft関連発表をまとめて追う場合は、Microsoft 2026年6月重要トピックまとめもあわせて確認してください。
Agents windowはStable previewで何を試せるのか
Stableで使えるpreviewなので、標準機能のように扱わず、レビューのしやすさから小さく試すのが現実的です。
今回の5月更新を読む入口は、Agents windowです。VS Code 1.120の公式リリースノートでは、Agents windowがStableでpreviewとして使えるようになったことが示されています。これは、従来のChat viewを少し広げたものというより、エージェントに任せる作業を見渡し、進行を確認し、結果をレビューするための別の作業面として読むべき更新です。
GitHub Changelogでも、Agents windowは複数プロジェクトをまたいで、より速く移動し、変更を確認するための専用サーフェスとして整理されています。ここで大事なのは、VS Codeの主画面を置き換える話ではないことです。短い質問、コード片の説明、ちょっとした修正相談なら、従来のChat viewで十分な場面は残ります。
Chat viewとAgents windowの使い分け
個人開発者が最初に見るべきなのは、作業の長さです。数分で終わる質問ならChat viewでよく、依存関係の確認、複数ファイルの修正、レビュー待ちの差分確認、別ブランチでの検証を含む作業ならAgents windowを試す価値があります。
チームで見る場合は、さらに「誰がセッションを追うのか」が論点になります。エージェントが作った変更をレビューする人、実行したコマンドを見る人、途中で方針を変える人が分かれるなら、作業がチャット欄の奥に沈まないことは意味があります。
| 作業 | Chat view向き | Agents window向き |
|---|---|---|
| APIの使い方を聞く | 向いている | やや重い |
| 1ファイルの小修正 | 向いている | 変更確認が多いなら候補 |
| 複数ファイルの実装修正 | 状況次第 | 向いている |
| 長めの検証やレビュー | 追いにくい | 向いている |
| 複数プロジェクトの並行作業 | 追いにくい | 試す価値がある |
preview扱いを外して読まない
注意点
Stableで使えるpreviewという表現は、導入判断でかなり大事です。Insidersだけで触れる実験より試しやすい一方、企業の標準開発フローへ即採用する完成版という意味ではありません。まずは検証用リポジトリ、権限の弱い環境、レビューしやすいタスクで試すのが自然です。
特に、エージェント作業では「動いたか」だけでなく、「何を読んだか」「どのコマンドを実行したか」「どの差分を残したか」を追える必要があります。Agents windowはその確認をしやすくする方向の更新ですが、レビュー責任そのものを消す機能ではありません。
VS Code 1.123で見える方向性
VS Code 1.123の公式リリースノートでは、Agents windowのセッション一覧にgrid layoutが入ったこと、セッション内のフィードバックがthreaded repliesを扱うようになったことなどが示されています。小さなUI更新に見えますが、複数セッションを並べて扱う前提が強まっているサインです。
つまり、VS CodeのCopilotは「ひとつのチャットを開いて一問一答する」体験から、作業単位のセッションを並べて管理する方向へ寄っています。ここは、GitHub Copilot appがBuild 2026でプレビュー拡大した流れとも読み比べると分かりやすいところです。
Remote agentsとAHPは長時間セッションの運用論点になる
- 1Agents window
作業の入口になります。どのセッションを開き、誰が進行を見るのかを決めます。
- 2SSHまたはDev Tunnels
接続経路になります。接続ユーザー、作業ディレクトリ、アクセスできるリポジトリを先に分けます。
- 3VS Code CLIとCLI server
リモート側に必要な実行基盤です。導入や更新を誰が管理するかを確認します。
- 4agent host
軽量プロセスとして動きます。クライアント切断後も残る可能性があるため、終了条件が必要です。
- 5remote workspace
実際に触るコードと環境です。秘密情報、長時間コマンド、ログの扱いを運用ルールに含めます。
長時間作業を続けられることは利点ですが、セッション停止、権限、監査ログまで含めて確認する領域です。
VS Code 1.121では、remote agentsがpreviewとして説明されています。公式リリースノートによれば、Agents windowはSSHまたはDev Tunnelsでリモートマシンに接続し、VS Code CLIのインストールやCLI serverへの接続を通じて、agent hostという軽量プロセスを動かします。
ここは、単に「リモートでもCopilotが使える」という話に縮めない方がよいです。remote agent hostは長く動くプロセスとして扱われ、クライアントが切断されてもリモート上でセッションが続く可能性があります。ノートPCを閉じても長い作業を進められるのは利点ですが、同時に管理対象でもあります。
SSHとDev Tunnelsの前に決めること
実務でremote agentsを試すなら、先にリモート側の権限を決めるべきです。どのユーザーで接続するのか、作業ディレクトリはどこか、エージェントが触れてよいリポジトリはどこまでか、秘密情報を含むファイルにアクセスできるのかを分けます。
さらに、切断後も作業が残るなら、終了条件も必要です。セッションを誰が止めるのか、実行中コマンドのログをどこで見るのか、失敗したときに中断する基準は何か。ここを曖昧にすると、便利な遠隔実行が、監査しにくい背景プロセスになります。
AHPは複数クライアント協調のためのプロトコル
同じVS Code 1.121のリリースノートでは、Agent Host Protocolも説明されています。AHPは、agent hostが権威ある状態を管理し、それを接続クライアントへ同期し、変更を順序づけるためのプロトコルとして示されています。
この記事ではAHPと他プロトコルの優劣比較には踏み込みません。公式情報から読める実務上のポイントは、エージェント作業の状態を複数クライアントで扱う前提が置かれていることです。作業者、レビュー担当、別端末からの確認が分かれるチームでは、この状態同期の考え方が重要になります。
導入前チェック
確認項目
- SSHまたはDev Tunnelsの利用を組織として許可しているか
- remote agent hostを動かすユーザー権限を限定できるか
- セッションが切断後も続く場合の終了手順を決めているか
- ログ、差分、実行コマンドをレビューできるか
- 本番環境や機密リポジトリへ誤接続しない制御があるか
- 複数クライアントで同じセッションを見るときの責任者が決まっているか
Remote agentsは、長時間タスクには魅力があります。ただし、長く走れるものほど、権限、ログ、費用、終了条件を先に決める方が安全です。
BYOKはGitHubサインイン不要化で試しやすくなったが、範囲は限定される
BYOKのリクエストはproviderへ直接送られるため、API key、ネットワーク経路、請求、ログの責任範囲も確認対象になります。
VS Code 1.122で、Bring Your Own Key、つまりBYOKの読み方が変わりました。公式リリースノートでは、以前はVS Codeで自分の言語モデルAPIキーを使うにもGitHubサインインが必要だったが、今はGitHubサインインなしでBYOKを使えるようになったと説明されています。
これは、制限された環境やair-gappedに近い環境でVS CodeのAI機能を試したいチームには大きい変更です。Ollamaのようなローカルモデル、Anthropic、Azure、Gemini、OpenAI、OpenRouter、Custom Endpointなど、モデル接続の選択肢を自分たちの管理下に置きやすくなります。
使える範囲はchat、tools、MCP servers
条件
ただし、ここで一番間違えやすいのは、Copilot全体がGitHubサインイン不要になったと読むことです。VS Code 1.122の公式ノートは、BYOKがサインインなしで使える範囲をchat、tools、MCP serversとして示しています。
一方で、inline suggestionsとnext edit suggestions、つまりエディタ内の補完や次の編集候補は、引き続きGitHubサインインが必要とされています。この境界を落とすと、企業内の導入説明がかなり危うくなります。
| 見る項目 | GitHubサインインなしBYOKで扱える範囲 | 別扱いにする範囲 |
|---|---|---|
| Chat | 対象 | provider側の送信範囲を確認 |
| Tools | 対象 | ツール権限を別途確認 |
| MCP servers | 対象 | 接続先と権限を別途確認 |
| Inline suggestions | 対象外 | GitHubサインインが必要 |
| Next edit suggestions | 対象外 | GitHubサインインが必要 |
直接providerへ送るという意味
VS Code 1.122の説明では、BYOKのリクエストはproviderへ直接送られるとされています。これは、GitHub側のモデルルーティングを使わず、自分たちのprovider、API key、ネットワーク経路、請求を使うという意味に近いです。
便利になる一方で、確認先は増えます。API keyを誰が保管するのか、providerのログに何が残るのか、社内コードやプロンプトがどこへ送られるのか、MCP serverがどの情報にアクセスするのか。このあたりは、GitHub Copilot SDKが一般提供した記事で扱ったMCPやBYOKの確認点ともつながります。
ローカルモデルでも免責にはならない
Ollamaなどのローカルモデルを使えば、外部providerへの送信を減らせる可能性があります。それでも、ローカルだから何でも安全とは言えません。MCP serverがファイルや社内APIへ接続するなら、その権限は別問題です。ターミナルツールを許可するなら、コマンド実行権限も別問題として残ります。
BYOKのサインイン不要化は、選択肢を広げる更新です。セキュリティレビューを不要にする更新ではありません。
Custom Endpointとutility modelsは費用と品質の調整弁になる
高性能な主モデルだけを選んでも、utility modelsが未設定なら補助機能の体験が落ちる可能性があります。
BYOKの話を導入判断に落とすなら、Custom Endpointとutility modelsを外せません。VS Code 1.121ではCustom Endpoint provider for BYOKがInsidersのpreviewとして説明され、VS Code 1.122ではCustom Endpoint providerがVS Code Stableで利用できるようになったと説明されています。
Custom Endpoint providerは、Chat Completions、Responses、Messages互換のendpointを接続できるものです。自社ホストのモデル、enterprise向けendpoint、互換APIを持つproviderを、ひとつのprovider flowで扱いやすくする方向の更新です。
Custom Endpointはモデル選択肢の入口
Custom Endpointが意味を持つのは、標準providerに名前があるモデルだけを使うのではなく、自社のAI基盤や互換APIをVS Code Chatへつなぎたい場合です。開発者個人にとっては選択肢の拡大ですが、企業にとってはモデル接続経路を標準化する入口にもなります。
ただし、接続できることと、社内標準として使えることは別です。Responses API互換なのか、Messages API互換なのか、認証はどうするのか、モデルごとのcontext windowと費用をどう見るのかは、providerごとに確認が必要です。
utility modelsを軽く見ない
VS Code 1.121のリリースノートでは、chat.utilityModel と chat.utilitySmallModel が説明されています。これらは、チャットタイトル、サマリー、commit message、rename suggestion、prompt categorization、intent detectionなど、背景で動く軽量タスクに使われるモデルです。
VS Code 1.122では、BYOKを使いながらGitHubからサインアウトしている場合、通常のCopilot subscription側のdefault utility modelsに届かないため、BYOKモデルをutility modelsへ指定する通知が出ると説明されています。指定しない場合、utility-driven featuresはinactiveのままになります。
これは細かい設定ではありません。主モデルだけ高性能にしても、utility modelsが未設定なら、タイトル生成やcommit messageなどの補助体験が落ちる可能性があります。逆に、utility taskへ安価で速いモデルを割り当てられれば、応答品質と費用の調整余地が出ます。
token visibilityとreasoning effort
評価基準
VS Code 1.120では、BYOKモデルのtoken使用量がChat viewのcontext window controlに反映されるようになったと説明されています。GitHub Changelogでも、BYOK token visibilityが5月更新の要点として挙げられています。
同じくVS Code 1.120では、BYOKのreasoning-capable modelsについて、model pickerからthinking effortを設定できる更新も示されています。品質、速度、費用のどれを優先するかを、モデル選択だけでなく推論努力の設定でも調整する考え方です。
導入企業が見るべき評価軸は、次のように整理できます。
| 領域 | 確認すること | 判断材料 |
|---|---|---|
| 主モデル | 生成品質、対応API、context window | 実装タスクの成功率、応答時間 |
| utility models | title、summary、commit messageなど | 軽量タスクの速度と費用 |
| BYOK token visibility | token使用量の見え方 | 費用見積もり、会話の長さ |
| reasoning effort | 品質、遅延、provider請求 | 高難度タスクだけ上げる運用 |
| Custom Endpoint | API互換性、認証、ログ | 社内標準化、監査可能性 |
ターミナル安全機能は出力、リスク、秘密入力を分けて見る
terminal tool output compressionは、長いdiffやtest、install、lintの出力をモデルへ渡す前に圧縮します。
command risk assessmentはexperimentalです。ファイル変更、package install、ネットワークアクセスを止める判断と一緒に見ます。
secret prompt protectionは、passwordやPINなどの入力をエージェントへ不用意に渡さないための確認点です。
背景コマンドの見え方やVSCODE_AGENT環境変数は、長時間実行と監査の扱いに関わります。
圧縮ログだけでは失敗原因の細部が見えない場合があるため、raw outputを確認する手順も残しておく必要があります。
5月更新で見落としたくないのが、ターミナルまわりです。GitHub Changelogでは、terminal safety and efficiencyとして、出力圧縮、command risk assessment、secret prompt protection、背景コマンドの見え方、VSCODE_AGENT 環境変数が整理されています。
エージェントがコードを読むだけなら、主なリスクは誤回答や不適切な差分です。しかし、ターミナルコマンドを扱うようになると、ファイル変更、package install、ネットワークアクセス、認証情報、長時間実行が入ります。ここは機能紹介ではなく、権限設計として読む方がよいです。
出力圧縮はtoken節約だけではない
VS Code 1.120では、chat.tools.compressOutput.enabled によるterminal tool output compressionがpreviewとして説明されています。長いgit diff、ls -l、npm installなどの出力を、モデルへ渡す前に圧縮する機能です。
VS Code 1.121では、対象が広がり、pytest、jest、cargo test、tsc、linters、Docker、package managersなどの冗長な出力も圧縮される方向が示されています。これはtoken節約だけでなく、モデルが重要な失敗箇所を見つけやすくする狙いがあります。
一方で、圧縮は万能ではありません。失敗原因の細部を見たいとき、圧縮されたログだけでは不足する可能性があります。調査時にraw outputをどう確認するか、チームのデバッグ手順に残しておくべきです。
Risk assessmentは人間の確認を置き換えない
注意点
VS Code 1.120では、terminal command confirmationsにAI-generated risk levelsと短い説明を出すrisk assessmentがexperimentalとして説明されています。設定名はchat.tools.riskAssessment.enabledです。
公式ノートでは、Safe、Caution、Review carefullyのような段階で、コマンドが何をするかを短く示す例が説明されています。読み手にとっては助かる機能ですが、ここで判断をAIに丸投げしないことが重要です。force push、外部送信、workspace外の削除、本番環境への接続は、組織の承認フローで止められるようにしておく必要があります。
秘密入力はchat contextへ入れない
VS Code 1.121では、password、passphrase、PIN、verification codeなどのsensitive promptsがterminal側に残る設計が説明されています。default permissions modeでは、chatが確認ダイアログを出してterminalで直接入力するよう促し、auto-approve flowではコマンドをキャンセルして、モデルに再試行や秘密情報の要求をさせないとされています。
この更新は、エージェントがうっかり秘密情報を会話文脈に取り込むリスクを下げます。ただし、コマンドがどの環境へ接続するか、ログに何が残るか、providerへ何が送られるかは別に確認する必要があります。
CLIsはVSCODE_AGENTを見られる
VS Code 1.121では、エージェント起動のterminal commandにVSCODE_AGENT環境変数が設定されることも説明されています。CLI側はこの値を見て、進捗アニメーションを抑える、機械可読な出力へ切り替える、対話プロンプトを避けるといった対応ができます。
社内CLIを持つ企業にとっては、これは小さくない更新です。エージェントに実行される前提の出力モードを用意すれば、不要なログ量を減らし、ブロックする対話を避け、レビューしやすい実行結果を返せます。
企業導入では設定と組織ポリシーを先に読む
便利な機能追加として読むだけでなく、どのモデルが何を読み、どのツールが何を実行できるかを先に決めます。
VS CodeのCopilot更新は、個人開発者には便利な機能追加に見えます。しかし、企業導入では、BYOK、MCP、terminal tools、remote agents、observabilityが同時に近づいていることを見なければなりません。モデル、ツール、シェル、リモート環境がつながるほど、最初に決めるべき境界が増えます。
この文脈では、GitHub Copilot in VS Code settings referenceが重要です。設定リファレンスには、agent設定、MCP access、terminal output compression、risk assessment、OpenTelemetry関連設定などが並びます。全部を暗記する必要はありませんが、導入前にどの領域を管理対象にするかは決めておくべきです。
MCPとterminal commandは境界をまたぐ
BYOKで独自モデルを使い、MCP serverで社内ツールへ接続し、terminal toolsでコマンドを実行し、remote agentsでリモートマシン上の作業を続ける。この組み合わせは強力です。同時に、どのモデルが何を読み、どのツールがどこへ接続し、どのコマンドが何を変更できるかを分けて管理する必要があります。
GitHub CopilotのEnterprise-managed pluginsがVS Codeでpublic previewした流れを追っている読者なら、MCPやpluginsを個人任せにしない動きが強まっていることも見えているはずです。VS Code側の5月更新も、その企業管理の文脈で読むと位置づけがはっきりします。
observabilityは便利だが中身を見る
VS Code 1.121では、agent observability with OpenTelemetry and Grafanaが説明されています。Copilot Chat agent interactionsのOpenTelemetry emissionを有効にし、Azure Managed Grafanaなどでagent operations、token usage、chat sessions、tool calls、モデルごとの応答時間を可視化する流れです。
設定リファレンスでは、github.copilot.chat.otel.captureContentがfull prompt and response contentをOTel spansに含める設定として説明され、sensitive informationを含む可能性があると明記されています。観測できることは強みですが、何を保存し、誰が見られるのかを決めないまま有効化するのは危険です。
企業向けチェックリスト
確認項目
| 領域 | 確認する機能/設定 | 担当 | 本番前に決めること |
|---|---|---|---|
| Agents | chat.agent.enabled、Agents window | 開発基盤 | preview機能の利用範囲 |
| Remote agents | SSH、Dev Tunnels、agent host | 情シス/開発基盤 | 接続先、権限、終了条件 |
| BYOK | provider、API key、Custom Endpoint | セキュリティ/開発基盤 | 送信先、請求、ログ |
| MCP | chat.mcp.access、server許可 | 情シス/各プロダクト | 接続先とツール権限 |
| Terminal | output compression、risk assessment | 開発基盤 | auto-approveと禁止コマンド |
| Observability | OpenTelemetry、captureContent | SRE/セキュリティ | 保存先、閲覧者、機密情報 |
ここを先に決めてから試すと、Copilotを止めるか使うかの二択ではなく、「どの範囲なら安全に試せるか」という現実的な導入判断になります。
開発者は小さく試して、企業は先に境界を決める
- 1個人: Agents windowから試す
VS Code StableでAgents window previewを開き、短い修正タスクを分けて実行します。
- 2個人: BYOKの範囲を見る
モデルを1つ設定し、Chat、tools、MCP serversの範囲と補完系のサインイン要件を確認します。
- 3個人: terminal safetyを試す
output compression、risk assessment、secret prompt protectionを検証用コマンドで確認します。
- 4企業: BYOKとMCPを承認する
許可するprovider、API key、Custom Endpoint、MCP server登録者を先に決めます。
- 5企業: terminal toolsとremote agentsを見る
ファイル変更、外部アクセス、リモートセッション、長時間コマンドの運用条件を確認します。
- 6本番前に止める条件
差分を追えない、ログを説明できない、秘密入力を守れない、provider送信範囲を説明できない場合は本番利用を止めます。
AIが賢く答えたかよりも、差分、ログ、危険なコマンド、providerへ送る範囲を説明できるかが成功条件です。
今回の5月更新は、ひとつの派手な製品発表というより、VS CodeのCopilotをエージェント運用基盤へ寄せる細かな更新の集合です。読む順番を間違えると、機能が多く見えるだけで、何を試すべきか分からなくなります。
個人や小規模チームなら、まずAgents windowで短めの修正タスクを試し、次にBYOKで自分のモデル接続を確認し、最後にterminal output compressionやrisk assessmentの表示を見ます。いきなりremote agentsやMCP serverを本命環境へつなぐより、検証用リポジトリで差分、ログ、秘密入力の扱いを見る方が堅実です。
個人で試す順番
- VS Code StableでAgents window previewを開き、短い修正タスクを分けて実行する
- Chat viewとAgents windowで、レビューしやすさがどう違うかを見る
- BYOKモデルを1つ設定し、Chat、tools、MCP serversの範囲を確認する
- inline suggestionsとnext edit suggestionsはサインイン要件が別であることを確認する
- terminal output compressionやrisk assessmentを、検証用コマンドで試す
- passwordやPINを求めるコマンドで、secret promptの扱いを確認する
ここで見るべき成功条件は、AIが「賢く答えた」ことだけではありません。差分を追えること、ログを見直せること、危険なコマンドを止められること、providerへ送る範囲を説明できることです。
企業で承認する順番
企業なら、最初にBYOKとMCPの境界を決める方が先です。どのproviderを許可するか、Custom Endpointを社内標準にするか、API keyをどこへ保存するか、MCP serverを誰が登録できるかを決めます。
その後でterminal toolsとremote agentsを見ます。terminalはファイル変更や外部通信を伴い、remote agentsは切断後もリモートで作業が残る可能性があります。ここは開発者の生産性だけでなく、監査、ログ、停止条件、コストの問題です。
上振れは明確です。長時間の修正、複数セッション管理、独自モデル接続、token使用量の可視化、ターミナル出力の整理によって、開発者の作業はかなり回りやすくなります。下振れもあります。preview機能の仕様変更、provider費用の読み違い、utility models未設定、terminal権限の過信、observabilityでの機密情報保存です。
今回の結論
評価基準
VS CodeのGitHub Copilot 5月更新は、Copilotをただの補完・チャット機能として見ている読者ほど確認する価値があります。Agents window、remote agents、BYOK、Custom Endpoint、utility models、terminal safetyは別々の機能ですが、全体としては「エージェントに任せる作業をどう見える化し、どう制御するか」に向かっています。
本番利用を急ぐ必要はありません。previewとexperimentalを落とさず、BYOKの対象範囲を限定して理解し、ターミナルとMCPの権限境界を先に決める。それが、今回の更新を安全に試すための現実的な読み方です。
Microsoft Watch JapanはMicrosoftおよび関係会社とは非提携の独立サイトです。製品名、サービス名、商標は各社に帰属します。VS Code、GitHub Copilot、BYOK、MCP、Agents windowの仕様や提供状態は変わる可能性があるため、導入前に必ず公式ドキュメントと管理者向け設定を確認してください。
次に読むなら
参照した主な情報源
- GitHub Changelog, "GitHub Copilot in Visual Studio Code, May releases"（確認日: 2026年6月8日）: https://github.blog/changelog/2026-06-03-github-copilot-in-visual-studio-code-may-releases/
- Visual Studio Code 1.120 release notes（確認日: 2026年6月8日）: https://code.visualstudio.com/updates/v1_120
- Visual Studio Code 1.121 release notes（確認日: 2026年6月8日）: https://code.visualstudio.com/updates/v1_121
- Visual Studio Code 1.122 release notes（確認日: 2026年6月8日）: https://code.visualstudio.com/updates/v1_122
- Visual Studio Code 1.123 release notes（確認日: 2026年6月8日）: https://code.visualstudio.com/updates/v1_123
- GitHub Copilot in VS Code settings reference（確認日: 2026年6月8日）: https://code.visualstudio.com/docs/copilot/reference/copilot-settings
更新履歴
previewやexperimentalの表記、BYOKの対象範囲、Custom Endpoint providerの提供状態が変わる可能性があります。
| 日付 | 確認内容 | 更新理由 |
|---|---|---|
| 2026年6月8日 | GitHub Changelog、VS Code 1.120、1.121、1.122、1.123、Copilot settings referenceを確認 | 初回公開 |
今後、Agents windowやremote agentsのpreview表記、risk assessmentのexperimental表記、BYOKの対象範囲、Custom Endpoint providerの提供状態、utility modelsやterminal safety関連設定が変わった場合は更新します。