1.
DRIVE CHARTの裏側
〜 AI ☓ IoT ☓ ビッグデータを
支えるアーキテクチャ 〜

2.
森 健太郎 (@moriken)
● 出身：福岡
● 経歴：
○ 大手SIerで、毎年１プロダクト新規開発を経験
■ 2009年 第1回SBIビジネスコンテスト準優勝 (個人)
○ 2011年12月 DeNA入社
■ Mobage/AndAppのゲームプラットフォーム開発
■ 第7回DeNAビジネスコンテスト 最終選考
■ IoTデジタルサイネージ自販機開発(お蔵入り..)
■ DRIVE CHARTの立ち上げ(リードエンジニア兼アーキテクト)
■ 会社を起業し、エクセライク会計(クラウド会計)をローンチ

3.
起業実績 ステルスリリースで
700社導入済
https://tax.excelike.co.jp/lp_accounting/

4.
幻
の
自
販
機
https://youtu.be/c4CUXZgeR6c

5.
アジェンダ
DRIVE CHARTのご紹介A
AI x IoT x ビッグデータを支えるアーキテクチャB
Edgeデバイスのシステム構成C

6.
DRIVE CHARTのご紹介
A

7.
A1
４０万
これはなんの数字でしょう？
日本の年間の交通事故件数です。
これは、約１分に１回、交通事故が発生している状況となります。交通事故、多いですよね。

8.
A2 DRIVE CHARTとは
DRIVE CHARTは、交通事故ゼロ社会をめざすべく、AIドラレコが、
ドライバーの速度超過などの荒い運転や、脇見などの気の緩みを検知し、レポートで振り返り
を行って、運転が改善していき、結果として、事故が減る、というサービスになります。

9.
A3 DRIVE CHARTの実証効果

10.
A5
車間距離不足
一時不停止
速度超過
車外カメラ
DRIVE CHARTでは、車外カメラがついており、このように、
「車両」や「ひと」や「自転車」などをリアルタイムで検知できますので、
「車間距離不足（いわゆる、あおり運転）」や「一時不停止」「速度オーバー」などを検知することができます。
https://youtu.be/EpVC_tsdUrE

11.
居眠り
脇見
A5
車内カメラ
また、「車内カメラ」もついていて、
「脇見」、「居眠り」などを検知して、ドライバーさんにアラートをお知らせすることができます。
https://youtu.be/nzIiNDiKPhg

12.
A7
運転のクセを見える化し、危険な動画だけピックアップ。
このようにして集めた情報を、レポートとして、ドライバーさんに自身の運転を振り返っていただき、
運転行動の改善を促していきます。

13.
A5
AI
ア
ノ
テ
|シ
ョ
ン
ツ
|
ル
このように、AIの精度をあげるために、
「これが車だよ」「これは人だよ」という「アノテーションツール」もつくり、数十万枚の学習データ
をつくりました。

14.
A5
AI
ア
ノ
テ
|シ
ョ
ン
ツ
|
ル
顔のほうも「目」「口」なども同様につくっていき、精度が大幅に向上していきました。

15.
エ
ン
ジ
ニ
ア
体
制
2017.3〜6 2017.7〜12 2018.1〜9 2019.7
プロトタイプ実装 実証実験(Ph1〜Ph2) ローンチ
AI Sys
Edge Sys
Server Sys
5人
5
人
A6
10
人
AI
30人

16.
AI x IoT x ビッグデータ
を支えるアーキテクチャ
B
AI IoT BigData

17.
ラ
イ
ブ
マ
ッ
プ
②危険運転のみ見たい
数10万台
要求
仕様
①運転スコアがみたい
③車両がいまどこにいるか

18.
車両数： X,000台 x 3ヶ月間 X00,000台 x 3ヶ月間
ECS 車両からのリクエスト数 60 RPS 4,000 RPS
コンポーネント数 21 21
起動Container数 230 15,000
Aurora Auroraレコード数 3億レコード 200億レコード
Aurora容量 70 GB 4.5 TB
S3 S3オブジェクト数 6億オブジェクト 400億オブジェクト
S3容量 200 TB 13 PB
S3秒間GET数 500 get/s 35,000 get/s
S3秒間PUT数 60 put/s 4,000 put/s
ビ
ッ
グ
デ
|
タ
要求
仕様

19.
Question
このようなサービス。
どのようなアーキテクチャに
しますか？

20.
AI x IoT x ビッグデータを支えるアーキテクチャB1
CloudWatch CloudTrail
Aurora
Trusted
Advisor
CloudFront
Route 53
ALB
Secret
Manager
KMS
WEB
DynamoDB
SNS
OPE
OPS
CAR
UPL
S3
Glue
SQS
BigQuery
User
Device
Firehose
Internet
gateway
VPC
WEB
CAR
BATCH
JOB
OUT
DNA
OUT
DAEMON
MapMatch
AI
Scoring
FaceRecog.
DB
CDN
MONITORING ANALYTICS
KMS
S3
Queue
Medjed
Argus(BI)

21.
サーバ拡大B2
WEB
OPE
OPS
CAR
UPL
VPC
WEB
CAR
BATCH
JOB
OUT
DNA
OUT
DAEMON
MapMatch
AI
Scoring
FaceRecog.
Go
Rails Python
各コンポーネントはマイクロサービス化し疎結合
Drive ChartのWebサービス本体
社内用Operationシステム
社外用Operationシステム
車載器のデータ管理API
車載器からのアップロード専用API
社外とのデータ連携用API
社内とのデータ連携用API
AI群サーバ
レポート
生成など
のジョブ
【開発初期】
開発スピード優先
【開発中期〜】
パフォーマンス考慮し、
GOに置き換え中

22.
シーケンス
Edge
API Server AI Server
走行ファイル送信
(GPS/加速度etc.) データ保存
ファイル保存 AI解析
エンキュー
デキュー
走行ファイル取得
MAPマッチ
スコアリング
危険運転検知
スコア登録
危険運転登録
Aurora S3 SQS
危険運転動画要求
危険運転動画送信 ファイル保存
1分単位
に送信
5分単位
に処理
大量データ処理は
SQS + Daemon！
動画は危険運転のみPickUp！
MAPマッチ結果保存
データ連携は
DB + S3 + SQS

23.
B3
シ
ェ
ア
マ
ッ
プ
北海道から
鹿児島まで
@2020.02

24.
ECS負荷対策
AI IoT BigData

25.
リクエストおよびサーバ負荷の特徴
WEB
OPE
OPS
CAR
UPL
VPC
WEB
CAR
BATCH
JOB
OUT
DNA
OUT
DAEMON
MapMatch
AI
Scoring
FaceRecog.
User
Device
WEBへのリクエストは少ない
車載器からCAR/UPLへ
大量リクエスト AI処理における
サーバ負荷大
JOBにおける動画＆
レポート処理負荷大
SQS
Queue
dequeue
enqueue

26.
サーバ負荷対策①：ECSのAuto Scaling
車両の動きは周期的でAuto Scalingと相性良し。
ー 車両からのアップロード数 ー 実際のAuto Scaling台数
8:30 8:30 8:30
朝8:30ごろにピークを迎え、
その後は翌朝まで減少傾向

27.
サーバ負荷対策②：ECSのチューニング
• ECS Clusterのインスタンスをコンポーネント別に最適化
• Webサービス周り ： m5.large〜
• AIマップマッチ処理： m5.2xlarge〜
• AI顔認証 ： r5.large〜 （メモリ強く）
• ECS TaskごとにvCPU/Memoryをチューニング
• vCPUはなるべく使い切るように値を定める
• OOMが発生しない程度のMemoryの値を定める
• Memory Limit Overで、Taskがkillされないように見極める必要あり

28.
サーバコスト削減対策： ECSとFargateの住み分け
• 用途別にEC2 Container InstanceとFargateで分けて管理
• Spot Instanceを活用したい場合はEC2を。
• 一時的な処理やバッチ向けにFargateを。
• 車載器からの大量のデータアップロードへの対応
• AI処理やAI顔認証周りの大規模処理でSpot Intanceを活用中
• 現在は、9割以上がSpot Instanceで起動中
５５%のコスト
削減に成功！

29.
S3負荷対策
AI IoT BigData

30.
S3で保管するデータの特徴
CAR
UPL S3
CAR
Device
走行ファイル(GPS/加速度等)
動画
• データサイズは小さい
• 数B〜数十KB
• データ数量がかなり多い
• １走行で100超のオブジェクト生成と数が多い
• データサイズが大きい
• １動画が数MB〜数十MBとサイズが大きい
• データ数量が比較的少ない
• 危険運転に比例
1日1,000万超のファイル生成

31.
S3でのデータ対策
• Storage Class
• Standard
• S3操作
• LIST は禁止！ (高コスト)
• PUT/GET回数を減らすため、ファイル数は最小限に。
• アーカイブ
• 一定期間経過したオブジェクト群をまとめ圧縮し、Glacier送り
• S3ライフサイクルでのStorage Class変更はコスト爆上げなので要注意
• 1,000リクエストあたり、0.0571USD (ap-noarheast-1@2020/2)

32.
その他の工夫ポイント
AI IoT BigData

33.
• 車載器がS3に保管している設定ファイルをダウンロード
• CloudFront + S3 署名付きURL
▼いろいろ試した結果...
• DBで管理する？
• 容量、実行ファイルetc...
• AWS SDK + S3 GetObject？
• 車載器側でのSDKの更新
• credentialsの運用
• S3 署名付きURL？
• 発行しすぎてスロットリング
S3署名付きURLのスロットリング対策
Car API Cloud
Front
S3
Secret
Manager
Device
key-pair 取得
認証付き
URL 取得
アクセスNG

34.
分析データの保存先はBQ
分析データは、Google Big Query (BQ) に保存
• Webアプリの操作ログ、走行情報などをS3に転送
• S3に保存後、MedjedでBQへ転送
• BQのデータを、BIツール(Argus)でKPI設計・グラフ化
• Glue + Medjedで、アナリストがスキーマ定義して、BQまで必要な形式で連
携
Web
ECS
Firehose
S3GlueAurora Medjed
(Embulk)
Big Query Argus(BIツール)

35.
ログ・レコード転送にはGlue
• Auroraから取得するテーブル群は、AWS Glueで生成
• GlueはAWSのマネージドETLツール
• Aurora < - Glue -> S3の経路でデータ転送
• DPU(Data Processing Unit)単位で、IPアドレスを使用
• 大量にDBのレコードを抽出する場合、IPアドレスもその分消費
• Glueは、サービスの稼働するVPCとは切り離して実行
• ➔ DPU大量起動するため、一緒のVPCだと最悪IP枯渇問題発生のため
• アクセスログは、Kinesis FirehoseでS3へ

36.
モニタリング
• CloudWatch + Lambdaで各種リソースをモニタリング
• サービスの外形監視
• ECSのstatus監視
• Spot Instanceの停止イベント検知
• エラーログ、スロークエリログ監視
• SNSで通知
• Slack通知 (CWログからエラー内容を抜粋通知し１次判断可能）
• PagerDuty通知
• リソースの制限
• AWS Limit Monitorで監視
• https://aws.amazon.com/jp/solutions/limit-monitor/

37.
OpenAPI Documentを利用した
API自動テストの効率化

38.
APIテストにおける工夫
• 背景
• 0 ➔ 1 フェーズではスピード最優先
• API：1,000本、モデル：150個と大量
• UnitTest書いてる時間がない＆書いても仕様変更激しい
• ➔ API仕様書(I/F)を書いたら、req/resの自動テストできたら便利では...
• やったこと
• API 仕様書の規格
• OpenAPI 3 規格に沿って書く
• ツール選定
• テストツールは Dredd
• クラウドサービス (S3、SQS等)もローカル化し実行可能とし、ファ
イルのアップロード、メール送信までもカバー

39.
SwaggerAPI仕様書をOpen API3規格に沿って書く
APIテスト効率化ステップ
1

40.
APIテスト効率化ステップ
API仕様書からテストコード自動生成2
CIでテスト実行3
テスト結果がSlack通知4

41.
IoT機器のAIを利用した
サービスの実現

42.
自己紹介
• 木村 尭海（きむら たかうみ）
• 所属
• DRIVE CHART
• ハードウェアメーカーと協業してデバイス・ソフト開発および推進を担当
• 業務経歴
• メーカー系 家電連携Androidアプリ開発
• Androidデバイス開発
• toB/toC向け
• 執筆
• プロの力が身につくAndroidプログラミングの教科書
• Amazon Alexa開発ガイド Alexa対応スキル＆AVS対応アプリの作り方

43.
業務用車両を持つ会社の課題
• 事故削減のPDCAのサイクルが長い
• 運行管理
• 乗務員の事故防止や安全運行に支障が出ないように指導・監督
• 現行の安全運転指導
• 事故が発生した映像から指導が多い
• 1人あたりの乗務員の業務時間12時間〜20時間
• 1人の運行管理者に対して39車両を監督することがある
• 事故削減にはPDCAのサイクルを短くする必要がある
• 指導対象者を早く見つける
• 不安全運転を見つけやすくする
月に数回、1ヶ月に1回程度の指導をすることしかできないのが実
態

44.
誤検知を減らすためのアプローチ
• AI・ビッグデータを活用
• 非力なデバイスでは実現できない
• 通信型車載カメラが必要
• 通信型車載カメラ特有の通信量問題の解決が必須
• 映像データをすべてアップロードすると莫大な費用がかかる
• 実現にはハードウェアが必須
• AIを処理するだけのマシンパワーのある車載カメラがない

45.
開発しました

46.
DRIVE CHARTの通信型車載カメラのアプローチ
• DRIVE CHART用のデバイスをメーカーと協力して実現
• ハードウェア
• 株式会社 JVCケンウッド
• ソフトウェア
• 株式会社 ディー・エヌ・エー

47.
DRIVE CHART Spec
動作温度範囲 -10℃〜+60℃
外形寸法 約100 × 約62 × 約49mm
本体質量 約220g
電源電圧 5V
消費電流 1.2A
有効画素数 約400万画素
フレームレート 27fps (変更可)
記録解像度 1920 × 1080 (変更可)
録画フォーマット mp4(H.264, AAC)
音声記録 オン/オフ 可
HDR オン
動作温度範囲 -10℃〜+60℃
外形寸法 約52 × 約27 × 約
26mm
本体質量 約60g
電源電圧 8V
消費電流 300mA
有効画素数 約200万画素
フレームレート 27fps (変更可)
記録解像度 1920 × 1080 (変更可)
録画フォーマット mp4(H.264, AAC)
赤外線照明 赤外線LED × 4
HDR オン

48.
取り付け位置

49.
通信型車載カメラ＋AIで発生した課題
• 通信量問題と通信方法
• リスク運転動画について
• AI利用によるデータ削減
• 限定空間の制約を利用したデータ削減
• 排熱問題
• AIモデル導入におけるトラブル

50.
通信型車載カメラ＋AIで発生した課題
• 通信量問題と通信方法
• リスク運転動画について
• AI利用によるデータ削減
• 限定空間の制約を利用したデータ削減
• 排熱問題
• AIモデル導入におけるトラブル

51.
• 大きく4段階に分類分けができる
事故が発生する運転
安全運転
リスクのある運転
ヒヤリ
ハット
事故
● 右折時に対向車と接触事故 :走行中事故(自責or/and他責)
● 停車中に追突される :停車中事故(他責)
● 高速道路逆走車両と接触 :走行中事故(他責)
● etc...
● 人の飛び出しによる急ブレーキ :走行中トラブル
● 車間距離が近く事故確率が高い状況 :走行中トラブル
● etc...
● 速度超過 :走行中リスク
● 一時停止場所での不停止 :走行中リスク
● 急減速 :走行中リスク
● etc...

52.
安全運転
リスクのある運転
ヒヤリ
ハット
事故
DRIVE CHARTの運転行動を変えるアプローチ
• リスク運転までカバーして指導
• 事前教育の強化
• 運転の癖を矯正
• 運行管理者の仕事は増やさない
• 危ない運転だけを抽出

53.
分類ごとのDRIVE CHARTの観点
安全運転
リスクのある運転
ヒヤリ
ハット
事故 危険な運転は即時で危険性を知らせる
• 運行管理者が乗務員を止めるなどの処置を促す
• 明確な事象に対してリアルタイムに
デバイスで解析
リスク運転は誤検知を減らしより正確に提供
• 指導によっての改善を促す
• 運転終了までにリスク運転の動画を提供する

54.
分類ごとのDRIVE CHARTの観点
安全運転
リスクのある運転
ヒヤリ
ハット
事故 危険な運転は即時で危険性を知らせる
• 運行管理者が乗務員を止めるなどの処置を促す
• 明確な事象に対してリアルタイムに
デバイスで解析
リスク運転は誤検知を減らしより正確に提供
• 指導によっての改善を促す
• 運転終了までにリスク運転の動画を提供する

55.
リスク運転動画取得
• ビッグデータとAIを使って精度の高いリスク運転を抽出・収集
• デバイス内では実現できない
• 計算速度
• 過去のデータの保有
• サーバーで実現する
• 運転終了までにリスク運転動画をアップロードする必要がある
• 運転時のセンサー情報のアップロード
• AIによるリスク運転検出
• デバイスにリスク動画作成&アップロード要求
• リスク動画アップロード
必要な動画データのみをアップロードしてデータ量削減

56.
アーキテクチャ
内向き
カメラHardware
外向き
カメラ
3軸加速度
センサー
3軸角速度
センサー
GPS
OS
Application
ドライブレコーダー用フレームワーク
Hardware Abstraction Layer
顔認識
AI
車線認識
AI
物体認識
AI
衝突警報/車間距離警報
録画機能 センサーデータ保存機能
AI処理
ドライブ
レコーダー
処理
メーカー
開発

57.
アーキテクチャ
内向き
カメラHardware
外向き
カメラ
3軸加速度
センサー
3軸角速度
センサー
GPS
OS
Application
ドライブレコーダー用フレームワーク
Hardware Abstraction Layer
顔認識
AI
車線認識
AI
物体認識
AI
衝突警報/車間距離警報
録画機能 センサーデータ保存機能
AI処理
ドライブ
レコーダー
処理
メーカー
共同開発

58.
アーキテクチャ
内向き
カメラHardware
外向き
カメラ
3軸加速度
センサー
3軸角速度
センサー
GPS
OS
Application
ドライブレコーダー用フレームワーク
Hardware Abstraction Layer
顔認識
AI
車線認識
AI
物体認識
AI
衝突警報/車間距離警報
録画機能 センサーデータ保存機能
AI処理
ドライブ
レコーダー
処理

59.
リスク運転動画取得
運転中停車
走行状態
イグニッション OFF ON ?
時間
7:00 8:00
?
センサー
データ収集
現在時刻
AIサーバー
...
?
リスク動画
アップロード
1分間区切りでデータ生成
生成の都度サーバーへ送付
センサーデータを解析

60.
リスク運転動画取得
運転中停車
走行状態
イグニッション OFF ON ?
時間
7:00 8:00
?
センサー
データ収集
現在時刻
AIサーバー
...
?
リスク動画
アップロード
リスクのある行動を検知

61.
リスク運転動画取得
運転中停車
走行状態
イグニッション OFF ON ?
時間
7:00 8:00
?
センサー
データ収集
現在時刻
AIサーバー
?
リスク動画
アップロード
SDカード内の動画データから
必要な動画データを切り出し&送付

62.
データ量削減
運転中停車
走行状態
イグニッション OFF ON ?
時間
7:00 8:00
?
センサー
データ収集
現在時刻
AIサーバー
...
?
リスク動画
アップロード
このデータをできるだけ減
らす必要がある

63.
• 営業時間すべての情報をアップロードはNG
• 20時間勤務
• 実運転時間は12時間程度
• 走行中判断
• 3分以上の停止を停車と判断
リスク運転動画用データの削減
時間
センサー
データ収集
データ収集
運転中 一時停車 運転中 一時停車 運転中 一時停車 停車停車走行状態
40%の通信量削減
安全運転
リスクのある
運転
ヒヤリ
ハット
事
故
● 速度超過
● 一時停止場所での不停止
● 急減速
● etc...

64.
車内映像データの削減
• 人物の特徴点データをサーバーにアップロード
• 目
• 鼻
• 口
• 顔の方向

65.
限定空間の制約を利用した通信量・計算量の削減
• 乗務員特定の課題
• 車内映像には人は複数人存在する可能性がある
• タクシー
• 助手席・後部座席に乗客が乗る(最大5名映り込む)
• 営業車
• 同乗者
• 左ハンドル車両
• 乗務員は映像の左側とは限らない
• 防犯目的
• 中央につけて後部座席まで撮影するため中央に乗務員が来るとは限らない
複数人のデータのアップロードは無駄が多い

66.
複数人の中から乗務員の特定
• 乗務員の運転姿勢に着目
• 運転中の乗務員の動きは小さい
• 体を左右に動かす程度
• 内向きカメラを取り付けたときに映像の映り方が固定になる
取り付け時に
AIの計算領域を確定
枠内に一人しか映らない
制約をもたせる
乗務員のみのデータに限定できる

67.
DRIVE CHARTのデバイスで解決したい課題
• 通信方法と通信量問題
• リスク運転動画について
• AI利用によるデータ削減
• 限定空間の制約を利用したデータ削減
• 排熱問題
• AIモデル導入におけるトラブル

68.
通信型車載カメラのAI利用の条件
• 一定時間以内で計算が終わること
• 製品に組み込める精度を持つこと
• 過酷環境の動作ができること
• 炎天下の車内温度対応
• オーバーヒートを起こさない設計が必要
• エアコンによって車内温度が低下するまでの期間にAIが動かないのはNG
AIのアルゴリズム検討

69.
通信型車載カメラのAI利用の条件
• 一定時間以内で計算が終わること
• 製品に組み込める精度を持つこと
• 過酷環境の動作ができること
• 炎天下の車内温度対応
• オーバーヒートを起こさない設計が必要
• エアコンによって車内温度が低下するまでの期間にAIが動かないのはNG
AIのアルゴリズム検討
事故の発生率は運転開始時点が多い

70.
AIモデルの温度検証
• デバイスの動作要件
• 録画機能が60℃環境で動くこと(AIは50℃環境で動くこと)
• 10分間以上は高温環境下でも動作できること
• エアコンが効くまでの時間は必ず動作できること
• 温度影響によるクロック変動によって計算時間が伸びないこと
• 簡易試験
• 温度上昇試験
• 高温維持試験
• 高温からの温度低下試験
• リリース前試験
• 人工気象室
• 高温日照試験
2段階で試験を繰り返す

71.
AIモデル開発のフロー
HW特性調査
未学習モデル
作成
HW上動作
温度検証
HW上動作
温度検証
AIアルゴリズム
検討
人工気象室
温度検証
リリース
学習済みモデル
作成

72.
AIモデル利用のポイント
• CPU/GPU特性に注意する
• CPU/GPUのクロック調整
• オーバーヒートによるクロックダウン
• 仕事が少なすぎる事によるクロックダウン
• オーバーヒートしたときの設計
• オーバーヒートによるシャットダウンの見極め
• AI処理を止めるタイミング・復旧のタイミング

73.
まとめ
• 安全運転の実現の現時点のアプローチ
• AI×IoT×ビッグデータのアーキテクチャ
• ECS負荷対策
• S3負荷対策
• 通信型車載カメラ開発
• 通信量問題
• 排熱問題
新しい分野のため事故削減に必要な技術やアプローチに答えはありません
積極的なトライ＆エラーを繰り返し、事故の無い未来を目指します！

74.
ご清聴ありがとうございました。