GitHub が 2026年4月8日に公開した VS Code 向け GitHub Copilot の 3月リリースウェーブで、まず押さえるべき結論はひとつです。今回の更新は、Copilot を「コード補完が少し賢いツール」から、「自律的に動き、ブラウザや検索やデバッグまで横断して進めるエージェント」へ近づける内容でした。特に実務で効くのは、Autopilot による自律実行、統合ブラウザでのデバッグ、チャットカスタマイズの一元管理、#codebase の整理、/troubleshoot の強化です。(The GitHub Blog)
「何が変わったのかは分かったが、結局どれから試すべきか分からない」という人は、まず #codebase、チャットカスタマイズ、統合ブラウザ、/troubleshoot の順で触るのがおすすめです。Autopilot は便利ですが、承認を飛ばす性質上、最後に小さなブランチで試すほうが安全です。(The GitHub Blog)
GitHub Copilot の VS Code 3月リリースウェーブで押さえるべき変化
今回の changelog は、週次 stable リリースへ移行した VS Code の v1.111 から v1.115 を対象にしたもので、期間で言えば 2026年3月9日公開の 1.111 から、2026年4月8日公開の 1.115 までをまとめています。つまり「3月リリースウェーブ」という名前でも、実際には 4月初旬の改善まで含まれます。(The GitHub Blog)
今回の変化を実務目線で縮めると、次の5点です。
- Autopilot と権限レベルの導入で、Copilot の自律度をセッション単位で変えられるようになった。ローカルだけでなく Copilot CLI セッションにも広がっています。(The GitHub Blog)
- 統合ブラウザの強化で、VS Code を離れずに Web アプリを開き、ブレークポイントや変数確認まで進めやすくなった。画像や動画もチャット文脈に乗せやすくなっています。(The GitHub Blog)
- チャットカスタマイズの一元管理で、指示・エージェント・スキル・プラグインを一か所で扱えるようになり、モノレポ運用とも相性が良くなった。(The GitHub Blog)
#codebaseの整理と Thinking Effortにより、コードベース理解の精度と再現性を上げやすくなった。(The GitHub Blog)/troubleshootの強化で、「なぜその挙動になったのか」を過去セッションも含めて追いやすくなった。(The GitHub Blog)
この並びを見ると分かる通り、今回の本質は単純な生成精度アップではありません。自律実行を強めつつ、同時に制御・共有・原因調査も強めたことに価値があります。Copilot を本気で日常開発に組み込むなら、このバランスはかなり大きいです。(The GitHub Blog)
Autopilot と権限レベルは「便利」より先に「運用設計」が先
1.111 では Chat view に権限ピッカーが入り、Default Approvals、Bypass Approvals、Autopilot をセッション単位で切り替えられるようになりました。Autopilot は、ツール呼び出しを自動承認し、エラー時に自動再試行し、必要な質問にも自動応答しながら、タスク完了まで自律的に進みます。Stable で試す場合は chat.autopilot.enabled を有効にします。1.112 では同じ考え方が Copilot CLI セッションにも広がりました。(The GitHub Blog)
実務で相性がいいのは、たとえば次のような作業です。Lint 修正の一括適用、テスト失敗の機械的な修正、命名統一、複数ファイルにまたがる軽いリファクタリング、テンプレート生成のように「やることは多いが判断は重くない」作業です。逆に、DB スキーマ変更、デプロイスクリプト変更、権限まわりの修正、知らないリポジトリへの初回適用は慎重に扱うべきです。
最初の使い分けは、こう考えると失敗しにくいです。
Default Approvalsは普段使いの標準Bypass Approvalsは差分が小さく戻しやすい作業Autopilotは検証用ブランチで、反復作業が多いタスクから試す
注意したいのは、Bypass Approvals と Autopilot は手動承認を飛ばし、設定済みの approval ルールも無視し得ることです。1.111 の release notes では、ファイル編集、ターミナルコマンド、外部ツール呼び出しのような破壊的な操作も対象になりうると明記されています。設定リファレンスでも、全体 auto-approve は重要な保護を無効化するとされています。便利さだけ見て main ブランチでいきなり使うのは避けたほうがいいでしょう。(Visual Studio Code)
CLI 派にとっては、今回の波でローカルセッションとの差も縮まりました。Copilot CLI ではメッセージの steering / queueing が入り、セッション fork や debug logs も強化されています。ターミナル中心の作業でも、VS Code 内のエージェント体験に寄せやすくなっています。(Visual Studio Code)
統合ブラウザと画像・動画対応で、フロントエンドの再現調査が速くなる
フロントエンド開発者にとって、今回いちばん体感差が大きいのは統合ブラウザです。1.112 で、VS Code 内の integrated browser を使ったデバッグが可能になり、Web アプリを開いたままブレークポイントを置き、ステップ実行し、変数を確認できるようになりました。新しい editor-browser debug type は、既存の chrome や msedge 設定の多くを流用しやすい設計です。(The GitHub Blog)
さらに 3月リリースウェーブでは、スクリーンショットや動画をチャットに添付し、エージェントが返した画像や録画をカルーセルで確認できるようになりました。1.114 では動画プレビューにも対応し、1.115 ではブラウザツールのラベル改善、長時間スクリプト対応、重複タブ抑制なども入り、実用性がかなり上がっています。GitHub changelog でも、統合ブラウザデバッグと画像・動画対応は今回の主要ハイライトとして挙げられています。(The GitHub Blog)
この変化が効くのは、たとえば「ログイン後だけ崩れる UI」「特定操作でしか出ない JavaScript エラー」「再現動画がないと伝わりにくい操作バグ」のような場面です。従来は、ブラウザ、DevTools、エディタ、チャットの間を行き来していました。今は、VS Code の中で再現し、必要なら画面の文脈まで Copilot に渡せます。“コードだけでなく、画面状態も文脈にできる”のが大きいです。(Visual Studio Code)
実際に試すなら、次の流れが分かりやすいです。
- 既存のブラウザ用
launch.jsonを見直し、typeをeditor-browserベースで検討する - ローカルのフロントエンドを統合ブラウザで開き、再現時点でブレークポイントを確認する
- スクリーンショットや動画をチャットに渡し、「この状態になる原因候補を 3つ」と聞く
- 返答を issue や PR に貼る時は、後述の
Copy Final Responseを使う
なお、画像カルーセルは current docs では imageCarousel.chat.enabled の Experimental 設定として案内されています。記事執筆時点では、今すぐ本番運用に固定化するより、まず検証チームやフロントエンド班から試すのが現実的です。(Visual Studio Code)
チャットカスタマイズの一元管理で、個人設定からチーム運用へ進んだ
1.113 の Chat Customizations editor は、今回の中でも見落とされやすい一方で、継続運用にはかなり重要です。カスタム指示、prompt files、custom agents、agent skills などをタブで整理し、埋め込みエディタで編集でき、MCP サーバーやプラグインの marketplace もそこからたどれます。開く導線も分かりやすく、Chat view の歯車か Chat: Open Chat Customizations から入れます。(The GitHub Blog)
ここが本当に便利なのは、「個人の隠し設定」ではなく「チームの再利用資産」として Copilot を扱いやすくなった点です。1.112 では、chat.useCustomizationsInParentRepositories により、モノレポでサブフォルダだけを開いていても親リポジトリ側のカスタマイズを見つけやすくなりました。current settings reference でも、この設定は instructions、prompts、agents、skills、hooks の親リポジトリ探索用として案内されています。(Visual Studio Code)
たとえば、モノレポなら次のような置き方が分かりやすいです。
repo/
.git/
.github/
copilot-instructions.md
prompts/
agents/
skills/
.vscode/
mcp.json
apps/
web/
packages/
ui/この形なら、apps/web だけを開いて作業するメンバーでも、親リポジトリ探索を有効にすれば、ルート側の指示やエージェントを共有しやすくなります。レビュー方針、命名規約、テスト観点、PR 説明の書き方まで共通化しやすくなるので、個人差が減ります。(Visual Studio Code)
さらに 1.113 では、VS Code で設定した MCP servers が Copilot CLI や Claude agent sessions でも使えるようになりました。加えて 1.112 では、プラグインや MCP servers をアンインストールせずに有効・無効へ切り替えられるようになっています。つまり、ローカルエージェント、CLI、共有設定を別々に育てるのではなく、同じ部品で揃えやすくなったわけです。(The GitHub Blog)
注意点もあります。親リポジトリ探索は無条件ではなく、開いているワークスペース自体が Git リポジトリではないこと、親フォルダに .git があること、親リポジトリが trusted workspace であることが条件です。また、subagents の多段呼び出しは 1.113 で可能になりましたが、もともと無限再帰を避けるために制限されていた機能です。必要なワークフローだけで有効にするのが無難です。 agent-scoped hooks も便利ですが Preview なので、まずは少数のカスタムエージェントから始めるほうが混乱しません。(Visual Studio Code)
#codebase と Thinking Effort で、コード理解の質を上げやすい
1.114 の #codebase 見直しは、地味に見えてかなり重要です。これまでの local / remote index の考え方が整理され、#codebase は常に semantic search に専念する形になりました。インデックスは単一の自動管理に寄り、Copilot が必要に応じて自動で使います。以前 indexed と表示されていたワークスペースでも、旧来の非 semantic index を使っていた場合は再インデックスが必要です。特に巨大なコードベースで GitHub リポジトリを持たないものは、まだインデックス対象外のケースがあるとも案内されています。(The GitHub Blog)
この変更で得られるのは、検索の速さだけではありません。「名前が一致する場所を探す」より、「意味的に関係する実装を探す」ほうへ質問の質を寄せやすくなったことです。たとえば、次のような聞き方がしやすくなります。
#codebase 認可チェックが実行される流れを入口から整理して#codebase PaymentService に影響するイベント発火箇所を候補つきで出して#codebase この例外が発生しそうな経路を実装ベースで洗い出して
1.113 の Thinking Effort も、この流れと相性がいい改善です。Claude Sonnet 4.6 や GPT-5.4 のような reasoning model では、model picker から推論の深さを選べるようになり、選択内容は会話をまたいで保持されます。非 reasoning model ではこの項目は出ませんし、選べるレベルはモデルごとに異なります。ざっくり言えば、Low は素早い相談、Medium は普段の設計補助、High は原因切り分けや複雑なコード読解という使い分けが実務向きです。(The GitHub Blog)
ここに小さな改善を重ねると、さらに使いやすくなります。1.112 では、クラス名や関数名などのシンボルをチャットに貼ると #sym:Name 形式の参照へ自動変換されるようになりました。1.114 では Copy Final Response が追加され、thinking steps や tool calls を除いた最終 Markdown だけをコピーできます。PR 説明、issue コメント、調査メモへの転記がかなり楽になります。(The GitHub Blog)
/troubleshoot で「なぜ効かないか」を調べやすくなった
Copilot を本格運用すると、いずれ必ず「カスタム指示が効いていない気がする」「やたら遅い」「変なサブエージェントを呼んだ」といった不満が出ます。1.112 で導入された /troubleshoot は、その原因を debug logs から会話形式で掘れるようにした機能です。1.114 では過去セッションも #session で参照できるようになり、再現し直さなくても振り返りやすくなりました。(Visual Studio Code)
current settings reference では、github.copilot.chat.agentDebugLog.enabled が agent debug logs と /troubleshoot を有効にする設定、github.copilot.chat.agentDebugLog.fileLogging.enabled が JSONL への file logging を有効にする設定として案内されています。つまり、後から困って慌てるより、先にログを取れる状態にしておくほうが運用しやすいです。(Visual Studio Code)
試し方はシンプルです。
github.copilot.chat.agentDebugLog.enabledを有効にするgithub.copilot.chat.agentDebugLog.fileLogging.enabledを有効にする- VS Code を再読み込みする
- 問題のあった会話を開く
/troubleshoot #session カスタム指示が無視された理由を教えてのように聞く
この機能の価値は、単に「バグを直す」ことではありません。チーム内で「Copilot が変だった」で終わっていた会話を、「どの指示が読まれず、どのツールが呼ばれず、どこで遅くなったのか」に変えられることです。自律度が上がるほど、診断のしやすさは重要になります。(Visual Studio Code)
つまずきやすいポイントと対処
| 症状 | よくある原因 | 対処 |
|---|---|---|
Autopilot が怖くて使えない | Bypass Approvals や Autopilot は承認を飛ばし、破壊的な操作も自動承認し得る | まずは検証ブランチで、戻しやすいタスクだけに使う。Default Approvals を標準にし、段階的に上げる。(Visual Studio Code) |
#codebase の結果が不安定、または期待より弱い | 旧インデックスの再構築が必要、または巨大な非 GitHub コードベースでまだインデックス対象外 | 一度再インデックスし、難しい場合は text / grep / symbols も併用する。(Visual Studio Code) |
| モノレポの共通指示が読まれない | 親リポジトリ探索の条件を満たしていない、または workspace trust が不足している | chat.useCustomizationsInParentRepositories を有効にし、親に .git があるか、trust 済みかを確認する。(Visual Studio Code) |
| Windows で MCP sandbox が使えない | 1.112 時点でローカル MCP sandbox は macOS / Linux 向け | Windows は前提にせず、必要なら WSL / SSH などの remote も含めて検討する。(Visual Studio Code) |
/troubleshoot が有効に働かない | debug log 設定がオフのまま | github.copilot.chat.agentDebugLog.enabled と github.copilot.chat.agentDebugLog.fileLogging.enabled を先に有効化する。(Visual Studio Code) |
まずはこの順番で試すと失敗しにくい
- VS Code と Copilot Chat を最新状態にする
GitHub Docs では、Copilot Chat の変更は VS Code リリースに密接に結びついており、古い VS Code では最新の Copilot Chat が使えないと案内されています。まずはCheck for Updatesで最新安定版を確認するのが出発点です。(GitHub Docs) - Chat Customizations を開き、共通指示を 1つだけ作る
最初から agents や hooks を盛り込みすぎず、まずは.github/copilot-instructions.md相当の共通ルールを整理するだけで十分です。歯車から入れる一元 UI があるので、散らかった設定を減らせます。(Visual Studio Code) - 実リポジトリで
#codebaseを 2〜3 回試す
「この機能の入口はどこか」「この変更の影響範囲はどこか」といった質問から始めると、semantic search の違いが分かりやすいです。(Visual Studio Code) - フロントエンド案件なら統合ブラウザを先に触る
editor-browserを使ったデバッグと、画像・動画の文脈投入は体感差が大きい部分です。CSS 崩れやクリック導線の不具合を Copilot に説明しやすくなります。(Visual Studio Code) /troubleshoot用のログ設定を先回りで有効にする
問題が起きてから設定するより、先にログを取れるようにしておくほうがチーム運用では楽です。(Visual Studio Code)- 最後に
Autopilotを小さなブランチで試す
いきなり本流に入れず、lint 修正やテスト修正のような戻しやすいタスクで挙動を見るのが安全です。(Visual Studio Code)
今回の GitHub Copilot の VS Code 3月リリースウェーブは、単なる新機能追加というより、自律実行・画面理解・検索・共有・原因調査をひとつの流れにまとめ始めた更新でした。すぐに効くのは、チャットカスタマイズ、#codebase、統合ブラウザ、/troubleshoot です。Autopilot はそのあとで十分です。読んだあとにやるべきことは明確で、まず最新化し、共通指示を整え、検索と調査の基盤を固め、それから自動化を強める。この順番なら、便利さだけを追って運用が崩れる失敗をかなり避けられます。(The GitHub Blog)
コメント