つぶやく
 |
まずはEmbarkにおける機械学習の位置づけから。Embarkは，いくつかの哲学的なアイデアを掲げて設立されたスタジオだ。その中心にあったのは「AAA級のビデオゲームを作るのは難しすぎる」という問題意識。
創業メンバーの多くはDICEやエレクトロニック・アーツ（EA）の出身で，巨大企業のもとでは数千人がかり，莫大な資金と労力がかかるため，クリエイティブなリスクを取るのが非常に難しかった。挑戦の数が少なすぎた，という反省である。だからEmbarkの創業理念は，「新しい技術を使えば，ゲームをより速く，より楽しく作れ，より大きなリスクを大胆に取れる」というものだった。
 |
ここで言う“新しい技術”とは，たとえばフォトグラメトリ。世界中のアイテムを手作業で作る代わりに，現実の物を撮影し，コンピュータでデジタルアセットに変換する。あるいは非破壊的なキャラクターアートのパイプライン。新しい見た目のキャラクターを素早く作れる。制作の途中で気が変わっても以前の段階に戻って変更を取り消せば，あとはパイプラインが自動で追従・修正してくれる（作り直しが要らない）。これらは別のセッションで詳しく語られるとのことだが，いずれも機械学習そのものではない。
では機械学習とAIはどう関わるのか。マーティン氏は2種類の使い方を挙げた。1つは「既存の作業をより速くする」こと。たとえばコーディングエージェント（Claudeにコードを手伝わせる）や，アートアセットでの活用ーーテクスチャ写真から機械学習モデルで影を除去する“ディライト”，フォトグラメトリのパイプラインの高速化など，従来からやっていたことをより速く・効率的にこなすものだ。もう1つは「これまで不可能だった新しいことをやる」こと。アークレイダースのロボット，クエスト，パーソナライズなど，機械学習モデルなしには成立しないものだ。両者の境界は厳密ではなく，「速くできること」が「新しいこと」を可能にする場合もある。氏のチームは主に後者，これまで不可能だった新領域に焦点を当てているという。
 |
最初の実例は「THE FINALS」（PC / PS5 / Xbox Series X|S / PS4）だ。「ちょっとした優れたレコメンドの工夫」と「ちょっとした優れた“組織”の工夫」の2つの物語が語られた。
背景はこうだ。「THE FINALS」は基本プレイ無料のゲームで，収益はストアでの購入に依存する。だからストアが極めて重要だ。2年以上の運営で，装着可能なコスメティックは4000点超。2年分のカタログに対し，ストアの表示面はごく小さい。膨大なアセットを，狭い場所でどう見せるかが課題だった。
 |
 |
チームは行列分解の手法をいくつか検証し，なかでもEASE（Embarrassingly Shallow Autoencoders）※を採用した。過去データで試すと，recall（再現率）とMRR（平均逆順位）という2つの指標の両方で，EASEが明らかに優れていた。しかもこのモデルは極めてシンプルで，学習はわずか4行のPythonコードで済む。全ユーザー×全アイテムの行列を作り，それ自体を掛け合わせ，対角に少し値を足して逆行列を取れば，それが予測行列になる。予測は掛け算1〜2行だけ。
 |
 |
テスト場所はストアの「For You」セクション。従来はカテゴリーごとに世界中で最も売れた商品をパーソナライズなしで並べていた区画だ。ここにパーソナライズを導入すると，結果は劇的だった。購入者数が400％増加，ゲーム内通貨の消費が大きく伸び，米ドル建ての支出も有意に増えた。このセクション自体が売上の大半を占めるわけではない（それはバトルパスなど）が，区画単体としては大きな伸びである。
 |
ところが，このプロジェクトは実運用投入を諦めかけたという。理由はアルゴリズムではなく，すべて“組織”にあった。
そもそも，関心を持ってもらえるかを知るのが難しかった。誰に話せばいいか分からない。多くの組織で機械学習の研究チームは“脇に置かれた”存在で，Embarkも例外ではなかった。
商業チームの賛同を少し得たあとも，今度はA/Bテストがなかなか通らない。オーナーシップの所在が不明で，「複雑すぎる」「このたった4行のPythonを保守するのは大変」「技術的リスクが読めない」「そもそもテストの基盤があるのか」と難色が続く。
ようやくテストを回しても，初期の分析は「有意な結果なし」と出た。これも“ループの外”にいたことが原因で，研究を行った機械学習チームと，分析を担うデータサイエンスチームとでベースラインが異なり，見ているものが違い，コミュニケーションが崩れていた。きちんと分析すれば400％増だったのに，当初のレポートは「ベースラインに対し有意な改善なし」となっていたのだ。
最終的な解決策は，アルゴリズムとは無関係の組織的なものだった。機械学習エンジニアのジュンシク氏を，文字どおり機械学習オフィスの椅子から立たせ，ライブチーム（商業チーム）のオフィスの椅子に座らせたのだ。
すると，コミュニケーションのオーバーヘッドは消え，テストも分析も目標も明確になった。非・機械学習の同僚と毎日やり取りするようになったからである。外から内へ。席を移しただけで，長年の問題が解けた。
ここから得た教訓は明快だ。アルゴリズムがどれほどシンプルでエレガントでも，デプロイされなければ意味がない。そして“席”という単純なことが，仕事を前に進めることがある。リスクが取り除かれた今では，新しいアルゴリズムやアイデアをシーズンごとに試せるようになった。EASE成功後はさらに改良を重ね，ユーザーの閲覧履歴に基づく候補の再ランキングを，2番手のモデルのレコメンドと組み合わせているという。
 |
 |
2つめの実例はLLM（クエスト）だ。クエストはクエストの依頼者，名前，説明文，受注時に付与されるオブジェクト，完了時の報酬，達成すべき目標といった多くの属性を持つ。そして重要なのが，クエストは何らかの条件（多くは別のクエストの完了）で解放され，完了すると別のクエストを解放するという点だ。あるクエストが複数を解放したり，複数によって解放されたりもする。つまりクエストは“グラフ”構造を成している。
 |
これは通常の物語と対照的だ。本や映画は線形で，書き手は読者・視聴者が体験する順序をほぼ把握できる。だがビデオゲームのインタラクティブな物語は乱雑で難しい。プレイ順によって物語の受け取り方が変わり，違う順番で遊んだ友人とは「記憶している出来事」さえ異なる。これは執筆を非常に難しくする。
ゲームでは「見せかけの選択」でこれを回避することが多い。クエストAでもBでも，結局はクエストCに合流させる。物語空間を制約し，小さくして書きやすくするわけだ。だが，こうした作りを検証するには，あらゆるクエストの順列すべてを，飽きず，前回読んだ内容を取り違えずに読み通す必要がある。そんな人間はいない。
 |
 |
いや，一人だけいる。ChatGPTだ。LLMは決して疲れず，APIを呼ぶたびに“初めて読む物語”として読んでくれる。そこでマーティン氏のチームは，LLMを“生成的”ではなく“分析的”に使うことにした。プレイする順序でクエストをLLMに読ませ，プレイスルーをシミュレートさせるのだ。たとえばある順序で進めたとき，森のクエストの説明に「商人ボブ」が登場するのに，プレイヤーは前のクエストですでにボブを倒している…… LLMはこの矛盾を見つけ，「この順序だと話が分からなくなる」と指摘してくれる。いわば物語のためのユニットテスト，あるいはCI（継続的インテグレーション）だ。
さらに，LLMにペルソナを与えることもできる。「あなたはPvP好き。退屈になったら教えて」「あなたはロア（世界設定）好き。世界の情報をもっと知りたくなったら教えて」「あなたはルート（戦利品）目当て。報酬のペースがおかしい，ここは報酬が少なすぎる／多すぎると感じたら教えて」といった具合だ。
プロトタイプは好評だった。ナラティブチームは全クエストをこのツールに載せ，いくつかを選んで複数回流し，「どこで分かりにくくなるか」を確認できる。画面下部にLLMが実際にプレイした順序が表示され，サイドバーには「ここが分かりにくい」「ここで触れたロアがきちんと説明されていない」といった指摘が並ぶ。今では進行情報や報酬なども統合され，LLMベースの支援を備えた“ナラティブのワンストップ・ツール”になりつつあるという。
 |
 |
そして最後の実例がアークレイダースのロボットだ。マーティン氏はまず「リーパー（Leaper）」というロボットの映像を見せた。怒って飛びかかろうとし，着地に失敗して転がり落ち，また起き上がり……といった具合に，ぶつかったり失敗したりして必ずしも格好良くはない。だが，こうした小さなミスをすることが，かえってロボットを“本物らしく”見せる。
アークレイダースの開発初期，チームはリプレイ性（replayability）と“創発（emergence）”を強く求めていた。セッションごとに新しいことが起こる，その手段が創発であり，さらに「大きな歩行ロボット（誰もが格好いいと知っている）」と，接地感・物理性（physicality）を求めた。物理シミュレーションは毎回わずかに異なる結果を生むため，純粋にスクリプト化されたイベントの繰り返しに頼らず，各セッションを唯一無二にできる。
 |
 |
 |
実現可能だという確信はあった。現実の物理ロボットの映像は皆が見ていたし，Embark創業期には，ゲーム的な設定で物理と機械学習を組み合わせた興味深い論文が次々と出ていた。たとえばDeepMimic※は，物理ベースのロボットがかなり速く走り，高度な動作パターンをこなせることを示していた。では，物理と機械学習で自分たちのロボットを制御できるか。答えはイエス，強化学習（Reinforcement Learning）を使うことだ。
 |
強化学習は古くからあるシンプルなアイデアだ。「ポリシー」（ニューラルネットワーク）が行動（数値）を出力し，世界のエージェント（ロボット）へ送る。ロボットはその行動をシミュレーション内で実行し，世界に変化が起こる（前進する，腕を動かす，縁から落ちる等）。ロボットは結果を観測し，観測をポリシーへ返す。ポリシーは観測に基づき新たな行動を取る。この「行動→観測→行動→観測」のループが回る。どの行動を取るべきかを学ぶのが「報酬」だ。観測のたびに，研究者が定義した報酬を測り，行動がより高い報酬につながるようポリシー（ニューラルネット）を調整していく。
 |
初期デモはUnityのテスト環境とゲームアセットで行われた。観測は各関節の角度，ターゲットプレイヤーまでの距離と角度。行動は各関節のPD制御器に与える目標角度（モーターに「この角度になれ」と指示する）。報酬は，ターゲットへの距離を縮めること，身体の上方向と世界の上方向のなす角（コサイン角）を最小化して直立を保つこと，そしてプレイヤーの方を向く角度を最小化して相手を見ることである。
創発という設計目標は達成できたが，歩き方はふわふわとして不安定で，アニメーション的には望むものではなかった。そこで多数のパラメータを調整していく。各関節の硬さ，モーターの強さ・減衰，報酬の配分（前進・直立・対面のどれをどれだけ重視するか），消費エネルギー最小化などの追加報酬とその重み……。無数のつまみを回す日々だ。実験を管理するソフトウェアも大量に作り，何年もかけてチューニングを重ねた末に，自分で起き上がり，雨の中を歩き，視覚を持つ，なかなか良い歩容にたどり着いた。
 |
だが問題は残った。1つは到達までに膨大な時間がかかること。もう1つが「挙動のにじみ」※だ。「ターゲットへ歩く」という単一の挙動なら良いが，「歩く」と「止まる」のように複数の挙動を持たせると一気に複雑になる。1組の報酬で前進を，別の報酬で停止を学習させると，停止と歩行の切り替えは機能する。しかし歩き方が明らかに悪化する。いつ止まれと言われるか分からないため，ロボットが“おびえた”ようになり，全力で歩くことに踏み切れず，臆病に見えてしまうのだ。
ここでも教訓は同じ。ロボットがどれほどよく訓練されていても，ゲームデザイナーが「何を，どう見せながら」させるかを簡単に制御できなければ意味がない。
 |
解決策は，古典的なゲームAIの手法「ビヘイビア・ツリー（Behavior Tree）」だった。最終的に，「常に歩く・絶対に止まらない（停止を知らず全速前進する）」モデルと，「歩く・止まるを行う」モデルの2つを訓練。通常のゲームAIデザイナーが慣れたツールで制御するビヘイビア・ツリーが，「いま接近すべき＝全速で歩け」のときは“止まらない脳”を使い，「止まるべき」のときは停止を学習した“脳”に切り替える。後者は常に停止フラグを立てて使うため，即座に止まろうとし，例の挙動のにじみが出ない。停止用の脳はきれいに止まり，接近用の脳は前進時に格好よく動く。
これにより，機械学習側の“脳のエンジニアリング／報酬設計”と，ゲーム内で機能させる戦闘・ナラティブデザイナーの作業が切り離された。デザイナーは新たな機械学習モデルを作らずとも，「もっと頻繁に歩かせる」などを選べる。レゴのように独立したモジュールを足していけるようになったのだ。
 |
こうして良い見た目に到達し，（ゲームをリブートする前の）最初のローンチトレーラーにこのロボットを採用した。だがこのときの構成は，観測（関節角度，ターゲット位置までの距離・角度，実行すべき挙動），行動，そして非常に複雑な報酬でターゲットへ向かう速度，身体上方向と世界上方向のコサイン角，エネルギー消費，トルク使用，足以外の部位の接触，向きなど，10〜15種類もの報酬モデルを互いに完璧なバランスでチューニングしたものから成っていた。
問題は，これがスケールしないこと。新しいロボットを作るには全部を一から書き直す必要がある。アニメーターが「もっとキビキビ／跳ねる感じ／重い感じに」と言えば，すべての報酬を調整し直すことになり，見た目を変えるのに数週間〜数か月かかる。反復速度（velocity）の大きな問題だった。「1本足を2本足にしたい」と言われたら，また一からやり直しで，同じ結果になる保証もない。
 |
幸い，この問題が深刻化するなかで，AMP（Adversarial Motion Priors）という優れた論文が登場した。アニメーターが作ったアニメーションを，強化学習の枠組みと組み合わせる方法だ。
そこで（こちらも“マーティン”という名の）アニメーターに，いつものツールでロボットの歩行サイクルを作ってもらう。次に，アニメーターが作ったアニメの数フレームか，ゲーム内ロボットの数フレームを入力に取り，「マーティンが作ったものか，そうでないか」を分類するニューラルネットを構築する。そして，既存の報酬に加えて，「マーティンが作ったものらしく見えるほど報酬が高くなる」という報酬を与える。こうしてロボットは，常に模倣すべき“アートのお手本”を持つことになる。
 |
これでアーティストが再びループに戻ってくる。歩き方の方針を変えたければ，新しいアニメーションを作って再学習させればよく，制御がはるかに容易になった。アニメーターは「ものがどう動くべきか」を知っている。ならば，その動きを制御する道具を渡す。ここでも要点は「制作に携わる人にとって役立つツールを作る」ことだ。
こうして昨年3月の「サーバースラム」テストでは，ロボットは格好よく動き，好評を得た。ところが数秒後，問題が露呈する。同じ場面で，ロボットに倒されたプレイヤーがトンネルへ這って逃げ込もうとする。ロボットは入れるはずのトンネルに飛び込もうとして，はじき出されてしまう。なぜ中に入って倒さないのか。原因は“視覚システム”だった。
従来の視覚システムはこうだ。ロボットの上空に点のグリッドを作り，各点から下方向へレイ（光線）を飛ばし，地面に当たる位置を調べて高さマップ（height map）を得る。これは機械学習と相性が良い。コンピュータビジョンには，グリッド処理が得意なConvNet（畳み込みニューラルネット）があるからだ。実装も簡単だった。
 |
だが欠点も明白だった。張り出し（オーバーハング）に対応できない。橋の下やトンネル内に入ろうとしたとき，どこからレイを飛ばせばいいのか分からない。さらに，壁に近づくとグリッドの一部が壁の反対側に回り込み，“見えないはずの地面が見えてしまう”，いわば壁抜けの「ズル」が起きる。
解決策は点群（point clouds）だ。上空のグリッドからではなく，ロボット自身からレイを飛ばす。賢いのは，当たった点はその後も世界の中で動かないので，ヒット位置を記録しておき，毎フレーム，ロボットのローカル座標系へ再投影できる点だ。毎フレームは少数のレイで済み（安価），それを1秒ほどキャッシュして再利用できるので計算も軽い。難点は，点群向けの機械学習手法（PointNet）が，グリッド向けのConvNetより性能が劣ること。使える計算機構が少なかったが，実装は難しかったものの最終的にPointNetで解決し，トンネルの問題はなくなった。
 |
マーティン氏はここから学びをまとめた。アルゴリズムやモデルは重要だ。だが，組織も同じくらい重要だ。良いモデルも，人々がその存在を知り，使えなければ役に立たない。機械学習を実運用に乗せる作業の半分はしばしばツール作りであり，アーティストやデザイナーが実際にどう働くかを理解し，彼らのパイプラインにどう収まるかを見極めることだ。それこそが，レコメンドでも，クエストでも，そして最後に紹介したロボットでも，自分たちを足止めしていた要因だった。機械学習をやるなら，モデルに時間をかけるのは大いに結構。だが，一緒に働く人々が，あなたの作る道具をどう使うかも考えてほしい，そう述べて講演を締めくくった。
 |
