子供は選ぶだけ、大人は全部

プロダクトを作るとき、古典的な判断がある。まずプロトタイプで方向を検証するか、そのまま実装するか。プロトタイプの理屈はこうだ。実装はコストが高いから、まずローファイの試作で回し、方向が正しいと確認してから本実装に移る。この理屈が成り立つ前提は、実装そのもののコストが十分に高いことにある。

その前提が崩れつつある。

Claude Design でインタラクティブプロトタイプを生成するのと、Claude Code で動く実装を生成するのとでは、コストが非常に近い。Magic Patterns、WeaveFox、Variant のようなツールはさらに進んでいて、一度のプロンプトで複数の動く実装案を出し、そのまま見比べられる。選択が行われる場所は「作る前」から「作った後」へ移った。判断の材料はスケッチの山から、動く実装の山になった。自分もこの考えに沿ってマルチバリアント生成器を作った。欲しい画面を一文で入力し、三つのスタイルを選ぶと、AI がそれぞれ違うスタイルの完成した UI を三つ同時に作り、並べて比べられる。90 種類のデザインスタイルを名前で絞り込め、生成は早くできたものから順に表示される。AI が各案を自動で評価し、最良の部分をまとめた統合版も作ってくれる。

xAI の Grok Build はこの考えを極限まで推し進めた。一度に最大 8 つの agent を同時に走らせ、それぞれが計画、調査、コーディングを担い、最後に Arena Mode で自動的に順位をつける。agent が自分で解空間を探り、最良の結果へ自動的に収束する。

これはリソースの浪費ではない。並列のコストが十分に低いとき、すべての方向を同時に実装するのが最適な道筋だ。

トヨタ生産方式にはワンピースフローという考え方がある。核となるのは、バッチが小さいほどフィードバックが速く、無駄も少ないということだ。AI がマルチバリアントを並列生成するのは、ワンピースフローを極限まで押し進めることに等しい。バッチは全集合に等しく、フィードバックはその場で返る。どの案に実装する価値があるかを判断する必要はもうない。すべての案がすでに実装済みだからだ。選ぶのは子供だ、大人は全部もらう。マルチバリアント生成器の名前はこの言葉から来ている。並列生成のコストが十分に低くなれば、この言葉は冗談から開発手法になる。

従来のプロトタイプの進め方はこうだ。アイデア → スケッチ → ローファイプロトタイプ → レビュー → 方向を一つ選ぶ → 実装。各段階で選択が起き、そのたびに可能性が削られる。AI がもたらす新しい進め方はこうだ。アイデア → 複数の動く実装を並列生成 → 自動で絞り込み → 人間が最後に選ぶ。マルチバリアント生成器はこの流れの縮図だ。一文を入力すれば、ツールが三つの違うスタイルの画面を同時に作り、こちらはどれがいいかを見るだけでいい。選択の回数は減ったが、選ぶための材料は増えた。何枚かのスケッチのどれがいいかを推し量るのではなく、複数の動くプログラムを見比べるのだ。

この転換の核心は「AI が速い」ことではなく、「選択が実装の後に行われる」ことにある。従来の流れでは、選択がもっともコストの高い作業だった。間違えればやり直しになるからだ。AI はそのコストをほぼゼロまで縮めた。間違えたら、もう一組生成すればいい。並列化には二つの基本パターンがある。一つは分割で、一つのタスクを複数の独立したサブタスクに分け、各 agent が一つずつ担当し、最後にまとめる。たとえばダッシュボードの実装なら、一人がバックエンド API を書き、もう一人がフロントエンドのコンポーネントを書き、三人目がデータベースの移行を担当し、三つが揃ったところで統合する。もう一つは投票で、同じタスクを複数の agent に渡し、各 agent が違うプロンプトや違うモデルで独立に実装し、出力を見比べて最良のものを選ぶ。マルチバリアント生成器は投票のパターンを使う。同じ画面の説明を三回 AI に渡し、それぞれに違うスタイル指示を添え、最後に人間が選ぶ。

Anthropic の Agent 研究レポート はこの二つのパターンを sectioning と voting と呼んでいる。二つを組み合わせれば、ほとんどの並列の場面をカバーできる。分割は「どうやるか」の並列を担い、投票は「何をやるか」の並列を担う。プロトタイプの時代は分割だけで足りた。方向はあらかじめ決まっていたからだ。マルチバリアントの時代は投票も要る。方向そのものを並列に探すからだ。

並列生成は評価の仕方も変えた。スケッチを人が見る価値は下がり、動く結果を agent が自動で選別する価値が上がった。まず agent に選別を回させ、明らかにダメなものを落とし、最後に少数の質の高い候補を人間に渡す。必要とされる力も変わった。並列生成では、複数の agent が衝突せず、同じ作業を重ねないよう制御する力が要る。結果の比較では、どの実装がより良く、何を基準に判断するかを見極める力が要る。自動収束では、違う案の共通点と相違点を見分け、使える部分をまとめる力が要る。どれもプロトタイプの時代にはなかった。一度に一版しか作らなかったからだ。

Amp は 2026 年 2 月にエディタプラグインの終了を発表した。モデル自体が十分に強くなり、エディタの補助という足場はもう要らないという理由だった。プロトタイプも一種の足場だ。「いきなり実装する」コストが「まずプロトタイプを作る」コストに近づけば、プロトタイプの土台は消える。プロトタイプが前提にしているのは「実装は高コストだ」ということだが、その前提はもう成り立たない。

プロトタイプと Demo は同じものではない。プロトタイプは判断のコストを下げるために使い、実装が高コストなときに方向を確かめる。Demo は見せるためと話を通すために使い、あるアイデアが実現できることを示す。プロトタイプの前提は実装が高コストであること、Demo の前提は伝えることが大事だということだ。AI は Demo を作るコストをほぼゼロにした。アイデア一つに対して、動く画面、インタラクションの流れ、API 一式を、ほとんどコードを書かずに作れる。こうした Demo は製品ではないが、実際に動く。プロトタイプの役目を引き受けながら、プロトタイプの枠を超えている。

Aspire チームの実践が、その違いをはっきりさせた。彼らは AI でプロダクトの開発を進めている。Demo を作っているのではない。プロダクトのソフトウェアは、本物のコードベース、顧客、保守のコストに向き合う必要がある。Demo はそこに向き合わなくていい。プロダクトは安くなったが、保守は安くなっていない。Demo には保守の負担がないので、「実装は高コストだ」という前提に縛られない。

どの世代のツールも、死ぬときには背後にある前提が死んでいる。プロトタイプは実装が安くなって死んだ。それに取って代わるのは、より速いプロトタイプツールではなく、まったく新しい進め方だ。まず全部作って、それから選ぶ。