アクセス管理システムの発注は、現状のID・アプリ・権限の棚卸し、要件整理、RFPによる比較、段階導入の順に進めると、安全性と使いやすさを確かめながら展開できます。
発注形態、要件整理、契約と費用、委託先の選び方を順に見ていきます。全体像はアクセス管理システム開発の完全ガイドもご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
アクセス管理システムを発注する前に知っておきたい全体像
アクセス管理システムは、誰がどの端末や場所から、どのシステムのどの操作まで使えるかを管理する仕組みです。ログイン画面を一つにまとめる作業は、その一部にすぎません。
入社、異動、退職、委託期間の終了に合わせて権限を変えていく基盤です。そのため、発注範囲は認証と認可を起点に、ID管理から監査、運用体制までを含めて考えます。
カードリーダーや電気錠を使う入退室管理は、機器、施工、現地保守が加わるため、見積の体系が別になります。
認証と認可を分けた発注範囲
認証は本人確認のことで、パスワードやMFAのほか、パスキーや生体認証などが該当します。認可は、本人確認を済ませた後に、利用できるデータや操作を決める仕組みです。
たとえば、営業担当者には顧客情報の閲覧を許可し、給与情報の出力や権限変更は許可しない、といった区別が認可です。RFPには「SSO導入」と書くだけでなく、許可条件まで示します。
- 組織条件：部署、役職、雇用区分、契約期間
- アクセス条件：端末状態、接続元IP、場所、利用時間帯
ID管理から監査までの一続きの範囲
発注対象は、ID運用の面と、権限・監査の面に分けて考えます。
- IDと認証：登録・変更・削除、組織連携、SAMLやOpenID ConnectのSSO、SCIMのプロビジョニング
- 権限と監査：権限申請・承認、特権IDの一時利用、アクセスレビュー、操作ログ保存
個人情報保護委員会のガイドラインは、個人データを扱う担当者と範囲を限定するアクセス制御を示しています。アクセス者の識別と認証も、技術的安全管理措置に当たります。この内容は「個人情報の保護に関する法律についてのガイドライン（通則編）」に記載されています（出典: 個人情報保護委員会、2026年確認）。
発注側は、製品の機能と並べて、権限の承認者と退職時の停止確認者も決めておきます。
アクセス管理システムの発注形態の選び方
発注形態は、標準コネクタなどの標準機能で足りるかどうかと、独自の連携や業務ルールがあるかどうかで決まります。SaaS中心ならIDaaS、複雑な連携ならSIer、自社サービスなら既存基盤と独自開発の併用が候補になります。
既製IDaaSの導入支援を委託する形
SaaS中心の企業が既製IDaaSを使うなら、対象範囲と委託内容を先に整理しておきます。
- 対象：Microsoft 365、Google Workspace、Salesforce、BoxなどのSaaS
- 製品候補：HENNGE One、Microsoft Entra ID、Okta、CloudGate UNO
- 委託範囲：初期設定、アプリ連携、ユーザー移行、管理者教育。MFAやSSOを短期間で始めやすく、脆弱性対応や機能更新を自社だけで抱えずに済みます
- 契約前の確認：最低契約数、初期セットアップ費、対象外アプリ、障害時の代替認証、データ返却条件
SIerや開発会社に統合設計から依頼する形
複数会社の人事制度、Active Directory、オンプレミスの業務システムを統合する場合に向きます。独自の権限申請や監査の仕組みを組み込む場合も、この形が候補になります。
この形では、要件定義から運用設計までを委託します。連携開発や移行も、その範囲に入ります。候補としては、NRIはIAM全体構想や複数製品、SCSKは業務連携や権限管理を組み合わせた提案が考えられます。
確認したいのは、製品を売っているかどうかより、異動、退職、委託終了などの業務イベントを権限に反映できるかです。
自社開発とハイブリッドで進める形
顧客向けサービスでテナントごとに権限が異なる場合や、APIごとの認可、契約期間に応じた利用範囲の変更が必要な場合に検討する形です。
認証基盤をゼロから作るのは避け、標準ID基盤に認証を任せて、アプリ側で認可ロジックを担う分担にします。認証まわりの機能（パスキー、セッション管理、アカウント復旧、レート制限、監査ログ）を自社で実装すると、継続的な脆弱性対応が必要になります。
自社固有の価値がない部分は既製基盤に寄せ、独自要件だけをAPIで実装すると、費用とリスクを抑えられます。
アクセス管理システムの発注・外注の進め方
製品のデモから始めると、業務を製品に合わせる流れになり、追加費用が膨らみやすくなります。そのため、まず現状を一覧にして優先度を決め、同じ条件のRFPを複数社に渡します。
段階導入では、全社や全アプリへ一度に広げず、代表部門で安全性と使い勝手を確かめられます。
現状のID・アプリ・権限の棚卸し
まず、従業員・派遣社員、取引先・顧客、サービスアカウントに分けて、それぞれの人数と管理責任者を洗い出します。
アプリは、SaaSや社内Web、基幹システムを一覧にします。VPNやAPI、古いオンプレミス認証も、その一覧に加えます。各アプリについて認証方式や利用者、重要データを記録し、退職時の停止方法とログ保存期間も書き添えます。
Excelの台帳だけに頼らず、ログイン履歴や各システムの管理画面と照合して、未使用IDや共有アカウントを探します。
MUST要件とWANT要件の分け方
必須条件と追加の希望を分けておくと、候補製品と見積もりを同じ基準で比べられます。
- MUST：退職者の即時停止、管理者MFA、最小権限、認証・権限変更ログ、障害復旧
- WANT：パスキー全社展開、アクセスレビュー自動化、SIEM連携、条件付きアクセス高度化
MFAを先に入れると、問い合わせが増える場合もあります。そのため、要件にはスマートフォンを持たない従業員、共有端末、夜間勤務といった例外を含めておきます。海外拠点や委託先の例外フローも、要件に加えます。
パイロット導入から段階的な展開
代表部門と代表アプリを選び、ログイン成功率、認証遅延、MFA登録率を測ります。問い合わせ件数と権限申請の処理時間も、あわせて確かめます。
代表部門では、退職者を停止できるか、異動前後の権限が適切か、IDaaSの障害時に管理者が復旧できるかを試します。
試した結果をもとに設定を直し、次の部門へ展開すると、全社展開後の手戻りを抑えられます。
RFPと要件整理に書く内容
RFPは、製品名を指定する書類ではなく、解決したい業務課題と評価条件を候補会社に伝える書類です。RFPには、規模や条件（ユーザー数、アプリ数、権限、データ重要度）、既存環境、移行期限、運用担当者も記載します。候補会社が同じ前提で見積もれるように、必須項目と提案を希望する項目を分けておきます。
業務背景と対象範囲の明示
たとえば、「異動時に複数の管理画面を更新し、付与漏れと削除漏れがある」や「委託先アカウントを契約終了日に止めたい」のように、課題は場面ごとに書きます。
監査で権限変更の証跡を出したい場合は、その内容も具体的に書きます。また、対象ユーザーに取引先、顧客、ゲストを含めるかどうかも区別して示します。
対象アプリは、本番と検証、オンプレミスとクラウド、APIとバッチに分けて書きます。対象外のものも明示しておけば、見積もりの前提がぶれにくくなります。
プロトコル・権限・ログの条件の記載
SSOでSAML 2.0、OpenID Connect、OAuth 2.0のどれを使うかと、ユーザー連携でSCIMに対応するかを、RFPで候補会社に問います。
Active Directoryや人事システムとの同期の向きも定めます。認可はRBACで足りるのか、ABACや条件付きアクセスが必要なのかを整理します。
ログ対象は、認証や権限の付与・変更、管理者操作に加えて、失敗や緊急時の例外操作です。保存期間や検索、エクスポート、SIEM連携、時刻同期の条件も指定します。
導入後の運用と成果指標の要求
引き継ぎの成果物には、設定一覧、連携仕様、権限マトリクスを含めます。さらに、障害対応手順、管理者手順書、利用者FAQも求めます。
成果を測る指標は、退職者停止の完了率、過剰権限の是正件数、アクセスレビューの実施率です。ログ確認時間や認証関連の問い合わせ件数も、指標に加えます。
自社で設定を確認できず、変更のたびに有償の依頼が必要になる状態は避けたいところです。そのため、管理者権限の分担と教育範囲も決めておきます。
アクセス管理システムの契約形態の選び方
契約形態は、要件がどれだけ不確かか、成果物がどれだけ明確か、発注者が管理できる範囲はどこまでかで選びます。そのうえで、費用に加えて、運用に関わる責任（設定変更、障害対応、証明書更新、ログ監視、権限レビュー）を、契約書と別紙に定めます。
請負契約の成果物と受け入れ条件
要件が固まり、対象アプリから移行データ、テストまで範囲が決まっている場合は、請負契約で成果物と納期を定めやすい形です。
「SSO連携一式」とだけ書くと、対象アプリやエラー修正の責任が曖昧になります。受け入れ条件には、正常ログインに加えて、MFA失敗と退職者停止を含めます。権限変更やログ検索、障害時の復旧とロールバックのテスト結果も、同じ条件に入れます。
準委任契約が向く要件整理と継続支援
作業時間や専門知識の提供を受ける段階に向いています。たとえば、現状調査やRFP作成の支援、製品選定から権限設計、運用設計までが、これに当たります。
要件が変わりやすい初期段階では、完成品を固定しません。代わりに、月次の作業範囲と担当者を定め、報告内容と成果物の扱いも決めておきます。
品質を確かめるために、レビュー会を定例で開きます。課題一覧、意思決定記録、次月計画も、その場で扱います。
ライセンス・保守・運用の責任分界
IDaaSの利用や追加開発などの項目は、同じ会社から購入しても、費用と責任が異なる場合があります。
確認したいのは、月額ライセンスのサポート時間、障害連絡先、SLAです。また、設定変更の単価やユーザー追加、証明書更新の扱いも確かめます。
ログの保存と返却、解約時の移行支援も、契約で決めておきます。設定情報と連携仕様を自社へ納品する条項は、ベンダーへの依存を抑えるうえで役立ちます。
アクセス管理システムの費用相場と内訳
費用は、ライセンスと、導入費（初期設定、連携開発、データ移行、教育）、運用保守に分けて考えます。
公開されている単価は、HENNGE One Identity Editionが月額300円から、Microsoft Entra ID P1が年払いで月額899円相当です。Okta Workforce Identity Starterは月額940円から、CloudGate UNOは月額400円からです（出典: 各社公式料金ページ、2026年確認）。
公開単価は、契約条件（契約期間、税区分、最低ID数、既存のMicrosoft 365契約）や初期費用によって変わります。そのため、公開単価をそのまま導入総額とみなさないよう注意します。
ユーザー数と機能で変わるライセンス費
公開料金は、単価だけでなく契約条件と合わせて比べます。
- 月額例：100ユーザーで月額300円なら3万円
- 年額の幅：公開価格を単純に計算すると約36万円〜約320万4,000円。初期費用、税、オプション、サポートは含まない
- 最低契約数：CloudGate UNOの新規契約は100 ID以上
CloudGate UNOの初期セットアップ費は、別途かかります（出典: インターナショナルシステムリサーチ「CloudGate UNO サービス紹介・料金」、2026年確認）。
少人数の場合でも、最低契約数が総額を左右します。そのため、見積書でその条件を確かめます。
初期導入・連携開発の費用レンジ
リサーチノートと一般的な認証基盤・業務SaaS連携案件をもとに試算すると、連携範囲が広いほど、費用も期間も増えます。中規模の案件では、人事・AD連携、権限申請、ログ連携を含みます。
- 小規模：50〜200ユーザー、SaaS 3〜10個、標準コネクタ中心。費用は50万〜300万円、期間は1〜3か月
- 中規模：200超〜1,000ユーザーで、SaaSとオンプレミスが混在。費用は300万〜1,000万円、期間は3〜6か月程度
- 大規模：1,000ユーザー超、複数会社、IGA・PAM、複雑な職務分掌、段階移行。費用は1,000万〜3,000万円以上、期間は6〜12か月以上の可能性
いずれも、特定の会社の確定見積ではなく、要件と連携本数で変わる推定の幅です。
見積書で見落としやすい運用費
初年度は、ライセンスと導入費に加えて、準備や検証の作業（ユーザー台帳、権限マトリクス、アプリ改修、テスト環境、移行リハーサル）も見積もります。
利用者への案内やヘルプデスクも、初年度の費用に入ります。2年目以降は、年額ライセンスのほか、運用代行やアクセスレビュー、ログ監視の費用が続きます。
証明書更新や連携先の追加、退職者・委託先アカウントの棚卸しも、継続的な費用になります。設定変更や連携追加の単価が高いと、複数年の総額で見たときに、初期費用の比較が逆転することがあります。
委託先の選定と見積比較の確認ポイント
委託先は、製品販売と導入支援、SIer、アプリ開発のどこに強みがあるかで見極めます。デモが分かりやすくても、権限設計や運用移行は弱いことがあります。
提案の見栄えより、前提や除外範囲を同じ様式で比べます。リスクや成果物、導入後の責任も、同じ並びで示してもらいます。
類似案件の経験と担当体制
導入社数より、近いユーザー規模や、SaaSとオンプレミスの混在、委託先やゲスト管理の経験を確かめます。複数会社の統合や監査要件に対応した経験も、あわせて聞きます。
提案営業に加えて、要件定義から運用までの責任者とも会っておきます。再委託先がいる場合は、アクセスできる情報と作業場所を確かめます。ログ取得や秘密保持、契約終了時の削除方法も、聞いておきます。
同じ比較表での初期費用と総額
比較表には、要件定義、設計、製品・ライセンスの項目を並べます。アプリ連携は1本あたりの単価で示し、移行やテストに加えて、教育と本番切り替えも入れます。
保守や運用代行、追加変更、税・諸経費も、項目をそろえます。連携本数が未確定なら、候補会社には、標準連携、API連携、古いオンプレミス連携をそれぞれ1本の代表例として、単価を求めます。
年額ライセンスや最低契約数、ユーザー追加の単価、解約時のデータ返却費も、比較表に含めます。3年程度の総額で比べれば、初期費用だけの競争を避けられます。
見積段階でのリスクとベンダーロックインの抑制
見積の段階で、費用の増加やベンダー依存につながる条件を確かめます。
- 費用・変更：別途見積の前提、追加費用の条件、仕様変更の承認方法の確認
- 納期・障害：納期が遅れた場合の扱いと、障害時のエスカレーション
- 移行性：SAMLやOpenID Connectなどの標準プロトコルを使い、設定一覧、権限一覧、ログ出力仕様、アプリ側の接続情報を納品対象に含めます
前提や未確定事項を示さないまま「要件確定後に別途見積」と答える提案は、後から金額が増える可能性があります。そこで、契約と設計の両方で、他社へ移行できる状態を確保しておきます。
IPAは、2025年7月の不正ログイン相談が144件に達したと公表し、パスキーや多要素認証の設定を呼びかけています（出典: IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。
MFAの導入だけで完了とみなさず、例外承認やアカウント復旧を、退職者停止、権限レビュー、ログ監視と組み合わせられるかを確かめます。
アクセス管理システムの発注・外注でよくある質問
発注前に確かめたい、費用や既製サービスと開発の境界についての質問に答えます。
アクセス管理システムは開発会社と製品ベンダーのどちらに発注すべきですか？
SaaS中心で標準連携が多い場合は、製品ベンダーや導入支援会社が候補になります。複数会社やオンプレミス、独自の権限が絡む場合は、SIerや開発会社を検討します。
自社サービスの認証・認可では、IDaaSなどを使ったうえで、独自の処理を開発会社へ委託する形もあります。判断の軸は、要件定義から運用移行まで責任を持てるかどうかです。
アクセス管理システムの初期費用はどのくらいですか？
標準コネクタ中心で50〜200ユーザーなら、初期費用は50万〜300万円が推定の幅です。
オンプレミス・人事連携、権限申請、ログ監査、複数会社統合が絡むと300万〜1,000万円、大規模統合では1,000万〜3,000万円以上の可能性があります。
これは公開ライセンス価格と類似案件から整理した推定で、確定額ではありません。見積もりでは、条件（アプリ数、連携方式、移行データの品質、運用委託の範囲）をそろえて比べます。
RFPを作る前にユーザー数を正確に確定する必要がありますか？
ユーザー数が確定していなくても、準備は進められます。利用者は、従業員・委託先と、顧客・サービスアカウントに分けて、現在の数と3年後の想定数を幅で示します。
IDaaSの最低契約数や単価を比べるには、100・500・1,000ユーザーの3案が使えます。休眠、共有、検証用のIDは、数え方もそろえておきます。
アクセス管理システムの外注で失敗しやすい点は何ですか？
SSOとMFAだけを先に入れて、退職者停止や過剰権限を後回しにすると、失敗しやすくなります。委託先、サービスアカウント、ログ監査の扱いも、後回しにされがちな項目です。
設定や連携仕様を受け取れないまま、変更のたびに追加費用がかかる場合もあります。そこで、RFPには運用要件と納品物を含めておきます。
受け入れテストでは、異動や退職、障害、緊急権限の場面を確かめます。契約終了時のデータ返却まで、あわせて決めておきます。
まとめ
発注では、論理アクセスと入退室管理を分けて考えます。次に、ユーザーやアプリ、権限を一覧にし、ログと運用責任も洗い出します。標準IDaaS、SIerの統合設計、自社サービスの認可開発は、目的に応じて使い分けます。
RFPでは、MUST・WANTの区分、受け入れ条件、成果物をそろえます。費用は、ライセンスから保守、レビュー、監視までを含めて、複数年の総額で比べます。
発注前の要件と総額の整理
公開ライセンス価格と、要件から推定した導入費は分けて考えます。3社程度に同じ前提で相見積もりを取り、差額の理由を確かめます。
導入後の自社運用を見据えた委託先の決定
導入日にログインできるかどうかは、出発点にすぎません。退職者停止や異動に伴う権限変更、委託終了、定期的なアクセスレビューも、その後に必要になります。
設定に関する資料（設定情報、権限マトリクス、連携仕様、障害対応手順）は、自社でも持つようにします。例外承認と復旧方法を訓練できる委託先なら、安全性と運用継続性を両立できます。
▼全体ガイドの記事
・アクセス管理システム開発の完全ガイド
▼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を創業。