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

シングルサインオン(SSO)の開発は、ログイン画面を一つにまとめるだけではなく、IDの発行・変更・削除、MFA、権限、監査ログまでを一つの認証基盤として設計することが成功の条件です。

「何から着手すればよいか」「SAMLとOIDCはどちらを選ぶべきか」「費用と期間はどの程度か」と迷う企業に向けて、この記事では、要件整理、サービス選定、設計・開発、テスト、稼働、定着の6フェーズで進め方を解説します。Microsoft 365やGoogle Workspaceを利用している企業、オンプレミスの業務システムが残る企業、顧客向けサービスを運営する企業が、発注前に確認できる判断基準とチェック項目もまとめます。

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

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

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

SSOでは、利用者の認証を担うIDプロバイダー(IdP)と、利用者が使う業務システムやSaaSであるサービスプロバイダー(SP)を連携させます。利用者がIdPで認証すると、IdPが発行した認証情報をSPが検証し、許可されたサービスへアクセスできる仕組みです。認証を集約するため便利になる一方、IdPを守るMFA、条件付きアクセス、緊急時の復旧手順が欠かせません。

従業員向けSSOと顧客向けCIAMを分けて考えます

最初に、誰のIDを管理するのかを明確にします。従業員、派遣社員、取引先の担当者が社内SaaSへ入る仕組みはWorkforce IAMの領域です。一方、ECサイトや会員サービスの顧客、患者、学生などが自分で登録・退会する仕組みは、顧客向けのCIAMです。CIAMでは、月間アクティブユーザー数、外部IdPとの連携、同意管理、会員属性、ブランドに合わせた画面、高可用性が要件になりやすく、従業員向けSSOのユーザー数だけで費用を見積もると不足します。

認証プロトコルとIDライフサイクルを一緒に設計します

新規WebアプリではOpenID Connect(OIDC)を第一候補にし、既存のエンタープライズSaaSではSAML 2.0の対応可否を確認する進め方が一般的です。OAuth 2.0は主にAPIへの認可を扱う仕組みであり、利用者のログインそのものを表すOIDCと同じものではありません。また、SCIMなどのプロビジョニングを使えば、入社時のアカウント作成や退職時の無効化を自動化できます。認証連携だけでなく、属性、グループ、権限、退職日の反映までを一つの業務フローに落とし込みます。

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

シングルサインオン開発の進行イメージ

SSOの導入は、対象アプリを一度に切り替えるのではなく、現状を棚卸しして代表的なアプリで検証し、段階的に広げる流れが安全です。次の6フェーズでは、各段階の成果物、判断基準、見落としやすいリスクを具体化します。規模にかかわらず、旧認証を止める条件と、問題が起きたときの切り戻し条件を先に決めておくことが重要です。

フェーズ1:要件整理で対象範囲と成功条件を決めます

最初に、アプリケーション台帳を作ります。サービス名、利用部門、利用者数、認証方式、管理者、契約更新日、個人情報の有無、ログ保管期間、SAML・OIDC・SCIM対応、オンプレミスかクラウドかを記録します。Microsoft 365やGoogle WorkspaceをIdPとして使える場合でも、古いWebアプリ、クライアントサーバー、VPN、共有アカウントが残っていないかを確認します。対象を「SSOできるアプリ」だけでなく、「当面は例外として残るアプリ」まで含めて一覧化することがポイントです。

次に、経営・情報システム・現場・監査の目標を数値化します。たとえば、ログイン問い合わせを月何件減らすか、退職者のアカウントを何分以内に無効化するか、未利用アカウントを何日ごとに棚卸しするか、重要アプリに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へどのように伝わるかを定義します。部署名をそのまま権限に使うと組織改編で意図しないアクセスが残るため、職務や業務上の責任に合わせたロールとグループを設計します。管理者権限は一般利用者と分離し、特権操作には追加のMFAや承認を設定します。

自社開発のWebアプリはOIDCの認可コードフロー、リダイレクトURI、トークンの有効期限、署名鍵のローテーション、ログアウト、セッション無効化を設計します。既存SaaSはSPメタデータ、証明書、有効期限、NameID、メールアドレス、グループ属性を確認します。証明書や秘密鍵の更新担当を決めないまま稼働すると、期限切れで全社のログインが止まることがあります。アプリごとの設定値を台帳化し、手順書とテスト用アカウントを残します。

フェーズ4:テストで正常系と障害時の両方を検証します

SSOのテストは、ログインできることだけを確認して終わりにしません。正常系では、初回ログイン、2回目以降のアクセス、ログアウト、パスワード変更、MFA登録、スマートフォン変更、グループ属性の反映、複数ブラウザー、複数拠点、時刻ずれを検証します。権限テストでは、営業、経理、管理職、システム管理者、退職予定者などの代表ロールを用意し、見えるサービスと見えないサービスが設計どおりかを確認します。

障害系では、IdP停止、SP停止、ネットワーク断、証明書期限切れ、署名不一致、属性欠落、SCIM同期失敗、MFA端末紛失、退職者の無効化遅延を再現します。IdPにアクセスできないと全サービスに入れなくなるため、緊急管理者アカウント、ブレークグラス手順、連絡先、復旧目標時間を準備します。パイロットでは、SAML対応の既存SaaS、新規OIDCアプリ、古いフォーム認証の3種類を選ぶと、代表的な技術課題を早期に見つけやすいです。

フェーズ5:稼働で段階移行と切り戻しを管理します

本番移行は、影響の小さいSaaSから開始し、利用者の反応と問い合わせを確認してから重要業務へ広げます。部署単位、拠点単位、アプリ単位のどれで移行するかを決め、先行グループ、並行稼働期間、旧認証を停止する日時、停止判断者を明記します。移行当日は、ログイン成功率、MFA失敗数、問い合わせ件数、同期エラー、管理者操作を監視し、基準を下回った場合は旧認証へ戻します。

稼働直後の問い合わせは、認証失敗だけでなく、権限不足、アカウント重複、個人メールアドレスの不一致、スマートフォンの機種変更、共有IDの扱いに集中します。ヘルプデスク向けに、本人確認、MFA再登録、ロック解除、権限申請、緊急アクセスの手順を用意します。移行完了の条件は「全員がログインできた」ではなく、旧アカウントの停止、未使用アカウントの整理、ログ監視、運用引き継ぎまで含めて定義します。

フェーズ6:定着でIDと権限を継続的に見直します

SSOは稼働した時点が完成ではありません。毎月または四半期ごとに、退職者・休職者・異動者の反映、未使用アカウント、過剰権限、共有ID、管理者権限、MFA未登録者を確認します。SaaSの追加や組織変更のたびに、アプリ台帳、グループ、ロール、ログ保管、契約ライセンスを更新します。監査では、誰がいつどのサービスへアクセスしたか、権限付与の承認が残っているかを説明できる状態にします。

定着を測るKPIには、SSO経由ログイン率、パスワードリセット件数、MFA登録率、退職者無効化の平均時間、権限棚卸しの完了率、認証関連の障害時間を使います。ログを保管するだけでは改善につながらないため、異常な場所や端末からのアクセス、短時間の大量失敗、特権操作を誰が確認するかを決めます。2026年時点ではパスキーやフィッシング耐性の高いMFA、アクセスガバナンス、AI・SaaS増加に伴う利用状況の棚卸しも、導入後の拡張候補になります。

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

シングルサインオンの費用とライセンス

SSOの費用は、IdPやIDaaSのライセンス、初期設定、アプリ連携、既存システム改修、データクレンジング、テスト、教育、運用保守に分けて考えます。ライセンス単価だけを比べると、SCIM、ログ保管、端末制御、外部ユーザー、サポート、冗長化などの費用が後から加わります。以下の構築費は公式の製品価格ではなく、対象人数・アプリ数・既存環境を置いた記事用の推定レンジです。

ライセンス費は人数と機能で変わります

公開料金の例では、HENNGE One Identity Editionが1ユーザーあたり月額300円から、GMOトラスト・ログインのSSOプロが1IDあたり月額300円、SSOプロ+SaaS管理が月額500円、Okta Workforce IdentityのStarterが1ユーザーあたり月額940円、Core Essentialsが2,020円、Essentialsが2,670円と表示されています(出典: HENNGE「価格とプラン」、GMOトラスト・ログイン「料金・機能」、Okta「プランと価格」、いずれも2026年確認)。これらは税区分、契約期間、最低契約額、オプションによって変わるため、単純な横並びにはしません。

100人が1年間使うと仮定した場合、上記の公開単価だけなら、おおむね年額36万円から320万円程度が比較の起点になります。Microsoft Entra ID P1とP2は、2026年8月の公式表示でそれぞれ月額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本、Active Directoryや人事連携、MFA、SCIM、権限設計を含めると、300万〜800万円、3〜6カ月程度が一つの推定レンジです。

複数拠点、複数ドメイン、オンプレミスやレガシー認証、段階移行、冗長化、SOC連携まで含む大規模案件では、800万〜2,000万円超、6〜12カ月以上となる可能性があります。顧客向けCIAMを新規に構築し、会員登録、同意、外部IdP、高可用性、サポートを作り込む場合は、1,000万〜3,000万円超を見込むこともあります。いずれも確定価格ではなく、対象アプリ、利用者数、改修範囲、運用要件を確認してから正式見積もりに進みます。

5年TCOでランニングコストまで比較します

初期費用の比較では、ライセンス、初期設定、アプリごとの連携、既存アプリ改修、データ整備、端末や認証器、教育、移行期間の二重運用を分けます。運用費には、ライセンス更新、ログ保管、証明書・秘密鍵の更新、アカウント棚卸し、ヘルプデスク、監視、障害対応、追加アプリの連携を含めます。見積書に含まれない作業を「別途」としたままにせず、5年間の総保有コスト(TCO)で比較すると、初期費用が安くても運用負荷が高い構成を見つけやすくなります。

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

シングルサインオンの見積もりと要件整理

SSOの見積もりは、アプリ数だけでなく、連携方式、利用者の種類、権限の複雑さ、移行方法、運用体制で変わります。発注前に情報を揃えるほど、会社ごとの前提が揃い、金額と提案内容を比較しやすくなります。RFPでは「SSOを導入したい」とだけ書かず、対象範囲と受け入れ条件を具体的に記載します。

RFPにはアプリ・ID・運用の情報を記載します

最低限、対象アプリの一覧、利用者数、拠点・ドメイン、現行の認証方式、SAML・OIDC・SCIM対応状況、Active Directoryや人事システムとの連携、共有アカウント、MFA要件、ログ保管期間、可用性、障害時の復旧目標を記載します。アプリごとに「標準連携」「追加設定」「改修が必要」「当面は対象外」を分けると、見積もりの抜け漏れを抑えられます。

受け入れ条件には、初回ログイン、SSOログイン、ログアウト、MFA、属性・グループ同期、入社・異動・退職、権限変更、証明書更新、障害復旧を含めます。たとえば「退職情報を人事マスタへ登録してから何分以内に対象アプリへ反映するか」「MFA未登録者をどう扱うか」「IdP停止時に管理者が何分以内に復旧操作を開始できるか」を決めます。測定できない要件は、稼働後の追加費用や責任範囲の争点になりやすいです。

複数社比較では構築後の運用体制を確認します

比較する会社には、同じRFPとアプリ台帳を渡し、初期費用、ライセンス、アプリ連携費、改修費、移行費、教育費、保守費、追加作業の単価を分けて提示してもらいます。製品を販売する会社と、既存業務システムの設計・改修・運用まで担うSIerでは得意領域が異なります。SAMLやOIDCの連携数だけでなく、レガシー認証、共有IDの廃止、権限棚卸し、退職者無効化、障害時の切り戻しを誰が担当するかを確認します。

提案時には、代表的な3アプリでPoCを実施できるかを聞きます。SAML対応SaaS、新規OIDCアプリ、古いフォーム認証を含めれば、技術的な制約と利用者体験が見えます。成果物のサンプル、担当者の経験、国内サポートの時間帯、SLA、ログの保存場所、設定のエクスポート、契約終了時の移行支援も評価します。2026年にNTTドコモビジネスが社内ポータルからのSSO機能更新を公表したように、利用者の導線を変えずに段階導入できる提案かも確認対象になります(出典: NTTドコモビジネス「RINK IDaaS機能アップデート」、2026年)。

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

SSOでは一つの認証情報で多くのサービスへアクセスできるため、IdPアカウントが奪われた場合の影響が大きくなります。MFA、条件付きアクセス、端末制御、特権アカウントの分離、異常ログ監視、最小権限、フィッシング耐性の高い認証を見積もりへ含めます。便利さだけを訴求し、IdP侵害時の検知と封じ込めを提案しない会社は、セキュリティ要件を十分に理解していない可能性があります。

また、全社一斉切り替えではなく段階移行を前提にし、切り戻し用の旧認証、緊急管理者、バックアップ、連絡網、復旧訓練を確認します。見積もりには、リハーサル、夜間作業、並行稼働、問い合わせ対応、障害時の追加要員を含めます。最安値だけで選ばず、停止時の業務損失と復旧時間を含めたリスクコストで比較することが大切です。

よくある質問(FAQ)

シングルサインオンのよくある質問

SSOの導入では、現在の契約や既存システムによって最適な進め方が変わります。ここでは、発注前に多く寄せられる疑問へ直接回答します。

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

Microsoft 365を中心に利用し、既存のActive DirectoryやMicrosoft製品との統合を重視する企業は、まずMicrosoft Entra IDの契約と機能を確認する進め方が適しています。複数クラウド、Google Workspace、レガシーアプリ、豊富な国内SaaSテンプレート、導入支援を重視する場合は、専用IDaaSも比較対象になります。利用アプリ、MFA、SCIM、ログ、運用担当を同じRFPで比較し、単価だけで決めないことが重要です。

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

標準連携が中心で、50〜300人、SaaSが3〜10本程度なら、要件整理からテストまで1〜2カ月程度が一つの目安です。人事連携、SCIM、権限設計、オンプレミスアプリ、複数拠点、段階移行を含むと、3〜6カ月程度、さらに大規模な認証基盤では6〜12カ月以上となる可能性があります。対象アプリの調査と意思決定が遅れると開発会社の作業が止まるため、アプリ台帳と担当者を早期に揃えます。

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

MFAは必要です。SSOはログイン回数を減らし、認証をIdPへ集約する仕組みですが、IdPのパスワードだけで認証すると、その情報が奪われたときに複数サービスへ不正アクセスされるリスクがあります。MFA、条件付きアクセス、端末や場所に応じた制御、異常ログ監視、緊急アカウントの管理を組み合わせ、重要アプリにはより強い認証を適用します。

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

可能な場合がありますが、フォーム認証の代理入力、リバースプロキシ、アクセスゲートウェイなどの方式を検討することになります。標準プロトコルのSSOよりも、パスワード保管、画面変更への追随、障害時の切り分け、追加ライセンスが必要になりやすいため、短期的な代替策として位置付けます。中長期では、アプリ側をOIDCなどへ改修する費用と、現行方式を維持する5年TCOを比較して、移行計画を決めます。

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

同じ費用になるとは限りません。顧客向けCIAMでは、月間アクティブユーザー、会員登録・退会、パスワードリセット、同意履歴、ソーシャルログインや外部IdP、会員属性、問い合わせ対応、高可用性などが加わります。たとえばOktaの公式価格ページでは、Customer IdentityのEnterpriseベース製品は月額470,000円からと表示され、アドオンは利用量などで変わると説明されています(出典: Okta「プランと価格」、2026年確認)。従業員数ではなく、MAUや認証回数を含めた要件で見積もります。

まとめ

シングルサインオン開発のまとめ

シングルサインオン(SSO)の進め方は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分けると、判断漏れを防ぎやすくなります。最初に従業員向けSSOか顧客向けCIAMかを分け、アプリ台帳、認証方式、利用者、権限、入退社フロー、ログ、障害時の復旧を整理します。そのうえで、SAML・OIDC・SCIMの適合性を確認し、代表的なアプリでPoCを行ってから段階移行します。

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

発注前には、対象アプリと利用者数が確定しているか、Microsoft 365など既存契約に含まれる機能を確認したか、SAML・OIDC・SCIMの方式をアプリごとに整理したか、入社・異動・退職のIDライフサイクルを定義したか、MFAと最小権限を要件に入れたかを確認します。加えて、初期費用とライセンス、連携、改修、移行、保守を分け、5年TCO、切り戻し条件、障害時の連絡先、運用教育まで見積もりに含めます。

まずは現状のIDとアプリを棚卸しします

SSO導入で最初に行うべきことは、製品を決めることではなく、現状のID、アプリ、認証方式、権限、運用フローを棚卸しすることです。自社だけで整理が難しい場合は、既存システムの改修、移行、セキュリティ、稼働後の運用まで対応できる開発会社へ相談し、アプリ台帳と受け入れ条件をもとに複数社から提案を受けます。認証を集約する効果と集中リスクを両方評価し、利用者が安全に使い続けられる認証基盤を段階的に整えます。

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

会社紹介

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

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

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

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

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

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