DRESS CODE TECH BLOGPublicationへの投稿
🔐

認証基盤をCognitoからOry Kratosへ：B2B SaaSの「当たり前品質」を守るためのリプレイス戦略

ぽこひで
に公開
認証
orykratos
tech

Dress Code Advent Calendar 2025の12日目の記事です。

こんにちは。11月にDress Code株式会社に入社した、ぽこひで( @pokohide ) です。入社後、認証基盤のリプレースを担当することになり、既存のAmazon CognitoからOry Kratosへ移行するという意思決定を行いました。

弊社は創業からまだ1年程度ですが、事業の急成長に伴い、認証周りの課題が早期に顕在化していました。 本記事では、 「なぜ Cognito から Ory Kratos へ移行するのか」 を背景・検討プロセス・選択の決め手という観点から整理して紹介します。

1. Cognitoからの脱却：構造的限界と技術的負債

創業期はAWSエコシステムとの親和性を重視しCognitoを採用していましたが、B2B SaaSとして求められる品質基準に対応する過程で、以下の3つの構造的な課題に直面しました。

① 開発者体験の悪化と保守性の低下

Cognitoの標準機能で満たせない要件（ユーザーID/Emailの併用ログインや複雑なMFAフロー等）を実現するため、特定のLambdaトリガーに処理を集中させる必要があります。これにより、単一Lambdaの責務が肥大化し、保守性が低下する懸念がありました。

また、このアーキテクチャはローカル環境での再現やデバッグが困難です。LocalStackの導入などによる環境再現も試みましたが、AWS基盤を経由するイベント駆動型の複雑な通信経路そのものは変わりません。結果として、ローカルでのデバッグやテストが困難な状況は解消されず、バグの混入やセキュリティインシデントを見逃すリスクが高まりつつあると判断しました。

② ステートレスとステートフルの混在によるアーキテクチャの歪み

Cognitoは基本的にJWTを用いたステートレスな認証を前提としていますが、B2Bで求められる「ステップアップ認証」や「セッションの強制破棄」などは、本質的にステート管理を必要とします。

これらをCognitoで実現しようとすると本来ステートレスであるはずのアクセストークンとは別にアプリケーション側で独自にセッション管理をする必要があります。その結果、ステートレスであることによるスケーラビリティの恩恵を十分に受けられなくなります。また、認証とアプリケーションの境界が曖昧になり、将来的に深刻な技術的負債になると判断しました。

③ マルチテナント構造との不適合

Cognitoは設計思想として単一テナント向けであり、B2B SaaSに求められる「テナントごとのSSO設定」や「組織単位のポリシー運用」といった要件に構造的に適合しません。ユーザープールを物理的に分けて運用する事もできますが、リソース作成の手間や上限などから厳しいと判断しました。

2. 基本戦略と検討プロセス

具体的な移行先の選定に入る前に、まずは認証基盤のリプレースにおける基本戦略を策定しました。大きく分けて以下の3つの方向性を検討しました。

戦略A. Cognitoの継続利用

既存資産を活かし、不足機能を独自拡張をする事で補うアプローチです。既存資産を有効活用するため移行コストはかからず、すぐに次なる価値提供に結びつくため短期的には有利。しかし、前述した課題感からこの戦略は取らないことにしました。

戦略B. OSS/スクラッチ

まだユーザー数や認証機能が膨大ではないため、フルスクラッチ開発の選択肢も考慮したが、セキュリティリスクが許容範囲外であり、開発コストも最大化するためフルスクラッチの選択肢は取らないことにした。

しかし、OSSを活用して開発することはセキュリティリスクを抑えつつ、豊富な機能メリットを得られることからこの選択肢は現実的と判断した。開発コスト以外にもインフラ運用責任も別途発生するため、そこも加味して判断することとした。

OSSの簡易比較表
評価軸 🔵 Keycloak 🟢 Ory (Kratos) 🟡 Gluu (Janssen) 🟣 Casdoor
概要 UI付き全部入り
(Java / Quarkus)		 ヘッドレス
(Go)		 UI付き全部入り
(Java / Weld)		 UI付き
(Go / React)
UI ◎ 提供あり
(カスタマイズ可能)		 × 自前開発が必須
(APIのみ提供)		 ◎ 提供あり
(カスタマイズ可能)		 ○ 提供あり
(比較的シンプル)
主なコスト ② 運用人件費
(JavaVMの運用)		 ② 運用人件費
+ ③ UI開発人件費		 ② 運用人件費
(高機能ゆえ複雑)		 ② 運用人件費
(+ UI改修費)
B2B / SSO ◎ 非常に得意
(SAML, OIDC, マルチテナント)		 ○ (Hydraと組合せ) ◎ 非常に得意
(SAML, OIDC, UMA 2.0)		 ○ (対応中)
拡張性 / DX ○(Javaで拡張) ◎ (API駆動)
(モダン, Go)		 △ (Javaで拡張) ○ (API駆動)
(モダン, Go)
インフラ運用 △ やや重い ○
(K8s前提の設計)		 △ 重い・複雑 ○
(Oryより手軽)

戦略C. IDaaSの採用

セキュリティリスクをベンダーまたはコミュニティにオフロードでき、かつB2B SaaSに必要な標準機能（MFA、SSO等）を迅速に導入できるため、こちらも現実的かつ持続可能な選択肢であると判断しました。

IDaaSの簡易比較表
観点 🟠 Amazon Cognito 🔵 Auth0 🟢 FusionAuth 🟡 Firebase Auth 🟣 IAM Identity Center
ホスティング AWS SaaS SaaS / セルフホスト可 SaaS SaaS (AWS)
TOTP MFA対応 △ 自前実装要
(キー管理)		 ◎ 標準機能
(キー管理不要)		 ◎ 標準機能
(キー管理不要)		 △ 標準機能
(カスタマイズ性 低)		 ◎ 標準機能
SMS MFA ○ 標準機能 ◎ 標準機能
(プロバイダ選択可)		 ○ 標準機能
(外部連携)		 ◎ 標準機能 ○ 標準機能
ステップアップ認証 × 困難
(要セッション管理)		 ◎ 容易
(セッション管理不要)		 ◎ 容易
(セッション管理不要)		 × 困難
(独自実装が必要)		 × 用途外
SSO連携
(SAML/OIDC)		 × 困難
(標準サポートなし)		 ◎ 非常に容易 ◎ 非常に容易 × 非常に困難
(基本設計が非対応)		 × 用途外
AWS統合 ◎ 非常に強力 △ 限定的 △ 限定的 × 不可 ◎ 中核機能
運用コスト 低
(隠れコスト高)		 高 中〜高 低〜中 低
(基本無料)
移行コスト 低 高 中〜高 高 高
カスタマイズ性 ○ ◎ ◎ ○ △

3. 3つの現実的な選択肢

上記の基本戦略の中から現状の課題を解決するための3つの現実的な選択肢を特定しました。

  1. Ory Self-Host
    • Ory Kratosを採用し、UI開発とインフラ運用を自社で行う
  2. Ory Network
    • Ory KratosのSaaS版を利用し、UI開発のみ自社で行う
  3. Auth 0
    • IDaaSに移行し、機能とUI・インフラ運用の全てをアウトソースする

Auth0は機能・信頼性ともに最高峰ですが、やはり高いです。高いからOSSにしたと言ってしまえば、それまでなのですが、より正確にお伝えするとAuth0のMAU課金という課金形態が弊社の事業特性と合致しませんでした。

低頻度利用

導入企業の全従業員等にアカウント発行をする運用ですが、日常的に利用するユーザーは限られます。「アカウント数は多いが、利用頻度は低い」層に対しても一律で課金されるため、コスト効率が悪化します。

スパイクの影響

オンボーディング時に数千~数万ユーザーを一括登録する際に、一時的にMAUが急増します。実態の価値享受と乖離したタイミングでコストが跳ね上がる構造は事業計画上のリスクとなります。

Ory Kratosを選定した技術的・経済的理由

最終的にOry Kratosを選定した理由は、Auth0と比較した際に、主に以下の5点において弊社のフェーズと要件により適していたからです。正確にはOSSのKratos単体の特徴というより、Ory Networkを含めたエコシステム全体の評価になります🙏

① 経済合理性の高い課金形態（DAUベース)

現在検討を進めているOry Network EnterpriseプランではMAUではなく、 DAU を基準として料金体系です。これにより一括登録時のスパイク影響を平準化しつつ、事業成長とコストの連動性を健全に保つことが可能となります。

② ポータビリティの確保

将来的なコンプライアンス要件やコスト構造の変化に備え、特定のベンダーロックインを回避する必要があります。 Ory KratosはOSSベースであるため、 「現在はマネージドサービス（Ory Network）を利用し、将来的に要件が変わればSelf-Hostへ切り替える」 という選択肢を保持できます。この可搬性は、長期的な事業継続性の観点で重要なリスクヘッジとなります。

③ Server Driven UIによる疎結合の実現

Ory Kratosの最大の特徴の一つに、Server Driven UIの思想を採用している点が挙げられます。KratosのAPIはレンダリングすべきUIノードを返すため、フロントエンドの実装コストに足を取られることなく、常に最新のセキュリティ体制を維持し続けられます。
認証とアプリケーションの疎結合をアーキテクチャレベルで実現しているところに惹かれました。

④ データホーミングへの備え

海外展開において避けて通れないのが、GDPRや各国のデータローカライゼーション（個人データの国内保存義務）規制です。

フルマネージドなIDaaSの場合、データの保存場所はベンダーに依存します。 一方、Ory Kratos（特にSelf-Hostの選択肢が取れるOSS）であれば、将来的に 「特定の国のユーザーデータはその国のDBに保存する」 といった構成変更にも柔軟に対応できます。

「今はマネージドサービスで楽をするが、将来のコンプライアンスリスクに対して『自前でデータを持つ』という選択肢を残しておく」。 この 可搬性（Portability） が、長期的な事業リスクヘッジとして非常に魅力的でした。

⑤ B2B必須機能（マルチテナント・SSO）の標準対応

Self-HostをするにしてもEnterprise Licenceは必要となりますが、顧客企業ごとのSSO設定やマルチテナントに対応しています。Auth0のライセンス料と比較すれば、十分に費用対効果が見込めると判断しました。

さいごに

記事の中でOry Networkの話をしているのに、タイトルには Ory Kratos と書いています。 実は、この記事を書いている現時点ではまだ認証基盤のリプレースは完了していません。さらにいうと、Ory Kratosを「Self-Host」するか「Ory Network (SaaS)」にするかすら、最終決定していない状況です。[1]

普通に考えれば「見切り発車」と思われるかもしれません。 しかし、この 「どちらにするか、後からでも決められる」ことこそが、私たちがOry Kratosを選んだ最大の理由 なのです。

（冗談です。時間と人が足りない、、）

実際にはOry KratosとOry Networkは地味に仕様差分や追加機能などあるので簡単に移行可能とは言えないのですが、Self-HostとSaaSそれぞれの構成でPoCを行いながら、コストとSRE負荷のトレードオフを検証している最中です。この検証結果や、実際の移行で踏み抜いた落とし穴については、また別の記事で紹介できればと思います。

Dress Codeでは、後発だからこそ描ける「真の最適解」を技術とビジネスの両面から模索できるエンジニアを募集しています。 「認証基盤のリプレースに興味がある」「グローバルな課題に挑戦したい」という方、ぜひ一度お話ししましょう！

👉 採用ページはこちら

脚注

  1. Self-HostするにしてもB2Bに必要な機能を標準装備するためにOry Enterprise Licenseは別途、検討しています。 ↩︎

DRESS CODE TECH BLOG
DRESS CODE TECH BLOGPublication

DRESS CODEのProduct & Technologyチームによるテックブログです！ プロダクトマネジメントからモデリング、アーキテクチャ、フロントエンド、バックエンド、SRE、セキュリティなどなど様々なテーマで情報を発信しています！

Discussion