AIに3つの修正を並列で任せた。最後の統合で帰れなくなった

金曜17時18分。翌週から始まる水族館の夜間イベントに向けて、予約システムの改修を終える予定だった。

残っていたのは、予約枠を10分だけ確保する処理、キャンセル待ちを繰り上げる処理、確認メールを送る処理だ。エンジニアは三つのAI作業へ分け、それぞれ別の作業場所で進めてもらった。

夕方には、三つとも「修正完了、テスト成功」と返ってきた。進捗を聞いた運営担当者にも「AIで並列に進めているので、今日中に確認できます」と伝えてある。予定より早く終われそうで、少し誇らしかった。

ところが、変更を一つに集め始めると手が止まった。

• 予約枠の修正は、予約状態にheldを追加している
• キャンセル待ちの修正は、従来の状態だけを前提に繰り上げ順を変えている
• 確認メールのテストは、予約確定の前にメールが送られる前提になっている

ファイル上の競合を直しても、三つを合わせた時に「誰の席が確保され、いつ確定し、どの時点でメールを送るか」が決まらない。どのAIも、自分へ渡された範囲では筋が通っていた。でも、三つをつないだ一人の利用者の流れは、誰も見ていなかった。

並列で速くなると言ったのは自分だ。ここで分け方を間違えたと言ったら、AIを使いこなせていないと思われるかもしれない。

そう考えると、相談より先に差分を手でつなぎたくなった。片方の状態名を残し、別のテストを合わせ、失敗するたびに条件を足す。18時を過ぎても、完了したはずの作業が減らない。むしろ、どの変更を信じてよいのか分からなくなっていく😵‍💫

ここで問題なのは、AIを同時に動かしたことではない。一緒に動く必要がある仕事まで、独立した仕事として渡したことだ。

三つの「完了」を足しても、一つの完成にはならない

複数のAIエージェントを並列で動かす仕組みは、珍しいものではなくなった。OpenAIのCodex appは、複数のエージェントが別々のスレッドとworktreeで同じリポジトリの作業を進められる。worktreeは、一つのリポジトリから複数の作業用ディレクトリを作り、別のブランチを同時に開けるGitの仕組みだ。

これはかなり便利だ。片方が調査している間に、もう片方がテストを書ける。作業中のファイルを互いに上書きせず、変更ごとの差分も見やすい。

ただし、作業場所が分かれていることと、仕事の意味が独立していることは別だ。

GitHub Copilot CLIの並列実行に関する公式文書でも、向いているのは互いに依存しない小さな作業だと説明されている。前の結果が出ないと次を決められない仕事は、並列にしても利点が出にくい。

今回の三つは、別ファイルを触るように見えた。でも、全部が「予約状態は何種類で、どの順番に変わるか」という同じ約束を使っていた。予約枠の修正が状態を増やせば、キャンセル待ちもメールも、その変更後の約束を読んでから作る必要がある。

ここを見落とすと、各作業のテストは成功しても、統合後の利用者は先へ進めない。ファイルの競合が出ない場合ほど、「きれいに統合できた」と思いやすいので厄介だ。

エンジニアがしんどくなったのは、技術的な競合だけではなかった。三つも任せたのに止まったことを、段取りの失敗として一人で引き受けようとした。だから「まだ統合できていない」と共有できず、夜まで黙ってつなぎ続けた。

でも、並列化は速さを約束する魔法ではない。分けた後に依存が見つかることもある。そこで止めるのは失敗ではなく、次に進む順番が見えたという報告だ。

分ける前に、矢印がある仕事を見つける

並列にできるかを見る時、ファイル数や画面数だけで分けると危ない。同じファイルを触らなくても、同じデータ、同じ仕様、同じ公開手順へ依存していることがある。

依頼を投げる前に、三つだけ確認したい。

同じ「正しい状態」を書き換えないか

まず、複数の作業が同じ決まりを変えないかを見る。DBの項目、APIの返し方、権限、料金計算、画面の状態遷移は、別ファイルに分かれていても一つの約束だ。

今回なら、予約状態を決める作業と、その状態を使うメール送信は独立していない。先に状態の種類と変わる順番を決め、その結果を次の作業へ渡す必要がある。

一方で、「現在の状態遷移を調べる」「既存テストの不足を洗い出す」「運用担当者へ確認したい質問を作る」は、結果を変えない調査なので同時に進めやすい。最初から実装を三つに分けるより、調査を並べてから実装順を決める方が早いこともある🔎

前の結果を待たないと、次を決められないか

次に、Aの結果を使ってBを作る関係がないかを見る。

予約状態を決める → キャンセル待ちの条件を直す → メールを送る時点を直す。この間に矢印があるなら、全部を同じ時刻に始めるより、最初の小さな決定だけ先に終わらせた方がよい。

順番が必要な仕事を無理に並べると、各AIは足りない前提を自分で補う。その補い方が偶然そろうこともあるが、そろわない時は統合する人が三つ分の前提を読み解くことになる。

「並列にしないと遅い」と焦るかもしれない。でも、待ち時間をなくすために、後で二時間つなぎ直すなら逆効果だ。10分で共通の決定を置き、その後を並べる方が、帰れる時間は読みやすくなる。

最後に同じ利用場面を通るか

最後に、複数の変更が一人の利用者の操作でつながるかを見る。

予約する、10分以内に支払う、期限切れになる、キャンセル待ちが繰り上がる、メールが届く。これは一つの流れだ。担当ファイルが別でも、公開判断ではまとめて確かめなければならない。

同じ利用場面を通る仕事には、最初から「統合後に誰が、どの順番で、何を見るか」を置く。これがないと、三つの作業報告を読んだだけで確認が終わりやすい。

AIへ渡すのは、作業だけではなく返してほしい結果

依存関係を見つけたら、並列にできる部分へ担当範囲を付ける。大事なのは、「ここを直して」と投げるだけでなく、何を変えてよいか、何を変えずに戻すかまで決めることだ。

たとえば、確認メールの作業なら次のように渡せる。

目的:
- 予約が confirmed になった後だけ確認メールを送る

前提:
- 予約状態の定義は変更しない
- held から confirmed への処理は別作業が担当する

変更してよい範囲:
- src/lib/server/mail/
- 関連するメール送信テスト

止まって確認すること:
- 予約状態やDB schemaの変更が必要になった時

返してほしいもの:
- 変更ファイル
- 実行したテストと結果
- 統合後に確かめたい未確認事項

ここで効くのは、変更範囲の狭さだけではない。「予約状態を変えたくなったら止まる」と書いたことだ。別の担当が持つ約束へ踏み込む前に、依存を表へ出せる。

さらに、全員へ同じ開始地点を渡す。どのcommitから作業したかが違うと、片方だけ古い仕様を見ていることがある。開始したcommit、共通の前提、担当範囲を短く残しておけば、統合時に何が古いかを追いやすい。

作業中に共通の仕様が変わった時は、そのまま各作業を走らせ続けない。「予約状態の定義を更新したので、いったんここで止める」と共有し、新しいcommitへ合わせてから再開する。途中まで進んだ量が惜しいと感じても、古い前提のまま完成させるほど、あとで読み直す差分は増える。

そして、返してほしいものには「成功したテスト」だけでなく、未確認事項を入れる。自分の作業範囲では確かめられなかったことを返せると、完了報告が過剰に見えなくなる。

もう一つ、最後に統合する担当も先に決めたい。これは三つのコードを手で直す係ではない。共通の前提がそろっているか、取り込む順番は合っているか、利用者の流れをどこまで確認したかを見て、公開できるかをチームへ伝える役割だ。名前がないままだと、気づいた人が夜に全部を抱えやすい。

AIが「完了」と言った時に見る証拠は、AIが完了と言った。そのまま閉じて大丈夫？ 人が見る3つの証拠でも整理している。並列作業では、その証拠に「どの前提とcommitで確認したか」を足すと、統合の順番を決めやすい。

統合は、最後にまとめて片づけない

金曜18時32分、エンジニアは手作業でつなぐのを止め、チームへ短く共有した。

三つとも個別のテストは成功しています。ただ、予約状態の前提がそろっておらず、統合後の流れは未確認です。今日は公開せず、状態の定義を先に決めてから、キャンセル待ちとメールを順に合わせたいです。

送信するまでは、「遅れを認めることになる」と指が止まった。でも、返ってきたのは責める言葉ではなかった。運営担当者からは、夜間イベントの予約開始を月曜午後へずらせると分かった。同僚からは、状態の定義を一緒に確認すると返ってきた。

抱えていたのは、コードだけでなく、「今日中に成功させた人に見られたい」という気持ちだった。でも、「個別のテストは通った。ただし、統合後は未確認だ」と今の状況をそのまま伝えると、取れる選択肢が増えた。

翌朝、まず予約状態の変更だけを統合した。自動テストを通し、予約枠が切れる場面を画面で確かめる。そのcommitを新しい開始地点にして、キャンセル待ちを合わせる。もう一度テストし、最後にメール送信を合わせた。

Gitの競合が出た時は、最終的にどの内容を残すかを人が選ぶ必要がある。競合が出なかった時も同じだ。コードが自動で一つになったことは、仕様まで正しく一つになった証拠ではない。

統合では、次の順番を守りたい。

1. 共通の約束を変える変更から、一つずつ取り込む
2. 取り込むたびに、自動テストと変更箇所を確認する
3. 次の作業を、更新後のcommitへ合わせる
4. 最後に、一人の利用者が通る流れを最初から確かめる

これなら、どの変更で崩れたかを追いやすい。全部を一度に集め、最後に失敗した時より、戻す場所もはっきりする。

大きくなった差分をレビュー前に分け直したい時は、AIで差分が膨らんだ。レビュー前に小さく切り直す勇気も使える。複数の結果をレビュー相手へ渡す文脈は、AIで作ったPR、「レビューお願いします」だけで投げてない？にまとめている。

明日から複数のAI作業を始めるなら、タスク名を並べる前に、紙へ矢印を一本だけ引いてみてほしい。「この結果が出ないと、次は決められない」と思う二つをつなぐ。矢印がある仕事は順番に進め、ない仕事だけを並べる。

AIを何個動かしたかより、戻ってきた変更をどの順番で一つにできるか。 そこまで決めて任せられる人は、実装の速さだけでなく、チームが安心して公開できる進め方も作れる🙂

参考にした情報

• OpenAI「Introducing the Codex app」（2026年2月2日公開、2026年3月4日更新、2026年8月24日確認）
• OpenAI「Introducing Codex」（2025年5月16日公開、2026年8月24日確認）
• GitHub Docs「Running tasks in parallel with the /fleet command」（2026年8月24日確認）
• GitHub Docs「Merge conflicts」（2026年8月24日確認）
• Git「git-worktree Documentation」（2.54.0、2026年4月20日更新、2026年8月24日確認）