IdP導入の隠れたコスト、SSOとSCIMのために接続先SaaSのプランアップが必要になる話

IDチームの前田です。

私の所属するIDチームではIdP導入の技術支援を行っており、Entra IDやOkta、PingOneを主に扱っています。

IdP導入の作業でいつも時間がかかるのは、IdP側の設定ではなく、SSOをかける先のサービスを契約プランまで含めて洗い出すところです。
「SSOをかけたいサービスを、契約プランまで入れて一覧にしてください」とお願いすると、サービス名の列はすぐ埋まるのですが、プラン名の列は空のまま戻ってくることが多く、接続を進めようとした段階でプランが足りずに止まることがあります。

さて、今回はIdPを選ぶときに見落とされやすい、接続先のプランアップのコストの話です。

3行まとめ

• SSOやSCIMは接続先のSaaS側で上位プランの機能になっていることが多く、IdPのライセンス費用だけでは予算が足りない
• プランを上げないと決めたサービスはSSOの対象外になるので、ユーザーはそこを個別IDで使い続けることになる
• IdPを選ぶ段階で、接続先のプランが足りているかどうかも一緒に確認しておきたい

接続先にもコストがかかる

IdP自体の費用は稟議に乗る金額なので、たいてい最初から予算に入っています。

予算として抜けやすいのは接続先のほうです。
SSOとSCIMはIdPだけでは成立せず、つながれる側のSaaSが受け口を出していてはじめて使えるのですが、その受け口が多くのSaaSで上位プランの機能として提供されています。

つまりIdP導入には、利用中のSaaSのプランアップのコストが付いてくることになります。

どのプランからSSOやSCIMが使えるか

2026年10月時点で、各社の公式ページに書かれている条件です。
プランの区切りは改定されるので、確認するときは最新の公式ページを見てください。

Slackには例外があって、フリープランとプロプランでも、Salesforce組織をSlackに接続済みであればSSOとSCIMが使えます（プランごとの機能）。

公式ページの金額にすると差の幅が見えます。
Notionは料金ページの表示でPlusが1ユーザーあたり月額1,650円、Businessが3,150円です。
GitHubは初年度価格の表示でTeamが4ドル、Enterpriseが21ドルです（Notionの料金、GitHubの料金）。

ユーザー数を掛けると、IdPのライセンス費用と同じくらいの額になることもあります。

上位プラン限定になっているかどうかはサービスごとに違うので、使っているものを一つずつ確認することになります。

SSOを上位プランに置く売り方については、The SSO Wall of Shame というリストがあり、ベンダーごとに基本料金とSSO利用時の料金が並べられています。

SSOが入ってもプロビジョニングはなし

表を見ると、SCIMの列とSSOの列が揃っていないサービスがあります。

Notionの場合、Businessに上げればSAML SSOは使えますが、SCIMはEnterpriseだけなので、ログインをIdP経由にしてもアカウントの作成と無効化は手作業のまま残ります。

Zoomは、SAMLレスポンスを受け取ったときにユーザーがいなければアカウントを自動で作ってくれるので入社時の手間は減りますが、IdP側で無効にしたユーザーをZoom側でも無効にする動きは別の仕組みになります。

SSOの対応状況とSCIMの対応状況は分けて確認しておくと、設計や移行の段階で齟齬が出にくいです。

一部だけSSO化した状態

予算が出ない、契約更新の時期が合わない、使っている部署が限られているといった理由で、プランを上げないという判断になることもあります。
その場合、そのサービスはSSOとプロビジョニングの対象から外れます。

対象から外れたサービスは、ユーザーの手元ではこれまでと変わらず、ブラウザに保存されたパスワードで入れるので、IdPのポータルを経由する理由がありません。
一部だけSSO化された状態だと、「全部ここから入る」という運用に切り替えるのが難しくなります。

IdP側でアカウントを止めてもそのサービスには効かないので、棚卸しの台帳が二つに分かれたままになります。

接続先の一覧を作る

筆者が案件の最初にやるのは、接続先を並べて、SSOとSCIMに必要なプランやアドオンを調べていく作業です。
金額の計算と予算化は情シスや購買の側の仕事なので、こちらは接続できるかどうかと、そのために必要なプランを一覧に出すところまでを受け持ちます。

列はこれくらいで足ります。

• サービス名と現在の契約プラン
• 対象ユーザー数
• SSOとSCIMに必要なプラン、またはアドオン
• 年額差額
• 優先度

全部を同時に上げる予算は出ないことが多いので、優先度の列をどう埋めるかが残ります。
筆者の場合は、利用者の広さ、扱うデータの機密性、破られたときの影響の3つを見ています。

参考になる整理もいくつか公開されています。
Microsoftのアプリ統合ガイダンスは、優先順位を決めるパラメータとして「最も頻繁に使われているアプリ」「最もリスクの高いアプリ」「廃止予定のため移行対象外とするアプリ」を挙げています（Five steps to integrate your apps with Microsoft Entra ID）。
廃止予定のサービスを対象から外せる分、差額の計算は軽くなります。

影響の大きさについては、NIST SP 800-63-4に、認証や識別が破られたときの影響をいくつかのカテゴリに分けて、カテゴリごとにLow / Moderate / Highを付ける整理があります（NIST SP 800-63-4）。
サービスごとに影響の大きさを書いておくと、優先度の列を埋めるときの材料になります。

CISAのZero Trust Maturity Model v2は、IDストアの統合を段階で分けていて、Advancedが「一部を安全に統合し始める」、Optimalが「すべての環境にわたって統合する」です（Zero Trust Maturity Model、2023年4月）。
初年度から全部つながっている状態を前提にしなくてよい、という整理になっています。

差額と影響を同じ一覧に並べておくと、どのサービスから上げるかを相談するときに材料が揃います。

プランを上げないサービスでの打ち手

プランを上げないと決めたサービスについても、入り口だけならIdP側に寄せる方法があります。
SAMLとSCIMの代わりにはなりませんが、選択肢として挙げておきます。

ひとつは、パスワードマネージャーを間に置く形です。
個別IDの資格情報を共有の保管庫に入れて、パスワードマネージャー自体をIdPにつなぎます。
Keeper Password Managerの場合、Keeper SSO Connect CloudがSAML 2.0でIdPと連携する仕組みで、対応するIdPにはOkta、Microsoft Entra ID / Azure AD、Google Workspace、OneLogin、Ping Identity、JumpCloudなどが挙げられています。
SCIMによるプロビジョニングでは、ユーザーの作成、属性の更新、ユーザーの削除（Keeper側ではロック）、IdPのグループからチームを作ってメンバーを追加・削除する、といった操作が流れます。
どちらもEnterpriseプランの機能で、Business StarterとBusinessプランには含まれていません（SSO Connect Cloud、SCIMプロビジョニング、料金）。
IdPでユーザーを止めると保管庫に入れなくなるので、サービス側のIDが生きていても資格情報には手が届かなくなります。

パスワードの値をユーザーに見せないまま使わせる設定もあります。
Keeperのロールには、ドメインを指定してパスワードの表示を制御するApply Privacy Screen Setting（Prevent Viewing Passwords）という強制ポリシーがあり、対象のレコードではユーザーがマスクを外せなくなります。
編集権限を持っている場合でも、パスワード欄の更新はパスワードジェネレーター経由だけになります（Enforcement Policies）。

ただし、同じドキュメントに限界も書かれています。
マスクは表示上のもので、パスワード自体はユーザーの保管庫に残っていて、APIの通信やブラウザの開発者ツールからは参照できます。
効く範囲もユーザーやチームに共有されたレコードまでで、ユーザー自身が所有しているレコードは引き続き表示も更新もできます。

値そのものを渡さない形もあります。
KeeperPAMのRemote Browser Isolationでは、Keeper Gatewayが隔離されたChromiumの中で資格情報を入力し、その画面だけがユーザーのボルトに投影されます。
公式ドキュメントには「Credentials are never exposed to the user」と書かれていて、対象のレコードはKeeper Gatewayに紐づく共有フォルダに置く必要があります（Remote Browser Isolation、Browser Autofill）。
料金ページの比較表では、リモートブラウザ分離はBusinessとEnterpriseのアドオンという扱いで、Business Starterには含まれていません（料金）。

もうひとつは、GoogleアカウントやMicrosoftアカウントでのログインに寄せる形です。
SAMLが上位プラン限定でも、OIDCのソーシャルログインなら下位プランで使えることがあり、このあたりもサービスとプランごとに違うので確認が必要です。

どちらも代替の手段なので、次のようなものは対応ができません。

• アカウントの自動作成と自動削除
• IdPへのログの集約
• 直接サインインされた経路への条件付きアクセスやデバイス制御
• サービス側に残る個別IDの棚卸し
• パスワードの値そのものの秘匿（マスクは表示の制御で、値は保管庫に残る）

代替で済ませると決めたサービスも、どう扱うことにしたかを一覧に残しておくと、あとから見返せ、後日に対応などが可能です

所感

• 導入が止まりやすいのはIdP側の設定ではなく、接続先のプランが足りているかどうかのことが多い。対象サービスとそのプランは早めに洗い出しておくと進めやすい
• SSOの対応状況とSCIMの対応状況は別に確認しておくと、あとで齟齬が出にくい
• 対象から外したサービスがあると、ユーザーの入り口はそのぶん変わらないままになる
• 優先度は、利用者の広さ、データの機密性、破られたときの影響あたりを見て決めている
• 上げないサービスも入り口だけなら寄せられるが、自動プロビジョニングとログの集約は落ちてしまう

IdPを導入する際には、接続するサービスの契約プランも事前に把握しておく必要があります