本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物です。

2004|

2011

2011|

2014

2014|

SEサービス プリセールス @So+wareResearchAssociates,Inc.システム構築、客先のシステム運用、提案でキャリアをスタート→プリセールス〜PMを担当するインフラエンジニア

システムアーキテクト @TrigenceSemiconductor,Inc.、ほかエンベデッド開発支援、ITシステム管理、機械学習支援まで多岐に対応

セールスエンジニア@Fusion-io,Inc.高速半導体ストレージ ioDrive/ioMemoryシリーズのSEとして活動

様々なステージとルール

•  １６のステージ、４つのルール•  勝利に向けチームで立ち向かう

多様な楽しみ方

•  90以上のブキから好きなものを選んでプレイ

シューティングゲームの一種

–  第三者視点(TPS）

スプラトゥーンの特徴

–  自分たちの“ナワバリ”を広げないと進めない

–  「銃」タイプ以外に「バケツ」「ローラー」など、様々なブキがある

様々なプレイ層

–  小学校（クラスで半分がスプラトゥーン所有）〜大人まで

–  塗らないと勝てない （“相手を倒す”ことが 終目的ではない）

–  本気でやってる人たちは怖い

WiiU用ゲーム「スプラトゥーン」支援ソフト

– HDMIキャプチャを介して情報を自動取得

– 数値・文字列データとして認識

– お好みの方法で蓄積、出力

NintendoWiiU＆ スプラトゥーン

データ化{“kills”:5,“deaths”:1}

IkaLog

外部ツールへ出力(棒読みちゃん等)

出力例

HDMIキャプチャデバイス

IkaLog実行用PC

ARM搭載FPGAボード

10月より開発開始

録画ソフト 自動制御

AmaRecTV

カラーLED連動

Fluentd転送

スプラトゥーン戦績記録SNS

CSV/JSONファイル保存 スクリーンショット保存

SNS投稿

IkaLog

•  IkaLogユーザのひとり@fetus_hinaさんが開発、

運営するWebサイト

•  IkaLogからのプレイデータを受け取り、表示・集計する

•  IkaLogからの投稿を分析し統計情報、トレンドを表示

17https://stat.ink/

自分が倒されて行動不能だった時間

イカ（味方／敵　計８匹）の生死状況

チームのスペシャル発動、キル／デス

自分の塗り面積

https://stat.ink/

目標物の確保状況

敵チームのポイント

自チームのポイント

逆転の瞬間

https://stat.ink/

https://stat.ink/

https://stat.ink/

ナワバリバトル – 互いの干渉が少ない

ガチエリア – “相手を倒しつつ生存”がカギ

ガチホコ – 全体的に乱戦になりやすい

ガチヤグラ – 全体的に乱戦になりやすい

https://stat.ink/

https://stat.ink/

.96ガロンデコアップデートをきっかけにユーザー数が激減

ロングブラスターカスタム夏以降、人気を博しているブキのひとつ

データソースhbps://stat.ink/endre/user

【ピーク】24時間あたり370ユーザ、約15,000ゲーム

2016年11月時点にて24時間あたり 平均100ユーザ超が利用、平均2500ゲームを処理

後の“フェス“（ゲーム内イベント）

•  2014年INTEROPでの”Chainer”デモがきっかけ

– 深層学習のプレゼンテーションみて「凄いな」と思った

–  “何か面白いソフトウェアを作りたいな”

– ちょうどスプラトゥーンの発売直後だった

•  未経験からのチャレンジ

– OpenCV経験3時間ぐらい

– 機械学習／ディープラーニング経験 なし

0"

2"

4"

6"

8"

0" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10"

Kill Win/Lose

Win" Lose"

0"

1"

2"

3"

4"

5"

1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11"

Death����Win/Lose"

Win" Lose"0.0%$2.0%$4.0%$6.0%$8.0%$10.0%$12.0%$14.0%$

*5$ *4$ *3$ *2$ *1$ 0$ 1$ 2$ 3$ 4$ 5$

K*D

ここまでするなら

自動化できるツールを作ろう！

ソース映像 マスク画像 加算画像

+==

正しいマスクを加算すると画像が真っ白になる

違うマスクを加算すると画像が真っ白にならない

32

34

•  ゲーム中で使われているフォントは２種類

– 画面上に現れる数字フォントは１種類

– フォントが判っているのだから、認識できるはず

•  試行錯誤の後、既存OCRエンジンの利用は断念

– 機械学習ベースの認識エンジンを実装

• 

• 

– 

– 

– 

– 

– 

文字として認識されないことも

●●●

●

■

■

■■

?▲

▲

▲

▲

?

?

?

?

とてもシンプルな機械学習標本　　　　の傍にあるサンプルがどれかで分類する。K=1の場合は 寄りのサンプルがあるクラスに分類される。K=3の場合は近くに3つのサンプルがあるクラスに分類される。

•  GitHub にソースあり

–  https://github.com/hasegaw/opencv_knn_example/

•  三つのパターン ○ △ □ で画像を生成し、

kNNで学習する

•  ランダムに ○ △ □ から画像を生成し、その画像

の種類を判定する

– KNN を用いてそれに近い画像を見つけ出す

– 見つけた画像の種類から、問題図形の種類を特定

問題図形をランダムに生成

K近傍法を用いて、学習済みの図形から、もっとも近い図形を調べる

仕分ける○ △ □

○学習済み図形

○ △ □

１）画面上の数字部分（位置固定）を切り抜き

２）縦・横のヒストグラムを生成し各文字の位置を特定

３）文字を検出用サンプルのサイズ（等幅）にリサイズ、

二値化

４）KNNにより既知の検出用サンプルと照らし合わせて

認識する

•  基本は数字の認識と一緒

•  認識率はそれほど高くないが、認識回数で精度を確保

–  IkaLogは現在毎秒10フレームほど解析している

–  下記例では、死因のメッセージ合計49fを解析し、

多頻度は96gal_deco (18f, 36%) だった → 結果的に正解

votes={'supershot':6, 'carbon_deco':1, 'bucketslosher':1, 'octoshooter_replica':1,'splashshield':1, 'sshooter_collabo':5, 'hotblaster':2, 'pablo':1, 'nzap89':6,'sharp_neo':3, 'hotblaster_custom':2, '96gal_deco':18, '52gal':1, 'hokusai':1}

47

スプラトゥーンのブキ　５９種類（スライド作成当時）

• 

• 

• 

• 

他の装備品が被っている 保護色（まだマシ） 保護色（マジつらい）

（まだバグがあった頃のバージョンの表示なので色がずれているけども）こんなかんじで特徴量を抽出していた

入力画像 ラプラシアンフィルタ適用

グレースケール K近傍法によるクラス分類

Thanks@itooon

sschooter_collabo

スプラシューターコラボ

特徴画像

52

長所

– 色の違いに鈍感

– 画像の「形」でざっくり認識

短所

– 解像度の違いに弱い

– 似た形の画像を正しく分類できない

スクリーンでは視認しにくいが、ユーザーが様々な解像度の画像を送ってくる「現実」

56

オリジナルのブキ(longblaster)

カスタムバージョン(longblaster_custom)

更に追加（Apr2016）(longblaster_necro)

出力される特徴量に被りが発生し、特徴量算出アルゴリズムの見直しが必要に

longblaster_necro

longblaster_custom

longblaster

IkaLog内部で使用する特徴量を主成分分析(PCA)で2次元空間に

投影したもの

出力される特徴量に被りが発生し、特徴量算出アルゴリズムの見直しが必要に

ゲーム終了時に表示される別の画面画面上に表示される「ギアパワー」画像を分類するKNNの問題点・「メイン」ギアパワーと「サブ」ギアパワーで　画像の大きさが異なる・ユーザー環境によって解像度が異なる・ブキ画像同様、状況によって特徴量が変化→ 「画像サイズの変化に強い分類器がほしい」

• •  ❌ ⭕

– 

– 

– • 

• 

（本スライド中の画像の一部はイメージであり実際のものとは異なります。）

オブジェクトストレージ

作業用インスタンス

onIaaS

１年以上のデータを蓄積総データ量 4TB以上

IkaLogユーザ stat.ink

hasegaw

•  機械学習／深層学習の精度は前処理の精度に影響を受ける

•  画像のズレ／ゆがみ対策（自動補正）を実装し、対策

テンプレートマッチング、 小二乗法を用いて 適候補を選定

アスペクト比が壊れている なぜか画像がズレているリファレンス

分類に使用する画像

Thanks@itoooon

長所

– ニューラルネットワークにより認識率が大幅に向上

短所

– データが大きくなる（例：100MB~400MB）

– Windows版に組み込みしづらい

PythonスクリプトをEXE化する「Py2EXE」と

ディープラーニングフレームワークは相性が悪い

– 処理に時間がかかる

ゲーム終了時のスクリーンショットstat.inkから投稿データを深夜バッチで受け取り約4000枚/日

認識対象となるブキ画像約24000サンプル/日

ChainerによるDNNで自動的に分類

スクリーンショットからサンプルを生成

ブキ精度向上にあたり注目したいサンプル（絞り込み済）

実際に IkaLogが利用するブキ認識モデルの強化、テストに利用

•  入力値と出力値

–  入力値： RGBもしくはHSVの色情報(47*45*3=6,345units)

–  出力値： 各クラスの出力値（91units,So+maxを適用する）

–  使用する結合：全結合のみを使用（理由は後述）

–  目　的：特徴量の自動生成

•  今回の用途であれば、深層学習で特徴量を自動的に見つけ出せるはず

•  各ブキの背景色の重みが自動的ゼロに調整されれば、背景色への考慮も不要

–  目標性能値

•  目標性能値:91クラスのマルチクラス分類が350ms未満（画面１枚あたり3秒以内）

•  stat.inkの投稿データに対して99.99%の精度

0

1

2

3

..

..

n

0

1

2

3

…

89

90

InputLayer OutputLayerHiddenLayer

52gal

52gal_deco

96gal

96gal_deco

…

sschooter_wasabi

wakaba

69

•  AzureML上でアルゴリズムの事前検証

–  小さなデータセットを使用し分類器を作成

–  入力層:ピクセル情報（をPCAにかけたもの）

–  隠れ層:1層、150ユニット（暫定）

–  出力層:各クラス（のはず）

•  この方針でトレーニングすれば、精度が高い分類器を得られるだろうと判断

–  特に何も考えなくても９８％以上の精度が得られた

–  各種ボケ画像も、おおよそ問題なく判定できた

72

•  AzureMLで得た結果をベースに、IkaLogに組み込む

モデルを作成する

–  stat.inkに投稿された90万点のブキ画像を教師データとして用意

–  フレームワーク「Chainer」を使用

–  GPUの恩恵も受けられる

•  学習したモデルの配布用フォーマット

–  float32→float16に変換

– 配布するモデルファイルのサイズが半減

CPU GPU #ofjobs

Throughput(images/s)

GPUTime/epoch(s)

RelaJveperf.

(virtual)

Corei7-4790S定格3.2GHz

使用せず 1 3,928 234.5s 1X

Corei7-4790S定格3.2GHz

GeForceGTX760

1 10,371 39.2s 5.9X

Corei7-4790S定格3.2GHz

GeForceGTX760

4 (bl)15,988 25.8s(103/4)

9.0XCorei7-4790S

定格3.2GHzGeForceGTX1080

4 (bl)30,320 6.25s(25.0s/4) 37.5X

※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。

75

目的と手段が入れ替わる瞬間

76

77

CPU GPU #ofjobs

Throughput(images/s)

GPUTime/epoch(s)

RelaJveperf.

(virtual)

Corei7-4790S定格3.2GHz

使用せず 1 3,928 234.5s 1X

Corei7-4790S定格3.2GHz

GeForceGTX760

1 10,371 39.2s 5.9X

Corei7-4790S定格3.2GHz

GeForceGTX760

4 (bl)15,988 25.8s(103/4)

9.0XCorei7-4790S

定格3.2GHzGeForceGTX1080

4 (bl)30,320 6.25s(25.0s/4) 37.5X

2XE5-2630Lv3定格 1.80GHz

TeslaP100 4 (bl)65,811 2.5s(10.3/4)

93.8X

SpecialThanksto

※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。

自宅のLinuxBox

パラメータチューニングのための事前学習ジョブ

–  様々な隠れ層の構成（パーセプトロン数）で学習を行い、モデルファイルサイズが小さくなるような構成を探索

–  4ジョブ同時投入（バッググラウンドプロセス化→wait）

–  ジョブ実行開始 03:08〜終了18:28 （実行時間15時間20分）

終的な学習速度

–  550エポック/24時間

※ファイルシステム書き込みへのモデルデータ書き込み、各エポックのTest/CrossValidadonテストの所要時間を含む

–  第一弾として第617エポックの重みを採用

→21GBのデータ・セットを用いて、数時間の作業、約48GPU時間で学習した

SpecialThanksto

K近傍法 既存ImageNet 新ニューラルネット

認識効率 一部ユーザでは低い

99.99+%

99.99+%

モデルサイズ 20MB（現時点） 400MB(AlexNet)100MB(GoogleNet)

14MB(Float32)7MB(Float16)

分類にかかる時間@IvyBridge2GHz

とても高速 ~300ms ~20ms

•  既存のImageNetよりも高速、より小さなモデルデータ（配布物）

•  従来のIkaLogよりも高い認識精度を実現

SpecialThanksto

•  ニューラルネットの順伝播処理を新規実装

– 既存のフレームワークは組み込まない

（Windowsユーザ対策）

– 高度な機能を実装すると面倒なため、 低限の

機能を絞り込んで実装（LinearFuncdon,ReLU）hbps://github.com/hasegaw/IkaLog/commit/3238b67749334a3c4254aa6f25c005f83e210895

–  IvyBridge2.0GHzで20ms以下、PYNQ-Z1(Cortex-A9650MHz)で200ms以下で順伝播可能

•  ニューラルネットを他の用途にも適用

–  ブキ分類器のほか、ギアパワー分類器を作る（優先度 高）

–  ガチホコのタッチダウン分類器を作る

–  戦況評価関数にRNNが使えるのではないか

•  本当に必要なデータセットの選定

–  21GBのデータセットには大量の重複データが含まれている

–  重複データをうまく取り除くと学習時間、効率ともにメリットがあると考える

–  PCA-basedanomalydetecdonが使えそう

•  IkaLogでは、複数の機械学習アプローチを適用している

–  リアルタイム処理では、おもにK近傍法(KNN)を利用

–  入力画像にロバストな分類器を作るため、深層学習を利用

•  特徴量の自動抽出、何十万の画像から自動的な学習

•  IkaLogとディープラーニング

– Windowsアプリケーションにそのまま組み込めるような深層学習のフレームワークは限られている

–  しかし、関数や機能を限定すれば、比較的容易に実装可能

–  学習には既存の深層学習フレームワークやGPUを活用

らぴす(2000-2014)

©07strikers