agentがreview commentを直した。ところがrequired checkは落ちたまま。次の修正では、最初の依頼に入っていないfileまで変わっている。
PR作成後もagentを動かすなら、こうした場面は珍しくなくなるはずです。自分が怖いのは一回の誤修正より、修復を繰り返すうちに「何を直すPRだったか」が薄れていくことです。
2026年9月2日公開のVS Code 1.136には、Preview機能としてAgent Mergeが入りました。review feedback、failed checks、merge conflictsへの修復とworkflowの再実行を繰り返し、PRをmerge-readyへ近づけます。
便利そうですが、いきなり実repositoryで回し続けるのは避けたい。merge-readyを目指す修復ループと、teamがmergeを許可する判断は別です。
まず使い捨てPRでblockerを一種類ずつ作り、各cycleの前後を記録する。さらに、回数とscopeに停止条件を置く。自分ならこの順で試します。
まずtest用PRで有効化する
最初にVS Codeが1.136系か確認します。
code --version
次に、検証用repositoryまたはproduction変更を含まないbranchで小さなPRを作ります。設定は次の一行です。
{
"chat.agentMerge.enabled": true
}
Agents windowで対象sessionを開き、Enable Agent Merge for Active Sessionまたはtitle barのAgent Mergeから有効化します。現時点ではPreviewなので、対応harness、GitHub権限、branch protection、画面上の名称は手元の環境でも確認してください。
初回の目的は自動mergeではありません。agentがどの入力を受け、何を変更し、どの状態で止まるのかを見ることです。最後のmergeは人間が行います。
blockerを三つ同時に置かない
検証用のfailureは分けます。
case A: review feedback
fixture関数名の変更を求めるcommentを1件置く
case B: failed required check
tests/agent-merge-fixture.test.tsだけを決定的にfailさせる
case C: merge conflict
base側とPR側で同じfixture行を別々に変更する
各caseは別commit、できれば別PRにします。review comment、CI failure、conflictを一度に盛ると、agentの変更がどのblockerへの反応だったのか追いにくくなります。
failure fixtureには固定入力を使います。flaky testや外部APIは避けます。production deploy、DB migration、実在するsecretも検証材料にしません。Agent Mergeの挙動を見るために、別の事故要因を増やす必要はありません。
この手順は成功結果を示すものではなく、読者が自分の環境で埋める検証harnessです。架空の成功率や所要時間は置きません。
transcriptよりPRの前後を残す
session transcriptだけを読んでも、どのcommitでcheckが走ったのか曖昧になりがちです。1 cycleをhead beforeからhead afterまでの変更として記録します。
| cycle | head before | blocker | agent change | changed files | workflow run | head after | result |
|---|---|---|---|---|---|---|---|
| 1 | `<sha>` | failed check | `<summary>` | `<paths>` | `<url>` | `<sha>` | fixed / repeated / new-blocker |
記録は次の順で行います。
- agentへ戻す前に、PRのhead SHAとblockerのURLを保存する
- agentのturn後に、changed pathsとdiffを確認する
- 再実行されたworkflowのURLとstatusを残す
- 新しいhead SHAを保存する
-
fixed、repeated、new-blockerのどれかを選ぶ
会話ログは、agentが何を意図したか調べる補助資料にはなります。一方、PRの状態を判断するときの正本はGitHub上のhead、diff、review thread、check URLです。
同じblockerが残ったのか、新しいblockerを作ったのかも分けます。「元のtestが通った」だけでは、修復成功とは限りません。
修復回数をteam側で制限する
Agent Mergeが何cycleで収束するかを決め打ちせず、teamの運用としてbudgetを置きます。
# VS Code / GitHubの公式schemaではない
# team内で使う検証用convention
agent_merge_policy:
repair_budget: 3
allowed_blockers:
- review_feedback
- required_check
- merge_conflict
stop_when:
- same_blocker_repeats
- changed_paths_leave_task_scope
- permission_or_secret_is_required
- new_unrelated_failure_appears
final_gate:
human_scope_review: required
merge: manual
ここでのrepair_budget: 3はVS Codeの既定値でも、推奨値でもありません。説明用のteam設定です。repositoryのrisk、CIの実行時間、model usage、reviewできる人数に合わせて決めます。
回数より先に止める条件もあります。
- 同じblockerが再発した
- task外のpathへ変更が広がった
- secretや追加権限が必要になった
- 元のfailureとは無関係なfailureが増えた
このどれかに当たったら、同じ指示をagentへ投げ直しません。証拠を残して人間へ戻します。新しいfailureを作ったcycleを「元のfailureは直ったから成功」と数えるのも危険です。
Agent Hostがsessionを保持しても、merge policyまでは決めない
VS CodeのAgent Hostは専用processとしてagent sessionを所有します。editor、Agents window、remoteやbrowser側のclientが、同じsessionへ接続してstateを継続・同期できる設計です。Agent Host Protocolはclientから見たsessionの扱いを共通化します。
これは長い修復ループには都合がいい。windowを切り替えてもsessionを継続しやすくなります。
ただし、sessionを保持できることは、修復を許可してよいことの証明にはなりません。AHPは各harnessの推論やtool実装をそのまま扱い、team固有のapproval policyやmerge基準を決めるものでもありません。
継続性はAgent Host、停止条件はrepositoryとteam。この二つは分けて持つほうが運用しやすいです。
merge-readyの直前で人間が見るもの
Agents windowではChangesやFilesからdiffを確認できます。必要ならrepositoryのTaskやterminalでcommandを再実行し、UI変更ではintegrated browserも使います。
最後に、GitHubとAgents windowを行き来しながら次を確認します。
PR head SHA
changed paths / full diff
resolved review threads
required check URLs and status
conflict resolution diff
new warnings or unrelated failures
remaining approvals
とくに見るのはtask外変更です。checkがすべて緑でも、依頼していないconfigやworkflowまで変わっていたら、そのままmergeしません。conflictを解消した場合は、最終diffだけでなく解消部分も読みます。
merge-readyは修復ループが目指す状態です。人間のscope reviewが終わり、repositoryのapproval条件を満たした状態とは分けて扱います。
手戻りを減らすなら、まずループを観測可能にする
Agent Mergeによって、review commentやCI failureを毎回chatへ貼り直す手間は減らせそうです。そのぶん、agentが何cycle動き、どのheadを作り、何を新しく壊したかを追える形にしておく必要があります。
設定を有効にする前に、使い捨てPR、cycle table、repair budget、human final gateを用意する。少し地味ですが、修復を何度でも続けられる機能ほど、この外側のルールが効きます。