VS Code 1.136、プルリクエストを仕上げるAgent Mergeを追加
VS Code 1.136がAgent Merge(エージェントマージ)をプレビュー提供。エージェントがレビュー指摘に対応し、失敗したチェックを直し、コンフリクトを解消します。
3 分で読めます

Visual Studio Code 1.136が、Agent Mergeというプレビュー機能を追加しました。開いているプルリクエストをAIエージェントに渡す機能です。エージェントはレビューの指摘に答え、失敗したチェックを直し、マージコンフリクトを解消して、マージできる状態まで持っていきます。Microsoftはリリースノートの日付を2026年9月2日としています。
プルリクエストとは、レビュー待ちの変更案のことです。マージにたどり着くまでには、指摘、修正、テストのやり直しという遅い繰り返しが挟まりがちです。Agent Mergeが狙うのはこの繰り返しであり、コードを最初に書く作業ではありません。
Agent Mergeが実際にすること
Microsoftのリリースノートは、この機能を一文で説明しています。「Agent Merge helps you take a pull request across the finish line」とあります。「It asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows」とも書かれています。
この一文の中に、4つの別々の仕事が入っています。
| 仕事 | エージェントがすること |
|---|---|
| レビュー指摘 | レビュアーのコメントを読み、コードを直す |
| 失敗したチェック | 失敗したテストやLintの原因を切り分けて直す |
| マージコンフリクト | 対象ブランチに対するコンフリクトを解消する |
| ワークフロー | チェックを再実行し、この流れを繰り返す |
エージェントが自分でマージすることはありません。承認は人間の側に残ります。どのGitホスティングに対応するかは、リリースノートには書かれていません。
有効にする方法
Agent Mergeは既定では無効です。Microsoftはchat.agentMerge.enabledという設定の後ろに置いています。
この設定を入れただけでは、まだ何も動きません。機能はセッション単位で有効にします。入口は3つあります。Agent Mergeボタン、「Enable Agent Merge for Active Session」というコマンド、そしてAgentsウィンドウです。
このセッション単位という設計は見ておく価値があります。リポジトリを見張って勝手にコミットを積む常駐サービスではありません。
1.136のその他のエージェント関連の変更
Agent Mergeと同時に、セッションまわりの小さな変更がいくつか入りました。
- マルチルートワークスペース対応(実験的)。CopilotとClaudeの両方のセッションが対象
- エージェントがプロジェクトを名前で特定できるワークスペース解決
- 関連するチャットを親セッションの子として並べるセッション階層
- セッションが承認待ちになったことを知らせる通知
- セッションが作成したファイルの読みやすいパンくず表示
- 操作を1か所にまとめ直したセッション入力欄
チャット画面も変わりました。実験的なチャット背景、企業管理者向けのディクテーション制御、スクリーンリーダーの改善が入っています。
これが開発者にとって意味すること
ここで興味深いのはコード生成ではありません。エージェントがCI(継続的インテグレーション)とプルリクエストの待ち行列を操作するようになったことです。どちらも共有された仕組みであり、影響範囲はエディタのバッファより広くなります。
いちばん注意して見るべきはコンフリクトの解消です。4つの仕事のうち、間違った答えでもコンパイルが通り、テストも通ってしまうのはこれだけです。エージェントが誰か他の人の変更を黙って捨てる形でコンフリクトを解消しても、後段の何も文句を言いません。自分でやっていないリベースを読むときと同じように、その差分を1行ずつ読んでください。
2つ目に確認すべきは費用です。チェックが通るまでワークフローを再実行する仕組みなので、不安定なテストがあると、ランダムに失敗するテストへエージェントが挑み続けることになります。CIが分単位の課金なら、有効にする前に上限を決めてください。 Telemetryの作者がDuckDBの掲示板に投稿した合成データの計算例では、失敗した試行を数えると受理タスクあたり0.75ドル、数えないと0.30ドルになります。当サイトではGitHubがAzure ReposでCopilotのコードレビューを課金し始めた件を取り上げましたが、自分の代わりにパイプラインを回すものすべてに同じ問いが当てはまります。
本当の制御は変わっておらず、この設定ファイルの中にはありません。ブランチ保護ルール、必須レビュアー、必須ステータスチェックが、何を取り込めるかを決めます。この設定が決めるのは、エージェントがブランチにコミットを追加してよいかどうかだけです。リポジトリが何を受け入れるかは決めません。
当面はプレビューという表示を真に受けてください。自分が持つブランチで、すでにほぼグリーンのプルリクエストに対して有効にし、生成されたコミットをすべて読んでください。コーディングエージェントの調査では、どのツールを使うかで判断が割れることが、宣伝が示すよりずっと多いと分かっています。マージコンフリクトについて自信を持ったまま間違えるエージェントこそ、想定しておくべき失敗の形です。
出典
- Visual Studio Code September 2026 (version 1.136) - Visual Studio Code
- vscode release 1.136.1 - GitHub
関連記事

JetBrains調査: 開発者はエージェントがコードの47%を書くと回答
開発者1万5509人を対象にしたJetBrainsの調査で、エージェントが完全に書くコードは平均47%と分かった。90%が週に1回はエージェントを使い、Claude Codeが39%で採用率の首位だ。

MicrosoftのProject Zenith、ローカルAI開発向けWindowsモード
Project Zenithは、64GBの統合メモリを持つPCで300億パラメータ超のモデルをローカル実行するために作られた、開発者向けWindows 11環境だ。

Claude Code、Codex、Cursorが同じツールを選ぶのはわずか42%
1万6,893件のコーディングエージェントのセッションを調べた調査によれば、Claude Code、Codex、Cursorが同じサードパーティ製ツールを選ぶのは42%にすぎない。PayPalが候補だったセッションでは、常にStripeが勝った。