2026/05/07 2:19
Supabase から Clerk、さらに BeyondAuth へと進化させる道
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Val Town は、信頼性の問題とベンダーロックイン回避の必要性を動機として、Clerk から Better Auth へ社会機能の移行を完了しました。Val Town は 2023 年末にこれらの問題について Clerk に対し問題を提起しておりましたが、状況は 2025 年 5 月以降悪化し、Clerk の稼働率は 2 nines から 3 nines の間で変動するようになりました。プラットフォームは以下のような重大な技術的制約に直面しておりました：ユーザーデータエンドポイントにはアカウント全体で合計 5 回のリクエスト/秒という厳格な制限がかけられており、これにより社会機能は本番環境での利用を不可能にしていました。また、Webhook の失敗はデータベース状態の不完全化を招き、ユーザー名など必須情報を持たないユーザーが生じる状況を生み出しておりました。その結果、Clerk は障害発生時に整个サイトを使用不能にさせる単一障害点となりました。
自立性と長期的な安定性を確保するため、Val Town は高いコード品質、オープンソースのコアアーキテクチャ、堅牢なフレームワーク統合（Remix、Fastify、Express を含む）を備えた Better Auth を選択しました。WorkOS AuthKit も検討はされましたが、単一のベンダーからの自由を維持する観点から却下されました。移行には、セキュリティを確保するためには徹底的な 2 週間を要し、大規模な手動でのコード書き換えとテストが行われました。重要な戦略の一つとして、完全に切り替える前に Clerk と Better Auth の両方のクッキーを受け付けるカスタムエンドポイントを採用しておりました。また、Val Town は Better Auth の有料「Infrastructure」アドオンを利用しており、これはステートレスでありセッション管理への参加を避けており、コア認証ロジックにサードパーティサービスに依存することなく将来のダウンタイムリスクを効果的に軽減しております。
本文
2023 年、私は Val Town が Supabase から撤退し、より従来のデータベース構成へ移行したことを書いています。当時は Supabase の機能を大きく依存しており、認証もその一つでした。しかし移行の期が来た際、我々は代用の選択肢を見つけました：データベースとしては Render、認証に関しては Clerk を選んだのです。ところが、事態は思わぬ速さで変化し、2023 年末には「Clerk から撤退せよ」という問題提起が行われました。この問題は、ようやく一ヶ月前に閉じられ、その際、我々は Better Auth に切り替えたのでした。
まず重要な文脈として、Clerk は莫大な成功を収めています。先日、5,000 万ドルの資金調達に成功し、極めて満足度の高いユーザー数还拥有しています。関連ニュースとして言えるのは、Supabase が 10 億ドルの評価額で 1 億ドルを調達したことですが、これら両社に対し、心から敬意を表します。私は決して優秀なベンチャーキャピタリストとは言えないでしょう。私が認証やレコードレベルのセキュリティについて抱く意見や体験は、これらの数字と実績に比べれば二次的なものです。成功には反論の余地はありません。それでもなお、その問題を解消し Better Auth に移行することができたことに喜びを感じています。しかしながら、そのプロセスは困難を極め、多くの工夫を要する回避策、バグ、そしてサイクリング（サービス妨害）に見舞われました。Val Town のアーキテクチャと Clerk の期待が、鋭く対立していたのです。
核心的な課題
核心的な問題は、Clerk が「ユーザーテーブル」と「セッションテーブル」の両方になろうとした点にあります。現在は言及を控えつつありますが、当初は極めて極端な方向性を示していました。2021 年のブログ投稿「ユーザーテーブルを削除することを検討せよ」、あるいは 2023 年の YouTube 動画「DELETE your Users table」といった主張から始まったのです。しかしながら、強く推奨いたします：やめてください！
ユーザーテーブルをサードパーティサービスに委譲することには、大きく分けて二つの重大な問題があります。
Clerk はユーザーテーブルの代替としての性能は非常に乏しかったです。理由はその API が厳格にレート制限されており、信頼性も低かったためです。当初移行した際、私は必要な都度 Clerk の API からユーザーデータを取得できると考えていました。畢竟、ユーザー設定、アバター URL、メールアドレスといった情報を把握したいからです。Clerk の SDK はこれを非常に利便性高く設計しており、アプリケーション全体の認証を担う
rootAuthLoaderloadUser特に Val Town の社会的側面において、このレート制限は打撃を受けました。例えば、ソーシャルウェブサイトのページには他のユーザーによるコンテンツのリスト、そのユーザー名やアバターが表示されることが一般的です。Clerk のデフォルト UI は、「ユーザーは自分自身のアバターしか見ず、設定や情報は JWT トークンから取得すれば良い」という前提に基づいています。Val Town などのソーシャルウェブサイトはこの前提を完全に破ります。その結果、アドバイスでは「Clerk と我々のユーザーテーブル間でアバターなどの情報を同期せよ」となりました。こうなると、その情報の権限が二か所に分散し、実質的に「2 つのユーザーテーブル」の複雑さへ直面することになります。
そのため、ウェブフックを用いて Clerk のデータを自社のデータベースへ同期する必要があり、その結果としてアカウント登録のプロセスは極めて複雑で難解になってしまいました。一時的にはユーザーは Clerk のアカウントを持つだけで Val Town 側のデータベース行を持たない状態が続いたり、または当プラットフォームがユーザー名を要求しているため、Clerk のアカウントとデータベース行は存在するものの、アカウント情報が未整備な不完全な状態に陥ったりしました。ユーザー設定も、認証手法のような Clerk が管理すべき部分と、ユーザー名やエディタ設定など我々が必要とする部分を分割する必要がありました。
二つ目は、Clerk がすべてのユーザーセッションの単一障害点（SPOF）となった点です。クッキーベースのユーザーセッションは通常、短命で定期的な更新を伴う仕組みであり、これにより迅速に無効化できます。しかし同時に、数分に一度新たなセッションクッキーへの入れ替えが必要となります。つまり、ログインセッションの更新が発生した際、そのリクエストを受け付けるのは Val Town のサブドメインであり、実際のリフレッシュ処理は Clerk が行います。我々はセッションテーブルを持っておらず、セッションに関する責任も負っていませんでした。
これは、認証における一切の責任を負わずに済もうとする場合に適しているのですが、一方で Clerck がダウンすれば全体サイトが停止してしまいます。Clerk の障害は単なるログイン・ログアウトフローの破綻だけでなく、既にログイン済みユーザーに対してサイトを使えなくしてしまう致命的な問題です。Clerk は比較的頻繁かつ長時間のダウンを繰り返しており、2025 年 5 月以来は可用性が「ニナイン」ないし「サナイン」（99.9%〜99.99%）の間で揺れ動いていました。それ以前のデータはありませんが、私個人としては多くの回、この単一障害点によりサイトが壊れ、修復手段を失った経験があります。
複雑なシステムを構築していく過程で学ぶ重要な教訓の一つは、「そのシステムの信頼性は、構成要素それぞれの信頼性の最小値に依存する」という点です。
これらの二大課題に加え、他のバグや問題も遭遇しました。多くはその後に修正されましたが、私は「自動閉鎖ボット（Stale Issue Bot）」との戦いに多くの時間を費やしました。
約三年
これほど問題があったにもかかわらず、なぜすぐさま切り替えなかったのかという疑問があります。
まず第一に、これが私が執筆する「X から Y に移行」シリーズの第二作目となりますが、これを習慣化するつもりはありません。意思決定を行いそれを維持することが開発 velocity（開発スピード）とチームの健全性のために重要です。Val Town の再書き換えは、必要最小限のものにとどめるべきです。また、批評を書くことよりも、実際に構築することの方が有意義で前向きな作業です。
第二に、Clerk もいくつか優れた点を持っていました。我々が利用しているすべての技術スタック（Remix、Fastify、Express）に対して SDK を提供してくれました。それらのフレームワークのバージョン変更やエコシステムの流動性に追いつく作業は、フルタイムの仕事であるにもかかわらず、そこでの対応は随分と良かったと言えます。また、顧客サポート課題の解決や詐欺対策など、管理機能や反悪用措置も実用的であり、助かりました。
Clerk が真に光る場所は、比較的シンプルで社会的要素を持たないフロントエンド主体のアプリケーションです。これらはユーザーテーブルを必要としないため、導入が非常に容易であり、安価で、Clerk のダッシュボードも使い勝手が良かったです。
さらに、認証サービスとして優れた選択肢は限られています。したがって、Clerk の代替となる製品へのハードルは高いものでした。多くのオープンソースの認証ソリューションは古く、半放棄状態にあります。認証即サービス（Authentication-as-a-Service）プラットフォームではベンダーリスクが存在し、Clerk 同様の問題を抱える可能性があります。技術的な制御水準を適切に保つことは容易ではありません。認証機能を自前で从零構築することで Val Town に新たな恥ずべき脆弱性を開くことは避けたい一方で、過度な責任を負託することも望みませんでした。特に、サードパーティのセッション管理を再び信頼する気はありませんでした。
Better Auth の登場
Better Auth は、出発点から多くの要件を満たしてくれました：高いコード品質、多様なフレームワークとの統合、そして真に独立したオープンソースプロジェクトとして実用的であることなどです。
依然としてベンダーリスクは存在します：主要な開発を一つの企業が担う大規模で複雑なコードベースです。ベンダーリスクは常に付きものです。しかしながら、セッションとユーザー認証が機能するためには、第三者がオンラインであることに依存し続ける必要はなくなりました。
runner-up（二位）に相応しいのが WorkOS 社製の AuthKit です。WorkOS を信頼しており、AuthKit も極めて洗練されていますが、二つのベンダー間を行き来した結果、最終的には「独立して動作し、核心部分はオープンソースである」ことができる製品を見つけることが重要でした。
また、Better Auth のダッシュボードと有料プラグイン（Infrastructure と呼称）も非常に巧妙です。我々はすべてのデータを自前で管理しており、プラグインによってサイトに API が提供され、それらのダッシュボードから情報を引き出したり、軽いユーザー管理を行えます。Better Auth の有料サービス（Infrastructure）は、我々の使用形態においてはステートレスであり、セッション管理には関与しません。
一言で言えば、現時点では明らかに Better です。
そして、多少の後ろめたさを感じつつもここに LLM（大規模言語モデル）に拍手を送らなければなりません。ロボットによる拡張により、過渡的な二週間に渡り Better Auth と Clerk の両方をサポートするより複雑な移行経路を選択することができました。認証を処理するすべてのエンドポイントでは、どちらの種類のクッキーを受け付けるように設計し、サインインページで提供されるセッション種別に合わせてユーザーが徐々に Better Auth へ移行していきました。セキュリティに関連するあらゆる作業と同様に、コードの精査、書き換え、テストを徹底的に行うことで「自己責任回避」を確認する必要があり、最終的な純粋な Better Auth 認証システムはすべて手書きによって実装されました。
Better Auth はまた、Vals（Val Town の開発環境）とも良好に動作します：Val Town にコードを追加する際に、Better Auth のスターターテンプレートを使用できます。
この過程で多くのことを学ばされました。uptime（稼働時間）においてアップストリームプロバイダーへの依存度が高いため、そのリスクへの曝露を慎重に検討する必要があります。製品はその多くのユースケースには優れ、極めて成功している一方で、特定の課題に対する最適解とは限らないのです。ソフトウェアの世界は急速に変化しており、必要な時点ですべての解決策が存在するとは限りませんが、一年後に現れるかもしれません。