4。これが、ビルドが自身の検証を初めて通過し、実際に動くもの——動作するページ、動作するエンドポイント、誰かをログインさせるログインフロー——を生み出すおおよそのタイミングだ。11は、誰かが「完成」と判断してデプロイするまでにビルドが積み重ねるプロンプト数の中央値である。68パーセントは、その最初に動作したバージョン以降に送られたプロンプトのうち、根底のロジックにおいてユーザーが気づくような変更を一切もたらさないものの割合だ。そして30は、多くの人が静かに手を止める地点であり、製品が完成したからではなく、言うべきことがなくなったからだ。
これら4つの数字は、何度も同じ形を描いている。ビルドは素早く機能するようになり、その後の残りの寿命の大半を、作り直されるのではなく語られることに費やす。
壁は予想外の場所にある
注意を払い始める前に、開発者がどこで詰まるかと聞かれていたら、私は連携部分——決済プロバイダー、認証コールバック、送信者IDの認証が必要なSMS APIなど——を挙げていただろう。それらは確かに摩擦の元だが、プロンプト数が膨れ上がる場所ではない。たいてい1、2回の追加のやり取りで解決する。
壁が現れるのはもっと後、ものが動くようになった後だ。ビルドは最初のクリーンな検証をパスする——ページが表示され、コアフローが最初から最後まで動き、エラーも出ない——それでも、そこで止まらずプロンプトは続く。「ヘッダーをもっと大きく」「アクセントカラーを変えてみて」「ボタンをもう少し丸くできる？」「いや、やっぱり最初のバージョンに戻して」。これらはどれも、データモデル、ルート、権限チェックには触れていない。すべて表面的なものだ。
なぜ「完成」が停止点に感じられないのか
これは反復作業を内側から見たときの感覚の問題でもある。ビルドが壊れているとき、何を頼めばいいかは正確にわかる——エラーを直す、足りないフィールドを追加する、つながっていないものをつなぐ。動くようになると、目標が消える。青の色合いが間違っていると教えてくれるエラーメッセージはない。もはや根拠のない好みの判断をしているだけであり、好みの判断はバグとは違って際限なく修正し続けられる。
もう一つの理由は、プロンプトを送ることが安く、即座にできるため、「もう一つだけ試す」ことのコストがその瞬間には限りなくゼロに感じられることだ。たとえ積み重なれば決してゼロではないとしても。数分ずつの見た目の手直しを十数回繰り返せば、それだけで丸一日分の作業になるが、その十数回のどの1回も、飛ばすほど高くつくとは感じられなかった。
後半のプロンプトが実際に変えているもの
| プロンプト範囲 | 典型的な対象 | 機能的な差分？ |
|---|---|---|
| 1–4 | コアページ、データモデル、主要フロー | あり——ここで製品が実際に作られる |
| 5–7 | エッジケース、エラー状態、不足しているフィールド | 多くの場合あり——実際の利用中に見つかった本物のギャップ |
| 8–15 | レイアウト、文言、色、余白、トーン | まれ |
| 16+ | 以前の見た目の選択を元に戻す、またはやり直す | ほとんどない |
その3行目こそ、じっくり向き合う価値がある部分です。見た目の磨き込みが無駄だという話ではありません — ありきたりに見えるビルドは、そうでないビルドより成果が劣りますし、デザインの調整は重要です。問題は、その磨き込みに8〜15回もの個別プロンプトが必要になることはめったにないのに、実際にそれだけかかる理由が、たいてい反復ではなく優柔不断だという点です。プロンプト11回目でより良い答えに収束しているのではなく、プロンプト9回目の時点ですでに出していた2つの答えの間を行ったり来たりしているだけなのです。
ある人がランディングページのCTAボタンを3つの位置の間で40分かけて動かし、プロンプト14回目で最初の位置が一番良かったと決め、ビルドエージェントに元の位置へ戻すよう頼むのを見たことがあります。エージェントはどのやり取りでも何一つ間違ったことをしていません。そのボタンは、そもそも14通りの意見など必要としていなかっただけです。
20回と30回の差が実際に物語ること
最も意外だった点はここです。プロンプト11回前後で止まるビルドと、30回を超えて続くビルドとで、品質に有意な差は出ません。もっと反復すれば、より洗練された成果につながるはずだと期待して調べてみましたが、ほとんどその効果は見られませんでした。代わりに見えてきたのは、早めに止められるビルダーは、事後に20回の試行錯誤で好みを探るのではなく、最初にプロンプトの中で好みの判断を一度で済ませている(「クリーンでミニマル、アクセントカラーは1色のみ、ストック写真は使わない」など)ということでした。
最も長く続いたビルドは、より野心的だったわけではありません。最初のプロンプトで最も多くのことが未決定のまま残されていたビルドです — トーンも参照点も想定ユーザーも明示されていないため、あらゆる隙間が、最初に文章として一度で埋められる代わりに、少しずつプロンプトで埋められていったのです。
実践的な結論
4〜5回のプロンプトでうまく動いているなら、それは中間地点ではなく、実際の作業の大部分がすでに終わっているということです。残っているのは実質的ではあるものの小さな作業です — 誰も説明しなかったエッジケースを確認する、コピーを見直す、視覚的トーンについて一度だけ意図的な調整パスを行う、といった具合に。もしプロンプト20回目でまだボーダーの角丸を微調整しているのに気づいたら、それはビルドが未完成なのではなく、たいていはもっと前のプロンプトで最初から望む内容を伝えるべきだったというサインです。その修正は、今回のビルドの40回目のプロンプトではなく、次のビルドの最初のメッセージに入れるべきものです。
