AIエージェントを複数走らせれば、モジュール移行もあっという間に終わるはずだ——私も最初はそう高をくくって、作業を配分したことがありました。しかし、いざ蓋を開けてみると悲惨な光景が待っていました。同じコードを2台のAIが同時に書き換え、お互いの変更を上書きし合い、手動で解きほぐすハメになったのです。「任せすぎると迷走するし、細かく分けすぎれば確認が増えて進まない…」。そう頭を抱えた夜は一度や二度ではありません。複数AIによる並列開発は、台数を増やせばスピードが上がる単純な足し算ではないのです。境界の引き方を一歩間違えれば、その代償は最後の「統合」の段階で、恐ろしいほどの競合とバグとなって跳ね返ってきます。
並列化の単位はAIの数ではなく「コードの依存関係」で決める
「AIが3台いるから12個のモジュールを4個ずつ分けよう」という均等な割り振り方は一見効率的ですが危険な発想です。見るべきなのは「誰がいくつ担当するか」ではなく、「どの変更とどの変更が裏で繋がっているか（依存関係）」です。干渉しない独立した部屋を同時にリフォームするなら並列作業ができます。しかし同じ水道管や電気配線を共有しているなら、同時に作業すれば水漏れや停電が起きますよね。移行時はコード全体の繋がりを調べ、独立した部分だけを別々の場所でAIに同時に進めさせます。強く依存し合う部分は無理に同時実行してはいけません。作業の質を保てる粒度を見極める必要があります。ソフトウェア工学でも「将来変更されやすい設計判断は、他の部分から隠せる場所に境界を置く（情報の隠蔽）」ことが鉄則とされてきました。また技術的依存が調整負荷に直結するという知見もあります。台数という数字に惑わされる前に、まず「依存の地図」を描くこと——これが失敗を防ぐ出発点です。
最初に「変更の地図」を作り、タスクを三つの道へ分類する
依存関係を把握するにはファイル名の一覧をぼんやり眺めるだけでは不十分です。変更が触れる対象――公開API、DBの構造（スキーマ）、設定ファイル、生成物、呼び出し順序――を書き出し、関係性を線で結んだ「変更の地図（依存グラフ）」を作ります。手順は4ステップです。まず変更対象と理由を列挙し、共有ファイルやAPIを線で繋ぎます。そのうえで「単独でテストできるか？」「約束事（契約）を先に決めれば切り離せるか？」を確認します。最後に解きほぐせない強い依存関係が残った場合は実行順に並べ、人間が統合責任者として必須チェックと作業中止条件をセットしておきます。この準備により作業は「並列にできるもの」「契約を先に決めれば並列化できるもの」「直列に進めるしかないもの」の3つの道に自然と整理されます。AIを当てる前にこの分類を終わらせておくことが、統合時の事故を防ぐカギとなります。
共有APIやデータベースは「先に約束事を固める」か「1台ずつ進める」
2台のAIが同じ公開APIやDB構造、共通設定を同時に書き換える状態は避けなければなりません。片方のAIが仕様を変えただけで、もう片方のコードが一瞬で動作不能になるからです。家電を作る会社とコンセントを作る会社が、連絡をとらず勝手にプラグの形をデザインしているようなものです。ただし、この危険な依存関係も「共有部分の約束事（インターフェース契約）」を一番最初にガチッと固めてしまえば、安全な独立作業へ化けさせることができます。実務でも仮の定義やダミーの応答（スタブ）を先に用意し、変更を積み重ねていく手法が知られています。HTTP APIなら言語非依存の明確な仕様書を最初に書いておけば、2台のAIは同じルールを参照しながら迷わず作業できます。「既存を壊さない（後方互換）」の線引きを組み込んでおけば安全な追加か破壊的変更かを機械判定しやすくなります。事前約束を決められない不確定要素が多い変更なら無理に並列化せず「1台のAIで順番に処理する（直列化）」という判断を下す勇気が不可欠です。
Git worktreeで作業部屋を分けても「論理的な衝突」は防げない
AI同士のコード上書きを防ぐ手段として、Gitの機能（git worktree）でAIごとに個別の作業フォルダを用意することは有効な備えです。同じファイルを同時に書き換えて物理破損する事故は防げます。しかし作業フォルダを分けたからといって「意味や論理のバッティング（競合）」まで自動で消えるわけではありません。たとえ別の部屋で作業していても一方のAIが関数の意味を変えてしまえば、もう一方の処理は崩壊します。実際、私自身も1つの画面に機能を詰め込んで移行しようとした際、2台のAIが中で絡み合って混乱する恐怖を感じ、画面そのものを2つのページに切り分けて開発を進めた経験があります。ただしこれは厳密な実測値というより現場の肌感から選んだ設計上の仮説として扱うべきものです。作業場所を物理的に分けたことと、変更の意味が本当に独立しているかどうかは、別の問いとして人間が慎重に検証しなければなりません。
バラバラに作ったコードは「たった一つの責任点」で統合テストする
それぞれのAIが「テストが通りました！」と報告してきたとしても安心してはいけません。それは「そのAIの担当範囲内で矛盾がない」と言っているに過ぎず、全体を繋ぎ合わせたときに正常に動く保証はないからです。バラバラのパーツを一つに合体させるときは、必ず全体を見渡せる人間が調整役となりシステムの整合性をチェックする工程が欠かせません。計画や複数結果の統合、難しい判断、最終確認は単純作業より重要度の高い工程として扱うべきです。ここで現場で使える「統合直前のチェックリスト」を共有します。①最新のメインコードへ追随しているか、②共通APIやデータの約束事テストが通っているか、③局所テストだけでなく全体の回帰テストが通っているか、④設定や権限、生成物、DB更新の順序を確認したか、⑤競合解消後の差分を再度レビューしたか、⑥失敗したときの切り戻し手順と担当者が決まっているか。自動化ツールは確認の場を用意するだけで、最後の合格サインを出す覚悟までは肩代わりしてくれません。統合の採否をどこか一つの責任点に集めるという判断は自身の設計判断として下すものです。
時計の針の速さではなく「トータルにかかった総コスト」で評価する
並列化が成功したかを「作業時間が半分になったか」という経過時間だけで評価するのは危険です。一度に任せすぎて生成がうまくいかなかった経験があるように、分割にはやり過ぎの失敗もあります。一方で複数AIを同時に動かす価値は単なる時間短縮だけでなく「複数の検討結果を突き合わせることで成果物の質を上げられる」点にもあります。だからこそ評価は経過時間だけでなく、AIごとの作業時間、人間の調整・レビュー時間、競合解消件数、差し戻し件数、統合後の不具合件数、再利用できた契約やテスト数まで含めた「総完了費用（トータルコスト）」で見るべきです。技術的依存管理が生産性や不具合に関係するという知見や、変更の粒度がレビューのしやすさに影響するという知見もこの考え方を支えています。速く終わったように見えても、調整や差し戻しに時間を取られていれば並列化の成功とは言えません。
移行対象をAIへ配る前に、まず共有契約と依存の線を1枚の図に書き出し、独立してよい部分、契約を先に固定すべき部分、直列にするしかない部分の3つへ分ける。これが、AIの台数を先に決めるより優先すべき最初の一歩になります。静的なコード依存と実行時の依存をどう1枚の図に統合するか、AIが提案する境界の誤りをどこまで許容するか、統合の採否をどこまでAIに委ねられるかは、まだ自分の中で答えの出ていない問いとして残っています。
