2026.07.14 (火)
2026.07.16 (木) 更新

✨ GPT-5.6 Solの要約

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

以前のワーカーとは違った

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

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

コーディネーターとワーカーに分けて運用したCodexセッション

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

実際に動かしてみると

流れ自体は単純だった。

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

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

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

OpenClawで自動化したいこと

自然言語の目標を複数の実行主体に分けて処理し、検証するOrchestratorフロー

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

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

複数のAIを同時に立ち上げること自体は難しくなかった。難しかったのは、それぞれの成果を失わずに一つへまとめることだった。今日はその過程を人間が直接動かした。

カテゴリー: ,

更新日時:

コメントする