はじめに：エージェントを増やすとコードはどう変わるのか
コーディングエージェントに大きな実装を任せると、一つの迷いにぶつかります。一つのエージェントへ最後まで任せるのか。人間の開発チームのように、計画、実装、レビュー、品質保証へ分業させるのか。
分業すれば並列化と別の視点を期待できます。しかし、同じモデルを増やすだけで本当に違いは生まれるのでしょうか。責任の分け方が、技術選定、コードの境界、テスト、品質、次の変更コストをどう変えるか確かめました。
実験すると、エージェント同士の仕事の分け方とつなぎ方を変えただけで、ソフトウェアの構造まで変わりました。採用する技術、コードを分割する境界、テストの量が変わり、同じ要件とモデルを渡したとは思えないほど別のソフトウェアができあがりました。
どんな組ませ方がどんなコードを生むのかを、実時間、SVG、Webの順に見ていきます。
実験の前提：5種類のエージェント構成を同じ条件で比較する
比較したのは5構成です。Singleは一つのエージェントが完結し、Worker-Reviewerは実装後に独立レビューを挟みます。Orchestrator-Workerは実装を並列化します。Plan-Dev-QAは計画、開発、品質保証を段階化し、Accepter-Workerは受入結果から実装を戻します。
この記事では、この仕事の分け方とつなぎ方を「トポロジー」と呼びます。
全構成でモデル、推論設定、権限、時間上限をそろえました。変えたのは、タスクを誰が分解し、誰が実装し、誰が完了を判断するかです。
技術スタックは固定せず、各構成に選ばせました。責任の分け方が技術選定まで連鎖し、最終的なコードをどう変えたかも比較に含めます。
課題は、大判の編集可能なテーマパーク設計図と、Portal、Console、API、SQLite、認証、シミュレーター連携を含むWebアプリです。
Web課題の成果物例（Plan-Dev-QA）。来園者向け画面と運営者向け画面を、共通のAPIと永続状態で接続しています。
評価は候補名を隠した直接対決です。SVGはビジネスコンペ、Webは機能、テスト、セキュリティ、保守性、実装完全性で採用候補を決めました。偏りが見つかった画面評価はWebの順位から外しています。
全構成へ同じSQLite製バックログ、SVGを画像で見るスキル、Webを実ブラウザで操作するスキルを渡し、成果物を観測して修正できる条件もそろえました。
実験のソースは以下のGitHubリポジトリにアップロードしています。
仕事の分け方は品質を作り込むタイミングを変えた
同じ条件で5構成を動かすと、最初に差が表れたのは単純な速さではなく、それぞれが「どこまでできたら完成と呼ぶか」でした。動くものができた時点で提出する構成もあれば、独立した品質保証を通過するまで提出しない構成もあります。
つまり「分業すれば速くなる」でも「分業すると遅くなる」でもありません。品質を最初の提出前に作り込むのか、提出後の改善で積み上げるのかが構成によって変わるという結果になりました。
初回実行の終了を「初回提出」とし、それ以降を「改善」としました。これは同じ完成度への到達点ではなく、各構成が自分の手順を終えて最初に「完成」と判断した地点です。Plan-Dev-QAでは計画、開発、統合、QA、再作業、最終QAまでを含みます。
WebではPlan-Dev-QAの初回提出だけが遅く見えます。しかしバックログの時刻を突き合わせると、統合済みアプリへ到達したのはWorker-Reviewerの初回提出とほぼ同じタイミングでした。
Plan-Dev-QAはそこで提出せずQAへ渡しました。QAは統合後の成果物から欠陥を起票し、修正と最終QAが終わるまで提出を止めています。この品質ゲートに使ったのが約24分です。
最終提出までの実時間も、Worker-ReviewerとPlan-Dev-QAでほぼ同じでした。Plan-Dev-QAは遅かったのではなく、提出後に行うはずの改善を提出前へ移していたのです。違いは実装速度より、どの品質ゲートを通過して「完成」と呼ぶかにあります。
SVGではSingleが初回提出も最終提出も最速でした。全体を一つの文脈で扱う課題では、役割を増やして品質保証を前倒しする利点が小さく、Singleの短い改善ループがそのまま待ち時間の短さにつながっています。
仕事の分け方は開発時間を消しません。動く成果物を早く返すか、独立した品質保証を通してから返すかを変えます。 初回提出時点は匿名評価していないため、同じ品質への到達速度ではなく、品質投資を置いた時期として読みます。
目的関数がシンプルならSingleで改善ループを回す
時間の使い方が違うなら、次に見るべきは、その時間が何を生んだかです。まず、全体整合性が品質を決めるSVGから見ます。
一枚のマスタープランでは、施設を正しく置くだけでなく、情報階層、園路、線幅、凡例、余白を一つの構図にする必要があります。こうした「全体として良いか」が重要な課題ではSingleが強い結果になりました。
SVGもコードです。座標系、園路、ラベル、凡例は大域的な状態を共有します。責任を分ければ、コードの所有範囲と一緒に全体を見る文脈も分断されます。
同じ課題、同じ表示条件で生成した5成果物を並べます。園路の接続、線幅、情報密度、右側の情報欄までを一つの構図として見てください。
Singleは中心から各エリアへの動線、施設ラベル、右側の情報欄が一つの視線移動としてつながっています。ほかの構成には局所的に華やかな表現がある一方、通路や情報密度にばらつきが出ました。「自分の担当は正しいが、一枚の図としては落ち着かない」状態です。
Singleの強みは、同じ文脈のまま要件確認、実装、画像での観測、修正を繰り返せることです。Accepter-Workerとの直接判定では6回中5回採用されました。
目的関数が単純で全体整合性が重要なら、一つのエージェントに改善ループを所有させる方がよいです。Singleはコード全体を一つの最適化単位として扱えます。
目的関数が競合するなら責務ごとにエージェントを分ける
SVGでは文脈を分けないことが強みでした。ところが、複数の境界と品質目標を同時に扱うWebでは結果が逆転します。
Web課題ではPlan-Dev-QAの圧勝でした。機能、テスト、セキュリティ、保守性、実装完全性を比べた匿名評価で、ほかの4構成との全判定に勝ちました。
各組み合わせは表示順を反転して判定しました。それでもPlan-Dev-QAだけが全相手に勝っています。
Webアプリでは画面だけでなく、API契約、認証、永続状態、シミュレーター連携、異常系、保守性を同時に成立させます。Plan-Dev-QAは競合する品質目標を計画、実装、品質保証へ分けました。
全候補で受け入れテストは成功しました。それでも、テストの観測対象、認証境界、変更を閉じ込めるモジュールには差があります。直接対決から理由を見ます。
比較1：Single vs Worker-Reviewer
SingleとWorker-Reviewerの直接対決では、両反復ともWorker-Reviewerが採用されました。表示順を反転しても結果は変わっていません。
Worker-Reviewerは、複合絞り込み、FavoriteとMy Dayの永続化、管理画面の更新がシミュレーターとPortalへ届くことをSingleより直接的に検証しました。実装者の完了判断を別の視点から疑えた差です。
ただし、一つの成果物ではフォーカス保持を確かめるため、固定待機を繰り返していました。
await todayShowAdd.focus();
await page.waitForTimeout(4_500);
await expect(todayShowAdd).toBeFocused();
await search.pressSequentially("スカイワード");
await page.waitForTimeout(4_500);
await expect(search).toBeFocused();
固定待機は実時間と不安定さを増やします。Reviewerは局所欠陥を見つけても、実装前にAPI契約や認証境界を決める役割ではありません。
バックログでもSingleはほぼ一本道ですが、Worker-Reviewerは完成後の欠陥を実装へ戻す改善ループを重ねています。
比較2：Worker-Reviewer vs Plan-Dev-QA
Reviewerを加えるだけでもSingleより品質は上がりました。では、その品質チェックを実装者の配下から外すと何が変わるのでしょうか。
Worker-ReviewerとPlan-Dev-QAの直接対決では、両反復ともPlan-Dev-QAが採用されました。ここでも表示順を反転した判定は同じです。
ReviewerとQAの専門性に大差はありません。両者とも、画面間の反映、モバイル、多言語、モジュール境界、テストの抜けを見つけました。Reviewerもブラウザで再現し、QAもコードを監査しています。
違ったのは役割名ではなく、実装者との接続です。
Worker Orchestrator
└── Reviewer ├── Planner
├── Developers
└── QA
Worker-ReviewerではWorkerがReviewerを呼び、指摘の採否と最終提出を握ります。実験でもReviewerが指摘を返し、Workerが採用分を代理起票しました。品質への異論は実装者を経由します。
Plan-Dev-QAではDeveloperとQAが同じOrchestratorに接続されます。QAは統合済み成果物を監査して自分で欠陥を起票し、OrchestratorがDeveloperへ戻します。DeveloperはQAの指摘を採否判断できません。
QAは後段の品質ゲートですが、実装者の配下ではありません。異論がOrchestratorへ直接届くことが重要です。
Plan-Dev-QAのテストは固定時間ではなく、Portalの値が変わるまで条件付きで待ちました。
const waitValue = portal.locator(".facility-card .wait strong");
await expect
.poll(async () => await waitValue.innerText())
.toMatch(/^\d+分$/);
認証境界にも差がありました。Plan-Dev-QAはセッショントークンを直接保存せず、SHA-256のダイジェストだけを保存しています。機能を完成させるDeveloperと、その完成を疑うQAを別々に接続したことで、完了の定義まで変わりました。
バックログでは、レビューから実装へ戻る紫のループと、Plan、統合、QAを分けた緑の流れが対照的です。
横軸は全タスクの初回完了順です。代表タスク以外もIDを駅のように並べました。Workerが代理起票した指摘は、説明文からReviewerの仕事として復元しています。
Worker-Reviewerのバックログは、完成後に見つけた問題を再開する流れが中心です。ReviewerはWorkerの改善ループへ差し込まれた外部視点であり、独立した品質ゲートではありません。
Plan-Dev-QAではPlannerが依存関係と境界を記録し、OrchestratorがDeveloper、統合、QAへ渡します。実装者がレビューを所有するか、実装と品質保証を別々に接続するかが両者を分けました。
比較3：Orchestrator-Worker vs Plan-Dev-QA
Worker-Reviewerとの差だけでは、Plan-Dev-QAの強みがOrchestratorによる分業そのものなのか、PlanとQAを独立させたことなのかを切り分けられません。そこで、同じくOrchestratorが並列実装を束ねるOrchestrator-Workerと比べます。
Orchestrator-WorkerとPlan-Dev-QAの直接対決でも、両反復ともPlan-Dev-QAが採用されました。
Orchestrator-WorkerはAPI、Portal、Consoleを分けて並列実装しました。しかし、領域をつなぐセッション、時刻、状態、通信契約は、統合時にOrchestratorが検証してWorkerへ戻します。
実際の成果物にはセッショントークンをSQLiteへ直接保存する実装と、My Dayの待ち時間にシミュレーターではなくカテゴリ別の固定値を使う実装が残りました。
コンポーネントが単独で動いても、境界をまたぐ不変条件が正しいとは限りません。Plan-Dev-QAは共有契約を先に置き、QAがシミュレーター、API、Portal表示を一つの条件として追跡しました。
Orchestrator-WorkerはPortal、API、Consoleの問題をWorkerへ戻し、再統合を繰り返しました。機能間の依存関係はありますが、計画と品質保証の独立レーンはありません。
Plan-Dev-QAにもOrchestratorはいます。違うのは、Planが技術選定と所有者を決め、QAが独立監査する点です。並列化ではなく、統合境界と不変条件を誰の仕事にするかが品質を分けました。
共有契約が固まり、Worker同士が同じ状態を触らないならOrchestrator-Workerの並列化が効きます。契約から作るWeb開発ではPlan-Dev-QAが勝りました。
考察
三つの直接対決から見えたのは、エージェントの人数や役割名ではなく、異なる目的を担う役割をどこへ接続したかがコードを変えるということです。その影響はレビューの流れだけでなく、技術選定と維持費にも及びました。
計画役と独立した品質保証役：背反する圧力を分ける
ReviewerとQAはどちらも動作とコードを調べました。違いは技能ではなく発言経路です。独立した品質保証とは、別のエージェントにレビューさせることではありません。実装者を経由せず、品質上の異論を意思決定者へ届ける構造です。
- 実装速度と機能幅に対して、欠陥発見と受け入れ検証を置きます。
- 局所的な画面品質に対して、API、認証、コンポーネント間の不変条件を置きます。
- 受入条件に対して、内部構造と保守性を置きます。
コードレビューと受け入れ検証は同じ役割でもかまいません。背反する目的関数ごとに独立したノードを立て、Orchestratorに衝突を解かせることが重要です。
トポロジーは技術スタックと責任分解を変える
責任の置き場所が変わると、それを支える道具も変わります。同じ要件でも、採用された技術スタックは分かれました。
| 構成 | フロントエンド | API | 責任分解の特徴 |
|---|---|---|---|
| Single | Vanilla JS | Flask | 小さい依存構成へ責任を集中 |
| Worker-Reviewer | Vanilla JS | FastAPI | 実装は比較的小さく保ち、後段のレビューで補う |
| Orchestrator-Worker | React・TypeScript | Express | Portal、Console、APIを担当別に分割 |
| Plan-Dev-QA | React・TypeScript | Fastify | 共有契約、共有UI、各アプリ、品質保証へ分割 |
複数の担当が契約を介する構成では、型付き共有契約とパッケージ境界が選ばれました。責任を集中する構成では依存と構成要素が減っています。
今回はトポロジーと技術スタックの効果を分離できていません。しかし、責任分解が技術選定を誘発したこと自体が結果です。トポロジーはコードを書く順番だけでなく、何を作るかまで変えます。
ReactとTypeScriptだけで高品質になるわけではありません。同系統の技術を選んだOrchestrator-Workerとの直接対決でも、境界と検証責任の差が出ました。
品質保証は無料ではない：テストを量産する前に考える
責任境界をコードに埋め込めば、品質は上がります。ただし、その境界は次の変更で読み直す対象にもなります。AIはテストを安く書けますが、安く所有できるわけではありません。
Plan-Dev-QAは本番コードが約1割増えた一方、テストコードは約7割増えました。品質保証を厚くした結果、共有契約とテストが大きくなっています。
同じ変更を加えたとき、Plan-Dev-QAが読み込んだ入力トークンはWorker-Reviewerの約2倍でした。一方で実時間の差は小さく、負担は待ち時間よりも読み直すコードと文脈の量に表れました。
テストと共有契約は境界を明示しますが、変更者が読む対象も増やします。AI時代のテストは無料の安全網ではなく、ワンクリックで増やせる負債です。
頻繁に作り替える画面まで共有契約と独立QAで固めれば、品質保証が変更を妨げます。失敗コストが大きく安定した境界にはPlan-Dev-QAを使い、変化の激しい場所はSingleで回すのが実務上の境目です。
限界と次に確かめること
ただし、この使い分けを普遍的な正解とするには実験範囲が狭すぎます。
- SVGは3反復、Webは2反復で、一つのモデルと二つの課題に限られます。
- 受け入れテストは候補自身が実装しており、その設計も評価対象です。
- 偏りがあった画面評価は構成間比較から外しました。
- トポロジーと技術スタックの効果は分離できていません。
- WorkerがReviewerの指摘を代理起票したため、作成者だけでは活動量を比較できません。
次はWebの反復数を増やし、技術スタックを固定して責任分解だけを変える必要があります。
まとめ：トポロジーはコードを生成するアーキテクチャ
限界を踏まえても、エージェントの接続構造が成果物に痕跡を残したことは明確です。Singleは全体を一つの文脈へ集め、Worker-Reviewerは修正ループを増やし、Orchestrator-Workerは機能境界を増やしました。Plan-Dev-QAは共有契約とテストを積みました。
Web品質はPlan-Dev-QAが最も高くなりました。ただしテストと共有契約が増え、変更時の入力トークンはWorker-Reviewerの約2倍になりました。品質保証は無料ではありません。
全体整合性が重要ならSingle、複数の境界と競合する品質目標を扱うWeb開発ならPlan-Dev-QAです。品質を変えるのは人数ではなく、実装する役割と異論を唱える役割をどこへ接続するかです。
エージェントの性能が上がり、動くコードだけなら単一エージェントでも十分ですが、商用サービスとして求められる品質を達成するためには、エージェントのトポロジーを設計するスキルが今後求められていくのかもしれません。