SSOのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SSOのシステム開発は、ログイン画面を一つにするだけではなく、入社・異動・退社に合わせてIDと権限を安全に管理できる認証基盤を段階的に整える取り組みです。

本記事では、SSOのシステムを導入・開発する進め方を、要件整理、製品・会社選定、設計開発、テスト、稼働、定着の6フェーズに分けて解説します。費用相場、見積もり時の確認項目、SAML非対応の古いシステムやIdP障害への備えまで、担当者がそのまま計画に使える判断基準をまとめます。

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

SSOのシステム開発・導入の全体像とは何ですか？

SSOは、利用者を認証するIdP（Identity Provider）と、利用先のSP（Service Provider）を連携させる仕組みです。利用者がIdPで一度認証すると、許可された複数のSaaSや業務システムへ再ログインなしでアクセスできます。ただし、実務で価値を出すには、認証方式だけでなく、どの利用者にどの権限をいつ付与し、いつ停止するかまで設計することが重要です。

SSOの対象にする機能は、認証の一元化だけではありません。SAML 2.0やOpenID Connect（OIDC）によるアプリ連携、Active DirectoryやLDAPとの同期、多要素認証（MFA）、パスキーやFIDO2、端末・地域・時間帯に応じた条件付きアクセス、監査ログ、セルフパスワードリセットなどが代表例です。さらにSCIMなどを使えば、入社時のアカウント作成や退社時の停止を人事情報と連動させられます。

このため、要件定義で「何個のアプリをつなぐか」だけを決めると不十分です。誰がIDの責任者なのか、異動で部署が変わったときに権限をどう変えるのか、委託先や派遣社員をどう扱うのか、認証基盤が止まったときに業務をどう継続するのかを、業務ルールとして明文化します。

最初に利用者の範囲を分けることも、失敗を防ぐ重要な判断です。従業員向けのWorkforce Identity、取引先や代理店向けのB2Bフェデレーション、顧客向けのCIAM（Customer Identity and Access Management）は、同じSSOという言葉で呼ばれても、登録、本人確認、同意管理、退会、大量アクセス、問い合わせ対応の要件が異なります。

たとえば社内の人事マスタをそのまま顧客アカウントの正本にすることはできません。社内SSOは人事異動や退職に合わせた停止が中心ですが、顧客向けでは会員登録、メール認証、ソーシャルログイン、パスワード再設定、利用規約への同意、急なアクセス増への対応が必要です。日本精工の公式導入事例でも、約1万8,000人規模の社内ID統合と顧客向けサービスのID統合を別の要件として整理しています（出典: Microsoft公式導入事例、2025年）。

SSOのシステム開発・導入は6つのフェーズで進めます

SSOの進め方は、要件整理、製品・導入会社の選定、設計開発、テスト、稼働、定着の6フェーズに分けると管理しやすくなります。各フェーズに完了条件を置き、前の工程で決めていない事項を次工程へ持ち越さないことが、納期と費用のぶれを抑えるポイントです。標準連携のSaaSから始め、例外の多いアプリは後段に回す段階移行も有効です。

最初に作る資料は、製品比較表ではなくアプリ台帳です。Microsoft 365、Google Workspace、勤怠、会計、ワークフロー、営業管理、開発管理、社内ポータルなどを洗い出し、各アプリの利用者、管理者、認証方式、SAMLまたはOIDC対応の有無、アカウント作成・停止方法、権限の持ち主、契約更新日、個人情報の有無を記録します。シャドーITや部門が独自契約したサービスも対象に含めます。

次に、ユーザーとグループの正本を決めます。人事システムを正本にするのか、Active DirectoryやMicrosoft Entra IDを正本にするのか、兼務や外部スタッフをどこで管理するのかを決定します。最低限、アプリ名、利用部門、ユーザー種別、認証方式、付与グループ、退職時の停止期限、担当部署、例外対応者の項目を表にすると、後の見積もり精度が上がります。

このフェーズの完了条件は、対象アプリの優先順位と、未対応アプリの扱いが決まっていることです。優先度は、利用者数、業務停止時の影響、個人情報の重要度、パスワード漏えいリスク、標準連携のしやすさで判定します。すべてを一度に対象にせず、最初のリリースは10〜20アプリ程度に絞ると、PoCで検証しやすくなります。

製品選定では、Microsoft中心ならMicrosoft Entra ID、マルチクラウドや多様なアプリを横断するならOkta、Google Workspace中心ならCloud Identity、国内サポートや小規模な開始を重視するならIIJ IDサービスやHENNGE Oneなどを候補にできます。ただし製品名だけで決めず、対象アプリに対する接続方式、MFA、パスキー、SCIM、人事システム連携、ログ保管、オンプレミス対応を確認します。

製品ベンダーと導入会社は役割が違います。ベンダーはIDaaSや認証製品のライセンスと製品サポートを提供し、SIerや開発会社は現状調査、要件定義、アプリ接続、データ移行、テスト、教育、運用設計を担うことが一般的です。候補先には、SAML非対応アプリをどの方式で接続したか、退社処理をどのように自動化したか、障害時に誰が復旧判断をするかを具体的に質問します。

選定基準は、要件定義力30点、連携実績20点、セキュリティと運用20点、費用透明性15点、サポート15点のように、事前に配点を決めておくと比較しやすくなります。点数は自社で変更できますが、価格だけでなく、例外処理と導入後の運用体制を評価項目に含めることが大切です。

設計では、認証方式、属性、グループ、権限、ログ、例外処理を一体で決めます。SAML 2.0は業務SaaSで広く使われる連携方式で、OIDCはWebやモバイルアプリの認証に向いています。LDAPやActive Directoryとの連携、フォームベース認証、リバースプロキシ、エージェント方式が必要になる場合は、アプリ側の制約とセキュリティ上の責任分界を設計書に残します。

SAMLやOIDCに対応していない古いWebシステムは、無理に標準連携へ見せかけないことが重要です。リバースプロキシや専用エージェントで既存ログインを包む方法、フォーム入力を代理する方法、対象アプリだけを将来更改する方法を比較します。フォームベース認証はパスワードを扱う範囲が増えるため、認証情報の保存場所、暗号化、画面変更時の影響、ベンダーサポートの有無を確認して採否を決めます。

権限設計では、部署や役職だけでなく、業務、拠点、雇用形態、プロジェクト、情報区分を条件にします。過剰なグループを増やすと棚卸しが難しくなるため、基本権限と一時権限を分け、特権IDは通常のユーザーIDと別管理にします。SCIMでアカウントを自動作成する場合も、異動時の権限剥奪、退職時の無効化、再雇用時の扱いまでテーブルで定義します。

セキュリティ設計では、MFAを必須にする対象、パスキーやFIDO2を適用する対象、社外アクセスの条件、ブレークグラスと呼ばれる緊急用管理者アカウントの保管方法を決めます。個人情報保護委員会のガイドラインが示すアクセス制御、アクセス者の識別と認証、不正アクセス防止、漏えい防止の観点も、SSO導入で自動的に達成されるのではなく、設定と運用で確認する必要があります（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。

設計が固まったら、情シスと一部部門を対象にPoCを実施します。正常にログインできることだけを確認するのではなく、初回登録、パスワード忘れ、MFA端末の紛失、異動、退職、アカウント重複、権限不足、権限過剰、SAML証明書の期限切れ、IdP停止、ネットワーク障害まで試します。

PoCの合格基準は数値化します。たとえば対象アプリのログイン成功率、退職処理が完了するまでの時間、権限変更の反映時間、ヘルプデスクへの問い合わせ件数、障害から復旧するまでの目標時間を設定します。利用者30〜300人、アプリ5〜20個の標準連携中心であっても、導入期間を2週間〜2か月程度と見込むなら、テスト期間を削らず、利用者への案内と切り戻し手順を含めます。

テスト結果は、アプリごとの試験記録、画面キャプチャ、ログ、未解決課題、担当者、対応期限として残します。特に「退職者が翌日もログインできないか」「グループを外したときに既存セッションが残らないか」「IdPに入れないときの緊急アクセスが機能するか」は、業務継続と情報漏えいの両方に関わるため、責任者の立ち会いで確認します。

本番稼働では、全社一斉切り替えより、部門やアプリのまとまりごとに段階展開する方法が安全です。まず情シスと協力部門、次に利用頻度の高い標準SaaS、その後に例外アプリという順番にすると、問い合わせの集中と障害の影響を抑えられます。切り替え前には、旧ログインをいつ無効化するか、既存セッションをどう扱うか、利用者へどの手順で案内するかを決めます。

稼働判定では、機能だけでなく運用準備も確認します。問い合わせ窓口、一次切り分けの担当、ベンダーへのエスカレーション条件、ログの確認権限、証明書更新の期限、定例レポートの提出先が決まっていることが条件です。IdPは複数システムの入口になるため、IdPが停止すると複数の業務が同時に止まる可能性があります。冗長化、複数の管理者、緊急用アカウント、障害時の連絡網、切り戻し手順を本番前に確認します。

稼働後に重大な不具合が出たときの切り戻し基準も、事前に合意します。たとえば重要アプリで一定時間ログインできない、退職者の無効化に失敗する、管理者が誰もIdPへ入れない、認証ログが欠落するといった状態は、展開停止や旧方式への切り戻しを検討する条件になります。

SSOは稼働した日が完成ではありません。人事システムからの連携、月次または四半期の権限棚卸し、不要アカウントの削除、MFA端末の再登録、証明書や秘密鍵の更新、ログ監視、SaaSライセンスの利用状況確認を定例業務に組み込みます。退社処理が自動化されても、例外ユーザーや共有アカウントが残っていないかを定期的に確認します。

利用者教育では、ログイン方法だけでなく、MFA端末をなくしたときの連絡先、フィッシング画面を見つけたときの報告方法、共有アカウントを使ってはいけない理由を伝えます。管理者には、ユーザー追加、グループ変更、緊急停止、ログ確認、障害時の復旧訓練を実施します。操作マニュアルは導入時の一回だけでなく、組織変更や新しいアプリ追加のたびに更新します。

定着の指標には、SSO対象アプリ率、パスワードリセット件数、退社処理の完了時間、未使用アカウント数、MFA登録率、権限棚卸しの完了率、シャドーITの発見件数を使えます。導入効果を「ログイン回数が減った」だけで評価せず、IDの残存や過剰権限が減ったか、運用担当者が手作業から解放されたかまで確認すると、次のアプリ連携やガバナンス改善につなげられます。

SSOのシステム開発・導入費用の相場はいくらですか？

SSO固有の公的な一律相場はないため、費用は公開ライセンス料金と、業務システム全般の費用目安を組み合わせて計画します。標準連携中心の小規模導入、中規模の認証基盤構築、大規模・複雑な刷新では必要な工数が大きく違います。以下のレンジは確定価格ではなく、アプリ台帳と要件を作るための初期検討用の目安です。

利用者30〜300人、対象アプリ5〜20個、SAML 2.0やOIDCに対応したSaaSが中心であれば、初期設定、アプリ接続、簡単な移行支援、利用者案内を含めて初期0〜60万円程度が一つの目安です。期間は2週間〜2か月程度ですが、社内ポータルの改修、ID重複の解消、複雑なグループ設計、個別の教育を含めると上振れします。

ライセンスの公開例として、IIJ IDサービスは初期費用0円、最低利用ユーザー数1ユーザー、SSO連携が税抜105円／ID／月、SSO連携と多要素認証の組み合わせが税抜210円／ID／月と案内しています（出典: IIJ IDサービス公式料金ページ、2026年8月確認）。この価格はサービス利用料であり、要件定義やアプリごとの設定、テスト、運用支援まで含む金額ではありません。

利用者300〜3,000人、アプリ20〜100個、Active DirectoryやMicrosoft Entra ID、人事システム、SCIM、権限設計、監査ログ、段階移行まで含む場合は、初期300万〜1,500万円程度が目安です。要件整理から本番展開まで3〜9か月程度となることがあり、認証方式の設定だけでなく、アカウントの正本や異動・退社処理を業務に合わせて作り込むほど工数が増えます。

NotebookLMのリサーチノートでは、業務システム全般の費用目安として、小規模50万〜1,000万円、中規模300万〜5,000万円、大規模1,000万円以上または5,000万〜1億円以上が整理されています（出典: NotebookLMリサーチノート「SSOのシステム」、2026年）。これはSSO固有の統計ではありませんが、周辺の個別開発やデータ連携が増えると、認証サービスの月額だけでは説明できない費用になることを示す参考値です。

複数子会社や海外拠点、数千〜数十万人のID、顧客向けCIAM、古い独自認証、24時間365日の運用、冗長化、SIEM連携、厳格な監査を含む案件では、初期1,000万〜5,000万円超になることがあります。期間も6〜18か月以上となり、製品導入だけでなく、組織横断のID統合、データクレンジング、運用移管、復旧訓練まで計画します。

公開料金を比較するときも、プランの範囲を確認します。Microsoft Entra ID P1は公式ページで899円／ユーザー／月相当の年払いと案内され、Microsoft 365 E3やBusiness Premiumに含まれる場合があります（出典: Microsoft Entra公式料金ページ、2026年8月確認）。OktaはStarterが1ユーザーあたり月額6米ドル、Essentialsが17米ドルからで、年次請求と案内されています（出典: Okta公式料金ページ、2026年8月確認）。為替、最低契約額、既存ライセンス、導入支援費を含めて比較してください。

SSOのシステム開発で見積もりを取る際のポイントは何ですか？

見積もりの金額差は、単価の差よりも前提条件の違いから生まれます。対象ユーザー、アプリ数、標準連携と個別連携の区分、既存IDの状態、MFA、パスキー、SCIM、人事連携、ログ保存、教育、保守、障害対応を同じ資料で渡し、候補3社程度から比較見積もりを取得します。

RFPや見積依頼書には、まずユーザー条件を記載します。従業員、派遣社員、業務委託、取引先、顧客の人数、増加予定、拠点、利用時間帯、管理者数を分けます。次にアプリ条件として、対象アプリ名、重要度、利用部門、認証方式、SAML・OIDC対応、オンプレミスかクラウドか、現行のログイン方式、契約更新日を一覧化します。

認証条件にはMFAの対象、パスキーやFIDO2の採用、端末証明書、条件付きアクセス、セッション時間、パスワードポリシー、緊急用アカウントを入れます。運用条件には、入社・異動・退社の処理時間、権限棚卸しの頻度、ログ保管期間、監視時間、問い合わせ対応、証明書更新、復旧目標、教育範囲を入れます。これらがない見積もりは、安く見えても後から追加作業が発生しやすくなります。

見積書では、IDaaSや認証製品のライセンス、初期設定、要件定義、アプリ接続、個別開発、ID移行、データクレンジング、テスト、利用者教育、運用設計、保守を別項目にしてもらいます。標準コネクタを使えるアプリと、リバースプロキシやフォームベース認証が必要なアプリを同じ単価で見積もると、工数の比較ができません。

HENNGE Oneの公式ページでは、Identity EditionのIdPが月額300円から、IdP Proが月額500円からと案内されていますが、最小契約ID数は各200以上です（出典: HENNGE One公式料金ページ、2026年8月確認）。このように、1IDあたりの金額だけでなく、最低契約数、契約期間、オプション、サポートの範囲を確認します。3年間のライセンス、初期作業、運用支援、追加アプリの接続費を合算した総保有コストで比較すると、実際の予算を判断しやすくなります。

安い提案では、アプリ台帳の作成、既存IDの重複解消、権限マトリクス、利用者への周知、例外アプリの検証、稼働後の問い合わせが対象外になっていることがあります。見積もりの前提、対象外、追加単価、納期、検収条件、契約期間、減員・解約条件を確認し、想定外のユーザー数やアプリ数が増えた場合の単価も記載してもらいます。

障害時の責任分界も重要です。IdPの障害、ネットワーク障害、アプリ側の設定ミス、証明書期限切れ、利用者のMFA端末紛失が起きたときに、誰が一次対応し、誰がログを調べ、何時間以内に復旧を目指すのかを決めます。導入会社が運用まで担わない場合は、自社の管理者が対応できるように手順書と訓練を見積もりへ含めます。

SSOのシステム開発・導入に関するよくある質問

最後に、SSOのシステム開発を検討する担当者からよく寄せられる質問に回答します。自社の人数やアプリ数に当てはめるときは、ライセンス料金だけでなく、連携方式、権限設計、テスト、運用の範囲まで含めて判断してください。

人数だけでなく、利用するアプリ数、パスワードリセットの件数、入社・退社の頻度、情報の機密性で判断します。30〜300人程度でも、複数のSaaSを使い、退職者のアカウント停止を手作業で行っている企業であれば、SSOとID管理の効果を得やすいです。小規模導入では標準連携できるアプリから始め、初期0〜60万円程度の範囲を起点に、必要な作業を見積もる方法があります。

無料とは限りません。契約しているMicrosoft 365のプランにMicrosoft Entra IDの機能が含まれる場合は、追加ライセンスを抑えられる可能性がありますが、対象アプリの接続、条件付きアクセス、MFA設計、既存IDの整理、移行、テスト、教育、運用には工数がかかります。Microsoft Entra ID P1は公式ページで899円／ユーザー／月相当と案内されていますが、既存契約に含まれるかは契約プランと契約条件を確認してください。

できますが、標準連携より慎重な検討が必要です。リバースプロキシ、エージェント、フォームベース認証などの方式を候補にし、既存画面の変更、認証情報を扱う範囲、障害時の切り分け、製品や保守会社のサポートを確認します。接続費用をかけるより、古いシステムの更改時期に合わせて対象外とする方が安全な場合もあるため、業務影響と費用を比較して決めます。

同時に導入できます。むしろSSOで認証を一元化するなら、パスワードだけに依存せず、MFA、FIDO2、パスキー、端末証明書、条件付きアクセスをリスクに応じて組み合わせることが重要です。全員に同じ方式を強制する前に、管理者、社外アクセス、特権操作、一般利用者の順で適用範囲を決め、端末紛失や認証器の再登録、緊急時の代替手段をテストします。

標準連携のSaaSを少数設定するだけなら2週間〜2か月程度、中規模の認証基盤なら3〜9か月程度、大規模で複数拠点や古いシステムを含む場合は6〜18か月以上が目安です。期間はアプリの調査、権限設計、利用者教育、異常系テスト、段階移行をどこまで行うかで変わります。納期を短くする場合も、退社処理とIdP障害のテストを省略しないことが大切です。

まとめ：SSOは6フェーズで進め、IDライフサイクルまで定着させます

SSOのシステム開発・導入は、(1)アプリ・ID・権限の要件整理、(2)製品と導入会社の選定、(3)認証・連携・権限の設計開発、(4)PoCと異常系テスト、(5)段階的な本番稼働、(6)棚卸し・教育・復旧訓練による定着、の順に進めます。特に、SAMLやOIDCに対応しないアプリ、退職者の停止、人事マスタとの連携、顧客向けCIAM、IdP障害時の業務継続を初期から確認することが重要です。

費用は、標準連携中心の小規模導入なら初期0〜60万円程度、中規模の人事連携や権限設計を含む場合は300万〜1,500万円程度、大規模・複雑な刷新では1,000万〜5,000万円超が目安です。いずれもSSO固有の一律価格ではなく、公開ライセンス料金と業務システム全般の相場、連携・移行・運用工数から整理したレンジです。候補先には同じアプリ台帳と要件を渡し、3年分の総保有コストで比較します。

最初の一歩は、対象アプリ、利用者、認証方式、グループ、権限、退社処理、ログ保存、MFA、障害時の連絡先を一覧にすることです。そのうえで10〜20アプリ程度のPoCを実施し、正常ログインだけでなく、異動、退職、権限過剰、MFA端末紛失、証明書期限切れ、IdP停止、切り戻しを確認します。SSOを便利なログイン機能で終わらせず、IDを安全に生涯管理する業務基盤として設計することが、導入効果とセキュリティを両立する近道です。

▼全体ガイドの記事
・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を創業。