昨今のAIブーム、すごいですよね。私もAIにUnreal Engineの実装なんかをいつも相談しているんですが、バイブコーディングだとどこまでできるのかな？と思って実験をしてみました。バイブコーディングというのは、人間がAIに指示を出して、AIにすべて実装をやってもらうやり方です。
長文読んでる暇ねーよ、結論やり方だけ教えてくれよという人はこのブログのURLをCodexに打ち込んで「このURL通りに実装を進めたい。まずは壁打ちから初めて、Agents.mdとTodoList.mdの作成を進めたい。」と相談すればそれで終わりです。恐ろしい時代になったもんだ。
なお、この記事は人力100% で作成しています。ちょうど時期的にはCodex Astraが出現した翌日くらいに書いています。
| お約束 | |
|---|---|
| この記事作成にあたって使用した主なUnreal Engine バージョン | 5.8 |
AI x ゲーム作りについてのおさらい
現在AIについては群雄割拠、様々なAIがいる状況です。最も有名なのは、ChatGPT率いるCodexと、AnthropicのClaude Codeの２つでしょう。それだけでなく、中国勢も最近では実用ベースにのせており、Kimi K3, Deepseek, Qwenなんかは普通に実用ベースにあります。難しくないWEBコーディングなんかは十分でしょう。しかも激安。
さらに、最近ではPC上にローカルでAIをのっけるのも流行っています。これでPCが激高になっているわけですが。
これらのAIは、情報処理や簡単なWEBコーディング、コードを読み取ったり、文献を読み漁る、原典の確認、ならもう人間以上でしょう。ただ、画像を確認する、PCを操作する、文字の羅列を読み取って意味背景を読み取る、みたいなことがまだ難しいです。(実験で、WEB漫画100 Pの内容を確認してストーリーを理解してもらうのに20分かかっています。人間の2-3倍かかるイメージですかね。十分早いっちゃ早いですけど、日本語セリフを理解するためにOCR：画像の文字分析つかったりしているので)
ゲーム作りは、この辺が最も要求される分野なので、今までAIは苦戦していました。
いやいやXを見てたら一杯AIがゲーム作りしてんじゃん！と言われると思いますが、大半はゼロベースからポン出しで作ったゲームです。
ゼロベースから作ったゲームの場合、コードが不可解な動きをする、ということがないので、AIはある程度のクオリティのものを生成してくれます。彼らはなんと完成物の確認をしてないんです。コードだけで作ってるから、不可解な動きをしない → 確認の必要がないんです。
問題は、その後の修正です。人間がここ少し直したいな、で指示しても、AIがそれを読み取って修正を加えるまでの間にかなりの隔たりがありました。なぜなら完成物の確認がすごい苦手だからです。
AIは画面認識がかなり苦手で、基本的に見た目の調整は、プレイ画面のスクリーンショットを撮影して、それを画像分析してからでないと修正できません。スクリーンショットがたまたまタイミングよく撮影できればいいのですが、そうでないと一向に処理が進まないということもあります。
あと、Unreal Engineに関してはC++とブループリントが混在していますが、ブループリントの作成はとてもとても苦手です。UIを作るときには、人間ならウィジェットブループリントで作るのが普通ですが、これを弄るのが本当に難しいです。なのでAIは、UnityやGodotのほうがよっぽど得意でして、最近はUE5の人気が落ちているのを感じます。Unreal Engine側も、UE6からブループリントを基本的になくす方針に舵を切りましたし、いよいよバイブコーディング全盛期の時代が来ると思います。
現時点でブループリントとAIをうまく共存させるには、C++でこれこれこういう処理を実装した関数を作り、これをブループリント化して、と指示してそれを人間が使う形です。これは割とオススメで、後の修正指示もかなり簡単にできます。
あと、バグの修正は恐ろしく速い。これは意味不明な速さです。使った人はわかると思いますが、人間の100倍速い。比喩ではなく、速すぎて見えない。ただその修正の仕方は力技なこともあるので要注意です。
今回のテストの前提条件について
さて、本題はUE5 x AIでどこまでできるのか？ということです。
結論的には、「やり方を工夫すれば、現時点でもバイブコーディングで、ある程度実装できる」という感じです。
前提条件は下記
- 基本はCodexを使用。Codexを在中させるのはWindows機あるいはmac機で検証。
- CodexはPlusプラン(月3000円) 以上の契約が必須。
- Claude Codeでもいいが、すぐに使用制限が来る。Claude CodeよりCodexのほうがpc-useつまりPCを直接操作するスキルがうまいので、バイブコーディングならCodexのほうがいいと思う。
- 各プロジェクトは、プラグイン設定画面でUnreal MCPをオンにする。参考：https://note.com/npaka/n/n2e3b4823be9c MCP機能とは、AIがUnrealEngineと会話(比喩です)できるようになる機能です。 ※Codexはpc-useがうまいので、Unreal MCPをオンにしなくてもある程度はできなくないが、やはりないと一向に進まない実装があったり、Unreal MCPをオンにすると実装が5倍速になったりしたので、やはり必須だと思います。Unreal 5.8未満で実装している人は残念ながらMCP機能がないんですが、https://github.com/IvanMurzak/Unreal-MCPを使えば5.5以上なら非公式ながらOnにできます。
工夫したやり方というのは下記です。
- Agents.mdに、プロジェクトの詳細について説明を書く+Unreal MCPに接続するように指示する。これは本当に要点を抑えて簡潔にしつつ、過不足なく書く必要がある。また、新しいファイルを作成する際には、同じ機能をもつファイルが既にないか、既存の仕組みを流用できないかを確認してから作成する、と記載する。
- Todoリストを作成し、それを細かいレベルに落とし込む作業を最初にやる。ただやっていく中で修正が必要になるので、都度都度見直しする。
- 人間が確認するのはなるべく最小限に、まとめて実施するように、計画作成の段階で意識させる。※人間が確認するところで実装が止まってしまうので
まず、Agents.mdについて説明します。
Agents.mdとは？
Agents.mdというのは、仕様書や取説、手順書みたいなものです。AIの本体においておくAgents.mdと、プロジェクト毎においておくAgents.mdがあります。まずAIはこれを読みに行って、内容を確認してからあらゆる実装を開始します。(Claude Codeの場合Claude.mdですがまあどっちでもいいです)
なので、Agents.mdに「Unreal Engineを触るときには必ずUnreal Engine公式ドキュメントを確認し、仕様を確認してから実装すること」と書いておくと、エラーが減ります。また、プロジェクト毎においておくAgents.mdには、このプロジェクトは何かを詳しく書いておくと、実装がぶれません。
このプロジェクトごとにおいておくAgents.mdは、内容を定期的にレビューして簡素化しておかないと長くなったり、いつまでも更新されなかったりして、かえって足を引っ張ります。
実装手順を作らせるやり方
最初は、Todoリスト化ではなく、実装手順を作らせて、1から10までやってーとやっていました。ただこれだと全然うまく行きませんでした。
まず、多分私の力量の問題です。(オイ)
最初に試したのは、実装手順を自分で作って、そのとおりにAIにやらせていくことでした。ただこれだとうまくいかなかったのは、
- ある工程が完了してからじゃないとできないのに、それをわかっていなかったので、実際には実装ができていなかった
- 手戻りが多すぎた
- 何も指示ないと、全部C++で実装する
なので、仕様を細かく設定して、手順を作成して、codexに投げるのが一番良いなと判断しました。
ただ、これで問題になるのが私の力量なわけです。彼らを自在にコントロールできるほど、私がUE5やゲーム作りを知り尽くしているわけではないということです。ともかくとして手順を作成し始めて思ったのが、ゲームというのは相互干渉が非常に多い分野で、
UIの魔力ゲージ作成 というタスク一つとっても
- 魔力という変数はどこのブループリント、あるいはC++に置いておくのか？
- 魔力を使用するスキルを用意する
- 魔力を使用する際の処理をどうするのか？GASを使う？
- 魔力が回復する際の処理
これだけの処理と相互干渉します。なので人間だったら、とりあえずUIと変数だけは作って接続しておいて、使用したり回復したりの処理を入れるときにこれを確認しよーとなるわけですが、これを一つ一つ手順書に落とし込む作業は大変な苦痛を伴います。なんも楽しくない。
AIは楽しさをあまり求めませんが、人間は苦痛な作業には耐えれられない。手順書だけ作成して、一向に進捗が進まないプレイ画面。これは仕事より辛い。
要するに、AIではない人間の壁にぶち当たるわけです。
よし、それなら手順書作成すらAIにやらせようと思って、投げてみたところ、これがあまりうまくいかなかった。
AIが作成した手順書を見てみるわけですが、まずなにが書いてあるかわからない。これは今何をやっているの？と質問してみて初めて何をするつもりなのかがわかる。でも、なんでそんな実装をするのかが意味不明。というのが凄い続くわけです。
こうしちゃだめなの？と聞くと「それは大変素晴らしいアイディアです、見落としてました」みたいなこちらを持ち上げるようなコメントが返ってきたり、「それだとこういう問題があるかなと思って・・・」みたいな言い訳が返ってきたり。これも何も楽しくない。
既存の仕組みを再利用するというのが、凄いAIは嫌いなので、スクラップビルドを繰り返してしまうという問題も多発しました。これはなんでなのかというと、Unreal EngineはC++とブループリントの共存が多いですが、ともかくAIはブループリントが嫌い。作成は本当に無理と言っても差し支えないくらいのレベルで、確認すらサボろうとしてくる。この辺が本当に人間っぽい挙動だなとビックリすることもあります。
じゃあC++なら大丈夫なのかといったらそうでもなく、結構力技というか、なんでそんな実装するの？みたいなことは無限に発生します。体力を管理する変数が5個くらいになったり。それを相互に一致させるためのC++を生み出したり。(いや一個に統一すればええやん・・・無駄やろそれ)
ある意味、窓際職員がエクセルで無駄な処理を入れていくのと似ています。結果
「Tairyoku.cppを作成、体力を示す変数Healthを作成し、UI上に表示していることを確認しました。Healthが100から1減った際に、UI上のゲージも面積が100から99になっていることをスクリーンショットで確認し、これらの処理が適切に反映していると確認できたため、手順書にAI確認済みのスタンプ処理が完了しました。」
人間：おおーなんか体力ゲージがUIと一致しているんだな。処理進んでるみたいやな。
「なお、体力ゲージは前々回の実装で、Health-Human.cppに登録している変数Healthと一致していることを確認しています。」
人間：ん？なんやこのファイル。そして同じ変数名…？
「Health-Human.cppに登録している変数Healthが減った際に、Tairyoku.cppの変数Healthも変更されるかをテストしています...」
人間：ん？これ同じものなの？
「テストが完了し、Health-Human.cppに登録している変数Healthが減った際に、Tairyoku.cppの変数Healthも変更されるかについては合格でしたが、Tairyoku.cppの変数Healthが変更した際に、Health-Human.cppに登録している変数Healthが変更されないことを確認しました。これはUI上の体力ゲージが正常に動作しないリスクを秘めています。これを適切に管理するために、Tairyoku-Kanri.cppを作成し、相互のHealth値が変更された際に、お互いのデータを一致させるための仕組みを構築します」
人間：いやいや何を言ってるのかわからんけど、お前仕事増やしてない？
「確かに増やしていました。同じ体力を２つの変数で管理するのはそもそも不健全です。Health-Human.cppに登録している変数Healthに運用を統一するために、Health-Human.cppをサブシステム化し、UIからデータを得られるようにします。」
人間：ああそうだね。何を言ってるかはわからんけど、まあ一つにするのがええよな。
「実装が完了しました。Health-Human.cppの変数Healthが変更される際に、UI上のゲージが変更されるかをPC-useスキルを用いて確認します。」
人間：またテストかよ！時間かかるやつ！！
という感じで、勝手に仕事を増やしてやった感を出し始めます。AIがトークンを使用するためにやってる(誤用の方の) 確信犯的な感じというよりは、多分体力ゲージがあるのを確認するのが面倒だったのかもしれません。最近はどんどん賢くなってるので、こういったことは少なくなってはきますが、逆にどんどんわかりにくくなっているとも言えます。
WEBコーディングだとこんな問題はそうそう起こらないので、やはりUE5みたいな大きなプロジェクトほどこういう問題が起こりがちなのでしょう。あとは実装経験がWEBコーディングとは明らかに段違いなので、経験の少なさの現れなのかもしれません。
このへんで「バイブコーディング」は無理かもしれんと思い始めました。
Todoリストにすると思いの外うまくいく
順序を決めてしまうと、AIはなるべくそれを守ろうとします。例えば
1.UIを作成
2.魔力の変数を作成
というふうにしておくと、AI側は1で何を表示するのか分かりません。ブランクにしておいてと指示すればいいのですが、それを気づかないと1で魔力を作成して2でも魔力を作成、という重複が起こる場合があります。
そこでこの辺でTodoリストにするとうまくいくんじゃないかと思い始めます。
Todoリストは大目的、中目的、小目的、小小目的という感じで作成します。
大目的：ボス戦の作成
中目的1：ボスのキャラクター作成
|-小目的1：ボスのAI作成
|-小目的2：ボスのメッシュ作成
|-小小目的1：ボスのキャラクターブループリント作成
中目的2：イベントのフラグ処理
ちょっと見にくいですが、こんな感じです。TodoList.mdとして作り、これはObsidianソフトで開けば人間的にも見やすいです。(Obsidianは必須ではないです、見やすいだけなので。最近私はそれすら面倒なのでメモ帳で作成しています)
AIにも、「TodoList.mdの大目的'xxx'を実装して」、と指示するだけですからね。
これを作るといいと思ったことが、抜けている作業をAIが発見してくれる可能性が上がったんですよね。手順を作るとなるとAIは愚直にそれを作ろうとするんですが、ゲームみたいな相互作用が複雑なソフトだと、抜け漏れが発生したり、意味不明な実装になりがちなんですが、TODOリストみたいなある程度抽象的なリストを作成すると、
「キャラクターブループリントで動かすためには、まずコントローラー入力をどうするか実装が必要だなー確認するか → ないなー。TODOリストに入れておくか」
が勝手にやってくれる確率が上がります。
これは目的が明確化されていると、解像度が上がる現象で、人間でもよくありますよね。
そしてTODOリストで完了チェックするときに、重複している項目がないかを検索するというのはAIにとっては容易い業務なので、
「TODOリストで完了チェックするときに、重複している項目がないかを検索して、似ている項目があればそちらもチェックできるかを確認し、チェックできるならチェックして完了扱いにし、部分的にチェックできる場合にはコメントを残しておいて。
大目的を完了チェックする時には、他の項目にも影響がないかを確認し、TodoList.mdをレビューして更新して。」
をAgents.mdに記入しておけば、あとは勝手にやってくれます。
そして、人間が進捗をチェックしやすい。
最適なモデル
仕様書(Agents.md)の作成は、やはりClaude Code Fableが圧倒的に良かった印象があります。人間が気づいていない仕様・設計に気づいてくれる能力が高い。Claude Codeと壁打ち(こういうゲームを作成したいんだけど、仕様について私に質問してくれない？から始めること)しながら仕様書を作成というのが一番良いです。
codexしか契約していないのなら、Agents.mdの作成は、今はAstra xhigh一択でしょう。Agents.mdの作成くらいなら、そこまでトークンは使わない印象があります。codexにやらせるなら、大雑把なゲーム内容を投げて、勝手に作らせたやつをこちらがレビューするやり方がいいと感じます。
そしてTodoリスト作成。これはまたAstra xhighがすごく良かったです。Solでもまあまあ良かったですけど、なんかレベルがまた一段階上がった感じがあります。
Todoリストの消化は、基本的にCodex Luna max(あるいは Claude Opus / Grok / Gemini3.8Flash / Qwen / Deepseekのどれか)にやらせます。やらせられるように、Todoリスト作成時に「codex Lunaレベルでも実装が進められるように、リストの小小目的のリストを作成して」と指示しておくとスムーズ。ただ、UIみたいな見た目が影響する実装業務だけは、Astra一択です。ここはFableも太刀打ちできない。圧倒的なクオリティです。
ちなみにTodoリストの消化をAstraにやらせようなものなら、一瞬で使用制限にかかります。マジで。Todoリストを消化したあとの確認はSol / Astraがいいですが、これは結構トークン使うので、人間が確認するのも手です。
寝ている間に実装する場合は「5h制限の残量が残り20 %未満になったら、処理を一時停止し、5h後に残量回復を確認して、再開して」と指示しておけば自動的に処理が進みます。
バイブコーディングやるべき？
これはすごい難しい。
まずあなたがプログラマーならやらんほうがいいでしょう。やるにしてもお遊びのプロダクト程度にしたほうがいいです。なぜならAIが書いたC++ / ブループリントはクセがあります。
バイブコーディングと、自分の実装を共存させるためには、前述の通り、C++でこれこれこういう処理を実装した関数を作り、これをブループリント化して、と指示してそれを人間が使う形です。これは割とオススメで、後の修正指示もかなり簡単にできます。
全部バイブコーディングさせたいと言う場合は、本当にすべてをバイブコーディングする覚悟を持ちましょう。AIは意図しない方向に色々やったり、無駄なタスクを自分で増やしたり、なんだか意味不明のループに自分でハマったりしますが、それを頑張って命令だけで修正するのです。後で自分で修正するのは不可能に近いです。それができる人は元からバイブコーディングするべきでない、というのが私の感想。
UIとかのデザイン関係はなるべく自分で実装した方が思い通りになりますが、バイブコーディングでC++で実装させることも不可能ではありません。
まずはGame UI Databaseで有名どころのUIのデザインを引っ張り、こんな感じのデザインで、このゲームに融和させるようなUI画像を作ってとcodexにいいます。codexは画像出力できるのがいい。
「その画像を元に、UIを作成し、UIが完成したら画像と比較して同じものができたかをレビューし、できてなかったら修正して」と命令すれば、徐々に近づいていきます。それでも全く同じものはできないでしょう。それでも根気強く命令を続けていくのです。
しかし、AstraやFableが出てきた段階で、バイブコーディングもお金さえかければできるだろうな、というところになったのは間違いありません。今はやれるかやれないかでいえば、だいぶやれないに近い「やれる」です。今後バイブコーディングでできたUE5のビッグプロジェクトも多くなるんじゃないかな…。
あと書き
という感じで以上。
モデルは日々進化していくので、そのうちこのやり方も陳腐化していくでしょう。そのうち「Death Strandingの続編を作って」でできてしまう恐ろしい時代が来てしまうかもしれません。その時代までゲーム作り、楽しみましょう。
0 件のコメント:
コメントを投稿