AIでアプリを作っていると、「Supabase」という名前をよく見かけます。Supabaseは、データベースやログイン機能、APIなどをまとめて使えるサービスです。特にWebアプリでは便利で、サーバーやデータベースを一から構築しなくても、比較的簡単に「データを保存できるアプリ」を作れますので知っておくべきだと思います。
では、MVPを作る段階からSupabaseを入れた方がいいのでしょうか。
結論は、「今のMVPには基本的に必要ない」です。
たとえば、会社のWindows PCにインストールして使う買い切り型アプリなら、データはそのPCの中に保存できます。SQLiteのようなローカルデータベースを使えば、インターネット接続も外部サービスも必要ありません。
MVPの目的は、最初から完成品を作ることではなく、「本当に現場で使えるか」を小さく試すことです。
そこで最初からSupabaseを入れると、クラウド接続、ユーザー認証、通信処理、権限管理など、今は必要のない仕組みまで増えてしまいます。
便利な技術でも、必要になる前に入れれば、単なる複雑化です。
では、Supabaseが必要になるのはいつでしょうか。
分かりやすいのが、「複数人・複数拠点で同じデータを使いたい」となったときです。
たとえば本社で登録した図面を、大阪営業所でも見たい。東京の担当者が備考を追加し、それを全員がすぐ確認したい。
こうなると、各PCに別々のデータを保存するだけでは「どれが最新なのか」という問題が出てきます。
そこで、インターネット上に共通のデータベースを置き、全員がそこへアクセスする仕組みが必要になります。その有力な選択肢の一つがSupabaseです。
つまり、「データベースを使うからSupabase」ではなく、「離れた場所から同じデータを共有したいからSupabaseなどを検討する」という順番です。
ただし、今使わないからといって、将来のことを無視してよいわけではありません。MVPではSQLiteを使いながらも、画面の中にデータベース処理をベタ書きせず、「データを扱う部分」を分けて設計しておく。
そうしておけば、将来SQLiteからSupabaseなどへ変更するときの負担を減らせます。考え方はシンプルです。
今は、「ローカルPC＋SQLite」
将来、必要になれば、「複数拠点＋Supabaseなど」
今回の動画で本当に知っておくべきなのも、「Supabaseを今すぐ使おう」という話ではありません。
データベースを使うなら、削除や更新の前に対象を確認する。本番環境と開発環境を分ける。バックアップを取る。そしてAI任せにせず、最後は人間が確認するというのがこの基本の方が重要です。
MVPでは小さく作る。ただし、将来大きくできる道は残しておく。
Supabaseは「今すぐ入れるもの」ではなく、「必要になったときに使えるよう、役割を知っておくもの」と考えるのがちょうどよい。
