目次
Visual StudioのCopilotは、コードを補完する機能から、プルリクエストを読み、利用するモデルを選び、依存パッケージの更新案まで作る開発支援へ広がっています。ただし、三つの機能は同じ「AIに任せる作業」ではありません。入力にする情報、変更できる範囲、確認すべき結果が異なります。
GitHubは2026年10月22日、Visual Studio 2026向けCopilotの9月更新として、Gitエージェントによるプルリクエストの探索、独自モデルを使う仕組みの更新、エラー一覧からのNuGet脆弱性修正を公表しました。本稿は同日付のGitHub ChangelogとMicrosoft Learnを2026年10月23日に確認した、開発者向けの実装・使い分け解説です。本サイトでは実機検証を行っていないため、提供元が説明する機能と、導入時に提案する検証手順を分けて扱います。
スポンサーリンク
今回の更新は三つの入口をIDEへ集めた
GitHub ChangelogのVisual Studio更新告知は、三つの変更を挙げています。Gitエージェントでは、Git Repositoryウィンドウからプルリクエストをコンテキストとして添付し、コメントや変更ファイルへ移動できるリンク付きの要約を得られます。利用にはGitプロバイダーのMCPサーバー接続が必要で、GitHubとAzure DevOpsが対応すると説明されています。
独自モデルの利用はプレビューで、Microsoft Foundry、OpenAI、Anthropic、Ollamaが対応プロバイダーとして示されています。更新後はGitHub Copilot SDKを基盤にした新しいAgent（Preview）が必要になり、従来のAsk／Agentモードでは使えません。以前登録したOllamaモデルは再追加が必要です。これは単なる画面変更ではなく、既存設定とテスト手順を移す必要がある破壊的変更です。
NuGetについては、復元時に検出された既知の脆弱性警告から修正アクションを選ぶと、Copilot Chatのエージェントモードが開き、組み込みのNuGet MCPサーバーを使って更新案を作ります。GitHubへのサインインと、ChatのツールメニューでNuGet MCPサーバーを有効にする操作が前提です。更新はCopilot Free、Student、Pro、Pro+、Max、Business、Enterpriseを含む全プラン向けとされています。
| 機能 | 適する作業 | 人が確認する結果 |
|---|---|---|
| Gitエージェント | PRの変更点と議論の把握 | 要約が差分・コメントを正しく参照しているか |
| BYOK／独自モデル | 用途に合うモデルや自社デプロイの比較 | 機能対応、品質、費用、データ経路 |
| NuGet MCP | 既知の脆弱性を持つ依存関係の更新案作成 | 解消確認、互換性、テスト、ロックファイル |
PR理解は要約より根拠リンクを使う
Gitエージェントの価値は、長いプルリクエストを短くすることだけではありません。要約から元のコメントやファイルへ移動できるため、「何が変わったか」と「なぜ変えたか」を往復しやすくなる点にあります。レビュー開始時には、目的、変更範囲、未解決の議論、テスト状況を整理させ、各項目を原文へたどります。
Copilotの要約だけで承認を決めないでください。差分に現れない設定変更、生成物、外部サービスの前提、レビュー後に追加されたコミットを落とす可能性があります。まず要約で読む順番を作り、その後に重要ファイルの差分、未解決コメント、CI結果を確認します。要約と原文が食い違うときは、元の差分と会話を正とします。
実務では、PRを添付した最初の依頼を「変更された機能、影響する境界、未解決コメント、テスト不足をそれぞれ根拠リンク付きで列挙する」のように分解すると確認しやすくなります。その後、認証、永続化、課金、公開APIなど影響の大きい箇所だけ追加で尋ねます。質問を広げるほど答えが正確になるとは限らないため、レビュー観点を先に決めることが重要です。
スポンサーリンク
BYOMではなく18.10のBYOKとして移行を考える
GitHubの告知はBYOM（Bring Your Own Model）という表現を使っていますが、更新されたMicrosoft LearnのCopilot Chatモデル設定では、Visual Studio 2026 version 18.10以降をBYOK（Bring Your Own Key）として説明しています。旧BYOMの案内は18.10より前の仕組みとして残されています。導入手順を作るときは名称だけでなく、対象バージョンと新しいAgent（Preview）を明記すると混同を防げます。
18.10のBYOKはCommunity、Professional、Enterpriseで既定有効のプレビュー機能です。GitHubへサインインしていない場合でも自社のモデルデプロイを使えるとされています。一方、すべてのモデルがツール利用、画像入力、高度な推論などのエージェント機能に対応するわけではなく、Visual Studioは非対応機能を表示します。OpenAIとOllamaではカスタムエンドポイントも扱えますが、あらゆる構成の動作が保証されるわけではありません。
導入時は、既存のOllama設定を再登録できるかを最初に確認し、同じリポジトリ、同じ指示、同じツールで現行モデルと候補モデルを比較します。モデル名だけを変えたつもりでも、ツール対応やコンテキスト上限が異なれば、エージェントが完了できる手順も変わります。出力品質、ツール成功率、処理時間、プロバイダー側の費用を別々に記録してください。
モデル変更の評価手順は「AIの改善を勘で判断しないために｜評価データと回帰テストの始め方」で整理しています。今回のBYOK移行でも、成功例だけでなくツール非対応、長い差分、途中失敗を含む評価セットを作り、重大な退行がないことを確認します。
NuGet修正は提案から検証までを一つの作業にする
Microsoft LearnのError List解説によると、Visual Studio 2026 version 18.10ではNuGet AuditのNU1901、NU1902、NU1903、NU1904警告からFixer列のアクションを選べます。Copilot Chatが開いて更新案を示しますが、公式手順の最後も変更内容を確認して適用することになっています。警告が消えることと、アプリケーションが正しく動くことは別の合格条件です。
Visual Studio 2026のリリースノートでは、NuGet MCPサーバーは組み込みですが一度有効化が必要で、脆弱性の修正、互換性のある最新版への一括更新、指定版への更新に利用できると説明されています。便利だからと「全更新」を最初に使うのではなく、警告を出した直接・推移的依存、修正版の範囲、対象フレームワークを確認して、変更量を小さく保つ方が原因を追いやすくなります。
- 更新前に復元結果、警告コード、依存関係グラフ、現在のテスト結果を保存する
- 一つの脆弱パッケージまたは関連する小さな集合へ対象を絞って修正案を作る
- プロジェクトファイル、Directory.Packages.props、ロックファイルの差分を確認する
- 再度restoreとNuGet Auditを実行し、対象警告が解消したことを確認する
- ビルド、単体・結合テスト、起動確認を行い、互換性の退行を調べる
監査ソースとパッケージソースが異なる環境では、どの脆弱性データを基に警告が出たかも記録します。リリースノートは、Visual Studioでパッケージ取得元とは別の監査ソースを設定でき、未設定時はパッケージソースを監査にも使うと説明しています。社内フィードだけを設定している場合に警告が出ないから安全、と判断しないための確認点です。
スポンサーリンク
三機能を一つの自動化として混ぜない
PR要約、モデル切り替え、依存関係更新を連続して実行すると、失敗原因が分かりにくくなります。PR理解は読み取り、BYOKは実行基盤の選択、NuGet MCPはファイル変更です。それぞれに入力、出力、承認点を設け、作業記録を分けます。モデル変更とパッケージ更新を同じPRで行わないことも、比較とロールバックを容易にします。
また、利用できるモデルの変更に備える管理は「Copilotのモデル廃止にどう備える？ポリシーAPIで移行を管理」で扱っています。今回のBYOKは開発者がモデル接続を追加する手順が中心ですが、Business／Enterpriseで使う場合は組織ポリシーと提供条件も別途確認し、個人設定だけで導入完了としないでください。
小さな検証リポジトリから始める
最初の検証では、履歴とコメントを含む小さなプルリクエスト、既知の警告を再現できるテスト用依存関係、ビルドとテストが自動化されたリポジトリを用意します。Gitエージェントの要約が根拠へ移動できるか、候補モデルが必要なツールを使えるか、NuGet更新後に警告とテスト結果がどう変わるかを順番に確かめます。
本番リポジトリへ広げる判断は、機能が表示されたかではなく、レビュー時間を短縮しながら見落としを増やさないか、モデル変更を再現可能な条件で比較できるか、依存関係更新を小さな差分で検証できるかで行います。今回の更新は三つの入口を近づけましたが、最終的な品質保証まで自動化したわけではありません。AIには探索と候補作成を任せ、人は根拠、差分、テスト結果で採用を決める。この役割分担が、便利さを実務へ定着させる基準になります。
