B2B SaaS 開発者に最適なセルフホスト型 CIAM

SaaS 型の CIAM プラットフォームの価格を調べたことがあるなら、想像以上に高額になりがちだと気づき、セルフホスト型を検討したことがあるはずです。

この記事で扱うのは、小規模な B2B SaaS チームが 2 つ目のフルタイム業務にせずに実際に運用できる 4 つのセルフホスト型 CIAM プラットフォーム、ZITADEL、FusionAuth、Logto、Ory Hydra です。4 つは同じ形をしておらず、どれが適しているかは機能一覧よりも、どんな B2B プロダクトを作っているかで決まります。この比較をまとめるため、1 台の VPS 上で 1 週間並べて動かしました。以下は、CIAM について DM をくれた創業者に私が送る内容そのものです。

最初に一点。ここで扱うのはプロダクト機能としての CIAM であり、自社チーム向けの社内 SSO ではありません。

短いバージョン

セルフホスト型 CIAM プラットフォーム 4 つを、それぞれ 1 行で:

• ZITADEL マルチテナンシーと B2B 組織を最初から使いたい場合。
• FusionAuth 洗練された管理 UI と、長く予測しやすいリリース履歴が欲しい場合。
• Logto 初日の開発者体験がいちばんすっきりしているものが欲しい場合。
• Ory Hydra プロトコルレベルで作り込む人向けで、決め打ちのログインアプリではなく OAuth 2.0 エンジンが欲しい場合。

結論として、典型的な B2B SaaS にとって最も安全な最初の選択は ZITADEL であり、以降の章でその根拠を掘り下げます。

CIAM が社内 SSO とは別の判断になる理由

社内チーム向けの SSO が落ちても、被害はたいてい限定的です。エンジニアが 1 時間ほど Grafana など社内ツールにアクセスできなくなる程度でしょう。CIAM が落ちると、課金中の顧客はプロダクトにまったくログインできません。これによって判断基準は「どの認証ツールが自社チームにとって便利か」から「プロダクトの一部として信頼できる認証システムはどれか」へと変わります。

B2B SaaS が必要とする種類のアイデンティティ基盤である CIAM には、社内 SSO ツールの多くが重視しないプリミティブも求められます。顧客は単一のユーザーではなく、独自のユーザー、ロール、ブランディング、場合によっては企業 IdP への独自の SAML 接続を持つ組織（テナント）です。単に人を認証するのではなく、同じプロダクトの中である企業のユーザーを別の企業のユーザーから隔離しているのです。以下の 4 つのツールは、この B2B の形をそれぞれ異なるやり方で狙っています。 Keycloak には現在、第一級の Organizations があります。そのため、社内向け専用だと切り捨てるのはもう古い見方です。除外した理由は FAQ で説明します。

自作するか、買うか、セルフホストするかという三択もここでは様相が違います。OAuth をゼロから書くのは避けられるはずの失策です。あなたが世に出すのは SaaS プロダクトであって、アイデンティティプロバイダーではありません。マネージド（Auth0、Clerk、WorkOS）を買うのは、チームに運用の余力がまったくなく、まともな予算がある場合の正解です。2 人のスタートアップに初日から認証をセルフホストしろとは絶対に言いません。セルフホストが合理的になるのは、マネージド CIAM の MAU 単価がインフラ費用と継続的なエンジニアリング時間の合計を上回ったとき、あるいはデプロイとデータプレーンを直接制御する必要があるときです。私が関わってきたチームでは、その分岐点はたいてい「本物のプロダクトができた」と「本物のカスタマーサクセス機能ができた」の間に訪れます。

顧客のアプリではなく自社アプリ向けの SSO を探しているなら、それは本記事とは別の比較になります。では、おすすめの 4 つを見ていきましょう。

4 つのツールを 1 つずつ

この 4 つを選んだのは、社内 SSO としてだけでなく、プロダクト基盤として評価できるだけの CIAM らしさがあるからです。ZITADEL、FusionAuth、Logto、Ory はいずれも実用的なセルフホストの道筋があり、真剣に検討するだけの実績もあります。ライブラリのみのもの、社内 SSO 寄りのもの、成熟度の低いものは FAQ で扱うほうが適切です。

ZITADEL

ZITADEL はスイス発の ID プラットフォームで、Go で書かれ、イベントソーシング型のアーキテクチャと PostgreSQL バックエンドを採用しています。2026 年 7 月 27 日時点の GitHub 最新リリースは the 4.16 series, current as of July 2026。ZITADEL は v3 から Apache 2.0 を離れて AGPL-3.0 に移行しました。通常の SaaS 利用であれば実務上の影響は聞こえるほど怖くないことが多く、詳細は FAQ で説明します。

B2B SaaS において ZITADEL が際立つ点: 組織とマルチテナンシーが第一級のプリミティブである。汎用オブジェクトを組み合わせて作る機能ではありません。Organization を作成すると、そこに固有のユーザー、ポリシー、ブランディング、アクセス設定が付き、プロジェクトを付与すればその組織の管理者が自分たちのユーザーのロール割り当てを管理できます。汎用ユーザーの上に「テナント」という概念を自分で発明する必要はありません。最初からそこにあります。

開発者体験は API ファーストで、現行の v2 REST リソース API に加え、レガシーな v1 サービスへの gRPC/REST アクセスも用意されています。公式およびコミュニティの SDK が主要なサーバースタックをカバーします。管理コンソールは実用的ですが、FusionAuth のものより素っ気ない作りです。

私の見立て: B2B SaaS を作っていて、テナントが必要になるとわかっているなら、私なら ZITADEL から始めます。セルフホスト型の選択肢の中で、B2B ログインの課題を最も明確に中心に据えて設計されているのがこれです。

FusionAuth

FusionAuth は Inversoft, LLC（FusionAuth の名で事業を行うデラウェア州の LLC）による米国発のプラットフォームで、他の 3 つより歴史が長く、それが良い意味で表れています。管理 UI は他より明らかに作り込まれており、ドキュメントは成熟し、リリースのペースは慌ただしくなく安定しています。4 年前に書かれた認証まわりの実装を引き継いだとき、退屈な選択をしてくれた前任者に心の中で感謝した経験があるなら、FusionAuth はまさにその感謝に値する CIAM です。

つまずきやすいのはライセンスです。FusionAuth Community はセルフホストなら無料ですが、コア製品はオープンソースではありません。この製品を規定するのは FusionAuth 独自のライセンス。この制限は、FusionAuth を再配布・組み込み・リブランド・再販、あるいは自社の顧客向けにホストする予定がある場合に効いてきます。セルフホストの Community 版は B2B SaaS の中心的なユースケースをカバーします。 有料プランでは機能が追加され 、IdP 起点の SAML、高度な MFA、アプリケーション別テーマなどが含まれます。一方で SCIM、Tenant Manager、アプリケーション単位の MFA ポリシーは Enterprise に含まれます。

B2B の形について。FusionAuth はテナントとアプリケーションをモデル化しますが、その抽象は「ドメインオブジェクトとしての B2B 組織」ではなく「テナントごとにコンテナ化された認証」に近いものです。これでも動きます（実際に製品をリリースしました）が、マルチテナンシーは第一級の B2B モデルというより隔離のためのプリミティブに感じられます。公式 SDK とクライアントライブラリは幅広く揃っています:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

サーバーサイドのライブラリは薄い API クライアントです。管理コンソールは、他と比べてエンジニアでない運用担当者に任せやすい作りになっています。

私の見立て: チームが B2B ネイティブなプリミティブよりも UI の完成度と長く予測しやすい歴史を重んじるなら、FusionAuth です。ここで最も「退屈な」選択肢であり、それは褒め言葉です。

Logto

Logto は 4 つの中で最も新しく、Silverhand Inc. が開発しており、 MPL-2.0 ライセンスで提供されています、ダッシュボードへのこだわりが最もはっきり見て取れるプロダクトでもあります。初日のセットアップは比較的速く、プロビジョニングしてウィザードを進めれば、15 分ほどでまともなデフォルトのログイン UI を備えた OIDC プロバイダーが動きます（4 つを並べて動かした週に実際に計測しました）。公式のクイックスタートはモダンなフレームワークとサーバースタックを網羅しているので、スタックが「Next.js + Postgres + 何か」であれば違和感なく入れます。

その B2B に対する答えが Logto Organizations。組織メンバーシップ、組織スコープのロール、メンバー招待、ジャストインタイムプロビジョニング、エンタープライズ SSO 連携といった B2B の中核プリミティブをカバーします。組織モデルは ZITADEL のものより新しいため、変わった SAML・SCIM・フェデレーションのフローがあるなら、本格導入の前に想定顧客で検証しておくことをおすすめします。

トレードオフは成熟度です。Logto はここで最も新しい選択肢です。ロードマップの進みが速く、必要な機能が来るときは素晴らしい一方、破壊的変更が来るときは落ち着きません。あなたの B2B SaaS がマルチテナンシーの単純な側（組織数が少なく、風変わりなフェデレーション要件がない）にあるなら、Logto の開発者体験が残りの判断を楽にしてくれます。

私の見立て: 初日を最速で立ち上げたく、B2B の要件がまだ比較的シンプルなら Logto です。

Ory Hydra（および Ory スタック）

Ory Hydra は Ory エコシステムの OAuth 2.0 / OpenID Connect サーバーで、 Apache-2.0 ライセンスです。Ory スタック全体では、Hydra に Ory Kratos（アイデンティティとユーザー管理、セルフサービスのログイン、登録、MFA、アカウント復旧）、Ory Keto（ポリシー決定ポイントとして働く Zanzibar 型の認可サーバー）、Ory Oathkeeper（受信 HTTP リクエストを認証・認可・変換するアイデンティティ＆アクセスプロキシ）が組み合わさります。必要なものだけ自分で組み立てる形です。すべて Go で書かれており、API はきれいです。

注意点（これは欠点ではなく、適したチームにとっては長所です）は、Hydra がアプリケーションではなくエンジンだということです。設計上、 Hydra は別途用意するログインおよび同意アプリに接続します 。このアプリはあなたが用意します。すぐ使えるログイン画面が欲しいなら、これは違うツールです。逆に、認証フロー自体がプロダクトの一部になるようなもの（開発者プラットフォーム、独自の B2B ポータル、独自オンボーディングを持つ API ファーストの製品）を作っているなら、押し付けられた UI がないことこそが望ましい特性です。

B2B のストーリーはターンキーではなくコンポーザブルです。Kratos のスキーマと Keto のリレーションを自前の組織レイヤーに配線すればマルチテナンシーをモデル化でき、実際に動きますが、その配線をするのはあなたです。コストは配管作業が増えること、対価は体験を自分で制御できることです。Ory のドキュメントはプロトコル面を深くカバーしていますが、コンポーザブルなモデルはプロトコルレベルの判断を自分で下せることを前提にしています。「audience claim」や「PKCE」がピンとこないなら、他の 3 つから始めてください。

私の見立て: プロトコルレベルのもの（認証ゲートウェイ、独自フロー、開発者プラットフォーム）を作っていて、既製アプリが窮屈に感じるなら、Ory が正解です。今日ログインを動かしたい典型的な B2B SaaS にとっては、そうではありません。

ひと目でわかる比較

4 つのツールの要点を 1 つの表にまとめました。二読目に便利ですが、上のプロフィールを読む代わりにはなりません。

どれから始めるべきか

この件で相談を受けるチームの大半をカバーする、4 つの短いシナリオです。

B2B SaaS を作っていて、テナントが必要になるとわかっている場合。 ZITADEL から始めましょう。マルチテナンシーと組織のプリミティブはまさにこの用途のために設計されており、API の表面積も網羅的で、テナントモデルを自作する時間は他の 3 つより少なくて済みます。AGPL への移行はライセンス確認に値しますが、改変せず別個に統合したデプロイであれば、通常は素直な SaaS ユースケースです。

洗練された管理 UI と、安定して予測しやすいプラットフォームが欲しい場合。 FusionAuth です。Community プランは多くのチームの中核的なニーズをカバーします。ただしライセンスと機能マトリクスを丁寧に読む時間は見込んでおいてください。IdP 起点の SAML、高度な MFA、アプリケーション別テーマといった機能は有料プランが必要で、SCIM、Tenant Manager、アプリケーション単位の MFA ポリシーは Enterprise に含まれます。

現時点の B2B 要件はシンプルで、初日を最速で立ち上げたい場合。 Logto です。並べて試したテストでは、初日の開発者体験が最も速いものでした。より若いエコシステムに賭けることを受け入れ、要件が未検証のフェデレーションのエッジケースに広がったら選択を見直してください。

認証フローがプロダクト体験の一部になるものを作っている場合。 Ory Hydra（必要に応じて Kratos、権限が要るなら Keto も）です。書くコードは増えます。その分、制御できる範囲も増えます。このトレードが腑に落ちないなら、あなたは Ory の対象読者ではありません。他の 3 つから選んでください。

この説明のうち 2 つが自分に当てはまるなら、既定で ZITADEL を選んでください。もっとも幅広く適合し、細かい追加質問なしに小さな創業チームへ渡せるのがこれです。

セルフホストの代償（運用面で）

ここからは、この記事のロマンのない部分です。

PostgreSQL のバックアップ運用は、いまやビジネスが依存する要素です。これらの構成では、守るべきアイデンティティ状態にユーザーレコード、ハッシュ化された資格情報、MFA のシークレット、OAuth クライアントの資格情報、セッションデータが含まれ得ます。この状態を失えば、顧客はログインできなくなる可能性があります。最初の実ユーザーが登録する前に自動バックアップを用意し、リストアを検証し、バックアップの健全性をアプリケーションの稼働監視と同じアラートチャネルに載せてください。

リリースのペースは時期によって変わります。ZITADEL v4.16.1 は 6 月に複数のリリースを経て 2026 年 7 月 17 日に出ましたが、ここで挙げた各プロジェクトはそれぞれ独自のペースと互換性ポリシーを持っています。このペースは保守上の関心事として扱い、品質を測る近道と考えないでください。docker compose pull を実行する前にリリースノートを読み、定期的なパッチ適用の枠を確保しましょう。アイデンティティプロバイダーの更新を何か月も飛ばすと、最初の本格的なレビューでセキュリティ・互換性の修正から取り残されかねません。

いつも後ろから忍び寄る地味な作業: TLS 証明書の更新（Let's Encrypt を使うリバースプロキシを立て、更新を自動化し、失敗時にアラートを出す）、確認メールとパスワードリセット用の送信メール設定（SES、SendGrid、Postmark のどれかを選び、SPF/DKIM/DMARC をきちんと設定しないとリセットメールが迷惑メールに落ちます）、エンジニアが退職したときの OAuth クライアント資格情報のローテーション、そしてクレデンシャルスタッフィング攻撃で CPU が張り付かないようログインエンドポイントにレート制限をかけること。

ヒント: マネージド Postgres を使う場合、実行時のデータベースユーザーがスキーマまで作成できると決めつけないでください。データベースとユーザーを先に作成し、必要な所有権またはセットアップ権限を付与し、各ツールが期待する資格情報で初回セットアップを実行しましょう。そうしないと初回実行が曖昧なデータベース権限エラーで失敗し、見当違いの原因を追って 1 時間を溶かすことになります。

セルフホストの道がドルで節約させてくれる分は、オーナーシップとして請求されます。構築後は、アイデンティティ層を健全に保つために月あたり数時間のエンジニアリング工数を確保してください。時間をまったく割かないチームは、たいてい後になってその費用に気づきます。障害の最中、奇妙な SAML のエッジケース、あるいは最初のセキュリティレビューの場で。

どこにデプロイするか

Docker Compose を動かす Linux VPS は、評価用途や控えめな負荷であれば妥当な出発点になり得ます。ただし本番のサイジングと高可用性は、トラフィック、セキュリティ要件、そしてダウンタイムをどこまで許容できるかで決まります。よくあるデプロイ方式の位置づけは次のとおりです:

• 共有ホスティング はどれも動かせません。永続ストレージ、任意のポート、コンテナランタイム用の root 権限、そして本物のデータベースバックエンドが必要だからです。このリストの大半では PostgreSQL が既定の選択肢ですが、すべてのツールで唯一サポートされるデータベースというわけではありません。
• Kubernetes は 4 つとも動かせますが、公式サポートの手厚さにはばらつきがあります。 ZITADEL, FusionAuth、そして Ory は公式の Helm チャートを公開している一方で、 Logto のセルフホストに関するドキュメント は Docker と仮想マシンでのデプロイに重点を置いています。Kubernetes が他の用途で元を取れる段階にまだ達していない小規模な B2B SaaS にとっては、たいてい過剰設計です。インフラの残りがすでにそこにあるときに手を伸ばしましょう。
• ベアメタル は、すでにベアメタル上にいるなら問題ありません。ほとんどの B2B SaaS チームはそうではありません。

小規模な単一ノードのパイロットなら、私は 4 GB RAM、2 vCPU、60 GB の NVMe ストレージから始め、その後で実際のログインフローに負荷テストをかけます。これは計画の目安であって、万能な本番最低要件ではありません。アプリケーション自体は比較的軽量ですが、PostgreSQL にはメモリが、パスワードハッシュには CPU の余裕が必要です。 ZITADEL の本番運用ガイダンス では、パスワードハッシュのスパイクに備えて CPU コアを 4 つ確保することを推奨しています。

プロダクトが実在し、トラフィックが継続するようになったら、実測値をもとにサイズを見直しましょう。高速ストレージは PostgreSQL のレイテンシに効き、CPU の余裕は同時並行のパスワードハッシュで効いてきます。どれか 1 つのリソースが最重要だと決めつけず、メモリ、データベース I/O、ログインのレイテンシ、CPU の飽和度を観察してください。

CIAM を本番で動かすということは、その稼働率がこれからはあなたの責任になるということです。私たちはこの種のワークロードに Cloudzy Linux VPS インスタンスを使っており、NVMe ストレージと、基盤プラットフォームでの 99.95% 稼働率 SLA を備えています。Cloudzy はさらに、 ワンクリックの ZITADEL VPS 初期のプロビジョニングスクリプトを省きたい場合に使えます。他の 3 つは Docker ベースのセットアップ用に公式コンテナイメージを提供しています。アクセス制御がセキュリティ体制全体のどこに収まるかをマネージャー目線で押さえたいなら、 IAM のベストプラクティスガイド ポリシーの側面から解説しています。

よくある質問

ZITADEL の AGPL ライセンスは自社 SaaS に影響しますか？

改変せず別個に統合したデプロイであれば通常は影響しませんが、これは法的助言ではありません。ZITADEL の AGPL 上の義務は ZITADEL 自体に及びます。ZITADEL を改変し、その改変版をネットワークサービスとして運用する場合、ライセンスにより対応するソースコードを AGPL の下で提供する必要が生じ得ます。ZITADEL が公表している立場では、改変していないインスタンスを自社 SaaS の ID サービスとして利用するだけでは、それ自体で別個のアプリケーションを AGPL でライセンスする必要は生じないとされています。 ZITADEL のライセンス告知 を読み、ソフトウェアを改変・再配布・組み込み、あるいは第三者へ提供する場合は法的助言を得てください。商用ライセンスも用意されています。

なぜ Keycloak や Authentik はこのリストに入っていないのですか？

Keycloak も Authentik も優れたセルフホスト型 ID ツールで、私自身も使っています。ただし「B2B の組織機能がない」という理由で Keycloak を外すのは、いまや誤りです。現行の Keycloak リリースには Organizations、組織グループ、権限委譲による管理機能が含まれています。今回外したのは、本比較が小規模チームの B2B SaaS にとってより直線的な道筋を持つ 4 つに絞っているからです。JVM の運用、エコシステムの厚み、realm 単位の柔軟性が重要なら、Keycloak は独立した評価に値します。Authentik は依然として、プロダクト内蔵のテナントモデリングよりも、社内向け SSO や社内アプリに向いています。

セルフホストは Auth0 より安いですか？

MAU が少ないうちは、たいてい安くなりません。アーリーステージのスタートアップ帯では、エンジニアの工数のほうが Auth0 の請求額より高くつきます。セルフホストが経済的に勝つのは、マネージド CIAM の MAU 単価が、小さな VPS と月あたり数時間のエンジニアリング工数の合計を上回る規模になったときです。正確な損益分岐点は、チームの時間単価、MAU の成長カーブ、そして Auth0 の上位プランに押し上げられるようなエンタープライズ機能が必要かどうかで決まります。節約は本物ですが、即効性はないと考えてください。

本番の CIAM に必要な最小の VPS サイズは？

小規模な単一ノードのパイロットなら、4 GB RAM、2 vCPU、NVMe ストレージは妥当な出発点であって、本番の保証ではありません。データベースの規模、同時ログインの負荷、パスワードハッシュのコスト、稼働率目標からサイズを決めてください。ZITADEL 自身の本番ガイダンスは、ハッシュのスパイクに備えて CPU コアを 4 つ確保することを推奨しています。他のツールやトラフィックパターンには、それぞれの負荷テストが必要です。

後からマネージド CIAM をセルフホストへ移行できますか？

できますが、本気のプロジェクトとして計画してください。パスワードリセットが不可避とは限りません。エクスポートのしやすさやサポートされるハッシュ形式は移行先によって異なり、 一括またはジャストインタイムのユーザー移行 を扱える移行先もあれば、リセットを避けられない移行先もあります。MFA の要素、OAuth クライアント、アクティブなセッション、メール確認の状態、テナントやロールのマッピングは、それぞれ別途対応が必要です。将来セルフホストするかもしれないと今から思っているなら、マネージド事業者を選ぶ前にこれらのエクスポートと移行の制約を書き留めておきましょう。