Better Authという選択──AI時代に認証基盤のコードを持つ意味とは / better-auth-ai-era

Transcript

1. Better Authという選択 〜 AI時代に認証基盤を持つ意味 〜 2026.07.31 【BetterAuth】今TypeScriptで開発するなら、認証は何が正解？ 認 証 ラ イ ブ ラ リ の 最 適 解 # O f f e r s _ D ee p D i v e 1
2. 問い プロダクトを立ち上げるにあたり、 IDaaSを利用することは 本当によい選択なのだろうか？ 2 © 2026 Pluralworks LLC
3. 自己紹介 池内 孝啓 - Takahiro Ikeuchi プロダクトエンジニア / 合同会社プルーラルワークス代表 10年以上のCxO経験 〜 ゼロイチ開発・Biz/Devの橋渡し スタートアップCTOとして2社、CEOとして1社、10年〜のCxO経験。 技術的な理想論だけではなく事業数値に向き合うゼロイチ開発が得意。 AI時代の現役フルスタックエンジニアとして フロントエンド（React） バックエンド（Python、Go、Bun) モバイル（Flutter、React Native） イ ン フ ラ 、 A I エ ー ジ ェ ン ト e t c . .. 3
4. 自己紹介 https://www.pluralworks.ai/ 4
5. 実践の裏付け https://www.pluralworks.ai/ 5
6. IDaaSの選択肢あれこれ Firebase Auth Supabase Auth AWS Cognito Okta Auth 0 Clerk など。 6
7. IDaaSのメリット 1. 認証基盤開発のショートカット 認証基盤に独自性は必要ないことが多く、車輪の再発明をしがち。 IDパスワード、OAuth、二要素認証etc... 地味だがやることは結構多い。 2. 信頼性のあるセキュリティ体制 認証基盤はセキュリティが最重要。IDaaSは多くがエンタープライズ要件に足る セキュリティ体制を構築しており、これを利用することができる。 ……と言われている。 7
8. 推しIDaaS 開発体験がとてもよい スモールスタート B2Bマルチテナント対応 UI統合しやすい 無料枠有り https://clerk.com/ 8
9. IDaaS導入のデメリット 1. ロックイン問題 ユーザーIDという重要な情報を外部サービスに依存した状態で管理することになる。 利用するプラットフォームについてはユーザー数などによる従量課金が生じる。 2. データ同期問題 IDaaS = ユーザーIDの外部データベース。アプリケーションのデータベースと どのように同期・同調するかという問題が付いて回る。 9
10. ロックイン問題対策 アプリケーション内部発行のIDとIDaaS由来のIDを分けておくこと で、IDaaS基盤の乗り換え、仕様変更によりID体系が破壊されないよ うにする。 アプリケーション側の user テーブルの例）: user_id external_id（IDaaS由来） その他カラム... 73b9da52-d232-4eb0-9c16f42e9837f2e3 Nzk3NjU1MTktYTVkNS00N2Rh ... 10
11. ロックイン問題対策 ただ、自分の経験上IDaaSを乗り換えたり、利用を取りやめた経験は ないです... 公開事例 : 11
12. データ同期問題 IDaaS側データ アプリ側RDB Webhook リトライ エラー時の制御 要件によるが、IDやメールアドレスなどの同期が必要に エッジケース対応... なる場合が多い 12
13. データ同期問題 Webhook リトライ エラー時の制御 エッジケース対応... 開発コストを下げるのが目的だったのでは...? 13
14. IDaaSを使っても 関心事がゼロになるわけではない 14
15. 自社開発とSaaSの間に 自社開発 Better Auth IDaaS 開発コスト 高 低〜中 低〜中 学習コスト 高 低〜中 中 データベース 内部 内部 内部 運用費 なし なし 従量課金 メンテナンス 必要あり ある程度信頼 信頼 15
16. Better Authをひとことでいうと TypeScriptベースのバックエンドアプリ に認証関連機能を追加できるもの 16
17. Better Authのメリット 1. 認証基盤開発のショートカット + ロックインなし + 追加費用無し 導入は数分から。IDパスワード認証、OAuth、二要素認証、MCP向け認証まで。 2. データベースはアプリケーションのDBと同じ バックエンドアプリケーションと同じRDBを利用するため、外部DB不要。同期不要。 3. ノー・ノーコード TypeScriptライブラリのみ。すべてをコードで書く。 17
18. AI時代にコードがあることの恩恵 コーディングエージェントにより、ノーコードツール の強みが相対的に減退。 とくにサービス運用を伴わない類のシステムで顕著。 コードによる管理 >>> GUIによる管理 ※ 認証基盤はサービス運用をともなうが、アプリケー ションに相乗りするため、追加がない。 18
20. Better Authのデメリット 1. 運用はセルフマネージド。セキュリティへの配慮は必要（だが...） アプリケーション上のライブラリとして機能するので、運用は自前。 セキュリティ面への配慮も自己責任。 => だが、認証基盤だけがセキュアで、その他アプリケーションは杜撰でよい、という 状況設定はありえるのだろうか...? IDaaSを使っても最終責任は自分（自社） 。 2. Better Auth自体の継続性 OSSが継続的にメンテナンスされるかは常に気になりごと。今のところは活発。 => forkするなどしてリスク回避は可能。 ※ 最近Vercelに買収されました https://vercel.com/blog/vercel-acquires-better-auth 20
21. まとめ IDaaS利用 or 自前実装のあいだのベターソリューション （Better Authだけに） コードで定義する、というスタイルはAI時代と相性が良い 21