IDaaS開発の発注/外注/依頼/委託方法について

IDaaSの発注は、利用者とアプリを洗い出し、RFPと受入条件を整理して、委託先を比べる順に進めると、導入後の運用まで見通しを立てやすくなります。

全体像は、IDaaS開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・IDaaS開発の完全ガイド

IDaaS発注・外注の全体像

IDaaSの導入支援を初期設定、アプリ連携、ID同期、導入後の支援に分けた図解。
設定から運用まで、委託範囲を作業ごとに見渡せます。

IDaaSは、従業員や業務委託先のIDを一元管理し、SaaSや社内システムに認証・認可を提供する基盤です。

発注側は、利用者やアクセス条件、アカウント停止のルールを、発注前に決めておく必要があります。

外注の対象範囲

IDaaSの委託では、設定だけでなく、アプリ連携や移行、テスト、教育、運用監視も対象になります。

  • 初期設定:製品環境とユーザー属性の設計から、MFAの展開まで。
  • アプリ連携:SAMLやOpenID Connectによる接続。
  • ID同期:ADや人事システムとの利用者情報の連携。
  • 導入後の支援:移行、テスト、教育、運用監視。

特に、入社・異動・退職の情報をどのシステムから受け取り、どの権限に反映するかを設計することが欠かせません。

発注前に自社で決めることと委託することの区分

責任範囲を決めておけば、委託先からの提案を社内で判断しやすくなります。

  • 自社で決める:利用者、重要アプリ、認証方式、停止目標時間。
  • 自社で決める:監査ログの保管期間と障害時の継続方針。
  • 委託できる:実装、連携設定、移行、テスト、文書作成。

従業員向けIDaaSと顧客向け認証基盤の区別

社内業務向けはWorkforce IAMとして、従業員と派遣社員のほか、業務委託先や取引先のIDを管理します。

顧客向けのCIAMは、個人情報の扱いや登録・退会の要件が、社内向けとは異なります。アクセス集中や顧客サポートの要件も違います。そのため、RFPの冒頭で対象を明記し、提案条件をそろえます。

ポイント

委託範囲に迷うときは、利用者や重要アプリ、停止目標時間など発注側で決める事項を先に固め、残りの実装や連携設定、移行、テストを委託先と切り分けて考えます。

IDaaSの発注形態の選び方

発注形態は、標準SaaSを基本にし、既存環境との連携や運用設計を専門会社へ委託すると進めやすくなります。

独自開発を検討するのは、標準機能で満たせない要件が明確な場合です。

短期導入を優先する企業向けの標準SaaS+導入支援

標準SaaSは、SSOやMFA、条件付きアクセスを提供し、ログ確認もできます。そのため、クラウド基盤の更新や運用を自社だけで抱えずに済みます。

  • Microsoft 365中心:候補はMicrosoft Entra ID。
  • 国内SaaS・メール・ファイルをまとめる:候補はHENNGE One。
  • 国内サポート・端末証明書を重視:候補はCloudGate UNOやGMOトラスト・ログインなど。

製品と導入SIerを別々に選べる場合もあるため、発注側は、製品名だけで発注先を決めず、支援範囲を確認します。

既存ADや古い業務システムとの連携を含むハイブリッド型

ADやLDAPが残る場合は、IDaaSだけで全部が自動連携するとは限りません。人事マスタや社内Webとの接続も、個別に考える必要があります。そのため、連携方式はシステムごとに選びます。

  • 標準接続:標準コネクタやSCIMの利用。
  • 個別接続:APIやエージェントの利用。
  • 認証連携:SAML、OIDC、フォーム認証の検討。

見積書には、属性変換、エラー時の再実行、停止処理を含めます。さらに、ログ追跡とネットワーク制約も対象に入れます。

特殊要件と運用責任を受け入れる場合のスクラッチ開発

独自認証基盤は、特殊な端末や閉域網、既存設備に合わせやすい方法です。独自の認証保証レベルを求める場合にも、候補になります。一方で、次の責任が自社に残ります。

  • 認証の維持:認証プロトコル、秘密鍵、MFA。
  • 運用:脆弱性修正、冗長化、災害復旧。
  • 監査:監査ログを自社で担う。

初期費用の安さだけで選ばず、標準SaaSで満たせない要件を一覧にしてから判断します。

ポイント

発注形態は、標準SaaSを基本に、既存環境との連携や運用を専門会社へ委託するかで考えます。独自開発は、標準機能で満たせない要件が明確なときに限って検討します。

RFPと要件整理の進め方

RFPに記載するID・アプリ・認証方式、認証の正本、入社・異動・退職、受入条件を並べたチェックリスト。
提案条件をそろえる材料が4つの観点に分かれています。

RFPは、業務課題と委託範囲を同じ条件で比べるための依頼書です。

利用者数やアプリ数だけを書くと、見積もりがぶれます。RFPには、認証の正本、ユーザー属性、連携方式を具体的に書いておきます。加えて、移行対象と運用分担を記載します。成果物と受入条件も、RFPに含めます。

発注側は、最初から完璧な仕様書をめざさず、MUSTとWANTを分けます。提案会社からの質問に答えるなかで、要件の内容を具体化します。

最初に行うID・アプリ・認証方式の洗い出し

まず、利用者とアプリの現状をそろえておくと、対象範囲と影響を見積もりやすくなります。

  • 利用者:従業員、派遣社員、委託先ごとの区分。
  • 共有ID:共有アカウントと管理者IDの数。
  • アプリ:部署、重要度、認証方式の記録。
  • 連携と影響:SAML・OIDC・SCIMの可否と、停止時の影響。

保有データの機密度も記録しておきます。

退職者の停止担当や目標時間が曖昧なままなら、製品比較より先に業務フローを整理すると、発注後の追加費用を抑えられます。

RFPに明記する認証の正本とライフサイクル

人事システム、AD、Entra IDのどれを入社・異動・退職情報の正本にするかを、先に決めておきます。複数の台帳を手作業で更新すると、停止漏れや権限の残存につながります。

  • 入社・異動:仮登録と異動日の権限変更。
  • 退職・契約終了:停止日と委託先の終了手続き。
  • 例外と連携:休職や再雇用、失敗時の通知先。

SCIMやAPIを使う場合は、連携の方向もRFPに明記しておきます。

PoCと受入条件を決めてからの本番移行

パイロットには、代表ユーザー20〜50人と、重要度の異なる3〜5アプリを含めます。社内外の端末を使い、通常時と異常時を検証します。

  • 認証操作:SSO、MFA再登録、アカウントロックの試験。
  • 変更と障害:属性変更、連携エラー、IdP障害の場合の動き。
  • 復旧:端末紛失と緊急用アカウントによる復旧。

受入条件には、テストの合格と未解決障害の扱いを含めます。加えて、マニュアル、運用引継ぎ、ログ確認方法も条件に入れます。

ポイント

迷ったときは、利用者数やアプリ数の記載にとどまらず、認証の正本や連携方式まで要件が書けているかで判断します。MUSTとWANTの区別も、提案を比べる材料になります。

契約形態と委託先の選び方

契約をSaaS利用、導入・連携支援、運用保守に分けておくと、比べやすくなります。

一社に依頼する場合でも、製品料金と設定・開発・運用費を明細にしてもらいます。

委託先の実装力に加えて、認証情報の取扱体制と障害連絡を確認します。

再委託や契約終了時のデータ返却も、確認対象です。

成果物と変更の多さで分ける準委任と請負

要件が固まっていない調査や運用設計は、作業の進行を委ねる準委任が候補になります。一方、仕様と成果物を定義できる設定や開発は、完成責任を明確にする請負を検討できます。

  • 準委任:要件調査や設計など、変更が多い作業。
  • 請負:成果物と完了条件を明確にできる作業。

工程ごとに契約を分けるケースもあります。契約類型の名称だけでなく、成果物と検収条件を確認します。また、変更手続きと責任範囲も見ておきます。

製品ベンダーと導入支援会社の役割の確認

製品ベンダーは、ロードマップや標準機能、サービスの可用性に強みがあります。

サポートと価格体系も、製品ベンダーの得意とするところです。

導入支援会社やSIerは、既存システム調査や要件定義、連携設計を担うことが多いです。移行や教育、運用代行も、支援の範囲に入ることがあります。

候補会社には、営業資料の説明だけでなく、実行体制を確かめる質問をします。

  • 類似事例:同規模でAD・人事連携を行った事例。
  • 開発の切り分け:標準機能と個別開発の切り分け方。
  • 障害対応:障害時の一次対応の担当者。
  • 担当交代:担当者が交代した場合の引継ぎ方法。

製品ベンダーと導入支援会社の責任範囲は、RFPと契約に明記しておきます。

セキュリティと契約終了時の条件

委託先との契約では、アクセス管理から契約終了までの条件を整理しておきます。

  • アクセス管理:作業権限、MFA、操作ログ、作業承認、接続元制限、秘密情報の保管方法。
  • 契約中:再委託先、データ保管地域、監査対応、インシデント通知、ログの扱い。
  • 契約終了:データ返却とアカウント停止の手順、解約後の移行支援。

IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、重要情報の委託先管理を扱っています。

事故が起きたときに委託元の管理責任が問われ得る点も、説明されています(出典: IPA、2026年7月更新)。

IDaaS発注の費用相場と見積比較のポイント

小規模30万〜150万円、中規模100万〜500万円、大規模500万〜1,500万円のIDaaS導入・連携費レンジを比べる横棒図。
規模が上がると、費用レンジの幅も大きくなります。

IDaaSの費用は、ライセンスと初期設定、アプリ連携を軸に考えます。

IDデータ移行と運用設計は別の費目として扱い、教育と保守も内訳に含めて見ます。

ここで示す金額は、公開ライセンス価格や一般的な連携工数、調査結果をもとにした編集部の推定です。特定企業の確定見積ではありません。

金額は、ユーザー数やアプリ数、既存ADの状態で変わります。休日切替やログ要件、サポート時間も影響します。そのため、金額はレンジとして比べます。

公開価格は、条件をそろえるための比較材料になります。

比較の起点となる公開ライセンス価格

2026年8月の公式サイト表示例では、プランごとに価格単位や契約条件が異なります。

  • Microsoft Entra ID P1:899円/ユーザー/月相当、年払い・税別(出典: Microsoft公式料金、2026年)。
  • HENNGE One Identity Edition:300円〜/月(出典: HENNGE公式料金、2026年)。
  • GMOトラスト・ログイン SSOプロ+SaaS管理:500円/ID/月、税別・12か月契約(出典: GMO公式料金、2026年)。

実額は、既存のMicrosoft 365契約への包含や最低契約ID数によって変わり、年払いの条件やオプション、代理店経由の価格でも変わります。

比較では、単価だけでなく、対象ID数を掛けた年間費用と契約条件を並べて比べます。

導入費も、利用者数や連携対象、移行・運用の範囲で変わります。このため、ライセンスと導入費を分けて見積もり、期間や前提条件も確認します。

規模別のレンジで見る導入・連携費

規模ごとに人数や連携範囲をそろえて見ると、導入費と期間の幅を比べられます。

  • 小規模:30〜100人、SaaS3〜5個。30万〜150万円、1〜2か月が目安です。
  • 中規模:100〜500人、SaaS5〜15個。100万〜500万円、2〜4か月程度です。
  • 大規模:500〜3,000人、多拠点や社内Webを含み、500万〜1,500万円、4〜9か月まで広がります。

小規模は人事連携が少ない構成で、中規模はAD・人事連携と段階移行を含む構成です。

大規模では、例外処理も増えます。

公開相場は統一されていないため、金額は個別見積もりの前提条件と合わせて扱います。

ライセンス・開発・運用を分けて比べる3年TCO

初年度だけでなく、3年間の総保有コストで比べます。

費目をそろえておくと、提案ごとの差が見えやすくなります。

  • 初期費:初期設定、連携開発、データ移行。
  • 利用・追加費:ライセンス、アプリ登録、MFA端末や証明書。
  • 運用費:監視、ヘルプデスク、更新、障害支援。
  • 契約費:比較対象の契約更新費。

100人規模でも、既存契約の包含条件や最低ID数があるため、単価に100を掛けただけで予算を決めないようにします。

ポイント

判断に迷ったら、各社の金額が同じ対象ID数と契約条件で出ているかを先に確かめます。金額の大小は、その後に比べます。

委託先の選定と見積比較で失敗しないためのポイント

委託先は、価格だけでなく、安全な移行と運用引継ぎの実現性で選びます。

同じRFPを3〜5社に渡し、質問への回答は各社に共有します。

同じ課題を解いた実績の評価

評価表では、要件適合や実績、体制を確認します。移行やセキュリティ、運用支援も見ます。費用と契約条件も、評価に含めます。点数に表れない懸念は、別に記録します。

  • 規模と方式:同規模の利用者や認証方式の経験。
  • 既存環境:AD、人事連携、複数拠点の経験。
  • 運用実績:導入前の課題、移行後の問い合わせや停止時間の変化、内製化できた運用の聞き取り。

HENNGEの公式事例では、日本ハムが100超のシステムをSSO化し、問い合わせを10分の1にしたと紹介されています。同じ効果が出るかどうかは、自社のアプリと運用条件に照らして検証します。

見積書の作業単位と除外条件の読み解き

たとえば、「環境構築一式」のような表記を見るときは、作業量と対象範囲を確認します。

  • 対象量:アプリ数、利用者数、属性項目。
  • 作業内容:テスト、会議、現地作業、休日対応。
  • 成果物:文書、教育、追加変更の単価。

要件定義や受入テストが除外されると、追加費用が生じます。切戻しや運用設計、障害対応が除外された場合は、社内負担につながります。運用移管や監査資料まで含む提案は、3年TCOで妥当性を比べます。

提案に必ず含めるIdP障害と切戻し

IdPの停止や管理者侵害は、SSOで接続した複数のシステムに波及する可能性があります。そのため、復旧と代替手段を委託先と決めておきます。

  • 緊急認証:ブレークグラス用と別経路の管理者認証の用意。
  • 障害対応:バックアップ、ログ監視、連絡手順。
  • 切戻し:直接ログインへ戻す方法。

MFAやパスワードレスの再登録、端末紛失にも備えておきます。

対応できない場合は、業務停止やサポート負荷につながります。

NIST SP 800-63-4は、本人確認や認証器、認証プロトコルの技術要件を整理した指針で、フェデレーションも扱っています。

2025年8月1日に公開されました(出典: NIST、2025年)。

日本企業の法的義務を直接定めるものではありませんが、認証強度や連携方式を検討する際の技術的な参照資料になります。

国内では、業種別指針や委託先管理、契約上のデータの所在も確認します。

ポイント

迷ったときは、障害対応や担当交代への答えが具体的かで、各社の実行体制を比べます。見積額だけで比べると、含まれる作業の差を見落としかねません。

よくある質問

IDaaSの発注では費用や機能に加えて、既存環境との接続や導入後の責任分担も確認します。

IDaaSの発注費用は最低いくらからですか?

一律の最低額はありません。たとえば、公開ライセンスには1ユーザーあたり月数百円から1,000円前後の例があります。

契約には、最低契約ID数や年契約があり、初期設定・連携・移行・教育は別料金の場合があります。

小規模の導入費は30万〜150万円程度を検討レンジとし、複数社へ見積もりを依頼します。

既存のActive DirectoryがあってもIDaaSを導入できますか?

導入できる可能性はあります。その前に、同期方式と認証の正本を確かめ、ネットワーク経路と属性の対応も確認します。

既存のADを残すか移すか、認証の正本をどこに置くかで、方式は大きく3つに分かれます。

  • 並行運用:ADを残したまま、クラウドIdPと連携する方法。
  • 段階移行:Entra IDへ段階的に移行する方法。
  • 人事起点:人事システムを正本にする方法。

適切な方式は社内の運用ルールで変わるため、RFPには、ADのバージョンとドメイン構成を記載します。加えて、グループ数や同期対象、停止時の扱いも書き添えます。

IDaaSは自社開発と外注のどちらがよいですか?

一般的な従業員認証では、標準SaaSを採用し、要件定義や連携を外注する方法が候補です。

移行や運用設計を委ねることも、検討の対象になります。

自社開発は、特殊要件があり、認証技術やセキュリティ、可用性を担える場合に比べます。脆弱性対応と24時間運用を担えるかも、比較の前提になります。保守・監査・障害対応の3〜5年分の費用と人材も含めます。

委託先へ見積もりを依頼するとき何を渡せばよいですか?

利用者・アプリ一覧や認証方式、ADや人事システムの構成を渡します。加えて、対象範囲とMUSTとWANTも渡します。

移行希望時期と運用体制、セキュリティ条件も伝えます。予算レンジも、あわせて伝えます。

資料がそろわない場合は、現状調査と要件定義を先行させ、調査後に本導入を再見積もりする方法もあります。工程は、調査や設計、設定、連携に分けて依頼します。また、テストや移行、教育、運用引継ぎも、別の工程として依頼します。

まとめ

IDaaSの発注では、製品価格やSSO機能だけでなく、利用者と認証の正本を整理します。AD・人事連携と退職時の停止を確かめ、障害時の切戻しと運用責任も決めておきます。

標準SaaSを基本に、必要な個別開発を切り出すと、費用とリスクを見通せます。

発注前に確認する項目の一覧

発注前に対象と条件を整理しておくと、見積もりと成果物を照らして判断できます。

  • 要件:対象ユーザー、アプリ、MUST・WANT、認証の正本。
  • 導入:連携方式、MFA、PoC、受入条件。
  • 費用:ライセンス、初期費用、3年TCO。
  • 委託:作業権限、再委託、データ返却、障害対応。

見積額だけでなく、金額に含まれる成果物と運用状態を説明できる会社を選びます。

導入後の運用まで含めたIDaaSの成果評価

IDaaSの成果は、ログインの効率だけでなく、導入後の運用で測ります。退職者の停止漏れの減少と権限の定期見直しで評価します。認証ログの監査活用や情シスの管理時間の削減も、評価の対象です。

運用KPIや定例レビューを委託先と決めておくと、安全性と業務効率を改善しやすくなります。障害訓練と契約更新の基準も、あわせて決めておきます。

▼全体ガイドの記事
・IDaaS開発の完全ガイド

会社紹介

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

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

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

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

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

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