[🛠] コーディネーターとワーカーを実際につないでみた

✨ GPT-5.6 Solの要約

一つの目標を複数のWork Itemに分け、ワーカーに渡し、コーディネーターが検証して統合する流れを実際に動かした記録。

反復型ワーカーからWork Itemベースのワーカーへ

以前のデータ収集プロジェクトでも、ワーカーとコーディネーターを分けて使っていた。ただし当時のワーカーは、決められたgoalに従って同じbatchを繰り返し、コーディネーターは蓄積した結果を定期的に整理する役割だった。

今回は違った。自然言語で目標を渡すと、コーディネーターが完了条件とWork Itemを決め、各ワーカーにファイルと作業範囲を割り当てた。

-W- ワーカーは担当作業を終えて検証し、commitを引き渡した。-C- コーディネーターはその結果を確認して一つずつ統合し、全体の状態でもう一度確かめた。

ワーカーが増えると統合コストも増えた

流れ自体は単純だった。

目標を渡す
→ Work Itemに分ける
→ ワーカーごとに実行・検証する
→ commitを引き渡す
→ コーディネーターが確認・統合する
→ 全体の状態を再検証する

良かったのは、誰が何を担当するのかが明確になったことだ。一つの作業が失敗しても他の作業まで揺れず、結果もcommit単位で確認できた。

問題もすぐに出た。ワーカーを増やしすぎると報告が一気に押し寄せ、重複セッションまで生まれて管理がさらに複雑になった。並列だからといって、多ければいいわけではなかった。コーディネーターが扱える範囲で分ける必要があった。

この日は、OrchestratorとAcceptanceの基準、共通WorkflowとSkill、ワーカー・コーディネーターのセッション運用ルールも併せて整備した。

OpenClawで自動化したいこと

今日使ったセッション、Worktree、Branchをそのまま製品に再現したいわけではない。自動化したいのは、その裏にある判断だ。

• 目標をどこまで分けるか
• 誰がどの結果を所有するか
• 何を確認すれば完了とみなせるか
• 失敗したとき、どこから再開するか

OpenClawに必要だったのは、ワーカーの数よりも、成果の所有権、検証、再開地点を管理するコーディネーターだった。