Agent時代、branchはもはやデフォルトではない
Branchが開発のデフォルトになったのには、それを支える条件があった。commit履歴に名前を付けるだけでなく、コードの隔離、並行開発、レビュー待ちまで担ってきたからだ。ツールとチームのルールがその役割を前提に育つうちに、「まずbranchを作る」という手順は、ほとんど問い直されなくなった。
Coding Agentは、その条件の一つを変えた。タスクごとに独立したリモート環境で開発と検証ができるなら、実行環境の隔離をbranchが担う必要はない。変更が小さく、チェックが信頼でき、容易にrevertでき、必須の承認もないAgentの作業は、直接mainへ入れられる。
ただし、対象は明確に限られる。大規模な移行、外部からの貢献、長期的な共同作業、コンプライアンスや必須レビューがあるリポジトリでは、引き続きbranchとPRが必要だ。変えるのは、低リスクなAgentタスクのデフォルトである。
Branchは隔離とガバナンスを同時に担ってきた
Gitのbranchは、commitが増えるたびに先へ進むポインターであり、それ自体がコードを複製したり、作業ディレクトリを作ったりするわけではない。一つのディレクトリでバージョンを切り替えるにはcheckoutを使い、複数のバージョンを同時に扱うにはworktreeを追加できる。
同じGitリポジトリ
repo/ mainの作業ディレクトリ
feature-a/ feature-aのworktree
bugfix-b/ bugfix-bのworktreePRのワークフローは、その上にレビュー、自動チェック、承認記録を加えた。こうしてbranchは、開発の流れ、別の作業ディレクトリを示す名前、mainへの統合を待つ変更を同時に表すようになった。これらの役割は関連しているが、同一ではない。
Coding Agentも自然に「一つのAgent、一つのbranch、一つのworktree」という形を引き継いだ。ファイルのバージョンは分けられても、プロセスは同じマシン上でCPU、メモリ、ポートを奪い合う。依存関係、ブラウザ、バックグラウンドサービスの調整も人に残る。
Orbは実行環境そのものを隔離する
Ampが2026年6月に公開したOrbは、独立したリモート実行環境である。各Orb threadには専用のコード、依存関係、プロセス、ポート、ブラウザがあり、Agentは他のタスクと同じローカルマシンを奪い合わずに開発と検証を進められる。
人はdiff、テスト結果、実行環境を確認でき、必要なら共有ターミナルへ入り、変更をローカルへ同期できる。各タスクはbranchとworktreeに頼らず、開発と検証の現場を丸ごと持てるようになった。
Branch、checkout、worktree、Orb、PRはそれぞれ別の問題を解く。branchは開発の流れを表し、checkoutはバージョンを現在のディレクトリへ展開し、worktreeは追加のディレクトリを作る。Orbは完全なリモート実行環境を提供し、PRはレビュー、承認、監査を担う。Orbが取り除くのは、タスクの実行場所を隔離するためにbranchを作る理由だけであり、ガバナンスまで置き換えるものではない。
mainへ直接入れるための条件
複数のAgentが同じmainから作業を始めることはある。先に一つの変更が入ったら、後から完了したAgentは最新のmainへrebaseし、競合を解決して、チェックを再実行する。threadには変更の意図がまだ残っているため、通常の競合はAgentが処理でき、判断できない点だけを人へ戻せる。並行作業は残るが、統合待ちのbranchを長く維持する必要はない。
この方法が成立するには、次の四つを同時に満たす必要がある。
- 変更が小さく、diffを短時間で理解できる。
- 自動チェックが信頼でき、rebase後のコードでも再実行される。
- 各commitを独立してrevertでき、障害をすぐに止められる。
- 必須承認、コンプライアンス記録、長期的な共同作業の要件がない。
レビュー自体はなくならない。Orb内のdiffとテスト結果を確認すればよく、branchを待機場所として使わずに済む。どれか一つでも満たせなければ、branchとPRを使い続ける。
デフォルトを変える
条件を満たすAgentは、独立環境で開発と検証を終え、最新のmainへrebaseし、チェックをやり直してから直接pushできる。次のAgentは更新済みのmainから始められ、早い統合によって長期分岐の競合も減る。
導入するなら、まず文書、テスト、局所的な修正など低リスクの変更で試し、競合率、チェック結果、revertに要した時間を記録する。mainが安定しているという証拠が得られたら範囲を広げ、レビューや復旧が追いつかなければ従来のbranchワークフローを残せばよい。