省いた計画は、あとで対応することになる障害だ
ソフトウェアエンジニアリングのあらゆるフレームワークは、速く動き、早くリリースし、本番で反復せよと説く。AI生成ウェブサイトに関しては、それは逆だ。このビルダーはプロンプトから一気にコードをストリーム生成することを拒み — いったん止まって計画を書き、あなたが確認するのを待つ — この拒否こそが、パイプライン全体の土台となる唯一の決定だ。最初は遅いが、以後のあらゆる工程で安くつく。私はいつでもこのトレードオフを選ぶし、反対を主張する人の多くは、推測が誤っていた場合に下流で発生するコストを実際に目にしたことがないのだと思う。
計画が存在するのは、まさにこの失敗パターンを防ぐためだ。「自分のスタジオ用の予約サイト」と入力して実行ボタンを押す。システムは「予約」が何を意味するのか — カレンダーウィジェットなのか、サードパーティの埋め込みなのか、競合チェック付きの本格的な予約システムなのか — をまだ何も書いていない段階で推測しなければならない。他の順序では成立しないからだ。計画の段階で推測を誤っても、修正は一文で、5秒で終わる。生成済みのコードの中で推測を誤ると、もう一文の修正では済まず、すでに誤った前提に依存している10個のファイルを解きほぐすことになる。私はどちらのパターンも見てきた。計画段階での修正は一往復のやり取りで済む。生成後に同じ曖昧さに気づいて方向転換するのは、破棄して作り直すことになる。
計画は単なるToDoリストではない。ここが見落とされがちな部分だ。それは契約であり、システム自身がそれに従う責任を負う。ビルドが出荷される前に承認しなければならないエージェントの一つである整合性検証エージェントが、完成したサイトを承認済みの計画と突き合わせて差分をチェックする。計画したページはすべて作られたか？機能一覧は実際に出荷されたものと一致しているか？ここでの「完了」は感覚的なものではなく、書面で交わした約束に対する相対的なものであり、一行単位でチェック可能だ。これは「コードが動く」よりも強い保証であり、それが可能なのはチェックの対象となる文書が存在するからにほかならない。計画を取り除けば、その物差しも失われる。
実際に効果を発揮する場面
ビルドを主導する立場としてのあなたの発言力は、行使するかどうかにかかわらず、初期段階に偏って与えられている。情報構造、ページ構成、v1とv2のどちらに含める機能かにこだわりがあるなら、そのこだわりは最初の生成パス後よりも計画レビューの段階で10倍の価値を持つ。計画を読み返すのにかける追加の4分は、すでに脱線してしまったビルドを修正する往復作業に勝る。
最も分かりやすい例がプロダクトタイプだ — 単純な静的サイト、インストール可能なアプリ、フレームワークビルド、実データを永続化するサーバー連携アプリ。一見ただのドロップダウンに見えるが、そうではない。サイトの見た目とは無関係な数十の事項を静かに決定してしまう、プロセス全体の中で最も構造的な選択だ。
| プロダクトタイプ | プレビュー | 公開 | アカウント・データベース |
|---|---|---|---|
| 単純な静的サイト | 静的ファイルなので即座に反映 | 静的な出力がそのままクリーンにコピーされる | 不可能 — ログインを求めることは、このタイプが構造的にできないことを求めることになる |
| フレームワークビルド | まずコンパイルされる。ビルドが壊れている場合、「壊れたページ」ではなく「プレビューなし」という形で表れる | コンパイル後は同じクリーンな静的コピー経路をたどる | 不可能 |
| サーバー連携アプリ | — | 実際にプロセスを動かす環境が必要で、失敗の仕方も異なる — ファイルの欠落ではなく、プロセスのクラッシュとして現れる | アカウントやデータベースが存在し得る唯一のタイプ |
そして後から気軽にタイプを変更することはできない。単純なサイトからサーバー連携アプリへの移行は設定の切り替えではなく、ほぼ2回目のビルドに等しい。ページの読み込み方法、データの保存場所、「公開」の意味など、計画の前提の半分が旧タイプを基準に組まれているからだ。だから計画段階で、半信半疑でも言っておくべきだ。「アカウントが必要になる可能性がある」と。サーバー連携アプリを想定して計画し、結局静的部分しか使わなかったとしてもコストはかからない。あとから必要だったと気づくことは、作り直しというコストを伴う。
批判者たちの言い分にも一理ある点
これがタダで済んでいるふりをするつもりはありません。実行ごとに独立したワークスペースを用意するということは、あなたのナレッジファイルがその都度新しくコピーされ、何一つあなたのマシンに戻ってこないということです——ビルド途中でノートPCが壊れても安心な反面、レイテンシには不利です。ワークスペースのプロビジョニングと、フレームワークビルドの場合はコンテナ境界内での実際の依存関係インストールに、実時間がかかるからです。このコンテナ境界が存在するのは、フレームワークビルドが `npm install` や任意のビルドスクリプト——あなたが書いていない、ビルド時の権限で実行されるコード——を実行するためであり、これを隔離なしの共有ホストで行えば、依存関係の混同攻撃一つで他テナントのデータに触れかねません。速いが安全でない選択肢もありましたが、選ぶ価値のあるトレードオフではありませんでした。
検証についても同じことが言えます。完成したビルドがパイプラインを離れるのは、生成が止まった時点ではなく、複数の独立した検証者たちが、これ以上ブロックする価値のある問題を見つけられなくなった時点です。
- コードレビュー
- セキュリティ
- リンクとSEO
- アクセシビリティ
- 適合性
- 実際のブラウザでの動作確認
これは一回きりのチェックではなく、フラグ立て・修正・再チェックを、誰からも指摘が出なくなるまで繰り返すループです。単発のリンター実行では、その修正自体が引き起こす回帰を見逃すことがあるからです。壊れたリンクを直したつもりが、同じページの見出し階層をうっかり壊してしまう——これはまさに一度きりのチェックが見逃し、再チェックが捕まえる類のものです。このループの正直なコストは、最後の最後に見た目上の理由もなく1分ほど余計に時間がかかるビルドがときどきあることです。人はその1分に気づきます。6体のエージェントがサイトについて議論し終えたばかりだということには気づきません。それは体験に対する正当な不満です——ただ、議論そのものが行われないままリリースすべきだという主張には、私は賛成できません。
