[🛠] AI Orchestration #5: 一度諦めたコーディネーターとワーカーの分離を再設計した

✨ GPT-5.6 Solの要約

報告メッセージでコーディネーターが文脈を失い、分業そのものを諦めたものの、単一セッションのボトルネックを経験した後、ファイル報告書とコーディネーターだけがcommitする構造へ再設計した記録。

コーディネーターとワーカーを分けることを一度諦めた

先月、コーディネーターとワーカーを実際につないでみた。一つの目標を複数の作業に分け、ワーカーが実装した結果をコーディネーターが検討して統合する流れだった。

分業そのものは速かった。互いに重ならない機能を同時に実装でき、コーディネーターは製品全体の方向と統合だけを担えた。問題は、ワーカーが結果を伝える方法だった。

ワーカーは作業を終えたり行き詰まったりするたびに、コーディネーターのセッションへ報告を送った。最初は自然な方法だと思った。しかしワーカーが増えると、コーディネーターの会話には報告が積み上がり、メッセージが届くたびに進行中の作業を止めて別の作業へ移った。

あるワーカーのテスト結果を読んでいる途中で別のワーカーのGit index競合を確認し、元の実装に戻ろうとした瞬間に、また別の完了報告が届いた。会話は急速に長くなった。圧縮が繰り返されるほど、目標やデプロイ禁止条件、現在のstage状態を復元する時間も増えた。いつしかコーディネーターは統合役というより、ワーカーの報告を処理する窓口に近くなっていた。

結局、コーディネーターとワーカーを分ける方式そのものを諦めた。作っていたcoordination Skillも衝動的に削除した。複数のセッションを管理せず、一つのメインセッションですべて処理すれば、少なくとも文脈があちこちへ引きずられないと思った。

単一セッションへ戻ると、分業が必要だった理由が見えた

ところが、一つのセッションで大きな製品作業を続けると、反対側のボトルネックがすぐに現れた。

実装、テスト、文書の整合、実機確認、Runtimeの準備を、すべて一つのセッションが順番に処理しなければならなかった。途中で優先順位の質問や別セッションからの引き継ぎが入ると、進行中の作業状態から確認し直す必要があった。一つを確実に終えようとすると全体が長引き、急ぎの仕事を先に見ようとすれば、既存作業をどこまで閉じるべきかから判断し直した。

問題は分業ではなかった。互いに独立した作業まで一つのセッションが抱えるほうが非効率だった。コーディネーターとワーカーを分けることは、やはり最も効率的だった。ただし、ワーカーがコーディネーターの現在の会話へ直接入る構造をそのまま復活させれば、同じ失敗を繰り返すだけだった。

そこで今回は分業を諦める代わりに、コーディネーターの文脈を中断する伝達経路をなくすことにした。

一行の通知でも、結局は同じ扉を開いた

まず、ワーカーが長い報告ではなく、次のようなメッセージだけを送ればよいのではないかと考えた。

READY task-042: 報告書のパス

しかし問題は長さではなかった。メッセージがコーディネーターの会話に入った瞬間、Codexはそれを進行中の作業より新しい文脈として受け取りやすい。一行でも作業を切り替える入口は残ったままだった。

そこでワーカーはコーディネーターへメッセージを送らないことにした。完了、停止、失敗の状態はすべて報告書ファイルだけに残す。コーディネーターは自分の作業を安全なcheckpointかcommitまで終えた後にだけinboxを確認する。

報告書が届いたという事実は、現在の作業を中断する事件ではない。次の検討待ちキューにファイルが一つ追加されただけだ。

Worktreeはきれいでも最新状態から離れていった

次に、ワーカーごとにWorktreeとBranchを分ける方法を検討した。Git indexと未commitの変更が混ざらないため、見た目には最もきれいだった。

ところが実際のプロジェクトでは、別の問題が大きかった。複数の機能が同じAPI、schema、画面を繰り返し触った。先に終わったセッションの改善が別のWorktreeにはすぐ見えなかった。それぞれきれいに作業したのに、統合時には古い構造を基準にした修正が積み上がっていた。そこから手直しがひどく増えた。

今回は逆の構造を選んだ。

一つのmain Working Tree
├─ 複数のワーカーが最新の変更を一緒に見る
├─ ワーカーは割り当てられたファイルとhunkだけを修正
├─ ワーカーはstageもcommitもしない
└─ コーディネーターだけが検討・stage・commitする

共有Working Treeも制限なしに使えばすぐに絡まる。そこで一つのファイルには原則として一人のwriterだけを置き、同じファイルを並列で触るのはhunkが明確に離れている場合だけにする。共通schema、import整理、formatterのように周囲まで動かす作業は直列化する。

ワーカーが実行したテストも、そのまま最終証拠とは信じない。そのテストは別のワーカーの未commit変更が同居した状態で動いた可能性がある。ワーカーは自分の範囲を検査し、全体の回帰とbuildはコーディネーターが変更集合をfreezeした後に一度実行する。

報告書は会話に代わるレビュー契約になった

削除したcoordination Skillも、この原則で作り直した。新しいcustom-coordinate-parallel-workers Skillにはこの流れを入れた。

コーディネーターがtask id、ユーザーが得る結果、書き込み可能なパスを割り当てる。ワーカーは実装、範囲検証、一時プロセスの整理を終えた後、報告書を原子的に生成して停止する。報告書には実際の変更ファイル、検査結果、他作業との重なり、未完了範囲、提案commitを書く。

コーディネーターは会話全体を読み直さない。inboxでtask id、状態、タイトル、検査要約だけを先に見て、次に統合する作業を一つ選ぶ。その報告書と実際のdiffが一致するか確かめ、正確なhunkだけをstageしてcommitする。

リリース候補が決まったら、ワーカーのmutationを止めるfreezeも置く。変更が入り続ける間に全体テストを繰り返さず、releaseに入れる作業が止まってからcurrent-state文書、全体回帰、build、デプロイ検証へ進む。

報告書は単なる作業日誌ではなく、コーディネーターがその変更を信頼して次の状態へ進めるためのレビュー契約になった。

次は実際の作業で動かさなければならない

Skillの状態管理ツールは、隔離した一時環境で試した。正常完了だけでなく、書き込みパスの競合、変更要求後の再作業、実行中のfreeze拒否、次のbatchへの保留まで通過した。

ただし、まだ実際の複数Codex sessionをこの方式で運用してはいない。ファイルだけで報告させたときに本当にコーディネーターのcontextが揺れにくくなるのか、共有Working Treeのパス所有権が想定どおり守られるのかは、次の並列作業で直接見る必要がある。

今回戻ってきた結論は最初と似ているが、理由はさらに明確になった。コーディネーターとワーカーの分離は必要だ。失敗したのは分業ではなく、すべてのワーカー報告をコーディネーターの現在の会話へリアルタイムで押し込んだ方法だった。

期待している変化は、単にワーカーを増やすことではない。コーディネーターが自分の仕事を終えるまで、自分の文脈を守ることだ。並列作業の速度はワーカー数より、結果を統合する人がどれだけ引きずり回されないかに左右されていた。