Val TownのTom MacWright氏が書いたこの記事は、ひとことで言うと「認証サービス選びで痛い目を見て、ようやく落ち着きそうだ」という話です。
ただのツール乗り換え記事と思うと少しもったいないです。実際には、Webサービスにとって認証がどれだけ重要で、しかもどれだけやっかいかがよくわかる内容でした。しかも、理屈だけでなく「実際に運用してみたらこうだった」という生々しさがある。ここがかなり面白いです。
Val Townは、コードを書いて動かすタイプの開発プラットフォームです。単なる個人向けツールではなく、**ユーザー同士で見たり共有したりする“社会的な要素”**があるサービスです。
この「社会的な要素」が、認証サービス選びを難しくします。
たとえば、ログインした本人だけが自分の設定を見るだけなら、認証基盤はかなりシンプルで済みます。
でも、Val Townのように
となると、認証サービスだけに全部任せる設計は、かえって不自然になります。
記事では、Val Townが最初にSupabaseを使っていたことが語られます。
その後、より“普通のDB構成”へ移る中で、DBはRenderへ、認証はClerkへ移したそうです。
Clerkは認証SaaSとして有名で、導入しやすく、管理画面もわかりやすい。
だから「とりあえず認証を任せる」にはかなり魅力的です。
でも、Val Townではしだいに問題が出てきた。
そして2023年末ごろには「Clerkから離れたい」というIssueが立ち、ようやく1か月前にBetter Authへ切り替え完了した、というのがこの記事の主題です。
ここ、かなり重要です。
Clerkは当初、「ユーザーテーブルを外に出してもいいじゃないか」という発想を強く押していたようです。
つまり、アプリ側で users テーブルを持たずに、Clerkにユーザー情報を持たせる考え方です。
でも著者はこれにかなり否定的です。
私もこの感覚はかなりわかります。ユーザー情報って、アプリの根幹なんですよね。
Val Townでは、ユーザーの設定、アイコンURL、メールアドレス、ユーザー名などが必要でした。
ところがClerkに頼ると、次の問題が出ます。
ClerkのAPIには、当時かなり厳しいレート制限がありました。
記事では、あるエンドポイントが全アカウント合計で1秒あたり5リクエストだったと書かれています。
これはかなり少ないです。
しかも、開発中は便利に見える loadUser という仕組みがあっても、本番でその制限にぶつかった。
こういうのは本当に“地雷”で、導入時には見えにくいのに、運用で突然効いてくるんですよね。
Clerkの思想は「ユーザーは主に自分の情報を見る」という前提が強いようです。
でもVal Townは違う。他人のアイコンや名前を、いろんなページで大量に表示する必要がある。
この時点で、Clerkの設計思想とサービスの性質がズレています。
記事の指摘どおり、そういう場合はClerkの情報とアプリのユーザーテーブルの両方を同期することになり、今度は「ユーザー情報の正本が2つある」みたいな複雑さが発生します。
個人的には、これはかなりいやな設計です。
「便利になるはずだった外部サービス」が、気づけば二重管理と同期地獄の入口になる。あるあるですが、なかなかつらい。
次に大きいのが、session management（ログイン状態の管理）をClerkに強く依存していたことです。
セッションというのは、雑に言えば「ログイン済みの状態を覚えておく仕組み」です。
普通はCookieベースで短命にして、何分かごとに更新します。そうすると、万一漏れたときに被害を抑えられます。
でもVal Townでは、その更新処理をClerkに任せていた。
つまり、Clerkが落ちると、ログアウトや新規ログインだけでなく、すでにログイン中の人までサイトを使えなくなるわけです。
これ、かなり怖いです。
著者は、Clerkの障害が何度も起き、長引くこともあったと書いています。
2025年5月以降の稼働率も「2〜3 nines」と表現されていますが、これはだいたい99%〜99.9%くらいの稼働率を指します。
数字だけ見ると悪くなさそうでも、サービスによっては十分つらいです。
そしてここで出てくる一文が印象的でした。
複雑なシステムを作るときに学ぶ厳しい教訓は、全体の信頼性は重要部品の中で最も低いものに引きずられる、ということ
これは本当にその通りだと思います。
どれだけアプリ本体が頑張っていても、認証の土台が弱ければ、体験全体が崩れる。認証は“見えない部分”だけに、後回しにしがちですが、実は最重要部品なんですよね。
ここも大事です。
「そんなに不満があったなら、なんですぐ変えなかったの？」と思いますが、答えはかなり現実的です。
このあたり、すごくまっとうです。
ダメだったから即捨てる、ではなく、実害とコストのバランスを見て、我慢しながら使っていたわけです。ソフトウェア開発って結局これなんですよね。理想論だけでは回らない。
Clerkの良かった点としては、
といった点が挙げられています。
つまり、Clerkは「悪い製品」ではないんです。
むしろ成功していて、資金調達もうまくいっている。著者もそれを認めています。
ただし、Val Townというサービスの形には合っていなかった。ここがポイントです。
では、なぜBetter Authだったのか。
著者によると、Better Authは最初からかなり条件を満たしていたそうです。
この「オープンソースを中核に置く」というのが大きいです。
記事では、WorkOSのAuthKitも有力候補だったとしています。AuthKitはかなり洗練されていて信頼できるけれど、2回連続でベンダー依存を抱えたあとだったので、今度は独立して使えるものを選びたかった、という判断です。
ここはとても筋が通っています。
一度、外部依存で痛い思いをすると、「次はちゃんと自分たちで握れる部分を増やしたい」と思うのは自然です。
私ならたぶん、もっと早くそう考えると思います。
著者はBetter Authのダッシュボードと有料アドオンも評価しています。
ただし重要なのは、有料サービス部分は自分たちのセッション管理から切り離されていることです。
つまり、課金や管理の便利機能は使えても、認証の中核まで他社に握られない。
この分離はかなり賢いと思います。
要するに、
というバランスが取れているわけです。
認証の世界では、この「どこまで自前で、どこから外部か」の線引きが本当に難しい。Better Authはそこをうまく踏んでいるように見えます。
ここでちょっと驚くのが、ClerkとBetter Authを2週間並行運用したことです。
しかもLLMの助けを借りて、既存コードの対応をかなり複雑にしたとのこと。
具体的には、認証を扱うすべてのエンドポイントが、ClerkのCookieでもBetter AuthのCookieでも受け付けるようにしたそうです。
そして、サインイン画面がBetter Authのセッションを発行するようにして、ユーザーが自然に移行していった。
これは地味にすごいです。
認証の移行って、失敗すると即事故です。
だから、コードの読み直し、書き直し、テストを丁寧にやったという説明には説得力があります。
個人的には、ここで「LLMが役立った」と率直に書いているのも好感が持てました。
流行りの道具を持ち上げすぎず、でも実用的に使えたところは認める。この姿勢は健全だと思います。
この記事の価値は、単に「ClerkはだめでBetter Authはよかった」という話にとどまらないところです。
むしろ大事なのは、認証はサービスの性格とセットで考えるべきだという点だと思います。
導入が楽でも、運用で詰むことがある。
とくにレート制限や障害の影響は、実際に使ってみないと見えにくいです。
ユーザー名、アイコン、設定、メールアドレス。
こういう情報はアプリの中心です。
そこを外部サービスに全面委託すると、同期や整合性で苦しみやすい。
これが落ちると、ログイン中の人まで影響を受ける。
つまり、「ログイン機能の障害」ではなく「サイト全体の障害」になる可能性がある。ここは本当に重いです。
ClerkもSupabaseも成功している製品です。
でも、成功していることと、自分のサービスに最適であることは別です。
この当たり前だけど忘れがちなことを、記事はかなり実感をもって伝えています。
Val Townは、Supabaseから始まり、Clerkを経て、最終的にBetter Authへ移行しました。
その背景には、認証基盤を外部に寄せすぎたことで起きるレート制限、同期の複雑さ、障害時の脆さがありました。
読んでいて思ったのは、認証って本当に「地味なのに超重要」だということです。
派手さはないけれど、ここで失敗するとサービス全体が揺らぐ。
だからこそ、**“楽に始められるか”より“自分たちの形に合うか”を見極めるべき**なんだと思います。
Better Authが今後もVal Townにフィットし続けるかは、もちろんこれからですが、少なくともこの記事からは、「ようやく自分たちの手に戻ってきた」という安堵感が伝わってきました。これはかなり大きいです。
