SaaSのシングルサインオン(SSO)をいつ入れるか：上げる線は席数ではなく「取りこぼしの条件」で決める(2026)

SaaSが10本20本と増え、入退社のたびに各サービスの管理画面を開いている中小〜中堅企業の情シス・バックオフィス担当の方に向けて、シングルサインオン(SSO: 1つのIDで複数のサービスにログインする仕組み)に踏み切る線の引き方をまとめました。台帳を手で回す段取りは入退社でSaaSアカウントを取りこぼさない手順にあります。本記事はその次の段、仕組みで回すかどうかを決める判断です。

最終更新: 2026年9月24日／Slack・Notion・Figma の公式ヘルプは同日に原文を確認。「(編集部)」はjisalab編集部の判断です。かぎ括弧「」でくくった文は各社の公式ページからの引用です。プランの条件は変わるため、実行前に各社の公式ページでご確認ください。

先に分ける：SSO(ログイン)とSCIM(アカウント)は別の機能です

SSOを検討するときにいちばん取り違えやすいのが、この2つです。SSOはログインの入口、SCIM(System for Cross-domain Identity Management: IDプロバイダ側の名簿をサービス側へ流す仕組み)はアカウントそのものの作成・停止を担当します。

同じサービスの中でも、入口の寄せ方によって差が出ます。Slackのヘルプは Google Workspace SSO の2つの方式を表で比べていて、「ユーザーの自動解除」の欄に印が付くのは Google SAML の側だけです。OAuth 2.0 を使う「Google 認証」の側には、事前プロビジョニングもカスタム SCIM プロフィールフィールドも印がありません。

同じページには、SAML ベースの SSO を使う Google Workspace 管理者はユーザープロビジョニングを管理できるとしたうえで、「ワークスペースを退会したりオーガナイゼーションを退職したりした人のアカウントは、自動的に解除されます。」と書かれた節もあります。入口の寄せ方によっては、停止までIDプロバイダ側で回る場合があるということです。だからこそ、どちらがどこまで動くのかをサービスごとに見ます。

パスワード管理SaaSとも役割が違います。パスワード管理は共有のIDとパスワードを安全に配るための道具で、SSOのように各サービスのログイン自体をIDプロバイダへ寄せるものではありません。少人数で先に手を付けるなら共有パスワードをExcelやチャットで回すのをやめる手順のほうが早く、SSOはその後段に来ます。

手順① 上げる線を、席数ではなく取りこぼしの条件で引く

何人からSSO、という線は引けません。5人でも10本のSaaSを使っていて退職者の停止が当日に終わっていないなら手数は限界で、50人でも3本なら台帳で足ります。手数を生むのは人数ではなく、1人あたりに開く管理画面の数と、止め忘れが表に出るまでの時間だからです。そこで、線を次の条件に置き換えます。

• 必須の条件／入口が散っている：1人の入退社で開く管理画面が5つ以上あり、順番を間違えるとアクセスが残る。
• 加えて、どちらか／止め忘れが実際に起きた：直近6か月で、退職・異動した人のアカウントが1件でも当日中に止まらなかった。
• 加えて、どちらか／突き合わせが追いつかない：台帳と各サービスの実際の在籍者を最後に突き合わせた日付が、1か月以上前になっている。

どれも自社の台帳とカレンダーだけで判定できます。判定が社内で完結するので、調べ始める日をその場で決められます。必須の条件が立たないなら、当たっているのは台帳運用の緩みだけなので、仕組みを買うより台帳の運用を直すほうが先に効きます。管理画面の数そのものを減らす方向なら、用途の重なりはプロジェクト管理SaaS比較：Notion vs ClickUp vs Asanaで確認できます。

手順② SSOとSCIMのプラン条件を、公式ページで別々に調べる

出典は Slack・Notion・Figma 各社のSAML SSOとSCIMの案内ページ、および Figma のシート種別のページ(いずれも末尾の出典欄)。表の列の立て方は編集部です。

読み方は1か所です。SSOの列とSCIMの列が同じか、ずれているかを見ます。Notionはずれていて、SSOだけならビジネスプランで足りますが、アカウントの作成・停止を流すにはエンタープライズプランに上げる必要があります。SlackとFigmaはずれていません。ただしどちらも、SCIMでできる操作の一部はさらに上のプランに置かれています(Slackはマルチチャンネルゲストの作成・無効化、Figmaはシート種別の設定)。

Notionにはもう一段あります。SSOの強制は検証済みドメインのメンバーに限られますが、メールドメインに関係なくワークスペースへのアクセスにSAML SSOを必須にする「ワークスペースレベルのSAML認証」が別にあり、そちらは「この機能は、エンタープライズプランをご利用のユーザーのみが利用可能です。」とされています。

SSOは上位プランだけ、という一般化も成り立ちません。Slackの Google Workspace SSO の案内ページは「有料プランでご利用いただけます」とし、Google 認証の設定手順を「プロプランとビジネスプラスプラン」の欄に置いています。「エンタープライズ向けプラン」の欄にあるのは手順ではなく、「Google Auth は Enterprise オーガナイゼーションでは利用できません。」という一文です。サービス名とプラン名は、付いている条件ごとセットで確認してください。

料金は席数・契約形態・支払い周期で変わるため、金額は書いていません。差額は各社の料金ページで、いま使っている席数のまま試算してください。

手順③ 切り替え当日に誰が締め出されるかを、先に書き出す

• ゲストの扱い：Notionは「ワークスペースのメンバーのみが、SAML SSOを使用してログインできます。」とし、ゲストは別の方法を使う必要があるとしています。Figmaも、ゲストは組織のSAML SSO設定にかかわらず Google SSO かメールアドレスとパスワードでログインできると説明します。Slackはゲストを除く全員にだけSSOを必須にする選択肢を案内しています。なお表のとおり、SlackでSCIMからマルチチャンネルゲストを作成・無効化できるのはエンタープライズ向けプランのみです。
• 管理者の逃げ道：Slackは Google Workspace SSO の案内ページで「ワークスペースのオーナーと OrG オーナーは、ログイン時にログインページ下部のリンクを使って SSO 認証をスキップし、メールアドレスとパスワードだけでサインインすることができます。」としています(SAMLの案内ページにも短い同趣旨の記載)。Notionは「IdPまたはSAMLの失敗が発生した場合」にバイパスできる人が決まっていて、組織レベルの設定なら組織オーナー、ワークスペースレベルならワークスペースオーナーのみです。どちらのレベルで管理しているかを確認してください。
• 登録アドレスのずれ：Figmaは、既存のファイルやフォルダへのアクセスを保つには会社のメールアドレスで登録されたアカウントが必要だとし、SAML SSOを設定する前に全員のアドレスを確認するよう勧めています。ドメインが未検証だと、新しい端末やブラウザで初回に6桁の確認コードを求められるとも書いています。
• 切り替えの猶予：Slackは、設定後にメンバーへ通知メールが届き「メンバーは、リンクの有効期間である 72 時間以内にアカウントをバインドさせる必要があります。」とします。既にサインイン中の人はそのままです。
• 戻し方：SlackはSSOを無効にできるとし、「SSO が OFF になっているときには、メンバーはメールアドレスと Slack のパスワードを利用してサインインします。」「メンバーは SSO の削除後、サインインするためにパスワードを設定する必要があります。」と説明します。別ページでは「設定を削除すると、IDP を使用して Slack にサインインしているすべてのメンバーがログアウトされます。」とあります。ただし無効化のページの利用条件には「プロ、ビジネスプラスの各プランで利用可能」とあり、エンタープライズ向けプランは挙げられていません。

費用面でもう1つ。Slackのヘルプは、「有料の Slack プランを利用している場合、SCIM により追加が承認されたメンバーとゲストは、初回のサインイン時点でアクティブユーザーとみなされ、料金が発生します。」としています。自動で作る仕組みは、自動で席を増やす仕組みでもあります。IDプロバイダ側のグループの中身を、切り替え前に必ず見てください。

多要素認証や管理者権限、外部共有、ログといった設定そのものの固め方はSaaSのセキュリティ設定を固める手順にまとめています。差額を社内で通す段取りはSaaS導入の社内決裁を通す手順が使えます。

次に取る行動

よくある質問