Supavecとは｜OSSのRAG-as-a-Service基盤を実測——クラウドAPI停止後の自己ホスト検証

「OSSのRAG-as-a-Service」を名乗るリポジトリは増えましたが、その多くはSaaS本体のコードをそのまま公開したものです。Supavec（supavec/supavec、⭐1,210・Apache-2.0）はその典型で、しかも興味深い経緯を持っています——PerplexityによるCarbon.ai買収の発表からわずか6日後にリポジトリが作られ、「Carbon.aiのオープンソース代替」として立ち上がったのです。RAG全体の設計や選定軸を先に押さえたい方はRAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップを先に読むと、この記事の位置づけが掴みやすくなります。

この記事では、READMEの紹介ではなく「いま何が動いて、何が動かないのか」をGitHub API・DNS・HTTP応答・ソース実読・ローカル起動の実測で確かめます。検証はすべて2026年8月11日（JST）時点のものです。

Supavecとは——Carbon.ai終了から生まれたOSSのRAG-as-a-Service

Supavecは、ファイルをアップロードすると自動でチャンク分割・ベクトル化して保存し、/search で類似チャンクを引き、/chat でそれを文脈にした回答を返す、RAG機能をREST APIとして提供する基盤です。TypeScriptのモノレポで、Next.jsのWebアプリ（apps/web）とExpressのAPIサーバ（packages/api）、Supabaseのマイグレーション（supabase/）で構成されています。

生まれた経緯

Carbon.aiは、Google Docs・Notion・Slackなど多様なデータソースからの取り込みをRAG向けに提供していたスタートアップです。2024年12月18日にPerplexityによる買収が発表され、managed APIの提供は2025年3月31日に終了しました。Supavecのリポジトリが作られたのは2024年12月24日——買収発表の6日後です。行き場を失ったCarbonユーザーの受け皿としてのポジショニングが、READMEの「The open-source alternative to Carbon.ai」という1行に残っています。

なお carbon.ai ドメインは現在もNSレコードとSOAレコードを持っていますが、Aレコードがなく実際のサイトは配信されていません。SOAのシリアルは 2025033102 で、これはmanaged API終了日である2025年3月31日と一致します。

何ができるのか——9つのエンドポイント

packages/api/src/routes/index.ts に定義されているエンドポイントは9個です。すべてPOSTで、APIキー認証（apiKeyAuth()）と月次利用上限チェック（apiUsageLimit()）を通ります。

「これは結局何を代替するのか」という観点では、Supabase（Postgres + pgvector）の上にRAG用のAPI層とマルチテナント管理・課金を載せたもの、と言い切れます。ベクトルDBそのものを作っているわけではなく、pgvectorの上のアプリケーションです。

実装の中身

埋め込みは text-embedding-3-small（OpenAI）、チャット生成は @ai-sdk/google 経由の gemini-2.0-flash です。つまり埋め込みとチャットで別ベンダーを使う構成で、セルフホスト時はOpenAIとGoogleの両方のキーが要ります。この点はREADMEからは読み取れません。

チャンク分割の既定値は chunk_size: 1000 / chunk_overlap: 200 で、いずれもリクエストごとにzodスキーマで受け取れます（chunk_overlap < chunk_size のバリデーション付き）。ベクトル化は packages/api/src/utils/vector-store.ts の storeDocumentsWithFileId() が担当し、既定 batchSize = 100 でドキュメントを分割して embedDocuments() に渡します。

いま動くもの・動かないもの——ホストAPIの実測

「クラウド版がある」と書かれたOSSを評価するとき、最初に確かめるべきはそのクラウドが今も生きているかです。Supavecの場合、ここで結論が大きく変わります。

実測結果

READMEとドキュメントが案内するAPIのベースURLは https://api.supavec.com です。実際に叩くと次のようになります。

# ホスト側の生存確認（誰でも再現できる）
curl -s -o /dev/null -w "www   %{http_code}\n" -L https://www.supavec.com
curl -s -o /dev/null -w "docs  %{http_code}\n" -L https://docs.supavec.com
curl -si -X POST https://api.supavec.com/search | head -8
dig +short api.supavec.com

2026年8月11日時点の結果は次のとおりでした。

APIの応答本文とヘッダは次のようになります。

HTTP/2 404
server: railway-hikari
x-railway-fallback: true
content-type: application/json

{"status":"error","code":404,"message":"Application not found","request_id":"..."}

ポイントは x-railway-fallback: true と Application not found です。これはアプリ側が返した404ではなく、Railwayのエッジが「このドメインに紐づくサービスが存在しない」と返しているもので、/・/search・/chat・/health・/upload_text のどれを叩いても同じです。api.supavec.com は rrabiovn.up.railway.app へのCNAMEのまま、参照先のサービスが解放された状態と読めます。

リポジトリの活動状況

コードの更新も止まっています。git log の author date を月別に集計すると次のようになります。

2025年1月の269コミットをピークに、6月58 → 7月6と落ち、そこから空白期間が続きます。2025年12月の2コミットは Add Plausible Analytics script と chore: remove plausible——解析タグを足して消しただけで、機能的な最後のコミットは2025年7月13日です。リリースもタグも0件、コントリビュータは4人、オープンなIssueは1件です。

セルフホストの実体——起動までに越える4つのゲート

クラウドが使えない以上、評価はセルフホストで行うことになります。LocalSetup.md の手順どおりに進めたところ、起動までに4つの壁がありました。いずれも実際に bun run src/server.ts を実行して確認したものです。

検証環境は macOS（arm64）／ bun 1.3.11 ／ 2026年8月11日、origin/main（最終コミット 2025-12-28）です。環境変数の影響を排除するため、各試行は env -i でクリーンな環境から起動しました。

ゲート1：@supavec/common をビルドしないと import が解決しない

LocalSetup.md は「bun install → cd packages/api && bun run dev」と案内しますが、この順序では次のエラーで止まります。

error: Cannot find module '@supavec/common/usage'
  from packages/api/src/middleware/api-usage-limit.ts

ワークスペースのシンボリックリンク自体は張られています。原因は packages/common/package.json の exports が "./usage": { "default": "./dist/usage.js" } を指しており、dist/ は tsc を通すまで生成されないことです。さらに turbo.json の dev タスクには dependsOn: ["^build"] がなく（あるのは build タスクのみ）、ルートの bun run dev（turbo dev）でも共通パッケージは事前ビルドされません。先に一度ビルドしておけば解決します。

ゲート2：Upstash Redis は「レート制限を切っても」必須

packages/api/src/middleware/rate-limit.ts には RATE_LIMIT_DISABLED という環境変数によるトグルがあります。ところが RATE_LIMIT_DISABLED=true を設定してUpstashの認証情報を与えずに起動すると、こうなります。

error: Missing required environment variable: UPSTASH_REDIS_REST_URL

これは packages/api/src/server.ts が持つ独自の必須環境変数チェックで、OPENAI_API_KEY / SUPABASE_URL / SUPABASE_SERVICE_ROLE_KEY / UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN の5つを、トグルの状態と無関係に検査しています。トグルが効くのはミドルウェア内部のリクエスト処理だけで、起動そのものは止まります。

なお rate-limit.ts はモジュール読み込み時に Redis.fromEnv() を呼びますが、これ単体を import した実験では例外を投げず [Upstash Redis] The 'url' property is missing or undefined in your Redis config. という警告を出すだけでした。起動を止めているのは server.ts 側のチェックです。ソースを読んだだけでは順序を取り違えやすいところなので、実際に走らせて確認しました。

ゲート3：課金しないのに Stripe の商品IDが要る

インフラ系の変数を全部揃えても、次で止まります。

error: Missing required environment variables: NEXT_PUBLIC_STRIPE_PRODUCT_BASIC, NEXT_PUBLIC_STRIPE_PRODUCT_ENTERPRISE

packages/api/src/utils/config.ts は、モジュールの一番下で validateEnvironmentVariables() をトップレベル実行しており、この2つのStripe商品IDが無ければ import 時点で例外になります。これらはプラン判定（BASIC 750req/月 か ENTERPRISE 5,000req/月 か）に使われるもので、自分ひとりで使うセルフホストには本来不要な値です。

やっかいなのは、この2つがどの .env.sample にも書かれていないことです。packages/api/.env.sample の中身は PORT / OPENAI_API_KEY / SUPABASE_URL / SUPABASE_SERVICE_ROLE_KEY / UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN / POSTHOG_API_KEY / POSTHOG_HOST / GOOGLE_GENERATIVE_AI_API_KEY の9項目のみ。LocalSetup.md のAPI側の一覧にもStripeは登場しません。ダミー値でも通るので実害は小さいものの、サンプルにない変数を要求されるため、ソースを読むまで原因に辿り着けません。

ゲート4：PostHog は「optional」と書かれているが必須

最後の壁です。

error: You must pass your PostHog project's api key.

packages/api/src/utils/posthog.ts は new PostHog(process.env.POSTHOG_API_KEY!, ...) をモジュールスコープで実行し、posthog-node 側が空値をassertで弾きます。一方 LocalSetup.md の88行目は POSTHOG_API_KEY: Your PostHog API key (optional) と明記しています。ドキュメントと実装が食い違っている箇所で、分析基盤を使わない構成でもキーの投入が必要です。

4つを越えると起動する

以上を満たした状態で起動すると、期待どおりの出力が得られます。

# packages/common を先にビルド（ゲート1）
cd packages/common && bun run build && cd ../api

# ゲート2〜4を満たす最小構成（値はダミーでも起動は通る）
env -i PATH="$PATH" HOME="$HOME" \
  OPENAI_API_KEY=sk-xxx \
  SUPABASE_URL=http://localhost:54321 \
  SUPABASE_SERVICE_ROLE_KEY=xxx \
  UPSTASH_REDIS_REST_URL=https://xxx.upstash.io \
  UPSTASH_REDIS_REST_TOKEN=xxx \
  POSTHOG_API_KEY=phc_xxx POSTHOG_HOST=https://us.i.posthog.com \
  NEXT_PUBLIC_STRIPE_PRODUCT_BASIC=prod_x \
  NEXT_PUBLIC_STRIPE_PRODUCT_ENTERPRISE=prod_y \
  bun run src/server.ts
# => Server is running on port 3001

実際に投入が必要な外部サービスは、Supabase・OpenAI・Google・Upstash・PostHog・（形式上）Stripeの6つになります。「Supabaseさえあれば動く」構成ではない点は、採用判断で効いてくるはずです。

READMEの性能値はどこまで裏が取れるか

READMEには目を引く数字が並んでいます。ここは丁寧に切り分ける必要があります。

ソースで確認できるもの

次の項目は実装を読めば裏が取れます。

・Configurable chunk & overlap——chunk_size / chunk_overlap はリクエストごとに指定でき、既定は1000 / 200。z.coerce.number() によるバリデーションも入っている
・100-doc batch embedding——storeDocumentsWithFileId() の既定 batchSize = 100 でドキュメントを分割し embedDocuments() に渡している
・Redis-backed rate limiting: sliding-window——Ratelimit.slidingWindow(10, "10 s")。IPあたり10秒間に10リクエスト
・Usage-based billing: Free 100 → Basic 750 → Ent 5000——config.ts の API_CALL_LIMITS に定数として存在
・Async usage logging——utils/async-logger.ts が応答をブロックせずに使用量を記録

再現手段が見つからないもの

一方、次の3つの数値はリポジトリ全体を検索してもREADME.mdにしか出現しません。

これらを追加したのは2025年6月25日のコミット 166aa48（”Enhance README with architecture, performance, and developer experience sections”）で、変更は README.md のみ・55行追加・削除0・コード変更なしです。

同梱の eval/ は本物の評価コードですが、測っているものが違います。RAGASを使い LLMContextRecall / Faithfulness / FactualCorrectness の3指標を算出するスクリプトで、レイテンシのP95を測る処理も、「+12ポイント」を導けるA/B比較も含まれていません。しかも接続先は SUPAVEC_BASE_URL（既定 https://api.supavec.com）＝停止中のホストAPIで、SUPAVEC_API_KEY と アップロード済みの FILE_ID が必須です。

なお eval/README.md は「Taishi Kato氏の履歴書に関する10問」を評価すると説明していますが、実際のスクリプトが持つ質問はタイのチェンマイにおける屋内ラドン濃度の調査論文に関するものです。ドキュメントとコードが別々に更新された痕跡で、eval/ 全体が現状メンテされていないことを示唆します。

検索の中身——「Hybrid filter」とテナント分離の実装

RAG基盤を選ぶとき、検索の実装とデータ分離の境界がどこにあるかは避けて通れません。

match_documents が実際にやっていること

supabase/migrations/20250313084417_update_match_documents.sql のSQL関数が検索の中核です。処理は次のとおりです。

・deleted_at is null で論理削除済みを除外
・filter->'file_id'->'in' が渡されていれば専用カラム file_id で絞り込み（渡されなければ metadata @> filter のJSONB包含判定にフォールバック）
・1 - (documents.embedding <=> query_embedding) をsimilarityとして返す
・order by documents.embedding <=> query_embedding で近い順に並べ limit match_count

READMEはこれを「Hybrid filter (file_id + cosine)」と表現しています。「フィルタとベクトル距離のハイブリッド」という意味ではその通りですが、RAG文脈で一般に「ハイブリッド検索」と言えば密ベクトル検索とBM25等のスパース検索を融合して再ランクする手法を指します。Supavecの match_documents にスパース側はありません。キーワード完全一致に強いスパース検索を期待して選ぶと、想定と違う結果になります。この差は、pgvectorに全文検索を組み合わせる構成や、専用エンジンを検討する際の比較軸になります。

もう一点、file_id にはインデックスが張られています（20250313094315_idx_documents_file_id.sql）が、ベクトル列に対するANNインデックス（HNSW / IVFFlat）を作成するマイグレーションは見当たりません。件数が増えたときの検索特性はこの点に左右されます。

テナント分離が効いている場所

READMEは「Row-Level Security (RLS) for team-level data isolation」を掲げています。ここは正確に切り分ける必要があります。

マイグレーションを見ると、files・api_keys・profiles・team_memberships・teams・api_usage_logs にはポリシーが定義されています。一方、チャンク本文とベクトルが入る documents テーブルは ENABLE ROW LEVEL SECURITY はされているものの、ポリシーが1件も定義されていません（＝anon/authenticatedロールからは全拒否）。

そしてAPIサーバは SUPABASE_SERVICE_ROLE_KEY でクライアントを作ります。service roleキーはRLSを迂回します。つまりAPI経路では、RLSはテナント分離の実効的な防壁になっていません。

ではAPIは無防備かというと、そうではありません。packages/api/src/controllers/search.ts は検索前に次を行います。

・APIキーから team_id を引く
・要求された file_ids を files テーブルから team_id 一致で取得する
・取得できた件数と要求件数が一致しなければ処理を中断する

他チームのファイルIDを混ぜると件数が合わなくなるため、この事前検査はfail closed（不一致なら閉じる）に正しく働きます。設計として妥当です。ただし「RLSで守られている」という理解のままフォークして新しいエンドポイントを足すと、この事前検査を書き忘れた瞬間に分離が消えます。Web側（anonキー＋ユーザーJWT＋RLS）とAPI側（service roleキー＋アプリ層検査）で境界の位置が違う——ここを押さえておくのが実務上のポイントです。

全体の構成

類似ツールとの比較——どれを選ぶべきか

「RAGを載せたい」という要件に対して、Supavecはどの位置にあるのかを整理します。比較対象は用途が重なる代表的な選択肢です。

比較列のスター数・ライセンス・最終pushは2026年8月11日にGitHub APIで取得しました（RAGFlow・Onyx・Qdrant・Weaviate・LangChainはいずれも同年8月10日にpushがあり、開発は継続中です）。

読み取れることは明確です。Supavecの独自性は「RAG APIとしてのAPI設計」と「マルチテナント・課金まで含んだSaaSの実装例」にあり、検索エンジンとしての機能量では専用製品に及びません。

・文書解析（PDF・表・レイアウト）の精度が要件ならRAGFlow｜エンタープライズRAGエンジンの導入と使い方 — DeepDoc・ナレッジベース構築が正面から強い
・社内文書の検索・チャットをすぐ立ち上げたいならOnyx AIとは？企業向けRAGチャットボットの使い方・導入手順・Docker構築ガイドのようにコネクタとUIが揃った製品が近道
・自分でパイプラインを組み立てるならLangChainの使い方｜日本語入門 — LLMエージェント・RAG・チェーン構築をPythonで実践の構成要素を押さえたうえでpgvectorに載せるほうが、依存も可視化も素直

Supavecが刺さるのは、「Supabaseを既に使っていて、そこにRAGのAPI層とテナント管理をどう実装するかの参考実装が欲しい」というケースです。Apache-2.0なので、match_documents のSQL、チャンク設定のzodスキーマ、使用量ログの非同期記録あたりは、そのまま自分のコードに持ち込めます。

導入判断——Supavecをいま採用すべきか

3つの読者像に分けて整理します。

すぐ使えるRAG APIが欲しい人

適しません。 ホストAPIが停止しているため「5分でセットアップ」は成立しません。セルフホストしても、外部SaaSを6つ用意し、ドキュメントに載っていない環境変数を2つ突き止める必要があります。マネージドなRAG APIを求めるなら、現役で運用されているサービスを選ぶべきです。

Supabase上にRAGを実装したい人

参考実装として価値があります。 特に次の部分は読む価値があります。

・match_documents のフィルタとベクトル距離の組み合わせ方（JSONB包含から専用カラムへの移行の経緯がマイグレーション履歴に残っている）
・APIキー→team_id→ファイル所有権の事前検査という、service roleキー運用での分離パターン
・使用量ログを非同期で書き、月次リセット日を last_usage_reset_at から計算するプラン管理
・チャンクサイズをリクエストで受け、resync_file で再取り込みできるAPI設計

フォークして本番運用したい人

覚悟が要ります。 判断材料を並べます。

逆に言えば、規模が小さくコードを読み切れる（843コミット・TypeScriptのモノレポ）ため、剥がして自分のものにする前提なら扱いやすい部類です。「RAG-as-a-Serviceを名乗るSaaSがどう実装されているか」を丸ごと読める教材としては、Apache-2.0で公開されている価値は小さくありません。

この記事の検証まとめ

検証環境: macOS（arm64）／ bun 1.3.11 ／ 検証日 2026年8月11日（JST）／ 対象 origin/main（最終コミット 2025-12-28、843コミット時点）

・GitHub APIで実在・⭐1,210・fork 111・Apache-2.0・リリース0件を確認
・api.supavec.com は全パスでRailwayの Application not found（x-railway-fallback: true）を確認
・env -i のクリーン環境で起動ゲート4つを個別に再現し、全部満たした状態で Server is running on port 3001 に到達することを確認
・READMEの3つの性能値がリポジトリ内でREADME.md以外に出現しないこと、追加コミットがREADMEのみ55行追加であることを git log -S と git show --stat で確認
・documents テーブルにRLSポリシーが定義されていないこと、search.ts の事前検査が件数不一致で閉じることをソースで確認

参照ソース

・supavec/supavec — GitHub（README・packages/api ソース・supabase/migrations・eval/・LocalSetup.md。⭐1,210 / Apache-2.0 / 最終push 2025-12-28）
・Supavec 公式サイト（クラウド版の案内。2026-08-11時点で200応答）
・Supavec ドキュメント（APIエンドポイント仕様）
・Perplexity acquires Carbon to connect AI search to your work files — TechCrunch（2024-12-18、買収の一次報道）
・Carbon.ai acquired by Perplexity, shutting down in 3 months — Hacker News（managed API 終了の告知に関する議論）
・pgvector — GitHub（<=> コサイン距離演算子とインデックスの仕様）