クラウドAPIが使えない現場で顔認証を動かす【オンプレ・閉域・組込】

顔認証の導入を検討すると、多くの解説がクラウドAPI前提で書かれています。画像をクラウドに送って結果を受け取る——手軽ですが、その前提が成り立たない現場が実は多いのです。本記事では「クラウドに送れない／送りたくない」現場で顔認証を成立させる設計を、OpenCV ベースの実装目線で整理します。

クラウド顔認証APIが「構造的に」使えない現場

これは「使いたくない」という好みの話ではなく、構造上どうしても送れないケースがあるという話です。

これらの現場では「精度が高いクラウドAPI」がどれだけ優秀でも、選択肢に入りません。要件は「精度」の前に「端末内・閉域内で完結すること」だからです。

オフライン顔認証を成立させる4つの条件

1. 推論がローカルで完結する（CPU で動く）

クラウドに送らない以上、推論は手元のマシンで走らせます。ここで GPU 必須のモデルは組込・エッジで詰みます。OpenCV 標準の YuNet（顔検出）+ SFace（顔照合）は ONNX の軽量モデルで、前回実装したとおり CPU 推論で実用速度が出ます。これはオフライン要件と非常に相性が良い。

2. モデルとライブラリを端末に同梱できる

閉域網では実行時にモデルを取りに行けません。ONNX ファイルと共有ライブラリ（.so / .dll / .dylib）を成果物に同梱し、初回起動時にネットワークを一切必要としない構成にします。OpenCV も静的リンク or 同梱で持ち込めます。

3. 顔特徴量の保存先もローカル

登録した顔の特徴量（128次元ベクトル等）を端末内 or 閉域内のストレージに置きます。クラウドDBに保存する設計にすると、結局そこが「外部送信」になってしまい要件を満たせません。特徴量は生画像ではありませんが、それでも生体由来データとして閉域内で扱うのが安全です。

4. ライブネス検知もオフラインで動く

顔認証を入れる現場は、たいていなりすまし対策も要ります。ところがライブネス検知をクラウドAPIに頼ると、オフライン要件が崩れます。ここが盲点で、「顔照合はオフラインで組んだのに、ライブネスだけクラウド」では意味がありません。ライブネス検知も単一フレーム・CPU・オフラインで完結する方式を選ぶ必要があります。

「クラウドの空白地帯」がなぜ生まれるか

大手のクラウド顔認証・ライブネスサービスは、ビジネスモデル上API課金・常時接続を前提に最適化されています。だからこそ、上記のようなオフライン要件の現場は構造的に手が届きにくい空白地帯になっています。

この空白は「技術的に難しい」のではなく「クラウド前提のプロダクト設計とかみ合わない」だけです。CPU 推論・モデル同梱・オフライン完結を最初から設計に織り込めば、埋められます。OpenCV エコシステムはまさにこの方向（軽量・組込志向）に強いのが利点です。

設計チェックリスト（オフライン顔認証）

• [ ] 推論は CPU で目標フレームレートを満たすか（GPU 前提になっていないか）
• [ ] モデル・ライブラリを端末に同梱し、初回起動でネット接続を要求しないか
• [ ] 顔特徴量の保存先が端末内 or 閉域内に閉じているか
• [ ] ライブネス検知もオフラインで動くか（ここだけクラウドになっていないか）
• [ ] ライセンス認証（アクティベーション）がオフラインでも通る方式か
• [ ] モデル更新の配布経路が閉域運用で回るか（USB・内部配布等）

まとめ

• 医療・工場・金融・組込・官公庁など、クラウド顔認証APIが構造的に使えない現場は多い。要件は「精度」の前に「端末内・閉域内で完結すること」
• オフライン成立の条件は ①CPU推論 ②モデル・ライブラリ同梱 ③特徴量のローカル保存 ④ライブネスもオフライン
• 盲点は④——顔照合はオフラインなのにライブネスだけクラウドでは要件が崩れる
• この「クラウドの空白地帯」は技術的困難ではなく設計思想のズレ。CPU・組込志向の OpenCV エコシステムと相性が良い