AI開発の本当のボトルネックがQAである理由

いまAIソフトウェア開発で一番難しい未解決の問題は、品質保証であって生成ではありません。AIで機能を作るのは安上がりで、ほぼ解決済みです。本当のフロンティアは、いまや簡単に量産できるその機能が、そのスピードと規模で本当に動くのかを検証することです。QA は今まさにエージェントの自律性の上限になっています。検証は生成のようには並列化できないからです。

私たちは約18ヶ月にわたって AI で作った SaaS を出荷してきました。Claude Opus 4.1 から Claude Fable 5 までです。その間、ビルド側は劇的に速くなったのに、検証側はほとんど動きませんでした。この差こそが、すべての話の中心です。

---

---

作ることは、もう難しい部分ではなくなった

Build This Now は AI 駆動の SaaS ビルドシステムです。本番コードベースに加えて、18人の専門 AI エージェントが計画・構築・テスト・出荷を、すべて普通の言葉で進めてくれます。優れたエージェントの土台と、その下に本物の本番コードベースがあれば、生成はもう制約ではありません。

以前は1ヶ月かかっていた MVP が、いまは1日でできます。認証、決済、データベースのセキュリティ、メール、バックグラウンドジョブ。その大半はすでに組み込まれていて、その上に AI がカスタム機能を作ります。動く機能を作るコストは、桁違いに下がりました。

そこで私たちは当然のことをやりました。もっと多くを並列で動かそうとしたのです。

そこで壁にぶつかりました。

壁：作れるものを、すべては検証できない

私たちの経験では、4機能くらいを並列で動かすと、そこから先はぐちゃぐちゃになってしまいました。ビルドエージェントは問題なくついてきます。検証がついてこないのです。

おおよそ4機能を同時に超えると、3つのことがおかしくなりました。

1. テストの実行がぶつかり始めます。共有された状態、共有されたデータベースの行、共有されたポート。ある機能のテスト準備が、別の機能の後片付けを踏みつけてしまうのです。
2. 状態がずれます。テストが前提としていた環境が、もう実際の環境と一致しなくなります。隣のエージェントが裏でそれを変えてしまったからです。
3. テスト用のエージェントがループに陥ります。同じフローを何度も再実行・再チェックするのに収束せず、時間とトークンを浪費し、失敗が本物なのか衝突なのか判断できなくなります。

これらはどれも生成の問題ではありません。検証の問題です。そして並列作業を増やすほど、良くなるどころか悪化します。

生成はスケールする。検証はしない。

これが核心にある非対称性です。機能を生成するのは、ほぼ独立した作業です。エージェントに仕様とコードベースを渡せば、それだけで切り離して作業できます。機能を検証するのは、世界を共有する作業です。テストは本物の環境で本物の挙動を観察しなければならず、その環境こそ、ほかのすべてのエージェントも触っているものなのです。

10機能に10エージェントを投げれば、10機能が手に入ります。でも1つの環境で10個のテストスイートに10エージェントを投げても、きれいな10個の判定は手に入りません。検証する側は、同じ世界を奪い合うのです。

だから QA がボトルネックなのです。テストが何か抽象的な意味で難しいわけではありません。テストは、生成を安くしたまさにその性質、つまり多くのコピーを同時に走らせることを、受け付けないのです。

並列度が上がると、信頼性は下がる

私たちが見たものの形は、こうなっていました。並列で動く機能の数に対して、検証がどれだけ信頼できる状態を保てたか、です。これは私たちが観察した範囲であって、ベンチマークではありません。

ビルドの線は、これらすべてを通して横ばいでした。7機能でも2機能でも、同じくらい簡単に生成できました。ただ、7機能のテスト結果は信じられなかったのです。

より良いモデルが助けにはなるが、解決はしない理由

強いモデルは、たしかに状況を動かします。コンテキストが増えれば、エージェントはシステムをより多く頭の中に保ち、ミスを減らせます。つまり、後工程で拾う分が減ります。生成されるバグが減れば、検証すべきバグも減るのです。

Claude Fable 5 は Anthropic の最新モデルで、複雑で長時間動き続ける作業向けです（入力100万トークンあたり $10、出力100万トークンあたり $50）。これは別のやり方で問題の一部を吸収します。長い連鎖をずれずに走らせるので、検証エージェントは長いテスト&修正のループ全体で筋を保てます。途中で話の筋を見失って空回りを始める、ということがなくなるのです。これは、私たちがずっとぶつかっていたループの失敗の形を、まさに直接たたきます。

でも、これは上限を引き上げるだけです。上限をなくすわけではありません。非対称性は構造的なものです。検証が共有環境で挙動を観察しなければならない限り、並列の検証者を足せば奪い合いも増えます。良いモデルは、より速く収束し、よりずれにくい。だから壁にぶつかるまでに、同時に扱える機能が増えます。でも壁を無限のかなたに動かしてくれるわけではありません。

大規模な QA はいまだにフロンティアであり、次の本当の突破口です。生成をすでに並列化しているように、検証を並列化する方法を見つけたチームが、エージェントの自律性で次の桁違いの飛躍を手にします。なぜビルドはボトルネックではないのかを第一原理から書きましたし、同じ限界が実際にどう現れるかは、自律的な AI スウォームをどう動かしているか、そして検証者を正直に保つためになぜ敵対的な評価者に頼っているかで見られます。

FAQ

なぜ AI エージェントは大規模にコードをテストできないのですか？

AI エージェントが大規模にコードをテストできないのは、検証が共有環境に依存するのに対し、生成はそうではないからです。各テストは本物のシステムで本物の挙動を観察しなければならず、多くのエージェントが並列でテストすると、同じデータベース・状態・リソースを奪い合います。生成は独立していて、よく並列化します。検証は衝突します。私たちの経験では、4機能くらいを同時に超えるとテストの実行が干渉し始めました。

品質が崩れるまでに、何個の AI エージェントを並列で動かせますか？

約18ヶ月 AI の SaaS を作ってきた私たちの経験では、4機能くらいを並列で動かすと、そこから先は検証が信頼できなくなりました。ビルドエージェントはそれを超えても問題なくスケールしましたが、テストエージェントは衝突し、ずれ、収束せずにループし始めました。正確な数は環境の分離次第ですが、生成と検証の非対称性は一貫しています。ビルドはスケールし、検証はしません。

AI ソフトウェア開発の本当のボトルネックは何ですか？

AI ソフトウェア開発の本当のボトルネックは、生成ではなく品質保証です。優れたエージェントの土台があれば、動く機能を作るのにいまや1ヶ月ではなく1日で済みます。生成できるスピードでその機能を検証することは未解決です。検証は生成のようには並列化できないからです。QA は今日のエージェントの自律性における、実際の上限なのです。

より良いモデルは QA のボトルネックを解決しますか？

より良いモデルは助けにはなりますが、解決はしません。コンテキストが増えてミスが減れば、拾うべきバグも減ります。Claude Fable 5 のようなモデルは、ずれずに長い検証の連鎖を走らせるので、ループの失敗の形を抑えます。でもボトルネックは構造的です。検証は共有環境を観察するので、並列の検証者を足せば奪い合いも増えます。強いモデルは上限を引き上げますが、なくすわけではありません。

この先どこへ向かうか

生成は、もう面白くないほどに十分に解決されています。残っている問題は、生成のようにスケールする検証です。並列 QA を解き明かした者が、自律性の次のレベルを開きます。そしてそれこそ、私たちが Claude Fable 5 とその周りの土台で見守り、作り進めている仕事です。