AIが解釈を埋めることで開発が崩れていく──クラウドエースが採った「意図が消えない」ための工夫

AIが書いた行には持ち主がおらず、聞いても理由は返ってこない

　テストがあればいいのではないか、という反論に、高野氏は明確な否定で応じる。変更によって意図せず別の場所が壊れていないかを確かめる手段としては、テストは有効だ。しかし、AIにコードを書かせていると、テストごと消える。「テストごと消して、テストは全部通っていますと平気な顔で言ってくるので、AIが実施するテストは気をつけなければなりません」。

　テストの削除自体はAI以前から可能だった。変わったのはレビューだ。「プルリクエストでテストを消してくる人がいたら、なぜこのテストを消したのかという話になったはずです」。しかし、1回の変更で3000行も5000行も書かれる状況では、人間はマージリクエストを読み切れない。テストが示すのは「テストどおりに動くか」までで、「そう動くべきか」は示してくれないのだ。

　設計書なしで開発が回っていたのは、書いた本人に聞けたからだと高野氏は指摘する。しかし、AIが書いた行には持ち主がおらず、聞いても理由は返ってこない。「AIエージェントもセッションごとに記憶が真っさらです」。一方で仕様書や設計書は、AIが毎回必ず読む。生成量にレビューが追いつかない以上、人が統制できるのは仕様書に残された「意図」だけになる。

意図の持ち主・読み手・コードの確認という3つの観点で、AI以前とAI時代を対比

　設計書の費用対効果は逆転した、というのが高野氏の見方だ。AIが下書きすることで作成コストは下がり、陳腐化は機械的に検知でき、「読まれない」問題はAIが毎回参照することで解消する。ただし、置き場所は選ぶ必要がある。「Microsoft 365のディレクトリの奥深くに設計書を置いて、コードリポジトリは別だという状態では読んでくれません」。

仕様駆動開発の3段階から何を選ぶか

　こうした話をすると「バイブコーディングはダメですか」と問われることが多い。ダメなのではなく用途が違う、というのが高野氏の答えだ。バイブコーディングは、あえてふわふわした質問を投げて生成AIの解釈を見せてもらい、自分が本当に欲しかったものに気づくよ用途だ。これは、動かして初めて分かる要件を見つけるための探索である。危ういのは、そこで見つけた解釈を意図として残さないことだ。

　では、見つけた意図をどう持つか。最初に試したのは仕様先行、いわゆるspec-firstだ。だが高野氏は、Planモードのように仕様書が使い捨てになる点を懸念し、仕様書をファイルに書かせてそこから生成する方式を採用した。そこで次の壁に突き当たる。仕様書が更新されないのである。人は古い設計書を割り引いて読むが、AIは記載どおりに実装する。「古い仕様書は、むしろ無い方がいいです」と高野氏は断る。

　仕様駆動開発には3段階がある。martinfowler.comのBirgitta Böckeler氏の記事は、仕様を先に書いて一度だけ使うspec-first、仕様をコードの隣で一緒に育てるspec-anchored、人は仕様だけを編集しコードは生成物とするspec-as-sourceに分類する。クラウドエースが採ったのは中間のspec-anchoredだ。その理由は、高野氏の言葉を借りれば「ソフトウェアの正解は運用の中にしかない」からであり、コードが先行して仕様が後から追いつく場面もあるためだ。

仕様駆動開発の三段階。spec-first／spec-anchored／spec-as-sourceの違い

　ところが、仕様を自然文で書いて育て始めると、別の壁が現れた。仕様書どおりに実装されていることを、どう担保するのかという問題だ。分かりやすい方法は、仕様書のファイルを指定してAIに繰り返し尋ねることである。しかし、同じ質問でもAIの回答は揺れる。どうすればよいのだろうか。