Stack AuthからHexclaveへ、認証基盤がユーザーインフラへ広がる転換

冒頭で押さえたいのは、Hexclaveが最初から「何でも入り」のplatformとして始まったわけではないことだ。

出発点はStack Authという、authenticationだけでなくauthorization・user managementまで扱うopen-source projectだった。出典

認証への不満から始まった

創業者のKonstantin WohlwendとZai Shiは、既存の認証サービスに対する不満を出発点にした。

YCのローンチ文で二人は「User authentication sucks. Existing solutions are a pain to set up and have hostile pricing, terrible documentation, and vendor lock-in.」と説明している。出典

ここで問題にされたのはログイン画面だけではない。

organizations・permissions・RBACまで自前でつなぐ負担だった。

open-sourceを退出経路にする

2024年7月のShow HNでは、Stack Authをmanagedでもself-hostedでも使えるopen-source platformとして紹介した。

ユーザーデータを特定vendorに閉じ込めず、必要ならexportして自分で運用できる、という設計である。出典

これは価格の安さよりも、将来の選択肢を残すことを価値にした。

Stack AuthからHexclaveへ

転機は、認証の周辺機能を増やすことではなく、user infrastructure全体へ視野を広げたrebrandだった。

現在のGitHub repositoryは、authentication・teams・RBAC・API keys・payments・emails・analyticsなどを共通のuser modelで扱うplatformとしてHexclaveを説明している。出典

公式docsもSDK、CLI、dashboard、REST APIを一つの導線に置く。

deployまで広げた現在

現在のHexclaveは、frontend・backend・database・workersを一緒にdeployする体験を前面に出す。

公式サイトの「Your next deploy starts with a prompt」という導線は、coding agentを入口に、サービスの構成と運用をまとめる発想だ。出典

ただし、Stack AuthからHexclaveへの変化はまだ進行中で、具体的な売上やCloudの顧客規模は公開情報だけでは要確認である。

この道のりから見えるのは、単機能の代替品を作るより、最初に集めたユーザー・権限・チームの文脈を別の運用へ持ち運ぶ戦略だ。

認証を入口にしたことが、platform化の足場になっている。

HexclaveのPMFは、認証だけでなくteams・RBAC・payments・emails・analyticsまで必要になるB2Bアプリの開発チームにある。

公式docsは、SDK・CLI・dashboard・REST APIを組み合わせ、ユーザーまわりの機能を一つのuser modelで扱う構成を示している。出典

一方、Hexclaveは「自分で選んだfrontend・backend・databaseを残しながら、運用部品をまとめたい」チームに寄る。

Stack Auth時代のopen-source/self-hostableの約束を引き継ぎつつ、deployまで広げた点が、認証専業との差分になると考えられる。出典

技術的なmoatは単一機能ではなく、認証・ユーザー管理・権限・決済・deployを横断するデータモデルとSDKの蓄積にある。

GitHub公開コードとself-hostingは模倣障壁を下げる一方、移行コストと運用知識の蓄積が残る。出典

ネットワーク効果は弱い。

利用者が増えても認証データそのものの価値が自動的に増えるわけではない。

ただし、open-source contributors・integration・communityが増えるほど対応frameworkと周辺moduleが充実する間接効果は期待できる。出典

主な対象は、B2B SaaSやAIアプリを少人数で作る開発チーム。

auth・organizations・RBAC・API keys・deployを別々に組む余裕がなく、しかしfrontendやdatabaseを特定vendorへ全面移行したくないチームに合う。

大規模企業向けの厳密なSLAや既存IAM連携が最優先の組織は、要件確認が必要だ。

第一は、Stack Auth時代からのopen-sourceとself-hostingの選択肢である。

ベンダー依存を避けたい開発者に、managedと自前運用の両方を提示できる。出典

第二は、auth・teams・RBAC・paymentsを同じuser infrastructureとして束ねること。

機能の追加を個別SDKの寄せ集めにせず、共通のユーザー／チームモデルへ接続することが差別化になる。出典

最大のリスクは、authentication platformからdeploy platformへの拡張が、製品の焦点をぼかす可能性である。

authを求める利用者と、frontendからworkerまでのdeployを求める利用者は同じとは限らない。

また、公式サイトは無料開始とpaid planを示すが、公開された具体的な価格・売上・顧客数はこの調査で確認できなかった。出典

事業規模や収益性は要確認であり、open-sourceの採用がCloud売上へ結び付くかは未検証である。

成長の入口は、Stack Authで作ったopen-source・GitHub・YC・developer communityである。

そこからCLIとagent向けpromptを使い、セットアップの摩擦を下げる。出典

今後の課題は、free/self-hostedで得た採用を、Cloudの継続課金へ変える導線だ。

deploy・payments・analyticsなどを同じuser infrastructureに置くことで、利用範囲を広げる戦略と読めるが、価格表と転換率は要確認である。

主要チャネル: open-source, github, yc, community, content

認証のような単機能から始めても、隣接するユーザーまわりの仕事を共通モデルで束ねれば、より大きな開発課題へ進める。

ただし拡張は機能数の競争ではなく、同じデータとworkflowで自然につながるかが条件になる。

また、open-sourceは無料版の宣伝ではなく、self-hostingという退出経路まで含めて信頼を設計する手段になり得る。

日本のB2B SaaSでは、organization・権限・監査・請求の要件が顧客ごとに細かくなりやすい。

Hexclave型のuser infrastructureを展開するなら、国内の請求・データ保管・サポート要件と、既存の社内IdP／SIer連携を先に整える必要がある。

日本向けには、英語docsを翻訳するだけでなく、権限設計と運用監査の実装例を業種別に提供することが採用の鍵になると考える。