イベント参加者に「Wow！」と思わせる顔認識システム
新入社員5人のユニットによる初プロジェクトに一定の満足を覚えていた9月のある日、マネージャーから10月下旬のAmazon/AWS 合同イベントに向けて「参加者に『Wow！』と思わせるシステム」を作ってほしいと依頼を受けた。針原氏は即答で受け、ほかのメンバーも快諾し、1カ月の制約がありながらも、イベントの受付を顔で認証できる「Face Recognition Gate」の開発に乗り出すことになる。
とはいえ、社員証や顔というパーソナルな情報を取得することもあり、AWSの厳しいセキュリティ基準をクリアしなければならない。時間がない中で、一定ノウハウはあるといってもゼロから作り直しになる、5人で本当に作れるか、ちゃんとした運用をやったことがない、などさまざまな不安を抱えながらも、ともかく針原氏は「PR／FAQ」を書くことから始めたという。
なお「PR／FAQ」とは、プレスリリースと質問集の意味で、AWSでサービスを作る際にはまず必ず作成されるものだ。今回の「Face Recognition Gate」については10月の社内イベント向けの認証システムであること。そして最初に登録された顔と属性情報と、会場に入る際に撮影した顔データまたは社員証の写真のいずれかが一致することで入場できることなどが記載された。それを社内のWikiに上げ、さまざまな質問に対する回答を足していくことで全体像が把握できる。
開発にあたっては、前回の「Simple Location Finder」と同様にAmazon Rekognitionを活用している。ただし、そのまま画像を送るだけでは応答に1秒ほどかかり体感としてやや遅いため、先にエッジ側での顔検出により顔の周りを切り取って、SearchFacesByImage APIに画像を送るようにして、応答時間を半分の0.5秒にまで短縮した。機材としてはラップトップパソコンにユーザー確認用のディスプレイ、USBカメラと顔を照らすデスクライトを2つのレーンに配置し、実際に歩いて反応時間などを検証してみたという。
そして、使用する画像は止まる直前と止まってからの2枚とし、この2枚を使って99%の確率でOKが出るようにシミラリティ（類似度）の閾値を設定した。「この閾値の設定が大切ながら難しく、高すぎれば誰も通過できず、低ければ顔認識の意味がない。AWSのドキュメントやディスカッションを参考にしつつも、要件に合わせて適切な閾値を決定するのが大切」と針原氏は語る。そうした「人間が判断する部分」については、UI/UXの重要性も実感したという。例えば判定が出るまでに何も反応がないと、ユーザーは顔の認識ができたかどうかがわからず、戸惑ってしまう。「認識中」などの表示を出すだけでも印象が大きく変わるというわけだ。
そうして完成したシステムはシンプルな仕組みだ。まず事前に顔写真と名前を登録しておく必要がある。データをAmazon S3 Bucketに格納すると、AWS Lambdaによって画像はAmazon Rekognition、FaceIDはAmazon DynamoDBにひも付けられた状態で格納される。USBカメラでユーザーの写真を撮ると、そのデータがAmazon RekognitionとAmazon DynamoDBに行き、あらかじめ格納された写真と照合される。その際に類似度の数字が出るため、それを閾値に照らし合わせOKかNGが出るといったイメージだ。
また、ログとメトリクスはAmazon CloudWatchに送られ、写真などのデータは廃棄されるようになっている。
事前テストでの利用者の反応もおおむね好評であり、「すごい」「はやい」といった反応が多かった。そして、認証失敗の一番の原因は「事前の登録漏れ」だった。システムの精度が上がっても、その前の運用に問題があればトラブルや漏れが生じることを実感したという。
画像認識はセキュリティとコンプライアンスに配慮が必須
なお、今回開発した「Face Recognition Gate」では、センシティブな顔データなどの個人情報を取り扱うことからさまざまな気配りがなされている。
まず、システムのAWSのアカウントを、Develop用、Staging用、そして当日使用するProduction用の3つ用意した。開発は基本的にはDevelopアカウントで行う。プライベートなレポジトリを作成し、そこにコードをプッシュする権限を持ったDev power userを用意。クライアント側で動くPythonのコードとAWSの環境をすべて書いたクラウドフォーメーションのテンプレートを置いた。これらをStaging、Productionにデプロイすれば全く同一の環境が立ち上がる。またIAMロールとして、それぞれのアカウントにClient role （デバイス用）、Admin role（環境構築用）を付けた。
DevelopアカウントとStagingアカウントのAmazon Rekognitionには顔認識用の公開データセットと開発チームの5人のデータ、そしてProductionの方に実データ（社員のデータ）が入る。イベントが終わったらProductionアカウントを丸ごと消すというわけだ。
その他セキュリティ上の考慮として、針原氏は「正解があるわけではなくケース・バイ・ケース」と前置きしながら、「“原理原則にのっとって”一時的な認証情報を利用してオフィスネットワークからのIP制限をかけ、VPN接続経由のみにした。またAPIエンドポイントを自前で作らず密結合のままとした。Amazon API Gatewayなどを入れてもよいが、そうするとテストをする必要がある。時間がない中、余計な心配を生まないためあえての選択だった」と多方面に配慮して対策を打ったことを説明。
さらに、Amazon S3やAmazon DynamoDBはサーバーサイド暗号化を行い、TTLを指定して、一定時間がたつと自動で削除されるように設定した。また、登録用の写真・認証用の画像は保存せず、それらが破棄されていることをサービスチーム (Amazon Rekognition開発チーム) にも確認した。また東京外にデータが出たときの法律的な問題やAmazon Rekognition APIのレスポンス時間などを鑑み、東京リージョンのみの使用に限定。そして、写真の登録は任意であり、登録しても削除可能、当日その場でも社員証での入場を選択できるようにするなどの配慮も行った。
パフォーマンスの反省点としては、まずAmazon Rekognitionのレスポンス時間はオフィスなら0.5秒ながら、ポケットWi-Fiだと0.7秒とネットワーク環境に大きく依存することがわかった。なお、前述のような画像のリサイズも行い、速度の最適化を図っている。結果、目標2秒/人のところ、実測では3.38秒/人だった。設計値に満たなかった要因にはさまざまあり、ネットワーク環境や照明環境がよくなかったことなどが挙げられた。
とはいえ当日のコストは20ドル以下、社員からの評価は5つ星のうち4.53と上々で、「はやい」「すごい」と声が上がり、実感として楽しんでもらえた印象があったという。
針原氏は取り組みを振り返り、「今回一番意識していたのが、お客さまの体験から逆算してものを作ろうという『Working Backwards』の考え方だ」と語る。そして、「例えば『PR／FAQ』で顧客価値を明確化してから実作業に入るように、これはAmazonの基本的な考え方。そこをつかんでいればどんどんアイデアが湧き、さらにAWSを使うと短時間で実現できる。さらに個人のスキルも大事ながら、何より仲間との協力関係が、新しい挑戦をする上で大切であることを強く感じた」と満足げに語り、セッションを終えた。
お問い合わせ
アマゾン ウェブ サービス ジャパン株式会社
