SSOのシステム開発の発注/外注/依頼/委託方法について

SSOのシステム開発を発注・外注するときは、ログイン画面を一つにするだけでなく、アプリ台帳、認証方式、権限、人事異動・退職時のアカウント処理まで整理してから、適した発注形態と委託先を選ぶことが重要です。

この記事では、SSOのシステムを外注する際の発注形態、RFPと要件整理の進め方、請負・準委任などの契約形態、費用相場、委託先の選定方法、見積書の比較ポイントを順番に解説します。社内向けSSOと顧客向けログイン基盤を分けて考え、導入後に運用できる発注を目指します。

▼全体ガイドの記事
・SSOのシステム開発の完全ガイド

SSOのシステムを発注・外注する前に知っておきたい全体像

SSO（Single Sign-On）は、利用者が一度認証すれば、許可された複数の業務システムやSaaSへ再ログインなしでアクセスできる仕組みです。利用者を認証するIdPと、接続先のSPをSAML 2.0やOpenID Connect（OIDC）などで連携します。発注時は「SSOを入れたい」という要望を、そのまま開発会社へ渡すのではなく、対象範囲と運用上の成果に置き換える必要があります。

SSOの発注対象には、IdPの初期設定やSaaSとの接続だけでなく、利用者の登録、グループ・ロールの付与、入社・異動・退職時の変更、ログの確認、証明書の更新、障害時の復旧が含まれます。Microsoftの説明でも、Entra IDのSSOはクラウド、SaaS、オンプレミスのアプリへのアクセスを同じ資格情報で管理し、グループや役割に応じて権限を追加・取り消す仕組みとされています（出典: Microsoft「Microsoft Entra シングルサインオン」）。この範囲をRFPに書かないと、納品後に「退職者の停止は誰が行うのか」「権限棚卸しは別料金なのか」といった問題が発生します。

棚卸しでは、Microsoft 365、Google Workspace、勤怠、会計、ワークフロー、営業管理、開発管理などのアプリ名、利用部門、利用者数、管理者、認証方式、契約更新日を一覧にします。あわせて、派遣社員や業務委託先、取引先など社外ユーザーを含めるか、顧客向けログインを同じ基盤で扱うかを分けて記録します。検索者が迷いやすいのは、製品の機能不足よりも「どのIDが誰の権限を持っているか分からない」状態です。アプリ台帳と権限マトリクスが発注の出発点になります。

SaaSであればSAML 2.0やOIDCに対応している場合が多い一方、古いWebシステムやオンプレミスの業務アプリには、そのまま接続できないことがあります。その場合は、リバースプロキシ、エージェント、フォームベース認証などを候補にし、対象アプリの改修が必要かを調べます。認証方式を無理に統一するのではなく、例外をどの範囲で許容し、例外アプリのMFAやログをどう担保するかまで決めることが安全な発注につながります。

SSOのシステム発注形態はどれを選ぶべきですか？

最初に検討しやすいのは、実績のあるIDaaSを採用し、導入支援会社へ設定・移行・運用設計を外注する形態です。対象アプリが標準コネクタで接続できるなら短期間で始めやすく、複雑な環境では認証製品やSIerを組み合わせます。SSOのコアとなる認証処理をゼロから開発するスクラッチ方式は、独自性が本当に必要な場合に限定することが基本です。

利用者が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、段階移行の順で進めます。最初から全社の全アプリを一度に切り替えると、認証失敗や権限不備が業務停止に直結するため、対象を分けて検証します。

アプリ台帳には、アプリ名、提供会社、利用部門、利用者数、管理者、現在のログイン方式、SAML・OIDC対応状況、アカウント発行・停止方法、個人情報の有無を記録します。認証方式が不明なアプリは「未確認」として残し、委託先に確認させる項目にします。さらに、人事マスタからどの属性をIdPへ渡すか、グループと各システムのロールをどう対応させるかを権限マトリクスにします。これがないまま相見積もりを取ると、会社ごとに前提条件が異なり、価格比較ができません。

RFPには、対象アプリと利用者数だけでなく、認証プロトコル、MFA、パスキー・FIDO2、端末証明書、条件付きアクセス、SCIM、人事システム連携、ログの保管期間、管理者の分離、可用性、データ保存場所、サポート時間を記載します。特に「退職処理は何分以内に反映させるか」「証明書の期限を誰が何日前に確認するか」「IdP障害時にどの管理者がどの手順で復旧するか」は、数値または手順で回答を求めます。個人情報を扱う場合は、アクセス制御、アクセス者の識別・認証、不正アクセス防止などの対策も確認します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

候補製品を決めたら、情シスと一部部門、10～20個程度の代表アプリを使ってPoCを行います。ログインできるかだけでなく、異動によるグループ変更、退職者の即時停止、認証失敗、過剰権限、証明書期限切れ、IdP停止、ネットワーク断、ヘルプデスクへの問い合わせまで再現します。古いオンプレミスアプリを1つ含めると、SAML非対応を後工程で発見するリスクを下げられます。PoCの合否条件と、失敗した場合の切り戻し方法を契約前に合意しておくことが大切です。

PoCで問題がなければ、全社一斉ではなく、部門やアプリ群ごとに移行します。利用者へは新しいログイン方法、MFAの登録、スマートフォン紛失時の連絡先、パスワードリセット、問い合わせ先を案内します。管理者向けには、アカウント停止、グループ変更、ログ確認、証明書更新、緊急用アカウントの利用手順を教育します。納品物に操作マニュアルと運用手順書を含め、引き継ぎ完了を受入条件にすることがポイントです。

SSO外注の契約形態と責任分界はどう決めますか？

SSO案件では、要件が固まっていない調査・企画と、仕様が確定した設定・開発を同じ契約にまとめないことが重要です。契約形態によって、成果物の完成責任、作業時間の精算、仕様変更の扱い、障害対応の範囲が変わります。ライセンス契約、導入プロジェクト契約、保守運用契約を分けて整理すると、費用と責任が見えやすくなります。

請負契約を採用するなら、アプリ接続設定、属性マッピング、グループ設計、テスト仕様書、運用手順書などの成果物を具体化します。「SSOを導入する」だけでは受入基準にならないため、対象アプリごとのログイン成功、MFA適用、退職者停止、権限反映、ログ出力、切り戻しを検収項目にします。対象アプリが途中で増える可能性がある場合は、追加作業の単価や変更管理の手順も契約書に記載します。

アプリ台帳の作成、現状調査、製品比較、RFP作成、PoCの伴走、社内調整など、作業内容が変化しやすいフェーズは準委任契約と相性があります。作業時間で精算する場合でも、担当者、稼働時間の上限、定例会議、報告書、課題管理、成果の確認方法を定めます。準委任だから成果に責任がないと考えるのではなく、プロジェクトの節目ごとに確認可能なアウトプットを置くことが大切です。

見積書では、IDaaSや認証製品のライセンス、初期設定、アプリごとの接続、データ移行、テスト、教育、運用保守を別行にします。契約更新時の価格改定、最低契約ID数、利用者数の増減、未使用IDの扱い、時間外サポート、証明書更新、障害時の復旧支援も確認します。特に「導入後のアプリ追加は1接続いくらか」「人事連携の仕様変更は保守内か」を聞くことで、安い初期見積もりだけでは分からない将来費用を把握できます。

SSOのシステム発注費用・料金相場はいくらですか？

SSOに一律の公的な開発相場はないため、以下は公開ライセンス価格と業務システム全般の相場をもとに整理した推定レンジです。利用者数、対象アプリ数、SAML非対応システムの有無、AD・人事システム連携、MFA、ログ、冗長化、運用支援の範囲で大きく変わります。ライセンス料金と発注先への導入費を分け、初年度だけでなく3～5年の総額で判断します。

利用者30～300人、対象アプリ5～20個、標準コネクタ中心の設定型導入であれば、初期費用は0～60万円程度、準備から本番まで2週間～2か月程度が一つの目安です。月額ライセンスは1IDあたり100～800円程度のレンジで考えます。たとえばIIJ IDサービスは、公式ページで初期費用0円、SSO連携が105円（税抜）/1ID・月、SSO連携と多要素認証の組み合わせが210円（税抜）/1ID・月と公開しています（出典: IIJ「IIJ IDサービス」）。これはライセンスの公開価格であり、社内の棚卸し、設定、教育、運用設計の外注費は別に見積もる必要があります。

利用者300～3,000人、対象アプリ20～100個、AD・人事システム連携、SCIM、権限設計、監査ログ、オンプレミス接続、段階移行を含む場合は、初期300万～1,500万円程度、期間3～9か月程度が推定レンジです。費用の内訳は、要件定義、現状棚卸し、製品設計、アプリ接続、データクレンジング、テスト、教育、移行管理に分けて提示してもらいます。いずれかのアプリで個別改修や代理認証が必要になると、接続単価とテスト工数が増えやすいため、RFP段階で例外アプリを明示します。

複数子会社、海外拠点、数千～数十万人、顧客向けCIAM、古い独自認証、24時間運用、冗長化、SOC・SIEM連携、厳格な監査を伴う場合は、初期1,000万～5,000万円超、期間6～18か月以上の規模になる可能性があります。日立グループのOkta導入事例では、約48万人のアイデンティティと約1,500のアプリを対象にした大規模な統合が紹介されています。一方、日本精工のMicrosoft事例では、約1万8,000人の社員向け統合と、顧客向けサービスのID課題を分けて扱っています（出典: Okta「Hitachi Group」およびMicrosoft「日本精工」導入事例）。事例の金額を自社へ転用せず、規模・アプリ数・要件の違いを確認することが重要です。

公開価格の例では、Microsoft Entra ID P1が899円（税抜）/ユーザー・月相当、年払いで示されていますが、Microsoft 365 E3やBusiness Premiumなどに含まれる場合があります（出典: Microsoft「Entraのプランと価格」）。HENNGE One Identity Editionは300円/月から、IdPは300円/月、IdP Proは500円/月と掲載されています（出典: HENNGE「価格とプラン」）。Okta Workforce IdentityはStarterが月6ドル/ユーザー、Essentialsが月17ドル/ユーザーからで、年払い・最低年間契約額の条件があります（出典: Okta「Plans and Pricing」）。為替、契約期間、最低ID数、税、販売代理店、追加機能で変動するため、記事掲載時点の公開価格を固定的な見積もりとみなさず、発注時に再確認します。

保守運用は、ライセンス管理だけでなく、アカウント連携の監視、証明書更新、アプリ追加、権限棚卸し、ログ確認、問い合わせ、障害対応を含めて見積もります。業務システム全般の目安として、保守運用費を初期開発費の年15～25％程度とする整理もありますが、これはSSO固有の統計ではありません。自社に適用する際は、対応時間、対象範囲、月次報告、緊急対応、変更作業の単価を確認することが重要です。

SSOの委託先選定と見積比較のポイントは何ですか？

委託先は、知名度やライセンス価格だけで決めず、要件定義力、対象アプリとの連携実績、セキュリティと運用体制、費用の透明性、サポートを総合的に比較します。候補3社へ同じアプリ台帳、利用者数、MFA要件、運用範囲を渡し、同じ前提で提案と見積もりを受けると、価格だけでなく責任範囲の差が見えるようになります。

製品ベンダーはIDaaSや認証製品の機能、ライセンス、製品サポートを提供します。SIerや導入支援会社は、現状調査、要件定義、アプリ接続、データ移行、テスト、教育、運用設計を担うことが多いです。両者を一社にまとめる場合でも、製品の障害と設定ミスのどちらを誰が調査するか、サポートの受付窓口はどこかを明確にします。NTT DATA、SCSK、富士通などの大規模導入支援と、IIJやHENNGEなどの国内IDaaSを同じ軸だけで比べず、必要な役割に分解して選ぶことがポイントです。

提案依頼では、SAML・OIDC・LDAP・AD・Entra IDの連携実績、SAML非対応アプリへの対応方式、SCIMによるプロビジョニング、MFAとパスキー、条件付きアクセス、管理者の分離、ログの保存・検索、証明書更新、冗長化、バックアップIdP、緊急用管理者アカウントについて質問します。さらに、担当者の資格や経験だけでなく、同じ担当者が設計から運用引き継ぎまで関与するか、再委託先がいるか、障害時のエスカレーション時間を確認します。回答が「対応可能」だけで、方法・前提・追加費用が書かれていない提案は、比較時に減点します。

見積比較では、要件定義、アプリ棚卸し、IdP設計、1アプリごとの接続設定、ユーザー移行、MFA設定、SCIM設定、PoC、総合テスト、教育、移行、保守を項目別にします。「一式」と書かれた費用は、何人日・何アプリ・何回のテストを含むのかを確認します。対象アプリ数や利用者数を増やしたときの追加単価、対象外作業、出張費、時間外費用、ライセンス更新費、5年間の保守費も同じシートで比較します。

候補を採点する場合は、要件定義力30点、連携実績20点、セキュリティ・運用20点、費用透明性15点、サポート15点など、社内で重みを決めます。大規模案件では、既存アプリや子会社を含めた移行管理、障害時の復旧、長期運用が価格差以上に重要になることがあります。逆にSaaS中心の小規模導入では、標準連携の範囲、設定の分かりやすさ、最低契約ID数、国内サポートを重視します。評価軸を先に決めることで、最安値だけを理由に発注して後から追加費用が増える失敗を防げます。

SSO導入後の運用と発注時のリスク対策

SSOは導入して終わりではなく、IDの増減、権限変更、アプリ追加、認証ポリシーの見直しを継続する基盤です。発注時に運用担当者と手順を決めておかないと、導入直後は使えても、異動・退職・証明書更新の段階で手作業が戻ります。運用設計と復旧訓練まで含めて成果と考えます。

人事マスタからIdPへ連携する属性、グループの付与条件、各アプリのロール、退職時の停止タイミングを決めます。退職者のアカウント停止は、IdPだけでなく各SPや特権アカウント、APIキー、共有アカウントまで確認します。月次または四半期の権限棚卸しを実施し、上長やシステム所有者が不要な権限を承認しない仕組みを作ります。SCIMが使えないアプリについては、手動処理の期限と完了確認者を運用手順に残します。

SSOへ集約すると利便性が高まる一方、IdPの障害や設定ミスが複数アプリへ波及する可能性があります。緊急用のブレークグラス管理者アカウントを通常のSSO経路と分離し、保管場所、利用承認、監視、利用後のパスワード変更を決めます。バックアップIdPの要否、既存認証への一時的な切り戻し、ベンダーへの連絡方法、復旧目標時間もRFPと保守契約に記載します。PoCでは、正常ログインだけでなく、IdP停止時に業務を継続・復旧できるかを確認します。

2025～2026年のSSO選定では、パスワードを一つにまとめるだけでなく、MFA、パスキー・FIDO2、条件付きアクセス、ライフサイクル管理、SaaS利用状況の可視化が比較対象になります。将来機能をすべて初期導入する必要はありませんが、段階的に追加できる製品か、追加費用や契約変更がどうなるかを確認します。GMOトラスト・ログインなどもID管理や監査支援の方向へ機能を広げており、認証だけでなく権限レビューやシャドーIT対策まで視野に入れておくと、再調達の負担を抑えやすくなります。

SSOのシステム発注・外注に関するよくある質問

SSOの発注では、利用者数と料金だけでなく、既存環境、契約、顧客向け認証、運用体制に関する質問が多く寄せられます。ここでは、発注前に確認しておきたい代表的な疑問へ回答します。

明確な人数の境界はありません。数十人規模でも、複数SaaSのパスワード管理や退職者アカウントの残存が課題であれば、IDaaSの小規模導入にメリットがあります。逆に人数が多くても、対象アプリが少なく既存ライセンスにSSO機能が含まれる場合は、まず自社で現状を整理してから設定支援だけを外注する方法もあります。人数、アプリ数、認証リスク、情シスの運用負荷を合わせて判断します。

可能性はありますが、アプリの構成やベンダーの制約を調査する必要があります。リバースプロキシ、エージェント、フォームベース認証などを使える場合がありますが、パスワードを代理入力する方式では、MFA、ログ、パスワード変更、障害時の動作を個別に検証します。改修でSAMLやOIDCに対応できるなら、長期的な保守性まで比較して方式を決めます。

同じ会社へ相談することはできますが、要件と料金モデルは分けて整理します。社内向けSSOは従業員のIDライフサイクル、端末、MFA、業務アプリの権限が中心です。顧客向けCIAMは、会員登録、本人確認、同意管理、サポート、利用規模、外部公開時の可用性や不正利用対策が中心になります。RFPで利用者区分、データの所有者、認証フロー、目標稼働率を分けて書くと、適切な製品と契約を選びやすくなります。

短期の開発費だけで安いとは判断できません。認証、MFA、トークン、暗号鍵、監査ログ、脆弱性対応、仕様変更、24時間運用まで自社の責任になるため、長期の保守費とセキュリティ対応費が膨らむ可能性があります。独自要件がある場合でも、認証の中核は実績あるIDaaSや認証製品を採用し、業務固有の権限やデータ連携だけを開発する構成を優先します。

まとめ：SSOのシステム発注は要件と運用を分けて比較します

SSOの発注では、対象範囲と運用責任を先に明確にし、価格だけでなく、例外アプリへの対応や障害時の復旧まで比較することが成功の条件です。最後に、発注前に確認するポイントを整理します。

アプリ名、利用者数、認証方式、SAML・OIDC対応状況、権限、入社・異動・退職処理を台帳化し、機能要件と非機能要件をRFPへ落とし込みます。候補3社へ同じ資料を渡し、ライセンス、設定、移行、教育、保守を分けた見積もりを依頼します。受入条件には、正常ログインだけでなく、MFA、退職者停止、権限変更、障害時の切り戻しを含めます。

IDaaSの設定だけを終点にせず、PoC、部門ごとの段階移行、利用者教育、管理者教育、権限棚卸し、証明書更新、IdP障害時の復旧訓練までを計画します。製品ベンダーとSIerの役割、請負・準委任の範囲、追加作業の単価、保守窓口を契約書に残すことで、導入後の責任の空白を防ぎます。

SSOのシステムを発注・外注するときは、まずアプリ、利用者、認証方式、権限、入社・異動・退職処理を棚卸しします。そのうえで、IDaaSの設定支援、認証製品とSIerの導入、独自開発のどれが自社に合うかを判断し、RFPで機能要件・非機能要件・運用範囲をそろえて候補3社へ依頼します。SSO固有の一律相場はないため、ライセンス、初期導入、アプリ接続、移行、教育、保守を分けた推定レンジで比較することが大切です。

安価な初期設定だけを選ぶのではなく、退職者の停止テスト、SAML非対応アプリの例外処理、IdP障害時の復旧、MFA・パスキー、権限棚卸しまで契約と運用手順に落とし込みます。発注前に自社で整理しきれない場合は、現状調査とRFP作成だけを先に外注する方法もあります。段階的にPoCと移行を進め、利用者と管理者が継続して安全に使える認証基盤を構築します。

▼全体ガイドの記事
・SSOのシステム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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