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

MFAのシステム開発は、認証方式、導入の進め方、費用、発注先と運用の4つの観点で整理すると、自社に合う認証基盤の姿が見えてきます。

認証要素と方式、導入工程、費用相場、発注先や運用の注意点を順に説明します。各テーマの詳細は、下記の関連記事もご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

MFAのシステムの全体像

認証要素とアクセス制御が一つの基盤を支えます。

MFAは、異なる複数の観点から利用者本人を確かめる認証基盤です。パスワードを二つ入力させる方式とは違い、性質の異なる認証要素を組み合わせます。

業務システムでは、ログイン画面の前後にある利用者管理やアクセス制御も含めて、一つの仕組みとして設計します。

認証要素の種類（知識・所持・生体）

MFAの認証要素は、知識情報、所持情報、生体情報の3種類に分かれます。

知識情報：パスワードやPIN
所持情報：スマートフォン、認証アプリ、ハードウェアキー、ICカード
生体情報：指紋や顔、端末内で生体認証を解除した事実
組み合わせ例：パスワードと認証アプリのワンタイムコード

SMSやメールのコードは導入しやすい一方で、電話番号の乗っ取りやメールアカウントの侵害の影響を受ける可能性があります。

要素の組み合わせは、想定する攻撃に耐えられるかどうかで選びます。

NIST「SP 800-63B-4」（2025年7月公開）も、保証レベルや認証器の登録・利用・交換・失効を設計の対象に含めています（出典：NIST、2025年）。

業務システムに必要な認証以外の機能

業務用のMFAでは、認証機能に加えて、ID管理や連携、条件に応じた制御などが必要になります。

連携・ID管理：SAMLやOIDCによるSSO、Active Directory・LDAP・人事マスタとの同期、SCIMなどのIDライフサイクル管理。
利用者の異動：入社時に登録し、異動時に権限を見直し、退職時には認証器とアクセス権をすぐに無効化する。
アクセス制御：利用者や役職、端末状態、IPアドレス、場所、時間帯、リスク情報に応じて、追加認証やアクセス拒否を判断。
運用機能：重要操作時のステップアップ認証、認証器の登録・削除・再登録、予備手段、管理者承認、緊急用アカウント、成功・失敗ログ、設定変更ログ、SIEM連携。

認証以外の機能も、導入後の運用まで含めて設計することで、安定した運用につながります。

MFAの認証方式の種類

方式は、安全性に加えて、利用端末や復旧性を見て選びます。業務の停止許容度や導入費も判断材料になります。

一般利用者には利便性を、管理者や機密情報へのアクセスにはフィッシング耐性を重視するため、利用者によって方式を分けて考えます。

OTP・プッシュ通知・SMS方式の特徴と注意点

方式ごとに、使い勝手と必要な対策が異なります。

TOTP：認証アプリやトークンが一定時間ごとに生成するコードを入力します。通信が不安定でも使いやすく、標準連携との相性がよい方式です。
プッシュ通知：承認操作だけで済むため、利用者の負担を小さく抑えられます。
SMS・音声OTP：専用端末が要らず、利用者へ早く展開できます。

プッシュ通知には、承認要求を繰り返して誤操作を誘う「プッシュ爆撃」への対策が要ります。番号照合、通知回数の制限、異常検知でリスクを抑えます。

SMSや音声OTPは、SIMスワップや電話番号の再利用、通信事業者を狙う攻撃に弱い方式です。リアルタイム型フィッシングにも弱いため、管理者、VPN、財務処理、個人情報を扱う業務では、単独の第一候補にしないことが望ましいです。

デジタル庁の2025年資料も、保証レベルが高い領域では公開鍵暗号に基づく認証器とフィッシング耐性を重視しています（出典：デジタル庁、2025年）。

FIDO2・パスキー・証明書の方式と運用準備

FIDO2やパスキー、証明書は、公開鍵暗号などを用いて高い耐性を重視する方式です。

FIDO2・パスキー：端末の生体認証やPIN、セキュリティキーで秘密鍵を解除します。
利用場面：偽サイトのドメインへ認証情報を送らない設計にでき、管理者や高リスク業務の対策に適しています。
運用準備：端末変更・紛失、複数端末、共有端末、外部委託先を想定して、一時コード、本人確認付きの再登録、予備認証器、管理者による失効処理を用意します。
証明書：管理端末だけを許可したい場合に有効です。

FIDO2やパスキーでは、秘密鍵をパスワードのようにサーバー側へ保管しない点が特徴です。

証明書を使う場合は、配布、更新、失効、端末廃棄にかかる運用負荷も費用に含めます。

業務リスクと利用者層による方式の使い分け

特権管理者と重要な設定変更は、高リスク群に分類します。リモート接続や、決済・給与・個人情報へのアクセスも、同じ高リスク群に含めます。

高リスク群：FIDO2やパスキーなど、フィッシング耐性方式を優先します。
一般利用者：認証アプリが基本で、端末を持たない人には代替手段が要ります。
SMSを残す場合：管理者操作の再認証には使わないなど、利用範囲を限定します。

方式を比べるときは、ログイン成功率に加えて、登録時間や端末紛失時の復旧時間、問い合わせ件数をPoCで測ります。あわせて、認証要求の遅延、オフライン時の業務継続性、監査ログの粒度も確認します。

認証の強さと現場の継続性を両立させるため、複数の方式を同じポリシーで管理します。

ポイント

方式は、業務リスクと利用者層を組み合わせて選びます。管理者や機密情報にはフィッシング耐性のある方式を、一般利用者には運用しやすい方式を当てるのが基本です。

MFAのシステム開発の進め方

対象を確かめながら適用範囲を段階的に広げます。

MFA導入は、認証機能の実装に加えて、対象の整理から段階的な展開までを含むプロジェクトです。

まず対象と利用者を棚卸しし、リスクの高い対象から要件として整理します。そのうえで、代表的な利用シナリオをPoCで確認してから、段階的に導入します。

既存のオンプレミス業務システムやVPN、VDI、独自Webアプリでは、標準連携の可否が期間と費用を左右します。

認証対象と利用者の棚卸し

認証対象ごとに、環境と利用状況を洗い出します。

対象システム：業務システム、SaaS、VPN、VDI、管理画面、APIの認証方式とSSO対応状況。
利用状況：管理者数、利用者数、外部利用の有無、重要データ、稼働時間。
利用者区分：一般社員、管理者、派遣・委託先、取引先、共有端末利用者。
運用状況：パスワードの管理者、退職者アカウントの無効化経路、緊急用アカウントの監視担当。

利用者を区分しておくと、同じ認証ポリシーを無理に当てはめずに済みます。

アクセス権が人事マスタと連動していない場合は、MFAを追加しても不要なアカウントが残ります。そのため、認証と認可、IDライフサイクルを同時に見直します。

要件定義とPoCでの失敗条件の確認

要件定義とPoCでは、連携方式と、正常時・異常時の動作を確認します。

要件：対象範囲、認証方式、追加認証の条件、セッション時間、再認証の時期、登録・解除の権限、ログ保存期間、障害時の切り替え。
連携方式：SAMLやOIDCに対応したシステムは連携しやすく、非対応の古いシステムでは、認証ゲートウェイや代理認証、端末証明書、VPN側の制御を比べます。
PoCの異常系：管理者の再認証、端末紛失、スマートフォン変更、ネットワーク断、認証器の再登録、利用者の異動、アカウントロック、ログ欠落、連携先の障害。
参加者と評価：管理者、一般利用者、外部委託先、共有端末利用者を含めて、認証成功率や問い合わせ数、復旧時間を測定します。

PoCでは、正常なログインを確かめるだけでなく、想定した利用シナリオが成り立つかも見ます。

管理者から始める段階的な全社展開

管理者から全社へと段階的に広げ、各段階の状況を次の対象へ進む判断に使います。

管理者からの導入
IT部門への拡大
代表部署での運用確認
確認後の全社展開

各段階では、認証失敗率や問い合わせ件数を確かめます。登録完了率、復旧時間、ポリシー除外数も見ておきます。

全社一斉に必須化すると、登録漏れや端末の非対応で業務が止まる可能性があります。そのため、告知期間とサポート窓口を設けます。

例外申請には、対象者、理由、代替策、責任者を記録します。

期限と再評価日も記録し、無期限の抜け道にしません。

緊急用アカウントは常用せず、保管場所と利用通知を限定します。

使用後には、認証情報を交換します。

なお、工程の目安は、小規模な単一アプリで1〜3か月、複数システムのSSO連携で2〜6か月です。全社基盤になると、6〜18か月を検討の目安にします。

ポイント

迷ったときは、対象の棚卸しを終えてから小さなPoCで確かめ、その結果を見て展開範囲を決めるのが安全です。

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

連携するシステムの範囲に応じて費用帯が広がります。

MFAの費用は、利用者数に加えて、連携システム数や既存システムの改修可否で決まります。認証器やログ・監査要件、可用性も金額を左右します。

利用者教育やヘルプデスクの範囲も、費用に影響します。

MFA単体の受託開発価格は公開情報が限られています。そのため、ここに示す金額は、業務システムの一般相場と認証連携の工数から組み立てた推定レンジです。

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

構成規模で変わる初期費用の幅：100万〜5,000万円以上

既存IDaaSの設定と認証アプリの登録、簡易マニュアルだけなら、初期費用は0〜60万円程度です。期間は即日から4週間程度が目安です。

自社で設定すれば、外注費がかからない場合もあります。ただし、ポリシー設計、例外管理、復旧手順の検証にかかる社内工数は別に見積もります。

IDaaS設定のみ：0〜60万円程度、即日から4週間程度。
単一Webシステム：登録・解除・回復画面、API連携、監査ログ、受入テストを含め100万〜500万円程度、1〜3か月。
5〜20システムの段階移行：SSO、AD、人事マスタとの連携を含め300万〜1,500万円程度。
全社基盤：複数拠点、数千人以上、高可用性、SIEM連携、オンプレミス混在を含め1,000万〜5,000万円以上となる可能性。

これらは前提条件に基づく推定であり、MFA固有の公表価格ではありません。古いシステムの改修可否や利用者の登録方式によって、金額は変わります。

認証器の配布、24時間監視、災害対策の要否も金額を左右します。見積もりの範囲と除外項目を確認してください。

ライセンス・運用・復旧費を含むTCO

ランニングコストは、ライセンスや認証器に加えて、運用に関わる費用まで見積もります。

利用・認証：IDaaSや認証基盤の月額、SMS・音声の従量料金、セキュリティキーの購入・交換、証明書の発行。
運用：ログ保管、監視、ヘルプデスク、利用者教育、脆弱性対応。
契約条件：対象ユーザー・アプリ、必要なポリシー、最低契約数、従量課金、為替の影響。
保守運用費：初期開発費の年15〜25％程度を仮置きする方法がありますが、検討用の目安で、契約価格ではありません。

クラウド契約に基本のMFAが含まれていても、条件付きアクセスやリスクベース制御、オンプレミスアプリ連携、詳細レポートには上位ライセンスが必要な場合があります。

このほか、障害時の切り分け時間や休日夜間の対応者、予備認証器の数、復旧訓練の年あたりの回数も決めます。そうしておけば、安い初期費用のあとで運用費が膨らむ事態を防げます。

ポイント

費用を比べるときは、連携するシステムの範囲と既存環境の改修可否をそろえてから見ます。前提が違う見積もりは、単純に比べられません。

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

発注先は、認証製品の機能だけでなく、既存システムとの連携や移行、利用者サポート、運用設計まで比べて選びます。

パッケージやクラウドで標準的なSaaS設定を行い、独自の業務フローだけをAPI連携や小規模開発で補うハイブリッド構成は、費用と拡張性のバランスを取りやすいです。

既存環境との連携実績の確認

候補先には、認証連携と既存環境との接続範囲を、具体的に説明してもらいます。

対応方式・実績：対象アプリのSAML、OIDC、LDAP、RADIUS、WebAuthn対応と同種の連携経験。
既存環境：Active Directory・人事マスタとの同期、SCIMでの作成・停止、VPN・VDI認証、外部委託先のアクセス制御。
実装範囲：標準機能、設定、追加開発、対象外の区分を一覧で示し、それぞれの追加費用を説明。
継続利用：冗長化、障害時の切り替え、ログ保存先、データ保管地域、別サービスへの移行時の設定・コード・文書の引き渡し。

認証器の回復と運用支援の評価

MFA導入後は、スマートフォンの紛失や機種変更、認証器の故障、退職、管理者のロックアウトが現場の負担になりやすいです。そのため、候補先には回復手順と支援体制を確かめます。

回復方法：本人確認の方法、再登録の承認者、予備認証器、仮の認証手段の有効期限。
運用記録・窓口：復旧操作の監査ログ、ヘルプデスクの受付時間。
月次KPI：登録完了率、認証失敗率、復旧の平均時間、問い合わせ件数、管理者権限への追加認証率、例外申請の期限切れ件数。

KPIを月次で確認すると、セキュリティと利用者体験の改善に役立ちます。

SLA、障害通知、脆弱性対応、ログ調査、定期訓練の範囲も、月額費用とは別に明文化します。

RFPに入れる技術・費用・契約の質問

RFPには、技術要件、見積項目、比較条件、契約終了時の条件を具体的に記載します。

技術・導入要件：対象規模、認証方式、連携・運用要件。
見積項目：要件定義、設計、実装、テスト、移行、教育、マニュアル、保守、ライセンス、SMS、キー、監視。
比較・契約条件：5年間の総保有コスト、利用者追加時の単価、認証器交換費、障害時の支援、契約終了時のデータ移行。

技術要件には、対象ユーザー数と増加見込み、対象アプリ数、利用者区分を記載します。あわせて、フィッシング耐性が必要な対象も示します。SSOや人事マスタ連携、ログ保存期間、可用性、復旧目標、段階導入の期限も含めます。

複数の構成案と制約を示せる発注先であれば、特定製品に縛られず、将来の変更にも柔軟に応じられます。

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

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

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

ポイント

発注先は、認証製品の機能に加えて、既存環境との連携実績と回復運用の支援体制で比べます。特定製品への固定を避けられるかも、判断の材料になります。

MFA導入後のセキュリティと運用の注意点

MFAは不正ログインのリスクを下げますが、すべての攻撃を自動的に防ぐものではありません。

認証器の登録画面やアカウント回復、管理者権限が弱点になる可能性があります。ほかにも、セッションの乗っ取りや端末のマルウェア、過剰な例外設定が弱点になることがあります。

そのため、導入後は、認証方式だけでなく認証前後の運用も継続的に点検します。

回復フローと管理者権限の管理

本人確認が弱い回復フローを悪用されると、攻撃者はMFAを迂回できてしまいます。そのため、回復手順と管理者の制御を厳格にします。

回復時の本人確認：電話番号だけで認証器を再発行せず、本人確認の記録を残します。
再登録の制御：承認者を分離し、仮の認証手段に短い有効期限を設け、再登録後に旧認証器を失効します。
管理者ポリシー：一般利用者と分け、フィッシング耐性方式、管理端末、追加再認証、最小権限、操作ログを組み合わせます。

CISAは2025年の資料で、管理者・特権ユーザーやリモートアクセスにフィッシング耐性MFAを優先する考え方を示しています（出典：CISA、2025年）。

ログ監視と利用者教育の継続

ログ監視と利用者教育を続けることで、異常を検知し、適切な利用を支えます。

記録する操作：認証成功・失敗、認証器の登録・削除、バックアップ手段の使用、パスワードリセット、ポリシー変更、例外申請、端末や場所の異常。
監視する兆候：異常な連続失敗、普段と違う場所からの登録、短時間の回復操作。
利用者への案内：承認要求を急いで許可しない、認証コードを他人へ伝えない、紛失時の連絡先を知る。
継続教育：定期訓練、異動・入社時の案内、管理者向けの復旧演習。

ログは改ざんされにくい場所に保管します。継続的な訓練により、認証を実際の防御として機能させていきます。

ポイント

回復フローと管理者権限は、一般利用者より厳しく管理します。回復の手順が甘いと、MFAそのものを迂回されるおそれがあるためです。

よくある質問（FAQ）

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

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

追加できる可能性があります。SAMLやOIDCに対応していれば認証基盤と直接連携しやすく、非対応の場合も、認証ゲートウェイや代理認証、VPN、端末証明書を組み合わせられます。

画面の自動操作に依存する方式は、障害や改修の影響を受けやすいため、将来の刷新計画と合わせて判断します。

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

既存IDaaSを設定するだけなら0〜60万円程度、単一Webアプリへの追加なら100万〜500万円程度が推定の目安です。

複数システムのSSO連携は300万〜1,500万円程度、全社認証基盤は1,000万〜5,000万円以上です。

ライセンスやSMS、認証器、教育、保守、監視は別費用になる場合があります。そのため、5年間のTCOで比較します。

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

一般利用者へ早く展開する場合は、SMSや認証アプリが役立つことがあります。一方で、管理者やVPN、機密情報へのアクセスには、パスキーやFIDO2などを優先します。

端末紛失や共有端末での運用を検証し、必要に応じて、複数の方式をポリシーで使い分けます。

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

登録漏れや端末の非対応、認証器の紛失、古い業務システムとの連携不備で業務が止まる可能性があります。そのため、原則として段階導入が安全です。

まず管理者と代表部署でPoCを行い、告知、例外申請、予備認証器、復旧窓口を準備してから、対象を広げます。

まとめ

MFAは、ワンタイムコードの追加にとどまらず、認証要素や人事マスタ連携、条件付きアクセス、認証器の登録・失効・回復を含む認証基盤です。

監査ログや利用者教育、障害対応まで設計します。まず対象システムと利用者を棚卸しし、管理者や機密情報を扱う業務からリスクを分類します。

費用の推定レンジは、設定のみなら0〜60万円程度、単一アプリなら100万〜500万円程度です。複数システム連携なら300万〜1,500万円程度、全社基盤なら1,000万〜5,000万円以上です。

ライセンスや運用費を含むTCOで比べます。PoCでは、正常なログインに加えて、端末紛失や再登録、ネットワーク断、管理者ロックアウトも確認します。

また、退職者の無効化や認証基盤障害も試します。標準連携と追加開発の境界や、復旧手順、SLA、ログ、契約終了時の移行まで説明できる発注先を選ぶことが、長く使えるMFAにつながります。

認証方式だけでなく運用を含めた設計

業務リスクや利用者の端末、既存システムの連携方式、復旧要件を整理してから、適用範囲を決めます。

高リスクの管理者や重要操作には、フィッシング耐性方式を優先します。一方で、一般利用者には登録や復旧がしやすい手段を用意し、方式の使い分けを前提にします。

次の一歩：棚卸しと小規模PoC

まず、対象システムと利用者、管理者権限を一覧にします。認証情報、端末、ログ、IDライフサイクルも、一覧に加えます。

代表部署で正常系と失敗系を含むPoCを行い、費用・期間・運用負荷を実測します。そのうえで、全社展開の計画を固めます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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