ID管理システム開発の発注/外注/依頼/委託方法について

ID管理システムの発注は、IDの棚卸し、要件整理とRFP作成、小規模なPoC、段階移行の順で進めると、安全に運用へつなげられます。

発注形態や要件と契約、費用相場、委託先の選び方を、この順で見ていきます。全体像は、ID管理システム開発の完全ガイドでも確認できます。

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

ID管理システムの発注・外注に入る前の準備

製品名や月額料金から比べると、連携開発や運用設計の不足が導入後に分かることがあります。そのため、先に対象と課題、既存システムとの接続条件を整理し、発注範囲と見積条件をそろえておきます。

従業員ID・顧客ID・特権IDの切り分け

対象ごとに管理の目的が異なるため、まずは利用者や権限の種類で分けて考えます。

  • 従業員・関係者:派遣社員や取引先などを含むIDを、Workforce IAMで扱います。
  • 顧客・会員:ID管理の仕組みとして、CIAMを使う対象です。
  • 管理者・権限:強い権限を対象にする場合はPAM、申請や定期レビューまで扱う場合はIGAを検討します。

顧客向けの大量アクセス対策と従業員の退職時の即時停止を一緒に扱うと、RFPの要件が不明確になります。

製品探しより前の現状IDの棚卸し

棚卸しでは、利用中のシステムとIDの管理状況を合わせて記録します。

  • 確認するシステム:人事システム、Active Directory、LDAP、Microsoft 365。
  • 連携先:Google Workspace、業務SaaS、VPN、オンプレミスアプリ。
  • 記録する情報:正のマスター、認証方式、管理者、権限、退職時の停止方法、ログ保管期間。
  • 見落としやすいID:未使用ID、共有アカウント、委託先の期限切れID。

棚卸しの結果があれば、導入効果と移行工数を現実的に見積もれます。

ポイント

製品を探す前に、対象にするIDの種類と既存システムとの接続条件を整理できているかが、導入後の手作業を減らす目安になります。

ID管理システムの発注形態の選び方

発注形態には、自社でクラウドIDaaSを設定する方法と、SIerに導入支援を委託する方法があります。また、運用までマネージドサービスに任せる方法や、特殊な要件だけを自社で開発する方法もあります。特に、従業員のSSOやMFAを早く導入したい場合は、標準機能を使い、独自開発を最小限にする方法が現実的です。

クラウドIDaaSを自社主体で導入する方法

Microsoft Entra ID、Okta、HENNGE Oneなどを契約し、情シスがテナント設定やSAML連携を進めます。また、初期費用を抑えやすく、標準プロトコルに対応したSaaSから段階的に始められます。

ただし、人事データの整形やSCIM・API連携を、自社で担えるかを確認します。加えて、例外的なオンプレミスアプリの接続と障害時の運用設計も、社内で受け持てるかを見極めます。

製品選定・設計・移行をSIerへ委託する方法

SIerや導入支援会社には、現状調査から教育までの作業を一括で依頼できます。その中には、製品選定や基本設計、データ移行などが含まれます。特に、IAMの専門人材が少ない企業でも、既存のADや人事システムを含めて設計しやすい方法です。

製品販売会社か、第三者製品も比較して設計できる会社かを見分けます。特定の製品だけを前提にした提案になっていないかも、確かめておきます。

運用監視までマネージドサービスへ任せる方法

24時間監視から障害時の一次対応まで、運用作業を外部へ委託できます。対象には、アカウント申請の受付やログ確認、定期アクセスレビューも含まれます。なかでも、少人数の情シスや複数の会社を抱える企業では、導入後の定常業務を減らせる可能性があります。

月額料金とあわせて、対応時間や対象範囲を確認します。緊急連絡経路と作業記録も、契約前に見ておきます。また、契約が終わるときの設定情報とデータの返却方法は、契約書に明記しておきます。

ポイント

社内で設定や運用まで担えるか、特殊な要件があるかを基準にすると、自社主体、SIer委託、マネージドサービスのどれが合うかを絞り込めます。

ID管理システムの発注・外注の進め方と手順

現状調査、初期範囲の決定、PoC、段階移行と運用引き継ぎを順につないだ図解。
小さく検証してから対象を広げる順序が見て取れます。

発注後は、対象を絞った検証でログイン体験と連携の確実性を確かめてから、本番に展開します。全社の認証を一度に切り替えないよう、段階的に進めることが大切です。

  1. 現状を調査する
  2. 要件を整理する
  3. RFPを配布する
  4. 提案を比較する
  5. 契約する
  6. PoCを行う
  7. 設計・移行する
  8. 段階的にリリースする
  9. 運用を引き継ぐ

現状調査でのID・権限・連携先の一覧化

利用者の種類や人数、所属を一覧にします。雇用区分や契約期間、利用アプリも、同じ一覧に加えます。権限ロール、認証方式、管理者もあわせて押さえます。また、入社をJoiner、異動をMover、退職や契約終了をLeaverとして整理します。

人事情報がID管理基盤に届く時点と、権限に反映される時点を確認します。退職者の即時停止や委託先の期限切れを見落とすと、導入後も手作業が残ります。共有アカウントやサービス連携用の非人間IDも、洗い出しから抜けやすい対象です。

MUSTとWANTの切り分けによる初期範囲の決定

初回リリースの範囲を決めるため、導入時に必須の要件と追加候補を分けます。

  • MUST:退職時のアカウント停止、管理者へのMFA、SSO、認証ログ、管理者操作ログ、権限分離、人事マスター連携。
  • WANT:高度なリスク判定、追加自動化、AI分析、複雑な属性ベース認可。

すべてを初回リリースに含めると、設計とテストが膨らみ、現場が使いこなしにくくなります。

小さな対象でのPoCと切替条件の検証

検証範囲は、接続先と認証・連携上の確認項目を基準に決めます。

  • 対象アプリ:Microsoft 365やGoogle Workspace、主要SaaS、VPN、代表的なオンプレミスアプリの中から数本。
  • 検証項目:SSO、MFA、条件付きアクセス、プロビジョニング、ログ、障害時の迂回。

新しいCIAMの例では、日本精工が約半年のテストを経て段階移行を予定しています(出典: Microsoft Customer Stories、日本精工の事例、2025年)。また、新製品や新しい連携方式を使う場合は、業務データとサポート対応も確かめます。

段階移行と運用引き継ぎを含めた契約範囲

部門やアプリ単位で展開します。そのうえで、旧認証の停止日や問い合わせ窓口、利用者案内を決めます。さらに、ブレークグラス用管理者、バックアップ、手動復旧手順も定めておきます。

設計書や連携一覧、設定値など、導入会社から受け取った資料を、自社で読める状態にします。また、未使用IDの削除とアクセスレビューを定例化し、安全に運用できる時点を完了と定義します。

ポイント

現状の一覧化とMUSTの絞り込みを済ませ、PoCで接続と認証の動きを確かめてから段階的に広げるかどうかが、移行の失敗を左右します。

RFP・要件整理で決める内容

RFPに記載する対象範囲、認証方式と正のマスター、納品物・テスト・運用条件を並べた4項目の図解。
提案依頼前にそろえる論点を4つのまとまりで確認できます。

RFPは、対象や課題、必須要件、連携方式などを同じ条件で示し、各社の提案を比べられるようにする文書です。「ID管理システムを作ってください」とだけ伝えると、各社の前提が食い違い、提案を比べられなくなります。見積内訳や評価基準、体制、日程まで書いておくと、提案の違いが読み取れます。

対象ユーザーとシステム境界の明記

従業員、派遣社員、取引先、顧客の対象範囲を記載します。利用者数と増加見込み、国内外の拠点を書きます。対応言語や対象アプリ数も、あわせて記します。

顧客IDでは、会員登録やソーシャルログイン、同意の管理を記載します。退会とデータ削除、パスワードリセット、大量アクセスのピークも、示しておきます。

従業員IDでは、雇用区分や所属・役職、契約の開始日と終了日を明確にします。加えて、端末条件と、管理者権限の承認者もはっきりさせます。

SAML・OIDC・SCIM・APIと正のマスターの指定

アプリごとに認証方式を、SAML 2.0、OpenID Connect、OAuth 2.0から決めます。アカウント連携にはSCIM、API、CSVのどれを使うかも整理します。

社員番号やメールアドレスなどの一意キーと、所属・役職・雇用区分・役割コードを定義します。人事システムとディレクトリのどちらを正のマスターにするかも決めます。

連携先の仕様が不明な場合は、「対応予定」とせず、検証方法と追加費用の扱いまでRFPに記載します。

納品物・テスト・運用条件の先行定義

要件定義書や基本設計書、連携仕様書などは、納品物として定めておきます。移行計画やテストの計画と結果、操作手順書、復旧手順、管理者教育も含めます。

テストには、正常ログインのほか、退職時の即時停止や異動後の権限変更を含めます。さらに、MFA再登録、同期失敗、認証基盤の停止、管理者アカウントのロックも対象にします。

ログの保管期間や監査レポートは、契約前に確認します。サポート時間やサービスレベルも、契約前に確かめます。

ポイント

対象、認証と正のマスター、連携方式、納品物、運用条件を、各社が同じ前提で答えられる水準まで書けているかが判断の目安になります。

ID管理システムの契約形態の選び方

製品の利用契約と、導入・連携・運用の委託契約は、別になることが多くあります。要件定義は作業の不確実性が高い一方で、設計や設定は、何を納めるかを明確にしやすい作業です。そのため、フェーズごとに責任と検収を整理すると、追加費用や品質の認識違いを抑えられます。

要件整理・アセスメントに適した準委任契約

現状調査や課題整理、製品比較は、企業ごとに前提が異なります。ワークショップや基本方針の策定も、前提によって中身が変わります。作業時間や論点を固定しにくいため、専門家の助言や作業時間に対価を払う準委任契約が適する場合があります。

作業時間に加えて、会議の回数や参加者を明確にします。調査対象や提出物、報告形式も、あらかじめ決めておきます。

設計・設定・移行の請負契約の比較

要件が固まり、連携設定やデータ移行、テスト環境の構築など完成条件を定義できる作業は、請負契約として比較しやすくなります。

認証基盤の切替では、相手先アプリの仕様変更やデータ不備など、発注者だけで制御できない要因もあります。

請負にする場合は、前提や対象外の作業を契約書と仕様書に記載します。仕様変更の手続き、検収基準、瑕疵対応の範囲も、あわせて書きます。

運用・ライセンス・移行条件の別紙による固定

運用監視や申請受付を委託する場合は、月額の対象作業と対応時間を仕様書に書きます。問い合わせ上限やインシデント連絡、定例報告、アクセスレビューの頻度も、あわせて記載します。

IDaaSには、年契約や最低契約額が設定される場合があります。利用者の増減や、休職者・外部利用者の数え方を確認します。オプションの扱いや、更新時の価格改定も確かめます。

終了時の返却形式を確認します。設定情報やログ、監査証跡、ユーザーデータが対象になります。他製品へ移行できるかも、発注前に確かめます。

ID管理システムの費用相場とコストの内訳

小規模、中規模、大規模のID管理システム初期費用の目安を横棒で比べた図解。
規模が上がるにつれて費用レンジも大きく広がります。

総費用は、ライセンスと初期アセスメント、要件定義・設計、連携開発に分かれます。データ整理と移行、教育、運用監視、ログ保管も、総費用に含まれます。公開価格は、比較の起点と考えるのが無難です。

連携本数や既存データの状態によって導入費は変わるため、次に示す金額は、見積前提を置いた目安です。

公開ライセンス料金の幅(月額300円台〜数千円)

2026年8月確認の公式価格を比べると、製品によって月額料金に幅があります。

  • Microsoft Entra ID P1:ユーザーあたり月額899円相当の年払い。
  • Okta Workforce Identity:Starterは月額940円から、Essentialsは月額2,670円から。
  • HENNGE One Identity Edition:月額300円から。
  • 100人の場合:月3万円台〜27万円程度、年36万円台〜324万円程度。

価格は各公式ページの情報です(出典: Microsoft、Okta、HENNGEの各公式価格ページ、2026年8月確認)。

既存のMicrosoft 365プランや最低契約数、オプションによって、料金は変わります。さらに、二重契約になっていないかも確かめます。

初期導入費の規模と連携による試算

利用規模と連携範囲をそろえて比べると、初期費用と期間の目安を把握できます。

  • 小規模:50〜150人、SaaS 5〜15個。初期50万〜250万円、1〜2か月。
  • 中規模:200〜1,000人、AD・人事システム・SaaSが20〜100個。初期300万〜1,000万円、3〜6か月。
  • 大規模:複数社・海外拠点など。初期1,000万〜5,000万円以上、6〜18か月。

小規模は標準設定と数本のSAML連携、MFA・SSO中心の推定です。中規模はAD・人事システム・SaaSとの連携を含みます。

中規模ではJoiner/Mover/Leaverの自動化や段階移行を含む場合があります。大規模では、IGA、PAM、CIAMや、複雑な基幹連携、24時間運用を含むこともあります。

富士通の統合認証アセスメントは、課題整理とToBe像の提示を含み、公式価格は150万円からです(出典: 富士通「LDAP Manager 価格」、2026年8月確認)。なお、上に挙げた金額は、公開価格と一般的な連携・移行工数から試算したもので、公的な相場ではありません。

運用費と将来の変更費を含めたTCOによる判断

ランニング費には、IDaaSの利用料や運用監視、ヘルプデスクが含まれます。さらに、ログ保管やアプリ追加連携、ユーザー増加に伴う費用が入ります。端末交換や証明書更新、教育、監査対応も、ランニング費の対象です。

初期費用が安くても、アプリ追加が高額で設定情報も戻らない契約では、数年後のTCOが膨らみます。3年程度の利用期間を仮置きし、初期費用、毎年の費用、更新・移行費を合算します。

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

委託先は、認証や認可、IDのライフサイクル、監査を一つの運用として設計できるかで比べます。そのうえで、RFPの評価項目を先に決め、価格、実績、体制に加え、標準化やサポート、終了時の移行性も総合的に評価します。

同規模・同業種のIAM実績の具体的な確認

実績を比べる際は、匿名化できる範囲で具体的な規模や対応内容を確認します。

  • 確認項目:利用者数、アプリ数、AD・人事連携、移行期間、運用体制、障害対応。
  • J:COMの導入:4つの基幹システムの認証をOktaへ統合。
  • 開発期間:認証・ログ機能は従来の5〜6か月から2〜3か月に短縮。
  • 運用工数:認証関連は月20数時間程度からほぼゼロに。

上記はOkta公式顧客事例で紹介された内容です(出典: Okta公式顧客事例、2026年8月確認)。ただし、一社の事例なので、期間や運用効果を質問する材料になります。

作業・数量・前提に分けた見積の比較

見積は、アセスメントや要件定義、基本設計、テナント設定、アプリ連携などの作業ごとに分けてもらいます。SCIM・API開発やデータ整理、移行も、同じ粒度で示してもらいます。そのほか、次の作業も見積に含めてもらいます。

  • テスト
  • 教育
  • 運用設計
  • 保守

連携本数やユーザー数、環境数、移行データ件数を、見積の前提として確認します。会議回数や期間、担当者数も、あわせて聞いておきます。特に、「一式」が多い場合は、含まれる作業と追加費用になる作業を質問します。

セキュリティとサポートの責任範囲の確認

サービス提供者の障害と導入会社が設定した連携の不具合について、連絡先と一次切り分けの担当を確認します。また、緊急時の対応時間も決めておきます。

MFA情報や管理者アカウント、ログ、バックアップ、特権操作の記録は、誰が閲覧できるかを確認します。個人情報を扱う場合は、再委託や保管場所、漏えい時の報告まで確かめます。アクセス制御と終了後の消去も、見ておきます。

IPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版は、最新環境を踏まえた実践的な対策を示しています(出典: IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年)。

標準プロトコルとベンダーロックイン回避の評価

SAML、OIDC、OAuth、SCIM、FIDO2・WebAuthnなどの標準を使い、独自仕様への依存を最小限に抑えます。移行時には、ユーザー属性やグループ、権限、監査ログを、どう持ち出せるかも聞いておきます。

設定書の所有者や、APIやエクスポートの有無を確認します。契約期間中の価格改定や最低利用数、解約予告も聞いておきます。データ削除証明や、支援会社を変えるときの引き継ぎ費用も確かめます。

そのため、初年度料金の安さに引っ張られにくくなります。

ポイント

価格だけで選ぶと、障害時の責任範囲や契約終了時の情報返却で後から差が出るため、見積の内訳と終了時の条件まで比べるのが目安です。

よくある質問(FAQ)

製品の選定や自社開発、外注範囲の決め方では、迷いが生じがちです。初期検討で多い疑問について、費用と実装範囲を分けて答えます。

ID管理システムは自社開発と外注のどちらがよいですか?

SSO、MFA、標準的なライフサイクル管理なら、既製IDaaSを導入し、設計・連携・移行を外注する方法が検討しやすいです。

顧客固有の認可や会員体験が差別化要件になる場合でも、認証、パスワード保管、MFAの中核には既製基盤を使います。独自開発を業務ロジックに限定すると、脆弱性対応と規格変更の負担を抑えられます。

小規模企業のID管理システム導入費はいくらですか?

50〜150人、SaaS 5〜15個、標準SSO・MFAと数本の連携なら、初期50万〜250万円程度、期間1〜2か月程度という推定レンジがあります。

ライセンスは製品と既存契約で異なります。また、初期設定やデータ整理、運用設計、教育、ログ保管が別費用になる場合もあります。

見積では対象アプリ数と人事連携の有無を伝え、ライセンスと導入作業を分けてもらいます。

RFPを作れない段階でも発注先へ相談できますか?

相談できます。その際は、本番導入を一括で見積もるより、現状調査やアセスメントを小さな契約で依頼する方法が適しています。

対象ユーザーや困っている業務、既存システムを共有すると、調査範囲や進め方を提案しやすくなります。想定時期と予算上限も伝えておくと、より具体的に組み立てられます。調査の後にMUSTとWANTを固め、同じRFPで複数社へ依頼します。

ID管理システムの発注で失敗しやすい点は何ですか?

失敗しやすいのは、月額ライセンスだけを比べて、連携開発や運用監視を見落とすケースです。データ整理やログ保管、教育、将来のアプリ追加も、抜けやすい項目です。

退職時の即時停止や権限レビューを要件に入れないまま、SSOだけを導入すると、手作業が残ることもあります。例外処理や障害時の迂回、終了時のデータ返却について発注先に質問し、その内容を納品物と検収基準に反映します。

まとめ

ID管理システムの発注では、従業員ID、顧客ID、特権IDを分けたうえで、利用者とアプリ、権限、認証方式、退職時の処理を棚卸しします。そのうえで、IDaaS、SIer、マネージドサービス、限定的な自社開発を、要件と運用体制に合わせて選びます。

発注前に押さえるべき要点

RFPには、MUST・WANTや正のマスター、連携条件を記載します。ログ・監査やPoCの合格基準、納品物、どこまでを誰が受け持つかも、あわせて書きます。

見積は、ライセンスと初期導入費を分けたうえで、連携や移行、教育、運用、将来の変更を含むTCOで比べます。価格に加えて、実績や障害支援、情報返却、ロックイン回避も評価します。

次に行うこと

現状把握から委託先との継続計画まで、順を追って進めます。

  1. 利用中のIDとアプリを一覧にし、退職者や委託先のアカウント停止日数を確認します。
  2. 対象を絞ったアセスメントやPoCを依頼し、3社程度から同条件で提案と見積を取得します。
  3. アクセスレビューと運用改善を含めた継続計画を、委託先と立てます。

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

会社紹介

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

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

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

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

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

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