なんとなくわかる技術選定の注意点 — Vibe Coderのための実践ガイド
対象読者: 生成AIを相棒にしつつコードを書いている “vibe coder”（バイブコーダー） のみなさん。とりあえず動くものは作れる。でも、技術選定だけは毎回モヤっとする——そんな人に向けた、わかる／進めるための実践メモです。
はじめに — 「速く作る」と「後で困らない」を両立する
AIの助けで実装スピードは爆上がりしました。だからこそ、実装より設計の重みが増しています。インフラを豪華にしたり、逆に極端に削ぎ落としたり——どちらも簡単に踏み外す。この記事は、迷いがちな分岐点をほどよく現実的に整理します。過剰な理屈は置いといて、手触り重視でいきます。
楽しくバイブコーディングするために、技術選定をなんとなくわかっておきましょう！
まず決めるべきは「何を守るか」
- 速度: サーバー用意などの手間なくすぐリリースできるか？
- コスト: 固定費はいくらまで許容？ 従量課金の上限は？
- データの厳しさ: 個人情報？ 機微情報？ それとも匿名のログ？
- 運用の楽さ: 一人運営でも回せる？ 夜中のアラートは避けたい？
以降の各論は、この4点を頭の片隅に置いて読んでもらえればと思います。
5つの切り口
以下の５つの切り口で、それぞれ雑多に私の考えを書いていきます。
- Webアプリ vs モバイルアプリ
- BaaSを使うかどうか
- ルールベース（RLS / Rules） vs バックエンドで認証・認可
- Supabase vs Firebase
- どんなデータを扱うか
Webアプリ vs モバイルアプリ
結論から言うと、迷ったらWeb。ただし、モバイルにはASO（ストア露出）と完全ローカル運用という強みがあります。
ざっくり比較表
| 観点 | Web | モバイル（iOS/Android） |
|---|---|---|
| 初速 | 最速。デプロイ即公開。 | 審査・ビルド・証明書で時間がかかる。 |
| 配布 | SEO | ASOでオーガニック流入が狙える。 |
| 開発環境 | ブラウザで完結。端末差異は少なめ。 | シミュレータ/実機が必要。機種差＆OS差対応。 |
| 後方互換 | ブラウザ更新で吸収しやすい。 | アプリをバージョンアップしない人への考慮が必要 |
| オフライン | PWA＋IndexedDBで工夫すれば可能。 | 完全ローカル構成が簡潔。 |
| 収益化 | Stripe等でサブスク容易。 | Stripeより実装は簡単だが、手数料高。 |
メモとコツ
- 機能検証（PMF探し）段階はWebで十分。 反応が良ければ、後からモバイルに展開しても遅くない。
- ハードにオフライン運用したいならモバイル一択。 端末内DBに全データを置いて完結できる。サーバ不使用も現実的。オフラインならセキュリティもそこまで気にしなくていい。
- ASO。 技術ではなくマーケの力が効く。ストアで勝てる仮説があるなら、初手モバイルはアリ。
BaaSを使うかどうか
個人開発〜小規模チームなら、まずはBaaSを使うのが定石です。認証・DB・ストレージ・関数実行が一つにまとまって持ち運べるのは、スピードと学習コストの面で圧倒的に有利。
使うべき理由
- 認証やDBを一元で任せられる（めんどくさい認証や、DBを立てるなどの手間が不要）。
- 運用が静か（監視・パッチ適用・スケールを委ねられる）。
- 試行回数を稼げる（捨てやすい設計は、むしろ強い）。
使わないほうがいい兆候
- 頻繁に複雑な集計・結合・バッチが必要（データレイクやETL前提の構成を検討）。
- 厳格なコンプライアンス（リージョン固定、データ持ち帰り義務、社内ネットワーク制約など）。
Baasは気軽だが、認証のロックインだけは気にしておきたいところ。
ルールベース（Supabase RLS / FireStore Rules） vs バックエンドで認証・認可
ポイントは「権限の多様さ」と「データの交差具合」です。
こんなときはルールベースで十分
- “自分のデータは自分だけ” が原則のアプリ（家計簿、個人日記、マイメモ等）。
- 共有しても 読み取り限定 で済む。
こんなときはバックエンドを挟む
- 管理者ロールや複数ロールが存在する。
- 他人のデータを編集／代理操作する導線がある。
- マルチテナント（組織間の厳密分離、招待・追放、越境監査）。
- 監査ログや料金計測を確実にサーバ側で記録したい。
Supabase vs Firebase
どちらも名作。好みで決めて大きく外すことはないですが、体験はだいぶ違います。
| 項目 | Supabase | Firebase |
|---|---|---|
| データモデル | PostgreSQL（SQL）。複雑なクエリや外部キーが得意。 | Firestore（ドキュメント NoSQL）。柔軟なスキーマとスケールの手軽さ。 |
| 権限 | RLSが強力。SQLで厳密に書ける。 | Security Rules。ドキュメント単位で表現、シンプルな反面、複雑化しやすい。 |
| 関数実行 | Edge Functions（Deno）。 | Cloud Functions（Node.js）。CLIデプロイが前提。 |
| 学習コスト | SQL経験があれば早い。 | Webエンジニアの素地があれば早い。 |
| 価格感 | 固定費が発生しやすい（例: Proで月20USD前後の目安）。 | 無料〜従量課金で始めやすい。 小規模の長期運用に向く。 |
所感:
- 開発体験で選ぶならSupabase。 DBもクエリも見通しが良い。
- 初期コストを極小にして長く置いておきたいならFirebase。 ランニングの心配が少ない。
どんなデータを扱うか
画像や動画を扱う際は注意しましょう。テキストデータは多量に格納してもほとんど無傷みたいなものですが、特に動画は財布を削ります。
最近の高画質IPhoneで撮った動画や、ましてや4KになるとGBクラスになり、ストレージを圧迫します。
やるべき基本施策
- クライアントで圧縮してから送る（画像は長辺リサイズ＋JPEG/WEBP品質調整、動画はビットレートとフレームレートを落とす）。
- サムネイルを別生成し、一覧はサムネイルのみ読み込む。
- 保存期間と上限を決める（例：無料は30日・最大200MB/本）。
- CDN必須。オリジン直当ては避ける。
FAQ
Q. どちらのBaaSでもパフォーマンスは足りますか？
A. 小〜中規模なら充分です。ボトルネックは設計やクエリの質で生まれがち。N+1や無制限クエリを避け、必要なインデックスを貼るだけで体感は大きく改善します。
Q. 途中でSupabase⇄Firebaseを乗り換えられますか？
A. データ移行はどちらも可能なはずです。なお、認証においてはFirebase→Supabaseの記事は見たことありますが、逆は見たことがないです。
Q. RLS/Rulesだけで最後まで行けますか？
A. 個人利用中心なら行けます。組織利用・権限差・課金が入ると、関数や独自バックエンドを併用するほうが安全で読みやすいです。
Q. 動画サービスはやめたほうがいい？
A. やめる必要はありません。ただし圧縮・HLS・上限・課金の4点セットを必ず入れてください。無料・無制限は危険です。
Q. モバイルかWebかでまだ迷っています。
A. ユーザ獲得の主戦場がどこかで決めましょう。モバイル開発はストレスを溜めるものです、それでもモバイルの方が主戦場だと思ったら、モバイルで開発するのがいいと思います。
まとめ — “いまの自分”に最適化して始める
- 迷ったら Web + BaaS。
- RLS/Rulesは個人ユースに最適。多ロールになったらバックエンド併用。
- Supabaseは体験、Firebaseは持久力で選ぶと良いかも。
- 画像・動画は別腹設計。圧縮・上限・CDNを最初から。
色々言いましたが、今の自分に適した技術を選ぶことが重要だと思います。
迷ったら周りのエンジニア（もしくは私！）に聞くなどしましょう！
