ID管理システムの開発は、現状のIDと権限を洗い出し、要件を整理するところから始めます。そのうえで、製品や開発会社の選定、設計・開発、テスト、段階的な稼働、定着の六つのフェーズを順に進めます。
各フェーズを省かずに進めると、入社・異動・退職に伴う管理を一貫させられます。
▼全体ガイドの記事
・ID管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ID管理システム開発の全体像
ID管理システムは、従業員、派遣社員、取引先、顧客、サービスアカウントといったIDを一つにまとめて管理します。管理の対象には、認証や権限付与、アカウントの作成・変更・停止が含まれます。さらに、アクセス履歴や権限の棚卸しも対象になります。
全体設計は、標準サービスで足りる範囲と連携開発が必要な範囲を分けるところから始まります。
IAM・IDaaS・IGA・PAM・CIAMの違い
ID管理で比べる分類は、利用者や管理対象によって違います。まず対象となるIDの種類を見極めると、比較対象と必要な機能を絞り込めます。
- IAM：IDとアクセス権限を管理する考え方の総称。
- IDaaS：認証・SSO・MFAなどをクラウドで提供する仕組み。
- IGA・PAM：権限レビューや特権IDの保護を担う領域。
- CIAM：顧客・会員向けID基盤で、従業員向けIAMとは要件が異なる。
IGAでは、権限の申請・承認も管理します。一方で、CIAMでは利用者数、ログイン体験、同意管理、退会・データ削除が論点になります。
分類せずに製品を探すと、従業員向けの製品を顧客会員基盤に使ってしまう誤りが起きます。また、SSOだけで権限レビューもできると思い込むこともあります。
開発前に整理する主要機能
機能を整理する際は、IDの登録から停止までの管理範囲と認証連携を確かめます。そのうえで、サービスアカウントやAPIキーを対象に含めるかも決めます。
- ID管理：ディレクトリとアカウントのライフサイクル管理。
- 認証・認可：SSO、MFA・パスキー、アクセス制御。
- 連携・監査：プロビジョニング、ログ・監査。
人事システムを正のマスター（元となるデータ）にします。そのうえで、社員番号、メールアドレス、所属を連携します。役職、雇用区分、契約開始日・終了日も、連携する項目に含めます。
人事システムと連携させると、入社（Joiner）、異動（Mover）、退職（Leaver）の処理を自動化しやすくなります。
連携方式には、SAML 2.0、OpenID Connect、OAuth 2.0、SCIM、API、CSVなどがあります。そのうちSAMLとOpenID Connectは認証連携に使われ、SCIMはユーザーやグループの作成・更新・停止に使われます。さらに、管理者権限にPAMを適用するかも、設計の初期に決めておく必要があります。
ID管理システムの進め方
開発は現状の調査から始め、六つのフェーズごとに成果物と判断基準を決めていきます。製品を先に決めてしまうと、既存業務やデータの問題が後になって見つかることがあります。
- 要件整理と現状棚卸し
- 製品・開発会社の選定
- 設計・開発とデータ整備
- テストと移行リハーサル
- 稼働と段階移行
- 定着・改善運用
小規模な会社でも、フェーズは省かず、成果物の規模を小さくして進めます。
フェーズ1：要件整理と現状棚卸し
現状の棚卸しと要件整理では、次の四つの項目を順にまとめます。
- 現状：利用者、対象システム、認証方式、権限付与者、退職時の停止方法、ログの保管場所と期間。
- 台帳：システム名、所有部門、利用者区分、ID発行元、認証方式、権限単位、連携方式、停止までの時間、管理者、ログ確認者。
- MUST：退職時の即時停止、管理者の多要素認証、監査ログ、既存AD・人事システムとの連携。
- 優先順位と成果物：SHOULD・WANTを分類し、課題一覧、対象範囲、優先順位表、業務フロー、非機能要件、概算日程を作成。
Excelや個別管理画面に分散した情報を、一つの棚卸し表に集めるだけでも、重複ID、休眠ID、共有アカウント、過剰権限が見つかります。
高度なリスク判定や追加の自動化は、WANT（あれば望ましい要件）として扱えます。初回リリースに含めるか、別のフェーズに回すかを判断します。
フェーズ2：製品・開発会社の選定
選定では、IDaaS、パッケージ、オンプレミス、マネージドサービス、自社開発のうち、環境に合う方式を見極めます。方式が違えば比べる観点も変わるため、まず方式を決めてから製品を比べます。
- クラウドIDaaS：SSOやMFAを早く始めやすい方式。
- パッケージ・オンプレミス：閉域網や古い業務システムとの接続に向く方式。
- 自社開発：特殊な認可ルールや顧客体験を実現しやすい方式。
自社開発で認証、パスワード保管、MFAを独自に実装すると、脆弱性への対応と規格変更への追随が長く続く負担になります。
候補先には同じRFPを渡し、SAML、OpenID Connect、SCIM、API、Active Directory、LDAPへの対応を確認します。さらに、条件付きアクセス、パスキー、ログ出力、障害時の迂回手段も比べます。
製品ベンダーと導入支援会社は役割が異なるため、要件定義、移行、テスト、教育、運用監視のどこまでを誰が担うかを契約書に記載します。
データのエクスポートや設計書の所有者も決めておきます。また、契約終了時のデータ返却や、他社へ移す際の支援条件も確認します。これらは、ベンダーロックインを避けるための確認項目です。
フェーズ3：設計・開発とデータ整備
正のマスターから属性と権限のルールまでを設計し、誤った権限付与を防ぎます。
- ID属性：人事システムを正とする場合、属性と役割コードを一意に定義。
- データ品質：必須・任意、更新責任、エラー時の扱いを決め、表記揺れや重複による誤権限を防止。
- RBAC：役職だけで一括付与せず、業務上の役割と情報範囲を基準に権限を設計。
- ABAC：所属、雇用区分、場所、端末、時間帯などの条件を組み合わせる方式。
属性には、社員番号、所属、役職があります。ほかに、氏名、メールアドレス、雇用区分があります。入社日と退職日も属性に含まれ、その定義はデータ項目定義書に記載します。
基本は最小権限とします。そのうえで、申請・承認が必要な権限、定期レビューの対象、緊急時だけ使うブレークグラス用管理者を分けます。
開発対象には、連携エラーの再処理と重複IDへの対応を含めます。さらに、退職日の変更、委託先の契約終了、サービスアカウントの更新も対象です。
フェーズ4：テストと移行リハーサル
テストでは、ログインだけでなく、入社から退職までのライフサイクル全体を確認します。また、実データに近い検証環境を使います。
- 対象ケース：入社、異動、退職、休職、再雇用、委託契約の終了。
- 変更ケース：メールアドレス、所属、複数システムへの同時反映。
- 受入条件：過剰権限がなく、退職者IDが予定時刻までに停止する。
管理者操作の記録と連携失敗の検知も、受入条件に含めます。
利用者テストには、代表部門以外の関係者も加えます。店舗、海外拠点、派遣社員、在宅勤務者が対象です。さらに、管理者とヘルプデスクも対象になります。
MFA端末の紛失やスマートフォンの交換も試します。また、ネットワーク障害やIDaaS障害、同期遅延、旧認証との併存期間をリハーサルします。
テスト結果は、合格、条件付き合格、不合格のいずれかで記録します。あわせて、原因、担当者、再テスト日も残します。
切り戻しの条件と手順は、稼働判定会議で確認します。
フェーズ5：稼働と段階移行
稼働は、対象システムや部門を分けて段階的に移行すると安全です。各段階で、影響範囲と運用状況を測ります。
- 先行対象：Microsoft 365、Google Workspace、主要業務SaaS、VPN。
- 後続対象：オンプレミスの古いアプリ、個別連携の多いシステム。
先行対象は、利用者が多く影響範囲を測りやすいものを選びます。各段階では、ログイン率とMFA登録率を計測します。加えて、問い合わせ件数、認証失敗、連携エラー、権限付与の所要時間も計測します。
切り替え当日は、旧認証の停止時刻と対象者、問い合わせ窓口、管理者の連絡先を明記します。
手動での付与が必要な例外も整理します。あわせて、緊急管理者アカウントと障害時の切り戻しも準備します。
旧認証を長く残すと、利用者が古い経路へ戻ってしまい、ログも分散します。
併存期間を設ける場合は、終了日を決めておきます。そのうえで、旧アカウントと共有アカウントを確認してから廃止します。
フェーズ6：定着・改善運用
稼働後も権限を正しく保つため、定期確認、役割分担、運用指標を整えます。
- 定期確認：月次または四半期ごとに休眠・退職者ID、共有アカウント、特権ID、未使用アプリ、未完了レビューを確認。
- 権限変更：異動後の権限を自動で見直し、例外権限は期限付きで付与。
- 運用体制：責任者、データ管理者、承認者、ヘルプデスク、セキュリティ監視担当を定め、手順書と教育を整備。
- 指標：退職から停止までの時間、MFA登録率、アクセスレビュー完了率、手動処理件数、パスワードリセット件数、連携エラーの復旧時間。
J:COMの事例では、認証機能の開発期間が従来の5〜6か月から2〜3か月になりました。あわせて、月20数時間の認証関連運用がほぼゼロになったと紹介されています（出典: Okta「J:COM導入事例」、2026年確認）。自社でも、導入の前後で工数を計測しておくと、投資効果を説明しやすくなります。
ID管理システム開発の費用相場
費用は項目ごとに分けて考えます。たとえば、ライセンス、初期設定、連携開発があります。ほかに、データクレンジング、移行、テスト、教育、運用監視も費用に含めます。
月額ライセンスの金額だけで比べると、既存契約との重複や導入支援、ログ保管、ヘルプデスクの費用を見落としやすくなります。比較は、三年程度の総保有コスト（TCO）で行います。
次に示すのは、公開価格と一般的な連携工数を基にした目安です。個別の見積もりではありません。
公開価格から見るライセンス費用
ライセンスは製品ごとに価格の体系が違うため、候補となるサービスの公開価格を並べて比べます。
- Microsoft Entra
- Okta Workforce Identity
- HENNGE One
Microsoft Entra ID P1は1ユーザーあたり月額1,049円、P2は1,499円です（出典: Microsoft「Entraのプランと価格」、2026年8月確認）。Entra Suiteは1ユーザーあたり月額1,799円です（出典: Microsoft「Entraのプランと価格」、2026年8月確認）。
Microsoft EntraはMicrosoft 365 E3・E5やBusiness Premiumに含まれる場合があるため、既存契約との重複を確認します。
Okta Workforce IdentityはStarterが1ユーザーあたり月額940円、Essentialsが2,670円です（出典: Okta「プランと価格」、2026年8月確認）。また、Oktaには年契約の最低額も設定されています（出典: Okta「プランと価格」、2026年8月確認）。
HENNGE OneはIdentity Editionが1ユーザーあたり月額300円から、Ultra Suiteが800円からです（出典: HENNGE「HENNGE One 価格とプラン」、2026年8月確認）。
三つの公開価格を単純に比べると、従業員100人で認証・SSO中心に使う場合、ライセンスだけで月額3万円台から26万7,000円程度になります。年額にすると、36万円台から約320万円程度が目安です。
従業員300人なら、ライセンスだけで月額9万円台から約80万円程度です。実際の金額は、プラン、最低契約数、年払い、オプション、既存契約によって変わります。
初期導入・連携開発の費用レンジ
初期費用は、対象人数と連携数に加えて、人事マスターの品質、AD・LDAPの構成、古いアプリの認証方式によっても変わります。
さらに、権限の複雑さ、段階移行の回数、運用設計の範囲も影響します。目安は、公開ライセンス価格、富士通の統合認証アセスメント価格、導入事例、一般的な連携・移行工数から試算します。
- 小規模：50〜150人、SaaS 5〜15個なら初期50万〜250万円、期間1〜2か月。
- 中規模：200〜1,000人、連携20〜100個なら初期300万〜1,000万円、期間3〜6か月。
- 大規模：複数会社・海外拠点や複雑な連携を含むと1,000万〜5,000万円以上、期間6〜18か月。
小規模は、標準設定でMFAとSSOを中心に導入する場合の目安です。中規模は、人事システム、AD・LDAP、SaaSを連携し、入社・異動・退職を自動化する場合を想定しています。
大規模案件では、IGA・PAM、CIAM、複雑な基幹連携、24時間運用を含む可能性があります。なお、富士通の統合認証アセスメントは、150万円からと公開されています。
認証基盤そのものをフルスクラッチで作る場合は、2,000万〜1億円超となる可能性があります。これは、標準製品や標準プロトコルで代替しにくい特殊要件を含む場合の推定です。
認証、パスワード保管、MFAの暗号処理を自社で実装すると、脆弱性対応、監査、規格変更、運用監視が続きます。そのため、既製のIDaaSと連携開発を組み合わせる方法とも比べます。
ID管理システムの見積もりを取る際のポイント
見積もり依頼では、対象範囲、現状、目標、制約、成果物を同じ書式で示します。「ID管理システムを導入したい」とだけ伝えると、前提が揃いません。
安い見積もりには、移行、テスト、運用が含まれていないことがあります。そのため、初期費用と継続費用、必須と任意、製品費と作業費を分けて比べます。
RFPに入れる要件と成果物
RFPには、前提条件と必要な成果物をそろえて記載します。見積もり条件には、次の項目を含めます。
- 対象範囲：利用者数と内訳、会社・拠点、対象アプリ、現在の認証方式。
- 環境・運用：AD・LDAP・人事システム、MFA、権限、ログ保管期間、稼働希望日、運用体制。
- ライフサイクル：退職・契約終了時の停止期限、異動時に旧権限を外す時期、管理者権限の承認者。
- 成果物：現状調査、要件定義、構成図、ID・属性マッピング、権限モデル、連携・テスト・移行仕様。
- 運用引き継ぎ：手順書、教育資料、切り戻し手順、設計書・設定情報の納品。
運用を他社へ引き継げるかも確認します。引き継ぎの条件は将来の変更費用を左右するため、早い段階で詰めておきます。
3社以上の同じ条件での比較
比較先の種類と評価項目をそろえ、同じ条件で少なくとも3社程度から提案を取ります。
- 依頼先：製品ベンダー、導入支援・SIer、運用込みのマネージドサービス。
- 評価軸：機能、連携、セキュリティ、運用、費用、サポート、契約の七項目。
Microsoft 365やAzureを広く使う会社は、Microsoft Entraとの重複を見ておきます。一方で、マルチクラウドや海外拠点が多い会社は、Oktaなどが複数の環境をまたいで扱えるかを確認します。
国内SaaSの利用や導入のしやすさを重視する会社は、HENNGE Oneなどを候補にできます。また、大規模なオンプレミス資産やグループ会社がある場合は、環境評価と移行実績も確認します。
機能では、SSOやMFA、パスキーを確認します。ほかに、ライフサイクル、アクセスレビュー、PAM、CIAMも確かめます。
連携では、SAMLやOpenID Connect、SCIM、API、AD・LDAPへの対応を見ます。さらに、人事システムへの対応も確認します。
費用は、初期設定や連携の追加、ログ保管を含めて比べます。また、ユーザーの追加、最低契約数、更新時の単価も比較します。
サポートでは、障害時の連絡方法、対応時間、復旧目標を確認します。契約条件も、評価表に記録しておきます。
失敗を防ぐリスクチェック
導入リスクは、対象範囲、データ品質、認証の復旧、旧認証の終了に分けて確認します。
- 範囲・データ：アプリを増やしすぎず、データ品質を確かめてから自動連携する。
- 復旧・緊急時：MFA端末を紛失したときの復旧と、ブレークグラス用アカウントの準備。
- 移行・契約：旧認証の終了と、追加費用が生じる製品制限の確認。
契約の前に、仕様変更や製品制限によって追加費用が発生する条件を質問しておきます。そのうえで、PoCでは代表的なSaaSと古い業務アプリの両方を試します。
個人データを扱う場合、ID管理は製品の導入だけで終わらず、運用の設計も含めて考える必要があります。個人情報保護委員会のガイドラインでは、個人データを扱う情報システムの利用者を識別・認証することが示されています。
個人情報保護委員会は、アクセス権限を必要最小限にし、アクセスログを定期的に分析することも、ガイドライン（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）で示しています。
すべての企業に、特定の製品や一律のMFAが直接義務付けられているとは限りません。そのため、情報の重要度とリスクに応じて、認証の強度、権限、ログ、インシデント対応を決めます。
NISTは、2025年8月公開のSP 800-63-4で、デジタルIDの要件を整理しています。本人確認、認証、フェデレーション、認証器、管理プロセスなどが対象です（出典: National Institute of Standards and Technology「NIST SP 800-63-4」、2025年）。
また、国内の中小企業向けには、IPAが2026年3月に第4.0版のガイドラインを公開しています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年）。こうした最新の指針を確認し、自社のリスクと運用に対応づけてRFPを作成します。
よくある質問（FAQ）
費用や導入期間、自社開発の必要性、MFAの扱いは、会社の規模や既存環境によって違います。
ID管理システムの開発期間はどれくらいですか？
標準的なIDaaSの設定と数個のSaaS連携であれば、1〜2か月が目安です。人事システムやAD・LDAP、複数の業務アプリを含む中規模の導入であれば、3〜6か月が目安です。
複数の会社や海外拠点、IGA・PAM、CIAM、古い認証方式の移行を含む場合は、6〜18か月程度になる可能性があります。
期間を短くするには、対象を絞ったPoCと段階移行を先に計画します。また、データ整備と利用部門のテストは並行して進めます。
ID管理システムは自社開発とIDaaSのどちらがよいですか？
認証、SSO、MFA、ライフサイクル管理が中心であれば、標準機能のあるIDaaSを使い、必要な連携だけを開発する方法が一般的です。
顧客固有のログイン体験、特殊な認可、既存業務との深い統合など、標準製品では満たせない差別化要件があれば、自社開発を検討します。
認証プロトコルや暗号処理は独自に実装せず、標準規格と専門会社のレビューを活用します。代表的な標準には、SAML、OpenID Connect、OAuth 2.0、SCIM、FIDO2・WebAuthnがあります。
MFAを導入すればID管理は完了しますか？
MFAは本人確認を強化する機能で、ID管理全体を担うものではありません。
退職者のID停止や異動後の権限変更は、MFAとは別に設計します。また、最小権限やアクセスレビュー、特権IDも設計の対象です。さらに、ログ監視と連携エラーの復旧も必要です。
重要な管理者権限には強い認証を求めます。そのうえで、現場向けの復旧手順と、障害時の緊急アクセスも用意します。
小規模企業でもID管理システム開発は必要ですか？
小規模企業のID管理は、利用状況と運用上のリスクを見ながら、段階的に判断します。
- 必要性：SaaSの増加、委託先の利用、退職者アカウントの残存、個人データへのアクセスがあるなら、段階的なID管理が必要。
- 始め方：大規模IGAや自社開発から始めず、正のマスター、主要サービスのMFA・SSO、入退社時の停止手順を整備。
- 比較条件：利用者数、対象アプリ、扱う情報、監査要件を踏まえ、標準IDaaSの小規模プランと導入支援費を比較。
まとめ
ID管理システム開発は、六つのフェーズを順に進めます。要件整理と選定から始め、そのあと設計・開発に入ります。テストを経て、稼働と定着まで進みます。まず、IDと権限の現状を棚卸しして、MUSTとWANTを分けます。
人事システムなどの正のマスターを決めたうえで、標準IDaaSで対応する部分と連携開発の範囲を切り分けます。さらに、PoCと段階移行でリスクを抑えます。
着手前に確認するチェックリスト
着手前の確認事項は、一枚の要件整理シートにまとめておきます。そうすれば、候補会社から同じ前提で見積もりを取れます。
- 対象：従業員ID・顧客ID・特権ID、対象アプリ、利用者数。
- 運用：退職・異動時の停止と権限変更、正のマスター。
- 安全性：認証強度、ログと監査、障害時の迂回手段。
- 費用：三年分のライセンス費と運用費。
着手から比較までの流れ
着手から比較までは、次の順で進めます。
- ID・権限・認証方式を棚卸しし、課題と優先順位を決める。
- 3社以上に同じRFPを渡し、製品費、初期導入、連携、移行、テスト、運用、契約終了時の条件を比べる。
- 利便性に加えて、退職時の即時停止、最小権限、アクセスレビュー、ログの証跡、運用定着まで評価する。
▼全体ガイドの記事
・ID管理システム開発の完全ガイド
▼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を創業。