ジムの顔認証ゲートをイメージしたカバー画像
Natsuki Izumi

会員27万人ジムの顔認証が体感1秒な理由を設計から考えてみる

この記事のポイント

本文をもとにGemma 3が要約しています

  • 顔認証処理は、店舗端末内で完結するエッジ処理と、クラウドの利用を最小限にする設計が採用されている。
  • 生写真ではなく、AIによる特徴量(embedding)の利用により、データ量が大幅に削減され、高速な照合が可能になっている。
  • AIモデルの最適化と、顔認証処理専用のハードウェア(NPU)の活用により、計算コストが低減され、処理速度が向上している。

最近、FIT-EASY というジムに通い始めました。

24時間営業で、全国にチェーン展開しています。月会費で、全店舗を相互利用できます。驚いたのは、会員証もカードキーも要らず、顔認証で入れることです。手ぶらで通えるのは、思っていた以上に快適でした。

FIT-EASYは2026年5月末時点で280店舗以上あり、会員数は27万人を超えているみたいです。その規模でも、顔をかざしてからゲートが開くまで体感1秒もかかりません。率直に言うと、27万人の中から照合して体感1秒以内というのは、普通に考えてかなり速い部類に入りますよね。

調べてみたところ、FIT-EASYでは公式に「AI顔認証システム」を採用していると述べています。ただし、具体的な実装の詳細は公開されていません。ここでは、この種の高速顔認証システムが一般的にどう動くかを、調べた範囲で書きます。

なぜ1秒以内で認証できるのか

体感1秒以内の認証を支えている設計要素は、主に次の4点に整理できます。

  1. エッジ処理とクラウドのハイブリッド構成:照合処理が店舗の端末内で完結し、その瞬間はネットワーク往復が発生しない(一般的な高速顔認証の設計として)
  2. 生の写真ではなく「特徴量(embedding)」による軽量照合:生画像より大幅に小さいデータで照合計算が軽い(顔認証システム全般の特性として)
  3. AIモデルの最適化とNPUの活用:照合は件数が多くても計算コストが低く、さらに軽量モデル+NPUで高速化できる
  4. ローカルキャッシュによる高速化:端末に同期済みの特徴量データをローカルで保持しているため、認証時のデータアクセスが高速

1. エッジ処理とクラウドのハイブリッド構成

クラウドに送ると何が遅いのか

多くのサービスは、アプリが取ったデータをインターネット経由でサーバー(クラウド)に送ります。サーバー側で処理して、結果を返す形です。私も最初はこれだと思っていました。

この往復には時間がかかります。遅れる要因は、レイテンシ(通信の遅延)、サーバーの処理待ち、結果の返却です。これらが積み重なると、数百ミリ秒から数秒になります。混雑時はさらに遅くなります。

顔認証をクラウドに頼ると、「顔をかざす→送信→照合→受信→ゲート開く」というサイクルになります。どうしてもレスポンスが遅れやすくなります。

店舗端末で完結する意味

これを避けるのがエッジ処理(Edge Processing)です。クラウドに送らず、手元の端末で処理を完結させます。

身近な例でいうと、スマートフォンの Face ID も同じ原理で動いています。顔認証の処理をデバイス上で完結させているため、ネットワークの往復が発生しません。ジムの入館端末も、おそらく同じ考え方で作られています。照合が端末内で終わるなら、回線の品質に左右されず、速度が安定します。

ただし、「クラウドを使わない」のは認証(照合)の処理に限った話です。会員データの管理はクラウドが担い、認証だけ端末に任せる設計が一般的です。この点は、後の節で説明します。

2. 生の写真ではなく「特徴量(embedding)」による軽量照合

特徴量とは何か

よくある誤解として、顔認証は「写真同士を見た目で比べる処理」だと思われがちですよね。実際には、顔写真そのものを毎回見比べているわけではありません。

まず顔をAIで解析し、その人らしさを表す数値の並びに変換します。これを特徴量(embedding)と呼びます。AIモデルが顔全体のパターンを解析し、識別に使う情報を数百〜数千個の数値として圧縮したものです。

各次元が「目の間隔」や「鼻の位置」に1対1で対応しているわけではありません。同一人物の顔なら近い数値パターンになるよう、AIが自動的に最適化した表現です。

認証時は「今カメラで撮った顔」も同じように数値化し、登録済みの特徴量と比較します。生の顔画像は通常数百KB〜数MBあります。特徴量はその大きさに比べて小さく、通信と照合の両方で扱いやすくなります。

比較そのものは、2つの数値の並び(ベクトル)がどれだけ似ているかの計算です。向きの近さ(コサイン類似度)や、数値の差の大きさ(ユークリッド距離)が使われます。生の画像を見比べるより計算コストが低く、短時間で終わります。

3. AIモデルの最適化とNPUの活用

モデルの軽量化と量子化

顔認証専用の用途では、汎用の大型モデルより、精度を維持しながら計算コストを抑えた「軽量モデル」を使います。

量子化(Quantization)を使うと、AIモデルを圧縮でき、推論(AIモデルの実行処理)が速くなります。スマホのAI機能でも、よく使われています。

専用ハードウェア(NPU)の役割

もう一つの要素が、NPU(Neural Processing Unit / ニューラル処理ユニット)です。

NPUは、AI処理専用の計算回路です。CPUが何でもこなす汎用の係だとすると、NPUは顔認証のようなAI処理を短時間でこなす専門係です。最近のスマートフォンにも搭載されています。

入館管理端末向けの組み込みAIチップにも、NPUが載っているものが増えています。顔認証の計算をその専用回路に任せるので、照合が短く済みます。スマホの顔認証や音声アシスタントが速い裏側にも、NPUが使われていることがよくあります。聞き慣れない名前ですが、実は身近な部品なんですよね。

4. ローカルキャッシュによる高速化

キャッシュとは何か

ローカルキャッシュとは、よく使うデータをあらかじめ端末内に保持しておく仕組みです。認証のたびにクラウドへデータを取りに行かなくて済むので、参照が短時間で終わります。

顔認証では、その店舗でよく来る会員や、最近登録した会員の特徴量をローカルに置きます。認証時の参照は、端末内で終わります。全会員データの完全コピーではありません。頻度や直近の利用に応じた、部分的な保持です。

クラウドからは差分同期(更新があった分だけを送る同期方式)で、手元のデータを新しい状態に保ちます。認証処理そのものは、端末内のデータで動かします。この設計が、速度の下支えになっています。

27万人規模でも速く動く仕組み

ここからは、FIT-EASYそのものの実装ではなく、この種の全国展開サービスで一般的に採られる設計の話です。公開情報を調べたうえで立てた推測なので、店舗側の確定事実ではありません。間違ってたらごめんなさい🙏

全会員データを各端末に配るのは現実的でない

27万人分の特徴量を280店舗すべての端末に完全コピーするのは、データ量やメンテナンスの観点から非現実的です。退会や権限変更のたびに全端末へ配信する運用コストも、規模が大きくなるほど重くなります。

ローカルキャッシュ+クラウドフォールバックが一般的

つまり、よく採られるのは「ローカルキャッシュ+クラウド同期/フォールバック」です。フォールバックは、キャッシュにないときの代替照会です。

  • キャッシュヒット(端末内にデータがある)のとき、ローカルデータで照合が終わります。ネットワーク遅延は入りません
  • キャッシュミス(初来店など、まだ端末にない)のとき、クラウドへ照会して特徴量を取得し、照合します

キャッシュに当たれば速く、当たらない分はクラウドで補えます。件数を増やしても、当たる分は端末、当たらない分はクラウド、と場所が分かれます。

embedding照合は、件数が多くても1件あたりの計算コストが低い、という特性もあります。仮にキャッシュ内に数万件あっても、最適化されたシステムなら照合は数十〜数百ミリ秒で済みます。「27万人の中から探す」と聞くと、重そうに見えますよね。写真を見比べているわけではありません。軽量な数値データを比較する設計なので、件数の印象ほど計算量は増えません。

なぜ他の店舗でも使えるのか

FIT-EASYは入会31日後から全国の店舗を利用できます(公式情報)。登録した顔データが「入会した店舗だけ」に閉じていないということです。

中央クラウドで特徴量を一元管理

よくあるアプローチでは、入会時に登録した顔の特徴量を、会員アカウントと紐づけてクラウドで管理します。顔データのsource of truth(正の状態管理)をクラウドに置くと、全国の店舗で同じデータを共有できます。

退会、プラン変更、利用停止といった権限変更はクラウド側で即時反映される必要があります。端末側にはその更新が差分同期で届く設計にすることで、最新状態との乖離を最小限に抑えられます。

各店舗への差分同期とローカルキャッシュ

各店舗の端末は、クラウドから特徴量データを差分同期して、ローカルにキャッシュします。認証はそのデータを使って端末上で行うので、認証のたびにクラウドへアクセスする必要はありません。

新規入会、退会、データ更新があった会員の情報だけを各端末へ配信します。通信量(帯域)とストレージの無駄を抑えながら、端末のキャッシュを新しい状態に保てます。

通信が切れても、キャッシュ内の照合はできます。これをオフライン耐性(回線が切れても認証を続けられる性質)と呼びます。ただし、直近の退会や権限変更が、まだ届いていない可能性はあります。ここは設計上のトレードオフです。

入会31日後という条件は、公式には利用制限として書かれています。技術的になぜ31日なのかは、明記されていません。推測ですが、全店舗へデータを行き渡らせる猶予として置いている、とみるのが近いと思っています。

役割処理場所(想定)特徴
認証処理(照合)店舗端末(エッジ)リアルタイム。ネットワーク遅延なし
会員データ管理(source of truth)クラウド全国一元管理。退会や権限変更を即時反映
特徴量の保持端末ローカル(キャッシュ)クラウドから差分同期
キャッシュミス時の照合クラウド(フォールバック)初来店会員など未キャッシュ分をリアルタイム取得

認証はエッジで速く済ませ、データ管理はクラウドで一元管理します。この役割分担で、速さと全国利用を両立できます。

もっと技術的に知りたい人へ

ここからはやや実装寄りの話です。

顔認証の基本パイプライン

顔認証の処理は、パイプライン(処理の流れ)として3ステップで構成されています。

  1. 顔検出(Face Detection):カメラ映像から「どこに顔があるか」を特定する
  2. 特徴抽出(Feature Extraction):検出した顔をAIモデルに通し、embedding(特徴量ベクトル)を生成する
  3. 照合(Matching):生成した特徴量を、DBに保存された登録済み特徴量と比較し、一致する会員を特定する

このパイプライン全体が端末上で動くのが、エッジ処理の要点です。キャッシュヒット時は、認証の実行時にクラウドへのリアルタイム通信が不要です(データ同期は別タイミングで行われます)。

生体検知(liveness detection)とは

生体検知(liveness detection)は、写真や画面に映した顔での不正入館を防ぐ処理です。「本物の生きた顔かどうか」を判定します。

具体的には、まばたきの検出、深度センサーによる立体構造の確認、赤外線センサーの活用などが組み合わされます。入館端末にはこれらのセンサーが内蔵されていることが多く、静止画や動画によるなりすましを防ぐ設計になっています。

この検知処理も端末内で実行します。NPUや軽量モデルと組み合わせれば、全体を1秒以内に収める設計にできます。

プライバシーの設計上のリスク

顔認証で大きなリスクになるのは「生体データが漏れたとき、変更できない」という点です。パスワードなら変更できますが、顔は変えられません。

だから多くのシステムは、「顔の生画像を持たない」設計にします。登録時に特徴量へ変換したあと、元の顔画像は消すか、持ちません。漏洩しても、生の顔画像を復元しにくくする意図です。

ただし特徴量自体も、個人を識別できるバイオメトリクスデータ(生体情報)です。次の点は、各サービスのプライバシーポリシーで確認する対象です。

  • 入会時の顔写真は保存されるか
  • 特徴量の保存場所(端末 / クラウド)と暗号化の有無
  • 退会時の削除方針

ハイブリッド構成の運用イメージ

エッジ(端末)とクラウドが協調して動くシステムでは、キャッシュの更新タイミングが運用の中心になります。

更新は、大きく2パターンあります。一つは定期的なバックグラウンド同期です。深夜帯に差分をまとめて配信する、といったやり方です。もう一つは新規入会時のプッシュ配信(入会直後に近隣店舗へ即時配信)です。

退会や権限変更が起きた場合は、クラウド側でフラグをすぐ更新し、端末側のキャッシュを無効化する信号を送ります。端末がオフラインで同期できていない間は、退会済みの会員がまだゲートを通れる時間が残ります。その時間を短くする差分同期の頻度が、システムの信頼性に直結します。

これは「エッジとクラウドの協調」の典型例です。「何でもクラウドに集める」でも「すべてエッジで完結させる」でもありません。揃えるべきデータはクラウド、その場の照合は端末、と役割を置きます。その置き方で、短い応答と全国規模の両方を成立させます。

まとめ

体感1秒以内の認証は、エッジ処理とクラウドの役割分担で成立しています。照合はその場の端末で終わらせ、会員データの正(source of truth)はクラウドに置きます。特徴量で照合するので、件数が増えても1件あたりの計算は軽いままです。認証のたびにネットワーク往復を挟まないので、遅延を小さく抑えられます。

速度の条件は、計算側とデータ側の両方にあります。AIモデルを軽くし、NPUのような専用チップに推論を任せると、照合の計算時間が短くなります。よく使う会員の特徴量をローカルキャッシュに置けば、認証のたびにクラウドへデータを取りに行きません。

判断の軸は、「どこまでを端末で処理し、どこからをクラウドに任せるか」です。クラウドを捨てる話ではありません。一元管理と即時反映はクラウドが向き、低遅延とオフライン時の照合は端末が向きます。照合まで毎回クラウドに集めると、入館ゲートのように短い応答を求める場面では、往復の遅延が積み上がります。

この役割の置き方は、IoTデバイス(スマート家電などのネット接続機器)やスマートフォンでも同じです。速い処理は端末に残し、全体で揃えるデータはクラウドに残します。設計は、その境界で見ます。

関連:AIが現場の業務や体験にどう入り始めているかのトレンドの雰囲気はAI博覧会2026の現地レポートで触れています。