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