統合認証基盤開発の発注/外注/依頼/委託方法について

統合認証基盤の発注・外注は、IDaaSの導入だけでなく、対象ユーザー、接続アプリ、認証方式、権限管理、移行後の運用までを要件化して委託先と合意することが成功のポイントです。

「どの会社に依頼すればよいか」「RFPに何を書けばよいか」「SaaSのライセンスと開発費はいくらか」と迷う担当者に向けて、統合認証基盤の発注形態の選び方から見積比較、契約、導入後の管理までを実務の順番に沿って解説します。

▼全体ガイドの記事
・統合認証基盤開発の完全ガイド

統合認証基盤を外注する前に押さえる全体像

統合認証基盤の発注範囲を整理する担当者

統合認証基盤とは、従業員、派遣社員、退職者、取引先などのIDと、ログイン方法、権限、認証ログを複数システムにまたがって管理する仕組みです。SSOだけを指すこともありますが、発注時には認証、認可、IDライフサイクル、監査、障害時の復旧経路まで含めてIAMの土台として定義します。

認証と認可を分けて発注範囲を定義します

認証は「利用者が誰か」を確かめる処理で、認可は「その利用者が何にアクセスできるか」を判断する処理です。たとえば法務部の担当者が契約書を閲覧できても、全社の人事情報を変更できるとは限りません。部署、役職、案件、雇用区分、委託先の有効期限を組み合わせた権限モデルを決めないままSSOだけを導入すると、ログインは一つになっても過剰権限や退職後の残存アカウントは解消されません。

SSO・MFA・IDライフサイクルを一つの運用として考えます

発注対象には、SAML 2.0やOpenID ConnectによるSSOだけでなく、MFAやパスキー、条件付きアクセス、SCIMやAPIを使ったアカウント連携を含めます。人事システムをIDの正とする場合は、入社時の作成、異動時の属性変更、休職時の停止、退職時の無効化、委託先の契約終了時の削除が自動または承認付きで実行されるかを確認します。監査担当者が誰がいつどの文書にアクセスしたか追跡できるログ設計も、文書・契約・法務領域では重要です。

IDaaS・パッケージ・個別開発を使い分けます

Microsoft Entra ID、Okta Workforce Identity、Google Cloud IdentityなどのIDaaSは、SSO、MFA、ディレクトリ、プロビジョニングを短期間で利用しやすい選択肢です。既存ADやオンプレミスネットワークを重視する場合はパッケージや自社運用型も候補になりますが、サーバー、冗長化、証明書、パッチ、監視の責任が残ります。独自の認証プロトコルをスクラッチで作るのではなく、実績のある基盤を核に、特殊な組織階層やレガシー接続、承認ワークフローだけを個別開発する形が現実的です。

統合認証基盤の発注形態はどれを選ぶべきですか?

発注形態を比較する統合認証基盤プロジェクト

発注形態は、製品を契約する相手と、設計・移行・運用を支援する相手を分けて考えると整理しやすくなります。IDaaSの販売会社だけで要件整理やレガシー改修まで担えるとは限らないため、製品ベンダー、導入支援会社、SIer、保守会社の役割をRFPで明確にします。

IDaaSの導入支援を外注する形

接続する対象がMicrosoft 365やGoogle Workspace、クラウドSaaS中心で、標準コネクターを使える場合は、IDaaSの初期設計、テナント設定、SSO接続、MFA展開、操作教育を導入支援会社へ委託できます。利用者数とアプリ数が少ない段階では、短期間で効果を確認しやすい方法です。ただし、既存ライセンスに機能が含まれるか、追加ライセンスが必要か、設定変更の所有権が誰にあるかを契約前に確認します。

SIerや受託開発会社へ一括委託する形

ADやLDAP、人事システム、電子契約サービス、VPN、SAML非対応の古い業務システムまで接続する場合は、要件定義から設計、移行、テスト、運用設計までを扱えるSIerや受託開発会社に依頼します。窓口を一本化できる一方、製品費、初期設定費、連携開発費、移行費、保守費が一つの見積書に混ざりやすくなります。再委託先、担当技術者、成果物の引き渡し範囲を確認し、作業項目を分解して提示してもらいます。

段階導入または分離発注にする形

全社の認証を一度に切り替えると、障害や設定ミスの影響範囲が広がります。まず管理者と主要SaaSのMFA・SSO、次に人事連携と自動停止、その後に重要な文書・契約システムやレガシーアプリ、最後に権限レビューと特権アクセスへ進む段階導入が有効です。2025年公開の日立情報通信エンジニアリングの事例でも、短期間構築のリスクを避けるため、新基盤、認証切替、クラウドSSO、その他システムSSOの4段階で導入しています(出典: 日立情報通信エンジニアリング導入事例、2025年)。大規模案件では、企画・要件定義を準委任で発注し、仕様確定後の構築を請負にする分離も選択肢になります。

RFPと要件整理はどのように進めますか?

RFPの要件を整理する統合認証基盤担当者

RFPは「統合認証基盤を作ってください」という依頼文ではなく、現状、目的、対象範囲、制約、成果物、評価基準をそろえて提案を比較する文書です。特定製品の機能に引っ張られないよう、実現したい業務効果を先に書き、必須要件と提案を求める要件を分けます。

現状のID台帳と接続対象を先にそろえます

まず、利用者区分ごとの人数、IDの発行元、所属属性、管理者、退職・異動の処理を一覧にします。次に、対象アプリごとに認証方式、SAMLやOIDCの対応状況、プロビジョニング方法、重要度、利用停止可能な時間帯、ログ保存期間を記録します。たとえば「1,000人・30アプリ」と書くだけでなく、SAML対応が20、OIDC対応が5、独自ログインが5、うち契約書管理が2という粒度にすると、見積の差が説明しやすくなります。

機能要件と非機能要件を具体化します

機能要件には、SSO、MFA、パスキー、条件付きアクセス、グループ連携、SCIM、退職時の自動停止、アクセスレビュー、監査ログ、SIEM連携を記載します。非機能要件には、可用性、目標復旧時間、ピーク時の認証性能、ログの保存期間、データ所在地、バックアップ、障害時のブレークグラス管理者、管理操作の二者承認を入れます。NISTが2025年8月に公開したSP 800-63-4は、本人確認、認証器、認証プロトコル、フェデレーション、プライバシーを扱うデジタルアイデンティティの参照軸です(出典: NIST SP 800-63-4、2025年)。日本の法令そのものではありませんが、認証強度と委託先の設計説明を確認する際の補助資料になります。

移行・テスト・運用の要件をRFPに含めます

認証基盤の切替では、IDの重複、メールアドレス変更、兼務、外部委託先、休職者、共有アカウントなどの例外が問題になります。RFPには、移行前のクレンジング、並行稼働の期間、切戻し条件、利用者向け案内、問い合わせ体制、受入テストの担当を明記します。特に本番障害時に使う緊急管理者経路は、通常のSSO障害で同時に使えなくならないよう、保管場所、利用承認、利用後のパスワード変更、ログ監視まで決めます。

契約形態と導入工程はどう設計しますか?

契約と工程を確認する統合認証基盤プロジェクト

統合認証基盤では、発注時点で決め切れる内容と、調査して初めて確定する内容が混在します。現状調査や要件定義まで請負契約で固定すると、未知の連携や例外処理が見つかった際に変更契約が増えます。反対に、全工程を準委任にすると成果物や完了条件が曖昧になりやすいため、工程ごとに契約と責任を設計します。

準委任契約は調査・要件定義・伴走支援に向いています

準委任は、専門家の知識や作業時間の提供を受ける契約で、現状調査、要件定義、製品選定、移行計画、運用設計のように成果を一つの完成物だけで測りにくい工程に向いています。作業時間、担当者、定例会議、報告書、判断事項、月ごとの上限を明記します。準委任だから品質保証が不要という意味ではないため、成果物のレビュー日程や、提案した設計の説明責任も合意しておきます。

請負契約は仕様確定後の構築・移行に向いています

請負は、合意した仕様に基づくシステムや設定、移行作業などの完成を目的とする契約です。設計書、設定一覧、接続試験記録、移行結果、操作手順書、障害対応手順などを成果物として列挙し、受入条件をテストケースと数値で定めます。請負は仕様変更リスクを委託先が見込むため、準委任より見積が高くなる傾向がありますが、単価だけで優劣を判断せず、何が固定され、何が変更時に別料金になるかを比較します。

保守運用契約は認証基盤特有の責任範囲を定めます

運用契約では、証明書やコネクターの更新、ID連携エラー、認証障害、脆弱性情報への対応、ログ保管、権限棚卸し、定期レポートを対象にします。24時間監視が必要か、夜間の緊急連絡先、復旧目標、メーカー問い合わせの費用、ライセンス更新の責任も確認します。設定値やログのエクスポート、契約終了時のデータ返却・削除、別会社へ移行する際の支援を契約に含めると、ベンダーロックインのリスクを抑えられます。

統合認証基盤の費用相場はいくらですか?

統合認証基盤の費用を見積もる担当者

統合認証基盤だけを対象にした国内の公開見積データは限られるため、以下はノートで整理した類似業務システムの相場からの推定レンジです(出典: 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公式では、Workforce IdentityのStarter Suiteが1ユーザー月額940円から、Essentials Suiteが2,670円からと案内されています(出典: Okta公式「プランと価格」、2026年確認)。年間契約が前提で、上位プランや導入支援は個別見積です。1,000ユーザーなら単純計算で月94万円または267万円からになりますが、税、契約条件、対象ユーザー、導入費は別です。Microsoft Entra IDは無料版、P1、P2があり、Microsoft 365 E3やE5などに含まれる場合があるため、既存契約を確認して重複購入を防ぎます(出典: Microsoft Learn「Microsoft Entra ライセンス」、2026年確認)。Google Cloudの公式比較情報では、Cloud Identity Premiumは月払い7.20米ドル/ユーザー、年払い6米ドル/ライセンスの表示がありますが、請求方式や為替、契約条件を含めて最新の見積を取得します。

保守運用費は、類似業務システムの目安として初期開発費の年5〜15%程度で試算されることがあります。認証基盤では、証明書更新、コネクター更新、障害対応、脆弱性対応、ログ保管、権限棚卸し、監視時間を含めると割合を超えることもあります。相場の数字は予算枠を作るための出発点に使い、最終的には対象範囲とサービスレベルを明記した見積で判断します。

委託先の選定と見積比較で確認すべきポイント

統合認証基盤の委託先と見積を比較する担当者

委託先は、製品名の多さや提示価格の安さだけで決めません。同規模・同業種での接続実績、認証と認可の設計力、レガシー連携、移行、運用引き継ぎ、障害対応の体制を、同じ質問票で比較します。製品ベンダーと構築会社を混同せず、誰が設計判断をし、誰が本番運用を支えるのかを確認します。

同規模・同業種の実績を具体的に確認します

実績確認では、「導入しました」という紹介だけでなく、利用者数、接続アプリ数、ADや人事との連携、SAML非対応システムへの対応、移行方式、運用開始後の保守範囲を聞きます。法務・契約データを扱う場合は、アクセス権限を案件単位で分けた経験、監査ログを保管・検索した経験、委託先や退職者のアクセス停止を自動化した経験があるかを確認します。可能なら同業種の担当者から、要件変更時の対応、障害時の連絡、担当者の継続性も聞き取ります。

見積は作業・成果物・前提条件を分解して比較します

比較表には、要件定義、基本設計、詳細設定、アプリ接続、連携開発、ID移行、テスト、教育、切替、保守を行単位で並べます。各行に数量、単価、期間、担当、成果物、受入条件、前提、対象外を記載してもらいます。「アプリ連携一式」ではなく、標準コネクターが使えるアプリ、個別開発が必要なアプリ、対象外のアプリに分けると、安い見積が実は範囲不足という事態を防げます。

セキュリティと契約終了後の出口を確認します

SSOを導入すると認証経路が集約されるため、IdPの障害や管理者アカウントの侵害時に備える必要があります。MFAだけでなく、管理者分離、条件付きアクセス、フィッシング耐性のあるFIDO2・パスキー、特権IDの一時昇格、ログのSIEM連携、緊急用アカウントを評価します。IPAは2025年8月の注意喚起で、同年7月に不正ログインに関する相談が144件寄せられたことを示し、多要素認証とパスキーの利用を推奨しています(出典: IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年)。導入効果を「ログインが楽になった」だけにせず、侵害検知、停止、復旧、監査まで評価します。

また、データ所在地、海外法令の適用可能性、再委託先、ログの保管者、契約終了時の設定値・ID台帳・ログの返却形式、削除証明、別製品へ移行する場合の支援を確認します。見積書に書かれていない運用作業が後から追加されると、初期費用が安くても総保有コストが高くなります。RFPの評価配点に、価格だけでなく技術適合性、移行計画、保守体制、出口戦略を含めます。

よくある質問

統合認証基盤の発注に関する質問に答える担当者

統合認証基盤の外注では、発注前に費用と製品だけを決めようとすると、移行や運用の条件が抜けやすくなります。ここでは、担当者が特に迷いやすい質問に、判断の基準を直接回答します。

統合認証基盤の外注先はどのような会社を選べばよいですか?

利用中のクラウド製品に強い導入支援会社、複数製品を扱うSIer、既存ADや業務システムの改修に強い受託開発会社から、要件に合う会社を選びます。製品の販売実績だけでなく、同規模のID移行、SAML・OIDC・SCIM連携、権限設計、退職時の自動停止、障害時の復旧を実際に担当したかを確認します。提案書の説明担当者が本番構築や保守にも関わるかも質問します。

RFPには最低限何を書けばよいですか?

利用者区分と人数、IDの正、接続アプリ一覧、既存認証方式、必須のSSO・MFA・プロビジョニング、権限モデル、ログ要件、移行期間、切戻し条件、運用時間、成果物、保守体制、予算と希望時期を記載します。各社が同じ条件で見積もれるよう、標準機能で実現する部分と個別開発を想定する部分を分けます。未確定の事項は未確定と明示し、提案時に代替案と追加費用を示すよう依頼します。

統合認証基盤の費用を抑えるにはどうすればよいですか?

最初に全社の機能を一度に作り込まず、管理者MFAと主要SaaSのSSO、人事連携と退職者停止など、効果とリスク低減が大きい範囲から段階導入します。標準コネクターを使えるアプリと個別開発が必要なアプリを分け、不要な24時間監視や過剰な冗長化を前提にしないことも有効です。ただし、ログ、緊急アクセス、権限レビューを削ると後から監査・事故対応の費用が増えるため、削減対象は優先順位をつけて決めます。

SSOにすると認証情報の被害が集中しませんか?

SSOは認証経路を集約するため、IdPの管理者アカウントや復旧経路が侵害されると影響が広がる可能性があります。MFA、パスキー、条件付きアクセス、管理者分離、特権IDの一時利用、監査ログ、緊急用の別経路を組み合わせて設計し、SSO導入だけでゼロトラストが完成するとは考えません。委託先には、認証情報の保護だけでなく、異常検知、停止、切戻し、復旧の手順まで説明してもらいます。

まとめ

統合認証基盤の発注計画をまとめる担当者

発注前に対象範囲と責任分界を確認します

統合認証基盤の発注・外注では、SSO製品を先に決めるのではなく、利用者、接続アプリ、IDの正、認証、認可、ライフサイクル、ログ、障害時の復旧を整理してから委託範囲を決めます。IDaaSの導入支援で足りるのか、SIerによる一括委託が必要なのか、段階導入や分離発注が適切なのかは、既存環境と運用体制によって変わります。

最初は管理者MFAと主要SaaSから段階導入します

費用は、小規模な部分連携で300万〜1,500万円程度、中規模の統合で1,500万〜4,000万円程度、大規模・複雑な刷新で4,000万円超もあり得るという推定レンジを出発点にします。ライセンス、設計・接続、移行、教育、保守を分け、RFPでは成果物、受入条件、前提、対象外、契約終了時の出口まで明記します。価格だけでなく、同規模の実績、例外処理、セキュリティ、運用引き継ぎを含めて比較すると、導入後に使い続けられる認証基盤を選びやすくなります。

▼全体ガイドの記事
・統合認証基盤開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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