「Vibe Coding」の「国民的スタック」Next.js + Supabase、その誤解と真実
AIが提案するNext.jsとSupabaseの組み合わせは、迅速なプロトタイプ作成には便利ですが、本番環境では隠れた限界が露呈します。完成したアプリのように見える外見の背後に潜むコスト爆弾、ベンダーロックイン、学習曲線の真実を探り、賢明なスタック選択のための洞察を提供します。
Next.jsとSupabaseは、多くのVibe Codingツールが提案する「国民的スタック」ですが、この組み合わせがすべてのプロジェクトに最適というわけではありません。迅速なプロトタイプを作成するには理想的ですが、複雑なビジネスロジックやトラフィックが集中すると、予期せぬコストと構造的限界に直面する可能性があります。この記事は、スタック決定の裏に隠された真実を暴き、無批判な受け入れではなく、文脈に合った賢明な選択を支援するために書かれました。
「国民的スタック」はどのように誕生したか：AIのおすすめの脳内イメージ
近年、Claude、Cursor、v0などのAIコーディングツールは、「Next.jsとSupabaseから始めましょう」というアドバイスをほぼデフォルトのように提供します。実際にある開発者は、レシピアプリを作成した際、AIが「Next.js 14のServer Actions、Supabaseバックエンド、Tailwindとshadcn/uiを使おう」と提案した事例を共有しています。これは、初心者でも簡単に従える「準備された道」を提示するためです。しかし、これはAIが膨大な学習データから最も頻繁に登場するパターンを繰り返しているに過ぎず、プロジェクト固有の要件を反映したものではありません。
動作するプロトタイプが完成したアプリではない：認識の罠
非開発者やコーディングを始めたばかりの人々は、機能が動作するプロトタイプを見ると「アプリが完成した」と考えがちです。ロイ・デルクス（Roy Derks）氏が指摘するように、Vibe Codingの最大の問題は認識です。見た目には完璧に見えるアプリでも、内部にはセキュリティ脆弱性、スケーラビリティの欠如、トランザクション処理の不備などの本番環境向けの欠陥が潜んでいます。例えば、ユーザー認証をSupabase Authで簡単に実装したものの、きめ細かいアクセス制御（RBAC）やセッション管理がまったく考慮されていないケースが多々あります。このようなギャップは、技術的洞察力を持つ専門家だけが気付くことができます。
サーバーレスの魔法の影：リアルタイム・Edge Functionsの現実的なコストとパフォーマンス
Supabaseのリアルタイムサブスクリプション（realtime）やEdge Functionsは、デモアプリを作成するのには素晴らしいものです。しかし、同時接続数が数百人を超えると、リアルタイムサブスクリプションのチャネル数とメッセージ頻度が指数関数的に増大し、コストが急増します。Edge Functionsもまた、Denoベースの制限された環境で動作するため、Node.jsエコシステムの依存関係をそのまま使用できない場合が多いです。Supabaseの公式ドキュメントでさえ、「外部依存関係の代わりにWeb APIとDenoコアAPIを使用する」ことを推奨しているほどです。複雑なビジネスロジックを処理する必要がある場合、サーバーレスはむしろ設計を歪め、デバッグを困難にする可能性があります。
App RouterとServer Actions：生産性の裏に隠れた高いハードル
Next.jsのApp RouterとServer Actionsは確かに生産性を高めます。しかし、Reactのサーバーコンポーネント、クライアント境界、キャッシング戦略、データフェッチングパターンは、既存のNext.js開発者にとってもかなりの学習曲線を要求します。8か月間Next.jsとSupabaseでプロジェクトを完了したある開発者は、「Vercelにデプロイした後、長期的に管理すべき部分が増えた」と嘆きました。初期段階では迅速に進んだとしても、機能が追加されるにつれて、サーバーとクライアントの役割分担、エラーバウンダリー、デプロイパイプラインの最適化など、保守の負担が大きくなります。
ベンダーロックインと課金爆弾：VercelとSupabase依存の代償
VercelとSupabaseはそれぞれホスティングとバックエンドを見事に抽象化していますが、これは強力なベンダーロックインにつながります。例えば、VercelのEdge Functionsは独自のランタイムを使用し、SupabaseのストレージやリアルタイムAPIは移行を極めて困難にします。トラフィックが予想よりわずかに増加しただけでも、サーバーレス関数の実行回数制限やデータベースコネクションプールの限界にぶつかり、課金爆弾に見舞われるケースが頻繁にあります。実際、「Vercelから500ドルの請求が来た」というコミュニティの嘆きは容易に見つけることができます。
賢明なVibe Coderになるために：代替スタックとプロンプト設計
真の「Vibe Coding」の価値は、迅速な実験にあります。したがって、プロジェクトの性質に応じてスタックを柔軟に選択する知恵が必要です。例えば、オフラインファーストのアプリであればSQLiteやPouchDBのようなローカルファーストなツールを、シンプルなAPIサーバーであればHonoやFastifyを検討できます。また、AIにプロンプトを投げる際に、「簡易プロトタイプ用なのでNext.js+Supabaseを使用するが、後でPostgreSQL直接接続に切り替えられるように抽象化層を設けて」といった指示を追加すれば、初期段階からスケーラビリティを確保できます。結局のところ、ツールの長所と短所を理解し、批判的に受け入れる姿勢が重要です。
終わりに
Next.jsとSupabaseは確かに強力なツールですが、あらゆる状況を解決してくれる魔法の杖ではありません。Vibe Codingの流れの中でも、私たちは技術の本質を見抜く目を養わなければなりません。プロトタイプの先を想像し、チームとコードをレビューしながら隠れた欠陥を見つけ出すプロセスこそが、本当の製品を作る道です。このようなコラボレーションと履歴管理のために、md-logのようなHuman-in-the-Loopレビューツールを活用してみるのも良い方法です。結局、スタックはプロジェクトの目的を実現するための手段に過ぎず、私たちを導く主人になってはいけません。
参考資料
よくある質問
- Vibe CodingでNext.jsとSupabaseを必ず使わなければなりませんか？
- いいえ。AIツールがデフォルトとして推奨することが多いですが、プロジェクトの規模や要件によってより適切な代替案があります。例えば、軽量な静的サイトであればAstro、リアルタイムコラボレーションアプリであればElixir/Phoenixが適しているかもしれません。スタックの選定は常に批判的に行うべきです。
- Supabaseは実際のサービスに導入できるほど安定していますか？
- Supabaseは安定したPostgreSQLベースで十分なパフォーマンスを提供し、多くのスタートアップで成功裏に使用されています。ただし、サーバーレスアーキテクチャの特性上、同時接続数の急増時にコストが急速に増加する可能性があり、複雑なトランザクションやRBACの実装には追加の設計が必要です。本番環境前に必ず負荷テストを実施することをお勧めします。
- Next.jsのApp RouterとServer Actionsの学習が難しいと言われますが、代替案はありませんか？
- App RouterはReactサーバーコンポーネントの概念を含め、学習曲線が急な方です。従来のPages Routerを使い続けるか、Remixのような代替フレームワークを検討することができます。重要なのは、チームの能力とプロジェクトの複雑さを考慮してフレームワークを選択することです。
- ベンダーロックインを避けながらNext.jsとSupabaseを使い続けることはできますか？
- 可能です。Supabaseの場合、標準PostgreSQLと互換性があるため、いつでも他のPGホスティングに移行できます。Next.jsをVercelの代わりにDockerや自社サーバーにデプロイする方法もあります。ただし、Edge FunctionsやVercel固有の機能に依存すると移行コストが大きくなるため、依存を最小限に抑える抽象化層を初期段階から設計することが肝心です。