統合認証基盤の発注は、利用者と接続先を整理し、要件と責任範囲を合意してから、段階的に導入する順で進めます。この順を守ると、導入後も安全な認証運用につながります。
発注形態から委託先の比較まで、各段階で決めておくべきことを順に取り上げます。
▼全体ガイドの記事
・統合認証基盤開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
統合認証基盤を外注する前に押さえる全体像
統合認証基盤とは、従業員や派遣社員、退職者、取引先などのIDを、複数のシステムにまたがって管理する仕組みです。ログイン方法や権限、認証ログも、あわせて管理の対象になります。
SSOだけを指す場合もありますが、発注時には、認証や認可、IDのライフサイクル、監査、障害時の復旧経路までを含めて、IAMの基盤として位置づけます。
認証と認可を分けた発注範囲の定義
発注範囲を定める際は、認証と認可を分けて考えます。
- 認証：利用者が誰かの確認。
- 認可：利用者が何にアクセスできるかの判断。
法務担当者が契約書を閲覧できても、全社の人事情報まで変更できるとは限りません。そのため、権限モデルは、部署や役職に加えて、案件、雇用区分、委託先の有効期限を組み合わせて決めます。
権限モデルを決めないままSSOだけを導入すると、必要以上の権限が付いたままになったり、退職後のアカウントが残ったりします。
SSO・MFA・IDライフサイクルの一体運用
発注対象は、ログインの入口に加えて、本人確認とアカウントの連携まで含めて考えます。
- ログイン連携：SAML 2.0やOpenID ConnectによるSSO。
- 本人確認：MFA、パスキー、条件付きアクセス。
- アカウント連携：SCIMやAPIによるプロビジョニング。
人事システムをIDの正とする場合は、入社や異動、休職、退職に伴う処理を決めておきます。さらに、委託先の契約が終わるときも、アカウントの削除を自動で行えるか、承認を経て行えるかを確認します。
文書・契約・法務の領域では、誰がいつどの文書にアクセスしたかを追えるログの設計が欠かせません。
IDaaS・パッケージ・個別開発の使い分け
接続環境と運用負担に応じて、既製のサービスと個別開発のどちらを選ぶかを決めます。
- IDaaS：SSO、MFA、ディレクトリ、プロビジョニングを導入しやすい選択肢です。
- パッケージ・自社運用型：既存ADやオンプレミスを重視する場合の候補です。
- 個別開発：特殊な組織階層やレガシー接続、承認処理など、限られた範囲の開発です。
IDaaSの例には、Microsoft Entra ID、Okta Workforce Identity、Google Cloud Identityなどがあります。一方、自社運用型では、サーバーと冗長化の責任が社内に残ります。さらに、証明書の更新やパッチ、監視も社内で担うことになります。
独自の認証プロトコルを一から作るより、実績のある基盤を使い、必要な部分だけを開発する形が現実的です。
統合認証基盤の発注形態の選び方
発注形態は、製品をどこと契約するかと、設計・移行・運用を支援する会社を誰に頼むかを分けて考えると、整理しやすくなります。
IDaaSの販売会社だけでは、要件の整理やレガシー改修まで担えないこともあります。そこで、製品ベンダーや導入支援会社、SIer、保守会社のそれぞれの役割を、RFPで明確にしておきます。
IDaaSの導入支援を外注する形
Microsoft 365やGoogle WorkspaceなどのクラウドSaaSが中心で、標準コネクターを使える場合は、導入支援会社への委託が候補になります。
- 委託作業：初期設計、テナント設定、SSO接続、MFA展開、操作教育。
- 向く状況：利用者数とアプリ数が少なく、短期間で効果を確かめたい場合。
まず、既存のライセンスに必要な機能が含まれるか、追加の契約が要るかを確かめます。そのうえで、設定変更の所有権が誰にあるかを、契約前に合意しておきます。
SIerや受託開発会社へ一括委託する形
既存のディレクトリや人事、契約関連のシステムを接続する場合は、要件から運用設計まで扱える会社が候補になります。
- 対象例：AD、LDAP、人事、電子契約、VPN、SAML非対応の旧システム。
- 委託範囲：要件定義、設計、移行、テスト、運用設計。
窓口を一本化できる利点がある一方、製品費や初期設定費、連携開発費が一つの見積書に混ざりがちです。移行費と保守費も、同じ見積書の中で区別しにくくなります。そのうえで、再委託先や担当技術者、成果物の引き渡し範囲を確認し、作業項目ごとに分けてもらいます。
段階導入または分離発注にする形
全社を一度に切り替えると、障害や設定ミスの影響が広がります。そのため、次の順で段階的に導入するのが有効です。
- 管理者と主要SaaSへのMFA・SSO導入
- 人事連携とアカウントの自動停止の整備
- 重要な文書・契約システムとレガシーアプリの接続
- 権限レビューと特権アクセスの整備
日立情報通信エンジニアリングの2025年公開事例では、短期構築のリスクを避けるため、4段階で導入しました（出典: 日立情報通信エンジニアリング導入事例、2025年）。
導入の段階は、新基盤と認証切替、クラウドSSO、その他システムのSSOです。
大規模案件では、企画と要件定義を準委任で頼み、仕様が確定したあとの構築を請負に分ける方法もあります。
RFPと要件整理の進め方
RFPは、提案を同じ条件で比べられるように、現状と目的、範囲を示す文書です。
RFPには、制約や成果物、評価基準も書き込みます。
特定の製品の機能に引っ張られないよう、まず業務上の効果を書いておきます。
必須要件と、提案を求める要件は、分けて記載します。
現状のID台帳と接続対象の整理
RFPの前提として、利用者台帳とアプリ一覧に次の情報をそろえておきます。
- 利用者：区分別人数、ID発行元、所属、管理者、退職・異動処理。
- アプリ：認証方式、SAML・OIDC、プロビジョニング、重要度。
- 運用条件：停止可能時間帯、ログ保存期間。
「1,000人・30アプリ」といった総数だけでは足りず、方式別の数と重要アプリの数まで示します。
SAML対応が20、OIDC対応が5、独自ログインが5（うち契約書管理が2）と整理すれば、各社の見積の差を説明しやすくなります。
機能要件と非機能要件の具体化
機能要件では、SSOやMFAなど認証の働きを書きます。ID管理や監査、可用性、緊急時の条件は、別の項目として書き分けます。こうして分けておくと、設計の範囲に何が入り、何が入らないかを確認できます。
- 機能：SSO、MFA、パスキー、条件付きアクセス、グループ連携。
- ID管理：SCIM、退職時停止、アクセスレビュー。
- 監査：監査ログ、SIEM連携、ログ保存期間。
- 可用性：復旧時間、認証性能、データ所在地、バックアップ。
- 緊急時：ブレークグラス管理者と管理操作の二者承認。
NIST SP 800-63-4は、本人確認と認証器を扱う参照資料です（出典: NIST SP 800-63-4、2025年）。認証プロトコルや連携、プライバシーも扱っています。
ただし、NISTが2025年8月に公開したもので、日本の法令ではありません。とはいえ、認証の強さや委託先の設計説明を確かめる補助資料としては使えます。
移行・テスト・運用の要件
切替時に生じる例外は、次のとおりです。これらを先に洗い出し、移行と受入の条件をRFPに明記します。
- 例外：重複ID、メール変更、兼務、委託先、休職者、共有アカウント。
- 移行：事前クレンジング、並行稼働期間、切戻し条件。
- 受入：利用者案内、問い合わせ体制、テスト担当。
緊急用の管理者経路は、通常のSSO障害と同時に使えなくならない設計にします。
保管場所と利用承認を決めるほか、利用後のパスワード変更やログ監視まで定めます。
契約形態と導入工程の設計
発注時に決められる内容と調査後に確定する内容が混在するため、現状調査や要件定義を請負で固定すると、未知の連携や例外が見つかるたびに変更契約が増えてしまいます。一方で、全工程を準委任にすると、成果物や完了条件が曖昧になりやすくなります。
契約と責任は、工程ごとに分けて設計します。
調査・要件定義・伴走支援に向く準委任契約
完成物だけでは成果を測りにくい工程では、専門家の知識や作業時間を頼む準委任が向いています。その際は、どの工程を頼むかと、作業時間や報告の条件を契約で決めておきます。
- 対象工程：現状調査、要件定義、製品選定、移行計画、運用設計。
- 契約条件：作業時間、担当、定例会議、報告書、判断事項、月上限。
準委任であっても、品質の確認は欠かせません。そのため、成果物のレビュー日程と設計説明の責任を、あらかじめ合意しておきます。
仕様確定後の構築・移行に向く請負契約
請負は、合意した仕様に基づいて、システムや設定、移行作業を完成させることを目的とします。そのため、契約では成果物と検収条件を具体化しておく必要があります。
- 成果物：設計書、設定一覧、接続試験記録、移行結果。
- 運用資料：操作手順書、障害対応手順。
- 受入条件：テストケースと測定値による設定。
仕様変更のリスクを委託先が見込むため、準委任より見積が高くなる傾向があります。単価だけでなく、固定の範囲と変更時の追加料金も比べます。
認証基盤特有の責任範囲を定めた保守運用契約
保守の対象には、認証基盤の日常的な更新や障害対応、脆弱性への対応、監査作業も含めます。
- 定常作業：証明書・コネクター更新、ログ保管、権限の見直し。
- 障害対応：連携エラー、認証障害、復旧目標、夜間連絡先。
- 契約管理：脆弱性情報、定期報告、メーカー問い合わせ費、更新責任。
設定値やログの出力、契約終了時の返却と削除、移行支援も、契約に含めておきます。こうした出口を決めておくと、特定の委託先に依存しすぎるリスク（ベンダーロックイン）を抑えられます。
統合認証基盤の費用相場の目安
国内で公開されている見積データは限られるため、ここに示す金額は類似業務システム相場からの推定です（出典: NotebookLMリサーチノート、2026年8月、類似業務システム相場からの推定）。
費用は、利用者数やアプリ数、既存ADの有無、MFA方式によって変わります。加えて、レガシー改修、ログ、可用性の条件でも変わります。
移行の難しさと運用時間も金額を左右します。そのため、ライセンス料金と開発・移行・保守の料金は、分けて見積もります。
小規模な導入・部分連携の費用目安（300万〜1,500万円程度）
小規模な導入では、次の条件をもとに費用と期間を見積もります。
- 対象：主要SaaS数本、IDaaS初期設定、MFA、簡易プロビジョニング、利用者案内。
- 費用：類似業務システムの受託相場から300万〜1,500万円程度。
- 期間：一般的な計画では2〜4か月程度。
IDの重複やアプリ設定の変更が多いと、期間は延びます。さらに、ライセンスや教育、台帳整備、運用引き継ぎを含むかどうかで金額が変わるため、範囲を分けて確認します。
中規模の統合の費用目安（1,500万〜4,000万円程度）
中規模の統合について、主な対象と費用、計画期間を次に示します。
- 接続：AD・LDAP・人事をIDの正とし、SAML・OIDCで10〜30システム。
- 費用：権限設計、ログ・SIEM連携、段階移行を含め1,500万〜4,000万円程度。
- 期間：4〜9か月程度。
認証連携そのものより、アプリごとの例外への対応と権限マッピングに手間がかかります。加えて、データクレンジングや利用部門の受入テストも工数に含まれます。そのため、接続数だけでなく、アプリの難易度も見積の条件に含めます。
大規模・複雑な刷新の費用目安（4,000万円超も含む）
大規模案件では、対象範囲と必要な運用体制に応じて、次の条件を整理します。
- 対象：複数会社・拠点、数万ユーザー、オンプレミスとクラウドの混在。
- 追加要件：冗長化、特権ID、24時間監視、レガシー改修。
- 費用：上記を含む場合、4,000万円を超える可能性があります。
- 期間：要件定義から本番移行まで半年〜1年以上。
- 人月参考値：SE月額80万〜120万円、要件定義約10%、設計10〜20%、開発40〜60%、テスト10〜20%。
上の数値は、一般的な業務システム相場の目安で、個別案件の確定価格ではありません。そのため、まず全体構想と優先順位を決めておきます。
ライセンスと保守運用費の別枠での確認
ライセンスと保守運用は、費用の条件が異なるため、次のとおりに分けて比べます。
- Okta：Starter Suiteは月940円から、Essentials Suiteは月2,670円から。
- Microsoft Entra ID：ライセンスプランの確認が必要です。
- Google Cloud Identity Premium：月払い7.20米ドル/ユーザー、年払い6米ドル/ライセンスの表示です。
- 保守費：類似業務システムでは初期開発費の年5〜15%程度が試算の目安です。
- 保守対象：証明書・接続部品の更新、障害・脆弱性対応、ログ、権限の見直し、監視。
Oktaの料金は1人あたりで、年間契約が前提です（出典: Okta公式「プランと価格」、2026年確認）。上位プランや導入支援は、個別の見積になります。
1,000ユーザーなら、単純計算で月94万円または267万円からになります。ただし、税や契約条件、導入費は別途確認が必要です。対象ユーザーの範囲も、あわせて確かめます。
Microsoft Entra IDには無料版、P1、P2があり、Microsoft 365 E3・E5などに含まれる場合もあります（出典: Microsoft Learn「Microsoft Entra ライセンス」、2026年確認）。そのため、Microsoftの既存契約を調べ、同じ機能を二重に購入しないようにします。
Google Cloudについては、請求方式や為替、契約条件を含めた最新の見積を取得します。
保守作業の範囲によっては、費用が目安の割合を超える場合もあります。したがって、相場は予算枠の出発点とし、対象範囲とサービス水準を示した見積で決めます。
委託先の選定と見積比較で確認すべきポイント
製品名の多さや安さだけで決めると、判断の根拠がそろいません。そこで、同じ質問票を使って各社を比べます。
確認するのは、同規模・同業種の実績、認証・認可の設計、レガシー連携です。さらに、移行や運用の引き継ぎ、障害対応も確かめます。また、製品ベンダーと構築会社は区別して考え、設計判断と本番運用を誰が担うかを確認します。
同規模・同業種の実績の具体的な確認
導入実績は、利用者数やアプリ数だけでなく、移行や運用まで聞き取ります。
- 接続実績：AD、人事、SAML非対応システムとの連携。
- 運用実績：移行方式、保守範囲、退職者停止の自動化。
- 監査実績：案件別権限、ログの保存・検索。
法務や契約のデータを扱う場合は、アクセス停止や監査ログの経験も確かめます。さらに、可能であれば、同業種の担当者に、変更対応や障害連絡、担当者の継続性を尋ねます。
作業・成果物・前提条件に分けた見積の比較
見積の範囲の差を見つけるには、工程と条件を行ごとに比べることが必要です。
- 工程：要件定義、基本設計、詳細設定、接続、連携開発。
- 導入作業：ID移行、テスト、教育、切替、保守。
- 各行の条件：数量と単価、期間と担当、成果物と受入、前提と対象外。
アプリ連携は、標準接続と個別開発、対象外に分けてもらいます。「一式」にまとめられると、範囲の差が見えにくくなります。こうして分けておけば、安く見えた見積が実は範囲不足だったという事態を防げます。
セキュリティと契約終了後の出口の確認
SSOは認証の経路を一か所に集めるため、IdPの障害や管理者の侵害に備える必要があります。
- 認証保護：MFA、条件付きアクセス、フィッシング耐性のあるFIDO2・パスキー。
- 管理保護：管理者分離、特権IDの一時昇格、緊急用アカウント。
- 検知・復旧：SIEM連携、異常検知、停止、復旧、監査。
IPAは2025年8月の注意喚起で、同年7月に不正ログインに関する相談が144件あったと示しています（出典: IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。また、IPAは多要素認証とパスキーの利用を推奨しています。
導入の効果は、利便性だけでなく、侵害の検知や停止、復旧、監査まで含めて評価します。そのうえで、データの所在地や海外法令の適用可能性を確かめます。再委託先とログの保管者も確認します。
契約が終わるときの返却形式や削除証明、移行支援も決めておく必要があります。設定値やID台帳、ログをどの形式で返すかも、あわせて決めます。
運用の作業が見積の外にあると、初期費用が安くても、総保有コストは上がります。評価の配点には、価格に加えて、技術の適合性や移行計画を含めます。さらに、保守体制と出口戦略も評価の対象にします。
よくある質問
費用や製品から先に決めると、移行や運用の条件が抜けやすくなります。担当者が迷いやすい質問を、順に取り上げます。
統合認証基盤の外注先はどのような会社を選べばよいですか？
要件に合わせて、利用中のクラウド製品に強い導入支援会社、複数製品を扱うSIer、既存ADや業務システムの改修に強い受託開発会社から選びます。
販売実績に加えて、同規模のID移行や権限設計の経験を確認します。さらに、SAML・OIDC・SCIM連携の対応や、退職時停止、障害復旧の経験を聞きます。そのうえで、提案担当者が構築や保守にも関わるかを尋ねます。
RFPには最低限何を書けばよいですか？
最低限、利用者の区分と人数、IDの正、アプリ一覧は書いておきます。そのうえで、認証方式と必須機能、権限、ログ要件も書きます。
移行期間と切戻し、運用時間も記載します。さらに、成果物と保守体制、予算、希望時期も書き込みます。標準機能と個別開発は分けて示し、未確定の事項には代替案と追加費用の提示を求めます。
統合認証基盤の費用を抑えるにはどうすればよいですか？
費用を抑えるには、効果とリスク低減が大きい範囲から順に導入するのが有効です。
- 優先導入：管理者MFA、主要SaaSのSSO、人事連携、退職者停止。
- 範囲調整：標準接続と個別開発の分離、不要な24時間監視や過剰な冗長化の回避。
ログや緊急アクセス、権限レビューを削ると、監査や事故対応の費用が増えてしまいます。そのため、これらは慎重に決めます。
SSOにすると認証情報の被害が集中しませんか？
IdPの管理者アカウントや復旧の経路が侵害されると、影響が広がるおそれがあります。
- 認証保護：MFA、パスキー、条件付きアクセス。
- 管理保護：管理者分離、特権IDの一時利用。
- 監査・緊急対応：ログの記録と、緊急用の別経路。
上記を組み合わせても、SSOだけでゼロトラストが完成するとは言えません。そのうえで、委託先には、認証情報の保護と異常検知の方法、停止や切戻し、復旧の手順を説明してもらいます。
まとめ
発注前の対象範囲と責任分界の確認
SSO製品を選ぶ前に、利用者と接続アプリ、IDの正を整理します。そのうえで、認証と認可、ライフサイクルを固め、ログと復旧の扱いも決めておきます。委託の範囲は、既存の環境と運用体制に応じて、IDaaSの導入支援から分離発注までの中で選びます。
管理者MFAと主要SaaSからの段階導入
費用は、規模ごとの推定の幅を予算の出発点として扱います。
- 小規模な部分連携：300万〜1,500万円程度。
- 中規模の統合：1,500万〜4,000万円程度。
- 大規模で複雑な刷新：4,000万円超もあり得ます。
ライセンスと保守は別枠にします。設計や接続は、範囲ごとに見積を取ります。移行や教育も、同じ考え方で範囲を分けて見積もります。RFPには、成果物と受入条件を明記します。あわせて、前提や対象外、契約後の出口も書き込みます。
価格に加えて、実績や例外処理、セキュリティ、運用引き継ぎを比べると、続けて運用しやすい基盤を選べます。
▼全体ガイドの記事
・統合認証基盤開発の完全ガイド
▼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を創業。