Firebaseじゃ足りない。AIアプリにはSupabaseが必要な理由

ミドリ： タツヤさん、今AIアプリのバックエンドをFirebaseで組んでるんですけど、ベクトル検索やりたくなって詰んでます。Pineconeとか別のベクトルDBを追加するしかないですか？

タツヤ： その構成、管理が大変になるよ。Firebase + Pinecone + Cloud Functionsで3つのサービスをまたぐことになる。

ミドリ： ですよね……。もっとシンプルにならないですか？

タツヤ： Supabaseに乗り換えると全部解決する。PostgreSQL + pgvectorでベクトル検索が標準装備、エッジファンクションでAI APIも呼べる。Firebase感覚で使えるのに、AIアプリに必要な機能が全部揃ってるんだ。

Supabase vs Firebase：AIアプリ観点で比較

ミドリ： Firebase大好きなんですけど、ぶっちゃけどのくらい差があるんですか？

タツヤ： AIアプリを作る前提で比較してみよう。

ミドリ： ベクトル検索とSQLが使えるのが圧倒的ですね。

タツヤ： しかもSupabaseはPostgreSQLだから、既存のSQLの知識がそのまま使える。Firestoreのクエリ制限に悩まされることもない。

pgvectorのセットアップ ── 5分で完了

ミドリ： pgvectorってセットアップ面倒じゃないですか？

タツヤ： Supabaseなら最初から入ってる。有効化するだけ。

ステップ1：拡張の有効化

タツヤ： SupabaseダッシュボードのSQL Editorで1行実行するだけだよ。

create extension if not exists vector;

ステップ2：ベクトルカラム付きテーブル作成

create table documents (
  id bigserial primary key,
  content text,
  metadata jsonb,
  embedding vector(1536),
  created_at timestamptz default now()
);

ミドリ： vector(1536) ってのがベクトルの次元数ですか？

タツヤ： そう。1536はOpenAIの text-embedding-3-small の次元数。使うモデルに合わせて変えればいい。

ステップ3：インデックスの作成

タツヤ： 検索速度を上げるためにIVFFlatインデックスを作る。

create index on documents
using ivfflat (embedding vector_cosine_ops)
with (lists = 100);

ミドリ(thinking)： lists = 100 って何ですか？

タツヤ： ベクトルをクラスタリングするリスト数。データが1万行なら100、10万行なら300が目安。多すぎると構築時間が長くなるし、少なすぎると検索精度が下がる。

ベクトル検索の実装

ミドリ(thinking)： テーブルができたら、どうやって検索するんですか？

タツヤ(smiling)： PostgreSQLの関数として検索ロジックを作るのがベストプラクティス。

create or replace function match_documents (
  query_embedding vector(1536),
  match_threshold float default 0.7,
  match_count int default 5
)
returns table (
  id bigint,
  content text,
  metadata jsonb,
  similarity float
)
language sql stable
as $$
  select
    id,
    content,
    metadata,
    1 - (embedding <=> query_embedding) as similarity
  from documents
  where 1 - (embedding <=> query_embedding) > match_threshold
  order by embedding <=> query_embedding
  limit match_count;
$$;

ミドリ： <=> ってのがコサイン距離の演算子ですか？

タツヤ： 正解。pgvectorは3つの距離演算子を用意してる。

エッジファンクションでAI APIを呼ぶ

ミドリ(nodding)： ベクトル検索はわかりました。でもEmbeddingの生成とか、LLMへの問い合わせはどうするんですか？

タツヤ： Supabaseのエッジファンクション（Edge Functions）を使う。Deno Runtimeで動くサーバーレス関数で、全世界のエッジロケーションからレスポンスが返る。

ミドリ： Cloud Functionsのコールドスタート問題がないってことですか？

タツヤ： そう。Firebaseの Cloud Functionsは初回リクエストで3〜10秒かかることがあるけど、Supabaseのエッジファンクションは常にウォーム状態。レイテンシが段違いだよ。

RAGエンドポイントの実装例

タツヤ： ドキュメント検索 + LLM回答生成を1つのエッジファンクションで実現する構成はこうなる。

ユーザーの質問
    ↓
Edge Function
    ├─ 1. OpenAI APIでEmbedding生成
    ├─ 2. pgvectorで類似ドキュメント検索
    ├─ 3. 検索結果 + 質問をLLMに渡す
    └─ 4. 回答を返す

ミドリ： 1つのファンクションで全部完結するのはシンプルでいいですね。

タツヤ： しかもSupabaseのクライアントライブラリから supabase.functions.invoke('rag-search', { body: { query: '...' } }) で呼べる。フロントエンドのコードもシンプルに保てる。

認証 + RLSでAIアプリのセキュリティ

ミドリ： AIアプリでセキュリティってどう考えればいいですか？ ユーザーごとにアクセスできるデータを制限したいんですけど。

タツヤ： SupabaseのRow Level Security（RLS）がこの問題を綺麗に解決する。

-- ユーザーは自分のドキュメントだけ検索できる
create policy "Users can search own documents"
on documents for select
using (auth.uid() = user_id);

ミドリ(surprised)： えっ、これだけ？ ベクトル検索にもRLSが効くんですか？

タツヤ： 効く。pgvectorの検索もPostgreSQLのクエリだから、RLSポリシーが自動的に適用される。つまりユーザーAが検索してもユーザーBのドキュメントは絶対に返ってこない。これをアプリケーションコードで実装しようとすると相当大変だよ。

ミドリ： Firebaseのセキュリティルールより直感的かもしれない……。

タツヤ： SQLを書ける人にとってはね。Firestoreのセキュリティルールは独自構文だけど、SupabaseのRLSは普通のSQLだから学習コストが低い。

実践アーキテクチャ：AI Q&Aアプリ

ミドリ(thinking)： 全部組み合わせると、具体的にどういうアーキテクチャになるんですか？

タツヤ： 典型的なAI Q&Aアプリの構成を見てみよう。

┌──────────────────────────────────────────────┐
│ フロントエンド（React / Next.js）              │
│  supabase-js クライアント                     │
└──────────┬──────────────────┬─────────────────┘
           │                  │
    ┌──────▼──────┐   ┌──────▼──────┐
    │ Supabase    │   │ Edge        │
    │ Auth        │   │ Functions   │
    │ （認証）     │   │ （RAG処理）  │
    └──────┬──────┘   └──────┬──────┘
           │                  │
    ┌──────▼──────────────────▼──────┐
    │ PostgreSQL + pgvector          │
    │ ・documents（ベクトル付き）      │
    │ ・chat_history（会話履歴）      │
    │ ・RLS（行レベルセキュリティ）    │
    └────────────────────────────────┘

ミドリ： サービス1つで全部賄えるのがいいですね。Firebase + Pinecone + Cloud Functionsの3つが1つに。

タツヤ： 管理するサービスが減ると、障害ポイントも減る。これがプロトタイピングのスピードに直結するんだ。

料金の現実：月いくらかかる？

ミドリ： 料金体系を教えてください。Firebaseと比べてどうですか？

タツヤ： AIアプリを想定した月額比較をしよう。MAU 1,000、ベクトルデータ10万件の構成で。

ミドリ： Supabaseのほうが3分の1以下！？

タツヤ： ベクトル検索が組み込みだから、Pineconeの追加コストがまるごと不要になるのが大きい。さらにSupabaseの無料プランでも pgvector は使えるから、プロトタイプ段階なら$0で始められる。

爆速プロトタイピング：3日で動くAIアプリ

ミドリ： 実際にゼロからAIアプリを作ると、どのくらいかかりますか？

タツヤ： Supabaseを使ったタイムラインを見てみよう。

ミドリ： 3日で本番公開まで行けるんですか？

タツヤ： Supabase + Next.js + Vercelの組み合わせならね。バックエンドを自前で構築する場合の3〜4週間が、3日に圧縮される。これがBaaS（Backend as a Service）の威力だよ。

実導入事例：社内ドキュメント検索

ミドリ： 実際にSupabase + pgvectorで作った事例ってありますか？

タツヤ： 従業員200名のSaaS企業で、社内ドキュメント横断検索システムを構築した事例を紹介しよう。

ミドリ： 規模感は？

タツヤ： Confluence、Notion、Google Drive合わせて約15,000ページのドキュメント。これを全部Embeddingしてpgvectorに格納した。

ミドリ： 検索15分が30秒はインパクトありますね。1日5回検索するとして、1人あたり1時間以上の節約。

タツヤ： 200人で計算すると月間で約4,000時間の節約。時給3,000円として月1,200万円相当の生産性向上だ。Supabase Proの月$25と比べたら、ROIは天文学的だよ。

注意点とベストプラクティス

ミドリ： いいことずくめに聞こえるんですけど、注意点はありますか？

タツヤ： 3つ押さえておくべきことがある。

1. Embeddingのコストを見積もっておく

タツヤ： text-embedding-3-smallで10万ドキュメントをEmbeddingすると約$2〜$5。初回のバッチ処理は安いけど、ドキュメントが更新されるたびに再Embeddingが必要だから、月間の更新頻度を見積もっておくこと。

2. pgvectorのスケーリング限界

タツヤ(smiling)： pgvectorは100万ベクトルくらいまでは快適に動く。それ以上になるとHNSWインデックスへの切り替えや、パーティショニングが必要。1,000万ベクトルを超えるなら専用のベクトルDB（Qdrant、Weaviate）を検討すべき。

3. エッジファンクションの実行時間制限

タツヤ： Supabaseのエッジファンクションは最大150秒のタイムアウト。LLMのストリーミングレスポンスを返す場合はSSE（Server-Sent Events）を使って、タイムアウトに引っかからない設計にする必要がある。

ミドリ： 150秒あれば大抵の処理は収まりそうですけどね。

まとめ：AIアプリのバックエンドはSupabaseが最適解

ミドリ： 今日の話をまとめると？

タツヤ： 3つだね。

1. Supabase = PostgreSQL + pgvector + Edge Functions + Auth。 AIアプリに必要なスタック全部入り。Firebase + Pinecone + Cloud Functionsの3サービスが1つに集約できる
2. プロトタイプなら3日、コストは$0から。 無料プランでpgvectorが使えるから、検証段階でお金がかからない。本番でもPro $25/月で始められる
3. RLSによるベクトル検索のアクセス制御が強力。 ユーザーごとに検索対象を制限する仕組みがSQL一行で書ける。これをアプリケーション側で実装する手間を考えたら、圧倒的な生産性

ミドリ： Firebase使ってた身としては、乗り換えコストが気になりますが……。

タツヤ： Supabaseは supabase-js のAPIがFirebase SDKに近い設計になってるから、移行はそこまで大変じゃない。まずは新規プロジェクトからSupabaseで始めて、感覚を掴むのがおすすめだよ。

次のアクション

AIアプリのバックエンドをモダン化しましょう。

• Supabaseの無料プランでプロジェクトを作成し、pgvectorを有効化してみる
• 手元のドキュメント10件でEmbedding + ベクトル検索を試す
• 本格的なAIアプリ開発やSupabase移行のご相談は、Shimanto AI SolutionsのAIアプリケーション開発コンサルティングへ