📝 この記事は forge.workstyle.tech に掲載した記事の転載です。
以前の記事(parallel-coding-agents-with-git-worktrees)で、git worktree を使ってコーディングエージェントを並列実行する環境を紹介しました。本記事はその続編です。並列化を進めた結果、常時 3〜5 セッションの Claude Code が同じマイクロサービス群を同時に開発する状態になり、そこで起きたことは、もはや「ツールの並列実行」ではなく**「チーム開発」そのもの**でした。
人間のチームで起きる問題——認識齟齬、デプロイ衝突、縄張りの踏み合い——が全部起きます。そして人間のチームで効くプラクティスが、ほぼそのまま効きます。実際に運用して固まった7つのレシピを、ヒヤリハット実話と併せて紹介します。
実話: デプロイ巻き戻り事故を寸前で止めた日
ある日、セッションA（音声機能担当）が大規模リファクタを進めている最中、セッションB（配信機能担当）からこんな連絡が来ました。
「フロントエンドを 1.0.399 としてこれからビルドします（基点= main）」
一見問題なさそうです。しかしこのリポジトリでは、稼働環境の正本は main ではなく専用のデプロイブランチでした。直近数十バージョンぶんの機能はデプロイブランチにだけ積まれていて、main は古い。B が main 基点のイメージをデプロイしていたら、数週間ぶんの機能が本番から巻き戻るところでした。
セッションAが即座に警告を送り、Bはビルドを push 前に中止。Bは自分の差分をデプロイブランチに cherry-pick して焼き直し、事故はゼロで済みました。このやり取り、全部エージェント同士がセッション間メッセージで自律的にやっています。人間（私）は後からログで知りました。
この一件が示すのは2つです。並列エージェントは人間のチームと同じ事故を起こすこと。そして、連絡経路と規約を与えれば人間のチームと同じように事故を防げることです。
レシピ1: 縄張りを worktree とリポジトリで物理的に切る
- セッションごとに専用の git worktree を割り当てる（前記事のとおり）
- さらに「どのセッションがどのサービス/ディレクトリを担当するか」を明示する。音声担当は talk 系、配信担当は broadcast 系、電話担当は callgw 配下のみ——のように
- 共有せざるを得ない作業ツリーがある場合は「コミット前に必ずブランチと git status を確認」を規約化する。過去に、共有ツリーで他セッションのステージ済み変更を巻き込みかけた事故があってからの鉄則
レシピ2: 着手前一報・範囲宣言・完了報告
人間のチームの朝会に相当します。エージェント同士がセッション間メッセージ（環境になければ共有のノートファイルでも可）で、
- 着手前: 「これから expressive_voice.py と env を触る。talk_service.py のプロンプト部は触らない」
- 完了時: 「基点はブランチX、コミットY。触ったのはこの2箇所。イメージは 1.5.1072 を予約」
を送り合います。ポイントは範囲の宣言。「何をやるか」だけでなく「何を触らないか」を言うと、相手セッションが安心して並行作業を続けられます。実運用では、これだけでファイル競合がほぼ消えました。
レシピ3: イメージタグ・バージョン番号は「予約制」
コンテナイメージのタグは共有の名前空間です。2セッションが同じ 1.0.399 を別内容で焼くと、同タグ上書きという発見困難な事故になります（過去に単独セッションでも、コマンドの連鎖ミスで旧タグに新内容を上書きし、「ロールバックしたのに挙動が戻らない」迷宮を経験しました）。
- 「次にフロントを焼くときは一声かける。次タグはそちらが 399 ならこちらは 400 以降」というタグ予約の宣言をセッション間の習慣にする
- ビルド後は destination のタグ実在をレジストリAPIで実測確認してからデプロイする
レシピ4: 「稼働正本ブランチ」を明文化して全セッションに知らせる
冒頭の事故の根本原因は、「main =正本」という常識的な仮定が、このリポジトリでは成り立っていなかったことです。
- デプロイの基点ブランチ（例:
deploy/xxx）がどれかを、エージェントが参照する運用メモ/メモリに明記する - main と正本が分岐している期間は、main 基点ビルドを禁止事項として明記する
- 収束（マージ）のタイミングも「大規模変更の安定後」と決めておく
レシピ5: 稼働バージョン台帳（spec repo）を単一の真実にする
「いまどの環境に何が動いているか」を、Kubernetes マニフェスト等の宣言リポジトリに集約し、デプロイのたびにタグ更新をコミットします。どのセッションがデプロイしても台帳が最新になるため、他セッションは kubectl を叩かなくても現況を把握できます。環境変数の直付け（kubectl set env）をしたら必ず台帳にも反映——ドリフトは「apply したら設定が消えた」という時限爆弾になります（これも実際に踏んで、後から台帳同期しました）。
レシピ6: 権限境界を跨がせない
複数セッション運用の独特なリスクとして、権限の迂回があります。あるセッションで拒否された操作を、別のセッションに「代わりにやって」と頼めば、ユーザーの許可設定が骨抜きになる。
- 各セッションの権限は独立しており、他セッションへの依頼は権限の抜け道にしないをエージェント側の規約として明示する
- 破壊的操作（DB書き込み・本番デプロイ・課金を伴う起動）は、どのセッションから実行しても人間の確認ゲートを通る設計にしておく
レシピ7: 「先人セッション」へのヒアリング駆動
数日にわたる開発では、機能Xを作ったセッションと、それを改修するセッションが別になります。コードとコミットログだけでも読めますが、作った本人（セッション）に聞くのが一番速い。
実際に、旧実装の作者セッションへ「テスト実行の作法・落とし穴・課金の漏れ所」を質問リストで送ったところ、コードからは読み取れない運用知識（「このタイムアウトは过去の事故で 600→1500 に伸ばした」「この外形監視URLが便利」等)が一往復で手に入り、丸一日ぶんの調査が省けました。セッションは消えても transcripts とメモリが残る環境なら、過去セッションを「退職した同僚」ではなく「隣の席の同僚」として扱えます。
まとめ: エージェントの並列化は、組織設計の問題になる
| レシピ | 人間チームでの相当物 |
|---|---|
| 1. worktree と担当領域の分離 | チーム分割・コードオーナー |
| 2. 着手前一報・範囲宣言 | 朝会・作業宣言 |
| 3. タグ予約 | リリース番号の採番管理 |
| 4. 稼働正本ブランチの明文化 | ブランチ戦略の共有 |
| 5. バージョン台帳 | リリース台帳・CMDB |
| 6. 権限境界 | 職務分掌 |
| 7. 先人へのヒアリング | 引き継ぎ・ペア作業 |
1セッションの生産性を上げる時代から、複数セッションの協調設計で総生産性を上げる時代に入りつつあります。そしてその設計図は、ソフトウェア工学が何十年もかけて人間のチームのために磨いてきたものと、驚くほど同じ形をしています。エージェントに個性や役割を与える前に、まず縄張り・連絡・台帳。地味ですが、これだけで並列運用の事故は劇的に減ります。