2019-09-04 CEDEC2019 組織的に Game x AI を 推進していくための方法論 〜『逆転オセロニア』の AI の一歩先へ 〜

CEDEC2019 での「組織的に Game x AI を 推進していくための方法論 〜『逆転オセロニア』の AI の一歩先へ 〜」という発表の資料です.

Transcript

1. 組織的に Game x AI を 推進していくための方法論 〜 『逆転オセロニア』の AI の 一歩先へ 〜 2019/09/04 Ikki Tanaka, Data Scientist, DeNA, Takeshi Okada, ML Engineer, DeNA
3. Yet another talk?
4. Next Othellonia...
5. Today’s Talk DeNA のゲームでの AI 開発は どこに向かっているのか? （講演者の視点から）
6. Takeaway (summary) • 振り返り → Next Action → テーマの選定、着地、スケール • AI 活用ができる組織をどう作るか? → 適切な役割分担と推進フロー → 現場と横断部署を繋ぐ機能 • ゲームの作り方をどう変えたいか → AI の周辺システムの構築 → ゲームと AI の境界を意識した開発
7. Takeaway (summary) • 振り返り → Next Action → テーマの選定、着地、スケール • AI 活用ができる組織をどう作るか? → 適切な役割分担と推進フロー → 現場と横断部署を繋ぐ機能 • ゲームの作り方をどう変えたいか → AI の周辺システムの構築 → ゲームと AI の境界を意識した開発
8. 田中 一樹 データ サイエンティスト ❤　ゲーム AI 開発 ❤　レコメンド ❤　Kaggle Master keno (岡田 健) ML エンジニア & AI 推進する人 ❤　ゲーム AI 開発 ❤　設計 & 実装 ❤　Kubernetes, Rust 教師あり学習や強化学習の高速化や , 並列分散学習, 効率的なゲーム AI の開発などに興味を持っています . Practical Developers, 一緒に書きました And lots of other contributors… 『逆転オセロニア』の ゲームAI 開発の（ほぼ） 全てを最近書きました 強化学習の訳書なども 書いたりしました
9. History
10. And then... • Re-init • まずは「プレイヤーエージェ ントを強くする」 • Deploy & Release!! • Chaos • 「AI で何ができるのか?」 • 可能性の発見 & 提示 • Re-define Re-construct • 「スケールさせる」 • 組織的に注力 • 応用ケース拡大 2016 ~ 2017 2017 ~ 2019 2019 ~ ※ オセロ・Othelloは登録商標です。TM&© Othello,Co. and MegaHouse © 2016 DeNA Co.,Ltd.
11. “AI 利用の模索”
12. AI によるゲームアプリ運用の 課題解決へのアプローチ
13. • 課題 ◦ ステージ設計の難易度調整工数が大きい ◦ パラメタ設計 & 入力 ↔ テストプレイをループ • ユースケース ◦ 「強い AI」がテストプレイ ◦ プレイ結果を可視化、プランナーに提供 • 手段 ◦ ニューラルネット、遺伝的アルゴリズム ◦ MCTS、強化学習 http://cedil.cesa.or.jp/cedil_sessions/view/1511 https://www.slideshare.net/dena_tech/gameai-denatechcon
14. • 「強い AI」は作れる!! • 価値を明確にしてコミット ◦ タイトルメンバーとの関係をより深く築く ◦ 事業責任者とも投資価値を握り合う ◦ 外部事例サーベイにより知見蓄積 • ゲームの中へアプローチ ◦ 外から AI を作るだけでは理想の学習を 回せない ◦ シミュレータ開発まで踏み込む • 学習できた & 可視化もできた • 導入までは至らず ◦ タイトルの他施策との兼ね合いで導入見送り ◦ 工数削減のための工数が取れない... ◦ PDCA ループ回せず • シミュレータが遅い ◦ View 分離は元々の設計により簡単だったが... ◦ JavaScript なので fork ができなかったり ◦ 強化学習、MCTS の深く踏み込めず 学んだこと 振り返り
15. Good point • 「テーマ」を発掘したこと DeNA はこの 2016 年の発想から AI のもつ高い可能性を見つけ ゲームで取り組むきっかけになった
17. • 「負けてる時ほど面白い！クセになる大逆 転の爽快感！」 • リリースから 3 年 6 ヶ月 • 国内累計 2,500 万ダウンロード突破 (2019 年 8 月時点)
18. • 課題 ◦ 手強い AI と戦い気軽に練習できる場がない ▪ PvE → PvP 環境に ◦ 様々な相手に応じた戦い方を覚えるのが大変 ▪ アーキタイプの特性を学ぶ場がない ▪ 「プレイングスキル」「デッキの強さ」の両軸で コンテンツに幅出ししたい • ユースケース ◦ 「強い AI」と自由に対戦できるコンテンツ • 技術 ◦ ディープラーニング（教師あり学習） ▪ プレイヤーの対戦ログから AI を作成
19. • 課題 ◦ 始めたばかりのプレイヤーはデッキの組み方が 多種多様で迷ってしまう • ユースケース ◦ プレイヤーの所持駒をベースに AI がデッキ構築・提案 ▪ 「属性」や「使いたい駒」を指定可能 • 技術 ◦ アソシエーション分析 × レコメンド技術 × ドメイン知識 ▪ 「駒同士の関係性」を毎日自動で抽出し利用
20. • AI はゲームに新たな価値を もたらす ◦ リリース後のポジティブな結果 • 組織としてスケールさせる 重要性 ◦ Bottom Up & Top Down の側面から ◦ → Next • あるべき「シミュレータ」像 ◦ → Next • リリース & 運用中!! ◦ AI のポテンシャル、を実証 ◦ プレイヤーからも高評価 • プロダクト落とし込みに苦戦 ◦ 課題、ユースケース、技術の結びつけ ◦ AI に対する投資価値の明確化 • ゲームと AI の接続部分 ◦ ゲームを改造してシミュレーターは作れた ◦ それでも不十分なポイントが出てきた ◦ 特徴量抽出器まわりも技術的負債 学んだこと 振り返り
21. Good points • 課題解決する AI を作りきり「リリースできた」こと • プレイヤーからの「フィードバック」を得られたこと
22. And then...
23. 振り返ってみて 何が足らないのか？ ↓ どうすればもっと上手くAIを “使いこなせる”か？ • これからは AI をスケールさせることも重要 → Bottom Up（探索）と Top Down（スケール） • Bottom Up（探索） → 今までのやり方をさらに洗練 → 隠れている実課題を発掘 • Top Down（スケール） → AI 推進部という組織を作り体制強化 → AI のスケールに必要な材料の整理・作成
25. 0 → 1 Bottom Up 1 → 10 Top Down
26. Bottom Up Top Down 0 → 1 1 → 10 探索 スケール 未知のユースケース 既知のユースケース Do what we currently we don’t know Do what (probably) we can Expand（拡大） Profit（確実な成果） 思いつきのアジリティ 計画的なアジリティ それぞれ AI を活用する上では大切な要素 目的を明確に区別し、組織的に AI 活用を推進・加速
27. Bottom Up “AI でできることの探索”
28. うーん、ゲーム開発の ここ改善したいですよね〜 あ〜、こうやって解けば できそうな気がします！ （そんな課題あるんだ ...） プランナー ゲームエンジニア ゲームアナリスト マーケター ... AIエンジニア データ サイエンティスト AIリサーチャー MLアナリスト ... いいですね！やりましょう！ （できないと思ってた ...） ゲームプレイしてたら AI でこういうことできそう〜 ② AI チーム発 ① タイトル発
29. 目的 Bottom Up • ゲーム領域で目の前にある事業課題を データ・AI の力で解決 • サービス・データに触れている メンバーが双方向で協力 ◦ アナリスト（分析部、タイトル） ◦ プランナー（タイトル） ◦ データサイエンティスト（AI 組織） ◦ AIリサーチャー（AI 組織） ◦ エンジニア（インフラ、タイトル） ◦ and more...
30. 大切にしていること Bottom Up ★ 広範なゲーム関連事業の中で模索 ★ 横展開可能な技術・応用を意識 ★ 新たな技術の習得、発掘 ★ 潰れる取り組みも一定許容 ★ 部署を横断した繋がりの強化
31. 推進フロー 適切な役割分担 案件推進者 ✓ 案件の推進を担当 ▪ 事業担当者、プランナーなど ✓ 問題設定から導入まで一貫して推進 ✓ 効果測定、振り返り ビジネス ✓ 実課題を抱えているメンバーが担当 ▪ プロデューサー、プランナーなど ✓ 案件推進のサポート ✓ ソリューションを実際に利用 ✓ 具体的な業務フローの整理 ✓ ドメイン知識の共有 AI/分析 ✓ 分析やAI開発を行うメンバーが担当 ▪ アナリスト、データサイエンティスト、リ サーチャー ✓ データ整備 ✓ 技術的な課題設定 ✓ モデル構築 エンジニア ✓ AIのシステム設計開発、運用保守を担当 ▪ データ/インフラエンジニアなど ✓ AIモデル導入（w/ AI/分析） ✓ アプリケーションの提供（ w/ ビジネス） 課題探索 案件立ち上げ Feasibility 検証 (PoC) ビジネス適用 成果の定着 成果の発信 成果の拡大 ✔ 取り組むのが妥当な課題の探索 ✔ 多数の関係者の巻き込み ✔ 問題設定、成果イメージ ✔ AIの問題への落とし込み ✔ 果たして解ける問題なのか？を判断 ✔ 具体的な課題設定、データ収集 ✔ AIモデル構築（プロトタイプ） ✔ 性能評価、結果のすり合わせ ✔ AIモデルの作り込み（本番用） ✔ システム構築、（試験）導入 ✔ 効果測定、振り返り ✔ 利用者からAI作成者、案件推進者への ✔ 定期的なフィードバック ✔ 教育、育成（AIリテラシー向上） ✔ 外部登壇、記事執筆の積極支援 ✔ 案件立ち上げ時にも考慮できたらベスト ✔ 成果物の横展開 ✔ 成果物を元に再び課題探索
32. 案件推進者 ✓ 案件の推進を担当 ▪ 事業担当者、プランナーなど ✓ 問題設定から導入まで一貫して推進 ✓ 効果測定、振り返り ビジネス ✓ 実課題を抱えているメンバーが担当 ◦ プロデューサー、プランナーなど ✓ 案件推進のサポート ✓ ソリューションを実際に利用 ✓ 具体的な業務フローの整理 ✓ ドメイン知識の共有 AI/分析 ✓ 分析やAI開発を行うメンバーが担当 ◦ アナリスト、データサイエンティスト、リ サーチャー ✓ データ整備 ✓ 技術的な課題設定 ✓ モデル構築 エンジニア ✓ AIのシステム設計開発、運用保守を担当 ▪ データ/インフラエンジニアなど ✓ AIモデル導入（w/ AI/分析） ✓ アプリケーションの提供（ w/ ビジネス） 課題探索 案件立ち上げ Feasibility 検証 (PoC) ビジネス適用 成果の定着 成果の発信 成果の拡大 ✔ 取り組むのが妥当な課題の探索 ✔ 多数の関係者の巻き込み ✔ 問題設定、成果イメージ ✔ AIの問題への落とし込み ✔ 果たして解ける問題なのか？を判断 ✔ 具体的な課題設定、データ収集 ✔ AIモデル構築（プロトタイプ） ✔ 性能評価、結果のすり合わせ ✔ AIモデルの作り込み（本番用） ✔ システム構築、（試験）導入 ✔ 効果測定、振り返り ✔ 利用者からAI作成者、案件推進者への ✔ 定期的なフィードバック ✔ 教育、育成（AIリテラシー向上） ✔ 外部登壇、記事執筆の積極支援 ✔ 案件立ち上げ時にも考慮できたらベスト ✔ 成果物の横展開 ✔ 成果物を元に再び課題探索 簡単ではない AI 開発を 持続可能な状態に 推進フロー 適切な役割分担
33. 得られた価値 Bottom Up • 今まで見えなかった課題を幅広く発見 ◦ ゲームの様々な業務フローに入り込む ◦ 双方向の連携（タイトル ↔ AI 組織） • 組織レベルで AI リテラシーが向上 ◦ 技術蓄積、教育 ◦ AI でできること・できないことの共通認識 ◦ 現場レベルでの AI の浸透 • AI 導入プロセスの確立、スムーズな導入 ◦ 共通の推進フローを整備 ◦ 相談から実施可否を高速に判断 ◦ 案件の適切な継続可否判断
34. 『逆転オセロニア』における、機械学習モデルを用いた デッキのアーキタイプ抽出とゲーム運用への活用 09月05日(木) 16:30 〜 17:30 会場 302 • 現在多くのゲームで挑戦中です！ • 業界全体で知見を共有していきたい • Next time... DeNA TechCon 2018 https://www.slideshare.net/dena_tech/ss-87960853 MLアナリスト プランナー Bottom Up から生まれた事例
35. Top Down 計画的に AI を推進 • Bottom Up（探索）とは対照的に、 • 事業インパクトが出せそうな領域で • 計画的に AI 活用をスケールさせる
36. 組織的な動き
37. 過去 タイトル 専門家 AI 推進チーム
38. 過去 タイトル 専門家 AI 推進チーム ユースケースの pool • 社内の過去実績の蓄積, 汎化 • 社外の事例の収集, 蓄積
39. 過去 タイトル 専門家 AI 推進チーム ユースケースの pool • 社内の過去実績の蓄積, 汎化 • 社外の事例の収集, 蓄積 pool しているものとのマッチング • → 課題 の吸い上げ • ↔ ユースケースの明確化, 選択, 方向付け • ← 技術, 手段の紹介 • ← feasibility, コストなど, 施策の判断材料の提供 • → インパクトの評価
40. 過去 タイトル 専門家 AI 推進チーム ユースケースの pool • 社内の過去実績の蓄積, 汎化 • 社外の事例の収集, 蓄積 pool しているものとのマッチング • → 課題 の吸い上げ • ↔ ユースケースの明確化, 選択, 方向付け • ← 技術, 手段の紹介 • ← feasibility, コストなど, 施策の判断材料の提供 • → インパクトの評価 要素の提供 • 技術 (e.g., AI 技術) • リソース (e.g., 人) • 実装 実行力の pool • 橋渡しをするための コミュニケーション能力 • クライアント, サーバー, AI の多分野に渡る知識, 実装力
41. 過去 タイトル 専門家 AI 推進チーム ここがなかった 外の事例の収集, 蓄積 内の分析, 考察 現場と横断部署の有機的な連携 問題と解法をつないで価値を出す 社内に既にある 有名 IP, グローバルタイトルなどの 規模の大きさ それに伴う色々な課題 AI の専門家 ゲーム基盤の専門家 テストや自動化の専門家 etc
42. ゲームと機械学習の最前線　〜現状と未来を正しく捉えるために〜 09月06日 (金) 11:20 〜 12:20 会場 メインホール • 過去事例を踏まえ, これからのゲーム業界で の機械学習利用がどうなっていくのかについ てパネルディスカッション Top Down なアクションの一例
43. “Simulator”
44. Why “simulator”? • AI 絡めた取り組みで最初に必要なの は, 課題とユースケースの設定 ◦ 何を解決したいのか ◦ どういうストーリーでそれを解決するのか • シミュレータは手段, 技術 ◦ 但し, 広く使える ◦ なので, ここで取り上げてみる
45. What’s “simulator”? • よく言われること ◦ 「初期段階からシミュレータをちゃんと作っておくのは重要」 ◦ 「ビューとロジックを分離したゲーム作りにしておく」 ◦ このへんはもう当たり前 • あまり言われないこと ◦ ゲーム本体とAI の境界の設計 ◦ やりたいことに対する要件定義 D. Sculley, et al. Hidden technical debt in machine learning systems, NIPS, 2015
46. “Simulator” = 境界
47. • 課題 ◦ 手強い AI と戦い気軽に練習できる場がない ▪ PvE → PvP 環境に ◦ 様々な相手に応じた戦い方を覚えるのが大変 ▪ アーキタイプの特性を学ぶ場がない ▪ 「プレイングスキル」「デッキの強さ」の両軸で コンテンツに幅出ししたい • ユースケース ◦ 「強い AI」と自由に対戦できる環境を作る • 技術 ◦ ディープラーニング（教師あり学習） ▪ プレイヤーの対戦ログから AI を作成
48. 設定 オセロニアをもう一度 • ユースケース ◦ 「強い AI」と自由に対戦できる環境を作る • 具体的には ◦ プレイヤーさんの対戦ログを教師データとして, 教師あり学習 で Tier 1 の強さの AI を作る ◦ キャラクターやスキルの追加などのアップデート後, データが 集まりさえすれば AI が常に up to date にできるようにする 「境界」には何が必要?
49. 内部構造 作業フロー
50. training serving 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 棋譜 推論 API Kubernetes Engine 特徴量 棋譜 『オセロニア道場』のシステムアーキテクチャ
51. training serving 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 棋譜 推論 API Kubernetes Engine 特徴量 棋譜 『オセロニア道場』のシステムアーキテクチャ ゲームと AI の境界
52. 52 棋譜 特徴量 BattleEmulator FeatureExtractor 実際のゲームの バトルロジックを 簡略化したもの 各ターンに 何が起こったか 特徴量抽出
53. 課題 こうしておけばよかった • 既存の棋譜ログを流用した ◦ → AI 用にあるべき棋譜ログの設計をしておきたかった • バトルロジックの二重管理 ◦ ゲームやシミュレータ(Unity, C#)と特徴量抽出器(Python) ◦ キャラクター, スキルの追加に対して追加の実装が必要 ◦ → AI 踏まえたバトルロジックの設計をしておきたかった
54. 課題 こうしておけばよかった • 既存の棋譜ログを流用した ◦ → AI 用にあるべき棋譜ログの設計をしておきたかった • バトルロジックの二重管理 ◦ ゲームやシミュレータ(Unity, C#)と特徴量抽出器(Python) ◦ キャラクター, スキルの追加に対して追加の実装が必要 ◦ → AI 踏まえたバトルロジックの設計をしておきたかった リプレイ可能 であることの重要性
55. 55 棋譜 特徴量 BattleEmulator FeatureExtractor 実際のゲームの バトルロジックを 簡略化したもの 各ターンに 何が起こったか 特徴量抽出 棋譜に従って ビューなしで バトルをリプレイ & 特徴量抽出 形式はなんでもよい (バイナリでも) ターン制のゲームなら アクションを protobuf などで serializable にしておいて 保存したり通信したり ゲームと同じ言語で 特徴量抽出までやってしまう + 必要であれば薄い wrapper
56. 『バトルロジック』は 入力を出力に変換する機械 game simulator 棋譜ログ 描画ロジック 特徴量抽出器 バトルロジック 内部状態 ダメージ 計算機 NCP AI etc 入力コマンド 描画コマンド or observe state 記録
57. 入力が同じなら 内部状態や後段の出力も同じになる game simulator 棋譜ログ 描画ロジック 特徴量抽出器 バトルロジック 内部状態 ダメージ 計算機 NCP AI etc 入力コマンド observe state Random seed も記録 Replay!!
58. 内部構造 作業フロー
59. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
60. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル AI の学習だけではない!!
61. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
62. AI 学習 特徴量抽出 リプレイヤー Learner (python) 通信 対戦ログ 特徴量 AI モデル バトル再現 & 特徴量抽出 『バトルロジック』 を wrap したもの 複数マシンを並べて 高速化可能
63. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
64. 勝率評価 対戦サーバー Evaluator (python) 通信 NPC AI モデル 勝率やダメージなどの 統計値を見て モデルがどれくらい 良さそうかを評価 弱いものは捨てる v.s. 他の AI モデル v.s. 対戦ログ 『バトルロジック』 を wrap したもの 強化学習のためにも 高速・並列にたくさんのバトルを 捌けるようにする必要あり
65. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
66. 打ち手評価 ゲームの リプレイ機能 画面 対戦ログ NPC vs AI で AI が取った行動を見て AI の質や弱点を評価 バトル再現 クライアント側の 1機能
67. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
68. 試し打ち評価 & AI コンテンツ ゲーム AI 対戦機能 推論サーバー (python) API AI モデル 特徴量抽出 リプレイヤー 実際に人間が AI と戦ってみて AI の質や弱点を評価 デバッグ・本番で 同じ機能を使い回す
69. ゲーム AI 学習 勝率評価 試し打ち評価 打ち手評価 AI コンテンツ 対戦ログ AI モデル 対戦ログ AI モデル AI モデル
70. 特徴量抽出 リプレイヤー 対戦サーバー ゲームの リプレイ機能 ゲーム AI 対戦機能 リプレイ可能 であることの重要性
71. Takeaway • AI の取り組みを成功させるためには ◦ まずは課題とユースケースを決める • 技術的な投資をする上で ◦ AI (機械学習)技術への投資はもちろん ◦ ゲームと AI の境界が重要 • 「境界」はたくさんある ◦ 特徴量抽出, 高速なバトル環境, AI 挙動確認, etc... ◦ それらをまるっと実現するアーキテクチャ設計が大事 ◦ リプレイ可能なように作ること • “AI-native” なゲーム開発は面白い ◦ ゲーム開発者の設計・実装による協力が不可欠 ◦ AI 開発者と上手く連携して動く ◦ まだまだ発展途上なので, やっていき (`・ω・´)
72. Summary • DeNAは AI (= 機械学習) の可能性を 模索してきた • AI を使いこなす為に必要なこと ◦ いくつか試してみて, わかってきた ◦ 発信していく中で, 組織に浸透してきた • 次なる挑戦に向けた取り組み ◦ 案件探索の洗練（領域拡大） ◦ AI推進部（体制強化） • AI利用加速のためのパーツ ◦ Simulator のあるべき設計 一緒にゲーム x AI を盛り上げましょう!!
73. Acknowledgement • いらすとや • https://www.irasutoya.com/ • Smashicons • https://www.flaticon.com/packs/file-type-collection • designed by Smashicons from Flaticon • フリー素材ぱくたそ • https://www.pakutaso.com