統合認証基盤開発は、要件整理から運用定着まで6フェーズで進めます。各フェーズの内容は、次の見出しごとに順に示します。各フェーズで決めたことを次へ確実に渡していくと、安全な認証統制につながります。
▼全体ガイドの記事
・統合認証基盤開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
統合認証基盤の全体像
統合認証基盤は、従業員、派遣社員、委託先、取引先などのIDを一元的に管理し、複数システムの認証と認可を共通化する仕組みです。
SSO（シングルサインオン）は代表的な機能です。さらに、開発範囲はIDライフサイクル、権限、監査、障害時の復旧まで含め、IAMの土台として定義します。
SSOとIDライフサイクルの一体設計
SSOのみでは入退社時の管理を完結できません。そのため、入社から退職までのアカウント管理も含めて、統合認証基盤ではSSOとIDのライフサイクルを一体で設計します。
- SSO：SAML 2.0やOpenID Connect（OIDC）を使い、複数のSaaSや業務アプリに接続する
- IDの更新：入社時に作成し、異動時に所属を変え、退職・委託終了時に停止する
- システム反映：人事システムやActive Directory（AD）をIDの正とし、変更を各システムに反映する
SSOを使うと、ログイン回数とパスワードの使い回しを抑えられ、認証ログも集約しやすくなります。
Google Cloudは、Cloud Identityで SAML 2.0・OIDCアプリとオンプレミスアプリを一元管理できると案内しています（出典: Google Cloud「Cloud Identity」、2026年8月確認）。
ユーザープロビジョニングも、一元管理の対象です（出典: Google Cloud「Cloud Identity」、2026年8月確認）。
各システムへの反映を、SCIM、API、ワークフローで行う設計まで含めれば、管理者の手作業とアクセス停止漏れを減らせます。
認証と認可の分離
認証は本人確認、認可は認証後に使えるデータや操作の制御を指します。そのため、設計時には両者を分けて要件に書きます。
- 認証手段：パスワード、認証アプリ、セキュリティキー、生体認証、パスキーを使います
- 認可範囲：契約書の閲覧と承認は分け、法務案件は担当者だけが編集できるようにする
- 権限属性：部署・役職のほか、案件、委託先区分、機密度、契約期間を扱います
文書や契約の権限は、対象データと業務上の役割に応じて設定します。
管理者権限と職務の分離、必要な時間だけの特権昇格、アクセスレビューを要件に含めます。省くと、SSOを導入したあとも過剰権限が残ります。
NIST SP 800-63-4では、本人確認と認証器を論点として整理しています。加えて、認証プロトコル、フェデレーション、プライバシーも論点です（出典: NIST「NIST SP 800-63-4」、2025年8月公開）。
クラウド型・オンプレミス型・個別開発型の選び分け
既存環境や必要な機能に応じて、クラウド型、オンプレミス型、個別開発型のいずれかを選びます。
- IDaaS：Microsoft Entra ID、Okta Workforce Identity、Google Cloud Identityなどを使います
- パッケージ・オンプレミス：既存ADや社内ネットワークを重視するときの選択肢です
- 個別開発：標準製品や実績あるライブラリを核に、周辺連携を作り込む方式
IDaaSは、SSOとMFAに加え、プロビジョニングや条件付きアクセスも標準機能で使えます。そのため、短期間で始めやすい方式です。
独自認証をゼロから作る場合は、保守や脆弱性対応、障害復旧の負担が大きくなります。
統合認証基盤開発の進め方と6フェーズ
製品を先に決めると、対象外のシステムや例外アカウントが後から見つかり、費用と納期が膨らみやすくなります。そのため、まず現状を一覧にして、優先順位を決めます。
標準機能で賄う部分と個別開発の範囲を分けたうえで、段階を追って接続していきます。各段階の成果物と判断基準も、あらかじめ決めておきます。
フェーズ1：要件整理（IDと業務の全体像）
要件整理では、利用者とアプリの現状を台帳にまとめます。そのうえで、IDをどう見分けるか、どんな資料を作るかを決めます。
- 対象の洗い出し：社員、派遣社員、退職予定者、委託先、取引先、共有端末の利用者と、アプリの認証方式・管理者・機密度・権限・ログ期間・停止手順を整理する
- IDの識別：人事システムとADのどちらを正とするか、メール変更時のキー、兼務者のグループ
- 成果物と優先度：業務フロー、ID・権限台帳、接続一覧、機能・非機能要件、移行方針、概算日程を作成し、MUSTとWANTを分ける
- 初期データ確認：管理者MFA、自動停止、重要文書の認可、監査ログ、緊急アクセスをMUSTとし、未使用・重複IDの数を把握する
未使用アカウントや重複IDの数は、名寄せの難しさを見積もる材料になります。
フェーズ2：要件適合性による製品・開発会社の選定
選定では、製品の知名度や月額料金に加え、機能と既存環境への適合性を見ます。
- 認証・連携：SAML、OIDC、SCIM、FIDO2、AD・LDAP連携
- アクセス制御：条件付きアクセス、特権アクセス、アクセスレビュー
- 監査：ログのSIEM連携と、必要なライセンスの有無
Microsoft 365を中心に使っているなら、Microsoft Entra IDの既存ライセンスを確認します。複数クラウドや多数のSaaSを使うならOktaを、Google WorkspaceやGoogle Cloudを中心にするならCloud Identityなどを比べます。
Microsoft Learnは、条件付きアクセスにはP1、リスクベースの条件付きアクセスにはP2など、機能ごとに必要な契約を案内しています（出典: Microsoft Learn「Microsoft Entra ライセンス」、2026年8月確認）。
提案依頼書（RFP）では、ベンダーの機能と、SIerや開発会社が担う設定、連携、移行、運用を分けて書きます。そのうえで、同じRFPを複数社に渡して比べます。
フェーズ3：認証・認可・連携の設計と開発
設計と開発では、認証、認可、連携、障害時の運用をまとめて扱います。
- 認証設計：ID属性、グループ、ロール、承認者、再認証条件、MFA対象、ログ保存先の定義
- 認可設計：案件単位のアクセス、閲覧と編集、承認者の職務、委託先の期限付きアクセスの切り分け
- 開発範囲：標準コネクタ、SAML・OIDC、SCIM・API、AD・人事、レガシー用ゲートウェイ、管理画面、監査ログ、通知、バックアップを含む
- 緊急経路：ブレークグラス用の管理者経路を通常経路から分け、利用条件と事後監査を決める
これらをすべて開発の対象に含め、障害時の運用まで見据えて設計します。
認可を後回しにすると過剰権限が残るうえ、後からデータ構造の作り直しが必要になります。
フェーズ4：例外と障害を含むテスト
テストでは、認証が通るかだけでなく、ライフサイクルの例外、権限、障害時の動作まで確かめます。
- 状態遷移：入社、異動、兼務、休職、退職、委託終了、メール変更、重複ID、権限の剥奪と再付与
- 認証・権限：MFA端末の紛失、パスキーの再登録、閲覧・編集・承認・管理者操作
- 障害条件：IdP・ネットワーク障害、証明書切れ、コネクタ停止、ログ転送失敗、時刻ずれ、過負荷
- 受入基準：成功率、応答時間、停止反映時間、ログ欠落、緊急経路の記録を確認し、利用部門が業務シナリオを実行する
権限の確認には、機密度を模したテストデータを使います。さらに、利用部門が参加すると、管理者だけでは見つけにくい現場の例外も見つかります。
フェーズ5：段階移行による稼働
一斉に移行せず、影響を確かめながら対象を段階的に広げます。
- 移行順：管理者MFAと主要SaaSのSSO、人事連携と自動停止、重要な契約・文書、SAML・OIDC非対応のレガシーアプリの順
- 並行稼働：二重登録、ログ突合、切り戻し条件、利用者への案内の取り決め
日立情報通信エンジニアリングの2025年の教育機関向け事例では、新システム構築、一部システム、内部門システム、クラウドなどの順に切り替えています。この事例は、既存システムを延長利用しながら4段階で導入し、一斉切替のリスクを抑えています（出典: 日立情報通信エンジニアリング「導入事例vol.1」、2025年2月）。
フェーズ6：運用ルールと権限レビューによる定着
稼働後は役割を分担したうえで、定期点検、権限レビュー、利用者支援、効果測定を続けます。
- 役割・月次点検：基盤管理者、アプリオーナー、人事、情報セキュリティ、ヘルプデスクの役割分担と、失敗ログ、停止漏れ、緊急経路、証明書、コネクタの点検
- 権限レビュー：四半期ごとに不要なIDと権限を洗い出し、担当者、承認者、未回答時の扱いを規程に記す
- 利用者支援：ログイン、MFA・パスキー登録、端末変更・紛失時の連絡、怪しい通知への対応を、手順書と研修で伝える
- 効果測定：退職者の停止時間、権限レビューの完了率、問い合わせ件数、監査ログの検索時間
IPAは、多要素認証に加えて、生体認証やPINを使うパスキーを推奨しています（出典: IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年8月）。
導入効果は、ログイン回数よりも運用指標で追い、継続的な改善に生かします。
統合認証基盤開発の費用相場
費用は、初期の設計、設定、連携、移行、テスト、教育費と、継続するライセンス・保守・監視費に分けて考えます。
継続費は毎月または毎年かかります。また、国内の統合認証基盤だけを対象にした公的な一律の相場は限られます。
ここで示す金額は、類似する業務システムの受託相場と公開料金から整理した推定です。
費用は、利用者数に加えて、接続アプリ数、既存ADの状態、レガシー改修、可用性、24時間運用の有無によって変わります。
小規模な部分連携の費用目安：300万〜1,500万円程度
100人から数百人で主要SaaSを数本接続し、SSO、管理者MFA、基本的なID登録を行う場合、初期費用は300万〜1,500万円程度が推定レンジです。
期間は2〜4か月程度が一つの目安です。ID台帳が整っていて、対象アプリがSAMLやOIDCに対応していれば、下限に近づきます。
名寄せ、アプリ改修、権限モデル、操作教育まで含めると、上限側に寄りやすくなります。
中規模の全社統合の費用推定：1,500万〜4,000万円程度
ADやLDAP、人事システムと連携し、SAMLやOIDCで10〜30システムを接続する場合、初期費用は1,500万〜4,000万円程度が目安です。権限設計、ログやSIEM連携、段階移行まで含めた想定です。期間は4〜9か月程度です。
利用者が少なくても、システムごとに認証方式が違えば工数は増えます。機密度別の認可や、保守期限が迫る旧システムも、費用に影響します。
大規模な刷新の費用想定：4,000万円超
複数会社・拠点、数万ユーザーを含む場合は、4,000万円を超える見積もりも考えられます。さらに、次の条件も見積もりを押し上げます。
- 環境：オンプレミスとクラウドの混在
- 権限：特権IDを扱う
- 可用性：冗長化を含む
24時間監視や複数のレガシー改修も費用に響きます。
要件整理から本番移行まで、半年から1年以上かかるケースもあります。
金額と合わせて、移行回数、切り戻しの方法、稼働後の監視担当者も、見積もりの前に確かめます。
ライセンス費の扱いとTCO比較
公開料金を比べるときは、ライセンス費を初期開発費と分け、TCOで判断します。
- Okta：Starterは1人あたり月額940円、Essentialsは1人あたり月額2,670円です
- Cloud Identity Premium：月額7.2米ドル／ユーザーです
- Microsoft Entra ID：保有ライセンスと必要機能の照合
Oktaの料金で1,000ユーザーなら、単純計算で月94万円（Starter）または月267万円（Essentials）です。年額にすると、1,128万円または3,204万円が出発点になります。
契約期間や最低契約額、税などの条件に加え、追加機能と導入支援費も別途確認が必要です（出典: Okta「プランと価格」、2026年8月確認）。
Google Cloudの場合、1,000ユーザーなら月7,200米ドルで計算されます。ただし、為替や税、契約条件に加え、既存のGoogle Workspace契約や導入支援費は含まれていません（出典: Google Cloud「Cloud Identity」、2026年8月確認）。
Microsoft Entra IDのP1・P2は、単体契約のほか、Microsoft 365などに含まれる場合があります。そのため、条件付きアクセスやプロビジョニング、ガバナンスなど必要な機能と保有ライセンスを照らし合わせ、二重計上を避けます。
保守・運用費の出発点：初期費用の5〜15％程度
類似する業務システムでは、保守・運用費を初期開発費の年5〜15％程度から検討できます。ただし、認証基盤では割合だけで決めないことが大切です。
保守では、証明書・コネクタ更新、脆弱性対応、ログ保管が続きます。さらに、権限の棚卸し、障害対応、利用者支援も発生します。
保守・運用費では、夜間休日の監視と復旧目標、代替認証経路、サポート時間を、明細で比べます。
統合認証基盤の見積もりのポイント
同じ製品でも、見積もりはIDの品質と権限の複雑さで大きく変わります。接続方式や移行回数、運用体制も見積もりを左右します。だからこそ、RFPには標準機能と個別開発の範囲を書いておきます。
稼働後の運用を担う人も明記しておきます。
テスト、教育、移行、保守が別々の契約に分かれていないかも確かめます。
見積もり前の資料整理（利用者・アプリ・IDの正・権限）
見積もりの前に、利用者や接続アプリを資料にまとめます。加えて、IDの管理元と権限ルールも書いておきます。
- 利用者・ID：人数内訳、年間の入社・異動・退職件数、AD・LDAP、人事連携、共有アカウント、委託期間の記録
- アプリ：名称と利用者数、認証方式、SSO・作成・停止の方法、管理者、テスト環境、停止できない時間
- 権限：ロール、承認フロー、閲覧・ダウンロード・編集・承認、外部共有、管理者操作の区分
役割と案件属性の組み合わせも書いておきます。
「要件定義で検討」とした未確定の項目には、追加工数を避けるために決定期限と決定者を設けます。
複数社の同条件比較と責任範囲の明確化
同じRFPと前提条件をそろえ、費用や作業範囲を中心に、実装責任と運用体制も比べます。
- 費用明細：設計、製品設定、連携、個別開発、移行、テスト、教育、稼働支援、保守の区分
- 比較条件：対象外作業、ユーザー数、アプリ数、納品物、検収条件、追加変更単価の統一
- 実装責任：製品機能と構築会社の担当範囲、同規模・同業種の実績、連携実績
- 引き継ぎ：設計書、設定値、データ出力、障害の一次対応、知識共有の体制
対応技術は、SAML、OIDC、SCIM、FIDO2への対応を確認します。
AD、人事、電子契約、レガシー連携の経験も質問しておきます。
契約が終わったときにデータを出せるか、障害時の一次対応者は誰かも確認します。特定の担当者だけに知識が集まっていないかも、判断材料になります。
移行・障害・出口戦略の見積もり
移行費、障害対策、クラウド契約の出口対応は、見積もりに含めておきます。
- 移行費：ID名寄せ、旧パスワード、並行稼働、再登録案内、アプリごとの受入テスト、切り戻し、ログの長期保存、証明書更新、監視
- 障害対策：可用性、バックアップ、復旧目標時間、緊急管理者の保管、連絡網、訓練の見積もり
- 出口対応：データ所在地、委託先、海外法令、ログ保存先、データ出力、サービス終了時の移行支援の確認
なお、監査ログや権限レビューを省くと、機密情報を扱う企業では、別の統制費用が発生します。
最後に、TCOは初期費用、ライセンス、保守、内製運用の人件費を合算して判断します。
統合認証基盤開発でよくある質問（FAQ）
進め方は利用者数、既存環境、接続アプリ、セキュリティ要件によって変わるため、導入前によく出る疑問を判断の見方とあわせて挙げます。
何人規模から統合認証基盤を開発すべきですか？
一律の人数基準はありませんが、100人程度でも契約・法務データを扱い、SaaSが増えて退職者の停止が手作業になっていれば、管理者MFAや主要SaaSのSSOから始められます。
人事連携も候補に入ります。人数が多くても、対象アプリが少なく既存ライセンスで要件を満たせるなら、設定支援から始められる場合があります。
判断は、利用者数とアプリ数に加え、権限の複雑さや停止漏れのリスクで行います。
SSOを導入すると認証情報が集中して危険ではありませんか？
SSOは認証の入口が一か所にまとまるため、IdPの管理者権限と復旧手段を強く守る必要があります。そのうえで、MFAや条件付きアクセス、フィッシング耐性のあるパスキーも組み合わせます。
管理者の分離や異常ログの監視、短時間の特権昇格、緊急経路の監査も有効です。認証がばらばらに分かれているより、統制を取りやすい場合があります。
ゼロトラストには、SSOに加えて、認可と運用監視まで設計することが前提になります。
SAMLやOIDCに対応していない古いシステムは接続できますか？
接続できる可能性はありますが、個別に検討が必要です。候補には、認証プロキシやアクセスゲートウェイ、リバースプロキシがあります。既存アプリの改修や連携用APIも、検討の対象になります。
まず、保守期限と改修の可否、通信経路を調べます。そのうえで、共有アカウントや監査ログ取得の可否も確かめます。重要度の低いアプリを対象外にする判断も含めます。
標準プロトコルに対応したアプリから移行し、レガシー連携は別フェーズに分けると、リスクを抑えやすくなります。
統合認証基盤の開発期間はどのくらいですか？
主要SaaS数本とMFAの部分連携は、2〜4か月程度が推定の目安です。一方で、AD・人事連携と10〜30システムの統合は、4〜9か月程度です。
複数会社・数万ユーザーの規模や、冗長化、24時間運用、レガシー改修を含むと、半年から1年以上かかることもあります。
短くするには、要件を曖昧にせず、対象アプリに優先順位を付けます。あわせて、標準機能の範囲と受入基準も先に決めておきます。
統合認証基盤開発の進め方・やり方・流れのまとめ
統合認証基盤開発は、IDの正と認証、認可を中心に、ライフサイクル、監査、障害対応までを整えるプロジェクトです。ログインを一つにまとめることは、その一部にすぎません。
費用の推定レンジは、小規模な部分連携で300万〜1,500万円程度、中規模の統合で1,500万〜4,000万円程度です。大規模な刷新では、4,000万円を超えることもあります。
ライセンス、初期開発、移行、保守は分けて、実際の対象範囲に合わせて見積もります。
6フェーズの順序と判断の記録
実務では、各フェーズの成果物と決定者をはっきりさせながら、順に進めます。
- 利用者、アプリ、権限を洗い出して要件を整理する
- 既存契約と標準プロトコルを踏まえて製品・開発会社を選ぶ
- 認証、認可、ID連携、ログ、緊急経路を設計・開発する
- 例外、障害、権限剥奪を含めてテストする
- 段階移行で稼働する
- 権限レビューと教育で運用を定着させる
未確定の事項を次の工程に持ち越さないことは、納期と費用を守る助けになります。
最初に作るID台帳と接続アプリ一覧
発注の前に、IDとアプリの状況、認証・権限のルールを確かめ、段階導入の計画を立てます。
- 現状整理：ID台帳、アプリ一覧、認証方式、権限、入社・異動・退職の処理、監査ログ、緊急アクセス
- 段階導入：管理者MFA、主要SaaSの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を創業。