AIコーディングを並列化するなら、エージェントの人数より先に「ぶつからない作業面」を用意する。
OpenAIが公開したAsanaの事例によると、同社はフロントエンド更新の障害になっていたテスト基盤Enzymeの撤去を、約2週間で完了しました。従来計画は少なくとも5年、約600万ドル相当。今回のモデル・インフラ費は約1万2,000ドルだったと報告されています。
ただし、これはAIが5年分の開発を自動で終えたという一般論ではありません。成功の核心は、機械的に分けやすい移行を選び、最大4体を別々のコードベースで動かし、人間が全変更をレビューした運用設計にあります。
何を2週間で終えたのか
対象は新機能開発ではなく、React向けテストツールEnzymeの撤去です。OpenAIの公式事例によると、EnzymeはAsanaのフロントエンド更新を妨げる技術的負債になっていました。
Enzymeの公式リポジトリを見ると、公式アダプターの対応表はReact 16までです。つまりAsanaの仕事は、仕様が固まっていない探索ではなく、既存テストを読み、置き換え、動作確認する反復型の移行でした。AIエージェントが得意な「似た変更を多数のファイルへ一貫して適用する」仕事と相性がよい領域です。
実績の数字は、次のように読む必要があります。
- 完了期間：1.5週間分のエンジニア作業量を、暦の2週間で実施
- 並列数：最大4体のコーディングエージェント
- 費用：モデルとインフラで約1万2,000ドル
- 比較対象：従来計画は少なくとも5年、約600万ドル相当というAsanaの見積もり
600万ドルから1万2,000ドルへの単純比較は魅力的ですが、同じ条件の実測対照試験ではありません。従来計画の見積もりと、今回の直接費を比べた事例値です。人間の設計・監督・レビュー費までゼロになった、という意味ではありません。
設計1：エージェントごとに作業面を分ける
Asanaは最大4体を、それぞれ別のコードベースのコピーで動かしました。ここが重要です。同じ作業ツリーを共有すると、同じファイルの編集、依存関係の更新、テスト生成が衝突し、速さより調整コストが増えます。
実務では、次の単位で隔離すると扱いやすくなります。
- エージェントごとにブランチまたはworktreeを分ける
- 担当範囲をディレクトリ、パッケージ、変更パターンで切る
- 共通設定ファイルの変更は一つの担当へ集約する
- 成果物は直接マージせず、PRとCIを通す
並列数は性能ではなく、衝突しない仕事の数で決めるべきです。4体を動かせることより、4つの独立した変更単位を作れることの方が先です。
設計2：長い指示書より、判定可能なゴールを置く
Asanaの事例では、出発点は5文のプロンプトで、複雑な設定より簡潔な指示の方がうまく機能したとされています。
ここで「短いほどよい」と一般化するのは危険です。短くできた理由は、ゴールが明快だったからです。Enzymeをなくす、既存の振る舞いを保つ、テストを通す。終了条件を機械的に判定できます。
OpenAIのCodex活用ガイドも、大規模変更では先に実装計画を作り、GitHub Issueのようにファイルパス、対象コンポーネント、参考実装を示す方法を推奨しています。指示を短くする代わりに、リポジトリ側へ規約、AGENTS.md、参考パターンを置き、完了判定はテストに委ねる。プロンプトへ全部詰め込まず、環境を説明書にする設計です。
設計3：人間は生成量ではなく、統合点を管理する
この事例で人間は外れていません。エンジニアが1日2回進捗を確認し、提案された変更をすべてレビューしました。
AI導入前は「誰がコードを書くか」がボトルネックでした。並列エージェント導入後は、次の工程へボトルネックが移ります。
- タスクを衝突しない単位へ分ける
- 失敗した変更を早く検知する
- PRの依存順序を決める
- 最終的な動作と保守性を人間が承認する
したがって、エージェント数だけを増やすとレビュー待ちが膨らみます。人間が確認できるPR数、CI時間、競合解消能力を含めて、仕掛かり上限を設定する必要があります。
車載開発にたとえると
これはECUソフトの一括置換にも近い構図です。複数チームが同じ統合ブランチを直接触れば、個々の実装が速くても結合で詰まります。
一方、対象コンポーネント、入出力、回帰試験、統合順序を先に固定すれば、作業を並列化できます。AIエージェントは高速な実装担当として働けますが、変更影響の境界と合否判定を作るのは依然としてPL（プロジェクトリーダー）の仕事です。
「4人を4倍速く働かせる」より、「4つの独立した検証可能な作業へ分ける」。Asanaの事例から持ち帰るべきなのは、この分解の設計です。
導入前チェックリスト
- 対象は大量の反復変更で、完了条件をテストで判定できるか
- 担当範囲を分け、同じファイルへの同時編集を減らせるか
- 各エージェントに独立したブランチまたはworktreeがあるか
- 共通設定、依存更新、マイグレーション順序の責任者を決めたか
- CI失敗、競合、レビュー待ちを可視化できるか
- 人間が全変更を確認できる仕掛かり上限になっているか
まとめ
- AsanaはEnzyme撤去を、最大4体のCodexと人間の全件レビューで約2週間で完了した
- 各エージェントを別のコードベースで動かし、編集衝突を隔離した
- 簡潔な指示が効いた背景には、判定可能な移行ゴールがあった
- 600万ドル対1万2,000ドルは、従来見積もりと直接費の比較であり、一般的な削減率ではない
- 並列化の上限はモデル数ではなく、独立タスク数と人間のレビュー能力で決まる
AIコーディングの速度を決めるのは、最も賢いモデルだけではありません。変更をぶつからない単位へ分け、機械で検証し、人間が統合できるハーネスです。