シェイピングは依然として人間の仕事

原作は、シェイピング(shaping)を終えたアイデアが備えているべき状態を三つの言葉で整理しました。粗く(rough)、解決済みで(solved)、境界がある(bounded)状態です (第2章: シェイピングの原則)。細部を確定していないので作る側が埋める余地があり、中核の要素とそのつながりがすでに決まっているので方向を見失わず、何をしないのかまで一緒に釘を刺してある、という意味です。

この三つの言葉は、もともと人に向けて渡す言葉でした。ところが作る側が人からエージェントに変わると、同じ三つの言葉がかえってより正確な言葉になりました。

スペック優先の再発見

バイブコーディングが残した失敗モードに対して業界が出した答えは、スペック優先(spec-driven development)でした。仕様を一次成果物に置き、コードはそこから作り直せる出力物として扱うアプローチで、その原型は2024年11月のAWSのAI-DLCにすでにありました (AI-DLCのスペック優先実装)。2025年にはGitHubがSpec Kitを公開して仕様・計画・タスク・実装を順序のある段階として釘を刺し (GitHubブログ)、AWSは同年7月にKiroを出して要件をEARS構文で書かせました。2026年には主要なコーディングツールがそれぞれこの構造を搭載しました。

この流れは、Shape Upを知る目で見れば見慣れないものではありません。何を作るかを先に固定し、その文書を根拠に実装をまるごと委ね、委ねた後は細部に介入しないという構造がそのままです。ピッチ(pitch)を書いてチームに任せることと、仕様を書いてエージェントに任せることは同じ形をしています。

たどり着いた場所は同じでも、出発した理由は違いました。Shape Upは6週間以内に確実にリリースするために、スペック優先はエージェントが見当違いのものを作ってしまう事故を防ぐために、この構造を選びました。異なる問題を解いていて同じ答えに行き着いたということは、この構造が道具ではなく原理に近いことの傍証です。

ピッチはそのままブリーフィング文書になる

原作が定めたピッチの五つの構成要素は、問題、アペタイト(appetite)、解決策、ラビットホール(rabbit hole)、除外項目(No-gos)です (第6章: ピッチを書く)。このリストを今あらためて読むと、エージェントに仕事を任せるときに埋めるべき項目と区別がつきません。新しい書式を作る必要はありません。すでにあります。ただし、後ろの二項目は意味が大きく変わります。

ラビットホールは、もともとシェイパーがあらかじめ見つけて埋めておくリスクでした (第5章: リスクとラビットホール)。人のチームには「ここにはまるとサイクルを失う」という警告で十分でした。人は行き止まりに入るとたいてい自分で止まって尋ねに来ますが、エージェントは止まらず、根拠が足りない場所でももっともらしい答えを作り続けます。そのためVDLCのピッチ書式は、この項目を書き直します。ラビットホールとは、エージェントが自分で判断せず人にエスカレーションすべき区間の明示的な宣言です。

除外項目の地位の変化はさらに大きなものです。人のチームにとって除外項目は、あれば良い安全装置でした。書いておかなくても、たいていは作らなかったからです。エージェントにはその「たいてい」がありません。エージェントは禁止を明示しなければ必ずやるので、これがピッチで最も重要な材料であり、最低でも三つ以上は書くべきだ、というのがVDLCがこの項目に付けた注釈です。五番目に書かれていたものが一番目に上がってきたわけです。

抽象度は依然として「ほどほど」

エージェントが空欄を勝手に埋めて事故を起こすのなら、いっそ空欄を残さずもっと詳しく書けばよいのではないか、という考えが自然に浮かびます。実際には逆の方向へ進みます。ワイヤーフレームの水準まで描き込んだ仕様は、エージェントがより良い方法を見つける余地をあらかじめ閉ざしてしまいます。ファットマーカースケッチ(fat marker sketch)で意図だけを残せという原作の助言は、細部を埋める側が速くなったぶん、かえってより有効です。

VDLCはこの感覚を意図の解像度という原則として定式化しながら、原作の三つの言葉をそのまま持ってきて使います。ワイヤーフレームは具体的すぎてエージェントの探索を殺し、一行の要求は抽象的すぎてエージェントが勝手に埋めるので、アフォーダンスとつながりだけを定義するブレッドボーディングが最も適した解像度だ、というわけです。そしてピッチを、人を説得する文書からエージェントが直接消費する実行可能な一次成果物へと格上げします (VDLC 週次サイクル)。ただしこの原則は構造とロジックに適用されるもので、UIとルック&フィールは例外です。好みはエージェントが探索する対象ではなく、人が確定する対象だからです。

シェイピングのやり方そのものも変わります。原作がスケッチと文章で解決策を練ったのは、作ってみるコストが議論するコストより大きかったからです。バイブコーディングはこの不等号をひっくり返し、そのためVDLCのシェイピングは文書作業ではなく、プロトタイプラウンドを内蔵した実験活動になります。方向が合っているかを確かめる必要があるときは、一つ作って使ってみて直すことを繰り返す収束型ラウンドを、言葉で説明しにくい好みを判定する必要があるときは、同じ問題に対してプロトタイプを二つ三つから五つほど並べて作っておいて選ぶ発散型ラウンドを回します。プロトタイプは決定のための道具にすぎないので、勝者も含めてプロダクションには上げず、確定した意図だけをピッチに移してビルドサイクルで作り直します。

発散型ラウンドで人がやることは、作ることではなく選ぶこと、すなわちキュレーションです。いくつまで並べられるかを決めるのもコンピュートではなく、人が実際に比較して判定できる注意力、つまり第3章で予算として押さえたあの資源です。

ですから、第1章で引用したKarpathyの言葉 — エージェントはインターンのような存在であり、美的感覚と判断、好みと監督は依然として人が握っていなければならないという話 (Sequoia Ascent 2026) — は、コードレビューについての助言としてよりも、シェイピングについての記述として読むほうが正確です。何を作るかを絞り、どこで止まるべきかを書き、複数の中から一つを選ぶ仕事。自動化されずに残るのは、この仕事です。

プロトタイプで判断を前倒しし、ピッチがそのまま実行可能な入力になるのなら、そのピッチを受けて作る期間が6週間でなければならない理由は残っているでしょうか。第3部の最初の章で、サイクルを測り直します。