シングルサインオン(SSO)開発の進め方/やり方/流れや方法/手法/工程/手順

シングルサインオン(SSO)の開発は、要件整理、IdP選定、設計・テスト、段階移行、運用定着の順に進めると、安全な認証基盤につながります。

SSOの全体像、6フェーズの進め方、費用相場と見積もりの要点を、発注前に確かめたい順にまとめています。

▼全体ガイドの記事
・シングルサインオン(SSO)開発の完全ガイド

シングルサインオン(SSO)の全体像

従業員や取引先向けのWorkforce IAMと、顧客、患者、学生向けの顧客向けCIAMを左右に比べた図。
誰のIDを管理するかで、仕組みの対象が分かれます。

SSOでは、利用者の認証を担うIDプロバイダー(IdP)と、業務システムやSaaSのサービスプロバイダー(SP)を連携します。

利用者がIdPで認証すると、SPが認証情報を検証し、許可されたサービスへアクセスできます。

認証を一か所のIdPに集めるため、IdPを守るMFAや条件付きアクセス、緊急時の復旧手順が欠かせません。

従業員向けSSOと顧客向けCIAMの違い

まず決めるのは、誰のIDを管理するかです。対象は、次の2つに分かれます。

  • Workforce IAM:従業員や取引先が社内SaaSへ入る仕組み
  • 顧客向けCIAM:ECサイトや会員サービスで、顧客、患者、学生が自分で登録・退会する仕組み

CIAMでは、月間アクティブユーザー数、外部IdP連携、同意管理が要件になりやすいです。

加えて、会員属性、ブランド画面、高可用性も検討の対象になります。そのため、従業員向けのユーザー数だけで費用を見積もると、見積額が実態より少なくなります。

認証プロトコルとIDライフサイクルの一体設計

認証方式は、新規のWebアプリなら第一候補をOIDCとし、既存のエンタープライズSaaSならSAML 2.0への対応を確かめて選びます。IDの作成から無効化までの流れも、あわせて設計に含めます。

  • 新規のWebアプリ:第一候補はOpenID Connect(OIDC)
  • 既存のエンタープライズSaaS:SAML 2.0への対応の確認
  • OAuth 2.0:主にAPIへの認可を扱い、利用者のログインを表すOIDCとは役割が異なります。
  • プロビジョニング:SCIMなどを使えば、入社時のアカウント作成や退職時の無効化を自動化できます。
  • 反映の範囲:効果を出すには、属性、グループ、権限、退職日の反映まで業務フローに含めておく必要があります。

ポイント

迷ったときは、まず従業員向けSSOか顧客向けCIAMかを分けます。認証方式とIDのライフサイクルを一緒に考えると、後で設計を組み直す手間が減ります。

シングルサインオン(SSO)開発の進め方

現状棚卸しから代表アプリ検証、段階移行へ進み、切り戻し条件を設けるSSO導入の流れ。
代表アプリで確かめてから対象を広げる順序です。

SSOは、対象アプリを一度にすべて切り替えず、まず現状を洗い出し、代表アプリで検証してから段階的に広げます。

発注側と開発会社は、6つのフェーズを通じて、各段階の成果物と判断基準、リスクを明らかにします。

旧認証を止める条件と切り戻し条件は、規模にかかわらず先に決めておきます。

フェーズ1:要件整理による対象範囲と成功条件の決定

まずアプリケーション台帳を作り、対象アプリと例外アプリを整理します。この台帳は、後の連携方式の選定や移行の順番を決める材料になります。

  • 基本情報:サービス名、部門、利用者数、認証方式、管理者、契約更新日
  • データと連携:個人情報の有無、ログ保管期間、SAML・OIDC・SCIM対応
  • 環境:オンプレミスかクラウドか、Microsoft 365やGoogle Workspaceの利用状況
  • 対象範囲:古いWebアプリ、クライアントサーバー、VPN、共有アカウント、例外アプリ
  • 成功条件:問い合わせ削減数、退職者IDの無効化時間、棚卸し周期、重要アプリのMFA必須化

成果物は、現状構成図とアプリ台帳です。加えて、利用者・グループ一覧や、認証と権限の課題一覧も作ります。

対象範囲、KPI、前提条件は、これらにまとめます。

共有IDが見つかった場合は、SSO連携だけで済ませず、個人IDへ移行する方針も決めます。

フェーズ2:選定によるIdPと連携方式の比較

アプリ台帳をもとに、認証連携、既存ディレクトリ、運用支援のそれぞれが自社の条件に合うかを比べます。

  • 標準連携:SAML 2.0、OIDC、OAuth 2.0、SCIMの対応範囲
  • ディレクトリ:Active DirectoryやLDAPとの接続
  • 認証・記録:MFA、条件付きアクセス、パスキー、監査ログ、API
  • 運用支援:国内サポート、障害時のSLA、設定のエクスポート可否

フォーム認証だけで連携するアプリは、IDとパスワードを保管しやすい構成になります。そのため、標準プロトコルのアプリと比べて、リスクと運用費を高めに見積もります。

Microsoft 365契約にMicrosoft Entra IDが含まれている企業は、追加でIDaaSを契約する前に、現行ライセンスを確認します。

そのライセンスで、SSOやMFA、条件付きアクセスを使えるかを調べます。あわせて、ディレクトリ同期とプロビジョニングの利用範囲も確かめます。

Microsoft公式料金ページでは、2026年8月時点で、Entra ID P1が1ユーザー月額1,049円相当、P2が1,499円相当と示されています。

契約によっては、Microsoft 365で両方の機能を利用できる場合もあります(出典:Microsoft「Microsoft Entraのプランと価格」、2026年)。

最終的な判断では、既存契約との重複、管理者の習熟度、将来のオンプレミス連携も含めて考えます。

フェーズ3:設計・開発による認証と権限の実装

認証の流れだけでなく、利用者の属性と権限がIdPからSPへどう渡るかも図にします。設計では、IDの入社から退職までの扱い、権限の与え方、自社Webアプリと既存SaaSそれぞれの設定を定めます。

  • IDライフサイクル:人事マスタの入社、異動、休職、退職、再雇用をIdPとSPへ反映
  • 権限:職務・責任に沿うロールとグループ、管理者権限の分離
  • 自社Webアプリ:OIDC認可コード、リダイレクトURI、トークン期限、署名鍵、ログアウト、セッション無効化
  • 既存SaaS:SPメタデータ、証明書・期限、NameID、メール、グループ属性

部署名をそのまま権限に使うと、組織改編後も不要なアクセスが残るおそれがあります。

特権操作には、追加のMFAや承認を設定しておきます。

証明書や秘密鍵を更新する担当者も決めます。

更新担当が決まっていないと、期限切れによって全社のログインが止まることがあります。そのため、設定値を台帳にまとめ、手順書とテスト用アカウントを残しておきます。

フェーズ4:テストによる正常系と障害時の検証

SSOのテストでは、ログインの確認に加えて、次の操作や条件を正常系で検証します。

  • 利用操作:初回・再ログイン、ログアウト、パスワード変更
  • 認証設定:MFA登録、スマートフォン変更、グループ属性の反映
  • 利用環境:複数ブラウザー、複数拠点、時刻ずれ

権限テストでは、営業や経理、管理職の代表ロールを用意します。

さらに、システム管理者と退職予定者も含めます。そのうえで、閲覧可否が設計どおりかを確かめます。

障害系では、IdPやSPの停止とネットワーク断を再現します。加えて、証明書切れや署名不一致、属性欠落も再現しておきます。

SCIM同期の失敗、MFA端末の紛失、退職者の無効化遅延も、テストで確認します。

IdPの停止に備えて、緊急管理者とブレークグラス手順を準備します。連絡先と復旧目標時間も用意します。

パイロットでは、SAML対応SaaS、新規OIDCアプリ、古いフォーム認証の3種類を選ぶと、代表的な技術課題を早い段階で見つけられます。

フェーズ5:稼働による段階移行と切り戻しの管理

本番移行は、影響の小さいSaaSから始めます。利用者の反応や問い合わせを見ながら、重要業務へ広げていきます。

  1. 移行の単位(部署、拠点、アプリ)の決定と、先行グループの選定
  2. 並行稼働期間、旧認証の停止日時、停止判断者の明記
  3. ログイン成功率、MFA失敗数、問い合わせ、同期エラー、管理者操作の監視
  4. 基準に届かない場合の、旧認証への切り戻し

稼働直後は、権限不足、アカウント重複、個人メールの不一致に関する問い合わせが集中します。さらに、端末変更や共有IDの問い合わせも重なります。

そのため、ヘルプデスクには、本人確認、MFA再登録、ロック解除の手順を用意します。権限申請と緊急アクセスの手順も定めておきます。

完了条件には、旧アカウントの停止と未使用アカウントの整理を含めます。ログ監視と運用の引き継ぎも加えます。「全員がログインできた」ことは、完了条件の一つにすぎません。

フェーズ6:定着によるIDと権限の定期的な見直し

SSOは、稼働した時点で完成するものではありません。そのため、定期的な運用の中で、次の点を見直していきます。

  • IDと権限:退職・休職・異動、未使用ID、過剰権限、共有ID、管理者権限、MFA未登録者
  • 環境と監査:SaaS追加・組織変更時の台帳、グループ、ロール、ログ保管、ライセンス更新、アクセスと権限承認の記録
  • 効果測定:SSOログイン率、パスワードリセット数、MFA登録率、退職者無効化時間、棚卸し完了率、障害時間
  • 監視と拡張:異常アクセスと大量失敗、特権操作の確認担当。パスキーなどの導入候補

見直しは毎月か四半期ごとに行い、ログを確認する担当者を決めておきます。

2026年時点で拡張候補になるのは、フィッシング耐性の高いMFAとアクセスガバナンスです。加えて、AIやSaaSの増加に伴い、利用状況を洗い出すことも検討します。

ポイント

迷ったときは、代表アプリでの検証を先に行い、旧認証を止める条件と切り戻し条件を早めに決めておきます。規模にかかわらず、この順序で進めると判断が揃いやすくなります。

シングルサインオン(SSO)の費用相場とコストの内訳

5年間の総保有コスト(TCO)を導入時、移行時、運用時、拡張時の4区分に分けた図。
導入後に続く費用も同じ期間で見渡せます。

SSOの費用は、IdPやIDaaSのライセンス、初期設定、アプリ連携に分けて考えます。既存システムの改修とデータクレンジングも、区分して扱います。

テスト、教育、運用保守も費用に含めます。SCIMやログ保管、端末制御は、別途費用がかかる場合があります。外部ユーザー、サポート、冗長化の対応も、追加費用の対象になることがあります。

この記事で示す構築費は、製品の公式価格ではありません。対象人数、アプリ数、既存環境を前提に置いた推定レンジです。

人数と機能で変わるライセンス費

各社の公開料金を見ると、プランによって月額単価が異なります。

  • HENNGE One:Identity Editionは1ユーザーあたり月額300円から
  • トラスト・ログイン:SSOプロは1IDあたり月額300円、SSOプロ+SaaS管理は月額500円
  • Okta Workforce Identity:Starter、Core Essentials、Essentials

Oktaの3プランの公開月額は、1ユーザーあたり順に940円、2,020円、2,670円です。

これらの金額は、税区分や契約期間で変わります。最低契約額やオプションによっても違いが出ます。そのため、単価を単純に横並びで比べるのは避けます。

出典はHENNGE「価格とプラン」、GMOトラスト・ログイン「料金・機能」、Okta「プランと価格」、いずれも2026年確認です。

100人が1年間使う場合、上記の公開単価だけで計算すると、年額36万〜320万円程度が比較の起点です。

Microsoft Entra ID P1とP2は、2026年8月の公式表示でそれぞれ1ユーザーあたり月額1,049円相当、1,499円相当です。

Microsoft 365のプランに含まれている場合もあります(出典:Microsoft「Microsoft Entraのプランと価格」、2026年)。

まず既存契約に含まれる機能を確認し、追加購入が必要な機能だけを費用に計上します。

規模とレガシー連携で変わる構築・移行費

構築・移行費の推定レンジは、人数や連携条件によって異なります。

  • 小規模:50〜300人、SaaS 3〜10本。既存IdPがあり、標準連携が中心なら構築・設定・テストが100万〜300万円、1〜2カ月程度
  • 中規模:300〜1,000人、SaaS 10〜30本。300万〜800万円、3〜6カ月程度
  • 大規模:複数拠点・ドメイン、オンプレミスやレガシー認証を含む場合、800万〜2,000万円超、6〜12カ月以上となる可能性があります
  • CIAM構築:会員登録・同意・外部IdP・高可用性・サポートを作り込む場合、1,000万〜3,000万円超を見込むこともあります

中規模の想定には、Active Directoryや人事連携、MFAが含まれます。SCIMと権限設計も、この想定に入っています。

段階移行、冗長化、SOC連携は、大規模案件の費用や期間に影響します。

いずれも確定価格ではありません。

正式な見積もりに進む前に、アプリ数と利用者数を確認し、改修範囲と運用要件も詰めます。

5年TCOによるランニングコストまでの比較

初期費用と継続費用を分けたうえで、5年間の総保有コスト(TCO)を使って比較します。

  • 導入時:ライセンス、初期設定、アプリ連携、既存アプリ改修、データ整備
  • 移行時:端末や認証器、教育、移行期間の二重運用
  • 運用時:ライセンス、ログ、証明書・秘密鍵、棚卸し、ヘルプデスク、監視、障害対応
  • 拡張時:追加アプリの連携

見積書で「別途」とされた作業も含めて、5年間のTCOで比べます。そのため、初期費用が安くても運用負荷が高い構成を見つけられます。

ポイント

初期費用と継続費用を分けて、5年間の総保有コスト(TCO)で比べます。見積書で「別途」とされた作業も含めると、各社の金額を同じ条件で比べられます。

SSOの見積もりを取る際のポイント

SSOの見積もりは、アプリ数のほかに、連携方式や利用者の数、権限の複雑さで決まります。さらに、移行方法と運用体制によっても左右されます。

発注前に情報を揃えておけば、各社の前提がそろい、金額と提案内容を比べられます。

RFPには、「SSOを導入したい」という目的に加えて、対象範囲と受け入れ条件を具体的に記載します。

RFPに記載するアプリ・ID・運用の情報

RFPに書く内容は次のとおりです。前提が細かく書かれているほど、各社の見積もりを同じ条件で比べられます。

  • 対象環境:アプリ、利用者数、拠点・ドメイン、現行認証方式、共有アカウント
  • 連携と認証:SAML・OIDC・SCIM、Active Directory・人事連携、MFA要件
  • 運用条件:ログ保管期間、可用性、障害時の復旧目標。アプリを標準連携・追加設定・改修・対象外に分類
  • 受け入れテスト:ログイン、ログアウト、MFA、属性・グループ同期、入社・異動・退職、権限変更、証明書更新、障害復旧
  • 測定条件:退職情報の反映時間、MFA未登録者の扱い、IdP停止時の復旧開始時間

測定できない要件は、稼働後に追加費用や責任範囲の争点になりやすいです。

複数社比較で確認する構築後の運用体制

各社には同じRFPとアプリ台帳を渡し、費用を分けて提示してもらいます。

  • 導入費:初期費用、ライセンス、アプリ連携費、改修費
  • 移行・定着費:移行費、教育費、保守費、追加作業の単価

製品販売会社と、既存業務システムの設計・改修・運用を担うSIerとでは、得意な領域が異なります。

SAML・OIDCの連携数に加えて、レガシー認証と共有ID廃止の扱いを確かめます。さらに、権限を洗い出す方法、退職者の無効化、切り戻しの担当も確認します。

代表的な3アプリでPoCを実施できるかを尋ねます。SAML SaaS、新規OIDCアプリ、古いフォーム認証を含めると、技術上の制約と利用体験が見えてきます。

成果物のサンプルと担当者の経験を評価します。

国内サポート時間、SLA、ログ保存場所も、評価の対象に含めます。

設定のエクスポートや、契約終了時の移行支援も見ておきます。

2026年にNTTドコモビジネスが、社内ポータルからのSSO機能更新を公表しました。利用者の導線を変えずに段階導入できるかも、確認の対象になります(出典:NTTドコモビジネス「RINK IDaaS機能アップデート」、2026年)。

見積もりに含める集中リスクと切り戻し条件

IdP侵害は複数サービスへ影響するため、セキュリティ対策と復旧準備も見積もります。

  • 侵害対策:MFA、条件付きアクセス、端末制御、特権分離、異常ログ監視、最小権限
  • 認証強化:フィッシング耐性の高い認証、侵害時の検知と封じ込め
  • 復旧準備:段階移行、旧認証、緊急管理者、バックアップ、連絡網、復旧訓練
  • 移行・障害対応:リハーサル、夜間作業、並行稼働、問い合わせ、障害時の追加要員

便利さを前面に出し、IdP侵害時の検知と封じ込めに触れない会社は、セキュリティ要件を十分に理解していない可能性があります。

選ぶ際は、停止時の業務損失と復旧時間を含めたリスクコストで比べます。単価の安さは、その一部として見ます。

ポイント

金額を比べる前に、RFPの前提が各社で同じかを確かめます。前提がそろわないと、金額の差の理由が分かりません。

よくある質問(FAQ)

SSOの進め方は、現在の契約や既存システムによって変わります。

発注前によく寄せられる疑問に、順に答えます。

SSOのIdPはMicrosoft Entra IDと専用IDaaSのどちらがよいですか?

Microsoft 365中心で、Active DirectoryやMicrosoft製品との統合を重視する企業は、Entra IDの契約と機能を確認します。

複数クラウドやGoogle Workspace、レガシーアプリを重視する場合は、専用IDaaSも比較します。国内SaaSテンプレートや導入支援を重視する場合も、この候補に入ります。

利用アプリとMFA、SCIMの対応は、一つのRFPで比べます。ログと運用担当も、同じ条件で確認します。単価だけで判断すると、運用面の違いを見落とします。

SSOの開発期間は何カ月かかりますか?

標準連携中心で50〜300人、SaaS 3〜10本なら、要件整理からテストまで1〜2カ月程度が目安です。

人事連携やSCIM、権限設計を含むと、3〜6カ月程度です。オンプレミスや複数拠点、段階移行を含む場合も、期間は3〜6カ月程度です。大規模基盤では、6〜12カ月以上の可能性があります。

調査や意思決定が遅れると、開発会社の作業も止まります。そのため、アプリ台帳と担当者を早めに揃えておきます。

SSOを導入すればMFAは不要ですか?

SSOを導入しても、MFAは必要です。SSOはログイン回数を減らし、認証をIdPへ集約します。

IdPのパスワードだけで認証すると、情報が盗まれた際に複数サービスへ不正アクセスされるおそれがあります。

MFAや条件付きアクセスを組み合わせ、さらに端末や場所に応じた制御を加えます。異常ログの監視と緊急アカウントの管理も、あわせて行います。重要アプリには、特に強い認証を適用します。

古い業務システムがSAMLやOIDCに対応していなくてもSSOできますか?

可能な場合があります。フォーム認証の代理入力、リバースプロキシ、アクセスゲートウェイなどを検討します。

標準プロトコルのSSOと比べると、パスワードの保管や画面変更への追随が必要になりやすいです。障害時の切り分けや追加ライセンスも、負担として見込みます。そのため、短期的な代替策として位置付けます。

中長期では、アプリをOIDCなどへ改修する費用と、現行方式を維持する場合の5年TCOを比べ、移行計画を決めます。

顧客向けのログインも従業員向けSSOと同じ費用で作れますか?

顧客向けCIAMは、従業員向けSSOとは費用の前提が異なります。会員やサービス運営に関する要件が加わるためです。

  • 会員対応:月間アクティブユーザー、登録・退会、パスワード再設定
  • 顧客情報:同意履歴、会員属性、ソーシャルログインや外部IdP
  • サービス運営:問い合わせ対応、高可用性

Okta公式価格ページでは、Customer IdentityのEnterpriseベース製品が月額470,000円からと示されています。

アドオンは利用量などで変わります(出典:Okta「プランと価格」、2026年確認)。

見積もりでは、従業員数よりも、MAUや認証回数を含めて考えます。

まとめ

SSOの開発は、6つのフェーズに分けて進めると、判断の漏れを防ぎやすくなります。

まず従業員向けSSOか顧客向けCIAMかを分けます。そのうえで、アプリと認証の方式、利用者と権限を整理し、入退社、ログ、障害復旧の扱いも決めます。

SAML・OIDC・SCIMとの適合性を確認します。次に、代表アプリでPoCを行い、段階的に移行します。

発注前に確認するチェックリスト

見積もりを依頼する前に、次の項目を揃えておきます。前提がそろえば、各社の金額と提案内容を同じ条件で比べられます。

  • 対象と利用者:対象アプリと利用者数の確定
  • 既存契約:Microsoft 365など、契約済みのサービスに含まれる機能
  • 連携とID:アプリごとのSAML・OIDC・SCIM対応、入社・異動・退職に伴うIDの流れ、MFAと最小権限の要件
  • 費用の内訳:初期費用、ライセンス、連携と改修を分けて見積もる(移行と保守の費用、5年TCOを含む)
  • 運用の備え:切り戻し、障害連絡先、運用教育も見積もりに入れる

最初に行う現状のIDとアプリの洗い出し

製品を選ぶ前に、現状のIDとアプリを洗い出します。認証方式や権限、運用フローも確かめます。

  1. 整理が難しい場合は、開発会社へ相談します。相談先は、改修や移行、セキュリティ、運用に対応できる会社が向いています。
  2. アプリ台帳と受け入れ条件をもとにした、複数社からの提案
  3. 認証集約の効果と集中リスクを評価したうえで、安全な基盤を段階的につくります。

▼全体ガイドの記事
・シングルサインオン(SSO)開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。