アクセス管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

アクセス管理システム開発は6段階で進めます。前半は要件整理、製品・方式の選定、設計・開発で、後半はテスト、段階稼働、定着です。この順に進めると、認証・権限・退職者管理を一貫して運用できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

アクセス管理システム開発の全体像

アクセス管理システムは、誰がどの端末や場所から、どのシステムのどの操作まで利用できるかを管理します。

認証と認可を中心に、ID管理、操作ログ、権限確認を一つの運用として設計します。

論理アクセスと入退室管理の切り分け

導入範囲を決める前に、発注側が対象と必要な要件を整理します。

• 対象範囲：「アクセス管理」は入退室管理を指す場合もあるため、従業員や取引先がクラウドサービス、社内Webシステム、基幹システムへ入る論理アクセスを対象とします。
• 入退室管理の要件：カード発行、電気錠、現地配線、来訪者管理、入退室ログが加わり、見積体系も変わります。
• 事前資料：対象ユーザー、対象システム、守る情報資産、論理と物理の範囲を明記した資料です。

論理と物理を切り分けずに相談すると、誤解が生じやすくなります。たとえば、IDaaSの見積に現地施工費を期待したり、入退室設備の導入だけでクラウドの退職者アカウントを停止できると考えたりします。

認証・認可・IDライフサイクルの一体的な整理

権限設計では、認証と認可を分けたうえで、IDの変更も一続きで扱います。

• 認証と認可：認証は本人確認、認可は操作の判定です。営業担当者でも給与情報を見られるとは限りません。
• 認可条件：部署、役職、雇用区分、契約期間、端末状態、接続元IP、時間帯で絞ります。
• IDの変更：入社時に発行し、異動で変更、休職で一時停止、退職で無効化します。
• 連携先：人事システム、Active Directory、Microsoft Entra ID、Google Workspace

SCIMなどで各サービスに情報を反映させると、Excelへの転記やIDの削除漏れを減らせます。

SSOだけでなく統制の優先順位

アクセス管理の機能は幅広く、認証ではSSOやMFA、パスキーなどがあります。認可では、RBACやABAC、特権ID管理を扱います。

運用面では、申請・承認とアクセスレビューがあり、監査ログやSIEM連携までが対象になります。

初回から全機能を目指すと、権限の洗い出しや例外の整理が終わらず、稼働時期が延びます。そこで、初回導入の範囲に優先順位をつける考え方が現実的です。

• 高リスクアプリ：MFAを適用します
• 退職者：ID停止を徹底します
• 管理者権限：付与状況を見えるようにします

個人情報保護委員会は、技術的安全管理措置としてアクセス制御とアクセス者の識別・認証を示しています。

その根拠は、同委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」およびQ&A（2025年確認）です。

権限の最小化や適切かつ定期的な権限管理も、手法の例として挙げられています。ただし、法律が特定の製品を一律に指定しているわけではありません。そのため、要件は情報資産とリスクに応じて定めます。

アクセス管理システム開発の進め方と6フェーズ

製品や開発会社を先に選ぶと、現場の権限と合わず、例外が増えてしまいます。そこで、要件整理から定着までを6段階に分け、完了条件を経営層、情シス、現場、ベンダーで共有します。そうすれば、どの段階でも同じ基準で判断できます。

フェーズ1：要件整理での現状と目標の共有

開発に入る前に、IDとアプリの現状を押さえ、必要な統制を決めます。

• 現状調査：ユーザー台帳、組織、アプリ、認証、権限、発令フローを洗い出します。
• 台帳項目：ユーザー種別、所属、責任者、期限、個人・共有の別、最終利用日を記録します。
• 連携要件：接続プロトコルとID情報の連携可否を確かめます。
• 運用条件：MFA、ログ保存、SIEM、代替認証、委託先・ゲスト・サービスIDの扱いを決めます。
• 導入範囲：MUST、SHOULD、WANTに分けて合意し、過剰なスクラッチ開発を避けます。

不明なIDを利用中として扱うか、停止候補とするかも決めます。そのうえで、対象ユーザー数とアプリ数を整理します。

SAML 2.0、OpenID Connect、OAuth 2.0、SCIMの対応状況と、AD・人事連携も確認します。対応状況を見ると、どこまで標準の仕組みで連携できるかが分かります。

フェーズ2：要件と運用体制に基づく製品・方式の選定

連携対象と運用条件を照らし合わせ、発注側と開発会社で導入方式と提案範囲を比べます。

• クラウドIDaaS：SSO、MFA、ログ、更新を標準機能で使え、SaaS中心の短期導入に合います。
• 統合認証基盤：ADや古い業務システム、発令日予約、職務分掌に合わせやすい方式です。
• API・ハイブリッド：特殊な顧客向けの認可に合う方式です。
• 未対応アプリ：リバースプロキシ、画面改修、別認証の継続を比べます。
• 提案比較：同じRFPで標準機能、追加費用、個別開発、運用代行を確認します。

統合認証基盤を選ぶ場合は、保守や連携アダプター、更新作業も確認します。特に、接続方式によって費用とリスクが変わります。

認証を自作するなら、脆弱性、セッション管理、パスキー、アカウント復旧を継続して担う必要があります。

フェーズ3：設計・開発での権限モデルと例外の確定

設計の段階では、権限の根拠とアカウントごとの管理責任を決めておきます。

• 権限モデル：IDの正本、部署・役職・雇用区分、RBAC・ABACの範囲を定めます。
• 判定条件：契約期間、勤務地、端末状態、接続元、時間帯を使い、許可根拠を残します。
• 設計書：認証、権限の付与・剥奪、承認者、緊急用ID、ログ、保存期間、証明書責任者を記します。
• 特権・ゲスト：特権IDは申請・承認・期限・記録を設け、ゲストには終了日を設定します。
• サービスID：所有者とローテーション周期を記録し、見直しの抜けを防ぎます。

部署の標準的なロールだけで足りない場合は、判定条件を組み合わせて例外に対応します。ただし、条件を増やしすぎると、権限を与えた理由を説明しにくくなります。許可の根拠は、管理者が読める形で残します。

フェーズ4：実ユーザーによる正常系と異常系のテスト

テストでは、ログイン確認に加えて、障害時の動きまで検証します。

• 利用者テスト：一般、部門・全社管理者、委託先、退職予定者で許可・拒否を試します。
• 障害テスト：複数アプリ横断のSSO、MFA再登録、パスワードリセット、端末紛失、通信・IdP障害、証明書期限切れを確認します。
• 退職テスト：IDの停止時間と連携先のセッション、APIトークンへの影響を測ります。
• 判定記録：結果、証跡、残課題、判定者を残し、遅延や問い合わせも測定します。

フェーズ5：代表部門からの段階的な稼働

全社で一斉に切り替えると、失敗時の影響が大きくなります。そのため、準備を整えたうえで、段階的に稼働させます。

• 段階移行：情シスや一つの代表部門で試し、SaaS中心、オンプレミスや複雑な権限の部門へ広げます。
• 切替準備：旧ログイン停止、利用者案内、窓口、当番、切り戻し条件を決めます。
• 利用者案内：MFAの理由、代替手段、機種変更・紛失時の手順を伝えます。
• 管理者演習：ID停止、緊急権限、ログ検索、連携障害の切り分けを行います。
• 初週確認：失敗率、問い合わせ、遅延、未連携アプリを調べ、例外を運用に反映します。

フェーズ6：定着期の権限レビューと改善の定例化

稼働後は、定期レビューとKPIを使って、権限や運用上の問題を見直し続けます。

• 定期確認：月次で人事異動、失敗ログ、管理者権限、期限間近のゲストを確認します。
• 権限レビュー：四半期または半期ごとに必要性、過剰権限、承認者を見直します。
• 運用KPI：退職後の停止時間、未使用ID、MFA適用率、権限棚卸し率を追います。
• 判定ルール：ゼロトラストを具体化し、端末不適合時の追加認証や国外からの管理者アクセス拒否を定めます。

このほか、アクセス申請の処理時間や認証障害からの復旧時間も追います。

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

費用は、ライセンス、設定、連携に分かれます。そのほか移行やMFA、教育・監視の費用もかかります。初期費用と開発費は推定レンジです。

この数値は、公開ライセンス価格や、認証基盤・業務SaaS連携の類似案件をもとにしています。

契約条件は案件ごとに異なるため、月額だけでは総額は決まりません。

公開ライセンスの月額単価：1ユーザー300円から2,670円程度

公開価格の例をもとに、人数と契約条件に応じたライセンス費用を試算します。

• HENNGE One：Identity Editionは1ユーザー月額300円からです。
• CloudGate UNO：ユーザー月額400円から600円です。
• 他社製品：Entra IDとOktaは、プラン別の単価を確認します。
• 100ユーザー：月額約3万から約27万円、年額約36万から約324万円です。
• 500・1,000人：500人は月額約15万から約133万5,000円、1,000人は約30万から約267万円です。

上記は、2026年に確認した各社公式価格の単価です（出典：各社公式の価格ページ、2026年確認）。

契約条件や、Microsoft 365契約への含まれ方によって、実額は変わります。

各社公式価格ページ（2026年確認）によると、Microsoft Entra ID P1は月額899円相当、P2は1,349円相当です。Okta Workforce Identityは、Starterが940円、Essentialsが2,670円です。

HENNGE Oneの最小契約ID数はプランによって異なり、CloudGate UNOの新規契約は最低100 IDです。また、課税条件も確認します。

初期費用の幅：規模と連携数で50万円から3,000万円以上

規模と連携の複雑さで費用帯が変わります。そのため、人数・機能・期間をそろえたうえで見積もります。

• 小規模：50から200ユーザー、SaaS 3から10個で初期50万から300万円です。
• 小規模の期間：標準コネクタ中心なら1から3か月が推定目安です。
• 中規模：200から1,000ユーザーで初期300万から1,000万円、3から6か月が目安です。
• 大規模：1,000ユーザー超では初期1,000万から3,000万円以上、6から12か月以上の可能性があります。
• 自社サービス：認証・認可のスクラッチ開発は、要件によって費用が広がります。

中規模の目安には、SaaSとオンプレミスの混在、AD・人事、権限申請、ログ連携が含まれます。大規模案件には、グループ統合、複数会社、IGAやPAM、複雑な職務分掌、段階移行、監査証跡が含まれます。

小規模の初期費用には、要件整理、テナント設定、MFA方針、初期ユーザー移行、管理者教育が含まれます。

自社サービスの単純な認証連携も、推定300万から1,500万円程度からです。顧客IDやB2Bのテナント分離、課金まで作ると、3,000万円以上のケースもあります。

同意管理やAPI認可、パスキーまで加わると、さらに費用が増えます。監査ログも作る場合は、その分の費用も見込みます。

運用費の範囲：レビュー・監視・障害対応まで

発注側は、定常作業と契約後の費用条件を合わせて確認し、運用体制を見積もります。

• 運用作業：ID洗い出し、権限レビュー、問い合わせ、ログ監視、証明書更新、連携変更を含めます。
• 運用体制：障害復旧・教育を含め、月次・四半期・年次の作業と担当者を示します。
• 比較項目：初期費用、年額、追加単価、最低数、連携費、オプション、サポート、ログ保存を並べます。
• 契約終了：データ返却・移行支援も含め、必要な統制を含む年間総額で判断します。

見積もりを取る際のポイントとチェックリスト

製品導入費と、安全に運用できる状態までの費用は分けて考えます。資料が粗いと、各社の前提が異なり、金額を単純には比べられません。

RFPには、現在の課題と対象範囲から始めて、連携方式、移行方針、運用体制、成功指標まで記載します。

要件定義書に書くユーザー・アプリ・例外の具体化

各社が同じ範囲で見積もれるように、利用者、連携、例外動作を具体的に書きます。

• 対象範囲：従業員・委託先・ゲスト数、拠点、アプリ、オンプレミス、IdP・人事・AD・端末管理を記します。
• アプリ情報：管理者、認証、IDの正本、付与者、退職時停止、ログ、SAML・OIDC・SCIM対応を整理します。
• 例外ID：共有ID、APIキー、サービスID、夜間バッチも対象に含めます。
• アクセス条件：社外接続の管理者にFIDO2または追加MFAを求め、非準拠端末から個人データへアクセスさせません。
• 受け入れ基準：ゲストの自動停止と権限変更の承認者・日時を定めます。

複数社の同一前提での比較と実装責任の境界

製品機能に加えて、導入作業の担当と契約に含める条件も比べます。

• 依頼先：製品会社と、要件整理・連携開発・移行・運用を担うSIerを分けて比べます。
• 作業責任：要件定義、設定、個別開発、移行、テスト、教育、運用引き継ぎの担当を決めます。
• 運用条件：標準外アプリの連携方法、退職者の停止時間、ログ保存日数、障害時の認証経路を質問します。
• 解約・実績：設定・ログの返却と類似移行実績を確認し、個別相談は追加費用・前提を別紙に残します。

製品の標準機能だけで要件を満たせない場合は、SIerの支援が必要です。

ベンダーロックインと切り戻し不能の防止

将来の移行や障害復旧に備え、契約と運用の条件を先に決めておきます。

• 自社保管：設計書、属性・権限、連携、証明書、ログ、運用手順、障害連絡先を保管します。
• 移行性：標準規格を優先し、独自エージェント等は将来の移行方法を確認します。
• 管理者教育：設定や運用を引き継げるよう、管理者教育を契約に含めます。
• 切り戻し：旧認証・パスワード・二重ログインの期間、再案内、データ整合性を計画します。
• 契約条件：残存セッションによる退職者停止への影響を踏まえ、リハーサル、障害対応、データ返却を明記します。

見積書の初期・連携・移行・運用の4層による点検

作業範囲と成果条件を分けておくと、追加費用や検収条件を同じ基準で比べられます。

• 費用区分：初期設定、連携・改修、データ移行、教育・監視・保守を分けます。
• 連携範囲：「一式」の本数、標準・個別開発の境界、テスト環境、変更費を確認します。
• 完了条件：対象者、方式、例外、再登録、紛失対応などMFAの範囲を定義します。
• 成果基準：対象500ユーザーの98％をパイロット後に展開し、退職者停止を人事登録から30分以内に反映、管理者がログ検索できる基準を設定します。

よくある質問

導入前によくある疑問を、SSOとMFA、既存システム連携、方式選定、期間の順に取り上げます。

アクセス管理システムはSSOとMFAだけ導入すれば十分ですか？

十分とは限りません。SSOはログインの入口を一つにまとめ、MFAは本人確認を強めます。ただし、どちらも入口と本人確認の対策なので、退職者IDの停止や過剰権限の削減、特権IDの期限設定、権限レビュー、操作ログ監査は、別途設計します。

後からIDライフサイクルと認可統制を加えられるよう、構成を組みます。

古いオンプレミスシステムもアクセス管理の対象にできますか？

対象にできますが、まずは連携方式の確認が必要です。SAMLやOIDCに対応していれば標準連携を検討し、非対応であれば、リバースプロキシ、代理認証、エージェント、画面改修を比べます。

ただし、独自方式に固定すると、移行費用と障害対応が増える場合があります。そのため、暫定方式と標準プロトコルへの改修時期を分けて計画します。

スマートフォンを持たない従業員にもMFAを適用できますか？

適用できますが、認証手段を一つに限定しない設計が必要です。FIDO2・パスキー、セキュリティキー、端末証明書、ワンタイムパスワードなどから、環境に合う方式を選びます。

紛失・機種変更・再登録の手順を用意し、利便性と安全性をパイロットで確認します。

• 相談件数：IPAは2025年7月、不正ログイン相談が144件あったと公表しています。
• 推奨：多要素認証とパスキーを推奨しています（出典：IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。

アクセス管理システムの開発期間はどのくらいですか？

期間の目安は、対象人数、連携範囲、移行の複雑さによって変わります。

• 小規模：標準コネクタ中心で50から200ユーザー、SaaS 3から10個なら1から3か月が推定目安です。
• 中規模：AD・人事、オンプレミス、権限申請、ログ連携を含む200から1,000ユーザーは3から6か月です。
• 大規模：複数会社、IGA・PAM、段階移行を含む案件は6から12か月以上の可能性があります。

期間は、対象アプリの改修可否や、ユーザーと権限データの整備状況によっても変わります。

各フェーズの完了条件も確認します。

まとめ

アクセス管理システム開発では、誰がどの情報へどの条件でアクセスできるかを整理します。認証機能の追加は、その一部にすぎません。

入社・異動・退職と権限変更を運用につなぎ、監査できる状態まで作ります。

6フェーズの完了条件をそろえた進め方

要件整理では台帳と対象範囲を確定し、選定では標準連携と例外を比べます。

設計では、RBACやABACを含む権限モデルを定めます。そのうえで、最小権限や特権ID、ログ、緊急時の経路も決めます。

テストでは、許可・拒否、異動・退職、障害を検証します。テスト後は、代表部門から稼働を広げ、定着後は権限レビューと改善を定例化します。

見積の判断軸は運用可能な総額

費用は、月額ライセンスに加えて、初期設定、連携、移行を含めて比べます。運用では、教育、監視、レビューも見ます。さらに、障害対応や将来の移行費も含めます。

アプリ一覧とID台帳を作り、MUST要件を決めます。次に、代表部門のパイロットを含むRFPで、複数社から同じ条件の提案を受けます。これが、安全な定着への第一歩です。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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