【CEDEC2019】DeNAのゲームAI開発に見る”AIを活かす組織”とは？

DeNAは現在「ネクストオセロニア」という言葉を掲げ、これまでのゲームにおけるAI開発を振り返っています。これは『逆転オセロニア』の開発における成功と失敗を、次のAI開発にどのように活かしていけばよいかを探ろうというものです。本稿ではCEDEC2019で発表されたセッション「組織的に Game x AI を推進していくための方法論 〜『逆転オセロニア』 の一歩先へ〜」の内容を取り上げます。

DeNAのゲームAI開発のこれまで

DeNAの『逆転オセロニア』（以下、オセロニア）は、ゲーム開発に機械学習を導入した成功事例として知られていますが、DeNAの中でどのような位置づけで始まったものだったのでしょうか。

セッションの前半を担当した田中一樹氏（株式会社ディー・エヌ・エー AI本部AIシステム部データサイエンス第一グループ データサイエンティスト）によれば、ゲームアプリ運用の課題解決に向けて、古典的なAI技術のみならず、機械学習やディープランニングといった最新技術を視野に入れたAIを活用する試みを始めたのが2016年のこと。2016年から2017年にかけては、AIでできることの可能性を模索していたフェーズです。

はじめに取り組んだのはゲームアプリ運用の課題解決です。大きな課題のひとつとして、ゲームアプリにおけるステージ設計の難易度調整の工数が大きいという点がありました。従来の工程では、パラメータを設計して、値を入力して、そのあと難易度が意図通りになっているのかを確かめるためにテストプレイをします。この作業を繰り返すことで理想的なステージや難易度を調整していきます。

その作業工程のコストを軽減させるために、強いAI（ここで言う強いAIとは、人間の知能に迫るようなAIのこと）を作ることで自動テストプレイを行い、プレイした結果をもとにステージの難易度調整を適切かつ効率的に行うユースケースを目指したのです。開発の手法としては、古典的なMCTS（Monte Carlo Tree Search：モンテカルロ木探索）からリカレントニューラルネットワーク（Recurrent Neural Network：RNN）、強化学習なども検証していきました。

この取り組みは当時の社内ではあまり事例のない新しい領域への挑戦でした。結果として、まずAIを学習して作るということには成功しましたが、さまざまな課題があったため導入するには至りませんでした。とはいえ、特定の条件下では強いAIを作ることができ、それを可視化することでAIの可能性を垣間見ることもできたとのことです。

これはとても大きな収穫でした。まだAIの事例がない中で、実際のゲーム開発を通して課題の探索からAIの作成まで行い、AIで解決できそうな課題を発掘できました。AIの可能性を垣間見ることができましたし、今後につながる取り組みだったと思います。（田中一樹氏）

この取り組みをきっかけに、DeNAは本格的にゲーム開発におけるAIの活用を推進することになります。そして、2017年にオセロニアで強化学習を使ったバランス調整を行う強いAIを作るところから始めて、最終的に複数のAI機能を実装しました。現在は、今までの知見や技術の応用範囲を拡大させるために、組織的にスケールさせるフェーズに入っているとのことです。

オセロニアにおける2つのAI機能

ここで、オセロニアに実装された2つのAI機能について紹介します。ひとつは「オセロニア道場」、人間のように戦うAIと対戦できるという機能です。もうひとつはおすすめのデッキを提案してくれる「おすすめ編成」という機能です。

まず、オセロニア道場ですが、これは「手ごわい敵と気軽に戦う場がない」「さまざまなアーキタイプとの戦い方を覚えるのが大変」という課題を解決しようとしたものです。これまではPvE（対CPU戦）とPvP（対プレイヤー戦）の2つしかなく、特に初心者プレイヤーにとって、いきなり強いプレイヤーと戦うのは難しかったのです。また、アーキタイプごとの戦い方も覚えなければなりません。このユースケースは、より人間らしいAIを相手に戦うことができたら戦術のサポートができるのではないか、という発想から生まれました。使っている技術は、プレイヤーの対戦ログから学習するディープランニングです。

初心者プレイヤーにとって、多種多様な駒の中からデッキを組むのが困難なのではないかという仮説から始まったのが、プレイヤーの所持コマに合わせてデッキをレコメンドしてくれるAI機能「おすすめ編成」の開発です。ここでは古典的なアソシエーション分析、データサイエンスのレコメンド技術を採用しています。この試みで得られた一番大きな成果は、AIを作った機能をリリースして運用まで持っていけたことです。また、事業価値的にもポジティブな結果が複数あり、AIのポテンシャルを実証できたことも成果として挙げられます。

ただ、発想からユースケースへの落とし込みには、ゲームに精通した知識と技術への結びつけが必要で、そうした試行錯誤に時間がかかりました。とはいえ、PoCではなく「使えるAI」を作ることができたのは大きな前進で、リリースしたAIに触れた多くのプレイヤーからのフィードバックを受け、DeNAの中では「AIがゲームに新たな価値をもたらす」ことが少しずつ確信に変わっていったのです。

そして、AIの重要性を革新したDeNAは、それまで蓄積してきたことを効率的に活かしていくためには組織としてAIの活用をスケールさせる必要があると判断します。オセロニアだけではなく、さまざまなタイトルでAIをうまく活用することができれば、企業として新しい武器を持つことになります。では、どうすればもっとうまくAIを使いこなすことができるのでしょうか。そこで出てきた2つのキーワードが「ボトムアップ」と「トップダウン」です。

ボトムアップは、従来のように現場レベルで課題を探索することで、まったく別のユースケースを探し出す0から1の取り組みのことを指します。一方でトップダウンは、会社としてAIを計画的にスケールさせるために未知のユースケースを拡大させていく1から10のアプローチです。どちらか一方がより重要というわけではなく、両者ともにAIを活用していく上で大切な要素となります。

ボトムアップという取り組み

AIでできることの課題探索はボトムアップの取り組みで、エンジニアだけではなく、アナリスト、データサイエンティスト、プランナーなど、サービスやデータに触れているメンバーが協力して行います。タイトルチームからAIチームに対して、「ゲーム開発のここをAIで解決できないか」と疑問が投げかけるところからスタートし、それに対してAIチームからできそうな方法を提案します。それとは逆にAIチーム内から、「こういうことができるのではないか」と、タイトルチームに対して提案する動きもあります。

チーム間の信頼関係を築いたことにより、スムーズにAI活用の推進をスタートさせることができました。ボトムアップの取り組みの主要な目的は、ゲーム領域で目の前にある事業課題をデータやAIの力で解決することです。このようにサービスやデータに触れているメンバーが双方向に協力して目的達成に向けて動いています。（岡田健氏）

その際の大切なポイントとして言及したのは、次の2点です。

1. 特定のゲームだけではなく、マーケティングやカスタマサポートなど、幅広いゲーム関連事業、業務と連携して進めること（これは、横展開が可能な技術を意識することにもつながる）
2. 新たな技術の習得やユースケースの発見には不確実性というリスクも伴うため、つぶれる取り組みの存在を一定数は許容し、心理的安全性も確保できる仕組みを意識すること

部署を横断するさまざまな取り組みも行われており、例えばアナリストが所属する分析部、AIの専門家が所属するAIシステム部やAI推進部など、AIの開発に携わる部署間で互いの進捗や技術トレンドを共有する機会を持つことが、ポジティブな効果につながっています。

また、明確な戦略なしに課題や案件の探索を行っていくと、それぞれのメンバーの責任分界点が曖昧になって進めづらくなるため、適切な役割分担を定義して関係者の認識を揃えることであるべき”姿”を明瞭にし、効率的に案件や課題の探索を進められる体制にしています。

成功や失敗の如何に関わらず取り組んだ事例の成果を次につなげられる体制を作るために、AIや機械学習、データサイエンスの案件を安全に進められる推進フローも社内で策定しました。これによって、取り組む価値が不明確であったり、明らかにAIではできないような無理難題な案件が進んでしまうことを回避できるようになりました。このように、地道な地盤作りをすることでAI開発を持続可能な状態にできるようにしていきました。

この推進フローの策定により、ゲーム開発に関わるさまざまな業務がフローに入り込み、今まで見えてこなかった課題を発見できるなど、組織としてのAIの活用の幅を広げることができるようになりました。また、さまざまな関係者がAI活用について議論することで、組織レベルでのAIのリテラシーが向上にもつながっているとのことです。

こうしたボトムアップの取り組みで生まれた事例としては、オセロニアのアーキタイプの自動抽出とゲーム運用への活用が挙げられます。AI部分はAIエンジニアや機械学習アナリストが開発していますが、運用にも関わる部分のためプランナーやタイトル側のエンジニアとも協力して完成させました。

トップダウンのAI開発とシミュレータ

もう一方のトップダウンのAI開発では、事業インパクトが出せる領域に対して計画的にAIの活用をスケールさせる必要があります。まずは組織的な動きとして、ゲーム分野におけるAIの応用的な活用を推進するためのチームとしてAI推進チームを設置しました。このAI推進チームの役割は大きく2つ、「事例・知識の蓄積」と「現場との架け橋」です。

AI推進チームでは、社内・社外を問わず過去の実績、事例、ユースケースを蓄積しています。どのような課題に対して、どのような技術を使い、どのような結果を得たのか、それらを調べた上で組織に還元することで、初めて課題に取り組むことができます。具体的には、開発の現場である各タイトルチームにヒアリングし、課題を把握した上で過去の事例の適用も視野に入れた解決策を提案します。そして、適切な専門家につなぎます。機械学習の勘所とゲームのドメイン知識やゲームの開発の経験も必要になってくるため、エンジニアリングの知識やスキルも併せ持っています。

このようなAIとの橋渡しの専門家は今まで注目されていなかった部分ですが、今は会社として積極的に投資しています。（岡田健氏）

これは、オセロニアの事例を振り返った際に、当時は「事例・知識の蓄積」と「現場との架け橋」、この2つの動きが欠けていたという分析から見えた課題です。

そして、ゲームに機械学習を応用する際にシミュレータが大きな役割のひとつを担っていると岡田氏は言います。

ここでシミュレータを取り上げる理由を明確にしておきます。AIの取り組みのためにまず必要なのは、何をどのようなストーリーで解決したいのかという課題とユースケースを決めることです。シミュレータはそのための手段となる技術でしかありません。ただ、用途は広いです。各社の発表を見ても、まずはシミュレータとなることが多いです。インゲームが絡んでくると、やはりここが重要になります。（岡田健氏）

よくシミュレータは大事、初期からシミュレータを作っておくべき、ビューとロジックを分離しておくようなゲームの作りにしておきましょうという話になります。しかし、岡田氏はそれでは片手落ちだと指摘します。やはり、ユースケースありきで考えるべきで、それを意識したときに浮かび上がってくるのが「ゲーム本体とAIの境界」と「やりたいことに対しての要件定義」です。

「オセロニア道場」の例では、ユースケースは強いAIと自由に対戦できる環境を作るというものでした。そして、インバトルの強いAIを教師あり機械学習で作ることを目指しました。このとき「境界」には何が必要になってくるのかを、内部構造と作業フローの2つの視点で見ていきます。

オセロニア道場の内部構造は図のとおりで、ゲームの端末から記譜を推論APIに投げ、特徴量抽出APIで特徴量に変換し、それをAIのモデルで推論した結果（出てきた打ち手＝どこに何をおくのか）、その価値をクライアントに返す、という流れになります。その際に生じる境界がゲームとAIの境界です。左側がゲームの世界、右側がAIの世界、それをつなぐのが特徴量抽出機です。特徴量抽出機は記譜を特徴量に変換します。左が記譜、右が特徴量。オセロニアの特徴量抽出は今の盤面を再現して、そこから情報（どこの場所に黒石が置かれていたのか、手札にどういうキャラクターがいるのか、など）を抜き出します。実際のオセロニアでは、これをPythonで実装しています。

振り返りの課題として岡田氏が上げるのは次の2点です。

1. 記譜ログをAI用に設計すること
2. バトルロジックの二重管理をやめること

ここで重要なのはリプレイが可能かどうかです。「そもそものゲームのバトルロジックをリプレイ可能にしておき、記譜に従い、ビューなしでバトルをリプレイして特徴抽出できるようにするべき」と岡田氏は語ります。

ゲームはプレイヤーからの入力を受けてメモリが変化し、その結果画面が変化してプレイヤーとインタラクトするものですが、この図の通り、現状はバトルロジックとビューロジックが分かれ、直接インタラクトしない形になっています。プレイヤーからどこに何のコマを置いたのかという入力コマンドが入ってくると、バトルロジックはそれを今の盤面に置いて、ダメージを計算して、内部状態を変化させます。その結果、どういう描画をするのかを描画ロジックに指示します。バトルロジックは入力を出力に変換する機械なのです。そして、AIのトレーニングなどで使うシミュレータを考えるために、入力コマンドを記譜ログに保存します。

入力を一元化し、学習段階と同じ記譜ログをバトルロジックに流し込み、それで特徴量抽出を行うようにすれば、リプレイ可能になります。こうしておくことで、同じ入力が与えられた際に内部状態も出力も同じになるはずです。

次は作業フローの点から見ていきます。AIコンテンツは、いくつかのフェーズを経て開発されます。重要なのは、目的は学習だけではないということです。AIのモデルに対しても、AIの専門家がAIの品質保証をしなければなりません。

まずAIの学習から始まります。ゲームからは対戦ログのデータが取れています。学習は、バトルロジックをラップした特徴量抽出（リプレイヤー）を使って行います。こうして疎結合にしておくことで、複数のマシンで学習データを生成することができるようになります。ここでのアウトプットは学習したAIのモデルです。

次に、勝率の評価です。学習はアウトプットとしてAOIのモデルを生み出しますが、それを「ふるい」にかけます。NPCや既存の他のモデルと戦わせて強いかどうかを判断し、弱いモデルは捨てられます。ここでのシミュレータは対戦サーバで、従来の狭義のシミュレータと呼ばれるものです。対戦環境を作って、実際のバトルロジックを動かしてPythonから対戦できるものです。ここでは対戦のログが出てきます。

そして、勝率評価で出てきた対戦ログは打ち手の評価に使います。打ち手の評価とは、人間がAIの打った手を見て、実際に目で確認して評価をすることです。AIの学習は試行錯誤するものです。その際、勝率が上がらない原因は何なのか、どういった状態のときにどういうパターンで負けるのかを分析します。このイテレーションをできるだけ短く行うことが非常に重要です。

そのためにはゲームのいちデバッグ機能として、バトルをリプレイして観戦する機能が必要となります。AIの対戦ログをどこかのサーバに置き、必要な際には即座に見られるようにしておくことが望ましいです。勝率評価を勝ち残ったモデルは、試し打ちを経てAIコンテンツにデプロイされます。試し打ち評価とは、実際に人間がAIと戦ってみて、どれだけ強いか、人間らしく打てるかを評価するステップのことを指します。そのための仕組みは、本番の推論とほぼ同じシステムです。注意点としては、やはりここでもイテレーションを回しやすいように作っておくことが望ましいということです。

このように、ひとつのユースケースだけを見てもゲームとAIの境界となる部分はたくさんあります。AIを活用するためには、これらすべてがしっかり機能する必要があります。リプレイ可能なように最初の段階から設計しておくことが重要です。（岡田健氏）

DeNAでは、オセロニアの2つのプロジェクトを経て、ゲームの文脈でAIを使いこなすために必要なことが見えてきたという状況です。現在はボトムアップで探索し、トップダウンで推進するという形で、次の段階に向けて動き出しています。最後に岡田氏は、最も大事なことはゲーム開発者とAIの開発者が協力すること、AIを使ってゲームをおもしろくしたり、ゲームの開発を効率的にするためには、現場からの声、新しい企画、エンジニアの腕が重要だと締めくくりました。

Writer：大内孝子