アマゾン ウェブ サービス ジャパン株式会社
アソシエイト ソリューション アーキテクト、博士（情報理工学） 針原佳貴氏
シアトルで視察したスマートシステムに触発されて
当該のプロジェクトに取り組んだチームのメンバーは、いずれも2018年4月にAWS Japanに入社したという新人ながらも全員が大学院卒で、5人中3人は博士号持ち。年齢差もあり、経歴も趣味も違いながら、ともにAWSのサービスを学ぶ教育プログラム「Tech-U」の研修を受けるうち、1カ月も過ぎる頃には「新しいことに取り組みたくなった」という。そんな折、針原氏は「Tech-U」のディスカッションを目的としたシアトル出張に出掛け、「Amazon Go」を始めとする最新の活用事例に触れる経験をすることになる。
「Amazon Go」はいわゆる「レジに人がいないコンビニ」だ。車の自動運転で活用されているコンピュータ・ビジョンやディープラーニング、センサー技術などが用いられており、アプリが入ったスマホを持っていれば、商品棚から商品を取るだけで、簡単かつスムーズに商品を購入することができる。「さまざまな技術が背景にあることは理解していたが、実際にユーザーとして店に入って買い物をしてみて、その便利さに驚いた」と針原氏は初めての「Amazon Go体験」の印象を語る。
また日本未発売の「AWS DeepLens」にも触れた。撮った動画を用いて、ローカルで深層学習モデルを実行するなどの分析や処理を行えることに興味を持ったという。そうした最新の事例に刺激を受け、研修のまとめとして「新しくて面白そうなことをしたい」といった気持ちが強まっていった。
針原氏はシアトルから戻り、改めてプロジェクトのヒントを探して周りを見渡すと、ちょうどオフィス移転の時期で、移転先では既に完全フリーアドレス制が導入されていた。自由で利点も多いながら、ちょっと相談したいと思っても、誰がどこにいるのかわからない。そんな不具合を改善するべく、新人チーム5人で開発したのが「Simple Location Finder」だった。社内に設置したカメラで画像を撮り、誰がどこにいるのかを自動認識して情報を共有することで、探している人がだいたいどのエリアにいるのか、”あたり”を付けられるようになるというアイデアだ。
システム構成としては「デバイス」「認識」「データ」「フロントエンド」の4つのマイクロサービスからなっている。
オフィスの複数のドア横に設置したRaspberry Piで、人が通ったら画像を撮影しAmazon S3上にアップ。それをトリガーとしてAWS Lambda関数が走り、画像分析APIサービスAmazon RekognitionとデータベースAmazon DynamoDBを呼び出して写真と対応する人の名前を取得し、Amazon API Gateway経由でAmazon DynamoDBにデータ保存、時間や場所を記録する。
検索する際のフロントエンドの動きとしては、S3の静的ホスティング機能でVue.jsで書かれたコードを置いておいて、検索画面に名前を入力すると、裏でAmazon Cognitoによる認証とAmazon API Gatewayが呼び出されて「いつどこにいたか」が表示されるという仕組みだ。
社内でテストユーザーを探しサービスを提供したところ、「気に入った」「（顔の写真を撮られることについて）抵抗感は問題ない」「人に勧めたい」のすべてで高評価を得ることができたというが、実運用には至らなかった。
イベント参加者に「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を使うと短時間で実現できる。さらに個人のスキルも大事ながら、何より仲間との協力関係が、新しい挑戦をする上で大切であることを強く感じた」と満足げに語り、セッションを終えた。
お問い合わせ
アマゾン ウェブ サービス ジャパン株式会社
