バイブコーディングで本番アプリは作れるか？正直な限界線
バイブコーディングはプロダクションアプリの一部にはうまくはまり、一部では破綻します。実際に通用するもの、破綻するポイント、ユーザーに公開する前のチェックリストをまとめました。
短く答えるなら：イエス、実際に「本番」が意味する仕事の多くについては。ノー、すべてについてではなく、そう思い込むとひどい目に遭います。正直な答えは、あなたがどんな種類の本番アプリを作ろうとしているか — その規模、何かが壊れたときの被害範囲、そして「地味だけど致命的」な作業をどれだけ自分でやる気があるか — に完全に依存します。
これは礼賛記事でも、こき下ろし記事でもありません。バイブコーディング — ほしいものを普通の言葉で説明し、AIエージェントに実際のコードを書かせ、実行させ、繰り返し改善させること — が本当に、収益を生む実働アプリまで連れて行ってくれる領域と、そこから無理が出始める領域の地図です。
今日、本当にうまくいくもの
コア機能が数個だけのインディーSaaS。 一つか二つのことをうまくやるツール — スケジューリングアプリ、ニッチな計算ツール、コンテンツ生成ツール、小さなB2Bユーティリティ — は、AIエージェントが全体を組み立てられる領域にすっぽり収まります。データベーススキーマ、認証、決済連携、フロントエンド、デプロイスクリプト。この種のアプリを本番で動かし、実際にお金を得ている人が何千人もいて、コードの大半はエージェントが書いています。
社内ツール。 ダッシュボード、管理画面、社内Slackボット、自分のチームしか触らないレポートツール。バグが起きてもコワーカーが困るだけで、顧客向けサービスが止まるわけではないので、リスクは低めです。自分がユーザーなので、要件も大抵よく理解できています。バイブコーディングにとってほぼベストケースのシナリオです。
中小企業のウェブサイトやシンプルなEC。 マーケティングサイト、予約システム、小さな店のカタログ＋決済。よく踏み固められたパターンで、失敗しても被害が限定的、エージェントが参照できる先例も豊富にあります。
アイデア検証のためのMVP。 ゴールが「誰かがこれをほしがるか」なら、本番グレードのインフラは必要ありません — デモの最中に落ちずに、実際のユーザーがクリックして回れる何かがあればいいのです。ここではむしろバイブコーディングの方が従来型の開発より優れていると言えます。最初のユーザーフィードバックまでの速さの方が、アーキテクチャの純度より重要だからです。
共通しているのは、ほぼシングルテナントの複雑さ、中程度の規模、そして失敗しても致命的というより「面倒」で済む失敗モードです。
すでに契約しているClaude・Codexをそのまま接続。あとは数分の一のコストで動くワーカーに任せます。
meshcode をダウンロード →リスクが高まる・破綻するところ
大規模インフラ。 エージェントはキューもキャッシュ層もシャーディング戦略も書けます — でもそれは「コードを書いている」だけで、そのシステムが実際の負荷で午前3時に落ちるのを見てきた経験の傷跡は持っていません。1日に何百万リクエストもさばき、レイテンシの余裕がなく、障害が連鎖するシステムには、トレードオフの「なぜ」を理解している人が必要です。スモークテストを通るだけの動くコードでは足りません。
重いコンプライアンス・規制対応システム。 HIPAA、PCI-DSS、SOC 2、医療記録・決済インフラ・財務報告に触れるもの全般。コードが「正しい」ことは基準になりません — 基準は、エージェントには見えず、責任も負えない、意思決定・監査・統制の証跡です。これは規制を理解している人間が必要な領域で、これは譲れません。
大規模な複雑な並行状態。 競合状態、分散トランザクション、複数サービスをまたぐイベントの正確な順序に正しさが依存するシステム。これは人間にとっても本当に難しいものですが、普通の言葉の説明から作業するエージェントは特に、一見正しく見えて自分の書いたテストを通り、それでも本物の並行負荷でしか出ない微妙なバグを持ったコードを生みがちです。
あなたのアプリがこれらのどれかに触れているなら、「バイブコーディングで作った」という言葉は、そのままの状態の本番システムには当てはまるべきではありません。プロトタイプの説明としてはまだ通用します。
中間地帯：実際のローンチの多くはここにいる
熱狂の側にも、反発の側にも見落とされがちな部分がここです。ほとんどのアプリは純粋に「簡単」でも純粋に「難しい」でもありません。本当に規模と重みがあるシステムを含め、エージェントにほぼ何にでも80〜90%まで連れて行ってもらうことはできます。そして残りのラストワンマイルこそ、キャリアエンジニアである必要はなくても、誰か（注意を払っている誰か）がその仕事をチェックしているかどうかが問われる部分です。
そのラストワンマイルは、たいてい次のような形をしています。
- セキュリティの硬化 — 入力バリデーション、認証のエッジケース、レート制限、シークレット管理。エージェントはハッピーパスは正しく書きがちですが、攻撃者のように考えろと具体的に指示しない限り、敵対的な経路は見落としがちです。
- 負荷テスト — 自分だけがユーザーのときはうまく動きます。同時接続500人でも動くでしょうか？実際にトラフィックを浴びせてみるまでわかりません。
- エッジケース — 空の状態、不正な入力、タイムゾーンのバグ、決済のWebhookが2回届いたときに何が起きるか。これらはまさに、ちょっとしたデモには現れないものです。
このギャップを埋めるのに、10年選手のバックエンドエンジニアである必要はありません。「これが失敗したらどうなるか」と問い、エージェントにそれを処理させるよう押し、答えを自分で確認する意志があればいいのです。多くの人はこれを、実際にやりながら学んでいます — リリースして、本物のバグに当たって、次回のためにギャップを埋める。それは正当なやり方です。ただ、一度も確認しないのとは全く違う話です。
バイブコーディングしたアプリのリリース前チェックリスト
本物のユーザーに公開する前に：
- 認証が本当に守るべきものを守っているか。 あるユーザーとしてログインし、URL/IDを直接いじって別のユーザーのデータにアクセスできないか試す。
- シークレットがリポジトリやクライアントバンドルに入っていないか。 プッシュする前にAPIキーをgrepする。
- 呼び出しごとにお金がかかるもの（AI API、メール送信、SMS）にレート制限があるか。
- 決済がリトライと重複を処理できるか。 現実世界ではWebhookは2回以上届きます — 二重課金が起きないことを確認する。
- ハッピーパスだけでなく、エラー状態が処理されているか。 ネットワークが落ちたとき、APIがタイムアウトしたとき、入力が不正だったとき、ユーザーには何が見えるか。
- 何らかの負荷で動かしたことがあるか。 非公式でも構いません — エンドポイントを50並列で叩くスクリプト一つが、負荷テストゼロよりずっとましです。
- ユーザーが失うと困るものにバックアップがあるか。
- 自分（または誰か）が実際に認証と決済のコードを読んだか。 「一度動いた」というテストだけで済ませていないか。
- ロギングがオンになっているか。 本番で何かが壊れたとき、推測ではなく何が起きたかを見られるように。
- デプロイが失敗したときのロールバック計画を知っているか。
これらは何一つコンピューターサイエンスの学位を必要としません。必要なのは、このチェックリストを「省略可能」ではなく必須として扱う姿勢と、本物のユーザーがその答えを見つける前に、エージェントと自分自身に気まずい「もしも」を問う意志です。
バイブコーディングは、本物のユーザーの前に本番アプリを出すところまで確実に連れて行ってくれます。それをそのままリリースすべきかどうかは、ラストワンマイルを省略したときに実際に何が危険にさらされるか次第です。
👉 meshcodeをダウンロード — Mac、Windows。