GitHub CopilotをVisual Studioで使うとき、モデルを選べるだけでは十分ではありません。どの作業にどこまで考えさせるか、チームの専門的な役割をどう共有するか、変更をいつ見直すかは、それぞれ別の判断です。

2026年8月の更新では、この三つをVisual Studio内で扱いやすくする機能がまとまって加わりました。思考量の切り替え、組織レベルのカスタムエージェント、変更やコミットに対するGit agentレビューが中心です。

便利な機能を全部オンにする話ではなく、制御する範囲を分けるのがポイントです。個人の一問、組織の共通手順、PR前の差分という三つの単位から、実務での使い分けを考えます。

Visual Studio 18.9でCopilotの制御点がタスク・組織・変更へ広がる

Visual Studio 2026のリリースノートでは、思考量、Git agentレビュー、組織レベルのカスタムエージェントを含むAugust Update 18.9.0が2026年8月11日に公開されています。その後、18.9.1が8月18日、18.9.2が8月25日に公開されました。

8月25日のVisual Studio Blogも、これらをStable Channelの更新として案内しています。つまり、更新の中心は新しいモデルを一つ追加することではなく、Copilotを使う場面ごとに制御点を置くことだと捉えられます。

制御点	主な範囲	判断できること
モデルと思考量	一つのタスク	応答速度、推論の深さ、トークン使用量のバランス
使用量とモデル管理	個人のプランとセッション	利用状況、モデルの能力、コンテキスト長、コスト情報
組織レベルのカスタムエージェント	複数リポジトリを含む組織	専門的な役割や進め方の共有
Git agentレビュー	未コミット変更またはコミット	PRを開く前の差分フィードバック

この切り分けができると、「Copilotを強くするか弱くするか」という一軸の話ではないと分かります。次は、最も小さい単位である一つのタスクから見ていきましょう。

思考量はモデル名ではなく作業の難しさに合わせる

Visual Studioでは以前からモデルを切り替えられました。GitHub Docsは、複数モデルを使うCopilot Chatの前提をVisual Studio 2022 version 17.12以降としています。Visual Studio 18.9で加わった思考量は、そのモデル選択に「同じモデルへどこまで推論させるか」という二つ目の軸を足します。

対応モデルでは、Low、Medium、Highを選べます。公式の位置づけを作業へ落とすと、次のようになります。

• Low: 単純な質問やコード提案など、速さと少ないトークン消費を優先したい作業
• Medium: 日常的な実装で、応答速度と推論の深さを両立したい作業
• High: 難しいアルゴリズム、アーキテクチャ判断、切り分けにくいデバッグなど、深い推論が必要な作業

Highは正しさを保証する設定ではありません。推論を深くする代わりにトークン使用量が増えるため、難しい作業へ絞り、出力は別途検証する使い方が自然です。

モデル選択画面では、お気に入りの固定、使わないモデルの折りたたみ、能力・コンテキスト長・コスト情報を確認できる管理画面も追加されました。プロンプト欄のコンテキスト表示からプラン全体の使用量へ移れるので、思考量を変えた結果を同じ作業の流れで追えます。

ただし、更新そのものは全Copilotプラン向けでも、選択できるモデルや機能は同一ではありません。Copilotプランの公式比較では、Copilot FreeとStudentのモデル利用は自動選択のみとされ、モデルへのアクセスはプラン、クライアント、組織ポリシーにも左右されます。画面に表示される選択肢を前提に判断したいところですね。

組織レベルのカスタムエージェントで専門役割をリポジトリ横断共有する

タスクごとの思考量が個人の制御なら、組織レベルのカスタムエージェントはチームの再利用単位です。GitHub organizationまたはenterpriseの所有者が公開したエージェントを、Visual Studioが対象リポジトリで検出し、説明と配布元の組織をagent pickerに表示します。

GitHubの組織向けセットアップ手順では、組織レベルの定義を組織の.githubまたは.github-privateリポジトリにある/agentsディレクトリへ置きます。.github-privateを使う場合、定義リポジトリへ直接アクセスできない組織メンバーにもエージェントを提供できます。

たとえば複数の.NETリポジトリで同じ移行手順を使うなら、対象の確認方法、期待する出力、参照してほしい資料を一つの専門エージェントへまとめる形が考えられます。リポジトリごとに長いプロンプトを複製するより、役割の更新点を一か所へ寄せやすくなります。

一方、この機能にはGitHub organizationが必要で、公式ドキュメント上はpublic previewです。全員へ展開する前に、まず一つの用途で定義内容とVisual Studio上の見え方を確かめ、変更履歴をレビューできる運用にしておくのが安全です。

Git agentレビューをコミット前後の短いループに入れる

Git agentは、未コミットの変更だけでなく、コミットもPRを開く前にレビューできます。未コミット変更ではGit Changesからレビューを始め、コミットではCopilot Chatへコンテキストとして添付するか、Git Repositoryの履歴から実行します。結果はエディタ内へ表示され、Git Changesの一覧から指摘箇所へ移動できます。

レビュー後もCopilot Chatで理由を聞いたり、修正方法を詰めたりできます。Visual Studio 18.9の説明ではGitHubとAzure DevOpsの両方のリポジトリに対応し、コミットレビューのコメントはVisual Studioのセッション内に残るとされています。PRの承認フローとは別に、作者が差分を整えるための短いループですね。

実務では、次の順に組み込むと役割が混ざりません。

1. Git agentへ未コミット変更または対象コミットを渡し、差分の問題候補を出す
2. 指摘の根拠を確認し、必要な修正だけを反映する
3. テストと静的解析を実行してからPRを作り、人によるレビューへ渡す

Copilotのレビューはすべての問題を見つける保証がなく、誤る場合もあります。GitHub Docsもフィードバックの検証と人によるレビューの併用を求めています。ローカルレビューを新しい品質ゲートにするより、既存のテストとレビューへ入る前のセルフチェックとして使うのが合います。

Copilot導入は個人設定から始め、共有とレビューを段階的に足す

2026年8月の更新を使い分ける答えは、機能名ではなく制御範囲で決めることです。まず個人がLow・Medium・Highと思考量を切り替え、モデル管理と使用量表示で負荷を把握します。ここは組織設定を待たずに試しやすい部分です。

次に、複数リポジトリで繰り返している役割が一つ見つかった段階で、組織レベルのカスタムエージェントを小さく試します。public previewであることを踏まえ、定義の所有者と更新方法を先に決めておくと、便利さと管理を両立しやすくなります。

最後にGit agentレビューをPR前のセルフチェックへ加えれば、Copilotは単なるチャット相手ではなく、タスク、チーム、変更の各段階をつなぐ道具になります。ただし、最終判断はテストと人のレビューに残す。この境界まで含めて設計することが、今回の更新を実務へ取り込む意味です。

出典

• Title: GitHub Copilot in Visual Studio — August update
• URL: https://github.blog/changelog/2026-08-28-github-copilot-in-visual-studio-august-update-2