MFAのシステム開発の完全ガイド - ブログ

MFAのシステムとは、パスワードだけに依存せず、知識・所持・生体など異なる認証要素を組み合わせて本人確認を行う仕組みです。業務システムでは、認証方式の追加だけでなく、SSO連携、利用者の登録・異動・退職、認証器の紛失、監査ログ、障害時の復旧までを一体で設計することが重要です。

本記事では、MFAのシステム開発を検討する担当者に向けて、認証要素の種類、既存システムとの連携方法、方式ごとの安全性、費用相場、開発の進め方、開発会社やサービスを選ぶ基準までを整理します。「認証アプリを有効にするだけ」で済むケースと、全社の認証基盤を開発するケースの違いも確認し、読み終えた段階でRFPの初稿を作れる状態を目指します。

MFAのシステムとは何ですか？全体像を理解する

MFAは、利用者が本人であることを複数の観点から確かめる認証基盤です。二つのパスワードを入力させればよいのではなく、互いに異なる要素を組み合わせることが条件です。業務システムでは、ログイン画面の前後にある利用者管理やアクセス制御まで含めて、ひとつの仕組みとして考える必要があります。

認証要素は知識・所持・生体の3種類です

知識情報はパスワードやPIN、所持情報はスマートフォン、認証アプリ、ハードウェアキー、ICカードなどです。生体情報は指紋や顔、端末内で生体認証を解除した事実などを指します。たとえば、パスワードと認証アプリのワンタイムコードは知識情報と所持情報の組み合わせになりますが、SMSやメールで届くコードは導入しやすい反面、電話番号の乗っ取りやメールアカウント侵害の影響を受ける可能性があります。

重要なのは、認証要素を増やすこと自体ではなく、想定する攻撃に耐えられる組み合わせを選ぶことです。NISTの「SP 800-63B-4」は2025年7月に公開され、認証器の保証レベルだけでなく、登録、利用、交換、失効などの管理を認証設計の対象として整理しています（出典：NIST、2025年）。

業務システムでは認証以外の機能も必要です

業務用のMFAシステムには、認証方式のほかに、SAMLやOIDCによるSSO連携、Active Directory・LDAP・人事マスタとの同期、SCIMなどを使ったIDライフサイクル管理が必要です。利用者が入社したら登録し、異動したら権限を見直し、退職したら直ちに認証器とアクセス権を無効化できる状態にします。

さらに、ユーザー、役職、端末の管理状態、IPアドレス、場所、時間帯、リスク情報に応じて、追加認証、アクセス拒否、重要操作時だけのステップアップ認証を判断する機能も重要です。認証器の登録・削除、端末紛失時の再登録、予備手段、管理者承認、緊急用アカウント、成功・失敗ログ、設定変更ログ、SIEM連携までを要件に含めると、導入後の運用が安定します。

MFAの認証方式にはどのような種類がありますか？

結論として、方式は安全性だけでなく、利用者の端末、業務の停止許容度、復旧のしやすさ、導入費を合わせて選びます。一般利用者の利便性を優先する場面と、管理者や機密情報へのアクセスのようにフィッシング耐性を優先する場面では、同じ方式を一律に適用しないことが現実的です。

OTP・プッシュ通知・SMSは導入しやすい方式です

TOTPは認証アプリやトークンが生成する一定時間ごとのコードを入力する方式です。通信が不安定でも使いやすく、標準的な連携に向いています。プッシュ通知は承認操作だけで済むため利用者の負担が小さい一方、短時間に承認要求を繰り返して誤操作を誘う「プッシュ爆撃」への対策が必要です。番号の照合、通知回数の制限、異常検知を組み合わせるとリスクを抑えられます。

SMSや音声OTPは専用端末が不要で、利用者の展開が早い方式です。ただし、SIMスワップ、電話番号の再利用、通信事業者を狙う攻撃、リアルタイム型フィッシングに弱いため、管理者、VPN、財務処理、個人情報を扱う業務では単独の第一候補にしないことが望ましいです。デジタル庁の2025年資料でも、保証レベルが高い領域では公開鍵暗号に基づく認証器とフィッシング耐性が重視されています（出典：デジタル庁、2025年）。

FIDO2・パスキー・証明書は高い耐性を重視する方式です

FIDO2やパスキーは、公開鍵暗号を使って認証する方式です。秘密鍵をサーバー側にパスワードのように保管せず、端末の生体認証やPIN、セキュリティキーによる解除と組み合わせます。偽サイトのドメインへ認証情報を送らない設計にできるため、管理者や高リスク業務のフィッシング対策に向いています。

一方で、端末変更や紛失、複数端末の登録、共有端末、外部委託先の利用を想定した運用が欠かせません。登録用の一時コード、本人確認を伴う再登録、予備の認証器、管理者による失効処理を先に設計します。クライアント証明書や端末証明書は、管理された端末だけを許可したい場合に有効ですが、証明書の配布・更新・失効・端末廃棄の運用負荷を費用に含める必要があります。

方式は業務リスクと利用者層で使い分けます

まず特権管理者、リモート接続、重要な設定変更、決済・給与・個人情報へのアクセスを高リスク群に分類します。高リスク群にはFIDO2やパスキーなどのフィッシング耐性方式を優先し、一般利用者には認証アプリを基本としながら、端末のない利用者向けの代替手段を用意します。SMSを完全に排除できない場合も、管理者操作の再認証には使わないなど、利用範囲を限定します。

方式比較では、ログイン成功率だけで判断しません。登録にかかる時間、端末紛失時の復旧時間、問い合わせ件数、認証要求の遅延、オフライン時の業務継続、監査ログの粒度をPoCで測定します。認証の強さと現場の継続性を両立させるため、複数方式を同じポリシーのもとで管理する設計が重要です。

MFAのシステム開発はどのように進めますか？

MFAの導入は、認証機能を実装して終わるプロジェクトではありません。対象システムと利用者を棚卸しし、リスクの高い対象から要件化し、代表的な利用シナリオをPoCで確認してから段階導入します。特に既存のオンプレミス業務システムやVPN、VDI、独自Webアプリは、標準連携の可否が期間と費用を大きく左右します。

最初に認証対象と利用者を棚卸しします

対象となる業務システム、SaaS、VPN、VDI、管理画面、APIを一覧化し、それぞれの認証方式、SSO対応状況、管理者数、利用者数、外部利用の有無、重要データ、稼働時間を整理します。利用者も、一般社員、管理者、派遣・委託先、取引先、共有端末利用者に分けると、同じ認証ポリシーを無理に当てはめずに済みます。

棚卸しでは、パスワードを誰が管理しているか、退職者のアカウントがどの経路で無効化されるか、緊急用アカウントを誰が監視するかも確認します。アクセス権が人事マスタと連動していない場合、MFAだけを追加しても不要なアカウントが残るため、認証と認可、IDライフサイクルを同時に見直します。

要件定義とPoCで失敗条件まで確認します

要件定義では、対象範囲、認証方式、追加認証の条件、セッション時間、再認証のタイミング、登録・解除の権限、ログ保存期間、障害時の切り替えを決めます。SAMLやOIDCに対応したシステムは連携しやすいですが、非対応の古いシステムでは、認証ゲートウェイ、代理認証、端末証明書、VPN側での制御などを比較します。

PoCでは正常なログインだけでなく、管理者の再認証、端末紛失、スマートフォン変更、ネットワーク断、認証器の再登録、利用者の異動、アカウントロック、ログ欠落、連携先の障害を再現します。少なくとも管理者、一般利用者、外部委託先、共有端末利用者を含め、認証成功率、問い合わせ数、復旧時間を測定します。

管理者から始めて段階的に全社展開します

展開は、管理者、IT部門、代表部署、全社の順に進めるとリスクを抑えやすいです。各段階で、認証失敗率、問い合わせ件数、登録完了率、復旧にかかった時間、ポリシー除外数を確認し、次の対象へ進む基準を決めます。全社一斉に必須化すると、登録漏れや端末の非対応で業務が止まる可能性があるため、告知期間とサポート窓口を設けます。

例外申請は無期限の抜け道にせず、対象者、理由、代替策、責任者、期限、再評価日を記録します。緊急用アカウントは常用せず、保管場所と利用通知を限定し、使用後に認証情報を交換します。段階導入の工程は、小規模な単一アプリなら1〜3か月、複数システムのSSO連携なら2〜6か月、全社基盤なら6〜18か月をひとつの検討目安にします。

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

MFAの費用は、利用者数だけで決まりません。連携するシステム数、既存システムを改修できるか、認証器の種類、ログ・監査要件、可用性、利用者教育、ヘルプデスクの範囲が金額を左右します。公開されたMFA単体の受託開発価格は限られるため、以下は業務システムの一般的な相場と認証連携の工数から組み立てた推定レンジです。

▶ 詳細はこちら：MFAのシステム開発の見積相場や費用/コスト/値段について

初期費用は100万〜5,000万円以上まで幅があります

既存のIDaaSで設定し、認証アプリ登録と簡易マニュアルだけを行う小規模展開なら、初期費用は0〜60万円程度、期間は即日から4週間程度が目安です。自社で設定できる場合は外注費が発生しないこともありますが、ポリシー設計、例外管理、復旧手順の検証にかかる社内工数は別に見積もります。

独自Webシステム1つにTOTPやWebAuthnを追加し、登録・解除・回復画面、API連携、監査ログ、受入テストまで行う場合は、100万〜500万円程度、期間は1〜3か月が推定目安です。SSO、AD、人事マスタをつなぎ、5〜20システムを段階移行する場合は300万〜1,500万円程度、複数拠点・数千人以上・高可用性・SIEM連携・オンプレミス混在まで含む全社基盤では1,000万〜5,000万円以上になる可能性があります。

これらはMFA固有の公表価格ではなく、前提条件付きの推定です。特に古いシステムの改修可否、利用者の登録方式、認証器の配布、24時間監視、災害対策の要否で大きく変わるため、金額だけでなく見積範囲と除外項目を確認します。

ライセンス・運用・復旧費をTCOに含めます

ランニングコストには、IDaaSや認証基盤の月額、SMS・音声の従量料金、セキュリティキーの購入・交換、証明書の発行、ログ保管、監視、ヘルプデスク、利用者教育、脆弱性対応が含まれます。既存のクラウド契約に基本MFAが含まれていても、条件付きアクセス、リスクベース制御、オンプレミスアプリ連携、詳細なレポートには上位ライセンスが必要になる場合があります。契約前に、対象ユーザー、対象アプリ、必要なポリシー、最低契約数、従量課金、為替の影響を確認します。

保守運用費は、初期開発費の年15〜25％程度を仮置きして予算化する方法がありますが、これは一般的な検討用の目安であり、契約価格ではありません。認証障害時に何分で切り分けるか、休日夜間に誰が対応するか、予備の認証器を何個持つか、復旧訓練を年何回行うかまで決めると、安い初期費用の後に運用費が膨らむ事態を避けやすくなります。

MFAの開発会社・サービスの選び方

MFAの発注先は、認証製品の機能表だけでなく、既存システムの連携、移行、利用者サポート、運用設計まで比較して選びます。標準的なSaaSの設定で済む領域はパッケージやクラウドを活用し、独自の業務フローだけをAPI連携や小規模開発で補うハイブリッド構成が、費用と拡張性のバランスを取りやすいです。

既存環境との連携実績を確認します

候補先には、対象アプリがSAML、OIDC、LDAP、RADIUS、WebAuthnのどれに対応しているかを提示し、同種の連携経験を確認します。Active Directoryや人事マスタとの同期、SCIMによるアカウント作成・停止、VPNやVDIの認証、外部委託先のアクセス制御を、実装範囲と追加費用に分けて説明できることが重要です。

「対応できます」という回答だけでなく、標準機能で対応する部分、設定で対応する部分、追加開発が必要な部分、対象外となる部分を一覧にしてもらいます。認証サーバーの冗長化、障害時の切り替え、ログの保存先、データの保管地域、別サービスへ移行する場合の設定・コード・ドキュメントの引き渡しも、初期提案の段階で確認します。

認証器の回復と運用支援を評価します

MFA導入で最も現場が困るのは、スマートフォンの紛失や機種変更、認証器の故障、利用者の退職、管理者自身のロックアウトです。候補先には、本人確認の方法、再登録の承認者、予備の認証器、仮の認証手段の有効期限、復旧操作の監査ログ、ヘルプデスクの受付時間を確認します。

運用開始後のKPIも提案に含めます。登録完了率、認証失敗率、復旧にかかる平均時間、問い合わせ件数、管理者権限への追加認証率、例外申請の期限切れ件数を月次で確認すると、セキュリティと利用者体験の両方を改善できます。SLA、障害通知、脆弱性対応、ログ調査、定期訓練の範囲も、月額費用とは別に明文化します。

RFPには技術・費用・契約の質問を入れます

RFPでは、対象ユーザー数と増加見込み、対象アプリ数、利用者区分、必要な認証方式、フィッシング耐性が必要な対象、SSOと人事マスタの連携、ログ保存期間、可用性、復旧目標、段階導入の期限を明記します。見積には、要件定義、設計、実装、テスト、移行、教育、マニュアル、保守、ライセンス、SMS、キー、監視を分けて記載してもらいます。

比較時は、初期費用の安さだけでなく、5年間の総保有コスト、利用者追加時の単価、認証器交換費、障害時の支援、契約終了時のデータ移行を並べます。特定の製品名だけで提案を固定するのではなく、要件に対して複数の構成案とそれぞれの制約を示せる発注先を選ぶと、将来の変更にも対応しやすくなります。

▶ 詳細はこちら：MFAのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：MFAのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：MFAのシステム開発の発注/外注/依頼/委託方法について

MFA導入後のセキュリティと運用で注意すること

MFAは不正ログインのリスクを下げますが、すべての攻撃を自動的に防ぐものではありません。認証器の登録画面、アカウント回復、管理者権限、セッションの乗っ取り、端末のマルウェア、過剰な例外設定が弱点になる可能性があります。導入後は認証方式だけでなく、認証前後の運用を継続的に点検します。

回復フローと管理者権限を最も厳しく管理します

攻撃者がログインできなくても、本人確認の弱い回復フローを悪用できればMFAを迂回できます。電話番号だけで認証器を再発行しない、本人確認の記録を残す、承認者を分離する、仮の認証手段に短い有効期限を設定する、再登録後に旧認証器を失効する、といった制御が必要です。

管理者は一般利用者と別のポリシーにし、フィッシング耐性方式、管理端末、追加の再認証、最小権限、操作ログを組み合わせます。CISAも2025年の資料で、管理者・特権ユーザーやリモートアクセスにフィッシング耐性MFAを優先する考え方を示しています（出典：CISA、2025年）。

ログ監視と利用者教育を継続します

監査ログには、認証成功・失敗だけでなく、認証器の登録・削除、バックアップ手段の使用、パスワードリセット、管理者によるポリシー変更、例外申請、端末や場所の異常を残します。ログは改ざんされにくい場所に保管し、異常な連続失敗、普段と違う場所からの登録、短時間の回復操作を検知できるようにします。

利用者には、承認要求を急いで許可しないこと、認証コードを他人へ伝えないこと、紛失時にどこへ連絡するかを短い手順で伝えます。導入時の説明会だけで終わらせず、定期的な訓練、異動・入社時の案内、管理者向けの復旧演習を行うと、認証の仕組みが実際の防御として機能しやすくなります。

よくある質問（FAQ）

MFAのシステム開発では、方式や価格だけでなく、既存環境への適合性と導入後の回復運用が疑問になりやすいです。ここでは、検討時によくある質問に直接回答します。

古いオンプレミス業務システムにもMFAを追加できますか？

追加できる可能性があります。SAMLやOIDCに対応していれば認証基盤と直接連携しやすく、非対応でも認証ゲートウェイ、代理認証、VPN、端末証明書などを組み合わせる選択肢があります。ただし、画面の自動操作に依存する方式は障害や改修の影響を受けやすいため、将来の刷新計画と合わせて判断します。

MFAのシステム開発費用はどのくらいですか？

既存IDaaSの設定だけなら0〜60万円程度、単一WebアプリへのMFA追加なら100万〜500万円程度、複数システムのSSO連携なら300万〜1,500万円程度、全社認証基盤なら1,000万〜5,000万円以上が推定目安です。ライセンス、SMS、認証器、教育、保守、監視は別費用になる場合があるため、5年間のTCOで比較します。

SMS認証とパスキーはどちらを選ぶべきですか？

一般利用者の早期展開ではSMSや認証アプリが役立つ場合がありますが、管理者、VPN、機密情報へのアクセスにはパスキーやFIDO2などのフィッシング耐性方式を優先します。端末紛失や共有端末の運用を検証し、必要に応じて複数方式をポリシーで使い分けることが適切です。

全社一斉にMFAを必須化しても問題ありませんか？

登録漏れ、端末非対応、認証器の紛失、古い業務システムとの連携不備で業務が止まる可能性があるため、原則として段階導入が安全です。管理者と代表部署でPoCを行い、利用者への告知、例外申請、予備の認証器、復旧窓口を準備してから対象を広げます。

まとめ

MFAのシステムは、ログイン時にワンタイムコードを追加するだけの機能ではありません。認証要素の選定、SSOや人事マスタとの連携、条件付きアクセス、認証器の登録・失効・回復、監査ログ、利用者教育、障害対応までを含む認証基盤です。

検討時は、まず対象システムと利用者を棚卸しし、管理者や機密情報を扱う業務からリスク分類します。費用は、設定だけなら0〜60万円程度、単一アプリなら100万〜500万円程度、複数システム連携なら300万〜1,500万円程度、全社基盤なら1,000万〜5,000万円以上という推定レンジを起点にし、ライセンスや運用費を含むTCOで比較します。

最後に、正常なログインだけでなく、端末紛失、再登録、ネットワーク断、管理者ロックアウト、退職者の無効化、認証基盤障害までPoCで確認します。製品名や初期費用だけで発注先を決めず、標準連携と追加開発の境界、復旧手順、SLA、ログ、契約終了時の移行まで説明できる開発会社・サービスを選ぶことが、長く使えるMFAにつながります。

認証方式ではなく運用を含めて設計します

最初から全社一律の方式を決めるのではなく、業務リスク、利用者の端末、既存システムの連携方式、復旧要件を整理してから適用範囲を決めます。高リスクの管理者や重要操作にはフィッシング耐性方式を優先し、一般利用者には登録しやすく復旧しやすい手段を用意するなど、使い分けを前提にします。

次の一歩は棚卸しと小規模PoCです

次に行うことは、対象システム、利用者、管理者権限、認証情報、端末、ログ、IDライフサイクルを一覧化することです。そのうえで代表部署を選び、正常系と失敗系のシナリオを含むPoCを行い、費用・期間・運用負荷を実測してから全社展開の計画を固めます。