SupabaseからClerkを経て、より良い認証へ

2026年5月7日原文(blog.val.town)

概要

Val TownはSupabaseから従来型データベース＋Clerk認証へ移行
Clerkの制約と障害が多発し、Better Authへ再移行を決断
Clerkの「ユーザーテーブル不要」思想がVal Townの設計と衝突
サードパーティ依存のリスクを痛感し、オープンソース主導へ
ベンダーロックイン回避と運用の柔軟性を重視した選択

Val Townの認証システム移行の経緯

2023年、Val Townは Supabase から従来型データベースへ移行
- データベースは Render、認証は Clerk を採用
しかし2023年末、 Clerkからの脱却 を課題として認識
1か月前、 Better Auth への移行を完了

Clerk採用とその課題

Clerk は大きな成功を収めている認証サービス
- 5,000万ドル調達、ユーザー多数
しかし、Val Townの アーキテクチャと衝突
- Clerkは「ユーザーテーブル不要」を推奨
- サードパーティが usersテーブルとsessionsテーブル を管理
主な問題点
- APIのレートリミット が厳しく、ユーザーデータ取得に制約
  - 1アカウントあたり1秒間に5リクエストまで
  - ソーシャル機能で他ユーザー情報を頻繁に取得する用途に不向き
- データ同期の複雑化
  - Clerkと自前DBでユーザー情報が二重管理状態
  - Webhookによる同期で登録フローが複雑化、アカウント不整合が発生
- セッション管理の単一障害点
  - Clerkがダウンすると 全ユーザーログイン不可
  - 実際に障害が多発、稼働率も2〜3ナインに留まる
- その他、バグや運用上の問題も多発

なぜすぐに移行しなかったのか

決定の継続性 や開発効率の観点から即時移行は回避
Clerkにも SDKの充実 や 管理機能 など長所あり
- Remix、Fastify、Expressなど主要フレームワークに対応
- 管理画面も使いやすく、スパム対策も一定の効果
シンプルなフロントエンドアプリには適合
認証の選択肢自体が少なく、 代替のハードルが高い
- OSS認証は古くメンテ不足、他の認証サービスも同様のリスク

Better Authへの移行理由と評価

Better Auth はOSSで高品質なコードと多様なフレームワーク対応
- 独立運用が可能、サードパーティ依存を軽減
- ベンダーリスクは残るが、 セッション管理は自社側で実施
AuthKit（WorkOS） も候補だったが、OSSでの自立性を優先
Better Authの ダッシュボードや有料アドオン も高評価
- データは自社管理、必要なAPIのみプラグインで提供
- 有料サービスはステートレス運用で、セッション管理に関与しない
移行期間 は2週間、ClerkとBetter Auth両対応で段階移行
- セキュリティ面で全コードを精査・テスト
- Better Auth用のスターターテンプレートも用意

得られた教訓と今後の指針

可用性は構成要素の最小値 で決まることを痛感
サードパーティ依存のリスク評価と回避の重要性
プロダクトの成功や一般的な適合性と 自社要件の最適解 は異なる
ソフトウェアの進化は早く、 最適解は時期によって変わる ことを実感

Hackerたちの意見

ちょっと前のSupabaseの移行に関する記事、めっちゃ楽しんだよ！(https://blog.val.town/blog/migrating-from-supabase) 長期的なエンジニアリングの決定について、いい感じの正直な文章が少ないから、ブログ続けてほしいな！

こんにちは、Better AuthのBereketです。自分のためにこの問題を解決するためにBetter Authを始めたんだけど、後に会社になったんだ。他の人たちも同じ価値を感じているのを見ると、いつも嬉しくなるよ :) まだまだやることがたくさんあるから、改善できることがあれば教えてほしいな。

└

ブラウザの認証の複雑さって、ブラウザがもっと頑張ってないからだと思う？

└

やっほー！質問なんだけど、Pythonのバックエンドをサポートする予定はあるの？それとも、私たちがそれを実現する方法があるの？

ClerkとBetter Authの比較は、ちょっと不公平かもしれないね。一つはサービスで、もう一つはライブラリだから、全然違うし。スタックに統合されたサードパーティのサービスはリスクがあるけど、ライブラリはその分マシかな。もっとサービスがライブラリに置き換わるべき時期だと思う。Better Authはそれを実現する方法を本当に示してると思う。フロントエンド、バックエンド、データベースに統合できるライブラリなんだ。だからこそ、すごくいいんだよね。

だからこそ、早めにLuciaを選んで本当に感謝してる。彼らはライブラリをサポート終了して、代わりに自分で認証を管理・ホストするためのドキュメント（といくつかの小さなユーティリティ）を作ったんだ。いつも「自分では管理できない大きくて怖いもの」として提示されるけど、セキュリティや基本的なソルトの仕組みを学ぶのに一週間かけたら、全体の仕組みについてもっと自信が持てるようになったよ。

└

https://lucia-auth.com/ 彼らがライブラリを廃止して、代わりに認証をゼロから実装するための学習リソースにしたときのことを覚えてる。素晴らしい決断で、著者には本当にリスペクトだね。

もっと賢い人に聞きたいんだけど、なんでPostgresのユーザーテーブルをサードパーティのプロバイダーにオフロードする必要があるの？ヘッツナーの自分のVMにそのテーブルを置いておくのがそんなに難しいの？支払いのことじゃないし、ただのいくつかのデータフィールドなんだけど。

└

キャリアをレベルアップしてアーキテクトになりたくないの？「ユーザー管理」って箱を描いて、「Clerk」や他のSaaSをその上に乗せて、管理してもらえると思ってるの？そうすると、その魔法のブラックボックスに自分の要件を押し込めることができて、「実装する価値がない」と感じることができるんだ。

└

なんで家を建てるのに誰かにお金を払うの？自分でできると思うけど…でもそれがいつも時間の最適な使い方とは限らないよね。この比喩は基本的だけど的を射てる。誰もがすべてのメカニズムを運営（または作成）したいわけじゃない。私も自分でホスティングを全部やってるわけじゃないし、できないからじゃなくて、私の場合はそれが価値がないから。もう少し詳しく言うと、ビジネスがリスクを増やしてお金を節約する選択肢に直面したとき、情報を管理して安全に保つことが仕事じゃない人に任せるのか、あるいはそれを扱うことが仕事で、独立した保険を持っていて、顧客データを失った場合に責任を負う第三者に任せるのか、どちらがビジネス的に魅力的に聞こえる？自分でソフトウェアを書いて少しお金を節約しようとして大きなミスを犯した後に、自分の信頼を取り戻すより、他の誰かを責める方がずっと楽だよね。それがSaaSの価値提案なんだ。

└

ほんの数フィールドのはずが、そうじゃなくなることもある。SSO、SAML、SCIM、OIDC、OAuth、2FA、パスワードレス認証、検証トークンなどなど、そして、人気のあるシステムに合わせた各種のバリエーションがあって、正確な仕様をサポートしていないものもある。私の会社では、しばらくの間、サポートエンジニアの半分の時間が自社開発の認証システムで発生するランダムなSSOの問題に費やされていたよ。

└

あなたと同じくらい賢いと思うよ、だってsupabaseみたいなものが存在する理由が全然わからなかったから。これが、フロントエンド開発の世界がどれだけシンプルで安全なものから離れているかを示していると思う。

Hacker Newsで議論の続きを見る

ハクソク