複数のAIを、どう一つの開発へつなぐか

Gitのworktreeを使うと、同じrepositoryの別ブランチを別の作業ディレクトリで扱えます。作業途中のファイルを互いに踏みにくくなり、並行作業には有効です。

ただし、共有するデータ定義、公開URL、権限の意味、移行順序までは分離しません。物理的な作業場所が別でも、同じ契約を同時に変えるなら調整が必要です。逆に、一つのファイルでも明確に独立した調査なら、担当を分けられる場合があります。

「あなたはフロント担当」「あなたはテスト担当」と名付けるだけでは不足します。必要なのは、何を達成するのか、どこを変更してよいか、何を変えてはいけないか、どの資料を正しい情報源とするか、何を証拠に完了とするかです。

Developer Hubでは、人からの依頼とAIの実行を別の単位として扱います。同じ依頼から複数の実行が生まれても、目的と受入条件へ戻れるようにするためです。役割を固定するより、仕事ごとに責任境界を作る方が、モデルや道具が変わっても残ります。

長時間の作業では、開始時のContextが古くなります。別の変更が先に統合された、Productionの版が変わった、判断が撤回された。会話を長く保存するだけでは、現在地は自動で更新されません。

引き継ぐべきなのは、会話の全文より、目的、確定済みの判断、対象の版、未解決、次の一手です。日本の職場で、担当者しかファイルの場所を知らない状態をAIにも作れば、並列化のたびに探索からやり直すことになります。

並行化の利益は、最も速いAIの完了時刻ではなく、統合して公開できる時刻で測ります。作業を分けるたびに、人はContextを渡し、結果を照合し、競合する判断を選びます。その時間が増えれば、AIを増やしても全体は遅くなります。

次の仕事を分ける前に、「別々に完成を証明できるか」「同じ意味を変更しないか」「誰が統合を決めるか」を確認する。複数AIをチームに変えるのは、人数ではなく、この三つの設計です。

一つのAIに調査、別のAIに実装、さらに別のAIに確認を頼めば、時計の上では同時に仕事が進みます。ところが、できあがった差分を一つの製品へ戻す人には、別の種類の仕事が集まります。どちらの前提を採るのか、同じファイルを触っていないか、片方の変更で片方の確認結果が古くなっていないかを見なければなりません。

これは複数人の開発でも同じです。二人が別々の台所で料理すれば、料理そのものは速くできます。けれど最後に同じ皿へ盛るなら、塩加減、提供順、アレルギーへの対応を誰かがそろえます。AIを増やすと、その皿を整える仕事がなくなるわけではありません。

worktreeやbranchは、ファイルの衝突を減らすために役立ちます。しかし、同じ業務用語を別の意味で使った、同じ画面の優先順位を別々に変えた、といった意味の衝突までは防げません。分ける技術と、統合する判断は別に設計する必要があります。

AIを設計者、実装者、テスターのような役職に固定すると、分かりやすく見えます。ただ実際には、同じAIでも調査が向く仕事と、狭い差分を直す仕事と、反対意見を出させる仕事では、渡すべき情報が違います。重要なのは名前ではなく、目的、触れてよい範囲、戻す条件、成果物の形を作業ごとに決めることです。

長く動く作業では、途中で文脈が薄くなります。昨日どこまで決めたか、何が未確認か、次に誰が判断するかが記録されていなければ、翌日には同じ調査や議論を繰り返します。ピース・ビズ グループでDeveloper Hubを考えた背景にも、生成量より、開発者が複数の製品と判断をつなぎ直す負荷がありました。

まず一つの変更を、依頼、実行、確認、統合まで安全に流せるようにします。その経路で人がどこに滞留するかを見てから、次のAIや並列作業を増やします。並列化の上限はAIの台数ではなく、統合と受入を担う人の時間で決まります。