多要素認証システムの発注は、現状の棚卸し、要件と契約範囲の整理、委託先の比較、パイロット導入の順に進めると、安全に段階展開できます。
発注形態や契約、費用相場、委託先の選び方も、順に確認していきます。全体像は多要素認証システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・多要素認証システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
多要素認証システムを外注するときの全体像
多要素認証システムは、パスワードに別の認証要素を足す画面改修を超えて、一つの運用として設計するものです。
対象には、利用者の登録・異動・退職から、認証ログ、失敗時の復旧までを含めます。
発注時は、認証機能だけでなく、ID管理・認可・監査、移行、運用のどこまでを委託先に任せるかを決めます。
たとえば、契約管理システムや電子署名、外部弁護士向けポータルでは、端末紛失や緊急復旧も対象に含めます。
多要素認証と二段階認証の違い
多要素認証と二段階認証は、使う認証要素の種類と数で区別できます。
- 多要素認証：知識・所持・生体情報から異なる要素を二つ以上使う
- 二要素認証：多要素認証のうち、二つの要素を使う方式
- 同じパスワード：二回入力しても多要素認証にはならない
IPAは、IDと一つ目のパスワードが不正利用されてもログインを防ぐ効果がある方式として、多要素認証を説明しています。ただし、リアルタイム型フィッシングでは、OTPを突破する攻撃も想定されます。
契約承認者や管理者については、TOTPだけでなくFIDO2やパスキーを優先する方針をRFPに含めます。そうすると、製品選定の基準が明確になります。
発注範囲の広がり
ログイン機能だけを発注すると、退職者を即時停止できない、紛失時に管理者が復旧できない、契約書を削除した操作の証跡が残らない、といった問題が起きやすくなります。
見積もりには、利用者ライフサイクル、SSOまたはAPI連携、認証方式を含めます。
さらに、認可との役割分担、監査ログ、障害時の復旧も、同じ見積もりに入れます。利用者教育と保守窓口も加えて、これらを一つの業務フローとして確認します。
発注の進め方と順番
発注は、まず現状把握とリスク分類を行い、方式選定、RFP作成、提案比較へと進めます。そのうえで、パイロットから段階展開に移ります。全社や全アプリを一括で移行せず、影響の大きい対象から小さく検証します。
管理者や契約承認者の範囲で復旧の負荷を確かめてから、対象を広げます。
段階導入により、現場の業務への影響も抑えやすくなります。
最初に行う棚卸しの対象
認証を必要とするサービスを洗い出すと、連携と運用の対象を定められます。棚卸しの対象には、次のようなサービスがあります。
- 社内基盤：Microsoft 365、Google Workspace、Active Directory
- 接続環境：VPN、リモートデスクトップ
- 業務アプリ：契約管理システム、電子署名、社内ポータル
各サービスについて、利用者、管理者、外部利用者を整理します。共有アカウントやサービスアカウントも、同じ一覧に加えます。あわせて、認証方式とログの保存先、停止までの手順も記録しておきます。
法務・契約の領域では、社員に加えて外部弁護士や取引先が利用者になります。
派遣社員や契約承認者も、利用者として整理します。
契約書の閲覧やダウンロード、承認は、操作ごとに分けて整理します。
削除と権限変更も、別の操作として扱います。
認証済みであることと、操作を許可する認可は別の要件です。そのため、誰がどの操作を、どの条件で許可されるかを委託先に確認してもらいます。
MUSTとWANTの分け方
要件は、今回必須、将来対応、採用しないの区分に分けます。理由と受入条件も付けておくと、提案を比べやすくなります。
- 今回必須：特権IDのMFA、退職者の即時無効化、高リスク操作の再認証
- 今回必須：認証ログの保管、管理者による緊急復旧
- 将来対応：全社へのパスキー展開、端末リスクに応じた条件付きアクセス
- 将来対応：外部利用者のセルフサービス
今回の要件を膨らませすぎると、製品比較の前提がそろわず、見積もりも比べにくくなります。一方で、WANTにあたる項目は、予算と納期を見ながら第2段階に回します。
受入条件は、「契約承認者はパスキーを必須にする」「認証失敗が5回続いたら管理者確認へ移る」のように、具体的に書きます。条件が具体的なほど、提案の差が見えやすくなります。
パイロット導入と本番移行の確認事項
パイロットでは、利用者が登録からログイン、端末変更、紛失申告、復旧まで完了できるかを確認します。
- 接続・端末：圏外、海外出張、社給端末と私物端末
- 利用形態：共有端末、外部利用者の招待
- 運用体制：管理者が不在の休日
ログイン成功率だけでなく、問い合わせ件数、復旧時間、管理者の作業時間も記録し、実運用の負担を確かめます。
本番は、対象グループを分けて段階展開し、旧方式を停止する時期を明確にします。並行運用が長すぎると旧方式が抜け道になり、短すぎると業務停止につながります。
移行判定には、重大な認証障害がないことと、ヘルプデスクの手順が完成していることを含めます。また、緊急用のブレークグラス管理者アカウントも、安全に保管します。
発注形態の選び方（クラウド・パッケージ・スクラッチ）
多くの企業では、MFA基盤にIDaaSや既存ライセンスを使い、独自に作る部分だけを連携開発します。そうすると、費用と安全性のバランスを取りやすくなります。
方式は、データの所在と既存環境から選びます。利用者体験や脅威への耐性、将来の運用体制も判断材料になります。
IDaaSを使う発注が向いている企業
Microsoft 365やGoogle Workspaceを使い、標準連携で業務アプリをつなげる企業は、IDaaSを軸に据えられます。
- 向いている環境：SAML、OIDC、SCIM連携を利用できる
- Entra ID P1：MFA、パスワードレス認証、条件付きアクセス、イベントログを含む
- 既存契約：Microsoft 365 E3やBusiness Premiumに含む場合がある
- 委託範囲：導入設計や移行後の運用支援も比較する
Entra ID P1の公式表示では、年払いで1ユーザーあたり月額899円相当です。
IDaaSでも導入作業は残ります。テナント設計、権限整理、レガシーアプリ連携、ログのSIEM転送は、構築会社に委託します。利用者教育と復旧手順も、あわせて委託の対象に含めます。
ライセンス販売だけの会社と、運用まで支援する会社は分けて評価し、支援範囲を確認します。
パッケージ型・ハイブリッド型を選ぶ場合
閉域網やオンプレミスのActive Directoryを使う場合は、パッケージ型やハイブリッド型を検討します。
- 選定条件：古いWebアプリ、特殊端末、厳格なデータ保管要件
- 移行：既存資産を残し、SAML対応アプリから移行できるか確認
- 責任分界：保守期限と脆弱性対応の担当を確認
- 費用：サーバー、冗長化、バックアップ、証明書、監視、パッチ適用も算入
提案書では、製品の標準機能と追加開発、顧客側の作業を分けて書いてもらいます。そうすると、クラウド型とも比べやすくなります。
スクラッチ開発を選ぶケース
認証体験が顧客向けサービスの競争力になる場合や、標準製品で対応できない場合にスクラッチ開発を検討します。
- 検討する要件：本人確認、認証API、高可用性、独自監査
- 長期の運用負担：暗号鍵管理、復旧、脆弱性対応、規格更新
- フィッシング耐性：認証方式の耐性を確認して選定する
- 開発要件：FIDO2、WebAuthn、鍵管理、レート制限、監査、第三者評価
NISTの2025年版SP 800-63B-4では、パスワードはフィッシング耐性を持ちません。また、手入力OTPは認証セッションに結び付かないため、耐性ありとは扱われません。
鍵のライフサイクルも要件に含め、開発後の運用体制まで見て判断します。
RFPと要件整理で外せない項目
RFPでは、製品名よりも、達成したい業務結果と制約条件を伝えることが中心になります。利用者数、アプリ数、認証方式を基本に記載します。そのうえで、移行や運用に関する例外、セキュリティ検証、納品物まで書き加えます。
必要な事項をそろえておくと、提案会社は同じ前提で見積もれます。次に、利用者とシナリオを整理します。さらに、連携と移行、復旧とログ、受入条件も定めます。
利用者と認証シナリオの書き方
利用者と操作ごとに認証条件を分けておくと、RFPで必要な運用を指定できます。
- 利用者区分：社員、管理職、管理者、委託先、外部弁護士、取引先、顧客
- 利用者管理：登録、本人確認、停止、再登録、権限変更
- 操作シナリオ：契約書の閲覧、承認、社外共有、削除
- 利用者数：現在数、同時利用者、MAU、外部利用者の増加
契約書の操作によって認証強度や再認証の要否が異なる場合は、シナリオごとに条件を指定します。
ユーザー単位課金とMAU課金では見積もりの基準が変わるため、人数の定義をそろえておきます。
共有・サービスアカウントには、人間と同じ方式を適用できない理由と、代替の統制を記載します。
連携とデータ移行の条件の指定方法
連携対象と方式を一覧にすると、標準機能と追加開発の境界が分かります。RFPには、次の対象を挙げます。
- 認証連携：SAML、OIDC、LDAP、Active Directory、SCIM
- 周辺システム：VPN、メール、端末管理、SIEM
標準コネクターと追加開発の有無、テスト環境の提供者も指定します。
標準連携が難しいレガシーWebアプリには、代理認証やリバースプロキシ、アプリ改修の提案を求めます。
既存利用者のデータ（ID、所属、メールアドレス、認証器情報）の移行方法も決めます。認証器の秘密情報を移せない場合には、再登録の案内と期限、未登録者へのフォローを計画します。
旧IDの削除、重複アカウントの統合、失敗時のロールバックも、RFPに含めます。
納品物には、移行設計書とデータ項目一覧を含めます。
復旧・ログ・受入条件を先に決める理由
多要素認証の運用では、利用者が認証できない状況への備えが成否を左右します。
- 復旧条件：端末紛失、機種変更、退職、管理者不在、認証障害、通信断、コード漏えい
- 復旧手順：本人確認と承認者を定め、メールだけの解除は慎重に扱う
- ログ：認証成否、利用者・端末・IP、ポリシー、管理者・復旧操作を記録
- 受入条件：認証、停止時間、操作追跡、重大障害時の復旧を測定可能にする
ログについては、転送の成否と保管期間も指定します。
受入条件は、「機能が動く」だけで完了としないように定めます。
契約形態の使い分け（請負・準委任）
要件が固まっていない調査や企画には準委任、成果物と仕様が定まった連携開発や設定には請負を使うのが実務的です。工程ごとに責任と変更ルールを分けておくと、追加費用を判断しやすくなります。
準委任契約の向き不向き
準委任契約は要件定義に向いています。一方で、調査や方式比較では前提が変わる可能性があります。
準委任でも、品質管理は必要です。
- 対象業務：RFP作成支援、移行計画、パイロット評価
- 契約条件：作業時間、体制、定例会、成果物を明確にする
- 品質・管理：スキル、報告、課題管理、レビュー、情報管理、再委託を定める
- 認証情報：作業権限、ログ取得、秘密情報の保管方法を確認する
請負契約で固定する成果物
請負契約では、作業範囲と検収条件を成果物として固定します。
- 開発範囲：対象アプリ・利用者、認証方式、連携仕様、画面、ログ、性能
- 受入・対応：試験の不合格条件、瑕疵期間、脆弱性修正範囲
- 費用・日程：移行、納期、ライセンスとクラウド費用の負担者
- 変更管理：追加工数、納期変更、影響調査、承認者を定める
- 納品物：仕様書、設定値、ソースコード、試験結果、運用手順書
変更管理の項目は、アプリの追加やパスキー対応の前倒し、外部利用者の増加に備えるためのものです。
納品物がそろっていれば、将来のベンダー変更にも備えられます。
工程ごとに契約を分けるときの注意点
工程ごとに契約を分ける場合は、成果物と責任のつながりを明確にします。
- 契約の例：調査・要件定義は準委任、構築は請負、運用監視は月額保守
- 工程間の引き継ぎ：前工程の成果物を次工程の入力資料にする
- 責任範囲：障害の切り分け、環境引き渡し日、移行失敗の責任者を定める
- 情報管理：秘密保持、再委託、保管場所、権限、事故報告、監査を確認
個人情報保護委員会のガイドラインを参考に、安全管理措置を契約と運用設計に反映します。あわせて、終了時のデータ返却・消去も定めます。
多要素認証システムの費用相場と内訳
費用は、ライセンスやAPI利用料、要件定義、連携開発、端末・認証器に分けて見ます。移行、教育、監視、保守も、費用の内訳になります。
公開価格は製品や課金単位を比べるための材料で、RFP作成や既存システム連携費は含みません。
ここに示す初期費用は、MFA単体の全国統計ではありません。リサーチノートの業務システム相場と公開料金をもとに置いた、相見積もり前の予算仮置きです。
製品・ライセンス費用の見積もり方
公開価格を比較するときは、課金単位と契約条件をそろえます。
- Microsoft Entra ID P1：年払いで1ユーザーあたり月額899円相当。1,000人なら月約89万9,000円
- Okta Starter：月額940円から。1,000人なら月約94万円
- Okta Essentials：月額2,670円から。1,000人なら月約267万円
- Oktaの年契約：最低額24万円の記載があります
いずれも税、契約条件、追加機能、導入支援費を除く製品料金です（出典: Microsoft Entraのプランと価格、2026年確認／Oktaプランと価格、2026年確認）。
Microsoft 365 E3やBusiness Premiumに含まれる場合は、追加費用が変わります。
契約では、対象ユーザーや最低購入数、支払いの周期を確認します。為替や値上げ、退職者の扱い、解約時のデータ取り出しも、契約条件に含めて見ます。
導入・連携開発の費用相場
導入費は、対象の規模と連携範囲に応じて、次の幅を予算の仮置きにします。
- 設定中心：初期30万〜150万円、期間2〜8週間程度
- 複数アプリ連携：初期100万〜500万円、期間1〜3か月程度
- 大規模統合：初期500万〜1,500万円、期間3〜6か月程度
- 独自スクラッチ開発：初期1,500万〜4,000万円以上、期間6〜12か月以上となる可能性
設定中心の範囲は、既存ID基盤と管理者登録です。金額は、ユーザー数やアプリ数によって変わります。
複数アプリ連携には、SSOや条件付きアクセス、ログ設計が含まれます。テストやヘルプデスクの準備も、この範囲に入ります。なお、大規模統合は、複数拠点や数千ユーザー、VPNや古いWebアプリを対象とする場合の範囲です。
金額は、一般的な業務システムの工程と人月の相場を、MFAの前提に合わせて推定したものです。公開統計ではないため、提案書の内訳を必ず確認します。
ランニングコストに含める項目
ランニングコストは、製品利用料だけでなく運用作業も含めて見積もります。
- 利用料：ライセンス、SMS、クラウド、認証器、端末管理
- 運用費：監視、問い合わせ、脆弱性対応、バックアップ、アクセスレビュー
- SMS課金例：日本向けは1通0.03米ドル、最初の1日10通は無料条件あり
- 保守費：初期開発費の年5〜15%程度を仮置き
Google Cloud Identity Platformは、電話認証とMFAを送信単位で課金します（出典: Google Cloud Identity Platformの料金、2026年確認）。
為替や利用量によって、金額は変わります。
24時間監視や休日対応、脆弱性対応の有無、利用者問い合わせの扱いによって、保守費は変わります。初年度の総額には、製品・導入費のほか、案内や端末配布、教育、ヘルプデスク増員も含めて見ます。
委託先の選び方と見積比較のポイント
委託先は、既存環境への適合、移行・復旧の設計力、運用を引き継ぐ力で選びます。知名度や見積総額は、その判断を補う材料にとどまります。
IDaaS販売代理店、認証製品の構築会社、業務システム開発会社では、得意領域が異なります。そこで、自社の課題に近い実績を持つ会社を、同じRFPで比較します。
委託先の実績の確認項目
実績が自社の利用者やシステムに近いかを確かめ、実装から運用までの担当体制も確認します。
- 実績の条件：利用者数、アプリ数、既存ID、外部利用者、移行期間、運用体制
- 類似案件：契約管理、電子署名、VPN、リモートワーク、特権ID
- 担当者：要件定義、構築、セキュリティ試験、運用引き継ぎの予定者
- 製品・責任：移行可能性と障害窓口、仕様変更、更新担当を確認
特定の一製品に誘導せず、Microsoft Entra、Okta、Google Cloud、オンプレミス製品の中から、既存契約に合う提案をするかを確認します。
提案担当者に加えて、要件定義から運用引き継ぎまでを担う予定のメンバーとも面談すると、担当分担を事前に明らかにできます。
見積もりの比較項目
見積もりの項目を工程と実費に分けると、初年度の総額を比べられます。工程は、次の作業でそろえてもらいます。
- 設計・構築：要件定義、基本設計、詳細設計、設定・開発、連携
- 移行・運用準備：テスト、移行、教育、管理者訓練、保守
ライセンスやクラウド、認証器や端末、監視サービスなどの実費は、工程とは別にします。
移行や復旧が別見積もりになっていると、合計が安く見えても、初年度の総額は高くなる可能性があります。
同じ前提で三社程度に依頼し、見積書には「含む」「含まない」の別、前提条件、追加時の単価を記載してもらいます。
価格だけでなく、要件への適合やセキュリティ、移行計画を重み付けして評価します。運用体制や納品物、担当者の経験、契約条件も、あわせて評価の項目に入れます。
価格差が大きい場合は、工数や別計上の製品費、対象範囲の違いを確認し、範囲や前提も踏まえて判断します。
提案・契約で注意すべきリスク
提案の適合性と運用リスクは、次の観点で見極めます。
- 説明不足：標準機能とうたいながら、レガシー、外部利用者、復旧、ログに触れない提案
- 過剰な断定：MFAですべての不正アクセスを防げると断定する
- 弱い例外運用：SMSのみ、または管理者例外アカウントを無制限に残す
- 契約確認：耐性、パスキー、権限、ログ、SLA、脆弱性通知、再委託、データ返却
選定前に、フィッシング耐性、パスキーの対応範囲、管理者権限の分離を確認します。
製品仕様と運用手順の両方で、自社のリスクに対して認証強度が足りているかを確認します。
よくある質問
発注前には、製品機能に加えて、既存契約、利用者の負担、費用、運用責任を確かめておきます。
Microsoft 365やGoogle Workspaceがあれば外注は不要ですか？
ライセンスにMFAや条件付きアクセスが含まれていても、アプリ連携や移行、復旧の作業は、別途必要になる場合があります。ID棚卸しや教育、ログ監視が、そこに含まれない場合もあります。
標準機能の範囲を確かめたうえで、設定だけを委託するか、運用設計まで任せるかを決めます。
SMS認証とパスキーはどちらを発注すべきですか？
利用者の環境と業務リスクで決めます。とくに、管理者や契約承認など高リスクの操作には、フィッシング耐性を持つパスキーやセキュリティキーを優先します。
SMSは導入しやすい一方で、SIMスワップや電話番号変更、海外利用の影響を受けます。そのため、低リスクの用途や代替手段として位置付け、復旧方法も含めて比較します。
小規模企業でも数百万円の予算が必要ですか？
小規模企業でも、導入範囲によって初期費用の目安は変わります。見積もり前の予算感を、範囲ごとに整理します。
- 設定中心：対象アプリと利用者が少ない場合、初期30万〜150万円程度を予算仮置きにできる可能性があります
- 複数アプリ連携：端末展開、外部利用者、監査ログ、教育を含むと100万〜500万円程度のレンジに広がります
- レガシー環境・独自開発：含める作業によって、費用はさらに増える可能性
対象範囲を分けて段階ごとに見積もると、必要な作業と予算の対応を判断しやすくなります。
まとめ
多要素認証システムの発注では、製品を買うだけでなく、既存ID基盤とアプリの棚卸しや、利用者と高リスク操作の分類が必要です。
発注要件には、認証方式や復旧、ログに加えて、移行、教育、保守も含めます。
製品費、導入費、運用費を分けたRFPを作成し、同じ前提で複数社の提案を比べます。
準委任で調査と要件定義を行い、仕様が固まった連携開発を請負にする方法もあります。
発注前に決めるべきこと
全社一括で完成させず、管理者や契約承認者、リモートアクセスなど影響の大きい対象でパイロットを行います。段階展開の前には、復旧の負荷を確かめておきます。
契約書には、成果物と検収、変更管理を記載します。脆弱性対応、データ返却、運用引き継ぎも書いておきます。契約形態と責任範囲は、工程に合わせて定めます。
委託先選定で重視すること
判断は、対象範囲と前提をそろえた初年度総額で行います。既存ライセンスやレガシー連携、外部利用者の扱いを確認し、端末紛失時の復旧と監査ログも見ます。
パスキー対応と、導入後の問い合わせ体制も質問します。そして、自社の運用担当者が続けられる提案を選びます。
▼全体ガイドの記事
・多要素認証システム開発の完全ガイド
▼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を創業。