Vibe-Coding: 可能性と限界
僕らは vibe-coding にかなり強気です。けれども バックエンドの結合、トークン消費の膨張、そして LLMの誤りが積み重なる問題 は現実。ここでは、実運用で何度もぶつかっている 5つの課題 をまとめます。
僕は Prompt.Build の共同創業者/CEO、Ivan です。以前は BeyondRisk AI-6 としてエンタープライズ向けのAIシステムを作っていました。スピード重視で、早い段階から vibe-coding系のツールを取り入れてきました。すごく強気——そして、まだまだ始まったばかりだとも思っています。🚀 この投稿は、vibe-coding で本当にプロダクションまで持っていこうとした時に現場のチームが直面する痛みを記録したものです。今回は解決策は書きません。次回、僕らのアプローチを共有します。
Vibe-coding が得意なこと（僕らが強気な理由）✨
Vibe-coding（やりたいことをAIに伝えて作らせるやり方）は フロントエンドを圧倒的に速く します。ゼロからでも1セッションで“それっぽい”アプリに届く。ページが立ち上がり、ナビゲーションが動き、フォームやテーブルが並び、長い議論なしに見た目も揃う。
さらに idea → screen の距離が短い。チケットやワイヤーや引き継ぎの前に、「こうしたい」を伝えてすぐ見える。だから試行回数が増える。レイアウトを2案試す、コンポーネントを差し替える、コピーをいじる——エンジニアリングの工数を飲み込む前に。
しかも今はフロント専用でもない。多くの vibe-coding プラットフォームは ready-made backend を一緒に配線します。たとえば Supabase（managed/OSS）。auth / Postgres / RLS / storage / 使いやすい SDK が Day 1 から揃う。つまり、デモや社内ツールがクリックだけの殻ではなく、端から端まで“本物っぽい” 体験になる。
✅ 要点: 速度・反復・共有理解 に強く、しかも 動くフルスタックのプロトタイプ まで持っていきやすい。
ただし UI層を越えたところ から雰囲気が変わります。
本番で何度も直面する5つの問題 ⚠️
1) Vibe-coding の速さ vs バックエンドの“すき間”🔧
いまどき多くのプラットフォームは Supabase 等で backend 付き です（auth / Postgres / RLS / storage / functions）。なので課題は「バックエンドがない」ではありません。高速で変わるUI と、バックエンドの契約（contracts） を“本当のロジック”が出てきた瞬間から どう噛み合わせるか。
現場で起きがちな痛み:
🔍 サイレントドリフト(UI vs API).
customer_id vs customerId、UIは 200 を期待しているのに API は 204、配列の形が { data: [] } → []。バックエンドの軽い修正で、画面が id vs user_id を取り違えても目に見えるエラーは出ない。🧩 画面の非同期化
「編集」画面は直したのに「一覧」は古いデータ形のまま。単一のソース・オブ・トゥルース がないと、画面ごとに微妙にズレる。🗄️スキーマ変更が行き渡らない
カラム名変更や enum の締め付けを一カ所でやっても、他のページ/関数は旧仕様のまま。migrations を束ねて流し、pipeline で検知 しない限り起きがち。Supabase 公式も “migrations + CI” を強く推奨。🌗 staging と prod の差
keys / base URL / storage の bucket / policy が一致していない。preview ではOK→本番で 401/403/404。いわゆる「手元では動いた」案件。🔌 ワークフローの縁が脆い（jobs / webhooks / queues）
画面上は「Approve → Notify → Reconcile」でも、serverless functions / cron / webhook 署名（Stripe, Slack, GitHub） の配線は脆い。rate limit / retry / idempotency は prompt だけでは担保できない。
外部連携が 3〜5個（決済・コミュニケーション・ID・ストレージ・分析）に到達したあたりから、ドリフトが始まりやすい。
✅ 要点: いまは backend の有無 ではなく、UI ↔ API ↔ data contracts の同期 がボトルネック。UIの回転が速いほど endpoint / schema / policy はズレやすい。特に CRUD を越えた payments / audit logs / 3rd-party APIs / background jobs が増えるほど。
2) Supabase への結合 🧩 —— “export & continue” でも完全に自分のコードとは言い切れない理由
多くの vibe-coding プラットフォームは Supabase（managed/OSS）で Day 1 backend を用意します。Postgres + Auth + RLS + Storage + Edge/Functions + Realtime。ログイン/テーブル/ポリシー/ファイルまで数時間で。端から端まで“本物”。
ただし僕らの見方はこうです：
“本当の” vibe-coding は、フロントもバックも “自分のコード” を出力できるべき
バックエンドが provider の中 にあると、primitives を完全には所有できない。つまり auth/session の shape、RLS policy の流儀、SQL拡張、storage の path/ACL、Realtime の channel、SDK の挙動 に縛られる。
だから Lovable / Bolt / Replit からエクスポートして Claude Code / Cursor / Codex 等で続けるとしても、多くの場合それは provider 仕様の backend を中心に据えた frontend コードのエクスポート。悪いことではない（速さの代償）が、independence ではなく attachment。
表に出る場面:
ポータビリティの工事 が後ろに回る。Postgres vanilla / RDS / Aurora などへ動かす際、policy / auth/session / storage semantics / SDK 呼び出し の張り替えが必要。
Ops / observability は provider 仕様のまま。incidents / logs / metrics / quotas / runbooks がその流儀に依存。乗り換えは 再学習とツール替え を伴う。
カスタマイズの天井。auth / queue / storage の内部に手を入れたい時、自分のリポ/インフラで生成されている場合の自由度 には届かないことがある。
僕らは “反Supabase” ではなく “プロオーナーシップ”。Supabase は 最速の立ち上げ として素晴らしい。ただ、結合 の事実は早めに見積もり、出口 と 移行戦略 を設計しておく。あるいは必要になった時に backend 側も自分のコードとして生成 できる道を確保しておく。
実務的には：速さのために Supabase は遠慮なく使う。ただし 逃げ道（escape hatch） を持つ。
auth / data をインターフェース化（薄い auth 境界 + data access layer）。
storage / webhooks / queues は自分の functions でラップして、URL / 署名 / provider を差し替え可能に。
所有権が重要 なら、backend primitives をコード/インフラとして出力 し、編集/レビュー/再デプロイ がどこでもできる流れを狙う。
3) デバッグ中のトークン消費が膨らむ 🔥💸
OpenAI / Anthropic の prompt caching のような制御が出てきても、反復デバッグ中のトークン支出 はまだ読みにくい。キャッシュ は同一文脈に割引を効かせるが、実際のループは retry / tool calls / 非局所的な編集 を含み、大きなコンテキストの再送 を誘発する。結果、“小さな修正” 同士でも 10〜50× の差が出ることがある。
🔥 なぜ今も燃え続けるか:
非決定的な編集。小さな指示で周辺ファイル/型まで広く書き換え、次パスでより大きな文脈を再処理させる（キャッシュやクレジットは効くが wide diff をなくしきれない）。
retry / tool の空回り。rate limit / schema mismatch / tool の replanning で同じ（あるいはより大きな）文脈を再ストリーム。cache miss も起きる。
価格シグナル 自体がばらつきを反映。usage/effort ベース や token tiers に各社が寄るのは、実際の負荷が「一発で決まる」と「探索的に何度も回す」を大きく揺れるから。
🤷♂️ どこが痛いか:
修正1件あたりのコスト を読めない。見た目が似た変更でも拡散の仕方は全然違う。
“他に影響ない” を確認するだけ でもコンテキスト再消費で課金が走る。
ビルド予算 が立てにくい。支出は 再生成の回数と広がり に追随し、機能数 とは比例しない。
✅ 要点: 痛みは 金額 だけでなく 予見可能性の欠如。キャッシュ割引があっても、「この修正はいくら？」を見積れる安定した単位 が開発者側にない。
4) 月額サブスクは僕らの作り方に合わない🗓️⏱️
多くのプラットフォームは 月額＋トークン上限。でも多くのチームは 月中ずっと作らない。登録して 5〜10日 集中的にビルド、デモを出し、Cursor / Claude Code などのAIコードアシスタントにエクスポートして、一旦止める。ユーザーが欲しいのは カレンダーではなく、まとまった作業単位に対する予測可能な支払い。
🧠 何が辛いか:
遊んでいる期間にも支払う。集中週が終わると残りは未使用
見積りが散らかる。小さな修正でも想定以上にトークンを食うことがある。タスク単価 が不明瞭
価値の単位がズレている。買っているのは 時間（1ヶ月） であって 仕事（ビルド試行/再生成回数/デプロイ可能な成果） ではない。
コンテキスト切替。アシスタントにエクスポートした後も、使っていないサブスクに課金される。
✅ ユーザーが本当に欲しいもの:
月ではなく“ビルド期間”に課金（例：3〜7日パス）。
明確な作業単位（例：N regenerations / M contract checks / デプロイ可能な1ビルド）。
ペナルティなしで一時停止。止めて、後で戻って、続きから再開。
「ビルダーは 月 ではなく スプリント で考える。『この機能を動かして、いったん止める』。料金も“集中ビルドに払う” 形 であるべき。」
✅ 要点: タスクに沿った予測可能な課金 が必要。短期集中→一時停止 の流れに合わせる。月額＋トークン は小規模案件でも割高・不透明に感じさせがち。
5) “誤りの積み重なり”——小さなLLMミスが雪だるま化する理由 🌀
マルチステップのプロンプト は 小さな誤りを増幅 しがち。外部からのフィードバック なしに 自己修正（self-correction） に頼るのは安定せず、むしろ質を落とすことも。マルチターン では、文脈の変動 と 非決定性 が新たな不整合を生み、誤りが累積 する。
🧪 いま起きる理由:
自己修正の限界。モデル自身の出力だけを手掛かりに直す手法は信頼性が低く、推論を悪化 させるケースも。
実行間の非決定性。温度を下げても出力は揺れる。Nステップ目の修正 が N+1 で別のズレを作る。
長文脈のドリフト。編集チェーンが伸びるほど 潜在的なドリフト が溜まり、検出・巻き戻しが難しくなる。
🧵 現場感としては:
名前/shape/state が“ほぼ”合っているのに 完全一致しない。テストやマイグレーションに脆いモザイクができる。
“もう一回お願い” が別の副作用を生み、安定性確認 に時間を溶かす。
数日たつと、元の機能ではなく ドリフトそのもの をデバッグしている。
「小さな一手の誤り が連鎖する。“もう一度頼む” しか武器がない と、直したい根本 ではなく モデルの直前のミス を追いかけ続けることになる。」
✅ 要点: 複数ターンの自己改善ループ では珍事ではなく既知の挙動。contracts / tests / verification pass といった 外部のソース・オブ・トゥルース がなければ、“もう一回プロンプト” は誤りを 広げがち。
A special note: “Spec-driven agentic flows” は必要だが、それだけでは足りない 📐
最近は spec-driven な agentic IDE / “software factory” が増えています。例：Amazon Kiro, 8090.ai（Chamath の “Software Factory”）、GitHub Spec Kit。方向性は正しい。PRD / spec / task といった 構造 をループに足すこと。
同意点:
spec-driven は必要。カオスを減らし、エージェントに 計画 を与え、明白なミスマッチを減らす。
現実チェック:
それでも hallucination / non-determinism は消えない。アプリが大きくなるほど、日々の編集ほど、自己修正ループが収束しない、長文脈がドリフト する、小さな修正が別の不整合 を産む、は普通に起きる。構造は助けになるが終点ではない。
僕らのやり方（学び）:
Prompt.Build でも PRD → tasks → contracts → code の spec-driven agentic flow を回しています。これは ミスマッチを減らす。ただ、スケール すると 誤りの累積 と 文脈ドリフト は依然として出る。だから guardrails が要る。
「Specs は必要条件、十分条件ではない。 進むべき方向を示すが、アプリが大きくなり編集が積み上がる時に ドリフトを防ぐのは guardrails だ。」
✅ 要点:
specs + agents は正しい次の一歩。ただし それだけでは足りない。Prompt.Build では verification と portability guardrails を組み合わせ、UI/API/schema を同期 させ、ドリフトを本番前に止める。詳細は次回に。
Quick FAQ ❓
vibe-coding とは？
やりたいことをAIに伝え、特に画面まわり を高速に作ってもらうやり方。vibe-coding は有効ですか？
スピード/デモ/プロトタイピング には最適。ただし 画面とバックエンドの整合 が崩れると難しくなる。デメリットは？
名前 / データshape / ステータスコード の小さな不一致が積み重なる。修正でトークンが想定以上に燃える。特定のbackend provider に縛られる ことも。vibe-coding は無料ですか？
NO。トークン課金。小さな修正でも 広い再生成 が走り 高くつく ことがある。どのツールが「ベスト」ですか？
本当のコードとしてエクスポート でき、他環境で動かせる ものを。Portability > ロゴ。vibe-coding はプログラマを置き換えますか？
置き換えない。データモデル/セキュリティ/デプロイ/完成の定義 は人が決める。「contract drift（契約のズレ）」とは？
UI と API の期待がズレる。UI は customerId を期待、API は customer_id を返す。200 vs 204。見た目は動いていても、ある日壊れる。デバッグ中にトークン消費が跳ね上がるのはなぜですか？
小変更が 周辺ファイルの書き換え と 大きな文脈再送（tool calls） を誘発。似た修正でも コストは大きくブレる。月額プランが作り方に合わないのはなぜですか？
多くのチームは 短期集中 で作る。欲しいのは ビルドウィンドウ/作業単位の課金 であって、月 ではない。誤りの積み重なり（compounded hallucination）」とは？
小さなAIの誤り が次の“修正”を呼び、別の場所が変わり、やがて 雪だるま になる。Spec-driven のエージェントフローだけで十分ですか？
助けにはなる が それだけでは足りない。整合性を守るチェック が必要。バックエンドのロックインを避けるには？
auth と data をプラガブルに。provider固有の呼び出し を全体にばら撒かず、層に閉じ込める。
なぜこれを書いているのか（この先の話）🚀
僕らが Prompt.Build を立ち上げたのは、vibe-coding が開いた可能性を愛しているから——そして フロントの後ろ側で同じ壁 に何度も当たったから。次回は、spec-driven を越えて machine-checkable な単一の契約レイヤ、atomic migrations、contract-aware tests をどう組み合わせ、再現性/可搬性/スピード を保ちながら 無駄なトークンを燃やさない かを共有します。
ここに挙げた課題に心当たりがあれば、ぜひあなたの経験も聞かせてください。下に コメント を残すか、このメールに 返信 してください（全部目を通しています）。フォローアップを受け取りたい方は Subscribe をどうぞ。🔔
— Ivan, co-founder/CEO, Prompt.Build
https://prompt.build