今週は、仕様駆動開発（SDD）が製品と本番事例の両方でまとめて着地した週だった。AWSのKiroが要件定義から設計、コードまでを連続で生成する仕組みとして紹介され、東京海上日動がそれを本番投入して、試作にかかっていた期間が半年から1日に縮んだと報じられた。ウォーターフォール、アジャイルに次ぐ第3の開発手法、という位置づけまで付いていた。

同じ週に、俺は何をしていたか。ちょうど仕様書駆動の執筆分業を自作スキルにしたばかりで、その記事では仕様書をコードと同じように敵対的レビューにかけて、SSRFガードの欠落みたいな穴を実装前に潰していた。業界が製品にして本番で回し始めたものを、俺は手で回していた。

思想はほとんど同じだ。調べてみると、詰まる場所も同じところに来る。違うのは、そこに迂回路を用意するか、自分から塞ぐかだった。

「仕様を先に固める」は共通のアンチテーゼ

Kiroの売りも、俺がやっている分業も、出発点は同じところにある。プロンプトを投げてAIにいきなりコードを書かせる、いわゆるバイブコーディングへのアンチテーゼだ。先に仕様を固めてから実装に入る。この一点では完全に一致している。

Kiroはそれを製品の形にした。要件をEARS記法という決まった構文で構造化し、そこから設計、コードへと降ろしていく。人間が毎回プロンプトで指示していた「まず要件を出せ、次に設計だ」という段取りを、ツールの中に組み込んでしまった。試作が半年から1日というのは、この段取りの自動化が効いた数字だと思う。

俺の側は、段取りを手で持っている。仕様書の執筆はClaude Fable 5に任せ、実装はSonnet 5に切り替える。判断が大量に詰まる工程と、決まった要求を量産する工程を、別のモデルに分けて渡す。ここまでは、やっていることの粒度こそ違えど、Kiroと同じ「仕様を先に固める」の実践だ。

分岐点は、レビューを省けるかどうか

書き始めた時点では、製品化されたSDDは仕様のレビューを飛ばして速さを売る側だと思い込んでいた。手回しの分業との対比も、そう組むつもりでいた。公式ドキュメントを読むと、逆だった。

Kiroの標準フロー（Feature Specs）は、要件・設計・タスクの各段に人間の承認チェックポイントを置ける作りになっている。それだけでなく、要件の論理矛盾や曖昧さ、抜け漏れを検出するAnalyze Requirementsという仕様レビュー機能まで公式に用意されていた。仕様を先に固めるだけでなく、固めた仕様を疑う工程まで、製品はちゃんと持っていた。

ただし、それは任意だ。Kiroには、承認ゲートを省いて要件・設計・タスクを一気に生成するQuick Planというモードもある。使い慣れた機能で速さを優先したいときに選ぶ位置づけで、ドキュメントにもそう書いてある。つまりKiroは、仕様をレビューする機能を持ちながら、それを使うかどうかを利用者の判断に委ねている。

俺の型は、そこを選択式にしていない。仕様書が書き上がったら、実装へ回す前に必ずSubagentへ敵対的レビューをかける。前の記事で実際に起きたのは、そのレビューでHighが3件出てきたことだった。yt-dlpが返す外部URLをそのまま次の処理に渡していたSSRFガードの欠落、youtube.comの部分一致で偽装ホストを通してしまうホスト判定の緩さ、動画のないページを動画扱いして既存機能を壊す退行。3件とも、コードを1行も書く前の、仕様の段階で見つかっている。仕様の穴は、実装を書く前なら仕様を直すだけで済む。

「省いていいか」の判断は、レビューの一部

少し前に書いた記事のころから、AIが書いたコードはレビューが律速する、という話を書いてきた。前作では、同じことがコードの手前、仕様書のレベルでも成り立つと書いた。要件を速く大量に生成できるようになるほど、律速は仕様のレビューへと前倒しで移っていく。この詰まりは、手回しでも製品でも同じ場所に来る。KiroがAnalyze Requirementsを用意したのは、その律速が製品側からも見えているからだと思う。

同じ仕様レビューでも、攻め方は違う。Analyze Requirementsは要件同士を突き合わせて、矛盾や曖昧さ、抜けを洗う整合チェックだ。俺が挟んでいる敵対的レビューは、壊す側の視点で仕様を読ませる。SSRFガードの欠落が「抜け」だと分かるのは、yt-dlpが返すURLを攻撃者ならどう使うか、という目で読んだときだ。

レビューを飛ばすこと自体は、間違いだと思わない。ドキュメントには、よく理解された機能でKiroの出力を信頼できるなら速度優先のQuick Planでいい、とも書いてある。何度も通した経路を、毎回同じ重さでレビューする必要はない。

それでも俺の型にその選択肢がないのは、「省いていいかどうか」の判断が、結局その仕様を読むことを要求するからだ。よく理解された仕様かどうか、信頼していい出力かどうかは、目を通して初めて言える。つまりその判断は、飛ばしたはずのレビューの一部を先にやることになる。だったら判断ごと捨てて、毎回かけたほうが安い。何度目の仕様書でも、迷う余地を残していない。

整理

結び

Kiroが第3の開発手法とまで呼ばれるのを見て、思想の勝ち負けで言えば、仕様を先に固める側が勝ったんだと思う。バイブコーディングへのアンチテーゼが、製品になり本番に乗った。仕様のレビューが律速になるという詰まりまで、製品側にはちゃんと見えていた。レビューを飛ばして速さを売る側だという俺の思い込みのほうが、外れていた。

ただ、機能として持っていることと、毎回それを通すことは別だ。要件を速く大量に生成できるようになるほど、レビューを省くという迂回路の魅力も一緒に増える。俺が手で回している分業でやっているのは、その迂回路を自分から塞ぐことだった。詰まる場所は同じでも、そこをどう扱うかが違う。そういうことだった。