多要素認証システム開発の発注/外注/依頼/委託方法について

多要素認証システムの発注では、既存のID基盤と業務アプリを棚卸ししたうえで、認証方式・復旧手順・監査ログまで含む範囲を定め、段階導入できる委託先を選ぶことが重要です。

「何を外注すればよいのか」「SaaSの利用料と開発費はいくら分けて考えるのか」「RFPや契約書に何を書けばよいのか」と迷う企業は少なくありません。この記事では、多要素認証システムを発注・外注・委託する際の進め方を、発注形態の選択、要件整理、契約形態、費用相場、委託先選定、見積比較の順に解説します。文書・契約・法務部門で使う契約管理システムや電子署名、外部弁護士向けポータルを想定し、現場で起きやすい端末紛失や緊急復旧も含めて整理します。

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

多要素認証システムを外注するときの全体像

多要素認証システムは、パスワードに別の認証要素を足すだけの画面改修ではありません。利用者の登録・異動・退職、業務アプリへのSSO、条件付きアクセス、認証ログ、失敗時の復旧までを一つの運用として設計します。発注時は「認証機能を作る会社」を探すのではなく、ID・認可・監査・移行・運用をどこまで任せるかを決めることが出発点です。

多要素認証は、知識情報、所持情報、生体情報のうち異なる要素を二つ以上組み合わせて本人を確認する仕組みです。パスワードと認証アプリのTOTP、パスワードとセキュリティキー、端末の生体認証とパスキーなどが該当します。同じパスワードを二回入力する方法は、入力回数が二回でも多要素にはなりません。二要素認証は、多要素認証のうち二つの要素を使う方式です。

IPAは、多要素認証について、IDと一つ目のパスワードが不正利用されてもログイン防止に効果がある方式として説明しています。一方、リアルタイム型フィッシングではOTPを入力させて突破する攻撃も想定されます。したがって、契約承認者や管理者のような高リスク利用者には、TOTPだけでなくFIDO2やパスキーを優先する方針をRFPに入れると、製品選定の基準が明確になります。

ログイン機能だけを発注範囲にすると、実装後に「退職者を即時停止できない」「スマートフォン紛失時に管理者が復旧できない」「契約書を削除した操作の証跡が残らない」といった問題が起きやすくなります。最低限、利用者ライフサイクル、SSOまたはAPI連携、認証方式、認可との役割分担、監査ログ、障害時の復旧、利用者教育、保守窓口を一つの業務フローとして見積もってもらいます。

発注はどのような順番で進めますか？

発注は、現状把握、リスク分類、方式選定、RFP作成、提案比較、パイロット、段階展開の順で進めると失敗を抑えやすくなります。最初から全社・全アプリを一括移行するのではなく、管理者や契約承認者など影響の大きい対象から小さく検証し、現場の復旧負荷を確認してから対象を広げます。

まず、Microsoft 365、Google Workspace、Active Directory、VPN、リモートデスクトップ、契約管理システム、電子署名、社内ポータルなど、認証を必要とするサービスを一覧化します。各サービスについて、利用者、管理者、外部利用者、共有アカウント、サービスアカウント、認証方式、ログの保存先、停止までの手順を整理します。

法務・契約領域では、社員だけでなく外部弁護士、取引先、派遣社員、契約承認者などが混在します。契約書の閲覧、ダウンロード、承認、削除、権限変更のように影響が異なる操作も分けます。認証済みであることと、操作を許可する認可は別要件ですので、委託先に「誰が、どの操作を、どの条件で許可されるか」を確認してもらいます。

MUSTには、特権IDへのMFA、退職者の即時無効化、契約承認など高リスク操作の再認証、認証ログの保管、管理者の緊急復旧を置きます。WANTには、全社へのパスキー展開、端末リスクに応じた高度な条件付きアクセス、外部利用者のセルフサービスなどを置き、予算と納期を見ながら第2段階に回します。

要件を一度に膨らませると、製品比較の前提がそろわず、見積もりも比較できません。「今回のリリースで必須」「将来対応」「採用しない」の三つに分け、各項目に理由と受入条件を付けます。たとえば「契約承認者はパスキーを必須にし、認証失敗が5回続いた場合は管理者確認へ遷移する」のように書くと、提案の差が見えます。

パイロットでは、実際の利用者が登録からログイン、端末変更、紛失申告、復旧まで完了できるかを確認します。特に圏外や海外出張、社給端末と私物端末の違い、共有端末、外部利用者の招待、管理者が不在の休日を想定します。ログイン成功率だけでなく、問い合わせ件数、復旧にかかった時間、管理者の作業時間も記録します。

本番移行は、対象グループを分けた段階展開とし、旧方式をいつ停止するかを明確にします。並行運用を長くしすぎると旧方式が抜け道になりますが、短すぎると業務停止につながります。移行判定には、重大な認証障害がないこと、ヘルプデスクの手順が完成していること、ブレークグラス用の緊急管理者アカウントを安全に保管していることを含めます。

発注形態はクラウド・パッケージ・スクラッチのどれが適切ですか？

多くの企業では、MFAの基盤はIDaaSや既存ライセンスを利用し、独自部分だけを連携開発する形が費用と安全性のバランスを取りやすくなります。クラウド、パッケージ、スクラッチの優劣を先に決めるのではなく、データ所在、既存環境、利用者体験、脅威への耐性、将来の運用体制を比較して選びます。

Microsoft 365やGoogle Workspaceを中心に利用し、標準的なSAML、OIDC、SCIM連携で業務アプリをつなげられる企業は、IDaaSを軸にした発注が向いています。Microsoft Entra ID P1は、多要素認証、パスワードレス認証、条件付きアクセス、イベントログなどを含み、公式表示は年払いで1ユーザーあたり月額899円相当です。Microsoft 365 E3やBusiness Premiumに含まれる場合もありますので、追加購入前に既存契約を確認します。

IDaaSでも、導入作業が不要になるわけではありません。テナント設計、グループと権限の整理、レガシーアプリの連携、ログのSIEM転送、利用者教育、復旧手順を構築会社に委託します。ライセンス販売だけの会社と、移行後の運用まで支援する会社を分けて評価することが大切です。

閉域網、オンプレミスのActive Directory、古いWebアプリ、特殊な端末、厳格なデータ保管要件がある場合は、認証製品を自社環境に置くパッケージ型やハイブリッド型を検討します。既存資産を残しながら、SAML対応のアプリから順番に移行できるか、製品の保守期限や脆弱性対応の責任分界を確認します。

この方式では、初期の構築費だけでなく、サーバー、冗長化、バックアップ、証明書、監視、パッチ適用の費用も発生します。提案書に「製品の標準機能」「追加開発」「顧客側で対応する作業」を分けて記載してもらうと、クラウド型との比較がしやすくなります。

顧客向けサービスの認証体験そのものが競争力になる場合や、標準製品では対応できない本人確認・認証API・高可用性・独自の監査要件がある場合に、スクラッチ開発を検討します。単に自社仕様にしたいという理由だけで認証基盤を作ると、暗号鍵管理、アカウント復旧、脆弱性対応、規格更新を長期に抱えることになります。

NISTの2025年版SP 800-63B-4では、パスワードはフィッシング耐性を持たず、手入力するOTPも認証セッションに結び付かないためフィッシング耐性とは扱われません。独自開発を発注する場合は、FIDO2やWebAuthnの適用、鍵のライフサイクル、レート制限、監査、第三者によるセキュリティ評価を要件に含めます。

RFPと要件整理で外せない項目

RFPは製品名を指定する文書ではなく、達成したい業務結果と制約条件を伝える文書です。利用者数、アプリ数、認証方式だけでなく、例外運用、移行、運用、セキュリティ検証、納品物まで書くと、提案会社が同じ前提で見積もれます。

社員、管理職、管理者、委託先、外部弁護士、取引先、顧客などの利用者区分を記載し、それぞれの登録方法、本人確認、利用停止、再登録、権限変更を示します。契約書を閲覧する場合、承認する場合、社外へ共有する場合、削除する場合で、必要な認証強度や再認証の有無が違うなら、シナリオを分けて書きます。

想定利用者数は、現在の人数だけでなく、ピーク時の同時利用者、月間アクティブユーザー、外部利用者の増加を分けます。ユーザー単位課金とMAU課金では見積の基準が変わるため、対象人数の定義をRFPで統一します。共有アカウントやサービスアカウントを残す場合は、人間の利用者と同じ方式を適用できない理由と代替統制も記載します。

連携対象には、SAML、OIDC、LDAP、Active Directory、SCIM、VPN、メール、端末管理、SIEMなどを挙げ、標準コネクターの有無、追加開発の有無、テスト環境の提供者を指定します。レガシーWebアプリなど標準連携が難しいものは、代理認証、リバースプロキシ、アプリ改修のどれを提案するかを委託先に求めます。

既存利用者のID、所属、メールアドレス、認証器情報をどう移行するかも重要です。認証器の秘密情報を移せない場合は、再登録の案内、期限、未登録者へのフォローを計画します。旧IDの削除、重複アカウントの統合、移行失敗時のロールバックをRFPに含め、移行設計書とデータ項目一覧を納品物にします。

多要素認証は、通常ログインよりも「使えないとき」の設計が成否を左右します。端末紛失、機種変更、退職、管理者の不在、認証サービス障害、通信断、バックアップコードの漏えいを想定し、本人確認の方法と復旧承認者を決めます。メールだけで簡単に解除できる設計は、MFAの強度を弱めるため慎重に扱います。

ログ要件では、認証成功・失敗、利用者・端末・IP、ポリシー判定、管理者操作、復旧操作、ログ転送の成否、保管期間を指定します。受入条件は「機能が動く」ではなく、「指定したアプリで認証できる」「退職者が所定時間内に停止される」「管理者操作を追跡できる」「重大障害時に復旧手順を実行できる」のように測定可能な表現にします。

契約形態は請負・準委任をどう使い分けますか？

要件が固まっていない調査・企画は準委任、成果物と仕様が定まった連携開発や設定作業は請負に分ける方法が実務的です。MFAの発注では、すべてを一つの契約に押し込めるより、調査、設計、構築、移行、運用引き継ぎの工程ごとに責任と変更ルールを分けると、追加費用の判断がしやすくなります。

準委任契約は、専門家の作業や助言を受けながら要件を固める工程に向いています。現状調査、認証方式の比較、RFP作成支援、移行計画、パイロットの評価では、途中で前提が変わる可能性があるため、作業時間、体制、定例会、成果物の定義を明確にして委託します。

ただし、準委任だから品質を約束しなくてよいわけではありません。担当者のスキル、作業報告、課題管理、レビュー方法、情報管理、再委託の条件を契約書や個別仕様書に記載します。特に認証基盤は機密性が高いため、作業用アカウントの権限、ログ取得、秘密情報の保管方法を確認します。

請負契約では、対象アプリ、対象利用者、認証方式、連携仕様、画面、ログ、性能、セキュリティ試験、移行、納期、検収条件を成果物として固定します。受入試験の不合格条件、瑕疵対応の期間、脆弱性が見つかった場合の修正範囲、ライセンスやクラウド費用の負担者も事前に確認します。

要件変更が発生した場合の変更管理も重要です。新しいアプリを追加する、パスキー対応を前倒しする、外部利用者を増やすといった変更について、影響調査、追加工数、納期変更、承認者を定めます。仕様書、設定値、ソースコード、テスト結果、運用手順書の引き渡しを契約上の納品物に含めると、将来のベンダー変更に備えられます。

調査・要件定義を準委任、固定範囲の構築を請負、運用監視を月額の保守契約とする分け方があります。契約を分ける場合は、前工程の成果物を次工程の入力資料として扱うこと、責任の境界、障害の切り分け、環境の引き渡し日を明記します。契約が分かれていることを理由に、移行失敗の責任が誰にもない状態を作らないことが大切です。

個人情報や認証ログを委託先が扱う場合は、秘密保持、再委託、保管場所、アクセス権限、事故時の報告、監査、契約終了時の返却・消去を確認します。個人情報保護委員会のガイドラインが示す安全管理措置を参考に、技術対策だけでなく組織的な管理手順まで契約・運用設計に落とし込みます。

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

費用は、ライセンス・API利用料、要件定義、連携開発、端末や認証器、移行、教育、監視、保守に分けて考えます。公開価格は製品や課金単位の比較材料であり、RFP作成や既存システムとの連携費を含みません。以下の初期費用はMFA単体の全国統計ではなく、リサーチノートの業務システム相場と公開料金から置く、相見積もり前の予算仮置きです。

従業員向けIDaaSの例では、Microsoft Entra ID P1の公式表示が年払いで1ユーザーあたり月額899円相当です。Okta Workforce IdentityはStarterが月額940円から、Essentialsが月額2,670円からで、年契約最低額24万円の記載があります。いずれも税、契約条件、追加機能、導入支援費を除く製品料金です（出典: Microsoft Entraのプランと価格、2026年確認／Oktaプランと価格、2026年確認）。

たとえば1,000ユーザーに単純適用すると、Entra ID P1は月約89万9,000円、OktaのStarterは月約94万円、Essentialsは月約267万円となります。ただし、既存のMicrosoft 365 E3やBusiness Premiumに含まれるなら追加費用は変わります。契約書には、対象ユーザー、最低購入数、年払い・月払い、為替、値上げ、退職者の扱い、解約時のデータ取り出しを確認します。

既存ID基盤の設定と管理者登録が中心なら、初期30万〜150万円、期間2〜8週間程度を予算仮置きにします。Microsoft 365、Google Workspace、Active Directoryと複数の業務アプリを連携し、SSO、条件付きアクセス、ログ設計、テスト、ヘルプデスク準備まで含める場合は、初期100万〜500万円、期間1〜3か月程度が目安です。対象ユーザー数、アプリ数、レガシー対応、移行範囲で変動します。

複数拠点、数千ユーザー、VPNや古いWebアプリを含む統合認証基盤は、初期500万〜1,500万円、期間3〜6か月程度を仮置きします。独自の顧客認証API、管理画面、パスキー、監査、高可用性をスクラッチ開発する場合は、1,500万〜4,000万円以上、6〜12か月以上の規模になる可能性があります。これらは公開統計ではなく、一般的な業務システムの工程・人月相場をMFAの前提に合わせた推定ですので、提案書では必ず内訳を確認します。

ランニングコストには、ライセンス、SMS、クラウド、認証器、端末管理、監視、問い合わせ、脆弱性対応、バックアップ、定期的なアクセスレビューを含めます。Google Cloud Identity Platformでは、電話認証とMFAがメッセージ送信単位で課金され、日本向けSMSは1通0.03米ドルと表示されています。最初の1日10通が課金されない条件もありますが、為替や利用量で変わります（出典: Google Cloud Identity Platformの料金、2026年確認）。

保守費は、初期開発費の年5〜15%程度を仮置きする方法がありますが、24時間監視、休日対応、脆弱性対応、ユーザー問い合わせを含むかで大きく変わります。初年度総額では、製品費と導入費だけでなく、利用者への案内、端末配布、教育、ヘルプデスクの増員まで含めて比較します。

委託先の選び方と見積比較のポイント

委託先は、製品の知名度や見積総額だけでなく、既存環境への適合、移行・復旧の設計力、運用を引き継ぐ力で選びます。IDaaSの販売代理店、認証製品の構築会社、業務システムの開発会社では得意領域が異なるため、自社の課題に近い実績を持つ会社を同じRFPで比較します。

「MFA導入実績があります」という説明だけでなく、利用者数、アプリ数、既存ID基盤、外部利用者の有無、移行期間、運用体制を確認します。可能であれば、契約管理、電子署名、VPN、リモートワーク、特権IDなど、自社に近いシナリオの実績を聞きます。提案担当者だけでなく、要件定義、構築、セキュリティ試験、運用引き継ぎを担う予定のメンバーと面談します。

また、Microsoft Entra、Okta、Google Cloud、オンプレミス製品など、特定製品一つに誘導するのではなく、既存契約と将来の移行可能性を説明できる会社を評価します。製品ベンダーと構築支援会社が別の場合は、障害時の一次窓口、仕様変更の責任、ライセンス更新の担当を明確にしてもらいます。

見積書は、要件定義、基本設計、詳細設計、設定・開発、連携、テスト、移行、教育、管理者訓練、保守に分けて比較します。さらに、ライセンス、クラウド、SMS、認証器、端末、監視サービスなどの実費を分離します。合計額が安くても、移行や復旧が別見積もりなら、初年度総額は高くなる可能性があります。

比較の際は、同じ前提で三社程度に依頼し、各社に「含む」「含まない」「前提条件」「追加時の単価」を記載してもらいます。評価は価格だけでなく、要件適合、セキュリティ、移行計画、運用体制、納品物、担当者の経験、契約条件の順に重み付けします。価格差が大きい場合は、工数を削っているのか、製品費を別にしているのか、対象範囲が違うのかを確認します。

危険な提案には、「すべて標準機能で対応できる」と言いながら、レガシーアプリ、外部利用者、復旧、ログの説明がないケースがあります。また、MFAを導入すればすべての不正アクセスを防げるという断定、SMSだけを唯一の方式にする提案、管理者用の例外アカウントを無制限に残す提案にも注意します。

選定前に、フィッシング耐性、パスキーの対応範囲、管理者権限の分離、ログの保管場所、障害時のSLA、脆弱性の通知、再委託、契約終了時のデータ返却を質問します。デジタル庁の2026年資料では、保証レベルに応じてパスキーなどを第一候補として検討する考え方が示されています。自社のリスクに対して認証強度が不足しないか、製品仕様と運用手順の両方で確認します。

よくある質問

ここでは、多要素認証システムの発注前に特に質問されやすい点をまとめます。製品の機能だけでなく、既存契約、利用者の負担、費用、運用責任を同時に確認することが大切です。

不要とは限りません。既存ライセンスにMFAや条件付きアクセスが含まれていても、アプリ連携、ID棚卸し、ポリシー設計、移行、復旧、教育、ログ監視は別途必要になることがあります。標準機能で対応できる範囲を確認したうえで、設定作業だけを委託するか、運用設計まで任せるかを決めます。

利用者の環境や業務のリスクによりますが、管理者や契約承認など高リスクの操作には、フィッシング耐性を持つパスキーやセキュリティキーを優先します。SMSは導入しやすい一方、SIMスワップや電話番号変更、海外利用の影響を受けるため、低リスク用途や代替手段として位置付け、復旧方法まで含めて比較します。

設定中心で対象アプリと利用者が少ない場合は、初期30万〜150万円程度を予算仮置きにできる可能性があります。複数アプリの連携、端末展開、外部利用者、監査ログ、教育まで含めると100万〜500万円程度のレンジに広がり、レガシー環境や独自開発を含めるとさらに増えます。自社の対象範囲を分けて、段階ごとに見積もりを取ることが重要です。

まとめ

多要素認証システムの発注は、MFA製品を購入するだけの案件ではありません。既存ID基盤とアプリを棚卸しし、利用者と高リスク操作を分類し、パスキーなどの認証方式、復旧、ログ、移行、教育、保守までを要件に含めます。製品費、導入費、運用費を分けたRFPを作成し、同じ前提で複数社の提案を比較します。

最初から全社一括で完成を目指さず、管理者、契約承認者、リモートアクセスなど影響の大きい対象でパイロットを行います。準委任で調査・要件定義を進め、仕様が固まった連携開発を請負にするなど、工程に合う契約形態を選びます。契約書には成果物、検収、変更管理、脆弱性対応、データ返却、運用引き継ぎを記載します。

安い見積もりを選ぶのではなく、対象範囲と前提をそろえた初年度総額で判断します。既存ライセンスの活用、レガシー連携、外部利用者、端末紛失時の復旧、監査ログ、パスキー対応、導入後の問い合わせ体制を質問し、自社の運用担当者が継続できる提案を選びます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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