
ゲーム組み込みAI普及の展望(~2025)
AIはどうしても超高性能モデルに目が行きがちですが、巨大化したAIモデルは需要・性能の両面ですでに頭打ちが見えており、これからは組み込みの(デバイス上で動く)、10億~30億パラメータ程度の軽量AIが大きく活躍することになるのではないかと考えられます。
ゲームにおけるAIの利用としては、現在はチャットボットとしての利用や、画像などのシンプルなアセットの生成にとどまっていますが、組み込みのAIが主流になれば、マップ生成や編集、プレイヤーの好みに応じたり場所に応じたモデルバリエーションの生成、アニメーション/モーションの生成や補間、状況に応じたミニクエストやキャラクターのセリフの補完、思考ルーチンのバックエンドといった用途が出てきます。
この記事では、ここ2年の流れをおさらいしつつ、組み込みAIの現在地がどうなっているのか、次に何が起きるか、少しマニアックに考察します。
縮小化の先陣を切ったマイクロソフト
AIには1~2年周期で、一種の技術スタイルの流行り廃りがあり(ファッションや音楽と同じかもしれません)同じ専門用語でも、その年代によって全く意味が違ってくることがあります。
2023年初頭に、マイクロソフトから現在の流れにとって重要な論文/コードが2つ出ています。まずひとつは、「3歳児向けの教科書だけで訓練したモデルは、極小のパラメータ数であっても意味の通った文章を出力できるようになる」というものでした。
Transformerのようなアテンション機構を持ったモデルの性能が伸びた理由として、各アテンションヘッドがそれぞれ小さなチューリングマシンとしての機能を持つことで * 、超非効率な、けれど極めて汎用性が高い自動プログラミング機構としてAIを訓練/利用できるという点があります。
*「コピペする」だけの機能を持つインダクションヘッド(これがあるから初見の固有名詞を使った文章が書ける)の研究が有名。
一方で、データの「複雑さ」がそのまま必要になるパラメータ数に直結してしまうという弱点もあります。経験的に、小説のような複雑なデータが入っていると訓練時のloss(入力されたデータとモデル出力の差異)が跳ね上がり、githubのコードのような単純でパターン化しやすいデータが入っているとlossが大きく下がることは知られていました。


もうひとつはGuidanceで、短い定型文の入力とモデルの出力を繰り返すことで、jsonフォーマットのような一定のフォーマットに固定した出力を行うものです。これはもともと、AI出力の文字数を減らすことでAPIコールの料金を削減し、高速化も期待できるという触れ込みでした。
ゲーム内のキャラクターの状態をAIで出力したいというような時、普通にやっていたのではこのような「流暢な」出力になってしまいます。
私は今竹林の中で森林浴をしていて、とても幸せ!これから駅に戻って家に帰ろうと思う。
こうした出力は見た目はよくても、セマンティック(意味)を取り出すのが大変難しく、ソフトウェアの一部として組み込むには極めて不向きになってしまいます。
そこで、jsonフォーマットという縛りを加えて出力させます。
{
"名前": "トマテ",
"現在地": "竹林",
"doing": "森林浴",
"気持ち": "happy",
"タスク": ["駅に戻る","家に帰る"]
}
人間にとってはとてつもなく退屈でつまらなくなってしまいましたが、ソフトウェアに組み込む上では断然有利になります。また、jsonフォーマットという縛りを加えることで、出力するデータの複雑性が一気に下がり、AIにとっても有利です。
なぜ組み込みなのか?
もともとマイクロソフトは、CopilotやBingサーチのAIでは(恐らくAzureクラウドサービス上の)OpenAIのライセンスモデルを利用していました。が、現在では下記するPhi-3など組み込み可能な軽量AIへの急速な置き換えを進めているようです。
これには2つ理由があって、一つは単純かつ重大なコストの問題で、基本的なタスクに関しては巨大モデルはオーバーキルだし、半無料で提供され、大勢が毎秒毎秒機能をコールするクラウドサービスのスケールでは、そもそもリクエストに対応可能なだけのGPUや、場合によっては電力を用意するのが難しくなってきます。
もうひとつはレイテンシーの問題で、ソフトウェアのいち部分としてAIを組み込むのであれば、常にネットワーク越しのAPIコールで数秒から10数秒待たされていては成り立ちません。
レイテンシーに関しては、APIでは必ずしもダメということは無く、どちらかというとモデルサイズの問題(巨大なモデルでは低レイテンシーは実質的に不可能)になってきます。たとえばOpenAIのモデルでも、GPT-4、GPT-4-Turbo、GPT-4oと、有効パラメータ数は公開されていないものの、明らかに減っていっています。これはコストだけでなく低レイテンシーを意識したものと考えることができます(グーグルによるGemini Flashなどの軽量モデルも同様です)。
蒸留(distillation)
上位のAIモデルを下位の(小さな)AIモデルに「蒸留」するという概念は、かなり昔からあったものですが、少し前まではモデルの出力と入力を直接繋げて訓練するようなやり方をして「蒸留」と呼んでいました。
AIの潜在的性能は、常にデータセットの質と量によって縛られてしまいます。
Transformerのようなアテンションベースのモデルが本質的に自動プログラムされたチューリングマシンであるとすれば、手続き型の(つまり、普通の)プログラムにできてAIにできないことはないはずだし、逆にAIにできて手続き型のプログラムにできないことは無いはずです。AIを使うアドバンテージは、人間がプログラムとしてデザインするには複雑すぎるデータを扱えることにあります。
ゲームやCGで定番となっているプロシージャル(「手続き的」という意味)なコンテンツの生成と、AIで言うジェネレーティブの間には、実際のところ、人間が生成パターンを逐次デザインするのか、データからパターンを自動で導出させるのかという違いしかありません。
一方、基本的な算数、ロジックや、乱数生成といった普通のプログラムなら簡単にできるようなことが、AIにとってはとてつもない難易度になってしまいます(乱数生成に関しては確率的モデルである以上、克服は難しいかもしれません)。というのも、例えば四則演算や乱数生成のテキストデータが十分に多く(100GB単位で)存在するわけではないからです*。
*わかりやすいところでは、最近の動画モデルにおいては、Unreal Engineなどでレンダリングした、微妙に視点や内容の違う大量の動画データを使ってデータを補完することが普通になっています。
そこで、既製品の高性能なモデルをひたすらコールし、その出力をAIに流し込んで更に出力……というような過程を繰り返すことで、合成(synthetic)データを作ってスペックを補完したり、上位モデルにしかできないことを下位モデルでもできるようにするという考え方が生まれます。これが今の世代の蒸留です。
マイクロソフトによる実践
マイクロソフトが発表したPhi-3は、そうとはっきり書いてあるわけではありませんが、明らかに既製品の(巨大な)言語モデルの出力を使って蒸留したオープンソースモデルです。
誤解を恐れずに言えば、ある意味で縮小版のコピーモデル(オーディオで言うベリンガーのような、回路をコピーして廉価化したもの)と言うこともできるかもしれません。
しかし、Phi-3 Miniはわずか38億パラメータにも関わらず、基本的な(例えば、簡単な数学や、入力された自然文をjsonフォーマットで再出力するというような)タスクであれば数百億パラメータクラスのモデルと比べても、おおもとの巨大モデルと比べても(!)遜色なくこなすことができます。
パターン化されたデータや、教科書的なデータセットを人工的に合成して作ることで、軽量モデルの可能性が大きく広がったのです。
トレードオフとして、あまり自然な文章を書けるようには作られておらず、たとえば小説内の人間関係を分析したり書いたりといった複雑なタスクには不向きですが、チャットボットで人を楽しませるためにある訳ではないので、その面では問題はありません。むしろ、超軽量であることによるメリットは、マイクロソフトのクラウドサービスのようなスケールでは限りなく大きくなってきます。
特に、最近アップデートされたPhi-3 Miniの新バージョンはjsonや表計算絡みのタスクに大きく注力した様子が伺えます。マイクロソフトとしては、ソフトウェア内のAI組み込みやデータの交換はjsonやcsv等のフォーマットで行いたいという考えなのかもしれません。そこに更に、今後は3DCGにおけるobjやfbxフォーマットのようなものが出てくる可能性が考えられます。
アップルとグーグルによるハードウェア側の切り崩し
組み込みが今まで進まなかったもうひとつの理由として、AIの稼働環境がNvidiaのエコシステムに縛られてきたということが挙げられます。NvidiaのGPUは必ずしもスマホなどの組み込み向きというわけではなく、かといってCPUベースやそれ以外でAIを稼働させようとすると対応するコードベースがないという壁が常に存在していました。
NvidiaはGPUというハードウェアだけでなく、CUDAという開発言語によるエコシステムを持っていて、これが開発者市場におけるNvidiaの優位性を保っています。つまり、CUDAで書かれたコードがすでに大量にあるので、ちょうどゲームの開発者がみんなCocos、Godot、Unity、Unreal Engineといったメジャーなエンジンを使うようになるのと同じく、開発のハードルが低いことがより開発のハードルを下げる(逆に、他のエコシステムはハードルが高いままで流行らない)という状況が続いてきました。
また、NvidiaのAmpere(A100など)までのアーキテクチャは16bit浮動小数演算が高速になるように設計されていて、組み込みでほぼ必須となる8bitへの正式な対応はHopper(H100など)でようやく出てきたものでした。
他方、AppleのM1はCPUでAIモデルを(ある程度小さいモデルなら)稼働させることが可能だったので、かなり早くから8bitに対応した高速なコードが公開されていました。なにしろ、CPUにとって8bitの高速演算は一番基本的な要件ともいえるものです。
アップルとグーグルはハードウェアの開発力が高く、特にアップルはハードウェア企業としての側面を強く持っています。ほとんどのAI企業は基本的にソフトウェア企業で、Nvidia等が作った既存のエコシステムに乗るしかない状況でした。それが今まで、小中規模な組み込みAIの可能性を制限してきたという部分は否めません。
総括
ソフトもハードもというアップルとグーグルが組み込み用のAIに(ようやく)乗り出したことで、スマホやタブレットでも組み込んで使えるAIのソフト・ハード両面でのエコシステムがこれから急速に整備されていくことが期待されます。
特に、今はあまり大きく取り上げられていませんが、アップルの分散AIコンピューティングの試みは面白いものです。これはBluetooth等で近くのデバイスと通信し、AIモデルの各レイヤーを分散して処理する(パイプラインパラレル?)仕組みだと思われます。多くの人が集まる都会やイベント会場、喫茶店のような場所であれば、分散してAIを処理することでより高速に、高性能なAIを組み込み稼働させることができるかもしれません。
ゲームやアプリのいち部分として、特に意識されることもなく自然にAIが組み込まれる時代は、意外と早く(1~2年で)来るのではないかと考えられます。