Claude Code 10本並行、1,138マージ失敗

構成は意図的に階層化されていた。人間が何を作るかを決め本番変更を承認し、インターフェースセッションが作業を中継し、オーケストレーターが実装せずにissueを仕分け・検証し、セッションA〜Gがそれぞれ自分のgit worktreeとブランチに住む。WindowsマシンがGitHub Actionsとデプロイ監視を担う。この構造は9月初旬のオーケストレーターと作業者2名だけの状態から、問題が現れるたびに現在の形へ育った。

何が壊れたかの記録は異例なほど具体的だ。作者不明のルールが要約に現れ、実際のマージを承認した。ドキュメントのみのプルリクエストがCIを飛ばしてmainを赤にした——存在しない4つのパスを含んでいたためだ。9月7日夜の5件の連続マージで4件のデプロイがキャンセルされジョブはゼロ——GitHub Actionsの並行制御は実行1件と待機1件しか保持せず、cancel-in-progress: falseも効かなかった。バックエンドはグリーン表示のまま本番より27コミット遅れていた——Docker Desktopが管理者パスワード待ちで、diffチェックが最後のプッシュしか比較していなかったためだ。5セッションがGitHubのアカウント全体レート制限を使い切り、空のエラー応答を「完了」と読んだ。.gitが1つしかないためworktree間で共有されるgit stashが、別の作業者の変更を破棄した。古いworktreeがmainに載っていた2つの機能を危うく巻き戻しかけた。毎日のチェックは再起動で消えるスクラッチパッドにあったため消滅した。2つのセッションがどちらも「orchestrator」と名乗って一覧に現れ、片方は実際には作業者Fだった。

本人の結論は、4つの原因ですべて説明できるというものだ。気づかれない共有資源、消える場所に置かれた重要物、不在と取得失敗の混同、誰が何を決めたかを確認しないこと。残るのはツールではなくいくつかの習慣——決定をコミットメッセージに記録する、要求された瞬間にissueを立てる、数字はその場で測る、オーケストレーターを実装から遠ざける、本番変更は実行直前に止める。9月27日のX投稿1件で1,348人が訪れ、その4人に3人は1問も解かずに離脱したとも記している。このファネルが、セッションを増やして壊れる分より速く直るかどうかが、この手法の真の試練だろう。