2026年の今、なぜSSOが重要なのか

どうも おかしん です。最近はAIの話ばっかりしてましたが、今日はSSOのお話です。

過去に私は以下のような記事も書いたことがあるのですが、久しぶりにアップデートしようかなと思います。

Webサービスの選定でSSOを見る理由は、ログインを楽にするためだけではありません。

会社で使うWebサービスやSaaSが増えるほど、アカウント発行、権限変更、退職者停止、MFA、監査ログ、パスワード管理、インシデント対応の負担は、サービスの数だけ増えていきます。

SSOが重要なのは、この増え方を抑えられるからです。

認証の入口を会社のIdPへ寄せる。MFAや条件付きアクセスをIdP側で効かせる。退職者の新規ログインを止める。ログを追えるようにする。利用者にサービスごとのパスワードを持たせない。

つまりSSOは、便利機能というより、Webサービスを会社として使い続けるための運用コストとセキュリティリスクを下げる仕組みです。

ただし、2026年の今は「SAML/SSOに対応していますか」だけでは足りません。SSOを強制できるか。直接ログインをどう扱うか。SCIMでユーザーを作成・停止できるか。MFAやPasskey、監査ログ、break-glassまで設計されているか。ここまで見ないと、企業利用に耐えるかは判断できません。

この記事では、Webサービスの選定においてなぜSSOが重要なのかを、あらためて整理します。

Webサービス活用はもう避けられない

まず前提として、会社でWebサービスやSaaSを使わないという選択肢は、かなり取りづらくなっています。

メール、チャット、Web会議、ファイル共有、契約、経費精算、採用、営業管理、問い合わせ管理、開発、デザイン、AI活用。業務の多くは、社内に閉じたシステムだけではなく、インターネット経由のサービスを組み合わせて動いています。

これは単に流行っているからではありません。

必要な機能を速く使えるからです。自社で一から作るより、すでにあるサービスを契約し、設定し、業務に組み込む方が速い。事業部門も現場も、その速さを前提に動いています。

だから、情シスやセキュリティ部門がWebサービスを一律に避けることは現実的ではありません。重要なのは、使うか使わないかではなく、会社として管理できる形で使えるかです。

機能要件だけを見るなら、「業務でやりたいことができるか」で選べます。

しかし、会社で使うならそれだけでは足りません。導入後に誰がアカウントを管理するのか。退職者をどう止めるのか。管理者権限を誰が持つのか。監査時に何を説明できるのか。事故が起きたときにログを出せるのか。こうした非機能の運用が、あとから効いてきます。

SSOは、この非機能の運用負荷を大きく左右します。

Webサービスが増えると、3つのコストが増える

Webサービスを1つだけ使うなら、個別のIDとパスワードでも何とかなるかもしれません。

でも、業務で使うサービスが10個、20個、30個と増えると話が変わります。Webサービスが増えるほど、次の3つのコストが増えます。

1つ目は、管理工数です。

入社した人にはアカウントを作る必要があります。異動した人には権限変更が必要です。退職した人は止めなければいけません。委託先や外部パートナーのアカウントもあります。管理者権限を持つ人は棚卸しが必要です。

これをサービスごとの管理画面で手作業すると、サービス数と利用者数に比例して工数が増えます。しかも、作業漏れがそのままリスクになります。

2つ目は、セキュリティ統制のコストです。

サービスごとにMFA、パスワードポリシー、ログ、管理者権限、アクセス制御の仕様が違うと、会社として同じ水準で守ることが難しくなります。

あるサービスではMFAを強制できる。別のサービスでは任意設定しかできない。あるサービスでは管理者操作ログが取れる。別のサービスではログ保持が短い。こうなると、会社全体の統制は一番弱いサービスに引っ張られます。

3つ目は、利用者側のパスワード管理コストです。

利用者がサービスごとにIDとパスワードを持つほど、使い回し、弱いパスワード、フィッシング、パスワードリセットが増えます。情シス側から見ると、パスワードリセット対応やアカウントロック対応も増えます。

この3つのコストが積み上がると、「誰がどのサービスに入れるのか」を説明できなくなります。

たとえば、退職者のGoogle WorkspaceやMicrosoft 365のアカウントは止めた。でも、部門が個別に契約していたSaaSにはまだログインできる。メールアドレスは無効になっていても、本人がIDとパスワードを覚えていれば入れる。

これは珍しい話ではありません。

SSOは、このコストをIdPへ寄せるためのもの

SSOという言葉は、どうしても「一度ログインすれば複数サービスに入れる」という利用者体験で語られがちです。

もちろん、それも重要です。利用者がサービスごとに別々のパスワードを覚えなくてよい。パスワードリセットの問い合わせも減る。フィッシングサイトに各SaaSのパスワードを入力する機会も減る。

ただ、企業利用におけるSSOの本質は、認証の入口をIdPへ寄せられることです。

ここで大事なのは、各Webサービスにもそれぞれの「本業」があるということです。

勤怠管理サービスなら、勤怠管理がコア機能です。経費精算サービスなら申請、承認、会計連携がコアです。予約サービスなら在庫、決済、通知、現場オペレーションがコアです。

もちろん、B2B向けのWebサービスであれば、認証、認可、監査ログ、ユーザー管理、権限管理は不可欠です。しかし、それらがプロダクトのコア機能より優先されることは多くありません。

これは個別のSaaSを責める話ではありません。SaaSベンダーは、自社の業務領域の価値を作るために開発リソースを使います。勤怠管理サービスなら勤怠集計、シフト、申請、法改正対応が優先される。予約サービスなら在庫管理、料金、通知、現場の運用が優先される。その結果、MFA、条件付きアクセス、詳細な監査ログ、SCIM、管理者保護のようなID管理まわりの機能は、どうしても後回しになりやすい。

一方で、IdPやIDaaSはID管理そのものがコア機能です。Microsoft Entra ID、Okta、Ping IdentityのようなID基盤は、認証、MFA、条件付きアクセス、デバイス条件、リスク検知、ログ、プロビジョニング、管理者保護を主戦場として作られています。膨大な企業の要件、監査、攻撃パターン、運用上の例外に向き合っている領域です。

だから、各SaaSが個別にMFAや監査機能を持つこと自体は大事ですが、会社全体の本人確認や入口統制の主役を各SaaSへ分散させるのは得策ではありません。入口の認証と共通統制はIdPへ寄せ、SaaS側は業務固有の権限、データ、操作ログをきちんと持つ。この役割分担にした方が、企業全体としては守りやすくなります。

IdP側でMFAを要求する。条件付きアクセスをかける。退職者の新規ログインを止める。危険なログインを検知する。パスワードポリシーやPasskeyを展開する。ログを集約する。

これらをサービスごとにバラバラにやるのではなく、会社のID基盤に寄せる。

だからSSOが重要です。

SSOがあると、Webサービスの選定基準は変わります。

「このサービスは便利か」だけではなく、「このサービスは会社のID管理の中に入れられるか」を見るようになります。これは、情シスやセキュリティ部門にとってかなり大きい違いです。

SSOに限定できないと、効果は半分になる

ここで重要なのが、SSOに対応していることと、SSOに限定できることは違う、という点です。

SAMLやOpenID ConnectでSSOできても、通常のID/Passwordログインが残っていると、IdPを迂回できます。

IdP側でMFAを強制していても、SaaS側の直接ログインではMFAが任意かもしれません。IdP側で退職者を停止していても、SaaS側のローカルアカウントで入れるかもしれません。IdP側で条件付きアクセスを設定していても、直接ログインには効かないかもしれません。

これでは、SSOを入れたつもりでも、統制が抜けます。

なので、Webサービスを選定するときは「SSO対応していますか」だけでなく、次を確認した方がよいです。

SSOは、設定できるだけでは足りません。

会社として守りたいログイン経路に限定できるかが重要です。

ただし、SSOに限定できても、すでにSaaS側で確立されたセッションが即時に失効するとは限りません。退職者対応や高リスク時の遮断まで考えるなら、SaaS側のセッションTTL、管理者によるセッション失効、SCIMによるdeactivateが何を無効化するか、そしてOpenID Continuous Access Evaluation Profile（CAEP）のように状態変化を継続的に伝える仕組みの対応有無も確認したいです。

この記事でいうSSOは、SAMLだけの話ではない

ここで言葉を揃えます。

この記事でいうSSOは、「利用者が1つのID基盤で複数のサービスへログインできること」くらいの広い意味で使います。技術的には、SAMLやOpenID Connectのようなフェデレーションプロトコルを使って、IdPが認証した結果をサービス側が信頼する構成です。

SAMLは今でもエンタープライズSSOで非常に重要です。多くのSaaSが対応していますし、既存の企業導入ではSAMLが前提になっていることも多いです。なので、「SAMLはもう古いから不要です」という話をしたいわけではありません。

一方で、2026年の今、新しくWebサービスやSaaSを作るなら、個人的にはOpenID Connect（OIDC）とSCIMの組み合わせがもっと主流になってほしいと思っています。

OpenID Connect Core 1.0は、OAuth 2.0の上にあるアイデンティティレイヤーとして、ClientがEnd-Userの本人性を検証するための仕組みを定義しています。ざっくり言えば、OAuth 2.0の仕組みを土台にしつつ、ID Tokenなどを使って「このユーザーは誰か」をアプリケーションが扱えるようにするものです。

ただし、OpenID Connectは認証連携の話です。

ユーザーを作る、部署変更を反映する、退職者を停止する、グループを同期する、といったライフサイクル管理は別の話です。そこで出てくるのがSCIMです。

RFC 7643とRFC 7644で定義されているSCIMは、クラウドサービス間でユーザーやグループの情報をプロビジョニング、管理するための仕様です。SCIMはSSOの代替ではありません。認証はOpenID ConnectやSAML、ユーザーやグループの作成・更新・停止はSCIM、という役割分担です。

なお、SCIMの中核がRFC 7643/7644であることは変わりませんが、2025年のRFC 9865はカーソルベースページネーションで両RFCを更新し、2026年のRFC 9967はSecurity Event Tokenによる非同期イベントのSCIMプロファイルとして両RFCを更新しています。実務上は「SCIM対応」の有無だけでなく、大量ユーザー同期、非同期イベント、deactivateの意味をどこまで実装しているかも見たいところです。

この組み合わせは、急に出てきた新しい話ではありません。OpenIDファウンデーション・ジャパンのEnterprise Identityワーキンググループも、2016年のOpenID ConnectとSCIMのエンタープライズ実装ガイドラインで、OpenID Connectを使った認証連携と、SCIMを使ったID管理により、利用企業の認証システムとクラウドサービスを相互接続する実装を整理しています。

10年前から方向性としては見えていた話が、SaaS利用の拡大、ゼロトラスト、MFA、Passkey、外部委託、監査ログの必要性によって、より現実的な要求になってきた。私はそう見ています。

SSOだけでは足りない。SCIMまで見たい

SSOでよくある誤解が、「SSOできればアカウント管理も自動化される」というものです。

されません。

SSOは、基本的には認証の話です。ユーザーがログインしようとしたとき、そのユーザーをIdPが認証し、サービス側がその結果を信頼する。これが中心です。

一方で、SaaS側にユーザーを作る、部署や役職を更新する、退職時に無効化する、グループを同期する、という話はプロビジョニングです。ここはSCIMなどの仕組みで別に考える必要があります。

SSOだけのサービスでよく起きるのは、ログイン時にはIdPで認証できるが、SaaS側のユーザーや権限は手作業で管理し続ける、という状態です。

これだと退職者のログインは止められても、SaaS上のユーザー棚卸しや権限管理は残ります。異動に伴う権限変更も手作業です。外部共有、管理者権限、グループ、ライセンス割り当てがSaaS側に残り続けます。

もちろん、すべてのSaaSがSCIMに対応できるわけではありません。SaaS側の権限モデルが単純すぎる、顧客ごとにロール設計が違いすぎる、IdP側の属性が整っていない、ということもあります。

それでも、会社として重要なSaaSを選ぶなら、2026年の確認項目としてSCIMは入れておきたいです。

SSOで入れるようにする。SSOに限定できるようにする。SCIMで作成・更新・停止できるようにする。グループや属性で権限を割り当てる。ログで説明できるようにする。

ここまで揃って、ようやく「会社として管理できるSaaS」に近づきます。

NCSCのSaaS安全利用ガイダンスでも、SaaS利用時にはオンボーディングとオフボーディング、信頼できるIDソース、可能な場合のSSO、SCIMのような自動ライフサイクル管理、MFA、レガシー認証の無効化、管理者保護、監査といった観点が扱われています。

個人的には、新規実装はOIDC + SCIMに寄ってほしい

ここは少し個人的な意見です。

既存のエンタープライズSaaSでは、SAML対応は今でも重要です。情シスやセキュリティ担当がSAMLを求めるのも自然です。IdP側の対応、既存の運用、顧客の調達要件を考えると、SAMLを無視するのは現実的ではありません。

ただ、新しくWebサービスやSaaSを作るなら、私はOIDC + SCIMに寄っていってほしいと思っています。

OIDCはOAuth 2.0のエコシステム上にあり、Webアプリ、モバイルアプリ、API、開発者体験との相性がよいです。ID Token、UserInfo、Discovery、JWT、JWK Setなど、現代的なWeb/APIの部品と自然につながります。SAMLのXMLベースの世界に比べると、Web開発者にとって扱いやすい場面が多い。

SCIMは、ユーザーとグループのライフサイクル管理を標準化するための道具です。認証だけOIDCに寄せても、退職者停止や権限変更が手作業なら、情シスの課題は残ります。だからOIDCとSCIMはセットで考えたい。

ただし、これは「SAMLは捨てましょう」という話ではありません。

実務では、顧客が使っているIdP、既存契約、監査要件、アプリの成熟度によって最適解は変わります。大企業向けに売るならSAML対応を求められる場面はまだ多いでしょう。既存のSAML連携が安定しているなら、無理にOIDCへ移行する必要もありません。

私が言いたいのは、これから作るなら、SSOを「SAML対応」の1行で終わらせず、OIDC、SCIM、MFA、ログ、緊急時の直接認証まで含めたID統制の部品として設計してほしい、ということです。

SSO、MFA、ログは高級機能なのか

ここまで書いてきたように、SSOは企業利用における基本的な統制機能です。

それでも現実には、SSOがEnterpriseプランに閉じ込められていることがあります。SSOを使うには上位プランが必要。最小契約ユーザー数がある。監査ログも上位プラン。SCIMも上位プラン。そういう料金設計は珍しくありません。

もちろん、SAMLやOIDC、SCIM、監査ログ、サポート、導入支援には開発コストも運用コストもあります。小さなサービスが最初から全部を無料で提供するのは難しい。そこは理解できます。

ただ、会社として安全に使うための最低条件が、極端に高いプランにしか存在しないと、利用企業は安いプランでID/Password運用を続けることになります。結果として、退職者停止、MFA、監査ログ、権限管理が弱くなる。

これは利用企業だけでなく、サービス提供者側にとっても望ましくありません。

CISAのSecure by Demand Guideでは、顧客が確認できる観点として、ベースライン版でログやSSOのような基本的なセキュリティ機能が含まれるか、標準ベースのSSOを追加費用なしで統合できるか、MFAやPasskeyのような認証を既定・無償で使えるか、SaaSでは少なくとも6か月分のセキュリティログを追加費用なしで提供するか、といった項目が挙げられています。

また、CISAのSSO導入障壁レポートでも、SMBにおけるSSO導入の障壁として、コスト、技術的ハードル、認知不足、リソース不足が挙げられています。SSOがプレミアムなEnterpriseサービスに含まれ、最小シート数や高いユーザー単価によって導入しづらくなる問題にも触れています。

私は、すべての高度なエンタープライズ機能を全プランで提供すべきだとは思いません。

ただ、SSO、MFA、最低限の監査ログ、管理者保護は、できるだけ基本機能側へ寄っていってほしい。高度な自動化、詳細な権限、長期ログ保持、SIEM連携、複雑なワークフロー、専任サポートを上位プランにする方が、健全だと思います。

一方で、すべてのWebサービスに対して「今すぐSAML、SCIM、SIEM連携まで実装すべき」と言いたいわけではありません。宿泊、飲食、小売、レジャーのような現場型のBtoBtoCサービスでは、1人1アカウントやIdPを前提にしづらいこともあります。このあたりの開発企業側・情シス側それぞれの見方は、別記事のなぜWebサービスにはSSOやMFAが実装されないのかで整理しました。

セキュリティを売上化するな、という単純な話ではありません。

基本的な安全機能を使いやすくした方が、結果としてサービスが業務プロセスの中に深く入り、長く使われやすくなるはずです。

SSOにも弱点はある

ここまでSSOの重要性を書いてきましたが、SSOにも弱点はあります。

一番分かりやすいのは、IdPが単一障害点になることです。IdPに障害が起きると、SSOしているサービスに入れなくなる可能性があります。設定ミスで全員が締め出されることもあります。IdPの管理者権限が侵害されれば、多くのサービスへの入口を握られます。

だからこそ、SSOを入れるときは、次の設計が必要です。

• break-glassアカウントを用意する
• break-glassには強いMFAと厳格な保管、利用ログ、通知を付ける
• 管理者権限は日常利用アカウントと分ける
• IdP管理者にはフィッシング耐性のあるMFAを優先する
• SSO設定変更、証明書更新、鍵更新、アプリ登録変更をログに残す
• IdP障害時に何が使えなくなるかを棚卸しする
• セキュリティ製品やインシデント対応ツールをSSO配下に置きすぎないか検討する

SSOは魔法ではありません。

SSOを入れることで、ID統制を中央に寄せられる。一方で、その中央の守り方と復旧手順が重要になる。この両方を見て、初めてSSOを会社の基盤として扱えます。

2026年のSaaS選定で見るべきこと

最後に、SaaSや業務向けWebサービスを選ぶときの確認項目としてまとめます。

この表は、すべてのサービスに一律で満点を求めるためのものではありません。

低リスクのサービスなら、まずMFAと管理者保護だけで十分なこともあります。現場型のBtoBtoCサービスなら、顧客の多くがIdPを持っていないこともあります。小さなSaaSに最初からSCIMやSIEM連携まで要求しても、現実的ではないことがあります。

それでも、会社の重要な業務やデータに深く入り込むサービスなら、この観点は避けられません。

Webサービスは、会社の外にある便利な道具ではなく、会社の業務とデータを動かす基盤になっています。

だからこそ、選定時には機能だけでなく、管理できるかを見た方がよいです。

SSOは、そのための入口です。

WebサービスやSaaSを企業で安全に使ってもらいたいなら、SSO、SSO強制、SCIM、MFA、ログ、管理者保護を、プロダクトの基本設計として扱ってほしい。

そして、これから新しく実装するなら、SAMLだけでなく、OIDC + SCIMを自然に選べる世界になってほしい。

その方が、使う側も、作る側も、長い目で楽になると思っています。