Oryとは？ChatGPTを支えるOSS認証基盤を公式パートナーが解説

OSS認証基盤Ory（オリー）のロゴ — Open-source identity and access infrastructure for modern applications

Ory（オリー）は、「モダンなアプリケーションのための、オープンソースの認証基盤」です。OpenAIがChatGPTの認証基盤として採用したことで一気に知名度が上がりました。ChatGPTのユーザー数は2025年10月時点で8億人とされており、この規模のサービスに採用されたという事実は、Oryという製品に魅力があることの証明です（Ory公式のケーススタディ）。

Identity & Access Management (IAM) Solutions | Ory

Ory delivers identity and access management (IAM) for applications, enterprises, and AI agents. Cloud-native, API-first, and self-hostable.

www.ory.com

国内でもLayerX社やマクロミル社などの採用事例が公開されており、Auth0やCognitoに続く選択肢として検討されるケースが増えています。

スタジオメッシュは、日本唯一（2026年6月時点）のOry公式パートナーとして導入支援・ライセンス販売を行っています。本記事では、実際の導入プロジェクトで得た知見も交えて、Oryの全体像・他製品との違い・使い分けの考え方を解説します。

Oryとは

Oryは、Ory社が開発・提供するOSSベースの認証基盤です。

正確には「Ory」という単一の製品があるわけではなく、認証・認可の役割ごとに分かれた複数のモジュール群の総称です。必要なモジュールだけを選んで組み合わせる構成をとっており、これが後述するOry最大の特徴につながっています。

Ory製品の全体像 — OSSモジュール群（Kratos・Hydra・Keto・Oathkeeper・Polis）と、それらをベースに構築されたクラウドサービスのOry Network

モジュール	役割	GitHubスター
Ory Kratos	認証・ID管理	13,400+
Ory Hydra	OAuth 2.0 / OpenID Connect プロバイダー	16,900+
Ory Keto	FGA（Fine-Grained Authorization）ベースのアクセス制御	5,200+
Ory Polis	SAML・SCIM 2.0 連携	2,200+
Ory Oathkeeper	ゼロトラスト型のAPI認証・認可プロキシ	3,500+

主要モジュールの合計で30,000スターを超えており、OSSの認証基盤としては最大級のコミュニティを持ちます。

Ory Kratos — 認証とID管理の中核

Kratosは、ユーザー登録・ログイン・パスワードリセット・セッション管理・プロファイル管理といった、認証基盤の中核機能を担うモジュールです。ソーシャルログインや多要素認証（TOTP、WebAuthn/FIDO2、SMS OTP）にも対応しており、Kratos単体で一般的な認証システムに求められる機能をほぼ網羅します。

注意点として、KratosはOAuth 2.0 / OpenID Connectのプロバイダー機能を持ちません。自社サービスを「IdP」として外部に開放したい場合は、次のHydraと組み合わせます。

GitHub - ory/kratos: Headless cloud-native authentication and identity management written in Go. Scales to a billion+ users. Replace Homegrown, Auth0, Okta, Firebase with better UX and DX. Passkeys, Social Sign In, OIDC, Magic Link, Multi-Factor Auth, SMS, SAML, TOTP, and more. Runs everywhere, runs best on Ory Network.

Headless cloud-native authentication and identity management written in Go. Scales to a billion+ users. Replace Homegrown, Auth0, Okta, Firebase with better UX and DX. Passkeys, Social Sign In, OID...

github.com

Ory Hydra — OAuth 2.0 / OIDC プロバイダー

Hydraは、OAuth 2.0 / OpenID Connectのプロバイダー機能に特化したモジュールで、OpenID Foundationの認定を取得しています。

Hydra自体は認証機能を持たず、認証は外部のシステムに委譲する設計です。連携先はKratosである必要はなく、既存の自社認証システムと組み合わせて、システムに手を入れずにOAuth 2.0 / OIDC対応のIdPを構築するという使い方ができます。LayerX社の事例は、まさにこの特性を活かして既存システムの共通ID化を実現したものです。

KratosとHydraを組み合わせると、Auth0やKeycloakに相当するフルスタックの認証基盤になります。

GitHub - ory/hydra: Internet-scale OpenID Certified™ OpenID Connect and OAuth2.1 provider that integrates with your user management through headless APIs. Solve OIDC/OAuth2 user cases over night. Consume as a service on Ory Network or self-host. Trusted by OpenAI and many others for scale and security. Written in Go.

Internet-scale OpenID Certified™ OpenID Connect and OAuth2.1 provider that integrates with your user management through headless APIs. Solve OIDC/OAuth2 user cases over night. Consume as a service ...

github.com

Oryの3つの特徴

1. モジュール構造 — 必要な機能だけを導入できる

従来のモノリシックな認証製品と異なり、Oryは必要なコンポーネントだけを選択して導入できます。「認証はそのままで、OAuth対応だけ追加したい」「アクセス制御だけ強化したい」といった部分導入が可能で、システムの複雑性を最小限に抑えられます。

2. 自社コントローラビリティ — IDaaSというブラックボックスからの脱却

OryのソフトウェアはすべてApache 2.0ライセンスで公開されており、商用利用・改変・再配布が自由です。ソースコードを直接確認でき、インフラも自社管理できるため金融や公共領域で求められるセキュリティ監査にも対応しやすく、特定ベンダーへのロックインを構造的に回避できます。

3. ヘッドレスアーキテクチャ — UXを完全にコントロールできる

Oryは画面（UI）を持たないヘッドレス設計です。ログイン画面や登録画面はReactなど任意の技術スタックで自由に実装します。

これは「画面を自作しなければならない」とも言えますが、B2Cサービスのようにログイン体験がブランドの一部になる領域では、テンプレートUIの制約を受けずにUXを作り込めることが大きな武器になります。実際にB2C認証基盤の案件で、この自由度が採用の決め手になるケースがあります。なお、SaaS版のOry NetworkにはプリセットUI（Ory Account Experience）が用意されています。

Auth0・Cognito・Keycloakとの違い

認証基盤の選定では、Auth0・Amazon Cognito・KeycloakがOryと比較されることが多いです。観点別に整理します。

観点	Ory	Auth0	Cognito	Keycloak
提供形態	OSS + SaaS	SaaS	SaaS	OSS
料金モデル	OSSは無償、SaaSはMAU従量	MAU従量	MAU従量	無償
UI	ヘッドレス	テンプレートUI	テンプレートUI	テンプレートUI
カスタマイズ性	非常に高い	中	低	高

Oryならではの強みは次の2点に集約されます。

状況に応じたコストのコントロール性。 OryはOSSをセルフホストすれば、無償で利用できます。サービスの新規立ち上げ時やユーザー数が少ない段階では、これで十分な場合も多いです。事業が成長してユーザー数が増え、非機能要件の重要性が高まってきた段階で、それらをサポートするOEL（Ory Enterprise License）やOry Networkを導入する——というように、状況に応じてコストと得られるメリットをコントロールし、最適なROIを実現できます。

カスタマイズ前提の設計。 UIだけでなく認証フローやワークフローも拡張前提で設計されており、既製品の枠に収まらない要件（独自の本人確認フロー、レガシーシステムとの段階的統合など）に対応しやすい構造です。特に日本のB2C認証基盤は、画面やUXの細やかなカスタマイズが求められるケースが多く、Oryのヘッドレス設計は大きなメリットになります。

Ory NetworkとOSSセルフホストの使い分け

Oryの導入形態は2つあり、これの使い分けが選定のポイントです。

Ory Network（フルマネージドSaaS） は、Auth0やCognitoと同じ感覚で使えるマネージドサービスで、KratosやHydraをベースに構築されています。インフラ運用が不要で、無料の開発者プランがあり、日本リージョンも提供されています。

OSSセルフホストは、コンテナ前提の設計でKubernetesやDocker Composeとの親和性が高く、自社管理のAWSやガバメントクラウドなど、デプロイ先の制約がある案件にも対応できます。本格運用には、SLA付きのセキュリティパッチ優先提供やSAML SSO・SCIM等のエンタープライズ機能を含む商用ライセンス（Ory Enterprise License）も提供されています。

実務での使い分けの目安はこうです。

小規模スタート・スピード重視 → Ory Networkで始める
ユーザー数が多い → Ory NetworkとOSSセルフホストをコスト比較して選ぶ
デプロイ先や監査の制約が強い（公共・金融など） → OSSセルフホスト + 商用ライセンス

導入前に知っておきたい注意点

公式パートナーの立場でも、正直に伝えておきたい弱点があります。

OSS版のリリース頻度は高くありません。 OSS版のリリースは、セキュリティアップデートを含めて年に1〜2回程度です。脆弱性対応を迅速に受けたい場合は、商用ライセンス（OEL）の購入で解決できます。一方で、OSSのセルフホストで大規模サービスを運用している事例も実際にあります。自社で運用できる体制があれば、OSS版のままで十分なケースもあります。

ドキュメントの使い勝手は発展途上です。 検索で目的の情報に直接たどり着きにくく、記載がどのモジュールに対する内容なのか判別しづらい箇所があります。Auth0の充実したドキュメントに慣れていると、ギャップを感じるはずです（ドキュメントサイトに組み込まれたAIアシスタントは比較的役に立ちます）。

Ory Networkの開発者体験も改善余地があります。 Terraformプロバイダーが存在せず、管理画面で設定できる項目は一部に限られるため、yamlやCLIでの操作が必要になる場面が多いです。致命的ではありませんが、IaCで全構成を管理したいチームは事前に運用イメージを確認しておくことをおすすめします。