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

多要素認証システムの開発は、守る情報と利用者を整理し、要件に合う方式と製品を選び、テストを重ねながら段階的に導入する流れで進みます。認証と認可の設計や、費用と見積もりの確認点も、この流れの中で押さえておくと安全な運用につながります。

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

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

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

多要素認証システムは、知識・所持・生体情報のうち異なる2つ以上を組み合わせ、本人を確認する仕組みです。

企業では、ログインだけでなく、IDの登録・変更・無効化、シングルサインオン、条件付きアクセスも対象になります。

開発では、監査ログや復旧手順まで含めて、認証基盤として設計します。認証方式の選択と並行して、権限管理や運用の範囲も決めます。

認証・認可・監査の一体設計

認証は「誰であるか」を確かめ、認可は「何をしてよいか」を決めます。

たとえば、契約管理システムで本人確認が済んでも、契約書の削除や承認者の変更まで許可されるとは限りません。

• 権限の定義：利用者、所属、役職、案件、操作の重要度に応じて、閲覧や削除などを個別に許可します。
• 特権IDの認証：管理者には通常利用者より強い認証を求めます。
• 監査記録：成功・失敗、端末、接続元、時刻、認証器、管理者操作を記録します。

ログは、必要に応じてSIEMやSOCへ転送します。保存期間と参照権限は、個人情報保護委員会のガイドラインを踏まえて決めます。さらに、改ざん防止と削除手順も要件に含め、安全管理措置を整えます。

リスクと利用者負担による認証方式の選択

認証方式は、脅威への強さと利用者の使いやすさを照らし合わせて選びます。方式ごとの特徴を理解したうえで、操作の重要度に応じて組み合わせます。

• SMS認証：導入しやすい一方、SIMスワップや電話番号の乗っ取りに備えます。
• TOTP：通信できない場所でも使いやすい認証アプリ方式です。
• プッシュ通知：操作は簡単ですが、承認の連打を促すプッシュ疲労への対策が要ります。
• FIDO2・パスキー：公開鍵暗号を使い、偽サイトへの入力を防ぎやすい方式です。

デジタル庁の2026年2月資料では、保証レベル3の代表例として、フィッシング耐性のある多要素認証やパスキーが示されています。レベル2の例は、パスワードとワンタイムパスワードの組み合わせです。

特に、契約承認、個人情報の一括出力、管理者権限の変更には、パスキーを優先します。一方で、一般利用者や復旧時には、TOTPを用意するなど、リスクに応じて複数の方式を使い分けます。

多要素認証システム開発の進め方（6フェーズ）

製品を契約して設定したあとも、対象アプリ、利用者、認証器、例外運用、移行方法を順に決める作業が残ります。

進め方は、要件整理、選定、設計開発、テスト、稼働、定着の6段階です。各段階で判断材料を残しながら、次の段階へ進みます。

フェーズ1：要件整理と対象範囲・リスクの明確化

要件整理では、認証の対象と利用者、操作のリスク、成果物を明らかにします。接続先のシステムから共有・サービスアカウントまでを、次の5項目で書き出します。

• システム：クラウド、社内ポータル、VPN、リモートデスクトップ、契約管理、電子署名、ファイルサーバー、API。
• 接続情報：認証方式、プロトコル、利用者数、管理者、停止時の業務影響を記録します。
• 利用者：Active DirectoryやLDAPのユーザー、委託先、外部弁護士、取引先、共有・サービスアカウント。
• 優先度：管理者権限や契約承認などはMUST、通知方式や全社自動プロビジョニングはWANTとして分けます。
• 成果物：対象範囲表、リスク分類、MUST／WANT一覧、例外候補、成功指標を用意します。

全員に一律で多要素認証を適用すると、重要操作への再認証や不審端末への追加確認を組み込みにくくなります。そのため、操作ごとにリスクを評価します。

なかでも、管理者権限と契約承認は優先して整理します。ほかに、個人情報の出力や決済がかかわる操作、削除、認証器の登録・解除も対象です。

要件と運用に基づく製品・方式の選定

製品と開発方式は、要件との適合や運用の分担を含めて比べます。Microsoft 365やWindows端末を中心にするならEntra ID、異種クラウドや外部アプリをまたぐならOktaが候補になります。

顧客向けのWebサービスでは、Google Cloud Identity Platformなどを検討します。選定時には、次の観点を確認します。

• 方式：クラウド型IDaaS、既存製品のパッケージ型、独自APIなどを作るスクラッチ型。
• 連携・機能：OIDC、SAML、LDAP、AD、SCIM。パスキー、端末管理、条件付きアクセス、SIEM連携。
• 契約・運用：既存機能、支援担当、保管場所、SLA、API制限、バックアップコード、緊急管理者。
• デモ：紛失、機種変更、圏外、外部利用者の退職、再登録、緊急復旧を試します。

契約を終えた後にデータを取り出せるかも確認します。機能と支援の範囲を見極めたうえで、製品を選びます。

フェーズ3：認証フローと連携の設計・開発

利用者が入力する画面、追加認証が求められる条件、認証に失敗したときの復旧を、画面と状態遷移で整理します。設計と開発では、次の項目を決めます。

• ライフサイクル：初回登録、認証器の追加・紛失、パスワードリセット、退職・契約終了。
• アカウント：共有IDの廃止、サービスアカウントの秘密情報更新を定義します。
• 認証・連携：セッション時間、再認証、ログアウト、同時ログイン、SAML・OIDCのクレーム、SCIM。
• 業務権限：「閲覧者」「承認者」「法務管理者」をグループに対応させ、認証・認可を検証します。
• 納品・運用：ログ、マスキング、保持期間、監視、手順書、仕様書の引き渡しを契約に含めます。

連携では、グループとロールの対応やSCIMのプロビジョニングを確認します。時刻のずれや証明書の更新も確かめます。

エラーコードやタイムアウトの扱いも、あわせて確認します。二重に検証しておくと、誤って許可される事態を防ぎやすくなります。

フェーズ4：機能・連携・攻撃・復旧のテスト

利用者や環境ごとに、正常系と異常系の両方を試します。機能・攻撃・障害・復旧の観点で確認します。

• 機能・連携：端末やブラウザごとの認証、登録・解除、ロック、同意画面、期限、権限反映、ログ。
• 外部利用者：社内ディレクトリにない弁護士や取引先の登録・解除を、実データに近い条件で試します。
• 攻撃：フィッシング、リプレイ、セッション固定、認証コードの総当たり、プッシュ連打、紛失端末、管理者乗っ取り。
• 障害・復旧：ID基盤停止、ネットワーク断、SMS遅延、証明書切れ、同期失敗を確認します。
• 緊急復旧：ブレークグラスによる復旧が監査ログに残るかを確かめます。

利用者の種別や端末、ネットワークを組み合わせて検証します。ブラウザ、認証方式、業務アプリとの組み合わせも、対象に含めます。

受入基準は先に決めておき、重大な障害を残したまま本番へ進まないようにします。

フェーズ5：パイロットからの段階的な稼働

未登録の人や例外的な利用者がいると、全社で一斉に切り替えたとき業務が止まるおそれがあります。そのため、段階的な稼働では次の点を決めます。

• 展開順：情シスや法務管理者で試し、リモートワーカー、契約承認者、一般利用者へ広げます。
• 測定：登録完了率、ログイン失敗率、問い合わせ件数、復旧時間、離脱理由を見て次段階を判断します。
• 利用者支援：案内、登録期限、説明会、FAQ、ヘルプデスク時間、本人確認付き復旧、代替手段の期限を決めます。
• 切り替え管理：旧認証の終了日・条件、切り戻し条件・責任者、変更時間、連絡経路を定めます。

旧認証を並行して稼働させる場合は、終了日と利用条件を明確にします。また、旧方式が恒久的な抜け道として残らないようにします。

パイロットで定めた基準を満たしてから、次の利用者集団へ広げます。さらに、サービスの停止を避けるため、変更の時間帯と関係部署への連絡経路も確認します。

フェーズ6：運用監視と利用定着の仕組み化

稼働後は、監視、権限の確認、利用者支援、方式の見直しを運用に組み込みます。

• 監視：成功・失敗率、異常地域、深夜の管理者操作、連続プッシュ、大量登録・解除、退職者アカウント。
• 権限レビュー：月次または四半期ごとに確認し、異動・退職・委託終了後の無効化を点検します。
• 利用者支援：入社、端末交換・紛失、休職、退職時の登録・復旧を人事・情シス・法務の手順にし、半年ごとに訓練します。
• 改善指標：パスキー利用率、SMS依存度、復旧件数、問い合わせ原因を記録して方式を見直します。

ログのレビュー担当と、アラート時の一次対応・エスカレーション先は、文書にしておきます。あわせて、利用者が迷わず登録や復旧を行えるよう、導線も用意します。

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

費用は、ライセンス料と、要件整理・連携開発・移行・教育・運用設計の費用に分けて考えます。

ここで示す金額や期間は、MFA単体の全国統計ではありません。指定リサーチノートの業務システム相場と公開料金をもとにした、相見積もり前の予算の仮置きです。

金額は、利用者数やアプリ数によって変わります。既存のID基盤や可用性、外部利用者の有無も条件になります。前提条件とセットで読み、予算の目安として使います。

初期費用の段階（設定中心から独自開発まで）

IDaaSの設定から独自認証の実装まで、開発規模ごとに初期費用と期間を見ていきます。

• 設定中心：IDaaS設定、管理者登録、認証ポリシー、簡易研修のみなら30万〜150万円、2〜8週間が目安。
• 業務アプリ連携：業務アプリ数本の連携で100万〜500万円、1〜3か月程度。
• 統合認証基盤：複数拠点、数千ユーザー、VPNやレガシーWebを含み、500万〜1,500万円、3〜6か月程度。
• スクラッチ開発：顧客向け認証APIなどを作る場合、1,500万〜4,000万円以上、6〜12か月以上の可能性。

連携先の例として、Microsoft 365、Google Workspace、Active Directoryが挙げられます。

業務アプリ連携の範囲には、SSOや条件付きアクセス、グループ同期の設定が入ります。加えて、ログ設計、テスト、ヘルプデスク準備も含みます。統合基盤では、これらに既存改修、端末展開、IDの洗い出しが加わり、段階移行も含まれます。

スクラッチでは、パスキーや高可用性のほか、詳細監査や本人確認などを実装する場合があります。金融・公共などの第三者評価や24時間運用は、別途見積もります。

ライセンスと認証メッセージの費用

法人向けIDaaSと顧客向け認証では課金の対象が異なるため、料金の仕組みを分けて確認します。

• Microsoft Entra ID P1：年払いで1人あたり月額899円相当。
• Okta Workforce Identity：1人あたりStarterは月額940円、Essentialsは月額2,670円から。年間契約の最低額は24万円。
• Google Cloud Identity Platform：多くの方式は月間アクティブユーザー、電話認証とMFAは送信メッセージで課金。
• 日本向けSMS：0.03米ドル/通、1日最初の10通は非課金（出典：Google Cloud「Identity Platformの料金」、2026年8月確認）。

Entra ID P1には、MFAやパスワードレス認証に加えて、条件付きアクセスやSSOなども含まれます。

Entra ID P1は、Microsoft 365 E3やBusiness Premiumに内包される場合があります（出典：Microsoft「Microsoft Entraのプランと価格」、2026年8月確認）。追加契約の前に、この点を確認します。

Oktaの料金は、公式価格を参照した例です（出典：Okta「プランと価格」、2026年8月確認）。顧客向け認証では、利用者数とメッセージ数を分けて試算します。

為替やSMS再送の影響に加えて、認証失敗やクラウド利用料でも費用は変動します。そのため、月次の上限とアラートを設定します。

運用費の内訳（保守・監視・教育を含む）

運用費は、継続して払う利用料に、保守と人件費を工程別に配分した額を合わせて見積もります。

• 継続費用：ライセンス、SMS、認証器、端末管理、監視、脆弱性対応、問い合わせ、権限レビュー。
• 保守運用：初期開発費の年5〜15％程度を仮置き。24時間監視、オンサイト対応、認証器の現物支給で超える場合があります。
• 段階導入：管理者や高機密データなどからMVP（Minimum Viable Product）を作り、復旧は後回しにしません。
• 人件費・工程：総額の40〜60％。要件定義約10％、設計10〜20％、開発40〜60％、テスト10〜20％。

指定リサーチノートの業務システム相場をもとにした仮置きです。保守の対象時間、障害時の目標復旧時間、アップデートをどこまで誰が受け持つかを、見積書に明記します。

リスクの高い領域から着手し、全社・全アプリ・全機能を一度に実装する進め方は避けます。

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

金額だけで比べると、認証器の紛失対応やログ監視が抜けた提案が安く見えることがあります。そのため、同じ前提を各社に渡し、含まれる作業と含まれない作業を比べます。

見積依頼書には、対象の利用者数やアプリ数、外部利用者、既存のディレクトリを記載します。認証方式や連携プロトコル、稼働希望時期、テスト範囲も書き込みます。教育、保守、成果物も、あわせて記載します。

要件定義書に記載する対象・例外・成果物

見積もりの条件をそろえるため、要件定義書と納品物に必要な情報を具体的に定めます。

• 基本要件：利用者数、ID発行・変更・停止、対象アプリ、認証方式・強度、失敗時制御、セッション。
• 統制と例外：条件付きアクセス、管理者権限、ログ、監査、保管場所、共有・サービスID、スマホなし、海外・圏外・委託先。
• 例外シナリオ：端末紛失、機種変更、退職者、緊急時のブレークグラス。
• 成果物：認証・認可設計書、連携・画面仕様、テスト、移行、運用・復旧手順、監視、教育、FAQ。
• 引き渡し：ソースコードや設定値の条件を定め、クラウド設定は個人アカウントに閉じず、契約後も自社で管理します。

発注先の比較（製品・開発・運用の責任範囲）

発注先は、製品の機能に加えて、製品・開発・運用ごとに、どこまでを誰が受け持つかで比べます。経験、運用支援、契約方式、価格と条件の4点を、この順に見ていきます。

• 経験：類似するユーザー数・アプリ数、SAML・OIDC、既存AD連携、パスキー設計の実績。
• 運用支援：要件整理から定着まで同じ担当体制で支えられるか。移行障害、ヘルプデスク、ログ監視、脆弱性対応、データ返却も確認します。
• 契約方式：調査・要件整理は準委任、成果が明確な連携開発は請負とする方法があります。
• 価格と条件：仕様変更リスクを含む請負は準委任より1.3〜1.5倍程度高い傾向ですが、契約条件やリスク分担で変わります。

製品会社と構築支援会社を分ける場合は、障害時の一次窓口を一つにします。

変更管理や追加費用、検収基準は、見積書と契約書で食い違いのないようにします。瑕疵対応と保守への移行日は、両方の書類で同じ内容にします。

導入リスクと追加費用の洗い出し

初期費用以外の追加条件や導入リスクも、あわせて比べます。見積もりでは、次の点を確認します。

• 追加費用：連携追加、利用者増、SMS再送、認証器、端末管理、24時間監視、休日対応。
• 移行・運用：脆弱性診断、ログ容量、データ移行、追加教育、旧方式の並行運用。
• 計上単位：利用者数を登録数、月間アクティブユーザー、同時接続数のどれで数えるか統一します。
• 安全策：MUST／WANT、脅威と代替手段、復旧・緊急アクセス・退職者無効化のテスト。
• 責任と納品：ログ・監査担当、段階移行・切り戻し、仕様書・設定・教育資料。

条件があいまいな見積もりは、本番後の追加費用や業務停止につながるおそれがあります。

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

費用や方式は、会社の規模に加えて、守る情報や利用者の範囲、連携先、復旧体制によって変わります。そのため、自社の状況に照らして、足りない条件をRFPに追加します。

Microsoft 365を使っていれば追加開発は不要ですか？

Microsoft Entra IDや既存ライセンスでMFAを有効にできても、追加開発が必要になることがあります。対象アプリとの連携、条件付きアクセス、グループ設計は、別途確認します。

端末紛失時の復旧やログ監視、利用者教育も、設計が必要です。既存契約にP1相当の機能が含まれるかを確認したうえで、設定作業と業務アプリ改修を分けて見積もります。

SMS認証とパスキーはどちらを選べばよいですか？

利用者と操作のリスクに応じて、認証方式を選びます。

• 一般利用者：導入しやすいSMSやTOTPが候補です。
• 高リスク操作：管理者や契約承認には、フィッシング耐性を持たせやすいパスキーを優先します。

IPAは、2025年8月の注意喚起で、2025年7月に不正ログインの相談が144件寄せられたと示しています。また、多要素認証やパスキーの利用を推奨しています（出典：IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。

端末の保有状況と復旧手段を含めて方式を組み合わせ、段階的に導入します。

スマートフォンを紛失したときはどう復旧しますか？

本人確認を済ませた管理者が、紛失した端末の認証器を無効化し、別の端末やセキュリティキーを登録できる復旧の流れを用意します。

メールだけで本人確認すると、そのメールアカウントの乗っ取りが抜け道になります。機密度に応じて、所属情報や上長承認、本人確認書類、対面確認などを組み合わせます。

復旧操作は監査ログに残します。緊急管理者を使った場合は、事後にレビューを行います。

多要素認証システムの開発期間はどれくらいですか？

設定だけで済む場合から独自の認証基盤まで、開発規模ごとの仮の期間を比べます。

• 設定中心：既存サービスの設定なら2〜8週間。
• 業務アプリ連携：Microsoft 365・Google Workspace・ADと数本を連携する場合は1〜3か月。
• 統合基盤：複数拠点やレガシーシステムを含む場合は3〜6か月程度。
• 独自開発：認証API、高可用性、顧客向け本人確認は6〜12か月以上の可能性があります。

アプリの洗い出しが不十分だったり、利用者データの品質が低かったりすると、要件整理と移行に時間がかかります。そこで、期間は開発会社の標準値に頼らず、自社の前提で確認します。

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

成功のためには、認証方式を比べる前に、守る情報と業務上のリスクを整理します。対象アプリや利用者、例外、認証強度を定めてから、製品を選びます。

その後は、設計開発やテストを経て、段階稼働と運用定着へ進みます。既存のライセンスと連携方式も、選定時に確認します。

まず決めるべき3つの判断基準

管理者や契約承認者、高機密データへのアクセスには、フィッシング耐性を持たせやすいパスキーなどの方式を優先します。

費用は、ライセンス料に加えて、連携・移行・教育などを含めた初年度の総額で比べます。監視や復旧、保守も、同じ総額に含めます。

端末紛失や退職といった場面を、本番前にテストします。共有IDやサービスアカウント、緊急管理者も、同じ場面で確かめます。導入後は、責任者とレビュー周期を決めておきます。

見積もり前の現状整理

導入前の洗い出しと相談から、稼働後の見直しまでを一続きで考えます。見積もりの前に、次の内容をそろえておきます。

• 現状整理：システム、利用者、MUST／WANT、例外、必要なログ、段階導入の対象を1枚にまとめます。
• 複数社への相談：同じ条件を渡し、設計力、復旧体制、移行計画、運用定着を比較します。
• 定期見直し：導入後も利用率とインシデントを確認し、業務を止めずに認証強度を高めます。

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

▼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を創業。