SSOのシステム発注は、アプリと権限の洗い出し、要件と責任範囲の整理、PoCと段階移行の順に進めます。この順で進めると、運用まで見通した認証基盤につながります。
発注形態、進め方、契約と費用、委託先の選び方、導入後の運用の順に説明します。全体像は、SSOのシステム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・SSOのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SSOのシステムを発注・外注する前に知っておきたい全体像
SSO（Single Sign-On）は、利用者が一度認証すれば、許可された複数の業務システムやSaaSへ再ログインなしでアクセスできる仕組みです。
利用者を認証するIdPと、接続先のSPを、SAML 2.0やOpenID Connect（OIDC）などの方式でつなぎます。
「SSOを入れたい」という要望のままでは、対象範囲が定まりません。そのため、発注時にはこの要望を、対象範囲と運用上の成果に置き換えて伝えます。
発注対象は認証基盤だけでなくIDライフサイクル
発注範囲には、IdP設定やSaaS接続に加えて、利用者登録、権限付与、入社・異動・退職時の変更も含めます。
- 日々の管理：ログ確認、証明書更新、障害時の復旧
- 人事異動への対応：グループやロールの付与・変更
- 退職時の処理：アカウント停止と接続先の権限削除
Microsoftの説明では、Entra IDのSSOはクラウド、SaaS、オンプレミスのアプリへのアクセスを管理します。また、グループや役割に応じて権限を追加・取り消します（出典: Microsoft「Microsoft Entra シングルサインオン」）。
RFPに範囲を書いていないと、退職者の停止や権限の洗い出しが別料金になる場合があります。
発注前のアプリ・利用者・権限の洗い出し
発注前に、アプリの利用状況と権限の管理状況を洗い出します。
- 対象アプリ：Microsoft 365、Google Workspace、勤怠、会計、ワークフロー、営業管理、開発管理など
- アプリ情報：アプリ名、利用部門、利用者数、管理者、認証方式、契約更新日
- 社外ユーザー：派遣社員、業務委託先、取引先などを含めるか
- 顧客向けログイン：同じ基盤で扱うか、分けて扱うか
製品の機能よりも、どのIDが誰の権限を持つか分からない状態のほうが課題になりやすいものです。そのため、アプリ台帳と権限マトリクスを発注の出発点にします。
SAML非対応システムと例外処理の確認
SaaSはSAML 2.0やOIDCに対応する場合が多い一方、古いWebシステムやオンプレミスアプリは接続できないことがあります。
- 接続方式：リバースプロキシ、エージェント、フォームベース認証
- 事前確認：対象アプリの改修要否と、例外として扱う範囲
- 安全性：例外アプリのMFAとログをどう担保するか
認証方式を無理に統一せず、どの範囲の例外を許容するかを決めます。そのうえで、例外アプリのMFAやログの担保方法まで決めると、安全な発注につながります。
SSOのシステム発注形態の選び方
まず検討しやすいのは、実績のあるIDaaSを採用し、設定・移行・運用設計を導入支援会社に外注する形態です。
対象アプリが標準コネクタで接続できるなら、短期間で始めやすくなります。一方で、複雑な環境では認証製品やSIerを組み合わせます。
SSOのコア認証をゼロから開発するスクラッチ方式は、独自性が本当に必要な場合に限って選びます。
IDaaSの導入支援を外注する方法
利用者30～300人、対象5～20個のSaaS、標準的なSAML・OIDC連携、基本的なMFAという条件なら、IDaaSの設定支援を外注する方法が現実的です。
自社で製品を契約し、現状調査、設定、テスト、操作教育だけを外注することもできます。ライセンス提供者と支援会社を分ける場合は、障害時の窓口、設定変更の承認者、契約更新の責任を、あらかじめ明確にしておきます。
認証製品・パッケージを導入する方法
Active DirectoryやLDAP、オンプレミスのWebシステムがある場合や、複数の子会社を含む場合は、認証製品とSIerの導入サービスを組み合わせる方法があります。
この方法では、SAML・OIDCに加えて、エージェント、リバースプロキシ、SCIM、人事システム連携、監査ログ、権限の洗い出しまで設計しやすい点が特徴です。
製品ライセンスと、設計・設定・移行・保守は別々に見積もられます。そのため、5年間の総保有コストで比べます。
スクラッチ開発は独自要件がある場合に限定
既製品では満たせない要件、たとえば顧客向け会員統合、独自の認証画面、特殊な本人確認がある場合は、アプリ側の機能を独自に開発します。
IdP、トークン発行、暗号鍵、MFA、セッション管理、監査ログまで自社で作ると、脆弱性対応や仕様変更の責任が長く続きます。
そこで、認証基盤はIDaaSや実績ある製品に任せ、独自開発は業務固有の権限、データ連携、画面に絞る構成が考えられます。この構成は、保守性と柔軟性を両立しやすい方法です。
SSOのシステム発注・外注の進め方
SSOの発注では、製品を先に決めて要件を後から合わせるのではなく、現状調査、要件定義、RFP配布、提案比較、PoC、段階移行の順に進めます。
全アプリを一度に切り替えると、認証の失敗や権限の不備がそのまま業務停止につながります。そのため、対象を分けて検証します。
1. 現状調査とアプリ台帳の作成
現状調査では、アプリとIDの状態を台帳と権限マトリクスにまとめます。相見積もりの前提をそろえるために、未確認の項目も明記します。
- アプリ情報：名称、提供会社、部門、利用者数、管理者
- 認証とアカウント：ログイン方式、SAML・OIDC対応、発行・停止方法
- データと権限：個人情報の有無、人事属性、グループとロールの対応
認証方式が分からない場合は「未確認」と記し、委託先に確認してもらいます。前提がそろわなければ、会社ごとの見積もりの価格を比べられません。
2. RFPでの機能要件と非機能要件の伝え分け
RFPでは、機能と運用条件を分けて書き、具体的な要件を伝えます。
- 認証機能：プロトコル、MFA、パスキー・FIDO2、端末証明書、条件付きアクセス
- 連携と管理：SCIM、人事連携、ログ保管期間、管理者の分離
- 非機能要件：可用性、データ保存場所、サポート時間
退職処理の反映時間、証明書期限の確認日数、障害時の復旧手順は、数値か手順で回答してもらいます。
個人情報を扱う場合は、さらにアクセス制御、アクセス者の識別と認証、不正アクセス防止も確認します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。
3. PoCでの正常系と異常系の検証
候補製品を決めたら、情シスと一部の部門で、10～20個程度の代表アプリを使ってPoCを行います。ログイン以外の状態も、あわせて確認します。
- 利用者の変化：異動時のグループ変更、退職者の即時停止
- 認証の異常：失敗、過剰権限、証明書期限切れ
- 障害時の対応：IdP停止、ネットワーク断、問い合わせ
古いオンプレミスアプリも1つ含めておくと、SAML非対応が後から見つかるリスクを下げられます。また、合否条件と失敗時の切り戻し方法は、契約前に合意しておきます。
4. 段階移行と利用者教育
PoCに問題がなければ、全社一斉ではなく、部門やアプリ群ごとに移行します。利用者には、新しいログイン方法とMFA登録に加えて、スマートフォン紛失時の連絡先、パスワードリセット、問い合わせ先も案内します。
管理者には、アカウント停止とグループ変更の手順を中心に教育します。そのほか、ログ確認や証明書更新、緊急用アカウントの手順も扱います。
操作マニュアルと運用手順書を納品物に含め、引き継ぎ完了を受入条件にします。
SSO外注の契約形態と責任分界
要件が固まっていない調査・企画と、仕様が確定した設定・開発は、同じ契約にまとめないのが基本です。
契約形態によって、成果物の完成責任、作業時間の精算、仕様変更、障害対応の範囲が変わります。
ライセンス、導入プロジェクト、保守運用の契約を分けると、費用と責任の所在が見えてきます。
請負契約の成果物と受入条件
請負では、成果物を具体的に決めておきます。アプリ接続設定や属性マッピング、グループ設計に加えて、テスト仕様書と運用手順書も対象になります。
- 検収項目：アプリごとのログイン成功、MFA適用、退職者停止
- 権限と記録：権限反映、ログ出力、切り戻し
- 変更管理：追加アプリの単価と手順
「SSOを導入する」とだけ書いても、受入基準にはなりません。
途中で対象アプリが増える可能性もあるため、契約範囲はその前提で設定します。
準委任契約が向く調査・伴走・運用支援
作業内容が変わりやすい段階では、準委任契約が合います。たとえば、アプリ台帳の作成や製品比較、RFP作成がこの段階に当たります。PoCの伴走や社内調整も、準委任契約と合います。
時間で精算する場合も、担当者と稼働時間の上限を決めます。定例会議と報告書で進捗を共有し、課題を管理します。成果の確認方法もあわせて定めます。
準委任であっても、節目ごとに確認できるアウトプットを置き、成果への責任を見える形にします。
ライセンス・導入・保守の費用の契約上の区分
見積書では、ライセンスと導入作業、保守を別の行に分けます。導入作業の中では、初期設定やアプリ接続、データ移行、テスト、教育を項目ごとに書きます。
契約更新時の価格改定や最低契約ID数、利用者数の増減を確認します。あわせて、未使用IDや時間外サポート、証明書更新、障害時の復旧支援も確認します。
導入後のアプリ追加の単価や、人事連携の仕様変更が保守の範囲に入るかも聞いておくと、将来の費用を把握できます。
SSOのシステム発注費用・料金相場
SSOには、公的に定められた一律の開発相場はありません。そのため、ここでは公開ライセンス価格と業務システム全般の相場をもとにした推定レンジを示します。
費用は、利用者数やアプリ数、SAML非対応システムの有無で変わります。加えて、AD・人事連携やMFA、ログ、冗長化、運用支援の範囲によっても変わります。ライセンスと導入費は分けて、3～5年の総額で判断します。
小規模なIDaaS導入の初期費用の目安（0～60万円程度）
標準コネクタ中心の設定型導入であれば、初期費用と期間は、おおよその目安として見られます。
- 初期費用と期間：利用者30～300人、対象5～20アプリなら、0～60万円程度、2週間～2か月程度
- 月額ライセンス：1IDあたり100～800円程度
IIJ IDサービスは初期費用0円、SSO連携105円（税抜）/1ID・月、SSOと多要素認証の組み合わせ210円（税抜）/1ID・月と公開しています（出典: IIJ「IIJ IDサービス」）。
これはライセンス価格の例にすぎません。社内での洗い出しや、設定、教育、運用設計の外注費は、別に見積もります。
中規模の認証基盤構築の初期費用（300万～1,500万円程度）
利用者300～3,000人、対象アプリ20～100個が目安です。AD・人事連携やSCIM、権限設計を含む場合は、初期費用が300万～1,500万円程度と推定されます。監査ログ、オンプレミス接続、段階移行を含む場合も、この推定の対象です。
期間は3～9か月程度です。見積もりでは、要件定義、棚卸し、製品設計、アプリ接続の工程を分けて示してもらいます。あわせて、データ整備、テスト、教育、移行管理の工程も、別々に示してもらいます。
個別改修や代理認証が必要なアプリがあると、接続単価とテスト工数が増えやすくなります。そのため、RFPで例外アプリを明示します。
大規模・複雑な刷新の初期費用（1,000万～5,000万円超）
大規模・複雑な案件では、初期費用が1,000万～5,000万円超になる可能性があります。
- 対象規模：複数子会社、海外拠点、数千～数十万人、顧客向けCIAM、古い独自認証
- 運用・監査：24時間運用、冗長化、SOC・SIEM連携、厳格な監査
期間は6～18か月以上になる場合があります。
日立グループのOkta導入事例は、約48万人のアイデンティティと約1,500のアプリを対象にした統合を紹介しています。
日本精工のMicrosoft事例では、約1万8,000人の社員向け統合と、顧客向けサービスのID課題を分けて扱っています（出典：Okta「Hitachi Group」およびMicrosoft「日本精工」導入事例）。
事例の金額を自社にそのまま転用せず、規模やアプリ数、要件の違いを確かめます。
月額ライセンスと保守運用費を含めた比較
公開価格は提供元やプランで異なるため、サービスごとの価格と契約条件を照らして比べます。
- Microsoft Entra ID P1：899円（税抜）/ユーザー・月相当（年払い）
- HENNGE One Identity Edition：300円/月から。IdPは300円/月、IdP Proは500円/月
- Okta Workforce Identity：Starterは月6ドル/ユーザー、Essentialsは月17ドル/ユーザーから
Microsoft Entra ID P1はMicrosoft 365 E3やBusiness Premiumに含まれる場合があります（出典: Microsoft「Entraのプランと価格」）。
（出典: HENNGE「価格とプラン」）
Okta Workforce Identityの価格には、年払いと最低年間契約額の条件があります（出典: Okta「Plans and Pricing」）。
為替、契約期間、最低ID数、税、販売代理店、追加機能によって、価格は変わります。そのため、掲載時点の価格を確定した見積もりとはみなさず、発注時に確かめ直します。
保守運用では、ライセンス管理に加えて、アカウント連携の監視、証明書更新、アプリ追加を含めて見積もります。
権限の洗い出しやログ確認、問い合わせ、障害対応も、対象に含めます。
業務システム全般では、保守運用費を初期開発費の年15～25％程度とする整理もあります。ただし、これはSSO固有の統計ではありません。そのため、対応時間、範囲、月次報告、緊急対応、変更単価を個別に確認します。
SSOの委託先選定と見積比較のポイント
委託先は、要件定義力、連携実績、セキュリティと運用体制、費用の透明性、サポートを比べて選びます。知名度やライセンス価格は、その判断材料のひとつです。
候補3社には、同じアプリ台帳、利用者数、MFA要件、運用範囲を渡します。前提をそろえた提案と見積もりであれば、価格と責任範囲の違いが見えてきます。
製品ベンダーとSIerの役割の切り分け
製品ベンダーはIDaaSや認証製品の機能、ライセンス、製品サポートを提供します。一方で、SIerや導入支援会社は、導入作業や運用設計を担うことが多いです。
- 製品側の役割：機能、ライセンス、製品サポート
- 導入側の役割：調査、要件定義、接続、移行、テスト、教育
- 共同で確認：障害原因の調査担当と問い合わせ窓口
NTT DATA、SCSK、富士通などの大規模導入支援と、IIJやHENNGEなどの国内IDaaSは、必要な役割に分けて比べます。
提案段階で確認する技術と運用の質問
提案を依頼する段階では、連携方式と運用方法を質問し、その方法・前提・追加費用まで確認します。
- 連携技術：SAML・OIDC・LDAP・AD・Entra ID、SCIM
- 認証と記録：MFA、パスキー、アクセス制御、ログ検索
- 継続運用：証明書更新、冗長化、バックアップIdP、緊急用アカウント
各方式の連携実績と、SAML非対応アプリへの対応方式を確認します。加えて、SCIMによるプロビジョニングや条件付きアクセス、管理者の分離、ログの保存方法も聞いておきます。
担当者の資格や経験を聞き、設計から運用引き継ぎまでどこに関わるかも確かめます。また、再委託先と障害時のエスカレーション時間も確認します。
「対応可能」とだけ書かれていて、方法・前提・追加費用が示されていない提案は、減点の対象にします。
見積書の作業範囲・単価・前提条件の横並び
見積比較では、要件定義、棚卸し、IdP設計、アプリ接続、ユーザー移行を、作業ごとに分けて並べます。さらに、MFA・SCIM設定、PoC、テストは、別の行として示してもらいます。教育、移行、保守も、それぞれ別の行に書いてもらいます。
「一式」と書かれている場合は、何人日か、何アプリか、何回のテストを含むかを確認します。アプリ数や利用者数を増やしたときの追加単価も、あわせて比べます。
対象外の作業や、出張費、時間外費用、ライセンス更新費、5年間の保守費は、同じシートにまとめて比べます。
価格以外の評価軸と発注先の選び方
候補を採点する場合は、社内で評価項目の重みを先に決めておきます。評価軸をそろえておくと、価格だけで選んでしまう失敗を防ぎやすくなります。
- 要件定義力：30点
- 連携実績：20点
- セキュリティ・運用：20点
- 費用透明性：15点
- サポート：15点
大規模案件では、既存アプリや子会社を含めた移行管理、障害時の復旧、長期運用が、価格差以上に重要な場合があります。
SaaS中心の小規模導入では、標準連携の範囲や設定の分かりやすさ、最低契約ID数、国内サポートを重視します。
SSO導入後の運用と発注時のリスク対策
SSOは導入後もIDの増減、権限変更、アプリ追加、認証ポリシーの見直しが続く基盤です。
運用担当と手順を決めておかないと、異動や退職、証明書更新のたびに手作業が戻ってしまう場合があります。そのため、運用設計と復旧訓練まで成果に含めます。
運用の中心にある入社・異動・退職の処理
人事マスタからIdPへ渡す属性を決め、グループの付与条件と各アプリのロール、退職時の停止時期も決めておきます。
退職者は、IdPだけでなく、各SPや特権・APIキー・共有アカウントについても確認します。権限は月次または四半期に洗い出し、上長や所有者が不要な権限を承認しない仕組みを作ります。
SCIMが使えないアプリは、手動で行う処理の期限と完了の確認者を、運用手順に残しておきます。
IdP障害と管理者ロックアウトへの備え
SSOへ集約すると、IdP障害や設定ミスが複数のアプリに広がるおそれがあります。そこで、緊急用のブレークグラス管理者アカウントは、通常のSSO経路から分けて用意します。
緊急用アカウントは、保管場所と利用の承認方法、監視、利用後のパスワード変更を決めておきます。あわせて、バックアップIdPや既存認証への切り戻し、ベンダーへの連絡、復旧目標時間を、RFPと保守契約に記します。
PoCでは、正常なログインだけでなく、IdP停止時に業務を続けられるか、復旧できるかも確認します。
MFA・パスキー・IDガバナンスを含む将来要件
2025～2026年の選定では、MFA、パスキー・FIDO2、条件付きアクセス、ライフサイクル管理、SaaS利用状況の可視化が、比較の対象になります。
将来機能を最初から導入する必要はありません。ただし、段階的に追加できるかどうか、その追加費用、契約変更の要否は確認しておきます。
GMOトラスト・ログインなども、ID管理や監査支援へ機能を広げています。認証に加えて、権限レビューやシャドーIT対策も視野に入れておくと、再調達の負担を抑えやすくなります。
SSOのシステム発注・外注に関するよくある質問
SSOの発注では、利用者数と料金だけでなく、既存環境、契約、顧客向け認証、運用体制も確認します。
発注前によく出る疑問に、順に答えます。
SSOは何人規模から外注するメリットがありますか？
明確な人数の境界はありません。数十人規模でも、複数SaaSのパスワード管理や退職者アカウントの残存が課題なら、IDaaSの小規模導入に利点があります。
人数が多くても、対象アプリが少なく既存ライセンスにSSO機能が含まれる場合は、自社で現状を整理し、設定支援だけを外注できます。判断では、人数、アプリ数、認証リスク、情シスの負荷を合わせて見ます。
SAML非対応の古いシステムもSSO化できますか？
可能性はありますが、アプリの構成やベンダーの制約を調べる必要があります。たとえば、リバースプロキシやエージェント、フォームベース認証を使える場合があります。
パスワードを代理で入力する方式では、MFA、ログ、パスワード変更、障害時の動作を個別に検証します。一方で、改修によってSAMLやOIDCに対応できる場合は、長期の保守性も比べます。
社内向けSSOと顧客向けログインを同じ発注で扱えますか？
同じ会社に相談することはできますが、要件と料金モデルは分けて整理します。社内向けSSOでは、従業員IDのライフサイクル、端末、MFA、業務アプリの権限が中心になります。
顧客向けCIAMでは、会員登録、本人確認、同意管理、サポートが中心です。利用規模や、公開時の可用性、不正利用対策も、中心的な論点になります。
RFPで利用者の区分、データ所有者、認証フロー、目標稼働率を分けて書くと、製品と契約を選びやすくなります。
SSOをスクラッチ開発したほうが安くなりますか？
短期の開発費だけでは判断できません。認証、MFA、トークン、暗号鍵、監査ログは、自社の責任になります。加えて、脆弱性対応、仕様変更、24時間運用も、自社で担うことになります。
そのため、長期の保守・セキュリティ費が膨らむ可能性があります。独自要件があっても、認証の中核はIDaaSや認証製品を使い、業務固有の権限や連携を開発する構成を優先します。
まとめ：要件と運用を分けて比べるSSOのシステム発注
SSOの発注では、対象範囲と運用の責任を先に明確にします。
価格だけでなく、例外アプリへの対応や障害時の復旧まで比べることが、成功の条件になります。
発注前に確認する資料と項目を整理します。
発注前のアプリ台帳・RFP・受入条件の整理
アプリ台帳には、アプリ名、利用者数、認証方式を書きます。SAML・OIDC対応、権限、入社・異動・退職の処理も、台帳に加えます。機能・非機能要件はRFPに書きます。
候補3社へ同じ資料を渡し、ライセンス、設定、移行、教育、保守を分けて見積もります。受入条件にはMFA、退職者停止、権限変更、障害時の切り戻しも含めます。
段階移行と運用引き継ぎを含む外注範囲
IDaaSの設定を終点にせず、導入後の運用まで計画に含めます。
契約内容が明確であれば、導入後に責任の空白が生じるのを防げます。
- 移行と教育：PoC、部門ごとの移行、利用者・管理者教育
- 継続運用：権限の洗い出し、証明書更新、IdP障害時の復旧訓練
- 役割と契約：製品ベンダーとSIerの役割、請負・準委任の範囲
- 追加費用と窓口：追加作業単価、保守窓口
SSO固有の一律相場はないため、ライセンス、初期導入、アプリ接続、移行、教育、保守を分けて推定レンジを比べます。発注前に整理しきれない場合は、現状調査とRFP作成だけを先に外注する方法もあります。
退職者停止のテスト、SAML非対応アプリの例外処理、IdP障害時の復旧は、契約と手順に落とし込みます。初期設定の安さだけで選ばないよう、ここを確認しておきます。
MFA・パスキーや権限の洗い出しも契約に明記し、PoCと移行は段階的に進めます。
利用者と管理者が、継続して安全に使える認証基盤を構築します。
▼全体ガイドの記事
・SSOのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。