「デモは作れた。で、製品はいつ出せるのか」── AIが見せる「9割の幻」と、経営が見誤る最後の谷

こんにちは、大平です。

最近、「AIでデモがすぐできたので、もう製品化もすぐですよね？」という相談や無茶振りが、はっきりと増えました。

結論から言います。動くデモと、お客さんのもとで価値を出し続ける実製品の間には、AIでは縮まらない深い谷があります。そして、この谷をいちばん見えなくするのが「デモができた＝9割完成」という感覚です。本記事では、その谷がどこにあり、経営としてそれを見積もりにどう載せるべきかを、現場でAI駆動開発を回している立場から整理します。

なぜAIは「デモ」だけを爆速にするのか

デモというのは、本来そういうものです。受注を取るために、いちばんうまく回ったときの姿を見せ、「こういう問題を解決できます」と示す。だから、整った入力と既知のケース、いわゆるハッピーパスだけを通せばいい。

ここはAIが極端に得意な領域です。入り組んだデータや仕様がない状態で画面を量産するのは、AIによってひたすら簡単になりました。100画面のデモでも普通に作れてしまう。しかも、デモで出てくる機能は「よくある画面・よくある機能」が中心で、AIの学習データが厚い領域です。プロンプトがぬるくても、いい感じに仕上げてくれます。

つまり、AIがデモを爆速にするのは、デモが「いちばん簡単な部分」だけでできているからです。裏を返せば、ここをいくら作り込んでも事業の堀（Moat）にはなりません。差がつくのは、この先にある谷の越え方です。

「デモ完成＝進捗9割」が、いちばん危ない錯覚

デモが動いた時点で「あと1割です」と社内や顧客に伝えてしまう人がいます。しかし、それは山でいえば三合目くらいです。

危ないのは「画面が揃った＝要件確定」という扱い方です。要件は画面の1つ上のレイヤーにあるもので、画面を全部並べれば要件が固まる、というわけではありません。デモはあくまで「仮説の検証」であり、製品化は「約束（コミットメント）の履行」です。デモは"解決できるかもしれない"と思わせれば成功ですが、製品は実際に問題を解決できなければいけない。位置づけがまるで違います。

だから実務上は、デモを見せる相手と、リリース日を約束する相手は最初から分けるべきです。そして見積もりの感覚としては、こう捉え直してください。見えている進捗9割と、残り工数9割は、同時に起きています。

見積もりを4つに分けて組み直す

「デモができた」を起点に、進捗・予算・スケジュール・人員の見方を組み直す必要があります。現場で炎上の引き金になりやすいのが、ここの雑さです。

進捗：見た目の完成度と、非機能要件（本番で耐えられるか＝レディネス）を二本立てで管理する。認証・異常系・ログ・バックアップ・監視・権限・データ移行をチェックリスト化して、リリース前に潰す。
予算：プロダクトのコストの大半は、開発そのものではなく保守と機能開発にかかります。デモ作成の工数・ツール代だけを全体と見ないこと。デモ工数の同程度以上を、非機能・統合・移行・合意形成のバッファとして別枠で積む。
スケジュール：PoC（デモ）→ パイロット（限定本番）→ 本番、と段階を分け、各段に出口条件を置く。決済審査・法務確認・他部署承認といった外部依存は、デモ完成とは独立してクリティカルパスに載せる。
人員：作る人と運用する人を、開発開始前に「名前で」決める。リリース後の保守担当を「未定」「兼任でなんとか」にしたまま走り出すと、必ず詰まります。

要は、デモにかかったコストは、製品化コストの一部にすぎないという前提に立てるかどうかです。

デモが隠している「実製品の要件」── 残り9割が溶ける場所

では、デモが隠している実製品の要件とは具体的に何か。ここに本実装の時間が溶けていきます。

異常系・汚いデータ：本番データには魔物がいます。最近のAIは異常系も書いてくれますが、それはAIが見た範囲のエラーだけ。全体としてどう落ちるかは、エンジニアの誰かが説明できる状態でないと危ない。
認証・認可・権限：特にマルチテナントでは、あるテナントのデータが別テナントに見えた瞬間に大事故です。テストまで含めて作り込む必要がある。
セキュリティ：IPAに載っているXSS・CSRF・SQLインジェクションは当然として、最近はFirebaseの設定をフロントに書いてAPIキーが丸見え、レスポンスのJSONにパスワードが入ったまま、といった事故が本当によくあります。
性能・スケール：10件のデモと1000万件の本番は別物です。N+1のような実装が混じると、1000万件どころか200件程度で目に見えて遅くなる。
運用・監視・障害対応：完全放置で回るWebサービスはありません。日常的にエラーもクレームも出るので、担当者を決めないと回らない。
法令・決済などの外部要件：第三者間メッセージなら電気通信事業法、決済ならトークン決済が前提です（カード番号をフォームからそのままサーバーに送る実装は論外です）。儲かる領域ほど規制は厳しくなります。
政治・合意形成：人は、新しいものを作るより、それにケチをつけるほうが楽です。そのレビューの網をかいくぐって出し切る時間まで見ておく必要がある。
既存システム統合・データ移行：API仕様の擦り合わせ、ETLの作成など、本番運用では必ず発生します。

デモが速かったのは、この一覧をすべて省いていたからです。

なぜ「最後の9割」はAIで縮まないのか

実装は、AIに任せていい領域です。むしろ任せるべきです。問題は、ここまで挙げた要件の多くが「どこまでやるか」「誰が責任を持つか」という文脈と判断を必要とすることです。

非機能要件の落とし所、運用体制、責任の所在──これらは仕様として一意に決まらず、その組織の事情と判断で決めるしかありません。だからAIでは縮まない。AIが速くするのは実装であって、意思決定ではないのです。ここは人と人とを突き合わせて決めるしかない領域です。

この谷を越えられる組織と、越えられない組織

谷を越えられる組織には共通点があります。テスト基盤があり、継続的に開発する人員が確保され、要件を切る判断ができることです。テスト基盤がなければ検証ループが回らず、AIを入れても効果は出ません。「動けばいい」で出したものは、だいたい半年もちません。

そして、技術的に谷を越えても、最後にもう一つ谷が残ります。「誰が買うのか」という谷です。プロダクトがどれだけ良くても、客がいなければ売れない。見込み客を自分で獲得できるエンジニアは、正直それほど多くありません。ゼロから売るためのマーケティング、泥臭い営業、SNS、広告、セミナーまでやりきれるか。製品化の見積もりは、本来ここまで含めて考えるべきものです。

まとめ

デモの速さと、実製品に届く速さは別物：デモはハッピーパスだけを通す。本番が要求する異常系・権限・セキュリティ・スケール・運用・法令・統合・合意形成に時間が溶ける。
見積もりはデモ完成を起点に組み直す：進捗・予算・スケジュール・人員の4点を、見た目の完成度と非機能要件に分けて二本立てで積む。
AIで縮むのは実装だけ：非機能・運用・販売は、テスト基盤・人員・要件を切る力・集客力という、組織の足腰で決まる。

経営層・開発責任者の方に問いたいのは、今の進捗感は、デモの速さに引っ張られていませんかということです。むしろ「デモで評判が良かったから、ここからプロジェクトをゼロから始められる」くらいの構えでちょうどいい。デモと実製品の間にある谷を見積もりに載せられている組織だけが、AI時代の開発速度を本当の意味で活かせます。