--- title: "WorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤を実装視点で解説" url: "https://www.issoh.co.jp/tech/details/17295/" published: 2026-09-04 updated: 2026-09-04 categories: ["プラットフォーム"] publisher: "株式会社一創" --- # WorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤を実装視点で解説 自社SaaSを大企業へ売り込む段階で、必ず出てくる要求があります。「うちのIDプロバイダでログインさせたい」「退職者は自動で無効化してほしい」「操作ログを監査用に出してほしい」。WorkOSは、この3つをまとめて外部サービスへ逃がすためのプラットフォームです。ここでは製品構成、Laravelスターターキットを使った接続手順、接続1本あたり125ドルという課金構造、そしてOktaやKeycloakとの立ち位置の違いを、実装と見積りの判断ができる粒度まで落として説明します。[SSOの実現方式そのものの整理](https://www.issoh.co.jp/tech/details/15821/)は別記事で扱っているため、本記事はWorkOSという具体的な製品に絞ります。 ## まとめ：WorkOSはSP側のエンタープライズ要件を接続課金で外部化する 先に結論を置きます。WorkOSは、SaaSを提供する側（SP側）が、顧客企業のIdPを受け入れるために必要な機能をAPI経由で借りる製品です。判断で迷いやすい点は次の4つに集約されます。 - **役割はSP側の受け入れ**：OktaやMicrosoft Entra IDが顧客企業のIdPなら、WorkOSはそれを何十社ぶんも受け入れる側の実装を肩代わりします。立ち位置が逆で、競合ではありません。 - **課金の単位は接続数**：SSOもDirectory Syncも「顧客企業1社との接続1本」あたりの月額課金です。ユーザー数ではなく契約企業数でコストが決まります。 - **無料枠はAuthKitのみ**：AuthKitは100万MAUまで無料ですが、エンタープライズSSOやSCIM連携は接続を張った時点で課金対象です。 - **設定作業は顧客へ渡せる**：Admin Portalを使うと、顧客企業のIT担当者が自分でIdP設定を完了できます。この工程を誰が持つかで工数が大きく変わります。 採用の前提は、接続数の増加が売上の増加と連動していること。ユーザー数だけが増えるコンシューマ向け製品では、価格構造が噛み合いません。 ## WorkOSの製品構成とAuthKit・SSO・Directory Syncの役割分担 WorkOSは単一の製品ではなく、目的の違う機能群の集合です。公式ドキュメント（2026年9月4日確認）に並ぶのは、AuthKit、SSO、Directory Sync、Admin Portal、Audit Logs、Radar、Vault、RBAC、FGA、Feature Flags、Pipes、そしてAIエージェント向けのMCPサーバー。まずは前半4つの分担を押さえれば、残りは後づけで足せます。 ### AuthKitが担う認証UIとSSO接続が担うIdP連携の境界 AuthKitは、ホスト型のサインイン画面です。メールとパスワード、ソーシャルログイン、パスキー、メールで送るコード認証（Magic Auth）、MFA、そしてエンタープライズSSOへの振り分けまでを、WorkOS側の画面が引き受けます。自社でログイン画面を作らず、リダイレクトで済ませる形です。 一方のSSOは、顧客企業のIdPとの接続そのものを指します。ログイン画面でユーザーが会社のメールアドレスを入力すると、そのドメインに紐づいた接続が判定され、該当するIdPへ飛ばされる。この振り分けがAuthKit側に内蔵されている点が、自前実装との差です。境界を一言で言えば、AuthKitは入口のUIとルーティング、SSOは接続先ごとのプロトコル処理になります。 ### Directory Syncによるユーザー入退社の自動反映の仕組み SSOだけを入れると、入社した社員はログインできるようになりますが、退職者のアカウントはアプリ側に残り続けます。ログインを止めるだけでは、ライセンス数の集計も、共有ドキュメントの所有者も整理されません。Directory Syncは、顧客企業のディレクトリ側の変更をリアルタイムでアプリへ流し込み、ユーザーの作成・属性更新・無効化を自動で反映させます。 接続先として想定されているのは、Okta、Microsoft Entra ID、Google Workspace、Workday、JumpCloudといった主要なID基盤です。アプリ側はWorkOSが送るイベントを受け取るだけでよく、IdPごとに異なるSCIMの方言を個別に吸収せずに済みます。要件定義で「入退社連携」と書かれたら、この機能が受け皿です。 ### Admin Portalが顧客IT部門へ設定作業を渡す運用設計 SSO導入で工数を食うのは、コードではなく調整です。顧客企業のIT部門とメタデータURLや証明書をやり取りし、属性マッピングを合わせ、テストする。この往復が1社あたり数日かかります。 Admin Portalは、この工程を顧客側のセルフサービスに置き換える画面です。招待リンクを発行すると、顧客のIT担当者がブラウザ上で自社のIdPを選び、手順に沿って設定を完了できます。開発側が持つのは、招待リンクを生成するAPI呼び出しと、接続完了イベントの受信だけ。見積り時は、この工程を自社で巻き取るのか顧客に渡すのかを最初に決めてください。 ### Audit LogsとRBAC・FGAが埋めるエンタープライズ要件 大企業のセキュリティ審査で追加要求されるのが、監査ログと権限管理です。Audit Logsはアプリで起きたイベントを取り込んで保存・エクスポートし、Log Streamingを併用すれば顧客のSIEMへ直接流せます。RBACは組織単位のロールと権限、FGAはリソース単位の細かい認可を扱う機能で、後者は「このドキュメントはこのユーザーだけ編集可」といった要件に対応します。 ほかにVault（機微データの暗号化保管）、Radar（ボットや不正登録の検知）、Feature Flags（組織単位の段階公開）も同じダッシュボードに並びます。全部入れる必要はありません。審査で返ってきた項目だけ後から足す構成が現実的です。 ## WorkOS導入の実装手順とLaravelスターターキットでの接続設定 実装の入り口は、フレームワークによって大きく変わります。Laravelのように公式スターターキットへ組み込まれているものもあれば、SDKを入れて自前でコールバックを書くものもある。ここでは代表的な経路を具体的に見ていきます。 ### Laravelスターターキットで設定する3つの環境変数と初期手順 Laravel公式ドキュメント（13.x・2026年9月4日確認）は、React・Svelte・Vue・Livewireの各スターターキットにWorkOS AuthKit版を用意していると明記しています。提供される認証方式は、ソーシャル認証（Google、Microsoft、GitHub、Apple）、パスキー、Magic Auth、SSOの4つ。手順は次の順です。 1. `laravel new` でアプリを作成し、プロンプトでWorkOSオプションを選ぶ 2. WorkOSダッシュボードで取得した値を `WORKOS_CLIENT_ID`、`WORKOS_API_KEY`、`WORKOS_REDIRECT_URL` の3つに設定する 3. ダッシュボード側にアプリのホームページURLを登録する（ログアウト後の戻り先になる） 公式が推奨している設定が2つあります。ひとつは、AuthKit側でEmail+Password認証を無効化し、ソーシャル認証・パスキー・Magic Auth・SSOだけに絞ること。パスワードをアプリ側で一切扱わない構成にできます。もうひとつは、AuthKitの無操作タイムアウトを、Laravel既定のセッション（通常2時間）に揃えること。ここがずれると、片側だけ生きた状態が生まれます。なお、WorkOS版のスターターキットではメール検証の実装が不要です。 ### SAMLとOIDCの差異をWorkOSが吸収する接続の張り方 顧客企業のIdPは、SAMLで来ることもOIDCで来ることもあります。自前実装なら、この2系統を両方書いて、さらにIdP製品ごとの癖に対応することになる。WorkOSのSSOは、接続の種類として両方を受け付け、アプリ側には同じ形のユーザー情報として返します。アプリが書くコードは、認可コードを受け取ってプロファイルに交換する1経路だけです。 ただし、プロトコルの理解が不要になるわけではありません。属性マッピングで「メールアドレスがどのアサーション属性に入るか」を顧客ごとに確認する場面は残りますし、署名検証エラーの切り分けにはIdPとSPの往復の理解が要ります。[SAMLの認証フローとIdP・SPの関係](https://www.issoh.co.jp/tech/details/13299/)を押さえてから接続作業に入ると、顧客のIT部門との会話が短くなります。 ### SCIM実装をDirectory Syncへ寄せる場合の設計判断 SCIMを自前で受ける場合、アプリ側にプロビジョニング用のエンドポイント群を実装し、IdPからのリクエストを処理する必要があります。ユーザーとグループの2リソース、フィルタ構文、PATCH操作の部分更新まで含めると、実装量は小さくありません。[SCIMのエンドポイント実装とスキーマの詳細](https://www.issoh.co.jp/tech/details/15876/)は別記事で扱っています。 Directory Syncへ寄せる判断の分かれ目は、顧客企業の数です。1社か2社の連携なら、自前実装のほうが総コストは安くなります。接続が10社を超えたあたりから、IdPごとの差異を吸収するコストと、接続課金の比較が逆転します。自社で持ち続けるなら、IdP側の仕様変更に追従する保守も自社の責任になる点を見積りに入れてください。 ### 対応SDKとNext.js・Laravel向けフレームワーク統合 公式ドキュメントに並ぶSDKは、サーバーサイドとモバイルを合わせて幅広く用意されています。 - サーバーサイド：Node.js、Python、Go、Ruby、PHP、Java、.NET、Rust、Elixir - モバイル：iOS、Android - フレームワーク統合：Next.js、React、Remix、Astro、React Router、TanStack Start 統合パッケージがある環境では、セッション管理やミドルウェアの雛形がそのまま手に入ります。無い場合は、コールバックの受け口とセッションの持ち方を自分で設計することになる。技術選定の段階で対応の有無を確認しておくと、後半の手戻りを避けられます。 ## WorkOSの接続数課金とAuthKitのMAU課金で見るコスト試算 WorkOSの価格は、公式の価格ページ（2026年9月4日確認）に単価まで公開されています。エンタープライズ製品では珍しく、営業と話す前に見積りが立てられる構造です。 ### SSO接続とDirectory Syncに共通する接続単価と割引段階 SSOとDirectory Syncは、どちらも「接続1本あたりの月額」で課金され、本数が増えるほど単価が下がります。 | 接続数 | 1接続あたり月額 | 割引率 | | ------- | -------- | ------ | | 1〜15本 | 125ドル | なし | | 16〜30本 | 100ドル | 20% | | 31〜50本 | 80ドル | 36% | | 51〜100本 | 65ドル | 48% | | 101本以上 | 個別見積り | 要問い合わせ | 1接続は顧客企業1社との1連携を指し、同じ顧客でSSOとDirectory Syncの両方を使うなら接続は2本です。この単位を取り違えると見積りが半額でずれます。ほかに、Audit Logsのイベント保持が100万イベントごとに月99ドル、Log StreamingがSIEM接続1本あたり月125ドル、カスタムドメインが月99ドルという従量項目があります。 ### AuthKitの100万MAU無料枠と超過時の月額2500ドル AuthKitは月間アクティブユーザー100万人まで無料です。この枠はかなり広く、社内システムや初期のSaaSであれば、認証UI部分の費用はゼロで済みます。超過分は100万MAUごとに月2500ドル。ボット検知のRadarは初期1000チェックまで無料で、追加は5万チェックごとに月100ドルです。 無料枠の広さから「WorkOSは無料で使える」と受け取られがちですが、無料なのはAuthKitの範囲だけ。エンタープライズSSOやDirectory Syncは、接続を1本張った時点で月125ドルが発生します。無料で検証したい段階では、ソーシャルログインとMagic Authまでで止めておき、SSO接続はテスト用の1本に絞るのが現実的な進め方です。 ### エンタープライズ顧客が20社を超えた場合のコスト試算と分岐点 具体的に計算します。SSOのみを20社に提供する場合、最初の15本が125ドルで1875ドル、残り5本が100ドルで500ドル、合計は月2375ドルです。年額では28500ドル。同じ20社にDirectory Syncも提供すると接続は40本になり、単価表の後段が効いてくるとはいえ、月額は4000ドル台まで伸びます。 見るべきは絶対額ではなく、1社あたりのコストと契約単価の比です。年間契約が1社100万円規模のSaaSなら、接続あたり年間1500ドル前後は許容範囲に収まります。月数万円のプランにエンタープライズSSOを付ける場合、粗利はほとんど残りません。SSOを上位プランの専用機能として切り出し、契約単価を上げる設計と組み合わせるのが定石です。 ## Okta・Auth0・Keycloakとの機能差と選び分けの判断基準 WorkOSは「Oktaの代替」と紹介されることがありますが、この理解は実装を誤らせます。まず立ち位置の違いから整理します。 ### OktaとWorkOSでIdP側とSP側という立ち位置の違い [Oktaは従業員や顧客のIDを管理するIdP](https://www.issoh.co.jp/tech/details/9368/)であり、企業が自社の社員アカウントを一元管理するために導入します。WorkOSが立つのは反対側、つまりそのOktaからログインを受け入れるアプリケーション側です。SaaSベンダーがWorkOSを入れ、その顧客企業がOktaを使っている、という組み合わせが典型になります。 両者が比較対象になるのは、Oktaが提供する開発者向けのCIC（旧Auth0）を検討している場面だけです。そこでの判断軸は、エンタープライズ接続の管理画面をどこまで顧客へ開放できるか、そして接続単位の価格が公開されているかどうか。顧客のIT部門に設定を任せたい製品なら、Admin Portalを持つWorkOSが有利になります。 ### Auth0・Keycloakと比べた運用負荷と初期実装量の差 Auth0は認証全般を広くカバーし、カスタムのアクションやルールで細かい制御ができます。WorkOSはB2Bのエンタープライズ接続に機能を寄せているぶん、設定項目が少なく、初期実装は短くなる。多様な認証フローを自分で組みたい要件ではAuth0、SSOとSCIMを早く載せたい要件ではWorkOS、という切り分けになります。 [Keycloakは自前でホストするオープンソースのIDプロバイダ](https://www.issoh.co.jp/tech/details/7663/)で、ライセンス費用は発生しません。ただし、可用性の確保、バージョン更新、証明書の更新、障害時の一次対応がすべて自社の運用になります。接続20本のWorkOSが月2375ドルだとして、その金額と、Keycloakクラスタを24時間支えるインフラと人件費を比べる。専任のインフラ担当がいない開発チームでは、後者が安くなることはほぼありません。 ## WorkOSを採用すべき案件条件と見送るべきプロダクトの状況 ここからは判断です。価格も機能も分かったうえで、採用する条件と、採用しない条件を条件つきで示します。 ### B2B SaaSでWorkOSの採用を決めてよい3つの前提条件 次の3つが揃っているなら、採用してよいと判断できます。第一に、顧客が企業であり、各社が別々のIdPを持っていること。第二に、SSOやSCIMが商談のブロッカーになっていて、実装できないと失注する状況にあること。第三に、接続1本あたり年間1500ドル前後を払っても粗利が残る契約単価であること。 典型は、シード後からシリーズA前後のB2B SaaSです。エンタープライズ商談が動き始め、しかし認証基盤に専任エンジニアを割く余裕がない段階。ここでの自前実装は、SAMLとSCIMに数か月、その後もIdPごとの個別対応が続きます。契約単価が低いままエンタープライズ機能だけを載せるのは失敗パターンで、固定費だけが積み上がります。 ### WorkOSの採用を見送るべきコンシューマ向け製品の条件と代替 コンシューマ向けサービスでは見送ってください。理由は明快で、価格構造が噛み合わないからです。個人ユーザーが100万人いても企業接続は0本なのでAuthKitの無料枠で足りますが、逆にそれ以上の価値が出ません。ソーシャルログインとパスワードレスだけが目的なら、フレームワーク標準の認証や、より安価な認証サービスで十分です。 社内システムでも過剰になります。自社の社員だけが使うツールなら、接続する先は自社のIdP1本だけ。この構成で必要なのはSP側の受け入れ機能ではなく、IdP側の設定と、アプリ側の1接続の実装です。[IDaaS製品の比較軸](https://www.issoh.co.jp/tech/details/16401/)で選び直したほうが、費用も工数も小さくなります。判断の分岐点は「接続先のIdPが1つか、複数の顧客企業ぶんあるか」。ここだけ見れば迷いません。 ### 受託開発でSSO要件を引き受けるときの見積り範囲と責任分界点 受託でエンタープライズSSOを引き受ける場合、揉めるのは実装ではなく分界点です。顧客企業のIdP側の設定は誰がやるのか、属性マッピングの取り決めは誰が主導するのか、接続後に顧客のIdP側で証明書が更新されたときの一次対応は誰か。この3点を契約前に文書化しておくと、運用フェーズの認識違いを防げます。 見積りは、WorkOSの初期実装（AuthKit導入・コールバック・セッション設計）、Admin Portalの組み込みと招待フロー、Directory Syncのイベント受信とユーザー同期処理、顧客1社ごとの接続立ち上げ支援の4本に分けて出します。接続立ち上げは社数に比例するため、初期構築とは別建てにするのが実務的です。WorkOSの月額を顧客の直接契約とするか、自社経由の再販とするか。ここで収益構造も変わります。[外部ID基盤との接続実装やプロビジョニング連携を含む開発](https://www.issoh.co.jp/service/system/api/)は、一創のAPI開発・システム連携で対応しています。要件の切り分けから相談してください。 ## よくある質問 WorkOSの検討で実際に挙がる質問を5つ挙げ、2026年9月時点の公開情報に基づいて答えます。 ### WorkOSの管理画面やドキュメントは日本語に対応していますか？ 公式ダッシュボードとドキュメントは英語で提供され、日本語版の管理画面はありません。ただしAuthKitのログイン画面は表示文言をカスタマイズでき、エンドユーザーが見る画面は日本語にできます。顧客のIT担当者がAdmin Portalで英語の手順を読む場面は残るため、案内文を日本語で補足しておくと設定作業が止まりにくくなります。 ### WorkOSの無料枠だけで本番運用はできますか？ 認証機能に限れば可能です。AuthKitは月間アクティブユーザー100万人まで無料で、ソーシャルログイン、パスキー、Magic Auth、MFA、ユーザー管理がこの範囲に含まれます。一方、エンタープライズSSOとDirectory Syncは接続を張った時点で1本あたり月125ドルからの課金対象です。「認証は無料、エンタープライズ接続は有料」という線引きになるため、顧客企業とのSSO接続が本番で1本でも走るなら、費用は発生します。 ### WorkOSからOktaやAuth0へ後から移行できますか？ 技術的には可能ですが、コストはゼロではありません。WorkOSはユーザーデータのエクスポートに対応し、公式もマイグレーション支援を年間契約プランの提供内容に挙げています。ただし移行作業は、ユーザーレコードの移送に加えて、顧客企業ごとのSSO接続を移行先で張り直す工程を伴う。接続数が多いほど顧客IT部門との再調整が重くなります。ロックインの実体はデータではなく、この張り直しにあると考えてください。 ### SSO接続は顧客企業ごとに1本ずつ必要ですか？ 必要です。接続は顧客企業とIdPの組み合わせ単位で作られ、課金もその本数で決まります。同じ顧客でSSOとDirectory Syncの両方を使う場合は、接続2本ぶんの費用になります。10社と接続してSSOのみなら10本で月1250ドル、両方使うなら20本という数え方です。提案時の概算は、想定する顧客社数に使用機能数を掛けて出すのが確実です。 ### WorkOSはSOC 2などのコンプライアンス要件に対応していますか？ WorkOSはコンプライアンス対応を訴求点に置き、Audit Logsによる監査ログの保存とエクスポート、Log Streamingによる顧客SIEMへの転送、Vaultによる機微データの暗号化保管を備えています。ただし認証基盤を外部化しても、自社サービス側の統制やログの取り扱いまで肩代わりされるわけではありません。どの証跡を自社で保持するかは、取得予定の認証区分の審査項目と突き合わせて確認してください。 ## 関連記事 - [シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説](https://www.issoh.co.jp/tech/details/15821/)：SSOの方式そのものを整理したい場合に。WorkOSがどの方式を代行しているかが分かります。 - [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：製品カテゴリの比較軸から選び直したい場合の出発点です。 - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】](https://www.issoh.co.jp/column/details/13631/)：技術用語の関係を経営・企画側へ説明する必要がある場面に。 - [Auth0 for AI Agentsとは？GA後の4機能とCIBA・Token Vault実装・料金を解説【2026年版】](https://www.issoh.co.jp/tech/details/9411/)：AIエージェントに認可を渡す要件が出てきた場合の比較先です。 --- 出典: [WorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤を実装視点で解説]()（株式会社一創）