こんにちは。@m_koshikawa です。
個人の趣味であるプロジェクトを AI 駆動で進めていたら、4日間で PR 83本、マージ51本、コミット171本 を積み上げていました。
最初は「進捗すごい」と喜んでいたのですが、3日目あたりから複数の AI エージェントを並走させた時に 同じ機能を別ブランチで実装し始める とか レビューが追いつかない といった情報錯綜が起き始めました。
原因を辿ったら、GitHub リポジトリの delete_branch_on_merge 設定がデフォルトの false になっていて、マージ済みのブランチが全部残っていた ことが分かりました。
この記事は、AI 駆動開発のスピードと、リポジトリの初期設定がそれに追いつかないとどうなるかという実例の記録です。
4日間で何が起きたか
数字で見るとこうなります。
| 日付 | コミット数 | マージPR数 |
|---|---|---|
| 2026-04-25(初日) | 31 | 2 |
| 2026-04-26 | 66 | 24 |
| 2026-04-27 | 59 | 17 |
| 2026-04-28(現時点) | 15 | 8 |
| 合計 | 171 | 51 |
PR 番号は #83 まで到達しています。マージは51本なので、残り32本はドラフトやクローズ済みです。マージ済み51本分のブランチが、リポジトリの設定上どこにも消されず残り続けていました。
これは AI 駆動開発の典型的な現象だと思います。Claude Code や GitHub Copilot Agent や Codex が 同時並列に作業を進める と、人間1人では絶対に到達できない PR 数になります。私の感覚値ですが、この4日間の作業は、AI を使わない従来の開発であれば1〜2ヶ月相当です。
ブランチが残ると何が困るのか
「マージ済みなんだから残っていても無害では?」と思うかもしれません。私も最初そう思っていました。実際には複数 AI エージェントの並走時に困ります。
具体的に起きたこと:
-
AI エージェント A が
feature/xxxブランチで機能 X を実装し、PR を出してマージされる - ブランチが削除されないので、AI エージェント B が別の作業を始めた時に、リモートから
git fetchでorigin/feature/xxxを取得してくる - B は「最新の作業ブランチがある」と判断して、その上に積んでしまう
- しばらくして矛盾に気づく(同じ機能が main にも feature/xxx にも存在する状態)
人間1人が手を動かしているうちは「自分が今どのブランチで何をやっているか」を脳内で管理できます。でも AI エージェントを2つ3つ並走させた瞬間、リポジトリの状態(=リモートに何のブランチが見えているか)を リポジトリ側がきれいに保ってくれていない と、エージェントの判断材料が汚染されます。
これは AI が悪いのではありません。リポジトリの状態が AI の入力情報そのもの という事実を、私が軽視していただけです。
原因 — delete_branch_on_merge のデフォルト
GitHub のリポジトリには delete_branch_on_merge という設定があります。PR をマージした時に、ソースブランチを自動で削除するかどうか を決めるフラグです。
| 設定 | マージ後のソースブランチ |
|---|---|
true |
自動削除される(クリーン) |
false(デフォルト) |
残り続ける |
新しくリポジトリを作ると、初期値は false です。GitHub.com の Web UI でリポジトリを作る時、特に何も触らないと false のままです。
これは個人開発でも、チーム開発でも、エンタープライズでも同じ。多くの人がデフォルトのまま使っている設定の1つ だと思います。今回のケースでは、私もリポジトリ作成時に何も設定せず、4日間そのまま走り続けていました。
解消 — 1コマンドで終わる
GitHub CLI(gh)を使うと、1コマンドで切り替えられます。
gh repo edit <owner>/<repo> --delete-branch-on-merge
これで以降のマージで自動削除が走ります。すでに残っているブランチについては、別途削除する必要があります。私の場合は AI エージェントに削除を依頼して、リモートブランチを main 1本だけのクリーンな状態に戻してもらいました。
Web UI から設定する場合は、リポジトリの Settings → General → Pull Requests → "Automatically delete head branches" にチェックを入れます。
教訓 — AI 駆動開発で最初の30秒に入れる初期設定
このトラブル自体は1コマンドで解消できます。問題は トラブルになる前にプロジェクト開始時に入れるべき設定 という認識を持てていなかったこと、そして AI 駆動開発の量を甘く見ていたことです。
私の中で更新された認識を整理します。
AI 駆動開発でプロジェクト開始時にチェックすべき項目
| 項目 | 推奨設定 | 理由 |
|---|---|---|
delete_branch_on_merge |
true |
マージ済みブランチが残ると複数エージェント並走時に情報錯綜 |
| ブランチ保護(main) | 有効 | エージェントが直接 main に push しないため |
| Auto-merge | プロジェクト次第 | レビューが人間ボトルネックになる場合は有効化を検討 |
.gitignore の初期整備 |
プロジェクト開始時 | エージェントが意図しないファイルを add するのを防ぐ |
| README に「AI エージェント運用ルール」を1セクション | プロジェクト開始時 | 複数エージェントが参照する共通の運用前提を明文化 |
特に delete_branch_on_merge は、プロジェクトを作った最初の30秒 で gh repo edit ... --delete-branch-on-merge を1回叩くだけで一生効きます。逆にこれを忘れると、4日後に83本のブランチ残骸の前で「何がどこにあるか分からない」状態になります。
AI 駆動開発の量を見積もる
人間1人で4日間に書ける PR は、せいぜい数本です。AI 駆動になると 50〜80本 に跳ね上がる可能性があります。これは規模の感覚としても認識を更新する必要がありました。
ちなみに今回の作業で使ったのは Claude Code(Max 20x プラン)で、全タスクを Claude Opus 4.7 で実行 しています。Sonnet に落とすこともなく、最上位モデルだけを使い続けた状態での使用量がこうです。
- 現在のセッション: 3% 使用済み(4時間39分後にリセット)
- 週間制限(すべてのモデル): 32% 使用済み(土曜12:00 にリセット)
4日で 83 PR を出したマルチエージェント並走を、最上位モデルの Opus 4.7 だけで回しても、週上限の 3分の1 しか使っていません。AI 駆動開発の量は、定額プランの範囲内で十分に出ます。「最強モデルでも使い切れないくらい使える」が現実値 だと言えます。
これは AIコーディングツールの選び方とも繋がります。Copilot のような従量課金では Opus 4.7 は 7.5x のプレミアム扱いですが、Claude Code Max のような定額プランなら、最上位モデルだけで運用しても定額の範囲に収まります。何にいくら払うかの選択 が、ここでも効いてきます。
もう1つ重要なのは、この量がトラブルの増幅率にも比例する ということです。設定漏れが1つあると、その影響は人間1人の時より50倍速で表面化します。AI 駆動の利点は速度ですが、設定ミスや運用ミスも同じ速度で拡大します。
まとめ
AI 駆動開発で4日間に PR を83本出した結果、delete_branch_on_merge がデフォルトの false だったせいでマージ済みブランチが大量に残り、複数 AI エージェントを並走させた時に情報錯綜が起きました。
ここから得た教訓は3つです。
- AI 駆動開発の量を見積もる ─ 1人で50〜80本/週の PR は普通に発生する
- リポジトリの状態は AI の入力情報 ─ リポジトリが汚染されると AI の判断も汚染される
-
delete_branch_on_merge: trueをプロジェクト最初の30秒で入れる ─gh repo edit一発、もしくは Web UI のチェックボックス1つ
AI 駆動開発に踏み込むエンジニアは、速度の利益を享受するために、リポジトリ管理が追いつく初期設定を最初に整える という習慣を身につける価値があります。私はこれを1度失敗してから学びました。あなたが先に学んでくれれば、その分だけ早く速度を活かせます。