MFAのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

MFAのシステム開発は、認証アプリを追加するだけではなく、認証方式・既存システム連携・本人確認情報の回復・監査運用までを一体で設計して進める取り組みです。

「どの方式を選べばよいのか」「Microsoft 365やオンプレミスの業務システムにも適用できるのか」「費用と期間はどの程度か」と悩む企業は少なくありません。本記事では、MFAのシステムを業務で使える状態まで導入する流れを、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分けて解説します。2026年8月時点の一次情報とリサーチ結果をもとに、費用の考え方、見積もりのチェック項目、失敗しやすい復旧・例外運用まで整理します。

▼全体ガイドの記事
・MFAのシステム開発の完全ガイド

MFAのシステム開発の全体像

MFAは、パスワードだけに頼らず、知識情報、所持情報、生体情報など、異なる要素を組み合わせて本人を確認する仕組みです。業務システムではログイン時の追加認証だけでなく、認証器の登録・削除、端末紛失時の復旧、権限変更、監査ログ、ヘルプデスクまで含めて設計する必要があります。

知識情報にはパスワードやPIN、所持情報にはスマートフォン、認証アプリ、セキュリティキー、端末証明書、生体情報には指紋や顔認証が該当します。パスワードと秘密の質問を組み合わせても同じ種類の要素に偏るため、MFAの強度を十分に高められません。例えば、パスワードと認証アプリのワンタイムコード、またはパスキーと端末の生体認証を組み合わせるように設計します。

ただし、二つの要素を使えばどの方式でも同じ安全性になるわけではありません。SMSやメールのOTPは導入しやすい一方、SIMスワップ、メールアカウント侵害、リアルタイム型フィッシングの影響を受けやすい方式です。管理者、VPN、財務情報、個人情報を扱う画面では、FIDO2やパスキーなど、公開鍵暗号を使うフィッシング耐性のある方式を優先します。CISAも、FIDOやPKIによるフィッシング耐性MFAを推奨しています（出典：CISA「Implementing Phishing-Resistant MFA」、2025年）。

全体構成は、利用者、認証基盤、業務システム、IDマスタ、監査・運用基盤の5つに分けて整理すると考えやすくなります。認証基盤はSAMLやOIDCでWebアプリ、SaaS、VPN、VDIと連携し、Active DirectoryやLDAP、人事マスタから入社・異動・退職の情報を受け取ります。SCIMなどを使えば、IDの作成・変更・無効化も連携できます。

業務上の重要操作だけに追加認証を要求するステップアップ認証も有効です。通常の閲覧はSSOで通し、給与データの出力、振込先の変更、管理者設定の更新などではパスキーやセキュリティキーを求める設計です。ユーザー、役職、端末の管理状態、IPアドレス、場所、時間、リスクスコアを条件付きアクセスに使うと、全員に一律の負担をかけずに保護を強められます。

MFAのシステムは既存環境に合わせて選ぶべきですか？

はい、既存環境に合わせて選ぶべきです。Microsoft 365中心の企業と、Google Workspace中心の企業、オンプレミスのADや古いVPNを多く残す企業では、同じMFA製品でも連携方法、必要なライセンス、移行工数が変わります。既存の認証基盤を活用し、独自要件だけを追加開発するハイブリッド方式が、費用と拡張性のバランスを取りやすい選択肢です。

Microsoft 365を利用している場合は、まずMicrosoft Entra IDのテナント、利用中のプラン、管理者アカウント、対象アプリを棚卸しします。Entra ID Freeではセキュリティの既定値による基本的なMFAを利用できる場合がありますが、対象者や条件を細かく指定する条件付きアクセスにはP1またはP2が必要です（出典：Microsoft Learn「Microsoft Entra 多要素認証のバージョンと従量課金プラン」、2026年確認）。

ここで重要なのは「無料でMFAを有効化できるか」だけで判断しないことです。管理者だけを先に強制するのか、外部ゲストを含めるのか、個人端末を許可するのか、SMSを例外として認めるのかを決める必要があります。AzureやMicrosoft 365の管理画面では必須MFAの段階的な適用も進んでいるため、既存テナントの強制状況と猶予条件を確認し、業務システムの移行計画と合わせます。

SAMLやOIDCに対応している独自Webアプリなら、IDaaSや統合認証基盤を認証プロバイダーとして接続できます。対応していない古いアプリでは、認証ゲートウェイ、リバースプロキシ、代理認証、RADIUS、端末証明書などを比較します。ただし、画面を自動操作する代理認証は、パスワード変更やエラー処理に弱く、将来の保守費用も高くなりやすいため、暫定策として期限と移行先を決めて使うことが大切です。

VPNやVDIでは、接続開始時のMFAだけでなく、接続後の端末状態、アイドル時間、セッション切断、再接続時の再認証も要件に含めます。共有端末、工場や店舗の共用アカウント、通信が不安定な現場、個人スマートフォンを持たない利用者がいる場合は、予備キー、端末証明書、オフライン時の手続きまで先に検証します。

MFAのシステム開発の進め方｜6つのフェーズ

MFAの導入は、製品を契約して設定をオンにすれば完了するプロジェクトではありません。認証に失敗したときも業務を継続できること、退職者を確実に無効化できること、管理者の操作を後から確認できることが、稼働判定の条件になります。ここでは、要件整理から定着までの6フェーズを、成果物と判断基準に沿って説明します。

最初に、業務システム、SaaS、VPN、VDI、API、管理画面を一覧にし、それぞれの認証方式、利用者数、利用者の種類、管理者権限、機密データ、接続場所、停止時の影響を記録します。利用者は正社員だけでなく、派遣社員、委託先、取引先、退職予定者、共用端末の利用者まで分けます。特権管理者、リモート接続、個人情報・決済情報を扱う業務は高リスク群として、最初からフィッシング耐性の高い方式を候補にします。

要件定義書には、認証方式だけでなく、登録方法、端末紛失時の本人確認、予備の認証器、アカウントロック、利用停止、再登録、監査ログの保存期間、SIEMへの連携、障害時の連絡先を明記します。要件整理の完了条件は、対象システムと利用者の漏れがなく、例外を誰が承認し、いつ見直すかまで決まっていることです。

方式は、SMS・音声OTP、メールOTP、TOTP、プッシュ通知、FIDO2・パスキー、クライアント証明書などを、セキュリティ、利用しやすさ、端末紛失時の復旧、オフライン対応、費用で比較します。例えば、一般利用者の入口に認証アプリを使い、管理者や重要操作にはパスキーを必須にするような段階的設計が考えられます。プッシュ通知を採用する場合は、プッシュ爆撃対策として番号照合、回数制限、リスク検知、利用者への教育を組み込みます。

製品比較では、SAML・OIDC・SCIM・RADIUS・WebAuthnへの対応、AD・人事マスタ連携、条件付きアクセス、ログのエクスポート、API、SLA、データ保管地域、契約終了時の移行性を確認します。既存ライセンスに含まれる機能と追加料金が必要な機能を分け、設定支援、個別開発、教育、保守を同じ条件で複数社に提示します。デモでは正常ログインだけでなく、端末紛失、退職、認証器の削除、ネットワーク断、管理者交代まで操作して比較します。

設計では、利用者が初回ログインして認証器を登録する画面、通常ログイン、追加認証、認証器の追加・削除、紛失時の利用停止、本人確認後の再登録を一つの利用者体験として描きます。認証器を一つしか登録できない設計は、スマートフォンの故障や機種変更で業務を止める原因になります。管理者承認付きの予備キー登録、本人確認の記録、緊急用アカウントの監視を実装し、回復手順にもMFAを適用します。

開発では、秘密鍵やリカバリーコードを平文で保存せず、トークンの有効期限、リプレイ防止、レート制限、CSRF対策、監査ログの改ざん防止を確認します。独自暗号や独自トークンをゼロから実装するのではなく、WebAuthnなどの標準仕様と実績のあるライブラリを利用します。ログにはユーザー、対象アプリ、認証方式、結果、端末、IP、時刻、認証器登録・解除、管理者変更を含めますが、OTPや秘密情報そのものは記録しません。

テストは、単にパスワードとコードを入力してログインできるかを確認する工程ではありません。利用者の登録、認証器の追加、認証成功・失敗、連続失敗による制限、ブラウザーやスマートフォンの変更、端末紛失、予備キー利用、退職者の無効化、管理者権限の変更、時刻ずれ、通信断、IDプロバイダー障害をシナリオ化します。

受入テストでは、認証成功率だけでなく、利用者が自力で復旧できる割合、ヘルプデスクへの問い合わせ件数、復旧に要する時間、ログがSIEMへ届く時間、拒否すべきアクセスが遮断される割合を測定します。金融・個人情報・管理者操作などの重要画面では、SMSやプッシュ通知を意図的に試し、フィッシング耐性の要件を満たす方式だけが許可されるかも確認します。NIST SP 800-63B-4は、認証器の保証レベルだけでなく、登録・管理・失効を含む認証器管理を整理しています（出典：NIST「SP 800-63B-4」、2025年）。

稼働は、管理者、IT部門、協力的な利用者を対象にしたパイロットから始めます。次に、業務停止の影響が比較的小さい部署、重要業務を担う部署、外部委託先の順に広げ、各段階で認証成功率、登録完了率、問い合わせ内容、例外申請数、復旧時間を確認します。利用者数の多さだけでなく、業務の重要度とサポート体制を考えて波を分けることがポイントです。

全社展開の案内には、対象日、登録期限、対応端末、登録手順、利用できる予備手段、紛失時の連絡先、問い合わせ受付時間を記載します。切り戻し条件も事前に決めますが、例外アカウントを無期限で残す運用は避け、対象者、理由、承認者、期限、代替策を台帳で管理します。稼働判定は、ログインできた人数ではなく、失敗時にも業務を安全に継続できる体制が整った時点で行います。

定着フェーズでは、導入を終点にせず、毎月の運用指標を確認します。指標には、MFA登録率、認証失敗率、パスワードリセット数、認証器の紛失・再登録件数、ヘルプデスクの一次解決率、例外アカウントの期限切れ、管理者権限の棚卸し、重大ログの検知時間を含めます。問い合わせが多い部署を責めるのではなく、登録画面、マニュアル、端末環境、方式選択のどこに負担があるかを見つけて改善します。

四半期ごと、または人事異動・製品変更・重大インシデントの発生時には、認証方式と回復フローを見直します。古いSMS例外を減らし、管理者からパスキーへ移行し、退職者の無効化が人事マスタと連動しているかを確認します。MFAは導入時の設定値ではなく、認証器のライフサイクルと利用状況を継続的に管理して初めて、業務に根付くセキュリティ対策になります。

MFAのシステム開発にかかる費用相場とコストの内訳

MFA単体の受託開発価格は公開情報が限られるため、以下は業務システム開発の一般的な規模感と、認証基盤・認証API連携の公開価格を組み合わせた推定レンジです。利用者数だけでは費用を判断できず、連携対象の数、SAML・OIDC対応の有無、既存アプリの改修可否、認証器の運用、ログ監視、可用性要件で大きく変わります。したがって、金額は確定価格ではなく、前提条件付きの予算枠として扱います。

既存IDaaSの設定と小規模展開だけなら、初期費用は0万〜60万円程度と見積もれる場合があります。既存ライセンスの範囲で自社設定するなら外部委託費が発生しないこともありますが、ポリシー設計、管理者保護、回復手順、利用者教育を省いてよいという意味ではありません。1つのWeb業務システムにTOTPやWebAuthn、登録・解除・回復画面、監査ログ、受入テストを追加する場合は、100万〜500万円程度が一つの推定レンジです。

SSO、AD・人事マスタ連携、複数システム、段階移行を含めると、300万〜1,500万円程度の推定レンジになります。数千人以上、複数拠点、オンプレミス混在、冗長化、SIEM、端末証明書、24時間運用まで求める全社認証基盤では、1,000万〜5,000万円以上になることもあります。これらは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のシステム開発で見積もりを取る際のポイント

MFAの見積もりは、利用者数とログイン画面の数だけを渡すと、後から追加費用が膨らみやすくなります。対象アプリ、IDマスタ、端末、認証方式、運用、移行、教育、保守を同じ資料にまとめ、初期費用と継続費用を分けて提示してもらいます。各社に同じRFPを渡すことで、価格だけでなく、含まれる作業と除外された作業を比較できます。

RFPには、対象ユーザー数とピーク時の同時利用者数、対象アプリ数、クラウド・オンプレミスの内訳、SAML・OIDC・RADIUS・LDAPの対応状況、AD・人事マスタ・SIEM連携、利用端末、必要な認証方式、管理者数、データ保管地域、可用性、ログ保存期間を書きます。パスキーを採用するなら、登録できるブラウザー、スマートフォン、セキュリティキー、端末の交換、複数認証器、バックアップを明記します。

さらに、紛失、盗難、機種変更、退職、異動、共有端末、外部委託先、通信障害、認証基盤障害、ヘルプデスクの時間外対応を要件に入れます。各シナリオについて、利用者、管理者、セキュリティ担当、ベンダーの誰が何分以内に何を行うのかを確認します。「認証失敗時は問い合わせ」とだけ書かれた見積もりは、実際の運用設計が含まれていない可能性があります。

選定では、MFA製品の販売実績だけでなく、要件整理、既存アプリ改修、ID連携、移行、教育、運用設計まで担当できるかを確認します。提案書には、SAML・OIDC・WebAuthnの実装経験、オンプレミスやVPNの対応例、認証器の回復手順、ログ監視、障害時のSLA、担当者の体制、成果物の引き渡し範囲を記載してもらいます。特に、設定値、ポリシー、連携仕様、テスト結果、運用手順書を自社に残せるかは、将来のベンダー変更にも関わります。

価格が最も安い提案でも、登録・回復・教育・ログ監視が除外されていれば、別発注で高くなる可能性があります。逆に、すべてをスクラッチ開発する提案も、認証暗号やトークン管理を自社で保守する負担が増えます。標準プロトコルと実績あるIDaaSを使い、独自業務の差分だけを開発する提案を基本に、3社程度へ同じ条件で相談すると比較しやすくなります。

見積もりの抜け漏れが起きやすいのは、通常ログインではなく例外処理です。個人端末を使えない人、海外出張者、共用端末の利用者、スマートフォンを紛失した人、認証アプリを削除した人、IDマスタに登録されていない委託先を想定し、どの手段で本人確認して再登録するかを確認します。緊急用アカウントを用意する場合は、常用禁止、強固な認証器、利用時の通知、利用後のパスワード変更、定期的な棚卸しを必須にします。

移行では、既存の認証器やパスワード情報を移せるのか、利用者に再登録してもらうのか、旧認証をいつ停止するのかを明確にします。並行稼働を長く続けると、弱い方式が残り続けるため、部署ごとの移行期限と例外の終了日を設定します。見積書に「移行支援一式」「保守一式」としか書かれていない場合は、対象人数、回数、対応時間、成果物、追加単価に分解してもらいます。

よくある質問

MFAのシステム開発では、方式の選択だけでなく、既存環境との接続や運用開始後の復旧に関する質問が多く寄せられます。ここでは、発注前に確認しておきたい代表的な疑問に回答します。

既存IDaaSの設定と小規模展開なら即日〜4週間程度、1つのWeb業務システムへのMFA追加なら1〜3か月程度が推定目安です。複数システムのSSO、AD・人事マスタ連携、段階移行を含める場合は2〜6か月程度、全社認証基盤やオンプレミス混在では6〜18か月程度になる可能性があります。対象アプリ数、PoC、利用者教育、移行波の数で変わるため、開発期間と展開期間を分けて見積もります。

導入のしやすさだけならSMS認証が候補になりますが、管理者、VPN、重要データ、重要操作ではパスキーやFIDO2などのフィッシング耐性方式を優先します。SMSを残す場合は、低リスクの補助手段に限定し、SIMスワップや番号変更、端末紛失への対応を定めます。利用者が多い企業では、一般利用者は認証アプリ、特権利用者はパスキーというように、リスクに応じて方式を分ける方法が現実的です。

追加できる可能性がありますが、SAMLやOIDCへの対応状況、VPN・VDIの接続方式、既存ADやLDAPの構成を先に調査します。直接改修できない場合は、認証ゲートウェイ、リバースプロキシ、RADIUS、端末証明書などを比較します。代理認証で暫定対応する場合は、保守期限、障害時の挙動、パスワード変更、将来のアプリ刷新を契約と設計書に明記します。

既存のMicrosoft Entra IDやGoogleなどに基本MFAの機能が含まれていれば、ライセンスの追加なしで始められる場合があります。ただし、条件付きアクセス、独自アプリ連携、端末証明書、パスキーの配布、利用者教育、ヘルプデスク、監査ログ、SMS送信には別の費用が発生する可能性があります。ライセンス費がゼロでも、業務を止めずに運用するための設計・設定・テスト・保守費用まで含めてTCOを確認します。

まとめ

MFAのシステム開発は、認証方式を選んでログイン画面に追加するだけの作業ではありません。要件整理で守る対象と利用者を洗い出し、選定で既存環境に合う基盤を決め、設計・開発で登録・認証・回復・監査をつなぎ、テストで失敗時の業務継続を確認します。その後、管理者から段階的に稼働し、登録率や復旧時間を測定しながら定着させます。

要件整理、選定、設計・開発、テスト、稼働、定着を一つの作業として扱わず、各フェーズの成果物と完了条件を決めます。特に認証器の登録・回復・失効と、管理者の緊急対応を先に設計すると、全社展開後の問い合わせと業務停止を抑えやすくなります。

見積もりでは、初期開発費だけでなく、ライセンス、SMS、認証器、教育、監視、ヘルプデスク、保守、将来の追加連携まで含むTCOを比較します。方式の安全性と利用者の負担をリスク別に整理し、標準基盤を活用して独自要件だけを開発することが、継続できるMFAにつながります。

費用は、既存IDaaSの設定なら0万〜60万円程度、1アプリへの追加なら100万〜500万円程度、複数システム連携なら300万〜1,500万円程度、全社認証基盤なら1,000万〜5,000万円以上という推定レンジがあります。ただし、これは前提条件付きの目安であり、ライセンス、SMS、端末、教育、監視、保守を別建てで確認する必要があります。RFPには認証方式だけでなく、認証器の紛失・再登録、退職者の無効化、例外の期限、障害対応、ログ保存、成果物の引き渡しまで記載します。

特権管理者や重要操作にはフィッシング耐性の高いパスキー・FIDO2を優先し、標準プロトコルと実績ある基盤を活用しながら、独自業務の差分だけを開発することが、費用と安全性の両立につながります。

▼全体ガイドの記事
・MFAのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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