顔認証システムの導入を成功させられるかどうかは、開発が始まる前のRFP（提案依頼書）と要件定義の精度でほぼ決まります。「とにかく顔で入退室できればいい」という曖昧な依頼でベンダーに丸投げすると、自社の現場環境では精度が出なかったり、必要な連携が標準に含まれず追加費用が膨らんだりと、後悔につながりがちです。逆に、認証精度の目標、対象環境、連携要件、セキュリティ要件を数値と条件で明文化したRFPを作れば、ベンダーからの提案を正しく比較でき、見積りのブレも抑えられます。
本記事は、顔認証システムのRFP・要件定義書・提案依頼書をどう書くべきかを、発注企業の視点から実践的に整理する「要件定義特化」の解説です。本人拒否率・他人受入率といった精度要件、稼働率や応答速度の性能要件、勤怠や入退室管理との連携要件、個人情報保護を含むセキュリティ要件、そして見積りを正しく取るためのRFP記載項目まで、具体的な書き方とともに掘り下げます。読み終えるころには、自社のRFPに何を盛り込み、どこを数値で縛るべきかが見えてくるはずです。なお、顔認証システム全体の費用相場や仕組みの全体像をまだ把握していない方は、まず顔認証システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・顔認証システムの完全ガイド
認証精度に関する要件定義
顔認証システムのRFPで最も重要かつ、最も曖昧になりがちなのが認証精度の要件です。「精度が高いこと」とだけ書いても、何をもって高いとするかが定義されていなければ、提案も評価もできません。精度は本人拒否率と他人受入率という二つの指標で表現し、それぞれに目標値を設定することが、要件定義の出発点になります。
本人拒否率・他人受入率の目標値を定める
本人拒否率は「本人なのに認証されない確率」、他人受入率は「他人を本人と誤認する確率」を指します。この二つはトレードオフの関係にあり、片方を下げればもう片方が上がる傾向があります。RFPでは、自社の用途に応じてどちらをどこまで重視するかを明示する必要があります。たとえば高セキュリティエリアでは他人受入率を極限まで下げることを最優先し、一般オフィスでは利便性のために本人拒否率を低く抑えることを優先する、といった具合です。
重要なのは、これらの目標値を「自社の実環境での実測値」として求めることです。メーカーが公表する数値は、理想的な照明・正面顔といった最適条件で測定されたものであることが多く、実際の現場では悪化します。RFPには、本番に近い環境でのPoC（概念実証）を実施し、そこで本人拒否率と他人受入率を実測して目標を満たすことを納品条件にする、と明記するのが有効です。これにより、カタログスペックと現場実態の乖離による導入失敗を防げます。
利用環境・条件を要件として明記する
顔認証の精度は、利用環境に大きく左右されます。RFPには、自社の利用条件を具体的に記載することが欠かせません。設置場所が屋内か屋外か、照明はどの程度の明るさか、逆光の有無、想定される利用者数、マスクや帽子・保護具の着用有無、利用者の動線と通過速度といった条件を漏れなく伝えることで、ベンダーは自社環境に適した製品とカメラ設置を提案できます。
これらの条件を曖昧にしたままRFPを出すと、ベンダーは無難な前提で見積もり、いざ設置すると現場で精度が出ない、という事態を招きます。とくに屋外や逆光環境、マスク常用といった厳しい条件は、対応の可否で製品が大きく絞られるため、最初に明示しておくほど提案の質が上がります。自社の利用シーンを写真や図面で添付するくらいの丁寧さが、結果的に手戻りを防ぎ、適切なベンダー選定につながります。
PoCの実施条件と合否基準を定義する
精度要件を実効性のあるものにするには、PoCの実施を要件として明確に位置づけることが欠かせません。どの場所で、どのくらいの期間、何人の被験者で、どんな環境条件のもとに検証を行うかを、RFPで定義します。検証の規模が小さすぎたり、最適条件でだけ測ったりすると、本番運用での実態を反映できません。実際の利用者構成や時間帯のばらつきを含めた条件でPoCを設計することが、意味のある検証につながります。
あわせて、PoCの合否基準を事前に数値で定めておくことも重要です。本人拒否率と他人受入率がどの水準を下回れば合格とするか、認証速度が何秒以内であれば許容するかを決めておけば、検証結果を客観的に評価できます。基準が曖昧だと、「だいたい動いたから良し」となり、本番で問題が表面化します。PoCを単なるデモではなく、合否を判定する正式な検証工程としてRFPに組み込むことが、導入失敗を防ぐ最も実効性のある手立てです。
稼働率・応答速度などの性能要件
精度と並んで定義すべきが、システムの性能とサービスレベルに関する要件です。入退室の鍵を担う顔認証は、止まると業務そのものが止まります。稼働率、認証の応答速度、障害時の対応といった非機能要件を数値で縛ることが、安定運用の前提になります。一般に、こうしたサービス品質はSLA（サービス品質保証）として契約に盛り込みます。
稼働率99.9%などSLAを要件化する
入退室や勤怠の基盤として顔認証を使うなら、稼働率の目標を要件に盛り込むべきです。多くの業務システムでは、年間稼働率99.9%以上が一つの選定基準とされます。99.9%は年間の停止時間に換算するとおよそ8.7時間に相当し、これを超える停止が許容できるかどうかを自社の業務影響から逆算して決めます。稼働率を数値で定めておけば、ベンダーは冗長構成や障害復旧の体制を含めて提案せざるを得なくなります。
稼働率と合わせて、障害発生時の復旧目標時間や、サポートの受付時間・対応窓口もRFPで確認します。24時間稼働の施設なら、夜間・休日のサポート体制が不可欠です。また、認証端末がネットワーク障害でクラウドにつながらなくなった場合に、ローカルで認証を継続できるオフライン動作の可否も、可用性に直結する重要な要件です。止まったときに業務がどうなるかを想像し、その最悪ケースを防ぐ要件を盛り込むことが、安定運用の鍵になります。
認証応答速度と同時処理性能を定める
認証の応答速度も、利用者の体験を左右する重要な性能要件です。顔をかざしてから認証が完了するまでに数秒かかると、入口で行列ができ、ストレスの原因になります。RFPには、たとえば「1人あたりの認証完了まで1秒以内」といった応答速度の目標を、自社の利用シーンに合わせて記載します。ウォークスルー型を求めるなら、立ち止まらずに通過できることを条件として明示する必要があります。
応答速度と密接に関わるのが、同時処理性能です。始業時のように多数の人が一斉に通過する状況で、何人まで滞りなく処理できるかを要件化しておかないと、ピーク時に処理が追いつかず渋滞が発生します。登録人数が増えると照合に時間がかかる1対N認証では、想定する登録人数とピーク時の通過量を伝え、その条件下で目標速度を満たせるかを提案で確認することが大切です。性能要件は、平常時ではなく、最も負荷の高いピーク時を前提に定めるのが鉄則です。
外部システム連携の要件定義
顔認証システムの投資効果を左右するのが、勤怠管理・入退室管理・人事・CRMといった既存システムとの連携要件です。連携の定義が曖昧だと、後から追加開発が発生し、費用が想定外に膨らむ典型的な失敗パターンに陥ります。RFPの段階で、何と何を、どう連携するかを具体的に固めておくことが、見積りの精度と導入後の満足度を決めます。
連携対象・項目・方向を具体化する
連携要件を書くときは、「どのシステムと」「どの項目を」「どちらの方向に」「どのタイミングで」連携するかを、表形式で具体的に整理するのが効果的です。たとえば、顔認証の打刻時刻を勤怠システムへ毎回送信する、人事システムの入退社情報を受け取って顔データの登録・削除を自動化する、入退室イベントをセキュリティ監視システムへ通知する、といった具合に、一つずつ明文化します。
この具体化が甘いと、ベンダーは連携をスコープ外として見積もり、後から「その連携は別途開発が必要です」と追加費用を求められることになります。連携1件あたりで数十万円規模の費用が発生することもあるため、必要な連携を最初にすべて洗い出しておくことが、予算管理の観点で極めて重要です。riplaはフルスクラッチ受託と国内開発の立場から、既存システムの仕様を確認しながら連携要件を整理し、認証から業務処理までを一気通貫で自動化する設計を支援しています。
既存の電気錠・ゲート機器との接続を確認する
入退室管理で顔認証を使う場合、既存の電気錠やフラッパーゲート、自動ドアといった物理機器との接続要件も忘れてはいけません。新規にすべてを入れ替えるのか、既存の設備を活かして顔認証だけを追加するのかで、構成も費用も大きく変わります。RFPには、既設の機器の型番や制御方式を記載し、それらと接続できることを要件として明示します。
既存設備との接続は、現地調査をしてみないと可否が判断できないことが少なくありません。そのため、RFPの段階で現地調査を提案プロセスに含めるよう求めると、後の手戻りを防げます。古い機器は制御信号の規格が合わず、変換装置の追加や配線工事が必要になることもあります。こうした物理的な接続要件を見落とすと、ソフトウェアは完成しても扉が開かない、という事態になりかねません。建物の設備まで含めた要件定義が、入退室分野では欠かせません。
セキュリティ・個人情報保護とRFP記載項目
顔認証システムは、顔という最も機微な生体情報を扱うため、セキュリティと個人情報保護の要件はとりわけ厳格に定義する必要があります。あわせて、提案を正しく比較するためのRFPの全体構成も押さえておくと、ベンダー選定の精度が高まります。この最後のセクションで、これらを整理します。
生体情報の取り扱いと保護を要件化する
顔の特徴量は、個人情報保護法において慎重な取り扱いが求められる情報です。RFPには、顔データをどう保管し、暗号化するか、保管場所は自社内（オンプレミス）かクラウドか、保管期間と削除のルール、アクセス権限の管理方法といった要件を盛り込みます。とくに、画像そのものではなく不可逆な特徴量として保管できること、退会・退職時に確実に削除できることは、漏えいリスクを抑えるうえで重要な要件です。
また、利用者本人への説明と同意の取得も、運用面の要件として整理しておく必要があります。何のために顔データを取得し、どう使い、いつ削除するのかを利用者に明示し、同意を得るプロセスを設計に組み込むことが、信頼される運用の前提になります。RFPには、こうしたプライバシー対応をベンダーがどう支援できるかも提案項目として求めるとよいでしょう。技術だけでなく、運用ルールと説明責任までを含めて要件化することが、トラブルを未然に防ぎます。
提案を比較するためのRFP記載項目
RFP全体としては、プロジェクトの目的と背景、対象範囲、これまで述べた精度・性能・連携・セキュリティの各要件に加えて、予算感、希望スケジュール、保守・運用の体制、ベンダーの実績要件、提案書の様式と評価基準を盛り込みます。とくに評価基準を事前に示しておくと、各社が比較しやすい形式で提案してくれるため、選定がスムーズになります。価格だけでなく、PoCの実施有無や運用支援の手厚さも評価軸に含めることをおすすめします。
見積りを正しく比較するうえで重要なのが、費用の内訳を項目ごとに分けて提示するよう求めることです。初期構築費、端末費、ライセンス・月額費、連携開発費、保守費、PoC費用といった内訳が揃っていないと、総額だけでは各社の妥当性を判断できません。要件定義に不備があると、再開発で100万〜500万円規模の追加費用が発生することもあるため、RFPの段階で要件を可能な限り具体化し、各社に同じ前提で見積もらせることが、適正なベンダー選定の基礎になります。
責任範囲・保守・拡張性を要件に含める
RFPで見落とされがちなのが、ベンダーの責任範囲と運用フェーズの要件です。導入後に認証精度が想定を下回った場合、誰がどこまで責任を持って改善するのか、追加のチューニングは保守契約に含まれるのかを、契約前に明確にしておく必要があります。責任範囲が曖昧だと、稼働後のトラブルで「それは契約外です」と突き放され、自社で対応を抱え込むことになりかねません。
加えて、将来の拡張性も要件として考慮すべきです。拠点や利用者が増えたとき、登録できる人数の上限や端末の追加にどう対応するか、機能を後から追加できるかといった点を、初期のRFPで確認しておくと、数年後の作り直しを避けられます。顔認証は一度導入すると長く使うインフラになるため、初期費用だけでなく、運用・保守・拡張まで含めたライフサイクル全体の視点で要件を定義することが、結果的に総コストを抑える賢明な進め方です。
まとめ
顔認証システムのRFP・要件定義では、本人拒否率と他人受入率を実環境のPoCで実測する精度要件、稼働率99.9%や応答速度・同時処理を定める性能要件、勤怠・入退室・人事・既存機器との連携要件、そして生体情報の保護を含むセキュリティ要件を、数値と条件で具体的に書くことが成功の鍵になります。これらを曖昧にしたまま発注すると、現場で精度が出ない、連携の追加費用が膨らむ、といった失敗に直結します。
RFPで要件を具体化しておくほど、ベンダーからの提案は精度が上がり、見積りの比較も正確になります。とくに連携要件と費用内訳は、項目ごとに細かく定義・提示させることが、予算超過を防ぐ要になります。riplaはフルスクラッチ受託と国内開発を組み合わせ、自社の現場環境と業務に即した要件定義の整理から、PoCによる精度検証、連携設計までを一貫して支援します。要件定義の質が、顔認証導入の成否を分けます。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。