多要素認証システム開発の進め方/やり方/流れや方法/手法/工程/手順

多要素認証システム開発は、認証方式を選ぶだけでなく、要件整理から運用定着までを段階的に設計して、認証と権限管理を安全に連携させる取り組みです。

「どの方式を選べばよいか」「既存のActive Directoryや業務アプリとつながるか」「費用はいくらか」「利用者が困ったときに誰が復旧するか」といった疑問を解消するため、本記事では多要素認証システム開発の進め方を6つのフェーズに分けて解説します。契約書や個人情報を扱う企業の情シス・法務部門が、ベンダーへの相談や相見積もりに使える判断基準とチェックリストも紹介します。

▼全体ガイドの記事
・多要素認証システム開発の完全ガイド

多要素認証システムの全体像とは？

多要素認証システムとは、パスワードなどの知識情報、スマートフォンやセキュリティキーなどの所持情報、指紋や顔などの生体情報から、異なる2つ以上の要素を組み合わせて本人確認する仕組みです。企業ではログイン画面だけでなく、IDの登録・変更・無効化、シングルサインオン、条件付きアクセス、監査ログ、復旧手順まで含む認証基盤として考える必要があります。

開発の最初に区別したいのが、認証と認可です。認証は「誰であるか」を確かめる処理で、認可は「その人が何をしてよいか」を決める処理です。たとえば契約管理システムで本人確認が済んでいても、契約書の削除や承認者の変更まで許可してよいとは限りません。利用者、所属、役職、契約案件、操作の重要度を組み合わせて、閲覧・承認・ダウンロード・削除・権限変更の可否を別々に定義します。

管理者や特権IDには通常利用者より強い認証を求め、認証成功だけでなく失敗回数、端末、接続元、時刻、利用した認証器、管理者操作も記録します。ログは認証基盤内だけに置かず、必要に応じてSIEMやSOCへ転送します。個人情報保護委員会のガイドラインが示す安全管理措置も踏まえ、ログの保存期間、参照権限、改ざん防止、削除手順を要件に含めることが重要です。

SMS認証は導入しやすい一方、SIMスワップや電話番号の乗っ取りへの備えが必要です。認証アプリのTOTPは通信できない場所でも使いやすく、プッシュ通知は操作が簡単ですが、承認を連打させるプッシュ疲労への対策が必要です。FIDO2やパスキーは公開鍵暗号を使い、偽サイトに認証情報を入力しにくいフィッシング耐性を持たせやすい方式です。

デジタル庁の2026年2月資料では、本人認証保証レベル3の代表例としてフィッシング耐性を持つ多要素認証やパスキーが示され、保証レベル2ではパスワードとワンタイムパスワードの組み合わせが例示されています。高い機密性がある契約承認、個人情報の一括出力、管理者権限の変更ではパスキーを優先し、一般利用者や復旧時の代替手段にはTOTPを用意するなど、リスクに応じて複数方式を組み合わせます。

多要素認証システム開発の進め方を6フェーズで解説

多要素認証システムは、製品を契約して設定すれば終わる案件ではありません。対象アプリ、利用者、認証器、例外運用、移行方法を順番に決め、各フェーズで次工程の判断材料を残します。以下では、要件整理、選定、設計開発、テスト、稼働、定着の6段階で実務上の進め方を示します。

まず、認証対象を一覧化します。Microsoft 365やGoogle Workspaceなどのクラウド、社内ポータル、VPN、リモートデスクトップ、契約管理システム、電子署名、ファイルサーバー、APIを洗い出し、認証方式、プロトコル、利用者数、管理者、停止時の業務影響を記録します。Active DirectoryやLDAPのユーザー、委託先、外部弁護士、取引先、共有アカウント、サービスアカウントも漏らさないことが重要です。

次に、操作ごとのリスクを評価します。「全員にMFAを適用する」だけでは、重要操作への再認証や不審な端末への追加確認が設計できません。管理者権限、契約承認、個人情報の出力、決済、削除、認証器の登録・解除をMUSTに置き、利便性向上の通知方式や全社自動プロビジョニングをWANTに分けます。成果物は、対象範囲表、リスク分類、MUST／WANT一覧、例外候補、成功指標です。

選定では、クラウド型IDaaS、既存認証製品を使うパッケージ型、独自認証APIや管理画面を作るスクラッチ型を比較します。Microsoft 365やWindows端末を中心に使う企業はMicrosoft Entra ID、異種クラウドや外部アプリを横断する企業はOkta、顧客向けWebサービスで認証を組み込む企業はGoogle Cloud Identity Platformなどが候補になります。ただし、製品名だけで決めず、既存契約に機能が含まれるか、構築支援を誰が担うかを分けて確認します。

比較表には、OIDC、SAML、LDAP、Active Directory、SCIMの対応、パスキー、端末管理、条件付きアクセス、ログのSIEM連携、データ保管場所、SLA、API制限、バックアップコード、管理者のブレークグラス、契約終了時のデータ取り出しを記載します。デモでは正常ログインだけでなく、端末紛失、機種変更、圏外、外部利用者の退職、認証器の再登録、緊急管理者の復旧まで実演してもらいます。

設計では、利用者がどの画面で何を入力し、どの条件で追加認証を求められ、失敗したときにどう復旧するかを画面遷移と状態遷移で整理します。初回登録、認証器の追加、認証器の紛失、パスワードリセット、退職・契約終了、共有IDの廃止、サービスアカウントの秘密情報更新を一連のライフサイクルとして定義します。認証を通過した後のセッション時間、再認証の条件、ログアウト、同時ログインの扱いも仕様化します。

連携開発では、SAMLやOIDCのクレーム、グループとロールの対応、SCIMのプロビジョニング、時刻ずれ、証明書更新、エラーコード、タイムアウトを確認します。契約管理システムでは「閲覧者」「承認者」「法務管理者」をID基盤のグループに対応させ、認証と業務側の認可を二重に検証します。ログの項目、マスキング、保持期間、監視アラート、運用手順書、仕様書の引き渡しを開発契約に含めることで、納品後の属人化を防ぎます。

テストは、正しい認証が通ることだけを確認してはいけません。利用者種別、端末、ブラウザ、ネットワーク、認証方式、業務アプリごとに正常系と異常系を組み合わせ、認証器の登録・解除、連続失敗時のロック、同意画面、トークンの有効期限、権限変更の反映、ログ出力を検証します。外部弁護士や取引先など、社内ディレクトリに存在しない利用者の登録・解除も実データに近い条件で試します。

セキュリティテストでは、フィッシング、リプレイ、セッション固定、認証コードの総当たり、プッシュ通知の連打、端末紛失後の不正利用、管理者アカウントの乗っ取りを想定します。障害テストではID基盤停止、ネットワーク断、SMS遅延、証明書期限切れ、同期失敗を確認し、ブレークグラスを使った緊急復旧が監査ログに残るかを検証します。受入基準を事前に決め、未解決の重大障害を残したまま本番へ進めないことが大切です。

全社一斉切り替えは、認証器の未登録や例外利用者が残ったときに業務を止めるリスクがあります。まず情シスや法務管理者など少人数でパイロットを実施し、次にリモートワーカー、契約承認者、一般利用者へ広げます。パイロットでは登録完了率、ログイン失敗率、問い合わせ件数、復旧時間、利用者の離脱理由を測定し、基準を満たしてから次の集団へ展開します。

切り替え前には、対象者への案内、登録期限、説明会、FAQ、ヘルプデスクの対応時間、本人確認を伴う復旧手続き、代替手段の有効期間を決めます。旧認証を並行稼働させる場合は終了日と利用条件を明確にし、古い方式が恒久的な抜け道にならないようにします。サービス停止を避けるため、切り戻し条件と責任者を決めたうえで、変更時間帯と関係部署への連絡経路を確認します。

稼働後は、ログイン成功率や認証失敗率だけでなく、異常な地域からのアクセス、深夜の管理者操作、短時間のプッシュ承認連続、認証器の大量登録・解除、退職者の残存アカウントを監視します。月次または四半期ごとにアクセス権レビューを行い、異動・退職・委託契約終了がIDの無効化へ反映されたかを確認します。ログのレビュー担当と、アラートを受けたときの一次対応・エスカレーション先を明文化します。

定着には、認証方式を増やすよりも、利用者が迷わず登録・復旧できる導線が欠かせません。入社時のアカウント発行、端末交換、紛失、長期休職、退職を人事・情シス・法務の手順に組み込み、半年ごとに訓練します。脅威や標準が変わったときに方式を見直せるよう、パスキーの利用率、SMS依存度、復旧件数、問い合わせの原因を指標として残します。

多要素認証システム開発の費用相場とコストの内訳

費用は、認証製品のライセンス料と、要件整理・連携開発・移行・教育・運用設計の費用を分けて考えます。以下の初期費用はMFA単体の全国統計ではなく、指定リサーチノートにある業務システム相場と公開料金をもとにした、相見積もり前の予算仮置きです。ユーザー数、アプリ数、既存ID基盤、求める可用性、外部利用者の有無で大きく変わるため、特定金額の断定ではなく前提条件とセットで使います。

既存のIDaaSを設定し、管理者登録、認証ポリシー、簡易トレーニングだけを行う場合は、初期30万〜150万円、期間2〜8週間が一つの目安です。Microsoft 365、Google Workspace、Active Directoryと業務アプリ数本を連携し、SSO、条件付きアクセス、グループ同期、ログ設計、テスト、ヘルプデスク準備まで行う場合は、初期100万〜500万円、期間1〜3か月程度を仮置きします。

複数拠点、数千ユーザー、VPNやレガシーWebを含む統合認証基盤では、既存システム改修、端末展開、ID棚卸し、段階移行が加わるため、初期500万〜1,500万円、期間3〜6か月程度を見込みます。顧客向け認証API、独自管理画面、パスキー、高可用性、詳細な監査、本人確認をスクラッチで作る場合は、1,500万〜4,000万円以上、6〜12か月以上となる可能性があります。金融・公共などで第三者評価や24時間運用が必要な場合は、別途見積もります。

公開価格の例では、Microsoft Entra ID P1が年払いでユーザー1人あたり月額899円相当です。MFA、パスワードレス認証、条件付きアクセス、SSOなどが含まれますが、Microsoft 365 E3やBusiness Premiumに内包される場合があるため、追加契約の前に既存ライセンスを確認します。Okta Workforce Identityは公式価格でStarterがユーザー1人あたり月額940円、Essentialsが月額2,670円からで、年間契約最低額24万円の記載もあります（出典：Microsoft「Microsoft Entraのプランと価格」、Okta「プランと価格」、2026年8月確認）。

顧客向け認証を従量課金で実装する場合は、利用者数とメッセージ数を分けて試算します。Google Cloud Identity Platformは多くのログイン方法を月間アクティブユーザーで計算し、電話認証とMFAはメッセージ送信ごとに課金します。日本向けSMSは1通0.03米ドルで、1日最初の10通は課金されない表示です（出典：Google Cloud「Identity Platformの料金」、2026年8月確認）。為替、SMS再送、認証失敗、クラウド利用料を加えると変動するため、月次上限とアラートを設定します。

初期費用とは別に、ライセンス、SMS、認証器、端末管理、監視、脆弱性対応、問い合わせ対応、定期的な権限レビューが発生します。指定リサーチノートの業務システム相場では、保守運用費を初期開発費の年5〜15％程度で仮置きしますが、24時間監視やオンサイト対応、認証器の現物支給を含める場合はこの範囲を超えることがあります。保守の対象時間、障害時の目標復旧時間、アップデートの責任分界を見積書に明記します。

費用を抑えるには、最初から全社・全アプリ・全機能を一度に実装せず、管理者、高機密データ、リモートアクセスなどリスクの高い領域からMVPを作ります。ただし、復旧や緊急管理者を後回しにしてはいけません。人件費は総額の40〜60％を占めやすく、要件定義約10％、設計10〜20％、開発40〜60％、テスト10〜20％という工程別の仮置きも、見積の妥当性を検討する材料になります。

多要素認証システムの見積もりを取るポイント

相見積もりで金額だけを比べると、認証器の紛失対応やログ監視が抜けた提案を安く見積もることがあります。見積依頼書には、対象利用者数、アプリ数、外部利用者、既存ディレクトリ、必要な認証方式、連携プロトコル、稼働希望時期、テスト範囲、教育、保守、成果物を記載します。各社に同じ前提を渡し、含む作業と含まない作業を分けて比較します。

要件定義書には、利用者の種類と人数、IDの発行・変更・停止条件、対象アプリ、認証方式、認証強度、認証失敗時の制御、セッション、条件付きアクセス、管理者権限、ログ、監査、データ保管場所を書きます。加えて、共有アカウント、サービスアカウント、スマートフォンを持たない利用者、海外拠点、圏外の現場、委託先、端末紛失、機種変更、退職者、緊急時のブレークグラスを例外シナリオとして渡します。

成果物は、要件定義書だけでは不十分です。認証・認可の設計書、連携仕様、画面仕様、テスト計画と結果、移行計画、運用手順書、復旧手順、監視項目、管理者教育資料、利用者向けFAQ、ソースコードや設定値の引き渡し条件まで確認します。特にクラウド設定は担当者の個人アカウントに閉じず、契約終了後も自社が管理できる形で納品してもらいます。

ベンダーを選ぶときは、製品の機能表だけでなく、要件整理から運用定着まで同じ担当体制で支援できるかを確認します。質問する項目は、類似するユーザー数・アプリ数の導入経験、SAMLやOIDCの実装経験、既存ADとの連携、パスキーの設計、移行時の障害対応、ヘルプデスクの分担、ログ監視、脆弱性対応、契約終了時のデータ返却です。製品ベンダーと構築支援会社を分けて契約する場合は、障害時の一次窓口を一つにします。

契約形態も工程ごとに検討します。要件が固まっていない調査・要件整理は準委任、対象と成果物が明確な連携開発は請負とする方法があります。指定リサーチノートでは、仕様変更リスクを価格に含む請負が準委任より1.3〜1.5倍程度高くなる傾向が示されていますが、契約条件やリスク分担で変わるため一律には決めません。変更管理、追加費用の条件、検収基準、瑕疵対応、保守への移行日を見積書と契約書で一致させます。

見積の確認では、初期費用の安さよりも、後から発生する費用の条件を見ます。対象外アプリの追加連携、ユーザー数の増加、SMSの再送、認証器の購入、端末管理、24時間監視、休日対応、脆弱性診断、ログ保管容量、データ移行、教育追加、旧方式の並行運用を項目別に確認します。特に利用者数を「登録数」「月間アクティブユーザー」「同時接続数」のどれで数えるかをそろえます。

導入前のチェックリストとして、第一にMUSTとWANTが分かれているか、第二に認証方式ごとの脅威と代替手段が記載されているか、第三に復旧・緊急アクセス・退職者の無効化がテスト対象か、第四にログと監査の責任者が決まっているか、第五に段階移行と切り戻し条件があるか、第六に仕様書・設定・教育資料が納品対象かを確認します。この6点が曖昧な見積は、安く見えても本番後の追加費用や業務停止につながりやすいです。

多要素認証システム開発でよくある質問

最後に、導入前に特に相談が多い疑問へ回答します。費用や方式は会社の規模だけで決まらず、守る情報、利用者、連携先、復旧体制によって変わります。自社の状況を以下の回答に当てはめ、足りない条件をRFPへ追加します。

追加開発が不要とは限りません。Microsoft Entra IDの機能や既存ライセンスでMFAを有効にできても、対象アプリとの連携、条件付きアクセス、グループ設計、端末紛失時の復旧、ログ監視、利用者教育は別途設計が必要です。既存契約にP1相当の機能が含まれるかを確認し、設定作業と業務アプリ側の改修を分けて見積もります。

導入しやすさを優先する一般利用者にはSMSやTOTPが候補になりますが、管理者や契約承認など高リスク操作にはフィッシング耐性を持たせやすいパスキーを優先します。IPAは2025年8月の注意喚起で、2025年7月に不正ログインに関する相談が144件寄せられたことを示し、多要素認証やパスキーの利用を推奨しています（出典：IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。方式を一つに固定せず、端末保有状況と復旧手段を含めて段階導入します。

本人確認をした管理者が、紛失端末の認証器を無効化し、別の端末やセキュリティキーを登録できる復旧フローを用意します。復旧時にメールだけで本人確認すると、メールアカウントが乗っ取られた場合の抜け道になるため、所属情報、上長承認、本人確認書類、対面確認など、情報の機密度に応じた手段を選びます。復旧操作は必ず監査ログへ記録し、緊急管理者を使った場合は事後レビューを行います。

設定中心なら2〜8週間、既存のMicrosoft 365・Google Workspace・ADと業務アプリ数本を連携する場合は1〜3か月、複数拠点やレガシーシステムを含む統合認証基盤は3〜6か月程度が仮置きの目安です。独自認証APIや高可用性、顧客向け本人確認をスクラッチで作る場合は6〜12か月以上になる可能性があります。対象アプリの棚卸しや利用者データの品質が悪いと要件整理と移行に時間がかかるため、期間は開発会社の標準値ではなく自社の前提で確認します。

まとめ：多要素認証システム開発は段階導入が成功の鍵です

多要素認証システム開発を成功させるには、認証方式の比較から始めず、守る情報と業務上のリスクを先に整理します。要件整理で対象アプリ、利用者、例外、認証強度を定め、選定で既存ライセンスと連携方式を確認し、設計開発、テスト、段階稼働、運用定着へ進めます。

第一に、管理者・契約承認者・高機密データへのアクセスには、パスキーなどフィッシング耐性を持たせやすい方式を優先します。第二に、費用はライセンスだけでなく、連携、移行、教育、監視、復旧、保守を含む初年度総額で比較します。第三に、端末紛失、退職、共有ID、サービスアカウント、緊急管理者を本番前にテストし、導入後の責任者とレビュー周期まで決めます。

最初の一歩は、対象システムと利用者を一覧にし、MUSTとWANT、例外シナリオ、必要なログ、段階導入の対象を1枚にまとめることです。その資料をもとに複数社へ同じ条件で相談すれば、金額だけでなく、設計力、復旧体制、移行計画、運用定着まで比較できます。多要素認証を導入して終わりにせず、利用率とインシデントを定期的に見直すことで、業務を止めずに認証強度を高められます。

▼全体ガイドの記事
・多要素認証システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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