AIスクール・ノーコード講座の「その後」——プロトタイプを本番公開するために必要なこと

AIスクールやノーコード講座でプロトタイプは作れるようになった。Bubble、Cursor、Bolt.new——ツールの使い方は身についた。動くアプリもできた。

そして多くの人がここで止まる。

スクール卒業後、プロトタイプを実際に公開して、ユーザーに使ってもらえた人はどのくらいいるだろうか。体感では2割を切っていると思う。これはスクールの質が悪いという話ではない。「作ること」と「公開すること」はまったく別のスキルセットだという話だ。

この記事では、スクール卒業後にプロトタイプを本番公開するまでに必要な工程を、具体的に整理する。

スクールで学べること・学べないこと

まず現状を正確に把握する。

スクールで学べること

• AIツール（Cursor、Bolt.new、Lovableなど）の操作方法
• プロンプトの書き方
• 基本的なCRUD（データの作成・読み取り・更新・削除）
• UIの構築
• Supabaseなどのバックエンドサービスの基本設定

スクールで学べない（学びにくい）こと

• 認証の本番実装 — ログイン、パスワードリセット、ソーシャルログイン、セッション管理
• セキュリティ — RLS設定、入力バリデーション、APIキーの管理
• 決済 — Stripeの本番接続、Webhook処理、エラーハンドリング
• インフラ — ドメイン設定、SSL、環境変数の管理、ステージング環境
• 運用 — 障害検知、バックアップ、ログ監視

これらは「教えにくい」のではなく「教えても実感がわかない」カテゴリだ。プロトタイプの段階では必要ないから、カリキュラムから外されている。

でも、本番公開するなら全部必要になる。

→ 全体像は「最後の30%」完全ガイドで詳しく解説している

プロトタイプと本番プロダクトの差

具体的に何が違うのかを整理する。

→ 各項目の詳細は本番公開前チェックリストを参照

この差を埋めるのが、いわゆる「最後の30%」だ。見た目の70%はできているのに、残りの30%に数倍の時間がかかる。これはスキルの問題ではなく、プロトタイプと本番プロダクトの性質の違いから来るものだ。

卒業後の3つの選択肢

プロトタイプを本番公開するにはいくつかのルートがある。

選択肢1: 自分でやる

スクールで学んだ知識を基盤にして、認証・セキュリティ・インフラを自分で実装する。

メリット

• 費用がかからない
• 技術力が身につく
• 自分のペースで進められる

デメリット

• 時間がかかる（3ヶ月以上が普通）
• セキュリティの抜け漏れリスクが高い
• 「自分で全部やる」は途中で挫折しやすい

向いている人

• エンジニア志向がある
• 時間に余裕がある
• 学ぶこと自体が目的の一つ

自分でやる場合の学習ロードマップ：

1. 認証の基本を理解する
2. Supabase RLSを設定する
3. セキュリティの最低ラインをクリアする
4. 本番デプロイ手順を踏む

選択肢2: 開発会社に依頼する

プロトタイプを渡して、本番化を開発会社に委託する。

メリット

• 品質が担保される
• 自分は事業に集中できる

デメリット

• 費用が高い（200〜500万円が相場）
• 要件定義からやり直しになりがち
• コミュニケーションコストが高い

向いている人

• 予算に余裕がある
• 大規模なプロダクトを想定している

→ 開発会社とフリーランスの費用比較

選択肢3: 仕上げに特化したサービスに依頼する

プロトタイプのコードをそのまま活かして、足りない部分だけを仕上げてもらう。

メリット

• プロトタイプが無駄にならない
• 費用が抑えられる（50〜120万円）
• 期間が短い（2〜4週間）

デメリット

• 大規模な機能追加には向かない
• AIコード前提のサービスを選ぶ必要がある

向いている人

• プロトタイプはできている
• なるべく早く公開したい
• 予算は50〜150万円程度

→ 費用を50〜75%削減する方法

公開前に必ず確認すべき5つのこと

どのルートを選ぶにせよ、以下は公開前に確認が必要だ。

1. 他人のデータが見えないか

RLS（Row Level Security）が正しく設定されていないと、ユーザーAのデータがユーザーBから丸見えになる。Supabaseを使っている場合、これは最も多い設定ミスだ。

2. APIキーがコードに直書きされていないか

AI生成コードでは、Supabaseのキーやその他のAPIキーがフロントエンドのコードに直接書かれていることがある。環境変数で管理する方法を確認すること。

3. エラーが発生したとき何が起きるか

プロトタイプではエラーが出るとブラウザの開発者ツールにスタックトレースが表示されるだけだ。本番ではユーザーにわかりやすいエラーメッセージを表示し、裏側でSentry等にレポートを送る仕組みが必要。

4. ユーザーが登録→ログイン→利用→課金まで通しで動くか

個々の機能が動いていても、フロー全体が通しで動くかは別の問題だ。特に「未ログイン状態でアクセスしたときの挙動」や「決済後にプラン変更が反映されるまでの挙動」はAIが生成しにくい部分。

5. 自分で運用できるか

公開したら終わりではない。ユーザーから問い合わせが来たとき、バグが見つかったとき、自分で対応できるか。運用の最低ラインと管理画面の最小要件を確認しておこう。

スクールの学びを無駄にしない

スクールで学んだことは無駄ではない。むしろ、AIツールの操作スキルは「プロトタイプを素早く作る力」として大きな武器になっている。

足りないのは「公開する力」だ。これはスクールで学ぶ範囲の外にある、別のスキルセット。自分で身につけるか、その部分だけ専門家に任せるか——どちらでもいい。大事なのは、「作れた」で満足せず、ユーザーに届けるところまで持っていくことだ。

プロトタイプの状態が分からない場合は、まずAIコード本番化リスク診断で現状を確認してみてほしい。10問の質問に答えるだけで、今のコードの状態と次にやるべきことが見えてくる。

→ 「何を作るか」から「どう届けるか」まで通しで知りたい方はマイクロSaaS開発完全ガイドも参照してほしい