GitHub Copilot in Visual StudioのMay updateでは、コードを書き始める前の計画、複数ファイル変更のレビュー、チャットのコンテキスト管理、Git連携、C++ビルド最適化が強化されました。特に重要なのは、Copilotにいきなり実装させるのではなく、Plan agentで計画を作り、差分をまとめて確認し、必要な指示をリポジトリ側に集約する流れへ近づいた点です。
Visual Studio 2026でGitHub Copilotを使っている開発者は、Plan agent、Multi-file summary diff、Context window indicatorをまず試す価値があります。管理者やリードエンジニアは、コミットメッセージ指示の移行、Agent Skillsの管理、C++向けCopilot機能の展開範囲を確認しておくべきです。GitHub Changelogでは2026年6月4日付の更新として掲載され、Visual Studio May Updateの内容としてMicrosoft公式ブログやリリースノートでも関連機能が説明されています。(The GitHub Blog)
GitHub Copilot in Visual StudioのMay updateで何が変わったのか
今回のGitHub Copilot in Visual Studio May updateは、単なる補完精度の改善ではありません。開発作業の流れそのものを、次のように整理しやすくするアップデートです。
| 変更点 | 主な効果 | 特に関係する人 |
|---|---|---|
| Plan agent / Planning mode | 実装前に計画を作り、合意してからAgent modeへ渡せる | 開発者、テックリード |
| Agent Skills管理パネル | ワークスペースや個人プロファイルのスキルを見つけやすくする | 開発者、管理者 |
| Multi-file summary diff | Copilotが複数ファイルを編集した後のレビューを一画面で行える | レビュアー、開発者 |
| Context window indicator | Copilot Chatがどれだけ文脈を使っているか見える | 長いチャットを使う開発者 |
| Add commit to Copilot Chat | Git履歴のコミットをCopilot Chatの文脈として渡せる | Git運用する開発者 |
| Commit message instructions moved | コミットメッセージ生成ルールをリポジトリのCopilot instructionsへ集約 | 管理者、チームリード |
| C++ビルド最適化の改善 | フルリビルドだけでなく、実務に近いインクリメンタルビルドの効果を見やすくする | C++開発チーム |
Visual Studio 2026 May update全体では、AI統合、基盤強化、パフォーマンス改善が柱とされており、今回のCopilot関連機能も「生成する」だけでなく「計画し、確認し、運用する」方向に寄っています。(Microsoft Learn)
Plan agentで「実装前のすり合わせ」がしやすくなる
今回もっとも注目したいのが、Plan agentです。従来のAgent modeでは、依頼内容によってはCopilotがすぐに複数ファイルを編集し始め、後から「その設計ではない」「触ってほしくないファイルまで変更された」と気づくことがありました。
Plan agentは、この問題を減らすための機能です。Copilot Chatのエージェント選択でPlanを選ぶと、Copilotはコードベースを読み取り専用ツールで確認し、不明点があれば質問し、実装計画をMarkdownファイルとして作成します。計画は.copilot/plans/plan-{title}.mdに保存され、納得できたら「Implement plan」でAgent modeに引き継げます。(The GitHub Blog)
Plan agentが向いている作業
Plan agentは、すべての小さな修正に使う必要はありません。効果が大きいのは、次のような作業です。
| 作業内容 | Plan agentを使う理由 |
|---|---|
| 認証機能の追加 | 影響範囲がルーティング、UI、DB、設定ファイルに広がりやすい |
| レガシーコードのリファクタリング | 変更方針を先に決めないと、意図しない構造変更が起きやすい |
| 支払い、権限、監査ログなどの重要機能 | 実装前に例外処理やテスト観点を確認したい |
| 初めて触るコードベースの改修 | Copilotに探索させたうえで、変更候補を整理できる |
| チームで合意が必要な変更 | Markdownの計画ファイルをレビュー対象にできる |
たとえば「ユーザー削除機能を追加して」と頼むより、Plan agentに次のように依頼すると、実装前の認識ズレを減らせます。
ユーザー削除機能を追加したいです。
物理削除ではなく論理削除にしたいです。
管理者のみ実行可能にし、既存の監査ログにも記録してください。
まず実装計画を作り、影響するファイル、必要なテスト、注意点を整理してください。計画が出たら、そのまま実装させるのではなく、次の観点で確認します。
| 確認観点 | 見るポイント |
|---|---|
| 変更対象ファイル | 不要なファイルや責務外の層を触ろうとしていないか |
| データ設計 | 既存の命名規則、マイグレーション方針に沿っているか |
| エラー処理 | 権限不足、対象なし、重複実行などを考慮しているか |
| テスト | 正常系だけでなく、権限・境界値・失敗系が含まれているか |
| ロールバック | 途中で失敗した場合の戻し方が想定されているか |
Plan agentの価値は、Copilotに「完璧な設計」を任せることではありません。人間が判断すべき設計の論点を、実装前に見える形へ引き出すことです。
Multi-file summary diffでCopilotの変更レビューが現実的になる
Copilotに複数ファイルを編集させると、レビューが難しくなります。ファイルを1つずつ開いて差分を追うと、全体像を見失いやすく、変更の一部だけを見て承認してしまうこともあります。
May updateでは、Copilotが複数ファイルを編集した後、Copilot Chatのworking setから「Open change summary view」を開くことで、複数ファイルの差分を1つのタブで確認できます。変更は全ファイル単位、ファイル単位、差分チャンク単位で受け入れまたは取り消しできます。(The GitHub Blog)
レビュー時に見るべきポイント
Multi-file summary diffを使うときは、単に「ビルドが通るか」だけで判断しないほうが安全です。特にCopilotが生成した変更では、次の観点を確認します。
| 確認項目 | ありがちな失敗 | 対応 |
|---|---|---|
| 変更範囲 | 依頼していないファイルまで変更される | まずファイル一覧を折りたたみ、対象外がないか確認 |
| 命名・責務 | 既存の設計規約から外れる | 既存コードと同じ層、同じ命名規則か確認 |
| 例外処理 | エラー時の戻り値やログが雑になる | 既存のエラーハンドリングと比較 |
| テスト | 通りやすいテストだけ追加される | 失敗系、境界値、既存テストへの影響を確認 |
| セキュリティ | 入力検証や権限チェックが抜ける | 認可、サニタイズ、機密情報ログ出力を重点確認 |
実務では、Copilotに大きな変更を任せるほど、レビューの粒度が重要になります。Multi-file summary diffは「AIが作った差分を丸ごと受け入れる機能」ではなく、AIの変更を人間が判断しやすくするためのレビュー補助機能として使うのが安全です。
Context window indicatorで長いチャットの精度低下に気づきやすくなる
Copilot Chatは、会話履歴、添付ファイル、IDEの状態などを文脈として使います。ただし、文脈として扱える量には上限があります。会話が長くなると、最初に伝えた条件や背景が効きにくくなることがあります。
May updateでは、Copilot Chatの入力欄右上にリングアイコンが表示され、コンテキストウィンドウの使用量を確認できるようになりました。クリックすると、使用率や内訳を確認でき、必要に応じて「Summarize conversation」で過去の会話を圧縮できます。(The GitHub Blog)
使いどころの判断基準
次のような状態になったら、コンテキスト使用量を確認するタイミングです。
| 状況 | 起きやすい問題 | 対応 |
|---|---|---|
| 同じチャットで長時間作業している | 前提条件を忘れたような回答になる | 使用量を確認し、会話を要約 |
| 大きなファイルを複数添付している | 回答が遅い、焦点がぼやける | 必要なファイルだけに絞る |
| 途中で方針を何度も変えた | 古い方針と新しい方針が混ざる | 最新方針を明示し、必要なら新しいチャットにする |
| 複数タスクを1つの会話で扱っている | 別タスクの文脈が混入する | タスクごとに会話を分ける |
「Copilotの回答が急に浅くなった」と感じたとき、モデルの性能だけを疑うのは早計です。文脈が増えすぎている、古い条件が残っている、不要なファイルを渡しているといった運用面の問題もよくあります。
Agent Skills管理でチーム標準の作業手順を扱いやすくなる
Agent Skillsは、Copilot Agentに特定タスクの進め方を教えるための再利用可能な指示セットです。Visual Studioでは、ワークスペースやユーザープロファイルから見つかったAgent Skillsを、チャット画面のSkillsパネルで一覧・検索・編集・ファイル場所の確認ができるようになりました。(The GitHub Blog)
Microsoftのリリースノートでは、Agent Skillsはリポジトリやユーザープロファイルに保存されたスキルを自動検出でき、たとえばビルドパイプラインの実行、ボイラープレート生成、チームのコーディング標準の適用などに使えると説明されています。(Microsoft Learn)
Agent Skillsに向いている内容
Agent Skillsには、属人化しやすい手順を入れると効果があります。
このリポジトリでAPIエンドポイントを追加するときは、次の順序で作業する。
1. Controllerでは入力検証だけを行い、ビジネスロジックはServiceへ置く
2. DTOはContracts配下に作成する
3. 既存のResult型で成功・失敗を返す
4. Unit TestとIntegration Testを追加する
5. OpenAPI定義の更新漏れを確認するただし、何でもSkillsに入れればよいわけではありません。大きすぎる指示、古い手順、プロジェクト固有すぎる例外処理を大量に入れると、Copilotの挙動が読みにくくなります。
管理者やリードエンジニアは、次のルールを決めておくと運用しやすくなります。
| ルール | 理由 |
|---|---|
| Skillsの管理者を決める | 似たスキルが乱立すると、意図しない指示が効きやすい |
| 命名規則を決める | 検索しやすく、用途が分かりやすい |
| 更新日と対象範囲を書く | 古い手順を使い続けるリスクを下げる |
| 実行コマンドは検証済みにする | Copilotが存在しないコマンドを前提にしないようにする |
| セキュリティ例外をSkillsだけに書かない | レビュー規約やCIと組み合わせる必要がある |
Add commit to Copilot ChatでGit履歴を文脈にできる
今回のアップデートでは、Git History、File History、Annotate（Blame）ビューからコミットを右クリックし、Copilot Chatへ文脈として追加できるようになりました。複数コミットの選択にも対応しています。(The GitHub Blog)
これは、過去の変更理由を理解したい場面で便利です。たとえば、次のような依頼ができます。
このコミットで変更された認証処理を説明してください。
現在のブランチで同じ設計方針に沿って、管理者権限チェックを追加する場合の注意点を整理してください。選択した3つのコミットを比較し、同じ不具合を別モジュールで修正する場合に見るべきファイルを挙げてください。使い方としては、障害対応やレビューの入口に向いています。過去のコミットから意図を読み取り、類似修正の候補を出す用途では強力です。一方で、Copilotの説明をそのまま監査記録や障害報告に使うのは避け、最終的には差分、Issue、Pull Request、CI結果と照合する必要があります。
コミットメッセージ指示はVisual Studio設定からCopilot instructionsへ移行
管理者が特に確認すべき変更が、コミットメッセージのカスタム指示です。
これまでVisual Studioの「GitHub → Copilot → Source Control Integration」にあるCommit message custom instructionsを使っていた場合、その設定は今後適用されません。コミットメッセージ生成の指示は、リポジトリのCopilot custom instructionsファイルで管理する形に移ります。(The GitHub Blog)
GitHub Docsでは、リポジトリ全体のカスタム指示は.github/copilot-instructions.mdに記述すると説明されています。保存した指示は、Copilotへのリクエストに自動的に追加されます。(GitHub Docs)
移行時の具体例
Conventional Commitsを使っているチームなら、.github/copilot-instructions.mdに次のようなセクションを追加します。
## Commit messages
このリポジトリのコミットメッセージはConventional Commitsに従う。
- 形式は `type(scope): summary`
- typeは `feat`, `fix`, `refactor`, `test`, `docs`, `chore` のいずれかを使う
- summaryは日本語で簡潔に書く
- 句点は付けない
- 破壊的変更がある場合は本文に `BREAKING CHANGE:` を含める
例:
- `feat(auth): 管理者権限チェックを追加`
- `fix(api): ユーザー削除時の監査ログ漏れを修正`
- `test(order): 注文キャンセルの異常系テストを追加`移行で失敗しやすいのは、個人のVisual Studio設定に残っている古い指示と、リポジトリ側の新しい指示が食い違うケースです。チームで運用するなら、個人設定に依存せず、リポジトリに集約するほうが再現性が高くなります。
管理者が確認すべき移行チェックリスト
| 確認項目 | 対応内容 |
|---|---|
| 旧設定の利用有無 | Visual Studioの旧Commit message custom instructionsを使っていたチームを確認 |
| 新しい保存先 | .github/copilot-instructions.mdにルールを移す |
| 既存規約との整合 | Conventional Commits、Issue番号、言語ルールなどを整理 |
| レビュー方法 | 生成されたコミットメッセージをPull Request運用と合わせて確認 |
| 周知 | 「Visual Studioの旧設定ではなくリポジトリ指示を見る」ことを開発者に共有 |
C++開発ではBuildPerfCppの挙動確認が重要
C++開発チーム向けには、GitHub Copilot build performance for Windowsの改善も含まれています。@BuildPerfCppがフルリビルド分析で回帰を検出した場合、比較可能なインクリメンタルビルドを再実行し、プリコンパイル済みヘッダーやヘッダー整理のような、日常的なビルド改善効果をより反映しやすくなりました。(The GitHub Blog)
リリースノートでは、GitHub Copilot build performance for WindowsはBuild Insightsを使い、MSVCのC++プロジェクトにおけるビルド性能の問題を特定し、改善案や変更を提案するとされています。利用にはBuild Insightsのためのトレース収集権限が必要になる場合があります。(Microsoft Learn)
C++チームで展開前に見るポイント
| 確認項目 | 理由 |
|---|---|
| 対象プロジェクト | MSVCを使うC++プロジェクトか確認する |
| 権限 | ETLトレース収集やUACプロンプトが運用上問題ないか確認する |
| ビルド時間の基準値 | 改善前のフルビルド、インクリメンタルビルド時間を記録する |
| 変更内容 | include整理やPCH導入が既存方針に合うか確認する |
| CI影響 | ローカルでは速くてもCIで遅くならないか確認する |
ビルド最適化は、ローカル開発体験には効いても、CIやクリーンビルドでは効果が異なることがあります。Copilotの提案を採用する前に、ローカル、CI、代表的な開発者環境の3点で比較するのが現実的です。
開発者がまず試すべき使い方
個人の開発者が今回のMay updateを試すなら、最初から全機能を使う必要はありません。次の順で試すと、効果を実感しやすくなります。
| 順番 | 試す機能 | 目的 |
|---|---|---|
| 1 | Plan agent | 実装前に計画を作り、認識ズレを減らす |
| 2 | Multi-file summary diff | Copilotの変更を安全にレビューする |
| 3 | Context window indicator | 長い会話の文脈管理を改善する |
| 4 | Add commit to Copilot Chat | 過去の変更理由を踏まえて相談する |
| 5 | Agent Skills | よく使う手順を再利用する |
特におすすめなのは、「小さすぎないが、失敗しても戻せるタスク」でPlan agentを試すことです。たとえば、既存APIのレスポンス項目追加、テスト不足の補強、画面表示ロジックの整理などが向いています。
反対に、本番障害対応中の緊急修正、セキュリティに直結する認可処理、DBスキーマを大きく変える作業では、最初からCopilotに広範囲の編集を任せるのではなく、計画作成と論点整理に用途を絞ったほうが安全です。
管理者・チームリードが確認すべき設定と展開上の注意点
GitHub Copilot in Visual StudioのMay updateは、個人の便利機能としてだけでなく、チーム運用にも影響します。管理者やチームリードは、次の項目を確認しておくと混乱を防げます。
Visual Studio 2026の更新チャネルを確認する
GitHub Changelogでは、最新機能はInsiders channelも確認するよう案内されています。(The GitHub Blog) ただし、業務端末へ一斉展開する場合は、安定版とInsidersを混在させると「同じCopilotのはずなのにUIが違う」という問い合わせが増えます。
展開前に、次の方針を決めておきます。
| 方針 | 判断基準 |
|---|---|
| 一部チームで先行検証 | Copilotを積極活用するチーム、C++ビルド改善を試したいチーム向け |
| 安定版のみ展開 | 本番保守や大規模チームでUI差分を抑えたい場合 |
| Insidersは希望者のみ | 新機能検証と通常開発を分けたい場合 |
Copilot instructionsの管理ルールを決める
コミットメッセージ指示がリポジトリ側に移ることで、.github/copilot-instructions.mdの重要度が上がります。ここに何を書くかで、Copilotの回答や生成結果の一貫性が変わります。
最低限、次の内容を整理しておくと実務で役立ちます。
| 書く内容 | 例 |
|---|---|
| ビルド・テスト手順 | dotnet test、npm test、特定プロファイルの使い方 |
| コーディング規約 | 命名規則、例外処理、ログ出力方針 |
| コミットメッセージ規約 | Conventional Commits、Issue番号の付け方 |
| レビュー観点 | セキュリティ、アクセシビリティ、パフォーマンス |
| 触ってはいけない領域 | 自動生成コード、移行中の旧実装など |
GitHub Docsでは、個人指示、リポジトリ指示、組織指示など複数のカスタム指示が適用される場合があるため、競合する指示は避けるよう案内されています。(GitHub Docs)
Agent Skillsを野放しにしない
Agent Skillsは便利ですが、個人ごとに独自スキルを増やしすぎると、同じプロンプトでも人によってCopilotの挙動が変わりやすくなります。チーム共通で使うものはリポジトリに置き、個人用は個人プロファイルに分けるなど、保存場所と責任範囲を決めておくとよいでしょう。
また、Skillsには「実行してよいコマンド」「参照してよいドキュメント」「守るべき設計方針」を書けますが、セキュリティ制御そのものの代替にはなりません。機密ファイルの扱い、外部接続、MCPサーバー利用、コードレビューの承認ルールは、別途ポリシーや権限設定で管理する必要があります。
Copilotの出力をレビュー工程に組み込む
May updateによって、Copilotの変更は見やすくなりました。ただし、見やすくなったことと、安全にマージできることは別です。
チーム運用では、次のルールを明文化しておくと事故を減らせます。
| ルール | 内容 |
|---|---|
| Planのレビュー | 大きな変更では.copilot/plans/の計画をレビュー対象にする |
| 差分の確認 | Multi-file summary diffで全体像を見てからファイル別に確認する |
| テストの実行 | Copilot生成コードでも通常のテスト・CIを必須にする |
| セキュリティ確認 | 認証、認可、入力検証、ログ出力は人間が重点確認する |
| 生成物の責任 | Copilotが書いたコードでも、マージ責任は開発者・レビュアーが持つ |
よくある疑問
Visual Studio CodeのCopilotと同じ機能ですか？
一部の考え方は共通していますが、今回の話はVisual Studio 2026向けのGitHub Copilot更新です。UI、利用できるツール、Agent SkillsやGit連携の見え方はVisual StudioとVisual Studio Codeで異なる場合があります。公式情報でもVisual Studio向けの更新として説明されています。(The GitHub Blog)
Plan agentを使えば設計レビューは不要になりますか？
不要にはなりません。Plan agentは、実装前に論点を整理するための補助です。アーキテクチャ判断、セキュリティ要件、運用要件、既存チームの設計思想は、人間が確認する必要があります。
Copilotが作った計画ファイルはコミットすべきですか？
ケースによります。チームで設計合意やレビュー記録として使いたい場合は、コミット対象にする価値があります。一方で、一時的な作業メモとして使うだけなら、リポジトリの運用ルールに従って除外してもよいでしょう。重要なのは、.copilot/plans/をチームでどう扱うかを決めておくことです。
コミットメッセージ指示を移行しないとどうなりますか？
旧Visual Studio設定のCommit message custom instructionsを使っていた場合、その設定は今後適用されないと公式リリースノートで説明されています。必要なルールは、リポジトリのCopilot instructionsファイルへ移す必要があります。(Microsoft Learn)
今回のMay updateで取るべき次のアクション
GitHub Copilot in Visual StudioのMay updateは、AIにコードを書かせる機能強化というより、AIを開発プロセスに安全に組み込むための更新です。開発者は、まずPlan agentで実装前の計画を作り、Multi-file summary diffで差分を確認し、Context window indicatorで長い会話の文脈を管理するところから始めるとよいでしょう。
管理者やチームリードは、次の3点を優先して確認してください。
1つ目は、コミットメッセージ指示を.github/copilot-instructions.mdへ移すことです。2つ目は、Agent SkillsやCopilot instructionsの管理ルールを決めることです。3つ目は、Copilotが生成した計画・差分・コミット文を、既存のレビューとCIにどう組み込むかを明確にすることです。
今回の更新を活かすコツは、Copilotにすぐ実装させることではありません。計画、実装、差分確認、ルール管理の各段階でCopilotを使い分けることです。その運用ができるチームほど、GitHub Copilot in Visual StudioのMay updateを実務の生産性向上につなげやすくなります。
コメント