バイブコーディング、やめました
目次
1. はじめに
2. バイブコーディングで近道しようとした理由
3. ぶつかった限界：マルチテナントと認証認可
4. 根本原因の整理（どこで破綻したか）
5. 方針転換：認証認可をAuth0に外出し
6. 実装スケッチ（最小構成の例）
7. 運用してみて：バイブコーディングを“スモール化”する
8. 同じ壁に当たっている人への指針
9. アンチパターン
10. まとめ
1. はじめに
私はもともと開発部門上がりのPdMです。設計も実装もゴリゴリできます。
ここ1ヶ月ほど、Lovable を使った“バイブコーディング”を本格的に実践し、プロダクト用の要員を育てるより1人で回した方が速いのではと考えていました。実際、思いついたプロダクトのプロトタイプは次々に作れていました。
ところが、ここに来て限界にぶつかりました。本稿は「バイブコーディングをやめた」話と、その後にどう再設計し直したかの記録です。
同じように業務が複雑化して破綻しかけている人の指針になれば幸いです。
2. バイブコーディングで近道しようとした理由
- 発想→画面→動くものまでが速い。LovableとSupabaseをつなげば、CRUDや簡単な業務は”一気通貫”で動かせます。
- 「プロダクト用の要員を増やすより、自分がAIを使って一人称で作る」のが最短に見えました。
- Edge Functions は「処理がブラックボックス化していく」懸念から意図的に使わない運用を選びました（Lovable配下で意図せぬ更新が混ざるのを避けたかったため）。
3. ぶつかった限界：マルチテナントと認証認可
プロダクトが育つほど、マルチテナントと認証・認可の要件が増えます。私が詰まったのはここでした。
- 制御データ（ロール/権限/テナント設定）の追加削除と、それに伴うUI・API・DBの整合。
- 1か所を直すと別の動いていた箇所が壊れる。修正のたびに連鎖デグレ。
- 自然言語だけでは表現しきれない境界（「このロールは、このテナントの、このリソースにだけ可」など）。
- SupabaseのAuthは便利ですが、柔軟で複雑な業務要件（マルチテナント＋ロール/権限の細粒度制御）には運用では耐えない場面が出てきました。
メール送信などは Resend を使ってAPIベースで実装でき、ここは問題ありませんでした。
最大のボトルネックは認証認可でした。
4. 根本原因の整理（どこで破綻したか）
- 境界の曖昧さ：フロント/サーバ/DB/認証認可の責務分担が、自然言語生成の勢いでにじんでいきました。
- 暗黙依存の増殖：生成コードの“お作法”に合わせて仕様が歪み、小変更で連鎖破壊。
- 試験の粒度不足：E2Eは回せても、権限境界の契約テストが不足し、回帰が漏れがち。
-
マルチテナントの“型”不在：
tenant_idの一貫した伝搬、権限と結び付ける設計、外部IdPとの役割分担を最初に決めていなかった。
5. 方針転換：認証認可をAuth0に外出し
そこで、認証認可をAuth0に切り出す方針に変更しました。
- Auth0（OIDC/OAuth 2.0） を**IdP（Identity Provider）**として採用。
- 認証はAuth0で行い、発行されたアクセストークン（JWT）をAPIサーバで検証します。
- トークンのカスタムクレームに
tenant_idやrolesを含め、アプリ側で権限判断。 - データ層では常に
tenant_idでスコープを絞り、権限×テナントの二軸でアクセス制御。 - Lovableのフロントは画面生成と軽い前処理に専念。サーバはCursor等で実装し、責務を切り分けました。
結果、柔軟な認証要求（マルチテナント、ロールの切替/追加、将来の外部SaaS連携）に素直に対応できるようになりました。
6. 実装スケッチ（最小構成の例)
6.1 全体像（責務分担）
- フロント（Lovable）：UI/UX、フォーム検証、API呼び出し（秘密鍵は持たない）。
- APIサーバ（Node/TS）：Auth0のJWT検証、テナント/ロール判定、DB操作。
-
データ（Supabase/Postgres）：
tenant_id必須、ユニーク制約、参照整合。 - 外部サービス：Resend（メール送信）などはAPIで疎結合。
ポイントは**「境界をAPIで明確にする」**ことです。
フロントは“見せ方”、サーバは“認証・認可と業務”、DBは“整合性”に集中させます。
7. 運用してみて：バイブコーディングを“スモール化”する
- フロントはLovableで素早く作る。
- サーバはCursorで狙い撃ち（小さなルート/ユースケース単位）。
- 認証認可はAuth0、メールはResend、DBはSupabase。
- つまり、“バイブコーディングの適用範囲を小さくする”ことで、壊れにくさと速度のバランスが取れました。
- これからは「AIで作ったモジュールを組み合わせる」感覚が良さそうです。
なんて名付けようかな。バイブパズルとでも言おうかな。名前怪しいな。
8. 同じ壁に当たっている人への指針
- 認証認可は早めに外出し：マルチテナントや柔軟な権限があるなら、最初からAuth0等のIdP採用を検討します。
-
tenant_idを最初から全テーブルに：アプリ/DB/ログのすべてでテナント境界を一貫させます。 - インターフェースを固定：API/スキーマ/イベントに契約テストを用意して、生成コードに揺らされないようにします。
- 生成は“小さく頻繁に”：1画面、1ルート、1ユースケース単位でAIに作らせ、レビューとテストで固めてから次へ進みます。
-
秘密鍵はサーバ側限定：ブラウザに持たせない。
.envと権限設計を最初に決めます。
9. アンチパターン
- 自然言語だけで複雑な認可を表現し続ける（実装が散逸してデグレの温床）。
- テナント判定をフロント頼みにする（URLだけで分岐など）。
- 画面修正で業務ルールも同時変更（境界が溶ける）。
- “動くからOK”でテスト未整備（特に権限の契約テスト欠如）。
10. まとめ
- 私はフルの“バイブコーディング”をいったんやめました。
- 認証認可はAuth0に外出し、データはSupabaseで厳密にテナント境界を切り、メールはResend。
- フロントはLovable、サーバはCursorで、AI生成の適用範囲を小さく保つ。
- その上で、AIが作った小さなモジュールを組み合わせる方向へ舵を切りました。
「バイブコーディングで突っ走ったけれど、業務が複雑になって難しくなってきた」方は、まず認証認可の外出しと**マルチテナントの“型”**から整えるのがおすすめです。すると、AIの速度をもう一度、安全に取り戻せます。
ということで、今後しばらくはauth0を使った実装について書いていこうかな。