アーカイブ動画
登壇者プロフィール
セーフィー株式会社
ソフトウェアエンジニア 鈴木 敦志氏
2009年株式会社デジタルセンセーションに入社。2019年セーフィー株式会社に入社し、顔識別来店分析サービス「Safie Visitors」や画像解析サービス「Safie AI People Count」の開発などに従事。
LINE株式会社
AI開発室 サーバサイドエンジニア 四倉 晋平氏
スマートスピーカーの音声対話システム構築など、自然言語処理や全文検索を用いたWebサービスの開発に従事。より多くのユーザーにAIプロダクトを提供するため、機械学習の推論を分散処理させるアーキテクチャの開発に取り組む。
株式会社LayerX
SaaS事業部 AI-OCRチームLead 高際 隼氏
サイバーエージェントに新卒入社後、テックリードとして複数のスマートフォンゲームの新規開発および運用を担当。その傍ら組織運営や新卒採用にも携わる。2018年8月LayerX設立とともに参画。PMやテックリードとしてブロックチェーン事業に携わる。SaaS事業部立ち上げ後は、AI-OCRやバクラク請求書/申請の開発に注力。
【セーフィー】クラウド録画サービスをハード・ソフトなど包括的に開発
セッションのトップバッターは、セーフィーの鈴木敦志氏。2014年に設立したセーフィーは、クラウド録画サービスを提供している。特徴的なのは、映像を撮影するカメラなどのハードウェア、ハードを制御するソフトウェア、より付加価値の高いサービスを提供するために、映像プラットフォームも含め、サービスに関するプロダクトやシステムを包括的に開発している点だ。
メーカー、小売、飲食、建設・不動産など、様々な業界における大企業からスタートアップまで、セーフィーのサービスは広く使われている。
「カメラで撮影したリアルもしくは録画映像を、利用者はクラウドを通して遠方にいながら、パソコンやスマホを通して見ることができます。見るだけでなく遠隔操作することもでき、同時に複数のカメラ映像を視聴することも可能です」（鈴木氏）
さらにセーフィーは、開発した映像プラットフォームを通じ、自社サービスだけでなく、社会の誰もが映像を活用できる未来の実現を掲げている。そのためより多くのプレイヤーが参加できるよう、各種センサー・アプリ・API連携・SDK（Software Development Kit）の公開などにも積極的だ。
ちなみにプラットフォームに収集されるデータ量は、1日あたり数百テラバイト。録画データは約14PB（ペタバイト／1000テラバイト）にもおよび、同データを活用すべく自社独自のAIプロダクトの開発も行っている。本セッションではその中から2つのプロダクト開発の舞台裏が紹介された。
高画質な映像取得のために、カメラの機種や設置場所を規定
1つ目のプロダクトは、カメラが撮影した画像をAIが解析し、顧客分析や接客支援サービスにつなぐ「Safie Visitors」だ。例えば、店舗にカメラを設置すると、入店した客の画像を取得してデータをクラウドに送り、1日の客数をカウントする。さらにAIを活用し、具体的に誰が来訪したのかを分析する。新規顧客の場合は登録するといったシステムである。
「ヘビーユーザーを優良顧客としてラベル付けすることもできますから、該当者が来店したら、店員のスマホなどにアラート通知すれば、そのユーザーに素早く手厚い接客をすることで、接客サービスの向上はもちろん、売上アップにも寄与します」（鈴木氏）
システム構成は以下のスライドのように、カメラサーバー・ライブ配信サーバーを経由し、動画処理サーバーで顔検出処理を行う。同時に、店内をどのように移動したのかなどをデータ化し、来訪者記録としてS3に保存する。さらに、顔認識API・サーバーを経由して処理された画像から、顔の識別処理を行う。API、コンポーネントの処理は外部サービスを採用している。
また、顔認識のメリット・デメリットについても言及した。
「スタッフも含め、同一人物や特定人物を重複カウントしない、性別や年代といった詳細の属性が分かる一方で、高画質なデータが必要とするなどの欠点もあります」（鈴木氏）
ビルやオフィスの入門ゲートと異なり、来店者はカメラに顔を映そうという意識がない。そのため下や横を向いているなど、カメラに対して正面の画像データを得ることが難しいという課題もある。
加えて、カメラに逆光が入り込み、天井が高い場合は撮影角度がキツいといった問題もある。つまり、顔認識においてはカメラの設置条件が重要なのだ。そこで、セーフィーでは「顔正面から±15度」「サイズは75×75px以上」「顔パーツの階調差40％」と、カメラの機種も含めたレギュレーションを明確に設定することで、サービスの品質を担保している。
画像の圧縮・転送においても課題があった。リアルタイムで画像分析する必要があるため、動画データ転送プロトコル「RTP（Real-time Transport Protocol）」に準じたタイムスタンプ機能から時刻を計算しているが、この計算が大変だというのだ。
また、通信プロトコル「UDP（User Datagram Protocol）」も、受信バッファサイズ超過によって映像の乱れが発生する。そのため現在は、Googleが開発した通信プロトコル技術「gRPC」をベースとした伝送手法に切り替えを検討中だという。
個人情報やプライバシー保護の影響については、経産省の「カメラ画像利活用ガイドブックver2.0」の「リピート分析」の内容に準じた対応をとっている。例えば、ホームページや店舗の入り口などに画像を利用する目的を公表し、データの開示や削除要求に対応する。マンションや公園・駅構内といった公共空間では、サービス提供は行わない。
ジョブを待機・実行するタスクキューでサーバー処理負荷を分散
2つ目は、「物体（人影）検出」を用いたプロダクトである。カメラが物体を撮影してAIに認識させるといったフローは同じだが、顔認識はせずリアルタイムでもないため、画像はJPG圧縮すれば、動画よりも高画質で取得できる。
AIは物体検出機械学習モデルのひとつである「CenterNet（センターネット）」を採用。タスクサーバーでの処理を負荷分散するために、バックグラウンドでジョブを待機・実行させるためのタスクキューを設けている。
「Safie Visitorsとは異なり、カメラを天井に設置し、真上から撮影してもデータを取得できるなどの利点があります。CenterNetAIが物体（人影）を検出し、CPUが推論処理を行い、カメラの画角内にいる人数を集計する。メールやSlackで通知することができます」（鈴木氏）
鈴木氏は最後に今後の展望を述べ、セッションを締めた。
「単に映像・AIのプロダクト開発企業としてではなく、他のAIベンダーや新たなサービスやソリューションを開発する外部企業との協力を強化する。つまり、膨大な映像データを扱うクラウドプラットフォーマーとして、さらに進化していきたいと考えています」（鈴木氏）
【LINE】2.2億枚の画像をOCR処理する分散処理アーキテクチャ
続いて登壇したのは、もともとは自然言語処理エンジニアであったというLINEの四倉晋平氏。LINEのスマートスピーカー「LINE CLOVA」の開発メンバーでもあったが、2021年にジョブチェンジ。「機械学習の推論を分散処理することで、多くの人にAIを活用してもらいたい」という想いで、現在取り組んでいるプロジェクトを紹介した。
「LINEはトークやマンガなど、BtoCサービスのイメージが強いのですが、実はBtoB事業も手がけています。私は現在、自社開発したAIエンジンを他社に提供するビジネスに携わっています」（四倉氏）
そのプロジェクトのクライアントは、国内唯一の国立図書館であり、国内最大級約4500万点の蔵書を誇る国立国会図書館。同図書館が保有する1860年代（江戸時代）から1960年代の図書ならびに、明治期以降2010年代までの雑誌など、247万件の書籍、2.2億枚にもおよぶデジタル化資料（画像）を、LINEのOCR技術でテキスト化するというものだ。
データを正確に読み取ることが最優先であるが、与えられた期間は90日。OCRを分散処理することが必要不可欠であり、プロジェクト最大のポイント。かなりチャレンジングだったと、四倉氏は振り返る。
1枚の画像をOCR処理するのに必要な時間が、前処理・OCR・後処理と3つの工程合計で約12秒と仮定すると、分散処理を行わない場合には84年もの時間がかかることが分かったからだ。
そこで四倉氏は、予算も加味しながらGPUサーバーを60台、GPUを120枚用意することでまずは対応した。GPU1枚に付き、2プロセス動かせるので、一度に240ジョブを並行して実行できるようになり、84年（30660日）の1/240、128日にまで処理日数を短縮することができた。
分散処理の実装には、キューを利用
分散処理の実装においては、キューを利用した。Pythonのキュー処理のフレームワークCelery（セロリ）を使い、ジョブ投入サーバーから前処理・OCR・後処理と3つの処理を実行するように記述。それぞれの処理サーバーはジョブが終わったら、自らキューをチェックし処理していくので、非常に簡単に分散処理が実行できる。サーバーの追加も容易となる。
ただ、目標値は90日であるため、あと40日ほど処理に要する日数を短縮する必要がある。そこで改めてアイデアを練り直した。その結果、前処理・後処理は、GPUに比べ低コストなCPUでも処理ができることが分かった。GPUの240処理と並列して実行することで、240×3で720並列での分散処理が可能となり、処理に要する日数も43日まで短縮することができる。
新しいアイデアの実装においても、キューを利用した。前処理・OCR・後処理それぞれにキューを設けることで、CPUサーバとGPUサーバに処理を分散する実装を実現した。
「OCR処理にどうしても時間がかかるため、OCR前のキューにジョブが溜まりやすいというボトルネックがありました。そこでキューの長さをチェックし、一定量を超えた場合は投入を止める制限を設けました」（四倉氏）
四倉氏は実際に、投入量が制限される様子を視覚化したスライドも紹介した。キューの長さ制限を2000に設定（中央の横線）。2000を超えてからしばらくすると制限がかかり、2000の長さで維持されていることが分かる。
なお今回はバッチ処理だったのでこのような対応ができたが、Webアプリの場合は適用できない可能性があると補足した。ユーザーのリクエスト数に制限がかかるためだ。
最後に四倉氏は改めて現在の業務の取り組み意義を語り、セッションを締めた。「今回の事例のように、機械学習の推論処理を負荷分散する技術を使うことで、機械学習を適用できる対象や頻度が増えることを望んでいます。機械学習を支えるバックエンドエンジニアがさらに増えることで、より多くのお客様にLINEのAI活用を広めていけると考えています」（四倉氏）
【LayerX】バクラク請求書のAI-OCRを支える非同期処理アーキテクチャ
続いては、請求書に特化したAI-OCRプロダクトを開発しているLayerXの高際隼氏が登壇した。LayerXが提供する「バクラク請求書（旧LayerX インボイス）」は、多様なフォーマットの請求書をOCRで読み取ると同時に、AIが内容を推論する。自動で仕訳を行い、社内の帳簿や決算書、オンラインバンキングにも同じく自動、かつシームレスにデータ連携するシステムだ。
請求書受取業務は経理だけでなく、現場からの申請業務が必要など、経理だけで完結しない。このような観点から、申請業務を効率化する「バクラク申請」なるプロダクトも開発している。また、請求書申請業務に限らず、上長の承認や稟議をする際にも利用できる。
「バクラク請求書は請求書に特化したOCRのため、振込先の企業名、金額、期日といった箇所を重点的に読み込む仕様となっています。実際の利用画面を見ていただくと分かりますが、それらの項目がハイライトで強調されています」（高際氏）
処理のフローとしては、まずファイルの前処理を行い、続いて入力画像の「文字」と「位置情報」を読み取る。その後、読み取った結果を元に「支払金額50000円、支払期日2021/12/24」といった意味付けの処理を行う。最後にファイル内の読み取り箇所をハイライトする等の後処理を行い、紙からデジタルへの読み取り（変換）成功となる。
それぞれ処理が重く、一連のフローが完了するのに5秒ほどかかる。重たい処理同士が影響しあって更に負荷が上がるという状況は避けたかった。また、月末や月初には大量の請求書がアップロードされるが、アップロード数が急増しても問題なく動作するようにしたかった。
そこで、非同期処理アーキテクチャとAWS Lambdaを採用することで、システム全体の負荷を軽減するチャレンジを行った。実際に構築したシステム、アーキテクチャは以下である。
「請求書ファイルがアップロードされ、データの保存が完了したら、残りの処理は非同期で行うようにしました。SQSを経由しジョブが稼働するのが基本構成のシステムアーキテクチャです」（高際氏）
【設計のポイント】
請求書のアップロードと保存が完了したら、残りは非同期処理
- SQSで残りの処理を切り離し、別サーバで処理
- 重い処理は、呼び出しごとに個別の環境を素早く並列に起動し実行するAWS Lambdaを活用
一方で、実装については苦労も多かった。例えば、請求書ファイルのフォーマットが、PDF、JPG画像、EXCELファイルなど、多岐にわたるからである。横向きでスキャンされる場合もある。そのため、前処理では条件に応じて異なるLambda関数を実行したり、Lambdaを使わなかったりするなど、複雑に分岐している。
非同期タスクの管理には、Goで実装されたmachineryというフレームワークを採用。高際氏はmachineryについて次のように補足した。
「machineryを利用することで、SQSから受信したメッセージに応じて指定のタスクを実行できる。それだけでなく、遅延して実行したり、エラーの場合はリトライのタイミングや回数の制御など、machineryを使うことで柔軟な非同期タスクの管理が行えます」（高際氏）
高際氏は実際にコードの実装についても紹介した。事前に実行したい関数をタスクとして登録しておき、メッセージを受け取ると、Nameで指定されたタスクが実行される。
このようなアーキテクチャにしたことで、月初など処理件数が急増してもシステムはスローダウンせず、スムーズにAI-OCRの処理が実行できているという。一方で、処理のワークフローが複雑になっているので、同問題を解消することが今後の課題だと述べ、セッションを終えた。
【Q＆A】参加者から寄せられた質問に登壇者が回答
Q&Aタイムでは、登壇者たちが参加者から寄せられた質問に答えた。
Q．LINEの機械学習・バックエンドエンジニアの連携や両スキルを持つ人材について
四倉：両領域どちらとも深く精通している人は、多くはありません。そのため、双方のエンジニアが日々それぞれのスコープで頑張ることに加え、連携することが重要だと考えています。いわゆるMLOpsです。LINEではパラメータをチューニングしたり、機械学習モデルをアップロードしたりなど、サービスの更新が頻繁なこともあり、毎日のようにコミュニケーションを行っています。
Q．BtoB事業は研究目的の意味合いが強いのか
四倉：あくまで個人的な見解ですが、研究とビジネスの両面あると捉えています。最先端の機械学習をビジネス現場に導入するという研究的な側面がある一方、会社としては「世界をリードするAIテックカンパニー」を目標に掲げており、AIビジネスの拡大も推進しています。
Q．キュー活用のアンチパターンが他にもあれば知りたい
四倉：キューは万能のようですが、たくさんのサーバーからアクセスされるため、負荷がかかりがちです。対策としては、不必要なデータは入れないこと。実際、先の事例でも直接画像データを扱うのではなく、画像のパスを利用していました。
Q．Celeryを使う上での注意・苦労点は何か
四倉：広く使われてはいるライブラリですがOSSということもあり、ドキュメンテーションが少ないなど、細かな部分は行き届いていないこともあると感じています。
Q．マスクを着用した状態でも顔認識は正しく行えているのか
鈴木：実は、現在鋭意対応中というのが正直なところです。顔認識エンジンのポテンシャルももちろんですが、現在利用できるハードウェア（カメラ）は限られているため、今後も改善・注力する必要があると考えています。
Q．他社との連携事例について詳しく聞きたい
鈴木：AI事業ではありませんが、建設現場にカメラを設置し、施工状況や品質管理を遠隔で行えるシステムを大和ハウス工業社に導入し、省人化に寄与しています。また、AIは関係していませんが、「焼き肉ライク」の店舗オペレーションの分析・改善の事例もあります。
一方、AIも含めた外部連携サービスでは、飲食店のテーブルに提供した料理画像をAIが分析することで、次に提供する料理時間を最適化する取り組みなども行っています。
Q．請求書のフォーマットはある程度でパターン化されているのではないか
高際：実は私たちも最初はそう考え、レイアウト分析を行い分類することを検討していました。しかし、100社あれば100通りのレイアウトがあると言っても過言でないほど各社が独自の請求書フォーマットを使っていたため、実装は困難でした。
Q．AWSを選定している理由は何か
高際：インフラ構成をコード化し、資産化している。また、社内リソースの都合上、ガードレール整備（最低限のセキュリティ保護の設定等）が間に合っておらず、基本的にAWSを使用することにしています。ただ、特定のAPIサービスや特殊な仮想マシン利用したいといった場合にはAWSにこだわらず活用しています。
Q．フロントエンド・バックエンド人材の割合は？
高際：SaaS事業立ち上げ1年目ということで、一人のエンジニアがどちらの業務も対応する、フルスタックやマルチエンジニアが多かったです。今後は分業化も進んでいくフェーズで、各領域に特化した専門家が増えてきています。
鈴木：サーバーサイドのエンジニアがフロントエンドよりも多いですね。またカメラ内のファームウェアを開発する部隊、業務システムの開発部隊のエンジニアもいます。
セーフィー株式会社
https://safie.co.jp/
セーフィー株式会社の採用情報
https://safie.co.jp/recruit/
株式会社LayerX
https://layerx.co.jp/
株式会社LayerXの採用情報
https://jobs.layerx.co.jp/
LINE株式会社
https://linecorp.com/ja/
LINE株式会社の採用情報
https://linecorp.com/ja/career/
関連するイベント
