AI で作ったプロトタイプは捨てるか育てるか：業務アプリを本番の土台につなげる 4 つの準備

AI にコードを書かせる開発は、すでに一部の先進的な現場だけのものではなくなりつつあります。業務アプリや SaaS の立ち上げでも、「まず AI で動くものを作ってみる」という進め方が現実的な選択肢になりました。

一方で、動くものが速くできるようになったことで、新しい悩みも生まれています。作ったプロトタイプを、その後どうするかという悩みです。デモで終わらせて本番は作り直すのか、それとも本番開発の土台として育てていくのか。この記事では、業務アプリを作る側の視点から、この判断の分かれ目と、育てる前提にするなら最初に決めておきたいことを整理します。

AI がコードを書く割合はどこまで来ているか

IT 関連の調査を行っているプロジェクト Devographics は、世界のソフトウェア開発者を対象にしたアンケート「State of Devs 2026」の結果を公開しました。Publickey の紹介記事（2026 年 10 月 5 日）によると、回答者は 5,463 人です。

「あなたが作るコードのうち何％が AI によるものですか？」という質問では、最も多かった回答が 87.5％（回答者の 21％）、次が 75％（同 18％）でした。AI によるコードが 75％以上と答えた人を合計すると 49％で、全体の約半数になります。一方で、AI をまったく使わない（0％）と答えた人も 9％いました。

これは開発者の自己申告によるアンケートで、コードの量の割合であって、品質や工数の削減を示す数字ではありません。それでも、「コードを書くこと」そのものが開発のボトルネックではなくなりつつある、という変化は読み取れると私たちは考えています。

基盤側の発信にも「プロトタイプからそのまま本番へ」が表れ始めている

開発基盤を提供する側の発信にも、同じ変化が表れています。Supabase は 2026 年 10 月 2 日のイベント「Supabase Select」での発表で、エージェントが数分で作ったアプリが、プロトタイプの段階からペタバイト規模まで同じ Postgres の上で動き続けられる、というメッセージを打ち出しました（原文：“The app your agent built in minutes stays on the same Postgres from prototype to petabyte.”）。同じ発表では、エージェントがスキーマを SQL ファイルとして書き、マイグレーションはツールが算出するといった、AI が開発することを前提にした機能も紹介されています。

もちろんこれはベンダー自身の製品紹介であり、どのアプリでもそのまま本番に耐えるという意味ではありません。ただ私たちは、「プロトタイプは捨てるもの」という前提が変わり始めている兆しが、基盤の側の発信にも表れ始めていると見ています。

捨てるプロトタイプと、育てるプロトタイプ

プロトタイプには、大きく分けて 2 つの役割があります。

• 捨てるプロトタイプ：アイデアや画面の流れを確かめるためのもの。関係者の認識をそろえることが目的で、見た目が伝われば十分です。作り込むほど、捨てるときの抵抗が大きくなります
• 育てるプロトタイプ：業務の流れが本当に回るかを確かめ、そのまま本番開発の出発点にするためのもの。動くことに加えて、後から手を入れ続けられることが求められます

どちらが正しいということではありません。新規事業のアイデアを社内で議論する段階なら、捨てる前提で素早く作るほうが合っている場面も多いはずです。

問題になりやすいのは、捨てる前提で作ったものを、なんとなく育ててしまうケースです。AI で短期間に作れたぶん、「このまま使えるのでは」と感じやすくなります。しかし、データの持ち方や権限の考え方を決めないまま機能を足していくと、後から直す範囲が広がり、結局作り直しになることがあります。私たちは、AI で作れる速さが上がった今こそ、最初に「これはどちらのプロトタイプか」を決めておくことが大切だと考えています。

育てる前提にするなら、最初に決めておきたい 4 つのこと

ここからは、業務アプリや SaaS の開発に携わってきた私たちの考え方です。調査や発表から直接導かれる結論ではなく、実践にもとづく見方として読んでください。

1. 範囲を「画面」ではなく「業務の流れ」で切る

プロトタイプの範囲を「この画面とこの画面」で決めると、画面はそろったのに業務が最後まで通らない、ということが起こります。たとえば「受注を登録し、担当者が確認し、請求データを出す」のように、始まりから終わりまで 1 本通る業務の流れで範囲を決めると、検証の結果がそのまま本番の判断材料になります。最初は流れを 1 本に絞り、うまく回ることを確かめてから広げるのがおすすめです。

2. 架空のデータではなく、実際のデータのサンプルで動かす

業務アプリの問題の多くは、実際のデータを入れたときに見つかります。表記ゆれ、例外的な取引、想定より多い件数などです。整ったダミーデータだけで作ったプロトタイプは、デモではうまく見えても、運用に入った途端に想定外の分岐が出てきがちです。可能な範囲で実データのサンプルを使い、「この例外はどう扱うか」をプロトタイプの段階で洗い出しておくと、本番開発での手戻りを減らせます。

3. データの構造と、誰が何を見られるかを先に決める

画面や機能は後から比較的変えやすい一方で、データの構造と、利用者ごとの見える範囲（権限）は、後から変えるほど影響が広がります。誰がどのデータを登録し、誰がどこまで見られるのか。部署や取引先によって見える範囲が変わるのか。こうした点を最初に決めてデータベースの設計に反映しておくことが、プロトタイプを本番へつなげるための土台になります。

4. 開発ルールとテストを、コードと一緒に残す

AI がコードを書く割合が増えるほど、「このコードはなぜこうなっているのか」「どこを変えたら何が壊れるのか」を、人も AI も後から追える状態にしておくことが大切になります。命名や構成などの開発ルール、主要な業務の流れを確かめるテスト、変更のたびにそれを自動で動かす CI を、プロトタイプと一緒に用意しておけば、その後に自社のチームや AI で開発を続けても、品質を保ちやすくなります。

育てないほうがよい場合もある

すべてのプロトタイプを育てるべきだとは考えていません。次のような場合は、割り切って捨てる前提にしたほうが進めやすいことがあります。

• まだ業務の流れそのものが固まっておらず、複数の案を比べたい段階
• 社内や投資家への説明が主な目的で、見た目と体験が伝われば十分な場合
• 本番で使う予定の基盤や既存システムとの連携方針が、まだ決まっていない場合

大切なのは、捨てるか育てるかを途中でなし崩しに変えないことです。目的を最初に決めておけば、どこまで作り込むかの判断もしやすくなります。

まとめ

• 開発者向けの調査では、自分のコードの 75％以上が AI によるものと答えた人が約半数にのぼり、プロトタイプを作ること自体のハードルは下がっている
• 基盤の側でも、プロトタイプから本番まで同じ基盤で続ける前提の発信が出てきている
• だからこそ、最初に「捨てるか、育てるか」を決めることが重要になる
• 育てるなら、業務の流れ単位の範囲、実データのサンプル、データ構造と権限、開発ルールとテストの 4 つを最初に決めておくと、本番開発につなげやすい

Urchin&Company の「AI プロトタイプ開発」では、主要な業務の流れを実際の環境で動かすプロトタイプを、本番開発の土台として育てる前提でお作りしています。作り直さずに済むプロトタイプの進め方を検討している方は、お気軽にご相談ください。

参考資料

• Publickey「世界中のソフトウェア開発者の実態を調べた「State of Devs 2026」公開。何歳？ 年収は？ モニタは何枚？ AIにどのくらいコードを書かせている？ 趣味は？ など集計結果」（2026 年 10 月 5 日）https://www.publickey1.jp/blog/26/state_of_devs_2026_ai.html
• Supabase Blog「Select 2026: Scale without limits」（2026 年 10 月 2 日）https://supabase.com/blog/select-2026-scale-without-limits
• Supabase Blog「Select 2026: Build anything」（2026 年 10 月 2 日）https://supabase.com/blog/select-2026-build-anything