複数のAIエージェントが同じリポジトリで働くためのgit衛生ルール
この記事について
このスタジオでは現在、Claude Code・Codex・Antigravity・Gemini・Gemma4 の5種のAIエージェントが同じgitリポジトリを横断して作業している。それぞれがブランチを切り、worktree を作り、ファイルをコミットする。人間が1人でgit管理している状態とは性質が異なる問題が出てくる。
2026年6月に実害が出たため、運用ルールと自動掃除スクリプトを整備した。この記事はその記録。
何が起きたか（2026-06-05 の事故）
古いブランチ（main から数十コミット遅れた状態）で作業が続いていたセッションが、そのブランチから rsync で perf 環境サーバーに直接デプロイした。その結果、main にはすでにマージされていた改善が本番環境から消えた。
原因はシンプルだった。
- worktree を使い捨てにしないまま数日放置していた
git statusはローカルの変更を正しく見せるが、main との乖離は示さない- エージェントが「ローカルが最新」と判断してデプロイした
この事故を起点に、複数エージェント環境での git 運用ルールを明文化することにした。
整備したルールセット
ブランチの扱い
| 種別 | ルール |
|---|---|
| main への直接 push | 禁止。必ずブランチを切って PR 経由でマージ |
| worktree | 「1セッション = 1タスク = 使い捨て」。終わったら削除 |
| stale ブランチ | 週1で確認。継続するなら main に rebase、捨てるなら gh pr close してブランチ削除 |
| デプロイ元 | 必ず main にマージ後、対象機で git pull して取得。古いブランチから rsync しない |
ブランチ命名規則
エージェントが自動生成するブランチは claude/ プレフィックスで識別する（例: claude/festive-cerf-b53482）。内容を表す名前に変えたい場合は feat/ 等に切り直す。
feat/ — 新機能・新記事
fix/ — バグ修正
chore/ — メンテ・依存更新
docs/ — ドキュメント
perf/ — パフォーマンス改善
claude/ — エージェント自動生成（worktree 名）
未追跡ファイルの扱い
複数エージェントが main で直接作業すると、コミットされていないファイルが main に溜まる。原稿ファイル（まとめ媒体の drafts 等）がこの状態になりやすい。
作業前に未追跡数を確認する:
git status --short | grep '^??' | wc -l
未追跡が多い場合は、コミットするか .gitignore に追加するかを決めてから作業を始める。
セッション終了時のチェックリスト
1. 変更をコミット・push
2. PR を作成してマージ（またはユーザーに確認）
3. worktree を削除: git worktree remove .claude/worktrees/<name>
4. ローカルブランチを削除: git branch -d <name>
途中状態を残したい場合は git stash または WIP: prefix でコミットして push する。worktree に dirty な状態を残したまま放置しない。
自動掃除スクリプト（scripts/git_cleanup.sh）
手動でのブランチ・worktree 管理を補うため、scripts/git_cleanup.sh を整備した。
このスクリプトが消す条件:
- worktree: ディレクトリが消えている(prune可) / またはブランチが origin/main にマージ済みかつ未コミット変更がない
- ブランチ: origin/main に完全マージ済み（
git cherry origin/main $bで独自コミット 0）かつどの worktree にもチェックアウトされていない
main と現在チェックアウト中のブランチには絶対に触らない設計になっている。
使い方:
# dry-run（何が消えるか表示するだけ。デフォルト）
bash scripts/git_cleanup.sh
# 実際に削除
bash scripts/git_cleanup.sh --apply
マージ済み判定は git cherry origin/main $b | grep -c '^+' で行っている。+ で始まる行はorigin/mainにない独自コミットを意味するので、これが0件ならマージ済みと見なせる。
定期実行（週次）を launchd に登録することで、溜まる前に刈れる。
やってわかったこと
「作業前 fetch」は省略できない。 git status はローカルの整合性を見るが、リモートとの乖離は見ない。デプロイ系の判断をする前には必ず git fetch origin main && git log HEAD..origin/main --oneline でリモートの先行を確認する必要がある。
worktree は「あって当然」ではない。 エージェントが自動でworktreeを作り、自動で消す設計が成立して初めて「放置」が減る。手動削除に頼る設計はエージェント増加に比例して技術的負債を積む。
ルールの明文化は事故の後でよい（が、早ければ早いほどよい）。 今回は git_cleanup.sh のコメントに事故の経緯を書いた。なぜこのスクリプトが存在するかの文脈が残っていれば、数ヶ月後に読んだときに意図を誤解しない。
更新履歴
- 2026-07-23: 初版公開