シングルサインオン(SSO)開発の発注/外注/依頼/委託方法について

SSO開発の発注は、まず現状を調べ、次にPoCで実際の難所を確かめ、最後に段階的に移行する順に進めると、安全な認証基盤の導入につながります。

発注形態、RFP、費用、委託先の比べ方は、発注前に押さえたい点です。全体像は、シングルサインオン(SSO)開発の完全ガイドもご覧ください。

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

SSO開発の発注・外注の切り分け

SSO開発は、既製IDaaSの導入、既存業務システムの改修、顧客向け認証基盤の新規構築のどれに当たるかで分けて考えます。SaaSがSAMLやOIDCに対応していれば、作業は設定とテストが中心になります。一方で、古いWebアプリやクライアントサーバー、共有IDが残る場合は、認証方式の変換や利用者データの整理も必要です。

従業員向けWorkforce IAMと顧客向けCIAMの分け方

最初に、ログインを統合する対象者を決めます。

  • Workforce IAM:従業員、派遣社員、委託先向けです。
  • CIAM:会員、顧客、取引先向けです。月間アクティブユーザー、登録・退会、規約同意、外部IdP連携を要件に含みます。

Workforce IAMでは、Microsoft Entra ID、Active Directory、Google Workspaceと連携します。あわせて、人事マスタとの連携も整理します。さらに、入社・異動・退職にともなうIDライフサイクル管理も対象です。

一方で、CIAMではブランドに合わせたログイン画面とピーク時の可用性も確認します。Workforce IAMとCIAMを同じ見積もりで比べると、利用者数の数え方や必要な機能がずれます。たとえば、従業員100人のSaaS連携と会員10万人のサービス認証では、負荷試験、サポート、アカウント回復、個人情報の扱いに必要な工数が異なります。

発注形態の導入支援、準委任、請負の使い分け

発注形態は、作業の不確実性と成果物の明確さで選びます。製品選定、現状調査、アプリの一覧づくり、PoCは、時間単価や月額の準委任契約に向いています。

短期間の導入支援契約も選択肢です。環境を見ながら論点を洗い出す段階に適しています。

対象アプリと認証方式、画面改修まで合意し、テスト項目と切り替え日も決めた構築工程は、請負契約にしやすくなります。その場合は、成果物と検収条件を定めます。

不確実性を残したまま一括発注しないよう、工程を次の順に分けます。

  1. 現状調査と基本設計
  2. PoCと詳細設計
  3. 連携開発と移行
  4. 運用保守

古い認証方式や不明な共有アカウントがある場合は、調査のあとに後続工程の範囲と金額を確定します。発注者と受託者の双方にとって、現実的な進め方です。

ポイント

対象が従業員か顧客か、既存システムの改修を含むかで、見積もりの前提と発注形態が変わります。不確実性が残る部分は、工程を分けて発注します。

SSOを外注する前のRFPと要件の整理

RFPの現状調査で確認するアプリ情報、認証情報、アカウント管理を3枚のカードに整理した図解。
3つの棚卸し項目をそろえると、アプリとIDの現状を見渡せます。

RFPで大切なのは、製品名の指定より、現状の課題、対象範囲、目標、制約、評価方法を伝えることです。各社が同じ前提で提案できるようにするためです。

RFPには、利用者数や対象アプリ数に加え、現行の認証方式、アカウント管理元、業務を止められない時間帯も記載します。

現状調査で洗い出すアプリ、ID、権限、ログ

現状調査では、アプリ情報、認証方式、アカウント管理を一覧にします。

  • アプリ情報:名称、所有部署、利用者数、重要度。
  • 認証情報:方式、SAML・OIDC・SCIM対応、ログアウト方法。
  • アカウント管理:発行者と退職時の停止方法。

SaaSだけでなく、社内ポータルやVPN、オンプレミスWebも対象です。クライアントサーバーやAPIも含めます。さらに、誰がどの権限で何を見られるかまで確認します。

人事マスタと実際のアカウントを照合すると、退職者IDや重複アカウントが見つかることがあります。異動前の権限や共有IDが残っている場合もあります。こうした問題は、SSOの設定とは別に扱う必要があります。

データクレンジングと権限再設計は、別タスクとしてRFPに記載します。また、承認者と完了判定の方法もあらかじめ決めておきます。

数字で定めるセキュリティと運用の要件

SSOはIdPに認証を集中させるため、侵害時には複数のアプリに影響が及びます。そのため、RFPには集中リスクへの対策を記載します。

  • MFA:必須対象とフィッシング耐性を求める範囲。
  • アクセス制御:端末・場所・リスクによる条件付きアクセス、特権分離、緊急用アカウント。
  • 認証情報とログ:証明書・秘密鍵の更新、ログの保管・検索可能期間。

個人情報を扱う場合は、個人データを扱う情報システムの従業者を識別・認証する考え方を、実装・運用に反映します。

この考え方は、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(通則編)」に示されています(出典:個人情報保護委員会)。資料は2026年に確認しています。

法令対応では、認証に加えて、権限の洗い出し、監査ログ、委託先の安全管理も発注要件に含めます。

ポイント

RFPに進む前に、アプリ、認証方式、アカウント管理を一覧にできているかが目安です。一覧にできない部分は、要件と見積もりの前提が足りていません。

SSO開発・導入を外注するときの進め方

SSO開発・導入の流れとして、現状調査、目標設計、PoC、段階移行、運用設計を矢印でつないだ図解。
PoCと移行を区切ることで、工程ごとの成果物や次へ進む条件を置けます。

SSO開発・導入は、現状を調べ、目標を設計し、PoCで確かめ、段階的に移行して、運用を設計する順に進めます。認証方式を決めて設定するのは、その一部にすぎません。この進め方を通じて、安全に使える状態を作ります。

発注時には、工程ごとの成果物と、次の工程へ進む条件をはっきりさせます。

企画・PoCで検証する代表的な3パターン

実際の難所を把握するため、代表的なパターンをPoCで検証します。

  • SAML対応SaaS:代表的なアプリ。
  • 新規OIDCアプリ:新たに開発するWebアプリ。
  • 古い認証方式:フォーム認証やBasic認証のアプリ。

各アプリでは、ログインとログアウト、属性とグループの連携を確認します。さらに、MFA、利用停止、証明書更新も確かめます。また、IdP障害時の復旧や、利用者が迷わない導線も検証します。

新規のWebアプリではOIDCを第一候補にし、既存のエンタープライズSaaSではSAMLを中心に確認します。なお、OAuth 2.0はAPIのアクセス権限を扱い、ログイン認証そのものとは異なります。

Microsoft Learnは、OIDCをOAuth 2.0上に構築されたサインインプロトコルと説明しています。そのうえで、SAML 2.0とOIDCは、用途を比べて選びます(出典:Microsoft Learn「SAMLとOpenID Connect – 適切なSSOプロトコルを選択する」、2026年確認)。

段階移行で先に決める切り戻しと利用者対応

段階移行では、アプリごとの実施順と切り替えの条件を決めます。

  1. 影響の小さいSaaSから始め、重要業務、オンプレミス、外部利用者へ広げます。
  2. アプリごとに切り替え日時と並行稼働期間を決めます。
  3. 旧ログインの停止条件、切り戻し手順、問い合わせ窓口、管理者の連絡網を定めます。

本番切り替えの日に受託会社が待機するかどうかは、契約と見積もりで確認します。

2026年3月には、docomo business RINK IDaaSが、社内ポータルや業務アプリのリンクからSSOを起動する機能を公開しました(出典:docomo business RINK IDaaS機能アップデート、2026年3月)。

IDaaSの管理画面へ誘導するだけでなく、既存の社内導線を生かす考え方が広がっています。そのうえで、利用者向け案内文、ポータルのリンク差し替え、エラー表示も検討すると、導入後の問い合わせを減らせます。

運用引き継ぎで訓練する退職・異動・障害対応

本稼働後は、例外時の操作と担当範囲を運用手順にまとめます。

  • IDと権限:異動反映、退職者の即時無効化、権限承認、アカウント復旧。
  • 認証情報:証明書・秘密鍵の更新、MFA端末紛失への対応。
  • 障害と連絡:IdP・連携アプリの障害手順、委託先と社内管理者の担当、連絡先、対応時間。

運用テストでは、正常なログインに加えて、退職処理後のアクセス遮断と、権限を外した利用者のアクセス不可を確認します。さらに、MFAを失った利用者を本人確認のあとに復旧できることも試します。

IdPが止まったときに緊急経路が機能することも確認します。これらを受入テストに含めると、設定後に運用できない状態を防げます。

ポイント

工程ごとの成果物と次へ進む条件を決められるかが、進め方の目安です。PoCで難所が見えたら、段階移行の範囲と切り戻し条件を先に決めます。

SSOの契約形態と準委任・請負の使い分け

SSO案件では、工程に応じて契約を分けます。初期調査や運用設計には準委任、仕様と成果物が固まった連携設定・改修・テストには請負が適しています。

稼働後の監視や問い合わせは、保守契約として扱います。その際は、契約名に加えて、どこまでを誰が受け持つかを確認します。成果物と検収の条件、変更手続きと障害対応も確かめます。

調査と伴走支援に向く準委任契約

準委任契約は、要件や対象範囲が固まっていない段階の支援に向いています。

  • 委託内容:専門知識と稼働時間を提供し、調査、会議、設計・設定支援を進めます。
  • 適する状況:対象アプリが増える、認証方式が不明、意思決定支援が必要な場合。
  • 進捗管理:作業時間と機能完成は別です。月次報告、課題一覧、次月の成果目標を定めます。
  • 発注者の役割:資料提供、会議参加、期限内の判断、双方の担当範囲の文書化。

要件整理を委託先へ丸投げすると、情報不足のまま仮定が増え、追加費用や遅延が起きることがあります。

請負契約で細かく定める検収条件と変更管理

請負契約では、作業範囲と変更時の条件を具体的に決めます。

  • 実装範囲:対象アプリ、認証方式、属性マッピング、グループと権限。
  • 検収条件:テスト環境、本番切り替え、成果物、検収期限。「SSO対応」だけでは、SAML設定か自動発行までかが分かれません。
  • 変更管理:アプリ追加、未対応認証方式の判明、Microsoft 365等のライセンス前提変更時の追加費用と納期。
  • 費用と再テスト:無償対応、見積もりが必要な変更、緊急時の単価、再テストの扱い。

発注者と受託会社が、作業範囲、検収条件、変更時の費用を事前に決めておくと、発注後の対立を抑えられます。

ポイント

仕様と成果物が固まっていなければ準委任、固まっていれば請負を選ぶのが目安です。請負では、検収条件と変更時の費用、無償対応の範囲まで決めておきます。

SSO開発を発注・外注する費用相場の目安

小規模、中規模、大規模それぞれのSSO構築・移行費の概算レンジを横棒で示した図解。
対象規模が上がるにつれて、見積もりの幅も大きくなります。

SSO費用は、ライセンス料のほか、作業ごとの費用に分けて考えます。作業には、初期設定とアプリ改修、IDデータ整理があります。移行、利用者教育、保守も費用に含まれます。

公開料金では、100ユーザーのライセンスが年額で数十万円から300万円台まで幅があります。なお、ライセンス料金に構築・移行の外注費は含まれません。この記事の金額は、公式一律価格ではなく、対象規模と作業範囲を置いた概算レンジです。

ユーザー数と機能・契約条件で変わるライセンス料

ライセンスの公式価格を、サービス別に比べます。

  • Microsoft Entra ID P1:月額899円相当です。
  • Okta Workforce Identity:Starter月額940円、Core Essentials2,020円、Essentials2,670円です。
  • 100ユーザーの年額:単純計算で約10万7,880円から320万4,000円です。
  • HENNGE One:Identity Editionは月額300円からです。
  • GMOとCloudGate:複数の料金プランから選べます。

上の価格は、2026年8月時点の公式ページに表示された、1ユーザーあたりの価格です。Microsoft 365 E3やBusiness Premiumに含まれる場合もあります。

GMOトラスト・ログインはSSOプロが月額300円、SSOプロ+SaaS管理が月額500円です。CloudGate UNOはStandard Plusが月額400円、Enterprise Plusが月額500円です。国内サービスは、100ユーザーなら単純計算で年間36万円から60万円程度です。

表示価格は、税別・年契約などの条件に基づきます。年契約の最低額や上位機能、最低ID数は、個別に確認してください。初期設定費、オプション、サポート費についても、確認が要ります(出典:Microsoft Security「Entraのプランと価格」、Okta「プランと価格」、HENNGE One、GMOトラスト・ログイン、CloudGate UNO各公式料金ページ、2026年8月確認)。

規模別の構築・移行費の目安(100万〜2,000万円超)

構築・移行費は、規模と必要な作業範囲に応じて変わります。

  • 小規模:クラウド中心、50〜300人、SaaS3〜10本、既存IdPあり。100万〜300万円、1〜2カ月が目安です。
  • 中規模:300〜1,000人、SaaS10〜30本。AD・人事連携、MFA、SCIM、権限設計、段階移行を含み300万〜800万円、3〜6カ月が目安です。
  • 大規模:複数拠点、オンプレミスのレガシー認証、冗長化、SOC連携、24時間運用を含み800万〜2,000万円超、6〜12カ月以上の可能性があります。
  • 顧客向けCIAM:会員登録、同意管理、外部IdP、アカウント回復、ピーク時の高可用性までのスクラッチ開発は、1,000万〜3,000万円超を想定します。

ここでの想定は、設定・テスト・簡単な運用設計までを委託する範囲です。SaaS連携テンプレートの有無や、利用者データの整理状況によって、費用は変わります。

ここで示すCIAMの金額は、認証処理の自社実装を推奨するものではありません。費用を考えるときは、認証処理を自社で作り込まず、実績あるIDaaSや標準ライブラリを使う進め方を勧めます。固有の会員体験や業務連携の部分に絞って開発できます。この進め方なら、暗号鍵やトークン、パスワード、脆弱性対応を抱え込みにくくなります。

5年TCOで確かめる、見積書に出にくい費用

3年または5年のTCOには、初期導入と継続運用にかかる費用を含めて見ます。

  • 導入時:アプリ連携、レガシー改修、ID重複整理、利用者案内、並行稼働。
  • 運用時:監視、ログ保管、証明書更新、MFA端末、障害時の待機。
  • 見積項目:ライセンス、初期設定、アプリ連携、移行、教育、保守、追加オプション。
  • 複数年で変わる費用:利用者増加、入退社運用、上位プラン、最低契約数、解約時のデータ・設定出力、他製品への移行支援。

ライセンス単価に加えて、管理者の作業時間と、障害で業務が止まるリスクも比べます。そのうえで、削減できる内容を社内で説明できるようにします。

ポイント

費用は、ライセンス料と構築・移行費、3年または5年のTCOに分けて比べます。見積もりの対象規模と作業範囲がそろっていなければ、単価だけで比べないようにします。

SSOの委託先と見積もりを比較するポイント

委託先には、製品販売会社や導入設定を支援する会社があります。既存システムを改修するSIerや、稼働後の運用会社もあります。製品機能だけでなく、認証方式と発注範囲に合った責任体制を確かめます。

似た環境の案件で確かめる実績

導入経験の有無だけでなく、自社に近い環境や担当範囲を確認します。

  • 環境:利用者規模、SaaSとオンプレミスの混在、AD・人事連携、レガシー認証。
  • 対象者と機能:顧客向けか従業員向けか、MFA・SCIM・権限の洗い出しの実績。
  • 案件内容:製品名、対象アプリ数、移行期間、委託範囲、導入後の運用者。

SCSKの統合認証基盤導入サービスは、SSOと権限管理、棚卸しを扱います。そのほか、IDライフサイクルや多要素認証、プロビジョニングも含まれます。

同サービスは、全労済、明治大学、JCOMなどの事例を掲載しています(出典:SCSK「統合認証基盤導入サービス」、2026年確認)。公開事例は、自社にそのまま当てはまるとは限りません。そのため、提案時に匿名の類似案件の体制図や課題・解決方法を示してもらうと、比べやすくなります。

見積比較での作業単位と前提条件のそろえ方

複数社へ同じ前提を渡し、見積もりを作業単位で比べます。

  • 共通条件:RFP、アプリ一覧、利用者数、対象期間、検収条件。
  • 作業項目:要件定義、基本設計、PoC、連携設定、改修、SCIM、人事連携、テスト、移行、教育、保守。
  • 一式の内訳:人日、対象アプリ数、完了条件を質問します。
  • 高額見積もり:冗長化や24時間対応など、不要な要件の有無を確認します。

安い見積もりは、アプリ数が少ない、レガシー対応が別費用、テストや切り戻しが対象外といったケースがあります。さらに、保守窓口が平日の日中だけに限られる場合もあります。

提案書で比べる導入後サポートと撤退条件

提案書では、導入後の保守内容と契約終了時の引き継ぎ条件を比べます。

  • 保守対象:SAML証明書の期限切れ、OIDCクライアントシークレットの更新、アプリ仕様変更、入退社データの同期エラー、MFA端末の紛失。
  • 保守体制:月次ログ確認、権限の洗い出し、復旧訓練、受付時間、重大障害の連絡時間、SLA、報告書。
  • 契約終了時:設定情報、アプリ一覧、属性マッピング、監査ログ、運用手順の受け取り形式。
  • 移行・解約:データと設定の出力、他IdPへの移行支援、解約時のユーザー通知、旧認証に戻す手順。

SSOの発注・外注で起こりやすい失敗と対策

SSOの問題は、技術方式の選び方だけでなく、対象範囲や運用責任の曖昧さからも起きます。そのため、失敗例を知ったうえで、RFP、契約、受入テストに反映します。

IdPを入れれば安全だと考える誤解

SSOはパスワードの使い回しを減らします。一方で、IdPが攻撃されると、影響範囲は複数のアプリに広がります。

  • 予防策:MFA、条件付きアクセス、管理者分離、最小権限、異常ログ監視、緊急時の復旧経路。
  • 避ける状態:管理者MFAの例外や共有IDの継続は、追跡性と統制を弱めます。
  • 受入指標:認証成功率、退職者の無効化時間、権限反映時間、管理者ログ、異常通知先、復旧目標時間。

安全性は、「SSO対応」という言葉ではなく、具体的な運用状態で評価します。その状態を、そのまま受入判定に使います。

一括移行で業務を止めてしまう失敗

一括移行では、属性マッピングや証明書の不備が複数の業務に影響します。そのため、準備を段階ごとに分けます。

  • 移行単位:重要度と認証方式でグループを分けます。
  • 切り替え準備:テスト環境、パイロット利用者、並行稼働、切り戻し条件。
  • 利用者案内:ログイン方法、MFA登録、スマートフォン紛失時の連絡先、問い合わせ先。
  • 役割分担:発注者と受託会社、アプリ所有部署、人事・総務、情報セキュリティをRACI表のように整理します。

受託会社へ移行を依頼する場合は、発注者側でアプリごとの担当者と承認者を決めます。最小権限については、業務部門が確認します。

シングルサインオン(SSO)発注・外注でよくある質問

SSOの発注では、費用や製品だけでなく、対象範囲、契約、運用体制についても質問が寄せられます。発注前に判断しやすい質問から答えます。

SSO開発の外注費用は最低いくらからですか?

既存IdPがあり、50〜300人、SaaSが3〜10本で、設定とテストが中心なら、構築・移行費は100万〜300万円程度が概算です。

ライセンスは別料金です。サービスによって、ユーザー単価や最低ID数が違います。初期設定費やオプションも異なります。

古いWebアプリの改修や、AD・人事連携、SCIMを含める場合は、範囲を分けて見積もります。顧客向けの会員機能を含めるときも、同じように分けます。

Microsoft 365を使っていてもSSOを外注する必要がありますか?

Microsoft 365にEntra IDの機能が含まれる場合、追加のIDaaSライセンスを抑えられる可能性があります。ただし、既存アプリ連携や属性・グループ設計は別途必要です。

MFAや条件付きアクセス、レガシー認証には設計が要ります。SCIMや人事連携、移行、運用にも作業が必要です。

自社で行う設定と外注する設計・改修・移行を分けると、重複費用を抑えられます。

SSOを依頼する会社は何社に相談すればよいですか?

要件が固まった構築案件なら、同じRFPを3社程度へ提示します。そうすると、価格や範囲、体制を並べて比べられます。移行計画と保守も比較の対象になります。

要件が不明なら、まず2〜3社へ現状調査やPoCを依頼します。その結果をもとに、本構築の見積もりを取り直します。

製品販売会社に加え、既存業務システムの改修経験と導入後の運用支援があるSIerも候補にします。

まとめ

SSOを発注するときは、従業員向けWorkforce IAMか顧客向けCIAMかを分けます。そのうえで、対象アプリや認証方式、利用者を一覧にします。権限と入退社の流れも洗い出します。

工程ごとに、導入支援、準委任、請負を使い分けます。保守は稼働後の契約として扱います。

RFPには、MFAやSCIM、ログを記載します。切り戻しや運用責任まで含めます。

ライセンスと構築・運用費に分けた費用の判断

公開料金では、100ユーザーのライセンスが年額数十万円から300万円台です。構築・移行費は、小規模で100万〜300万円、中規模で300万〜800万円、大規模で800万〜2,000万円超が概算です。

対象アプリや既存環境、権限設計によって、金額は変わります。移行方式や可用性、保守条件によっても変動します。単価だけでなく、3年・5年のTCOと見積もりの除外項目を比べます。

最初の一歩となる現状棚卸しと小さなPoC

委託先を決める前に、小さなPoCで認証と運用の条件を確かめます。

  • 対象選定:代表的なSAMLアプリ、新規OIDCアプリ、古い認証方式のアプリ。
  • 動作確認:ログイン、MFA、権限、退職時無効化、障害時復旧。
  • 委託先確認:類似環境の実績、技術範囲、受入条件、保守体制、撤退時のデータ引き渡し。

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を創業。