MFAのシステム発注は、対象システムとリスクの棚卸し、RFPと要件整理、PoCと段階導入、運用の引き継ぎの順に進めます。
運用の引き継ぎまで見通しておくと、導入後に発生する業務負担を具体的に見積もれます。
▼全体ガイドの記事
・MFAのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
MFAのシステムを発注・外注する前に押さえる全体像
MFAの発注では、認証アプリを選ぶより先に、守る業務と利用者、適用条件を決めておきます。既存の基盤に設定を加えるだけで済む場合もあるため、発注側は新しい製品を選ぶ前に今の環境を確かめます。一方で、SAMLやOIDCに対応していない古いシステムは、中継サーバーや認証ゲートウェイを介して接続する場合があります。
認証画面以外も含むMFAの開発範囲
ログイン時の追加認証だけを設計すると、紛失時の再登録や退職者の失効が抜けやすくなります。そこで、認証器の登録から失効までを設計の対象に含めます。
- 登録・回復：紛失時の再登録と、管理者による承認。
- 運用管理：退職者の失効、緊急用アカウント、認証失敗の通知。
- 認証方式：SMS・メールOTPは、SIMスワップ、メール侵害、リアルタイム型フィッシングの影響を受けます。
- 高リスク環境：管理者、VPN、財務・個人情報には、FIDO2、パスキー、セキュリティキー、端末証明書などを優先します。
本人確認なしで電話による解除を認めると、認証そのものより回復窓口が弱点になります。
NISTの「SP 800-63B-4」は2025年7月に公開され、認証器の保証レベルに加えて、登録・管理・失効も整理しています（出典: NIST、2025年）。
IDaaS設定支援・連携開発・認証基盤構築の発注形態
発注形態は、Microsoft EntraやOktaなどの既存IDaaSの設定支援、連携開発、認証基盤構築に分かれます。
- IDaaS設定支援：条件付きアクセス、認証アプリ、グループ設定、操作マニュアルの整備。
- 連携開発：独自Webアプリやオンプレミス環境を、SAML、OIDC、LDAP、RADIUSなどでつなぐ作業。
- 認証基盤構築：複数拠点・数千人以上、複数方式、24時間運用、災害対策を含む構築。
Microsoft 365など標準対応サービスだけであれば、個別機能を作らずに始められます。基本MFAは無料の場合がありますが、高度な制御はライセンスの確認が必要です（出典: Microsoft Learn、2025年時点掲載情報）。
連携開発は、認証の中核を製品に任せ、業務側のログイン、ユーザー同期、権限マッピング、ログ連携を開発する形です。そのため、スクラッチで作るより保守の負担を抑えやすくなります。一方で、認証基盤構築は費用が大きくなり、全社のIDライフサイクルと監査を統一したい企業に適しています。
MFAのシステム発注・外注の進め方
発注の作業は4段階に分け、現状の棚卸しとリスク分類、RFPと要件整理、PoCと段階導入、運用の引き継ぎの順に進めます。各段階で条件を固めてから次へ進むと、失敗を減らせます。逆に、製品や開発会社を先に決めると、古いプロトコルへの対応や紛失時の復旧が後から加わり、見積もりと納期が膨らみやすくなります。
対象システムとリスクの棚卸し
企画段階では、対象システムごとに、利用者数や内外ユーザー、管理者数を一覧にします。接続端末、現行認証方式、ユーザー情報の管理元も、同じ一覧に書き加えます。
現行の認証方式によって必要な対応が変わります。たとえば、SAML・OIDC対応のSaaSと、ID・パスワードを画面内で照合する古いシステムでは、取るべき手段が異なります。また、VPNやVDIでは、RADIUS、証明書、端末管理製品との連携が必要になることもあります。
特権管理者やリモート接続者は、高リスク群として分けておきます。財務・個人情報の担当者や外部委託先なども、同じ群に入ります。
- 高リスク群：パスキーやFIDO2の優先。
- 一般利用者：認証アプリを併用する方法。
- プッシュ通知：プッシュ爆撃への対策となる番号照合と通知回数の制限。
発注側は、利用者ごとに方式を分けて、業務停止のリスクと安全性を両立させます。
RFPに盛り込む機能・連携・運用・成果物
RFPでは、各社の提案条件をそろえておくことが欠かせません。対象人数と増加見込み、対象アプリ数を書き、必須認証方式と代替方式、SSOの要否も記載します。Active Directoryや人事マスタとの同期、SCIM連携は連携条件として書きます。ログ保存期間やSIEM転送は運用の条件です。可用性、障害通知、問い合わせ窓口も明記します。
「MFA対応」とだけ書くと、受け取る側の解釈が分かれます。そのため、管理者には耐フィッシング方式を必須とし、退職処理から何分以内に止めるかも定めます。
登録・解除・再登録の画面と申請、本人確認も含めます。さらに、バックアップ認証器や緊急用アカウントの記録、管理者権限の分離も書きます。
- 設計・連携：設定一覧と連携仕様書の納品。
- 検証・運用：テスト結果、運用手順、切り戻し手順の指定。
- 利用者支援：教育資料とログ項目一覧も、対象に含めます。
納品物の条件を先にそろえておくと、見積価格だけでは分からない運用の質も比べられます。
PoCによる失敗シナリオの検証と段階導入
提案を受けたあとは、代表的なシステム一つと少人数の利用者でPoCを行います。正常なログインだけでなく、復旧や障害対応も試します。
- 端末紛失、機種変更、ネットワーク断、認証サーバー障害、時刻ずれを試します。
- アカウントロック、退職者の即時無効化、管理者交代を確認します。
- 登録失敗時のヘルプデスク対応を見ます。
- 成功率、ログイン時間、問い合わせ件数、復旧時間を測ります。
測った結果を使うと、導入後の負担を具体的に見積もれます。
本番展開は段階的に進め、まず基盤管理者とIT部門、次に特定部署、最後に全社へ広げます。各段階で登録完了率や問い合わせ件数、認証失敗率を確認し、復旧時間と例外申請数も見ながら、次の段階に進む基準を決めます。
全社一斉に必須化する場合は、緊急用アカウントとオフライン時の代替手段、切り戻し期限を先に決めて、業務停止を抑えます。
MFAのシステム開発費用の相場とコスト内訳
MFAの受託開発に限った公開見積は少ないため、業務システム一般の規模別相場と、認証APIや本人確認系の公開相場を組み合わせた推定です。
費用は、利用者数のほか、連携アプリ数や既存システムの改修可否で変わります。認証器の運用、可用性、監査要件も費用に響くため、予算はその前提と合わせて扱います。
初期費用は設定支援なら0〜60万円程度、連携開発なら100万〜1,500万円程度の目安
MFAの外注費は、既存IDaaSの設定支援から全社認証基盤の構築まで、対象規模に応じて幅があります。
- IDaaS設定・小規模展開：0〜60万円程度。
- 独自Webシステム1つへの追加：100万〜500万円程度。
- SSO・AD連携を含む5〜20システム：300万〜1,500万円程度。
- 全社認証基盤：1,000万〜5,000万円以上になる可能性があります。
自社で設定すれば、外注費がかからない場合もあります。ただし、ポリシー設計や管理者教育を外注すると、その分の費用が加わります。テストやマニュアル作成も、外注すれば費用に含まれます。
独自Webシステムの費用には、登録・解除・回復画面とAPI・SDK連携が入ります。監査ログや受入テストも含まれます。
複数システムへの展開では、ユーザー同期、権限マッピング、段階移行、ヘルプデスク設計が加わるため、単一アプリより工数が増えます。
全社基盤の推定は、複数拠点・数千〜数万人、高可用性を前提にしています。SIEMや端末証明書、災害対策、24時間運用も見込みます。いずれも前提条件を置いた推定で、MFA固有の公表価格ではありません。
ライセンス・SMS・保守・教育を含めたTCO
初期開発費だけで比べると、導入後に想定外の請求が起きます。そのため、TCO（総所有コスト）は継続費用も含めて計算します。
- 利用・認証：IDaaS月額、SMS・音声OTP送信料、FIDO2キーの購入・交換費。
- 基盤・監視：端末証明書、ログ保存・SIEM、監視費。
- 運用・支援：ヘルプデスク、利用者教育、脆弱性対応、障害時支援。
Oktaの価格ページでは、Workforce Identity Starterは1ユーザー月額6米ドルから、Essentialsは17米ドルからです。年契約などの条件があるため、そのまま円換算して予算を断定しないようにします（出典: Okta公式価格ページ、2026年確認）。
一方で、Microsoft Entraは、セキュリティの既定値による基本MFAを追加費用なしで使える場合があります。ただし、条件付きアクセスでユーザーや場所、端末状態、リスク別のルールを使う場合は、P1やP2などの確認が必要です（出典: Microsoft Learn、2025年掲載情報）。
既存契約に含まれる機能を確かめ、追加ライセンスと設定支援を分けておくと、二重契約を防ぎやすくなります。
作業単位と変動条件で見る見積もり
見積書は、「MFA機能一式」のようにまとめず、作業ごとの内訳で確認します。
- 設計：要件定義と基本設計。
- 構築：認証基盤設定、アプリ連携、ユーザー同期、登録・回復画面。
- 運用準備：ログ・監視、テスト、移行、教育、保守。
業務システム一般では、要件定義・設計10〜24%、実装48〜50%、テスト15〜17%の配分を仮定する考え方があります。特に、MFAでは認証器の登録・回復テストや連携試験が品質に直結します（出典: NotebookLM Q&A「業務システム全般_16」、2026年作成ノート）。
変動条件として、利用者数や対象アプリ数、対象プロトコルを記載します。SMS量やログ保存期間、冗長化、休日・夜間対応も、見積もりの前提として書いておきます。
保守運用費は、初期開発費の年15〜25%程度を仮置きします。ライセンス、SMS、キー交換費は別に積算します。費用範囲を分けておけば、運用を含まない安価な初期見積もりとの比較ミスを避けられます。
委託先の選定と見積比較で確認するポイント
IDaaS設定やオンプレミス・ネットワーク連携、FIDO2、端末証明書の扱いは、会社ごとに得意領域が異なります。そのため、委託先は製品販売力だけでなく、既存業務や運用に適合するかで評価します。
同じ条件のRFPを渡し、技術と体制、金額、将来の変更しやすさを分けて比べます。
既存システムとの連携実績と認証方式の実装力
似た認証連携の実績は、製品名だけでなく、構成図と課題も示してもらいます。
- 認証・連携：SAML、OIDC、WebAuthn、RADIUS、LDAP、SCIM。
- 社内基盤：Active Directory、人事マスタ、SIEM。
- 古いシステム：画面改修、リバースプロキシ、認証ゲートウェイ、端末証明書。
古いシステムは接続の方法が複数あるため、選択肢を比べられる会社が向いています。
SMSやメールOTPは「二要素だから安全」と扱わず、方式の安全性を確かめます。そのうえで、プッシュ爆撃、SIMスワップ、フィッシング、リプレイへの対策を質問します。認証器の不正登録についても聞いておきます。
たとえば、NTTデータは2026年4月にFIDO2準拠のパスキー対応サービスを開始しました。既存MFA等との併存、段階導入、24時間365日運用を案内しています（出典: NTTデータ、2026年4月）。
また、現在のMFAだけでなく、将来のパスワードレス化も提案できるかが評価材料になります。
見積書の含む範囲・含まない範囲・前提条件
各社の費目と範囲を表にそろえ、合計金額だけで順位を決めないようにします。
- 開発作業：要件定義、設計、設定、個別開発、テスト、データ移行。
- 導入支援：教育、リリース支援、保守。
- 継続費用：ライセンス、外部サービスの従量課金。
特に、「既存環境がSAML対応」「利用者情報が整備済み」「顧客がテストデータを用意」などの前提は、金額に隠れやすい項目です。
価格差が大きい場合は、対象アプリ数やテストシナリオ、ログ保存を確かめます。障害対応時間や納品物、責任範囲も見ます。さらに、現場ヒアリングが少ない見積もりは、後から追加開発になりやすいです。
過剰な冗長化や未使用の機能は、段階導入に分けておくと、初期費用を抑えられます。
要件の確度と変更の多さで選ぶ契約形態
要件が固まった範囲は請負、環境調査やPoCのように柔軟に進める部分は準委任と、契約を分けて考えます。どちらか一方に寄せきると、それぞれ起きやすい問題があります。
- 請負契約：要件が固まった範囲で、成果物と納期、受入条件を明確にできます。
- 準委任契約：環境調査、PoC、段階導入の改善を柔軟に進める形です。
- 請負に一本化：未知の連携条件や変更費用をめぐり、対立が起きやすくなります。
- 準委任に一本化：成果物や完了基準が曖昧になり、予算上限を管理しにくくなります。
契約では、認証情報とログの所有権、個人情報の扱いを確認します。再委託や脆弱性対応、SLA、障害連絡も、契約で取り決めておきます。
ベンダーを変える場合に備えて、設定やソースコード、文書の引渡しと、移行支援の範囲も決めておきます。
MFAが停止すると利用者全体がログインできなくなるため、復旧目標や切り戻し、緊急用アカウントを契約書や運用合意書に残します。
よくある質問
MFAの発注で相談が多い疑問をまとめています。自社に合う方式や費用は会社によって異なるため、RFPの前提条件を整理する材料として使ってください。
MFAのシステム開発を外注するといくらかかりますか？
既存IDaaSの設定支援は0〜60万円程度、Web業務システム1つへの追加は100万〜500万円程度が推定の目安です。
SSO・AD連携を含む複数システム展開は300万〜1,500万円程度です。一方、全社基盤などは1,000万〜5,000万円以上の可能性があります。
これらは、連携数や運用要件を前提にした推定で、MFA単体の公開定価ではありません。
Microsoft 365を使っていてもMFAの開発を外注する必要がありますか？
Microsoft 365など標準対応サービスだけであれば、既存ライセンスの設定と利用者教育で始められる場合があります。
VPNやオンプレミス、VDI、独自Webアプリが対象に入る場合は、設計や連携開発、テストの外注が役立ちます。端末証明書やSIEM連携も含める場合は、その分も外注の範囲に入ります。
発注側は、対象システムのプロトコルとユーザー情報の管理元を調べ、設定支援と個別開発の範囲を分けます。
SMS認証とパスキーはどちらを選ぶべきですか？
導入しやすさの点ではSMSも候補になりますが、管理者操作や機密情報を扱う環境では、FIDO2、パスキー、セキュリティキーを優先します。
SMSやメールOTPを禁止できない場合は、高リスク操作では使わせず、バックアップ手段も厳格に管理できます。
回復時の本人確認を強化し、端末の状況、オフライン利用、紛失時の復旧方法も含めて方式を決めます。
MFAの外注は請負契約と準委任契約のどちらがよいですか？
範囲と受入条件が固まった設定や連携開発は請負、現状調査やPoC、段階導入、運用改善は準委任が検討しやすいです。また、調査とPoCを準委任、本番開発を請負とする組み合わせもあります。
契約形式にかかわらず、成果物と完了基準、変更手続きを明文化します。障害時の責任や、設定とソースコードの引渡しも、文章で残しておきます。
まとめ
MFAの発注は、認証アプリの費用より先に、対象システム、利用者、管理者権限を整理して決めます。IDaaS設定、連携開発、全社基盤のどれを範囲に含めるかも定めます。方式や同期、登録・回復の扱いも含めて考え、監査ログと障害対応も合わせて整理します。
発注前に固める対象範囲とRFPの受入条件
RFPには、SAML・OIDC・WebAuthnなどの連携条件や耐フィッシング要件を具体的に記します。認証器の登録・失効、紛失時の復旧も、同じRFPに書いておきます。
ログ保存やSLA、教育、納品物も指定します。見積もりは、開発とライセンス、従量課金を分けて出してもらいます。保守や教育も、別の項目にしてもらいます。
含まれる範囲を同じ条件で比べ、金額よりも、安全に使い続けられる運用かで判断します。
認証対象の棚卸しと小さなPoC
最初は対象を絞ってPoCを行い、運用上の課題を確かめてから広げます。
- 全社一斉の必須化を急がず、管理者や高リスク業務から対象を選びます。
- 代表システムでPoCを行い、連携の難所と問い合わせ量を確認します。
- 将来のパスキー移行も含めて環境を整理し、複数の委託先に同じRFPを渡します。
MFAは、認証器のライフサイクルや権限、回復、監査まで含めて運用する仕組みです。
▼全体ガイドの記事
・MFAのシステム開発の完全ガイド
▼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を創業。