MFAのシステム開発は、要件整理から始めて、方式の選定、設計・開発、テスト、段階的な稼働、運用改善へと進みます。各段階で、認証に失敗したときも業務を続けられるかを確かめながら、安全な認証を社内に定着させていきます。
▼全体ガイドの記事
・MFAのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
MFAのシステム開発の全体像
MFAは、パスワードだけに頼らず、知識・所持・生体情報など異なる要素で本人を確認する仕組みです。
設計では、認証器の登録・削除や、端末紛失時の復旧も含めます。業務システムでは、さらに権限変更、監査ログ、ヘルプデスクまで範囲に入ります。
異なる認証要素の組み合わせ
MFAでは異なる種類の要素を組み合わせるので、認証情報を知識・所持・生体の3つに分けて整理します。
- 知識情報：パスワードやPIN
- 所持情報：スマートフォン、認証アプリ、セキュリティキー、端末証明書
- 生体情報：指紋や顔認証
パスワードと秘密の質問は同じ種類の要素なので、組み合わせても強度を十分に高められません。
パスワードと認証アプリのワンタイムコード、またはパスキーと端末の生体認証のように、種類の違う要素を組み合わせます。
方式によって、二つの要素を使った場合の安全性は異なります。たとえば、SMSやメールのOTPは導入しやすい一方で、SIMスワップ、メール侵害、リアルタイム型フィッシングの影響を受けやすい方式です。
管理者、VPN、財務情報や個人情報を扱う画面では、FIDO2やパスキーなど公開鍵暗号方式を優先します。
CISAもFIDOやPKIによるフィッシング耐性MFAを推奨しています（出典：CISA「Implementing Phishing-Resistant MFA」、2025年）。
認証基盤と業務システムの連携
認証基盤の連携先は、業務システムとID情報の両面から整理します。
- システム連携：SAMLやOIDCによる、Webアプリ、SaaS、VPN、VDIとの接続
- ID連携：Active Directory、LDAP、人事マスタからの入社・異動・退職情報の受け取り
- ID管理：SCIMなどによる、IDの作成・変更・無効化の連携
重要な操作だけ追加で認証を求める、ステップアップ認証も有効です。たとえば、通常の閲覧はSSOで通し、給与データの出力、振込先変更、管理者設定の更新ではパスキーなどを求めます。
全体の構成は、利用者、認証基盤、業務システムの三つに分けられます。
IDマスタや監査・運用基盤も、この構成の中で一緒に整理します。
条件付きアクセスでは、ユーザーや役職、端末の管理状態を判断に使えます。さらに、IPアドレスや場所、時間、リスクスコアも使えます。これにより、一律の負担を避けながら保護を強められます。
既存環境に合わせたMFAのシステム選定
MFAのシステムは、既存環境に合わせて選びます。Microsoft 365中心かGoogle Workspace中心かで、連携方法やライセンス、移行工数が変わるためです。
オンプレミスのADや古いVPNが多い環境でも、連携方法を同じ観点で確認します。
既存の認証基盤を活かし、独自の要件だけを追加で開発する方式は、費用と拡張性のバランスを取りやすい選択肢です。
Microsoft 365・Entra ID中心の場合の既存ライセンス確認
Microsoft 365を使っている場合は、まずEntra IDのテナントとプランを洗い出します。管理者と対象アプリも一覧にします。そのうえで、基本MFAと条件付きアクセスの要件を確認します。
- 基本MFA：Entra ID Freeでは、セキュリティの既定値で利用できる場合があります。
- 条件付きアクセス：対象者や条件を指定する機能です。
- 適用範囲：管理者、外部ゲスト、個人端末、SMS例外の扱い
条件付きアクセスにはP1またはP2が必要です（出典：Microsoft Learn「Microsoft Entra 多要素認証のバージョンと従量課金プラン」、2026年確認）。
基本MFAが無料で使えるかだけで判断せず、必要な機能とライセンスを見て決めます。
必須MFAの適用も段階的に進むため、既存テナントの強制状況と猶予条件を調べ、業務システムの移行計画と合わせます。
オンプレミス・古いVPN・独自Webアプリの連携方式の調査
SAMLやOIDCに対応した独自Webアプリは、IDaaSや統合認証基盤を認証プロバイダーとして接続できます。一方、古いアプリやVPN・VDIでは、次の方式を比較します。
- 古いアプリ：認証ゲートウェイ、リバースプロキシ、代理認証、RADIUS、端末証明書。
- VPN・VDI：接続時MFA、接続後の端末状態、アイドル時間、切断、再接続時の再認証。
- 利用環境：工場・店舗の共用端末、不安定な通信、スマホを持たない人も想定。
画面を自動操作する代理認証は、パスワード変更やエラー処理に弱く、将来の保守費用も高くなりやすい方式です。そのため、暫定策として使うなら、期限と移行先を先に決めておきます。利用環境に応じて、予備キー、端末証明書、オフライン時の手続きを検証します。
MFAのシステム開発の進め方｜6つのフェーズ
MFA導入は、製品を契約して設定を終えただけでは完了しません。認証失敗時の業務継続、退職者の確実な無効化、管理者操作の事後確認も、稼働の判定に含めます。
要件整理から定着までを6つのフェーズに分け、フェーズごとに成果物と判断基準を決めて進めます。
1. 要件整理｜守る対象と利用者の洗い出し
要件の抜けを防ぐため、対象システムと利用者、リスク、運用上の条件を洗い出します。
- 対象システム：業務システム、SaaS、VPN、VDI、API、管理画面の認証方式と利用者数。
- 利用者と業務：正社員、派遣社員、委託先、取引先、退職予定者、共用端末の利用者。
- リスク：管理者権限、機密データ、接続場所、停止時の影響。特権管理者、リモート接続、個人情報・決済情報を高リスク群とします。
高リスク群では、フィッシング耐性の高い方式を候補にします。要件定義書には、認証器の登録と紛失時の本人確認、予備器を書いておきます。さらに、ロック、停止、再登録の扱いも記します。
監査ログの保存期間、SIEM連携、障害時の連絡先も明記します。対象と利用者に漏れがなく、例外の承認者と見直し時期が決まれば、この工程は完了です。
2. 選定｜方式・製品・支援会社の比較
方式選定では、SMS・音声OTP、TOTP、FIDO2・パスキーを中心に比べます。ほかに、メールOTP、プッシュ通知、クライアント証明書も候補に入ります。それぞれの方式は、安全性、利用と復旧、費用の面から確かめます。
- 安全性：方式ごとのリスクとフィッシング耐性。
- 利用と復旧：使いやすさ、端末紛失時の復旧、オフライン対応。
- 費用：初期費用と継続費用、必要なライセンス。
一般利用者には認証アプリを使い、管理者や重要操作にはパスキーを必須にする、段階的な設計も考えられます。また、プッシュ通知を採用する場合は、番号照合や回数制限、リスク検知、利用者教育でプッシュ爆撃に備えます。
製品では、SAML・OIDC・SCIM・RADIUS・WebAuthnへの対応と、AD・人事マスタとの連携を確認します。加えて、条件付きアクセス、ログ出力、API、SLAも見ておきます。さらに、データ保管地域と契約終了時の移行性も確かめます。
既存ライセンス内の機能と追加料金の機能を分けたうえで、設定支援、個別開発、教育、保守の見積もりを、同じ条件で複数社に提示してもらいます。デモでは、正常なログインに加えて、紛失や退職、認証器の削除、ネットワーク断、管理者の交代も試します。
3. 設計・開発｜登録・認証・回復の一体設計
設計・開発では、利用者の流れと回復策を、安全な実装や監査ログと一体で決めます。
- 利用者の流れ：初回登録、通常ログイン、追加認証、認証器の追加・削除、紛失時の停止、本人確認後の再登録。
- 回復策：管理者承認付きの予備キー、本人確認記録、緊急用アカウントの監視を用意します。
- 安全な実装：秘密情報の保護と標準仕様を前提とする設計。
- 標準とログ：独自の暗号やトークンを避け、WebAuthnなどの標準仕様と実績あるライブラリを使います。
認証器を一つしか登録できない状態では、スマートフォンの故障や機種変更で業務が止まりかねません。
ログには、ユーザーや対象アプリ、認証方式、結果を含めます。さらに、端末やIP、時刻、認証器の登録・解除、管理者の変更も残します。ただし、OTPや秘密情報そのものは記録しません。
回復手順にもMFAを適用します。そのうえで、秘密鍵やリカバリーコードは平文で保存せず、トークンの有効期限やリプレイ防止、レート制限、CSRF対策、監査ログの改ざん防止を確認します。
4. テスト｜失敗・復旧シナリオの検証
テストでは、ログインの成功だけでなく、失敗と復旧の場面も確かめます。
- 登録と認証：登録、認証器の追加、認証の成功と失敗、連続失敗時の制限。
- 端末と利用者：ブラウザー・スマートフォンの変更、端末紛失、予備キー、退職者の無効化。
- 障害と権限：管理者権限の変更、時刻ずれ、通信断、IDプロバイダー障害。
受入テストでは、認証成功率と自力復旧の割合を測ります。加えて、ヘルプデスクへの問い合わせ件数、復旧時間、SIEMへのログ到着時間、拒否すべきアクセスの遮断率も数えます。
金融・個人情報・管理者操作の画面では、SMSやプッシュ通知も試し、フィッシング耐性の要件を満たす方式だけが許可されるかを確かめます。なお、NIST SP 800-63B-4は、登録・管理・失効を含む認証器管理を整理しています（出典：NIST「SP 800-63B-4」、2025年）。
5. 稼働｜管理者から始める段階的な展開
パイロットから始めて、確認しながら対象を段階的に広げます。
- 管理者、IT部門、協力的な利用者による試行
- 業務停止の影響が比較的小さい部署への展開
- 重要業務を担う部署と外部委託先への拡大
各段階で、認証成功率、登録完了率、問い合わせ内容、例外申請数、復旧時間を確認します。さらに、業務の重要度とサポート体制に応じて、展開の区切りを分けます。
全社案内には、対象日、登録期限、対応端末、登録手順を記します。また、予備手段、紛失時の連絡先、受付時間も入れます。切り戻し条件も、事前に決めておきます。
例外アカウントは無期限に残さず、対象者、理由、承認者、期限、代替策を台帳で管理します。失敗時も安全に業務を続けられる体制が整えば、稼働と判定します。
6. 定着｜認証状況の測定と運用改善
導入後は毎月、運用指標を確認して改善点を探します。
- 利用状況：MFA登録率、認証失敗率、パスワードリセット数。
- 復旧と支援：認証器の紛失・再登録件数、ヘルプデスク一次解決率。
- 統制と監視：例外期限の切れ、管理者権限の見直し、重大ログの検知時間。
問い合わせが多い部署を責めるのではなく、登録画面、マニュアル、端末環境、方式選択のどこに負担があるかを見つけます。
四半期ごと、または人事異動、製品変更、重大インシデント時に、認証方式と回復フローを見直します。
古いSMS例外を減らし、管理者のパスキー移行や人事マスタ連動の退職者無効化を確認します。認証器の管理を続けながら、利用状況を見て定着させます。
MFAのシステム開発にかかる費用相場とコストの内訳
MFA単体の受託開発価格は、公開情報が限られています。そのため、業務システム開発の規模感と、認証基盤・認証API連携の公開価格を組み合わせて、推定レンジを示します。
費用は、利用者数に加えて、連携対象数、SAML・OIDC対応、既存アプリの改修可否で変わります。認証器の運用やログ監視、可用性要件でも変わるため、前提条件付きの予算枠として扱います。
構成別の初期費用の幅
構成規模ごとの初期費用は、次の推定レンジです。
- 既存IDaaSの小規模設定：0万〜60万円程度。
- 1つのWeb業務システムへの追加：100万〜500万円程度。
- 複数システムの連携・段階移行：300万〜1,500万円程度。
- 全社認証基盤：1,000万〜5,000万円以上の場合があります。
既存ライセンスの範囲で自社設定すれば、外部委託費がかからないこともあります。ただし、ポリシー設計、管理者保護、回復手順、利用者教育は必要です。
1アプリ追加の推定には、TOTPやWebAuthnの対応と、登録・解除・回復画面を含みます。加えて、監査ログと受入テストも含みます。
複数システムの目安はSSO、AD・人事マスタ連携、段階移行を含みます。全社基盤は、数千人以上、複数拠点、オンプレミス混在の条件で費用が増える場合があります。冗長化やSIEM、端末証明書、24時間運用が加わると、さらに増えることもあります。
この数字は、MFA固有の公表相場ではなく、小規模50万〜1,000万円、中規模300万〜5,000万円という業務システムの一般相場と認証連携の工数から算出した推定です。
ランニングコストの内訳（ライセンス・通信・運用）
継続費用は、月額・年額の支払いを次のように分けて積算します。
- ライセンス：IDaaS・認証基盤の利用料、条件付きアクセス等の上位機能。
- 通信・機器：SMS・音声メッセージ、セキュリティキーや端末証明書の更新。
- 運用：ログ保管、監視、ヘルプデスク、障害対応。
Google Cloud Identity Platformは、多くの方式で月間アクティブユーザー数を課金の単位にします。一方で、電話認証とMFAユーザーは送信メッセージ単位です（出典：Google Cloud「Identity Platform pricing」、2026年確認）。
費用は、ユーザー数だけでなく、認証回数とSMS送信数を仮置きして試算します。
Microsoft Entraでは、基本MFAと条件付きアクセスなどの上位機能で、必要なライセンスが異なります。
OktaなどのIDaaSも、プラン、契約期間、最低契約額、オプションで費用が変わります。そのため、公式価格を円に換算しただけで費用を断定しません。
運用費は、初期開発費の年15〜25%程度を仮置きできます。これは一般的な保守予算の目安なので、ライセンスやSMS費用を含むかどうかは、見積書で確認します。
MFAのシステム開発で見積もりを取る際のポイント
利用者数とログイン画面数だけを示すと、後から追加費用が膨らむおそれがあります。そのため、見積もりの条件には、対象アプリ、IDマスタ、端末、認証方式を含めます。さらに、運用、移行、教育、保守も加え、初期費用と継続費用を分けて提示してもらいます。
各社に同じRFPを渡すと、価格に加えて含まれる作業と除外作業を比較できます。
RFPに書く対象範囲・連携・失敗時の運用
RFPには、規模、システム構成、連携先、運用条件を具体的に書きます。
- 規模：対象ユーザー数、ピーク時の同時利用者数、対象アプリ数。
- 構成・連携：クラウド・オンプレミスの内訳、SAML・OIDC・RADIUS・LDAP、AD・人事マスタ・SIEM。
- 環境：利用端末、認証方式、管理者数、データ保管地域、可用性、ログ保存期間。
- パスキー：対応ブラウザー、スマートフォン、セキュリティキー、端末交換、複数認証器、バックアップ。
RFPの条件をこの粒度まで揃えると、各社の提案範囲を比べられ、提案の差も確かめられます。
紛失や盗難、機種変更、退職、異動の場面を、要件に含めます。さらに、共有端末や外部委託先、通信・認証基盤の障害、時間外のヘルプデスク対応も加えます。
各シナリオで、利用者、管理者、セキュリティ担当、ベンダーの誰が何分以内に何をするかを確認します。たとえば、「認証失敗時は問い合わせ」とだけ書かれた見積もりには、運用設計が含まれない可能性があります。
認証と業務システムの両方を扱える開発会社の選び方
開発会社は、認証技術と業務システムの双方を扱えるか、提案内容と成果物を確認して選びます。
- 対応範囲：製品販売だけでなく、要件整理、アプリ改修、ID連携、移行、教育、運用設計。
- 実績と体制：SAML・OIDC・WebAuthn、オンプレミス・VPN、回復手順、ログ監視、SLA、担当体制。
- 引き渡し：設定値、ポリシー、連携仕様、テスト結果、運用手順書を自社に残せること。
提案書では、この項目ごとに実例を示してもらいます。
成果物を自社に残せるかは、将来のベンダー変更にも関わります。
登録・回復・教育・ログ監視を除いた最安の提案は、別発注で高くなる可能性があります。すべてをスクラッチで開発する提案では、認証暗号やトークン管理の保守負担が増えます。
標準プロトコルと実績のあるIDaaSを使い、独自業務の差分だけを開発する提案を基本にします。3社程度に同じ条件で相談すると、比較しやすくなります。
例外・回復・移行から見るリスクと追加費用
見積もりの漏れを防ぐため、例外、緊急対応、移行、見積明細を確認します。
- 例外利用者：個人端末を使えない人、海外出張者、共用端末利用者、認証器を失った人、未登録の委託先。
- 緊急用アカウント：常用禁止、強固な認証器、利用通知、利用後のパスワード変更、定期的な見直し。
- 移行：認証器等の移行・再登録、旧認証の停止時期、部署別期限、例外終了日。
- 見積明細：人数、回数、対応時間、成果物、追加単価。
例外利用者ごとに、本人確認と再登録の方法を定めます。そのうえで、既存の認証器やパスワード情報を移せるか、利用者に再登録を求めるかを確認します。
並行稼働が長引くと弱い方式が残るため、部署ごとの移行期限と例外終了日を設けます。
「移行支援一式」「保守一式」といった書き方だけの見積もりは、対象人数、回数、対応時間、成果物、追加単価に分けてもらいます。
よくある質問
発注の前には、方式の選択、既存環境との接続、運用開始後の復旧を確認しておく必要があります。よくある疑問に答えます。
MFAのシステム開発にはどのくらいの期間がかかりますか？
既存IDaaSの設定と小規模な展開であれば即日〜4週間程度、1つのWeb業務システムへの追加であれば1〜3か月程度が推定の目安です。
複数システムのSSO、AD・人事マスタ連携、段階移行を含む場合は2〜6か月程度、全社認証基盤やオンプレミス混在では6〜18か月程度になる可能性があります。
期間は、対象アプリ数、PoC、利用者教育、移行の段階数で変わります。そのため、開発期間と展開期間を分けて見積もります。
SMS認証とパスキーはどちらを選ぶべきですか？
導入しやすさを重視する場合はSMS認証が候補ですが、管理者、VPN、重要データ、重要操作ではパスキーやFIDO2などのフィッシング耐性方式を優先します。
SMSを残す場合は、低リスクの補助手段に限り、SIMスワップや番号変更、端末紛失への対応を決めておきます。一般利用者は認証アプリ、特権利用者はパスキーのように分ける方法もあります。
古いオンプレミス業務システムにもMFAを追加できますか？
追加できる可能性があります。まず、SAMLやOIDCへの対応状況、VPN・VDIの接続方式、既存ADやLDAPの構成を調べます。
直接改修できない場合は、認証ゲートウェイ、リバースプロキシ、RADIUS、端末証明書などを比較します。
代理認証を暫定利用するなら、保守期限、障害時の挙動、パスワード変更、将来のアプリ刷新を契約と設計書に明記します。
MFAは無料で導入できますか？
既存のMicrosoft Entra IDやGoogleなどに基本MFAが含まれていれば、ライセンス追加なしで始められる場合があります。
条件付きアクセスや独自アプリ連携、端末証明書、パスキー配布には、別の費用がかかる可能性があります。さらに、利用者教育、ヘルプデスク、監査ログ、SMS送信も、費用の対象になることがあります。
ライセンス費がゼロでも、設計、設定、テスト、保守を含めた総所有コスト（TCO）を確認します。
まとめ
MFA導入は、要件整理と環境に合う基盤の選定から始まり、登録・認証・回復・監査の設計、失敗時のテストへと進みます。認証方式を選んでログイン画面に足すことは、その一部です。
その後、管理者から段階的に稼働し、登録率や復旧時間を測りながら運用に定着させます。
6フェーズごとの成果物と完了条件
要件整理から定着までの6つのフェーズに分けて、各段階の成果物と完了条件を決めます。
認証器の登録・回復・失効と管理者の緊急対応を先に設計すると、全社展開後の問い合わせや業務停止を抑えやすくなります。
初期費用と運用費を合わせたTCO
初期費用と運用費を合わせたTCOで比べ、安全性と利用者の負担を、リスクごとに整理します。
- 費用範囲：ライセンス、SMS、認証器、教育、運用（監視・ヘルプデスク・保守）、将来の追加連携。
- 初期費用の目安：IDaaS設定0万〜60万円、1アプリ100万〜500万円、複数連携300万〜1,500万円。
- 全社基盤：1,000万〜5,000万円以上の場合があります。前提条件とライセンス等の別費用の確認が要ります。
- 安全性と発注条件：重要操作にパスキー・FIDO2を優先し、RFPで例外や復旧の扱いを明確にします。
各レンジは前提条件付きの目安です。RFPには、紛失・再登録、退職者の無効化、例外期限を記します。あわせて、障害対応、ログ保存、成果物の引き渡しも記します。
標準基盤を使い、独自業務の差分だけを開発することが、費用と安全性の両立につながります。
▼全体ガイドの記事
・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を創業。