顔認証システムのなりすまし対策 設計チェックリスト12項目

顔認証を業務システムに組み込むとき、「顔が一致するか」だけを見ていると印刷写真であっさり突破されます。本記事は、顔認証システムを本番運用する前に確認すべきなりすまし対策を、設計・調達の抜け漏れを防ぐチェックリストにまとめたものです。当ブログのこれまでの記事への索引も兼ねています。

各項目にチェックが付かない場合、その先の記事で背景を確認してください。

---

顔認証のなりすましとは — 何を検知すれば防げるのか

顔認証のなりすましとは、本人ではない人が、本人の顔を写した写真・画面・動画などをカメラに見せて認証を通そうとする行為です。専門的にはプレゼンテーション攻撃と呼ばれます（類型は なりすまし攻撃の種類と、どこまでが現実的な脅威か）。

顔照合は「登録された顔と同じ人物か」を判定する技術なので、本人の顔が写っていれば写真でも一致します（実験）。そのため、なりすましを防ぐには顔照合とは別に、カメラの前にいるのが生体か偽物かを判定する「なりすまし検知（ライブネス検知・PAD）」を組み込みます。

なりすまし検知の3つの方式

方式	やり方	ユーザーの負担	注意点
動作要求型（アクティブ）	まばたき・首振り・発話などを指示し、応じたかを見る	大きい（指示に従う必要）	動きの有無だけに頼ると動画で再現されうる（簡易ライブネス3方式の限界）
専用センサー型	深度カメラ・赤外線カメラで立体や素材を見る	小さい	専用ハードが必要。既存の汎用カメラには後付けできない
単一フレームのパッシブ型	通常のカメラ画像1枚から、生体か偽物かを学習モデルで判定する	なし（撮影するだけ）	精度はモデル次第。APCER / BPCER を測定条件つきで確認する

どの方式でも「防げます」という言葉ではなく、自分の用途で想定する攻撃と、数字（APCER / BPCER）で選ぶのが原則です。以下の12項目は、その判断を設計・調達の段階で漏れなく行うためのチェックリストです。

---

A. 脅威モデルを決める

□ 1. なりすまし成功時に「誰が・どれだけ得をするか」を言語化したか
対策レベルは用途で決まります。勤怠打刻と口座開設では守るべきラインが違います。まず自分のシステムの動機を言語化します。 → なりすまし攻撃の種類と、どこまでが現実的な脅威か

□ 2. どの攻撃類型まで守るかを決めたか
印刷写真・画面表示・動画再生・3Dマスク・ディープフェイク——全部に対策すると過剰投資になります。最低でも印刷写真と画面表示（誰でも今日実行できる）は必須と考えます。 → 攻撃コスト×遭遇しやすさのマトリクス

□ 3. カメラ提示攻撃だけでなく、注入攻撃（インジェクション）の想定をしたか
高価値システム（金融等）では、カメラを迂回して映像を注入する攻撃も想定します。これはライブネス検知だけでなく、通信・デバイスの保護が守備範囲です。

---

B. 顔認証と別に「ライブネス検知」を入れる

□ 4. 顔照合とライブネス検知を別の機能として設計したか
顔照合は「誰の顔か」、ライブネス検知は「生体か偽物か」を判定する別の技術です。顔が一致しても生体とは限りません。 → なぜ顔認証は写真で突破されるのか

□ 5. 選んだライブネス方式の「破られ方」を把握しているか
まばたき要求・動作要求・深度カメラには、それぞれ動画再生・注入攻撃・3Dマスクという弱点があります。採用方式の限界を理解した上で選びます。 → 簡易ライブネス3方式の限界

□ 6. ユーザーに動作要求をするか、パッシブ（無動作）にするか決めたか
動作要求は UX を損ない、高齢者・障害のある利用者に負担をかけます。単一フレームのパッシブ判定なら動作要求なしで成立します。 → 単一フレームのパッシブ判定

---

C. 精度を「数字」で評価する

□ 7. APCER と BPCER を「ペアで」「測定条件つきで」確認したか
片方だけの数字、条件のない数字は評価できません。攻撃種別（PAI）と件数を必ず添えて読みます。 → FAR/FRR と APCER/BPCER の違い

□ 8. 「ISO準拠の社内評価」と「第三者認定」を区別したか
「ISO/IEC 30107-3 の指標体系を参考にした社内評価」と、認証機関による認定は意味が違います。製品ページの表現を確認します。 → 指標の読み方

□ 9. 自社の運用環境（カメラ・照明・距離）で実測したか
公称値はベンダーの測定条件での数字です。実際のカメラ・照明・撮影距離では変わります。導入前に自環境で検証します。

---

D. 運用環境の制約を満たす

□ 10. クラウド送信が許される環境か確認したか
医療・工場・金融・組込・官公庁では、顔画像の外部送信が構造的に不可なことがあります。その場合はオンプレ・オフライン方式が必須です。 → クラウドAPIが使えない現場で顔認証を動かす

□ 11. 端末スペック（CPU・メモリ）で目標フレームレートが出るか
GPU 前提のモデルは組込・エッジで動きません。CPU 推論で実用速度が出るかを、実機（想定する最低スペック）で確認します。 → Cortex-A76（Raspberry Pi 5）での実測

□ 12. モデル・ライブラリの同梱、ライセンス認証、更新配布がオフラインで回るか
閉域網では実行時にモデルを取りに行けません。同梱・オフラインアクティベーション・内部配布の経路を設計に織り込みます。 → オフライン顔認証の設計チェックリスト

---

索引: このチェックリストの背景記事

観点	記事
顔認証は写真で突破される（実証）	印刷した写真であっさり突破された
そもそも顔認証をどう実装するか	OpenCVだけで顔認証を実装する（YuNet + SFace）
攻撃の類型と脅威度	なりすまし攻撃の種類と現実的な脅威
簡易ライブネスの限界	まばたき検知で防げるのか
精度指標の読み方	FAR/FRR と APCER/BPCER の違い
オフライン・組込での実装	クラウドが使えない現場で顔認証を動かす
低スペックCPUでの実測	Cortex-A76（Raspberry Pi 5）でOpenCVの顔検出はどこまで動くか
SDK組み込みの実測	なりすまし判定SDKの組み込みに何行必要か
既存システムへの後付け実装	既存の顔認証システムに、なりすまし対策を後付けする

---

まとめ

• なりすまし対策は「顔が一致するか」の先にある。脅威モデル → ライブネス方式 → 精度評価 → 運用環境の4段で漏れなく設計する
• 最低ラインは「印刷写真・画面表示を弾けること」。ここは用途を問わず必須
• 精度は APCER/BPCER をペア・測定条件つきで読む。運用環境での実測を怠らない
• クラウド送信の可否・端末スペック・オフライン運用は、精度と同じくらい導入可否を左右する