利用するクラウドサービス（SaaS）が増えるほど、サービスごとにID・パスワードが散らばり、ログインのたびのパスワード入力やリセット対応、入退社時のアカウント発行・停止が情報システム部門の負担になっていきます。パスワードの使い回しや退職者アカウントの消し忘れは、そのままセキュリティのリスクにもつながります。
こうした課題を解決する仕組みが、一度の認証で複数のクラウドサービスにログインできるSSO（シングルサインオン）です。ただ、いざ「自社のクラウドに導入しよう」と考えると、どの順で進めればよいか、どの認証方式を選べばよいか、どのサービスを使えばよいかで迷いやすいのが実情です。
この記事では、Microsoft 365・Google Workspace・SalesforceなどのクラウドサービスにSSOを導入する進め方を、要件整理から連携設定・テスト・全社展開・運用まで順を追って解説します。
あわせて、SAMLやOpenID Connectといった認証方式の選び方、SSO／IdPサービスの比較ポイントと費用の相場、導入後につまずきやすい点までを整理し、自社で導入に着手できる状態になることを目指します。
目次
一括ダウンロードする
クラウドサービスにSSOを導入する進め方【全体像】
ここからは、クラウドサービスにSSOを導入する全体の進め方を解説します。SSOは、利用者が一度ログインすれば、連携した複数のクラウドサービスへ追加の認証なしでアクセスできる仕組みです。導入は、やみくもに製品を選ぶのではなく、自社の環境を棚卸ししてから方式とサービスを決め、連携設定・検証を経て段階的に広げる、という流れで進めると失敗が少なくなります。
導入ステップの全体像
クラウドへのSSO導入は、おおむね次の流れで進みます。各ステップの詳しい内容は、この記事の後半の該当セクションで解説します。
- 要件整理：SSOでまとめたいクラウドサービス、利用者数、既存のActive Directoryの有無、社外からの利用の有無を洗い出します（本セクションの次項）。
- 認証方式の選定：対象サービスがどの連携方式に対応しているかを確認し、自社に合う方式を選びます（認証方式のセクション）。
- IdP／SSOサービスの選定：認証を束ねる基盤（IdP）となるサービスを比較して決めます（選び方のセクション）。
- クラウド側との連携設定：IdPと各クラウドサービスをつなぐ設定を行います（連携設定のセクション）。
- テストと段階展開：一部の利用者で検証してから、部門単位で広げ、全社へ展開します。
- 運用：多要素認証やアクセス制限を組み合わせ、入退社に伴うアカウント管理やログ監査を回していきます（運用のセクション）。
このうち、費用の見積もりは認証方式とサービスの選定とあわせて考えると判断しやすくなります。費用の目安は費用のセクションで整理します。
要件整理（対象サービス・利用環境の棚卸し）
最初に行うのは、SSOでまとめたい対象の棚卸しです。どのクラウドサービスを連携したいかを一覧にし、それぞれがどの認証方式に対応しているかを確認します。対応方式はサービスによって異なるため、ここを押さえておくと後の方式選定がぶれません。
あわせて、次の4点を整理しておくと、方式とサービスの選定がスムーズになります。
- 対象クラウドサービス：Microsoft 365、Google Workspace、Salesforce、Box、Slackなど、SSOでまとめたいサービスの範囲。
- 利用者数と利用形態：全社員か一部部門か、社外の取引先・委託先も含むか。
- 既存のActive Directoryの有無：社内にAD（利用者情報の管理基盤）があるか、クラウド中心か。
- 社外アクセス・端末の条件：社外や私用端末からの利用を許可するか、アクセスを制限したいか。
この棚卸しで「対象サービスの多くがクラウドSaaSで、SAMLやOpenID Connectに対応している」とわかれば、次の方式選定とサービス選定は進めやすくなります。
クラウドサービスとの連携設定（Microsoft 365・Google Workspace・Salesforce）
ここからは、認証を束ねる基盤（IdP）と各クラウドサービスをつなぐ、連携設定の流れを解説します。どの認証方式を使うか、どのサービスをIdPにするかの選び方は、後述の認証方式・選び方のセクションで扱います。ここでは、それらを選んだあとに行う設定の流れを先に示します。
クラウドサービスへのSSOは、多くの場合SAMLという方式で、IdP側とサービス（SP）側で情報を交換して設定します。
たとえばMicrosoft 365を使う組織では、その認証基盤であるMicrosoft Entra IDをIdP（認証を束ねる側）にして、他のクラウドサービスをSP（認証を受ける側）としてまとめる構成が一般的です。IdPがMicrosoftでもGoogleでも、設定の骨格は共通しています。
SAML連携の設定フロー（メタデータ交換・証明書）
SAMLによるSSOは、認証する側のIdP（Identity Provider）と、認証を受けて利用させる側のSP（Service Provider、各クラウドサービス）が、互いの識別情報と署名用の証明書を交換することで成り立ちます。設定の基本的な流れは次のとおりです。
IdPにMicrosoft Entra ID（Microsoft 365の認証基盤）を使う場合、エンタープライズアプリケーションとして対象サービスを登録し、シングルサインオンの方式としてSAMLを選びます。
続いて、SP側の識別子（Identifier／Entity ID）と応答先URL（Reply URL／Assertion Consumer Service URL）を設定し、IdP側の署名証明書とログインURL・識別子をSP側に登録します。設定後はテスト機能でSSOが成功するかを確認します。
この「アプリ登録→識別子・応答先URL・証明書の交換→テスト」という流れが、SAML連携の基本形です。
IdPにGoogle Workspaceを使う場合も流れは同様です。管理コンソールで「カスタムSAMLアプリ」を追加し、GoogleのIdP情報（メタデータ・SSO URL・証明書）を取得して、SP側の応答先URL（ACS URL）と識別子（Entity ID）を登録します。
あわせて、利用者を識別するName IDや、送信する属性のマッピング（Google側の属性とサービス側の項目の対応づけ）を設定し、アプリを有効化してテストします。
Salesforceのようにクラウドサービス側がSP（認証を受ける側）になる場合も、考え方は同じです。管理設定のシングルサインオン設定の画面で、IdPの発行者（識別子）・証明書・ログインURLを登録します。登録する項目の呼び名はサービスごとに異なりますが、「IdPの情報をSP側に登録する」という流れは共通です。
設定後にログインが失敗するときは、原因が決まっていることが多く、次の2点を先に確認すると切り分けがスムーズになります。
1つは証明書の有効期限です。IdPとSPで交換する署名証明書には有効期限があり、切れると、多くの実装で、それまで成功していたSSOが突然失敗します。更新時期を把握し、入れ替え前に新しい証明書を登録しておくことが重要です。
もう1つは、IdPが送るName IDの形式や属性名が、SP側の期待と食い違うケースです。この場合、認証自体は成功しても、SP側で利用者を特定できずにログインが失敗することがあります。テストでは、ログインの成否だけでなく、どの属性がSPに渡っているかもあわせて確認しておくと、こうしたつまずきを早く見つけられます。
SCIMによる自動プロビジョニング（アカウントの自動発行・失効）
SSOでログインを束ねても、各クラウドサービスのアカウントの発行・更新・削除が手作業のままだと、入退社や異動のたびに設定漏れが起きやすくなります。これを自動化する仕組みがプロビジョニングで、その標準プロトコルがSCIM（System for Cross-domain Identity Management）です。
SCIMはHTTPベースの標準プロトコルで、企業とクラウドサービスの間でのID管理（アカウントの作成・更新・削除）を標準化します。
SCIMを使うと、新しい利用者が加わったときに連携先サービスでアカウントを自動作成し、退職や異動があったときにはアカウントを自動で無効化できます。
Microsoftの公式ドキュメントでも、自動プロビジョニングは利用者の作成だけでなく、状況や役割の変化に応じたアカウントの維持・削除を含み、退職時にアカウントを自動で無効化できると説明されています。SCIMはSAMLやOpenID Connectと組み合わせて使う、ID管理の事実上の標準になりつつあります。
テストと段階展開（検証から全社本番へ）
連携設定が終わったら、いきなり全社へ適用せず、まず少人数で検証します。情報システム部門の数名でSSOログインとアカウントの自動発行・失効が想定どおり動くかを確かめ、問題がなければ部門単位で広げ、最後に全社へ展開する、という段階を踏むと、トラブルの影響範囲を抑えられます。
検証では、ログインが成功するかだけでなく、SSOに対応していないシステムが残らないか、利用者の属性が正しく連携されるかも確認します。既存のパスワードログインと並行運用できる期間を設けておくと、万一の切り戻しもしやすくなります。
SSOの認証方式と、クラウド中心ならどれが向くか
ここでは、SSOを実現する認証方式を整理し、クラウド中心の環境ならどれが向くかを解説します。方式には複数の種類がありますが、クラウドサービスへのSSOで中心になるのはSAMLとOpenID Connectの2つです。
SAML／OpenID Connect（OIDC）・OAuth
SAML（Security Assertion Markup Language）は、OASISが策定した標準で、認証情報をIdPとSP（サービス）の間で受け渡すためのXMLベースの枠組みです。多くの業務向けクラウドサービスがSAMLに対応しており、企業向けSSOで広く使われる方式です。
OpenID Connect（OIDC）は、OpenID Foundationが策定した、OAuth 2.0の上に載る認証のレイヤーです。クライアントが、認可サーバーで行われた認証に基づいて利用者の本人性を確認できるようにする仕組みで、新しいクラウドサービスやスマートフォンアプリとの連携で広く使われています。
出典・参考資料（1件）
混同されやすいのがOAuth 2.0です。OAuth 2.0はIETFが定めた「認可」の枠組みで、第三者のアプリケーションに限定的なアクセス権を与えるための仕組みです。
OAuth単体は認証（本人確認）のためのものではなく、その上に認証のレイヤーを載せたものがOpenID Connectにあたります。SSOの主役はSAMLとOpenID Connectであり、OAuthはその土台と位置づけると整理しやすくなります。
リバースプロキシ・エージェント・代理認証・透過型・ケルベロス
SAMLやOpenID Connectに対応していない社内システムやオンプレミスのシステムをSSOに含めたい場合は、次のような方式が使われます。クラウドSaaSが中心で該当するシステムが無ければ、この項は読み飛ばして差し支えありません。オンプレミスの社内システムが残る企業向けの、SAMLに対応しない対象を補う方式です。
- リバースプロキシ方式：利用者とシステムの間に認証用のサーバーを挟み、そこで認証を代行します。対象システム側の改修が少なく済みます。
- エージェント方式：各システムに認証用のプログラム（エージェント）を組み込んで連携します。
- 代理認証（フォームベース）方式：利用者の代わりにIDとパスワードをログイン画面へ自動入力します。SSOに対応していないサービスにも適用しやすい一方、パスワード自体はなくなりません。
- 透過型方式：利用者が意識せずに認証が完了する方式で、社内ネットワークでの利用で使われます。
- ケルベロス方式：Active Directoryなどで使われる認証の仕組みを利用し、Windowsログインの情報でSSOを行います。
自社環境別にどの方式が向くか
方式の向き不向きは、自社の環境で決まります。利用するサービスがクラウドSaaS中心なら、まずSAMLとOpenID Connectで対応できる範囲を押さえるのが基本です。両方式とも主要なクラウドサービスが対応しており、IdPと標準の仕組みで連携できるためです。
社内にActive Directoryがあり、Windows環境と組み合わせたい場合は、ケルベロスや透過型を併用すると、Windowsログインからの流れでSSOを実現しやすくなります。SSOに対応していないオンプレミスのシステムや古い社内システムが残っている場合は、リバースプロキシや代理認証で補う構成を検討します。
実際には、クラウド中心の環境でもこれらが混在することが多いため、SAML・OIDCを軸にしつつ、対応できない対象を他の方式で補える製品を選ぶと、対象を広くカバーできます。
一括ダウンロードする
SSO／IdPサービスの選び方と比較のポイント
ここからは、認証を束ねる基盤となるSSO／IdPサービスの選び方を解説します。どのサービスも「SSOができる」という点は共通しますが、対応範囲や運用のしやすさ、費用には差があります。自社の環境と照らし合わせて見るべき軸を整理します。
比較軸（対応SaaS・認証方式・多要素認証・プロビジョニング・料金・サポート）
サービスを比較する際は、次の軸で見ると自社に合うかを判断しやすくなります。
- 対応するクラウドサービスの範囲：自社で使っているサービスが連携対象に含まれるか。あらかじめ連携設定が用意されているサービスが多いほど、導入の手間は減ります。
- 対応する認証方式：SAML・OpenID Connectに加え、SSO非対応システム向けの代理認証やAD連携に対応しているか。
- 多要素認証（MFA）：ワンタイムパスワード、パスキー（FIDO2）、プッシュ通知など、どの認証強化手段に対応しているか。SSOは認証の入口を一本化するため、入口を守る多要素認証との組み合わせが重要になります。
- プロビジョニング（SCIM）：入退社・異動に伴うアカウントの自動発行・失効に対応しているか。手作業の棚卸しを減らしたい場合は重視します。
- 料金体系とサポート：利用者数に応じた課金か、必要な機能が含まれるプランはどれか。導入時・運用時の日本語サポートがあるか。
提供形態の選び方と自社環境別の当たりの付け方
SSO／IdPサービスには、クラウド型（IDaaS）と、自社で構築するオンプレミス型があります。クラウドSaaSへのSSOが目的であれば、導入・運用の負担が軽いクラウド型が基本の選択肢になります。自社でサーバーを用意・保守する必要がなく、対応サービスの追加もしやすいためです。
自社環境ごとの見当のつけ方としては、次のように考えると絞り込みやすくなります。クラウドサービス中心で情報システムの運用を軽くしたいなら、連携済みサービスが多く、多要素認証とプロビジョニングを標準で備えたクラウド型が向きます。
社内にActive Directoryがあり、Windows環境や社内システムと組み合わせたいなら、AD連携や代理認証に強い製品を軸にします。社外の取引先・委託先にもアクセスを広げる場合は、社外利用者のID管理や、端末・場所に応じたアクセス制限ができるかを重視します。次のセクションでは、こうした軸で主要なサービスを比較します。
SSOに多要素認証やアカウント管理まで含めたクラウド型のID基盤（IDaaS）を軸に選ぶ場合は、主要なIDaaSを選び方や導入事例まで含めて比較した次の記事が、サービス選定の参考になります。
クラウドSSOの費用・料金体系の相場
ここでは、クラウドSSOの費用の考え方を整理します。費用はサービスや利用者数、必要な機能によって変わるため、一律の金額は示せませんが、料金体系の型を知っておくと見積もりの見通しが立てやすくなります。
課金モデル（ID課金かプランか・MFAの扱い）
クラウド型のSSO／IdPサービスの多くは、利用する人数（ID数）に応じた月額課金です。本記事で紹介するサービスでは、1IDあたり月額数百円から、機能の充実した上位プランで2,000円台まで、というのが一つの目安になります（各社の具体額は後掲の比較表を参照）。基本機能を無料で使えるプランを用意するサービスもあります。
注意したいのは、多要素認証やプロビジョニング、アクセス制限といった機能が、下位プランには含まれず上位プランで使えるようになる場合がある点です。どのプランにどの機能が含まれるかは、見積もりの前に公式の料金ページで確認しておくと、導入後に「必要な機能が別料金だった」と気づく事態を避けられます。具体的な金額や、どのプランで何が使えるかは、各サービスの最新の公式料金情報で確認してください。
費用の目安と初期・運用コストの考え方
費用は月額のライセンス料だけでなく、導入時の設定作業と、導入後の運用にかかる手間も含めて考えると実態に近づきます。初期費用がかかるサービスと、初期費用なしで始められるサービスがあり、連携するサービス数が多い場合は設定の工数も見込んでおきます。
一方で、SSOやパスワードレス認証の導入は、パスワードのリセット対応や問い合わせを減らし、情報システム部門の運用負担を下げる効果も期待できます。費用の判断では、ライセンス料と、こうした運用負担の軽減を合わせて見ると、導入の妥当性を説明しやすくなります。
SSO導入でつまずきやすい点と運用・可用性の設計
ここでは、SSOを導入したあとにつまずきやすい点と、その備え方を解説します。SSOは認証の入口を一本化する仕組みのため、便利になる反面、入口が止まったときや破られたときの影響が大きくなります。導入前に対策を設計しておくことが大切です。
SSO非対応システムが残る場合の扱い
すべてのシステムがSSOに対応しているとは限りません。SAMLやOpenID Connectに対応していない古い社内システムが残る場合は、代理認証（フォームベース）やリバースプロキシで補えるか、あるいはそのシステムだけ個別ログインを残すかを、要件整理の段階で決めておきます。対応状況を洗い出さないまま進めると、導入後に「このシステムだけSSOでログインできない」という抜けが生じます。
障害時のフォールバック・冗長化・可用性
SSOでログインを束ねると、SSOの基盤が止まったときに、連携した複数のサービスへログインできなくなる恐れがあります。これはSSOの構造上のリスクです。
対策として、SSOサービスの稼働率（SLAで保証される稼働率の数値）や、障害を知らせる稼働状況ページの有無を選定時に確認し、障害時に備えた代替のログイン手段（管理者用の個別ログインなど）を用意しておきます。基盤の稼働率や障害時の運用方針は、サービス選定の判断材料になります。
不正アクセス対策（多要素認証・IP制限）とログ監査・入退社の棚卸し
前項の障害リスクと並んで備えたいのが、入口が破られたときの被害です。多要素認証を組み合わせて入口を強化し、アクセスできる場所や端末を限定するIP制限・端末制限を加えることで、万一パスワードが漏れても不正ログインを防ぎやすくなります。
運用面では、誰がいつどのサービスにログインしたかのログを残し、定期的に確認できる体制を整えます。また、入退社や異動に伴うアカウントの棚卸しは、手作業だと設定漏れや削除漏れが起きやすいところです。
前述のSCIMによる自動プロビジョニングを使えば、退職時にアカウントを自動で失効させ、棚卸しを自動化できます。SSOと多要素認証、アクセス制限、アカウント管理をあわせて設計しておくと、導入後の運用が安定します。
SSO・多要素認証・アクセス制限・ID管理をまとめて導入する
ここまで見てきたとおり、クラウドへのSSO導入は、SSO単体ではなく、多要素認証・アクセス制限・アカウント管理（プロビジョニング）とあわせて設計すると運用が安定します。これらを一体で提供するのが、クラウド型のID基盤（IDaaS）です。ここからは、クラウドサービスへのSSO導入に使える主要なサービスを紹介します。まずは主な違いを比較表で確認してください。
| サービス名 | CloudGate UNO | Microsoft Entra ID | Okta | HENNGE One | トラスト・ログイン byGMO | OneLogin |
|---|---|---|---|---|---|---|
| 提供形態 | 国産・クラウド型（IDaaS） | 海外・クラウド型（IDaaS） | 海外・クラウド型（IDaaS） | 国産・クラウド型（IDaaS） | 国産・クラウド型（IDaaS） | 海外・クラウド型（国内は代理店販売） |
| 対応認証方式（SSO） | SAML 2.0・OIDC・フォームベース | SAML・OIDC | SAML・OIDC | SAML | SAML・OIDC・フォーム・Basic | SAML・OIDC |
| 多要素認証（MFA） | 生体認証・OTP・認証アプリ | Authenticator・SMS・証明書・OATH 等 | Okta Verify・OTP・SMS・音声 等 | OTP・デバイス証明書・プッシュ承認 | アプリ/メールOTP・プッシュ通知 | OneLogin Protect・OTP・SMS・音声 等 |
| パスキー（FIDO2） | ●全プラン標準 | ●Windows Hello・FIDO2 | ●FastPass・FIDO2 | — | ●有料プラン | ●WebAuthn |
| アカウント自動発行・失効 | ●ライフサイクル管理 | ●SCIM 2.0対応 | ●SCIM・HR連携 | △一部SaaS限定 | ●対応アプリ100件超 | ●SCIM 1.1/2.0 |
| アクセス制限 | ●IP・端末・時間帯 | ●条件付きアクセス（P1以上） | ●IP・デバイス・リスク | ●IP制限・デバイス証明書 | ●IP制限・デバイス制限 | ●SmartFactor・IP 等 |
| 初期費用 | 要問い合わせ（別途） | 無料 | 要問い合わせ | — | — | 20,000円（代理店による） |
| 月額費用の目安 | 400〜600円/ID（税抜） | 無料〜1,499円/ID（年払い） | 940〜2,670円/ID（年払い） | 400〜1,000円/ID（税抜） | 無料〜500円/ID（税抜） | 要問い合わせ（代理店による） |
| 無料トライアル | ●30日間 | ●30日間 | ●30日間 | — | — | ●30日間 |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※料金・機能は各社公式情報に基づく（2026年11月時点）。「●」は対応、「△」は一部対応、「—」は公表なしまたは非該当。最新の提供状況・料金は各社公式情報をご確認ください。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、株式会社インターナショナルシステムリサーチが100%自社開発する国産のクラウド型ID基盤です。SSOを中心に、多要素認証、パスキー（FIDO2）によるパスワードレス認証、アクセス制限、アカウントのプロビジョニングまでを一つにまとめて提供します。
特徴は、端末・場所・時間の3つの軸でアクセスを細かく制限できる点です。私用端末からのアクセス禁止や、特定の拠点・時間帯に限定した利用など、労務管理や情報漏えい対策にもつながる制御ができます。
プロビジョニングやアクセス制限、パスキー対応の多要素認証がすべてのプランに標準で含まれる点も、機能ごとに追加費用がかさみにくい作りといえます。導入前から導入後まで日本語でのサポート体制があり、オンプレミスからクラウドへ移行して複数のSaaS利用を始めた企業に向いています。
同社は独自インタビューで、導入後の運用負担の変化について次のように述べています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。また、他社サービスからの乗り換え事例もございます。通常、設定の移行には時間がかかるものですが、当社のサポートによりわずか1週間で完了させたケースもあります。
2. Microsoft Entra ID（日本マイクロソフト株式会社）
Microsoft Entra ID（旧Azure Active Directory）は、Microsoftが提供するクラウド型のID・アクセス管理サービスです。Microsoft 365やAzureの認証基盤を担っており、これらをすでに利用している組織では、追加の導入なしでSSO・多要素認証・条件付きアクセスを使い始められます。
事前に連携設定が用意された数千規模のクラウドアプリと接続でき、SCIM 2.0標準に対応したアカウントの自動プロビジョニング・デプロビジョニングも備えます。入社・異動・退職といった人事イベントを起点にアカウントを自動で作成・無効化できるため、Microsoft 365を基盤にしている企業がSSOとアカウント管理をまとめて整えたい場合の有力な選択肢になります。
3. Okta（Okta Japan株式会社）
Oktaが提供するWorkforce Identity Cloudは、従業員や委託先など「働く人」のIDを管理するクラウド型IDaaSです。SSO、多要素認証、利用者ディレクトリ、IDライフサイクル管理を統合して提供し、世界で2万社を超える導入実績を持ちます。
強みは、入社・異動・退職の一連の流れを自動化するライフサイクル管理です。人事システムとITインフラを接続し、入社時のアカウント自動作成、役割変更時の権限更新、退職時の即時アクセス失効までを一気通貫で自動化します。SCIM標準を用いて数千のアプリで自動プロビジョニングに対応しており、連携したいクラウドサービスが多い企業や、人事システムと連動させたい企業にとって有力な候補になります。
4. HENNGE One（HENNGE株式会社）
HENNGE Oneは、東証グロース上場のHENNGE株式会社が提供する国産のクラウドセキュリティ基盤で、SSOを担うID統制の機能と、メール・エンドポイントのセキュリティを一体で備えます。契約ユーザー数は300万を突破し、東京証券取引所の上場企業の約2割が利用しています。
ID統制のIdentity Editionでは、SAMLによるSSO、多要素認証、IPアドレスやデバイス証明書によるアクセス制御を提供します。連携するクラウドサービス数に応じた追加課金がない料金体系で、SAMLで接続したサービスへのアカウント連携にも対応します。情報漏えい対策や脅威対策の機能とまとめて導入したい企業にとって、検討しやすいサービスです。
5. トラスト・ログイン byGMO（GMOグローバルサイン株式会社）
GMOグローバルサイン株式会社が運営するトラスト・ログイン byGMOは、基本機能を無料プランで使い始められる点を訴求する国産のクラウド型ID管理サービスです。電子認証局を運営する同社のセキュリティ事業として展開されています。
SSOを中心に、ID管理・プロビジョニング、多要素認証、アクセス制限、ログ・レポートを備えます。多要素認証はワンタイムパスワードやパスキー（FIDO2）、メール送信型のワンタイムパスワードに対応し、社外のゲスト利用者にも認証を広げやすくなっています。アカウントの自動発行・更新・削除に対応する連携アプリも増えており、まずは費用を抑えて始めたい企業や、取引先を含むID管理を検討する企業に向いています。
6. OneLogin（One Identity）
OneLoginは、米国発のクラウド型ID管理サービス（IDaaS）で、現在はOne Identityのもとで提供されています。日本国内では、サイバネットシステムをはじめとする代理店を通じて販売・サポートが行われています。
SSO、多要素認証、ディレクトリ連携、ユーザープロビジョニングを統合し、Microsoft 365・Salesforce・Boxなどのクラウドアプリへのアクセスとアカウントの発行・変更・削除を集中管理します。
Active Directory上での利用者の追加・変更・削除を検出して連携先クラウドのアカウントに反映する仕組みを備え、退職処理に伴うアカウント停止も自動で反映できます。Active Directoryを運用しながらクラウドのSSOを整えたい企業の選択肢になります。
ここで取り上げた6サービス以外のSSO製品も含めて、料金・連携できるサービス数・対応する認証方式を横並びで見比べたい場合は、より多くの製品をランキング形式で比較した次の記事が参考になります。
まとめ
クラウドサービスへのSSO導入は、対象サービスと利用環境を棚卸しし、認証方式とサービスを選び、IdPと各サービスを連携設定して、テストから段階的に全社へ広げる、という流れで進めます。クラウドSaaS中心であれば、SAMLとOpenID Connectを軸に、SSO非対応のシステムは他の方式で補う構成が基本になります。
導入後の運用まで見据えると、SSO単体ではなく、多要素認証・アクセス制限・アカウントの自動管理（プロビジョニング）をあわせて整えることで、入口のセキュリティと入退社の棚卸しの両方を安定させられます。自社の環境に合うサービスを比較検討し、必要な機能が含まれるプランと費用、サポート体制を確認したうえで、導入を進めてください。
一括ダウンロードする
よくある質問（FAQ）
Q. SSO（シングルサインオン）とは何ですか？
A. SSO（シングルサインオン）とは、一度の認証で、連携した複数のクラウドサービスやシステムに追加のログインなしでアクセスできる仕組みです。利用者はサービスごとにIDとパスワードを入力する必要がなくなり、情報システム部門はアカウントを一元的に管理できるようになります。
認証を束ねる基盤（IdP）が利用者の本人確認を一手に引き受け、各クラウドサービスはその認証結果を信頼してログインを許可する、という形で成り立っています。
Q. クラウドへのSSO導入にはどのくらいの期間がかかりますか？
A. 導入規模によりますが、クラウド型（IDaaS）なら設定の着手は数日、小規模な連携なら数週間、全社展開まで含めると環境により数週間〜数か月を見込むのが一般的です。あらかじめ連携設定が用意されたSaaSが中心であれば、1サービスあたりの連携設定自体は短時間で済みます。
一方、SSO非対応の社内システムを含める場合や、全社展開の前にテストと段階展開を丁寧に行う場合は、その分の期間を見込んでおくと安全です。要件整理→方式選定→サービス選定→連携設定→テスト→段階展開という流れのうち、どの工程に時間がかかるかを最初に見積もると、無理のない計画を立てやすくなります。
Q. クラウドSSOの費用はどのくらいかかりますか？
A. クラウド型のSSO／IdPサービスは利用人数（ID数）に応じた月額課金が主流で、1IDあたり月額数百円から、機能が充実した上位プランで2,000円台まで、というのが一つの目安です。基本機能を無料で使えるプランを用意するサービスもあります。
ただし、多要素認証やプロビジョニング、アクセス制限といった機能が下位プランには含まれず上位プランで使える場合があるため、自社に必要な機能が含まれるプランを公式の料金ページで確認したうえで見積もることが大切です。
Q. SSOとIDaaSの違いは何ですか？
A. SSOは「一度の認証で複数のサービスにログインできる機能」を指し、IDaaSはそのSSOを含むID管理の機能群をクラウドで提供するサービスの総称です。SSOはIDaaSが備える中心機能の一つ、という関係にあります。
IDaaSは、SSOに加えて多要素認証、アカウントの自動発行・失効（プロビジョニング）、アクセス制限、ログ管理などをまとめて提供します。クラウドへのSSO導入を検討する際は、SSO単体ではなくIDaaSとして周辺機能まで一体で選ぶと、導入後の運用が安定しやすくなります。
Q. SSOと多要素認証（MFA）の違いは何ですか？
A. SSOは複数サービスへのログインを一度の認証にまとめて利便性を高める仕組みで、多要素認証（MFA）はそのログイン自体を複数の要素で確認してなりすましを防ぐ仕組みです。両者は競合するものではなく、組み合わせて使うのが基本です。
SSOは認証の入口を一本化するため、その入口が破られたときの影響が大きくなります。そこで、パスワードに加えてワンタイムパスワードやパスキー（FIDO2）などの要素を求めるMFAを重ねることで、入口のセキュリティを保ったまま一度のログインで済む利便性を得られます。
Q. SSOとソーシャルログインの違いは何ですか？
A. ソーシャルログインはGoogleやMicrosoftなど外部サービスの個人アカウントで別のサービスにログインする仕組みで、会社がIDを統制する企業向けSSOとは管理の主体が異なります。技術的にはどちらもOpenID ConnectなどのID連携の仕組みを使います。
ソーシャルログインが個人の持つ外部アカウントを利用するのに対し、企業向けSSOは会社が管理するIdPを基盤に、社員のアカウントの発行・失効やアクセス制限まで会社側で統制できる点が異なります。業務利用では、退職時のアカウント停止やアクセス管理を会社側で行える企業向けSSO（IDaaS）が適しています。
SSO・IDaaSの料金・資料を一括チェック
MCB FinTechカタログでは、クラウドへのSSO導入に使えるSSO・IDaaSサービスの最新資料を無料で一括請求できます。対応する認証方式・多要素認証・プロビジョニング・料金を見比べて、自社に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
