AI開発でウォーターフォールに帰った話

レシピのない厨房

はじめてフグを扱う料理人がいるとします。免許は取らない。毒がどこにあるかも調べない。味見もしない。保健所の検査も通さない。そのまま客の前に皿を出します。

理由を聞けば「スピードが大事なので」と答える。

冗談みたいな話ですが、ソフトウェア開発の現場で今これに近いことが起きています。AIの登場でコードを書く速度は劇的に上がりました。その結果「速く作れるんだから設計なんて要らない」「テストは遅くなるから省こう」「レビュー？ AIが書いたんだから大丈夫でしょ」という空気が、確実に広がっています。

私はフリーランスエンジニアとしていくつかのお客様のシステムを開発しています。そして今、意図的にウォーターフォール開発に帰りました。数年前まで「古い」の代名詞だったあの手法に。

指示は出している、でも工程が消えている

バイブコーディングという言葉があります。「〜にログイン機能を入れて」「ワンタイムパスワードを使って」「〜をAPIで用意してPOSTで受け取って」——2〜3行の指示を出して、出てきたコードをそのまま使う開発スタイルです。プロトタイプや個人の実験なら有効な場面もあります。問題は、これが本番のプロダクトにまで持ち込まれていることです。

何が起きるか。AIはコーダーとして優秀で、指示すればコードを書きます。しかし機能要件を伝えるだけの指示では、設計・テスト・レビューの工程が丸ごと消えます。AIは設計者にもテスターにもレビュワーにもなれるのに、コーダーとしてしか使われない。他の工程は存在すら認識されていません。

「余白を残して指示すれば、AIは自分の知らない知識まで使ってカッコいいものを仕上げてくれる」。使ってみた系の感想でよく見かけます。確かにそう見える瞬間はあります。でもシステムというのは、ほとんどの場合一方向に正解があるものではありません。

たとえば「お弁当を作って」とAIに頼んだら、きれいな刺身の盛り合わせが出てきたとします。見た目のクオリティは高い。でもそのお弁当、真夏に野球をしに行く人が持っていくものでした。刺身は腐ります。真夏の野球場に持っていく弁当に求められるクオリティと、その場で食べる料理に求められるクオリティは、出すべきものがまったく違います。どちらも「高いクオリティ」だけど、方向が違う。AIには「真夏に屋外で数時間持ち歩く」という文脈が見えていません。

プロの料理人なら「いつ」「どこで」「誰が食べるのか」を確認してから作ります。開発も同じです。プロの開発者が設計で叩くべきは、コードの正しさではなく、誰がどんな条件で使い、何が起きたら困るのかです。異常系の挙動、運用条件、セキュリティ、パフォーマンス要件。これらは機能要件を伝えるだけでは絶対に出てきません。目で見て、時間をかけて想像し、関係者と合意を取って、はじめて設計書に落ちるものです。

そもそもバイブコーディングを推奨する声の中には、標準的な開発サイクルを経験したことがない人が少なくないように見えます。コードを書く前に何を検討すべきか。書いたらメインブランチにマージする前に何をすべきか。体験がなければ、これらの工程の価値を実感できません。だから「設計書？ 要らないでしょ」「レビュー？ 遅くなるだけ」と言えてしまう。

厄介なのはここからです。以前から「ある担当者しかわからない仕様」は問題視されてきました。いわゆる属人化です。でもバイブコーディングでは、その担当者すら最初からいない。AIがセッションの中でコードを書き、セッションが終われば、なぜそのコードがそう書かれたのかを知る人間は誰もいません。属人化ですらない。知っている人間がこの世に存在しないコードが、本番に乗ります。

アジャイル開発でも、AI以前はこのレベルの崩壊は起きにくかった。担当者が自分でコードを書いていたから、少なくとも本人は仕様を理解していました。スプリントレビューの場でスクラムマスターに情報が集約され、何かしらの文書が残る。それが最終防衛ラインでした。バイブコーディングは、その防衛ラインごと消します。

味見もせず、レシピも残さない厨房。翌日、誰もあの料理を再現できない。

Planモードはレシピの再発明だった

面白いことに、業界はこの問題にすでに気づき始めています。ただ、その解決策を「新しいもの」として再発明しています。

Claude CodeにはPlanモードがあります。Shift+Tabを2回押すと起動し、コードを触る前にまず調査して計画を立てます。公式の推奨ワークフローはExplore → Plan → Implement → Commitです。

仕様を先に書いてAIに実装させるSDD（Spec-Driven Development、仕様駆動開発）というアプローチも広がっています。AWSはIDE丸ごとこの方法論で構築し直しました。Thoughtworksは2025年の重要エンジニアリングプラクティスとしてSDDを認定しています。

これらを並べてみます。

見覚えがないでしょうか。要件定義→基本設計→詳細設計→実装→テスト。これはウォーターフォールです。名前を変えて、ツールを変えて、Markdownで書くようになっただけで、やっていることは同じです。

業界が「新しいレシピ管理システム」と呼んでいるものの正体は、料理の世界で昔からある「レシピを書いてから作る」でした。

レシピは腐るのか

「設計書は陳腐化する。だからリポジトリに置くべきではない」という主張があります。設計書不要を唱える記事も見ました。「説明的なドキュメントは腐ったコンテキストとしてAIの性能を下げる」「テストの方がドキュメントより腐敗に強い」という論理で、リポジトリには実行可能なアーティファクト（コード、テスト、型定義）だけを置くべきだと主張しています。

この指摘自体は理解できます。実際、ある現場で設計書を棚卸ししたら、ファイルの大半がコードの実態と一致しておらず、作成時点のスナップショットのまま放置されていた、という話は珍しくありません。

でも、よく考えてほしいのです。設計書が腐った原因は何だったのか。

設計書を更新する工程がプロセスに組み込まれていなかった。仕様変更があっても反映しなかった。レビューで設計との整合性を確認しなかった。全部、開発プロセスの崩壊であって、設計書という仕組みの問題ではありません。

人間だけの頃の開発サイクルとチーム構成を思い出してください。設計フェーズで設計書を更新する。設計に従ってコードを書く。テストとレビューで設計通りか確認する。この当たり前の手順が回っていれば、設計書は常に最新の状態を保ちます。陳腐化は方法論の欠陥ではなく、更新する工程をスキップした運用の問題です。

ここで重要になるのが、コンテキストとセッションの分離です。AIとの会話（セッション）は消えるものと割り切ります。一方、設計書（コンテキスト）はリポジトリに永続化する。AIはgit履歴を人間よりはるかに高速に読めます。だからこそ、意思決定の記録がリポジトリ上にあることの価値は、AI時代にむしろ増しています。

腐ったのはレシピではなく、キッチンの運用です。

チームを組み立て、AIを「配置」する

ではどうすればいいのか。やることはシンプルです。

AI以前の開発チームを思い出してください。設計者がいて、実装者がいて、テスターがいて、レビュワーがいた。それぞれに明確な役割があり、工程ごとに成果物を受け渡していました。

AIは設計者にもコーダーにもテスターにもレビュワーにもなれます。しかし「全部の役割を一つのプロンプトで同時に」やらせるのが間違いの始まりです。

正解はこうです。まず人間だけのチーム構成を描く。どの工程に、どんな役割の担当者が必要か。その上で「この担当はAIに任せる」「この工程は人間がやる」と配置を決めます。つまり、人間だけの頃の開発サイクルを先に組み立てて、どの席にAIを座らせるかを後から決める。

ドイツの大学研究が興味深いデータを出しています。ウォーターフォールの各フェーズにおける生成AIの有効性を測定したところ、結果はこうなりました。

Design（設計）がもっとも低く26%。一方、Coding & Testing（実装・テスト）は87%で突出しています。AIは「詳細度が不十分」「トレードオフの分析が浅い」と評価され、設計フェーズでは人間の判断が不可欠だという結果です。

つまり、設計は人間がやるべき工程であり、実装とテストはAIが圧倒的に速い。ウォーターフォールの構造、つまり上流で人間が設計を固め、下流でAIが実装・テストを回すという流れは、このデータときれいに一致します。

レシピを書くのは料理長。調理と盛り付けはAI。今のところ、この配置が一番うまくいっています。

調理学校で習ったことは、まだ効いている

「AI開発にはAI以前の知見は不要」という声を聞くことがあります。

これは少し乱暴だと思います。要件定義、基本設計、詳細設計、テスト計画。数十年かけて体系化されたこれらの工程は、AIがコードを書く時代になっても地盤として機能し続けています。コードを書く主体が人間からAIに変わっただけで、「何を作るか決める」「設計する」「設計通りか確認する」という手順は消えていません。消してはいけない。

ウォーターフォールの各種設計書は、数十年かけて磨かれた「人間にもAIにも読めるPlanファイル」です。フォーマットは確かに変わりました。以前はリポジトリとは別のサーバに設計書を格納している現場が多かったですが、今はリポジトリのdocs/配下にMarkdownで書く時代です。CLAUDE.mdやAGENTS.mdも、結局は設計書のバリエーションです。名前が変わっただけで、「プロジェクトの全体像と意思決定の根拠を一箇所にまとめる」という目的は同じです。

「設計なんて書いてたら遅い」と言われることもあります。でも「遅い」の基準は何でしょうか。速く作れても、3ヶ月後に誰も理解できないシステムは、長い目で見ればずっと遅い。

包丁がAIに変わっても、食中毒を出さない手順は変わらない。

数字が証明していること

「設計を省く開発は失敗する」——これは個人の感想ではありません。データがあります。

MIT SloanとBCGの共同調査によると、2025年のAI投資6,840億ドルのうち80%以上が価値を生み出せずに終わっています。調査が指摘する主因は「構造化された計画の欠如」です。AIに任せさえすれば何でもうまくいくという期待のもとで、設計フェーズを省いた開発がどれほど失敗しやすいか。規模だけでも伝わります。

一方、市場は逆の方向に動き始めています。仕様を先に書いてからAIに実装させるSDD（Spec-Driven Development）を支援するスタートアップTesslは1.25億ドルを調達しました。SDDのワークフローを実装したSpecKitのGitHub Starは77,000を超えています。2026年4月8日には「Spec-Driven Development Is Waterfall in Markdown」という記事が公開され、「業界が新しいプラクティスとして再発明しているものは、40年前のウォーターフォールだ」と明示的に指摘しています。

設計書の効果は現場の測定値でも出ています。DeNAはCLAUDE.mdとAGENTS.mdを軸に据えたAI開発体制を整備しました。その結果を数字で見ると、次のようになります。

設計情報をAIに正しく渡したことで、AIが自走する精度が上がり、人間のレビュー負荷が大幅に下がっています。「設計をちゃんとやると遅くなる」の逆が、測定値として出ています。

設計情報が整っているほど、AIはより正確に、より少ない手戻りで動く。これは感覚ではなく、計測された事実です。

設計を叩け

最初のフグの話に戻ります。

フグの調理には免許が要ります。毒がどこにあるか学び、正しい手順で処理し、仕上がりを確認し、検査を通す。この工程を「スピードが落ちるから省きたい」とは誰も言いません。人の口に入るものだからです。

ソフトウェアで人の命がかかることは多くありません。でも、ユーザーの業務が止まること、データが消えること、信頼を失うこと。これは毎日どこかで起きています。そしてその原因の多くは、設計の不在、テストの省略、レビューの欠如です。

設計を書いてください。設計に従ってAIに実装させてください。テストとレビューを通してください。ウォーターフォール？ そうかもしれません。でもこれは「古い手法に戻る」ではなく、「ものを作る基本に立ち返る」です。