AI評価企業Vals AIは2026年10月9日、複数のAIエージェントをチームとして動かした場合、Webアプリ開発にかかる費用が単体構成の1.8〜5.1倍に増える一方、統計的に有意な品質改善が確認されたのは4条件中1条件だけだったと発表した。GPT-6 SolとClaude Opus 5.5を使い、50件のWebアプリ開発課題で性能を比較した事例研究だ。
ただし、チーム化によって開発時間が短縮された条件もあり、追加費用に見合う価値を品質だけで判断することはできない。複数のAIに開発を分担させる場合、完成品の品質を高めたいのか、開発時間を短縮したいのかによって、その効果を評価する必要がある。
50件のアプリを開発し、操作テストの通過率を比較
今回の実験では、製品仕様に基づいてWebアプリを一式開発するベンチマーク「Vibe Code Bench」を使用し、各モデルを単体構成とチーム構成で比較した。
推論に割り当てる計算量は「中程度」と「最大」の2段階に設定され、2モデル、2段階の推論設定、2種類の構成を組み合わせた計8条件で評価した。各条件では同じ50件のアプリ開発課題を、それぞれ1回ずつ実行している。
チーム構成では、リーダーとなるエージェントが最大5つのサブエージェントに作業を並列で割り当てられる。ただし、サブエージェントがさらに別のエージェントへ作業を委任することは認められていない。
完成したアプリは、実際にブラウザーで操作して評価された。スコアは、各アプリのUIテスト通過率を50件で平均したものだ。
Vals AIが公開している評価方法では、各テストを構成する操作の90%以上が成功すると、そのテストを合格と判定する。
そのため、スコアが90%だったとしても、「50件中45件のアプリが完全に完成した」という意味ではない。また、コードの保守性やセキュリティーなど、ソフトウェアの品質全般を保証する指標でもない。
Vals AIが公式ブログで公表した比較結果は次のとおりだ。
| モデル・推論設定 | 構成 | UIスコア | 1アプリ当たりの平均費用 | 実行時間の中央値 |
|---|---|---|---|---|
| GPT-6 Sol・中程度 | 単体 | 77.6% | 1.22ドル | 12.4分 |
| GPT-6 Sol・中程度 | チーム | 84.9% | 3.07ドル | 11.9分 |
| GPT-6 Sol・最大 | 単体 | 89.0% | 4.82ドル | 38.4分 |
| GPT-6 Sol・最大 | チーム | 90.4% | 8.54ドル | 27.6分 |
| Claude Opus 5.5・中程度 | 単体 | 91.5% | 4.08ドル | 20.3分 |
| Claude Opus 5.5・中程度 | チーム | 91.2% | 9.10ドル | 26.6分 |
| Claude Opus 5.5・最大 | 単体 | 89.8% | 23.77ドル | 74.7分 |
| Claude Opus 5.5・最大 | チーム | 93.2% | 約122ドル | 174.1分 |
※すべて同じ50件のアプリ開発課題で評価した。費用は平均値、実行時間は中央値であり、集計方法が異なる。費用の算出条件については後述する。
チーム化によって統計的に有意な改善が確認されたのは、GPT-6 Solの中程度設定だけだった。UIスコアは単体の77.6%からチームの84.9%へ7.3ポイント上昇した。
対応のあるt検定によるp値は0.005で、差の95%信頼区間はプラス2.3〜12.4ポイントだった。
一方、Solの最大設定では1.4ポイントの改善にとどまった。Opus 5.5では、中程度設定で0.3ポイント低下し、最大設定では3.4ポイント改善したものの、いずれも統計的に有意な差は認められなかった。
ただし、有意差が認められなかったことは、チーム化に効果がないと証明されたことを意味しない。
例えば、Opusの最大設定におけるスコア差の95%信頼区間は、マイナス1.4〜プラス8.3ポイントと幅がある。今回の実験だけでは、チーム化による改善の程度を十分な精度で判断できないことも示している。
費用増加の主因は、コード生成よりも大量の入力トークン
Vals AIによると、チーム化によって増えた費用の大部分は、キャッシュされた入力トークンの処理に伴うものだった。
各サブエージェントは、製品仕様や作業の進捗状況などを自身のコンテキストとして保持する。モデルを呼び出すたびに、こうした情報を再び入力する必要があるため、複数のエージェントが並行して作業すると入力トークンの総量が大きく増える。
プロンプトキャッシュを利用すれば入力処理の費用を抑えられるが、キャッシュから再利用するトークンも無料ではない。
特に顕著だったのが、Claude Opus 5.5の最大推論設定だ。
サブエージェント群が処理したキャッシュ入力は、1アプリ当たりの中央値で2億2400万トークンに達した。単体構成の5500万トークン、チーム構成のリーダーの1700万トークンと比べても、非常に大きな数字だ。
ただし、これは新たに生成したコードや文章の量ではない。モデルが繰り返し読み込んだ入力トークンの累計である。
また、各グループの中央値を単純に足しても、チーム全体の中央値にはならない点に注意が必要だ。
興味深いのは、モデルによってチーム内での仕事の進め方が異なっていたことだ。
GPT-6 Solのリーダーは、開発の早い段階で作業を分担し、完成した部分を自ら統合してテストする傾向があった。
中程度設定でスコアが20ポイント以上改善した9件のアプリでは、単体構成で実装されなかった機能をチーム構成が追加していた。また、画面の入力項目とデータベースの定義が一致していないといった問題を、リーダーが発見した事例もあった。
つまり、作業の分担と統合時の確認が、機能の実装漏れや不整合を減らす方向に働いていたと考えられる。
一方、Claude Opus 5.5は、各機能の間で必要となるインターフェースや仕様を先に文書化し、基盤の実装、機能の追加、テストという順序で段階的に作業を委任する傾向を示した。
Opusの最大設定では、最初のデプロイまでにかかった時間の中央値は、単体構成が51分、チーム構成が56.8分と大きく変わらなかった。
ところが、開発全体の完了時間は単体の74.7分に対し、チームでは174.1分に達した。
つまり、アプリを最初に動かせる状態にするまでの時間はほぼ同じでも、その後の工程がチーム構成では大幅に長くなっていた。
デプロイ後のテストに費やした作業時間にも大きな差がある。
各エージェントの作業時間を合算した延べ時間の中央値は、単体構成の9.6エージェント分に対し、チーム構成では67.8エージェント分だった。
これは複数のエージェントが費やした作業時間の合計であり、利用者が実際に待つ時間とは異なる。
チーム構成でテストに投入する作業量が大幅に増えたことは確かだが、それがUIスコアの統計的に有意な改善につながったとはいえない。
開発時間を短縮する価値と、品質向上の価値は別
今回の実験では、チーム化によって開発時間が短縮された条件もあった。
最も注目すべきなのは、GPT-6 Solの最大推論設定だ。
単体構成では実行時間の中央値が38.4分だったのに対し、チーム構成では27.6分となり、約28%短縮された。
これは、Vals AIが公表した数値から「（38.4−27.6）÷38.4×100」で算出したものだ。各構成の実行時間の中央値を比較した値であり、50件それぞれの短縮率を平均したものではない。
また、各条件の実行は1回だけなので、別の開発課題でも同じ割合で時間が短縮されるとは限らない。
この条件では、1アプリ当たりの平均費用が4.82ドルから8.54ドルに増えた。一方、UIスコアは89.0%から90.4%への上昇にとどまり、統計的に有意な改善は確認されなかった。
それでも、開発を早く終えることに価値がある場合には、追加費用を払ってチーム化する合理性がある。
例えば、開発者が次の作業に着手するまでの待ち時間を減らせれば、費用の増加以上の価値が生まれる可能性もある。
反対に、完成品の品質向上だけを目的とするなら、今回の結果はチーム化に追加費用をかける十分な根拠にはならない。
なお、平均費用の増加額を、実行時間の中央値の短縮分で割って「1分短縮するための費用」を求めるのも適切ではない。平均値と中央値という異なる統計量を組み合わせるうえ、個々のアプリにおける費用と時間の関係も反映されないためだ。
チーム化以外にも、単体エージェントに割り当てる推論量を増やすという選択肢がある。
GPT-6 Solの単体構成では、推論設定を中程度から最大に引き上げることで、UIスコアが77.6%から89.0%へ11.4ポイント改善した。この差は統計的にも有意だった。
しかし、最大設定の単体構成と、中程度設定のチーム構成を比較すると、前者のスコアは4.1ポイント高かったものの、統計的に有意な差はなかった。
その一方で、最大設定の単体構成は費用が約1.6倍、実行時間が約3倍になっている。
したがって、推論量を増やすことも、チーム化に代わる万能な方法ではない。
重要なのは、開発課題の性質によって、どの方法が最も効率的かが変わるという点だ。
Anthropicは2025年6月に公開したマルチエージェントシステムの技術解説で、複数のエージェントによる並列処理が効果を発揮しやすい仕事として、異なる方向から独立して情報を調べられる調査業務を挙げている。
一方、コーディングでは、調査業務ほど多くの作業を完全に独立させられないとも説明している。
例えば、Webアプリの画面とデータベースを別々のエージェントに実装させても、データの形式や機能の仕様が一致していなければ、統合時に修正が必要になる。
複数のエージェントを同時に動かせるからといって、必ずしも全体の作業時間が短くなるわけではない。
また、Anthropicの技術記事には、マルチエージェントシステムのトークン使用量が通常のチャットと比べて約15倍になるという数字も登場する。
ただし、これは通常のチャットとマルチエージェントシステムを比較した値だ。Vals AIが示した1.8〜5.1倍は、単体エージェントとチーム構成の費用比である。
比較対象も測定している指標も異なるため、両者を直接比較することはできない。
実際の開発費用や性能は、利用環境によって変わる
今回の調査結果を、自分の開発環境にそのまま当てはめることには注意が必要だ。
まず、費用の算出方法がモデルによって異なる。
GPT-6 Solについて、Vals AIは報告されたトークン使用量にサブエージェント分も含まれていると仮定し、100万トークン当たり入力2ドル、キャッシュ入力0.20ドル、出力10ドルという基本料金を適用した。
ただし、27万2000トークンを超える長い入力には追加料金が発生する。実験ではトークン使用量が実行全体の合計として報告されていたため、個々のリクエストに対する追加料金を正確に計算できなかったという。
一方、Claude Opus 5.5では、Claude Codeが報告した定価ベースの費用を使用している。
最大推論設定のチーム構成では、1件の実行が時間切れになったが、このケースについてもトークン使用量から約189ドルの費用を推定し、平均値の計算に含めた。
つまり、表に示された金額は、研究チームが設定した条件で算出したものであり、すべての利用環境で同じ請求額になるわけではない。
さらに、今回の実験は、エージェントの数だけを変えて比較したものでもない。
チーム構成には、作業の分担と統合を促す追加の指示が与えられている。また、Opusではバックグラウンドで動くサブエージェントに設けられていた10分間の実行制限も解除された。
実行基盤にも違いがあり、GPT-6 SolにはAgents API、Claude Opus 5.5にはClaude Codeが使われた。
そのため、モデル間の性能差には実行環境の違いも影響している可能性がある。観察された作業の分担方法だけで、費用や品質の差が生じた原因を断定することはできない。
今回の結果は、Vals AIのKatrina Drozdovが公式ブログで公表した事例研究であり、チーム構成の比較そのものが査読付き論文として発表されたわけではない。
また、各構成で50件のアプリをそれぞれ1回ずつ開発した実験であるため、同じ課題を繰り返し実行した場合の結果の安定性までは確認されていない。
報告された信頼区間やp値は、50件のアプリ間で観察されたスコア差のばらつきに基づくものだ。AIエージェントの実行には確率的な変動があるため、同じ課題を複数回実行しても、同じ結果が得られるとは限らない。
実際の開発現場に導入するなら、まず同じ課題と完成条件を用意し、単体エージェントの推論量を増やす方法と、複数のエージェントに作業を分担させる方法を比較するのが現実的だろう。
その際には、テスト通過率だけでなく、実際の請求額と完了までの時間を別々に記録する必要がある。さらに、同じ課題を繰り返し実行し、品質や費用、実行時間の差が安定して再現されるかを確かめることが重要だ。
今回の研究が示しているのは、AIエージェントを増やすことが、必ずしも開発品質の向上や時間短縮につながるわけではないという現実である。
複数のエージェントが効果を発揮する場面は確かにある。しかし、分担によって生まれる利点が、情報共有や統合、テストにかかる追加費用を上回るかどうかは、仕事の内容によって変わる。
AIによるソフトウェア開発が普及するほど、単純にエージェント数を増やすのではなく、どの作業を分担させ、どこに追加の計算資源を投入すべきかを見極めることが重要になる。
