運用中のゲームタイトルにおいては、継続的にプレイヤーに楽しんでいただくために新しいコンテンツを開発するといった、運営施策を効率的に作っていけることが重要です。『逆転オセロニア』の運用チームをサポートするために、私達AI開発チームはAIでどういったことができるのかを考え、研究・開発を行っています。 ただ、AI開発はデータや技術が用意できればそれだけで上手くいくものではありません。AIモデルを作るだけではなく、ビジネス価値を生み出す施策を設計したり、AIモデルを動かすためのシステムを構築したり、継続的な運営負荷を減らすための取り組みも必要になってきます。このように、プロジェクトとして考えるとAIの導入には様々な課題が待ち受けています。 本講演では、私達が開発しているAI技術に触れながら、プロジェクト推進・システム開発といった観点で、実際の経験に基づいたノウハウを提供したいと思います。

1. 運用中 ゲーム AIを導入する
〜プロジェクト推進・ユースケース・運用〜
奥村 純、岡田 健
（in collaboration with 田中 一樹、甲野 佑）

2. システム本部
AIシステム部AI研究開発第三グループ
AI研究開発エンジニア
システム本部
AIシステム部AI研究開発第三グループ
AI研究開発エンジニア
システム本部
AIシステム部AI研究開発第三グループ
AI研究開発エンジニア
システム本部
AIシステム部AI研究開発第三グループ
AI研究開発エンジニア
本日 講演メンバー

3. 登壇者紹介：奥村 エルネスト 純
● 理学博士（専門：宇宙物理学）
● データアナリスト @ 分析部
○ 『逆転オセロニア』リードアナリスト
○ オートモーティブ事業
● AI研究開発エンジニア @ AIシステム部
○ ゲームAI・強化学習 チームリーダー
■ ゲームAI 案件推進
■ 強化学習領域 戦略策定・案件推進
『データサイエンティスト養成読本
ビジネス活用編』
（技術評論社）
@pacocat
星博士レオ
『逆転オセロニア』
公式サイト 登場

4. ゲーム×AI：これま 活動
https://www.slideshare.net/juneokumura/dena-techcon2018 https://www.slideshare.net/juneokumura/cedec2018ai
● 『逆転オセロニア』 おけるAI導入 研究開発
TechCon2018
ゲーム体験を支えるため 強化学習
CEDEC2018
『逆転オセロニア』 おけるAI活用

5. ゲーム×AI：これま 活動
https://shibuya.ai/report/03/https://www.slideshare.net/juneokumura/cedec2018ai
● 社内外を巻き込んだ「ゲームAI」や「強化学習」 議論・発信
Shibuya Synapse #3
現在 強化学習 何が足り い か？
CEDEC2018
次世代QA AI

6. 本日 講演内容
ユースケース検討
ビジネスデザイン
データ設計
データ収集
データ分析
モデル作成
モデル評価
仕様検討
システム設計
実装
運用
AIプロジェクト ライフサイクル これま 主 発表し いた内容
● 使 いるデータ・AI技術
● 検証段階 結果概念検証（PoC; Proof of Consept）:
プロトタイプ検証を繰り返し ケース 確度を高める
実現可能性が確認 き から、
本格的 仕様検討・実装 進む

7. 本日 講演内容
ユースケース検討
ビジネスデザイン
データ設計
データ収集
データ分析
モデル作成
モデル評価
仕様検討
システム設計
実装
運用
概念検証（PoC; Proof of Consept）:
プロトタイプ検証を繰り返し ケース 確度を高める
実現可能性が確認 き から、
本格的 仕様検討・実装 進む
これま 主 発表し いた内容
● 使 いるデータ・AI技術
● 検証段階 結果
1．プロジェクト 全体像
● よう ユースケースを作 たか
● これま 成果 今後
● ゲームAIプロジェクト 進め方
AIプロジェクト ライフサイクル

8. 本日 講演内容
ユースケース検討
ビジネスデザイン
データ設計
データ収集
データ分析
モデル作成
モデル評価
仕様検討
システム設計
実装
運用
概念検証（PoC; Proof of Consept）:
プロトタイプ検証を繰り返し ケース 確度を高める
実現可能性が確認 き から、
本格的 仕様検討・実装 進む
これま 主 発表し いた内容
● 使 いるデータ・AI技術
● 検証段階 結果
1．プロジェクト 全体像
● よう ユースケースを作 たか
● これま 成果 今後
● ゲームAIプロジェクト 進め方
2．AI施策を運用 乗せるため ML Ops
● システム設計
● 高負荷 耐えられる仕組み
● 運用を楽 する仕組み
AIプロジェクト ライフサイクル

9. 講演 流れ
1
2
3
AI施策を実現するため 技術
AI施策を よう 作 きたか
プロジェクト 振り返り 今後

10. 1 AI施策を よう 作 きたか
● 課題 背景
● AI施策 紹介
1. デッキ編成をサポートするAI
2. 戦略 学習をサポートするAI

11. 『逆転オセロニア』 い
● オセロをベース した、シンプルだが奥深い戦略対戦ゲーム
○ 対戦相手 読み合いや逆転が巻き起こるゲームシステム
● 2016年2月 リリース後、継続的 成長※1
○ 2018年 累計2,300万ダウンロード突破
● 「コミュニティ」 一緒 創るソーシャルゲーム※2
※2: 一周年 爆発した『逆転オセロニア』 おけるゲーム分析 貢献事例 (CEDEC2017)
http://cedil.cesa.or.jp/cedil_sessions/view/1729
※3: 『逆転オセロニア』が実践した “コミュニティ 共創するゲーム運営 ” (CEDEC2018)
https://www.slideshare.net/dena_genom/ss-112897402
オセロ･Othello 登録商標 す。TM&Ⓒ Othello,Co. and MegaHouse © 2016 DeNA Co.,Ltd

12. デッキ・キャラクター
● 3,000種類を超える選択肢から16キャラクターから るデッキを構築
● キャラクター それぞれ独自 ステータスやスキルを持 いる
○ 新しいキャラクター 週 2,3体程度追加され いく
ステータス
HP、攻撃力、…
キャラクター固有 ス
キル
デッキ よ 様々 戦略 バリエーションが生まれる

13. バトルシステム
● 基本ルール 、盤面が 6×6 オセロ
● コマを置く 攻撃力やスキル 応じ 相手 ダメージを与えられる
局面 応じ 、戦略的 駒 運用を考える必要がある
相手 HPを削り切る
勝利
手駒 ランダム
選択される
特定 条件を満たす
スキルが発動 きる
特殊 効果を持
マスが存在する

14. 『逆転オセロニア』 解決したい課題
● ゲーム 継続を妨げるよう ネガティブ 体験を無くしたい
○ 「面白さ」を体験するま 多く 試行錯誤を要求し しまう
■ よう デッキを組め 駒同士 相性が良く る か
■ 駒を活用するため よう 戦い方をすれ いい か
● 「デッキ 編成」や「戦い方 学習」をサポートし くれる機能
○ 技術検証が完了し、一部リリースされ いる

15. AI 活用事例① オススメ編成
● 2018年11月 リリースされた機能
デッキ 属性
デッキコスト
利用したい駒
を選択
所持駒からオススメ
デッキを編成

16. AI 活用事例① オススメ編成
● 上位プレイヤー デッキ編成ログをも キャラクター 関係性を学習
● 学習されたモデルをも 、オススメ デッキをプレイヤー 提示
大規模
デッキログ
キャラクター 関係を定量化
（アソシエーションルール）
デッキ編成ログ
…
デッキ オススメ 活用
相性がいい
相性がよく い

17. アソシエーション分析
● 大規模データ 存在する関係性を抽出する分析手法※
○ 関係が支持度、信頼度、リフト 呼 れる指標 定量化 きる
ルール 支持度 信頼度 リフト
アバドン → アズリエル 5% 50% 2.0
ガラム → ジークフリート 25% 40% 1.5
フレデリカ → アルキメデス 20% 45% 2.1
ラヴーシュカ → アルキメデス 5% 30% 2.0
デネヴ → クロリス 55% 60% 2.3
… … … …
組み合わせ
頻度 ルール 有用度
前者 キャラがいる き
後者 キャラが含まれる確率
※『逆転オセロニア』 おける運用効率化支援 〜デッキログ データマイニング〜
https://www.slideshare.net/dena_tech/ss-87960853
基本的 スコア 高い組み合わせを
オススメし いけ 定番 デッキを作れる

18. リリース後 状況
時間
オススメ編成
利用回数
● メインターゲット し いる序盤プレイヤー 順調 利用され いる
リリース
デッキ編成を促すイベント期間中
需要が急拡大
イベント終了後も
継続的 利用され いる
※ 新キャラ獲得を契機 オススメ 編成を
確かめる傾向も確認され いる

19. リリース後 状況
● 初心者 PvP 勝率がオススメ編成を使 た場合 +5pt 程度改善
○ 逆 上位プレイヤー 場合 自分 編成した方が勝率が高い※
○ ゲーム 習熟するほ 自分 デッキを工夫する必要性が出 くる
● 事業的 もポジティブ 数字が見え き いる
※ 上位プレイヤー 「取りあえずオススメ編成 デッキを作 からカスタマイズする」 いう使われ方も
され いるよう 、そ 意味 全方位的 プレイヤー 負担を軽減し いる

20. Tips:「納得感」を作るため
● 分析結果 単純適用 不十分
○ 基本的 関係性 指標が強いも から順 オススメするが、
それだけだ プレイヤー 文脈 即したオススメ ら い
● 細かいチューニングを繰り返し がら「納得感」を作り上げ いる
○ リーダー駒を選ぶ時 別 ルールを併用する
○ スキルが発動可能かを一部チェックする
○ マイナー 駒を使う時 ルールを変更する
○ …

21. AI 活用事例② 戦略 学習サポート※
● 棋譜を読み込ん 上位ユーザー 戦略を学習
● 『逆転オセロニア』を遊べるAIを練習相手 、定番 デッキ運用を学習
○ 対人戦ほ ハードル 高く く、人間 よう 打ち方をする練習相手
※ まだ未リリース 機能 ため、今後 リリースを保証するも ありません。
開発中 仕様 ため変更される可能性があります。

22. 深層学習を使 た戦略 学習
● 『逆転オセロニア』をプレイするため 複雑 戦略 獲得が必要
○ 表現力を持 DNN（Deep Neural Nework）を採用
① 盤面情報、手駒情報 を数値 変換
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
Deep Neural
Network
② DNNが入力情報をも 打ち手を推論
打ち手
確率
上位プレイヤー
棋譜ログ
③ 上位プレイヤーが打 たか うかを
教師信号 し 比較 (Cross-Entropy Loss)
④ 打ち方が上位プレイヤー 近 くよう
ネットワークを更新
（数千万 バトルデータを用い 何度も繰り返し学習）
5000程度
特徴

23. （参考）ネットワーク アーキテクチャ
※ 本講演 詳細 立ち入りません（概要 以下資料を参考 し ください）
https://www.slideshare.net/juneokumura/cedec2018ai

24. こ パート お話したこ
● 施策 デザイン 過程
○ プレイヤー ネガを軽減するため 施策を検証
● 各AI施策 説明 結果
○ デッキを編成するAI
■ 既 リリースされ おり、ポジティブ 数字が出 き いる
○ 戦略 学習をサポートするAI
■ 技術検証が完了し、機能 検討を進め いる

25. 2 AI施策を実現するため 技術
● システム設計
○ オススメ編成
○ 対戦 AI
● 高負荷 耐えられる仕組み
○ Cloud ML Engine オンライン予測 利用
● 運用を楽 する仕組み
○ Experiment as Code

26. 登壇者紹介：岡田 健
● 理学修士（専門：数論幾何）
● エンジニア @ ゲーム事業本部 (~2017/12)
○ 『FINAL FANTASY Record Keeper』エンジニア
● AI研究開発エンジニア @ AIシステム部 (2018/01~)
○ ゲームAI・強化学習 AI エンジニア
■ エンジニアリング担当
■ 学習高速化(教師あり学習, 強化学習), 実験管理 仕組み くり, CI/CD
@keno_ss

27. 『逆転オセロニア』
AI を導入する

28. PoC =

29. 機械学習サービス 課題
引用: Sculley, et al., Hidden Technical Debt in Machine Learning Systems, NIPS, 2015

30. 機械学習サービス 課題
引用: Sculley, et al., Hidden Technical Debt in Machine Learning Systems, NIPS, 2015
サービス し 提供するため
モデル 学習以外 も
いろいろ必要

31. 今日 話

32. トピック
● システム設計
○ オススメ編成
○ 対戦 AI
● 高負荷 耐えられる仕組み
○ Cloud ML Engine オンライン予測 利用
● 運用を楽 する仕組み
○ Experiment as Code

33. 2 AI施策を実現するため 技術
● システム設計
○ オススメ編成
○ 対戦 AI
● 高負荷 耐えられる仕組み
○ Cloud ML Engine オンライン予測 利用
● 運用を楽 する仕組み
○ Experiment as Code

34. システム設計

35. オススメ編成 (再掲)
大規模
デッキログ
デッキ編成ログ デッキ オススメ 活用キャラクター 関係を定量化
（アソシエーションルール）
…
相性がいい
相性がよく い

36. training
serving
batch
システム設計: オススメ編成
分析 batch
ユーザー
デッキ編成データ
レコメンド API
App Engine
BigQuery
アソシエーション分析
Compute Engine
Cloud
Storage
Cloud
Pub/Sub
Cloud
Storage
Cloud
Datastore
App
Engine
Cloud
Functions
更新日時
マスタデータ
アソシエーションルール
(pickle)
マスタデータ
アソシエーションルール
(sqlite)
ユーザー id
所持し いる駒
レコメンドオプション
レコメンド結果 デッキ
(cron)

37. 対戦 AI (再掲)
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
1 6 2 4 9 2
2 5 3 1 8 3
0 1 5 0 9 2
8 7 2 7 3 4
1 4 3 2 3 0
3 5 1 9 8 3
Deep Neural
Network
打ち手
確率
上位プレイヤー
棋譜ログ

38. training
serving
システム設計: 対戦 AI
serving
training棋譜
AI モデル よる推論
Cloud Machine Learning
推論 API
App Engine
打ち手
価値
打ち手
価値
AI PvE マッチ
PvP マッチ Training AI model
BigQuery
Preprocessing
Compute Engine
Training
Compute Engine
Cloud
Storage
棋譜
棋譜
AI model
特徴量
Cloud
Storage
AI model棋譜

39. 2 AI施策を実現するため 技術
● システム設計
○ オススメ編成
○ 対戦 AI
● 高負荷 耐えられる仕組み
○ Cloud ML Engine オンライン予測 利用
● 運用を楽 する仕組み
○ Experiment as Code

40. Cloud ML Engine オンライン予測 利用

41. スケーラビリティ
● ゲーム イベントが開始された瞬間(~10分) アクセスが急増する
○ 試算 結果, 推論 API サーバー おい 700 RPS (= リクエスト/sec)
● オンライン予測 (not バッチ予測)
○ クライアントから棋譜を受け取り, レスポンス し 推論結果を返す
⇒ Cloud ML Engine auto scaling 任せたい
想定 RPS

42. 推論 API 求められる要件
推論 API
App Engine
AI モデル よる推論
Cloud Machine Learning
持ち時間: 15秒
ターン制バトル
持ち時間がある
満たせ けれ
UX 影響する
相手 次 こ 置い くるか ...?

43. Cloud ML Engine 負荷検証
● 評価観点
○ 想定 RPS 耐えられるか
■ 10 分 1000 RPS ま 増加する負荷をかける
○ レイテンシ
○ エラー率, エラー 起き方
○ 暖機 必要か
● 検証結果
○ す やくスケールし くれる
○ レイテンシ 3 秒以下※1
○ ただし, 一定割合 タイムアウトする※2
■ インスタンス数が増加するタイミング 起きる
(一例)
リクエスト数
エラー数
※1 我々 モデル 場合 .
※2 リクエストする側 10秒 タイムアウト. 実際 200 返 くる.

44. タイムアウトへ 対処
推論 API
App Engine
AI モデル よる推論
Cloud Machine Learning
AI モデル よる推論
Cloud Machine Learning
5秒待 帰 こ か たら
何かあ た 判断し
backup 再度リクエスト
backupmain
● main auto scaling
● backup 最低ノード数(minNodes)指定
+ auto scaling

45. タイムアウトへ 対処: 結果
全 上手く捌け いる!!

46. 2 AI施策を実現するため 技術
● システム設計
○ オススメ編成
○ 対戦 AI
● 高負荷 耐えられる仕組み
○ Cloud ML Engine オンライン予測 利用
● 運用を楽 する仕組み
○ Experiment as Code

47. Experiment as Code

48. モデル管理あるある
(スプレッドシートを確認する )
えー ,
2018MMDD_classAB_2048_emd56252_sb_flat
す .
あ き 使 たモデル れだ け ?
(2048? sb_flat?)
ぐ ...
表現ベクトル サイズが合わ く
ビルド き い...
表現ベクトル い 昨年 TechCon を参照https://www.slideshare.net/juneokumura/dena-techcon2018
「運用 カバー」 限界
(一人 作業し い も起きる問題 )

50. Experiment as Code
Experiment = モデルを生成/学習する1単位
● Configration
○ 学習 用いる棋譜 (期間, ユーザー クラス帯)
○ 隠れ層 ユニット数, 活性化関数, 学習率, バッチサイズ, etc…
○ キャラクター 表現ベクトル version
○ 特徴量抽出器 version
○ … をコード 記述し
● Data Collection
○ 必要 素材を集め き
● Feature Extraction
○ 指定された特徴量抽出器を使い学習したい

51. extraction
Cloud ML
ModelRecipe
Model.train
feature module
ModelRecipe
ModelRecipe
feature module
feature module
特徴量 特徴量
※説明 ためコード 簡略化し います
実験 (experiment)
デプロイ (deployment) を
コード 制御したい

52. extraction
Cloud ML
ModelRecipe
Model.train
feature module
ModelRecipe
ModelRecipe
feature module
feature module
特徴量 特徴量
※説明 ためコード 簡略化し います
ModelRecipe (or model name)
● ↔ experiment
● → deployment
● こ モデルが保存されるか
(local & GCS)も決定

53. extraction
Cloud ML
ModelRecipe
Model.train
feature module
ModelRecipe
ModelRecipe
feature module
feature module
特徴量 特徴量
※説明 ためコード 簡略化し います
feature module (or feature version)
● 特徴量 スキーマ定義
● FeatureExtractor 実装
正しいも を使わ い 精度が落ちる

54. extraction
Cloud ML
ModelRecipe
Model.train
feature module
ModelRecipe
ModelRecipe
feature module
feature module
特徴量 特徴量
※説明 ためコード 簡略化し います
ModelRecipe から特徴量抽出器を
学習データ生成や推論 利用

55. Experiment as Code: CLI tool
$ python util_model.py COMMAND --model-name=sl/v001_alpha
AI model
embedding
vector
Cloud
Storage
download_dependencies
build
check_trainable
download_model log training log
download_model inference AI model
train がエラー く実行 きるか
学習回せるか チェックま local やり,
学習自体 学習サーバー 行う

57. 技術パートま め
● システム設計
○ クラウド環境を積極的 利用
■ 運用コストを低く保ち , 負荷 柔軟 対応可能 AI サービス きた.
● 高負荷 耐えられる仕組み
○ レイテンシ要求がそこま 高く い場合, Cloud ML Engine 便利
■ ひ 手間かけれ 更 堅牢 するこ が可能.
● 運用を楽 する仕組み
○ Experiment as Code を徹底
■ 学習やデプロイ 手順が明確 り, 再実験/共有が容易 .

58. 3 プロジェクト 振り返り 今後
● プロジェクトを通し 意識したこ
● 今後 い

59. プロジェクトを通じ 意識したこ
1. スモールスタート じめよう
2. 期待値を合意し いこう
3. 機械学習チーム 役割を分散しよう
4. 目的を見失わ い

60. 1. スモールスタート 始めよう
● AIプロジェクト 最大 課題 不確実性
○ 「AI 何が きる か」「 れくらい きる か」が分から い
計画 準備
施策がブレる
評価指標があいまい る
実装 検証 実現
期待値が膨らん
非現実的 ゴールを作 しまう
成果が不透明 状況
予算・工数 GO判断を出し らい
精度が出 い 手戻りが発生

61. 1. スモールスタート 始めよう
● AIプロジェクト 最大 課題 不確実性
○ 「AI 何が きる か」「 れくらい きる か」が分から い
大計画 準備 実装 検証 実現
小計画 準備 実装 検証
小計画 準備 実装 検証
小計画 準備 実装 検証
課題を分解し 少しず 不確実性を ぶし がら、
継続 判断 工数・予算 調整を繰り返した

62. 1. スモールスタート 始めよう
検証内容
1. そもそもAI 学習 きる か 基本3デッキ NPCより勝率が高いか
● シミュレータ、学習環境
● 基本デッキを使 た棋譜データ
● DNNアーキテクチャ設計
2. キャラを拡張するこ 可能か
定番14デッキ 拡張し も
勝率が維持 きるか
● AIエージェント 場合 イメージ（※簡略化し います）
3. 勝率を上げるこ 可能か 定番14デッキ 勝率を◯pt改善 きるか
● 定番デッキ 抽出（クラスタリング）
● 定番デッキを使 た棋譜データ
● 拡張技術候補（ohe、表現学習、…）
アーキテクチャや特徴量検証 ため
分散学習設計
4. 現実 ユースケース 耐えうるか
● 全キャラ拡張し 勝率を維持 きるか
● 高負荷を現実的 予算 さ けるか
● 強さを体感するため ツール開発
● サーバーサイド 仮実装 負荷検証
期間◯ヶ月
◯人月、◯万円
期間◯ヶ月
◯人月、◯万円
期間◯ヶ月
◯人月、◯万円
期間◯ヶ月
◯人月、◯万円
判断基準 必要 も ・技術 リソース
…
…
…
…

63. 2. 期待値を合意しよう
● 不確実性がある 、期待値 人それぞれ
● 以下 点 一緒 認識形成するべき
1. AI パフォーマンス 不確実性があるこ （一喜一憂し い）
2. 不確実性 度合い、リリース後 変動
「思 たより勝率が出た！」 「あれ、想像し いたより弱い…」
「勝率が◯%ま いく 思 たが、
そこま 改善し か た」
「前回 言 いるこ が違う…」
AIメンバー 事業部メンバー

64. 2. 期待値を合意しよう
● 3 見通しをすり合わせるこ 、共通 期待値が醸成され い た
※『データサイエンティスト養成読本 ビジネス活用編』第3章より引用

65. 2. 期待値を合意しよう
● 3 見通しをすり合わせるこ 、共通 期待値が醸成され い た
○ 重要度：最低ライン ＞ 現実ライン ＞ 理想ライン
※『データサイエンティスト養成読本 ビジネス活用編』第3章より引用

66. 3. AIチーム 役割を分散しよう
● AIチーム プロジェクト すべ フェーズ 関わるこ る
● フェーズご 必要 スキルも様々
ケース 設計
● ビジネス理解
● KPI設計
● コミュニケーション
● プロジェクトマネジメント
データ設計・収集
● インフラ構築
● アーキテクチャ設計
● ETL
モデル構築・評価
● 特徴量エンジニアリング
● モデリング
● 最新研究 サーベイ
● 分散コンピューティング
● ドメイン理解
実装・運用
● システム設計
● アプリケーション開発
● DevOps、CD/CI
● 想像以上 プロジェクト 生態系 複雑
● ん もカバー きる「スーパーマン」人材を求め しまいがち

67. 3. AIチーム 役割を分散しよう
● AIチーム プロジェクト すべ フェーズ 関わるこ る
● フェーズご 必要 スキルも様々
ケース 設計
● ビジネス理解
● KPI設計
● コミュニケーション
● プロジェクトマネジメント
データ設計・収集
● インフラ構築
● アーキテクチャ設計
● ETL
モデル構築・評価
● 特徴量エンジニアリング
● モデリング
● 最新研究 サーベイ
● 分散コンピューティング
● ドメイン理解
実装・運用
● システム設計
● アプリケーション開発
● ML DevOps、CD/CI
事業部メンバー 分析基盤チーム
データアナリスト
データサイエンティスト
リサーチャー
アプリケーションエンジニア
AI PM 機械学習エンジニア
● DeNA スキルご 専門 チームがおり柔軟 チーム編成が可能
● AIメンバーが複数 スキルをかけもちし 全体をカバーし いる

68. 4. 目的を見失わ い
● AI ため AI開発をし い
○ 「強いAI」や「AI 対戦 きるこ 」それ自体 メリット ら い
● ゲームが面白く るこ 、面白さを阻害するハードルを くすこ が目的
● 今回 「AIが黒子 徹する」くらいがちょう いい付き合い方

69. 今後 い
● ゲームAI開発 経験値を活かし 徐々 拡大したい
○ 今回 紹介 き か たが検討され いるケース
○ 他 タイトルへ 知見 展開
● 「0→1」 「1→10」 プロジェクト 性質が変わる
○ ゲームタイトルを横断した共通 基盤 必要性
○ ゲームAIを専門 したチーム体制 構築
○ より長期的 戦略策定
試行錯誤 真 最中

70. 社外 がり い
● 業界全体 技術共有を進め いく必要性
○ ゲーム開発 今後も大規模化・高度化が続い いく
○ 単独チームや一 会社だけ 話が進ま い
○ TechCon 情報発信やコミュニティ活動もそうした一環
ゲームAIコミュニティ
Slack: game-ai-ja
https://goo.gl/jqEgLf
Google Group: game-ai
https://goo.gl/4dVN2o

71. Acknowledgement
● いらす や
○
●
○
○