Steam「圧倒的不評」レビューからの復活劇！リリース後にHDRP→URP移行を完遂した2か月間の歩み【GCC 2026】

登壇したヘキサドライブの山口 裕也氏

『■■ノニラヤ』は、2000年代の日本を舞台としたホラーアドベンチャーゲーム。異界に迷い込んだ子供が怪物から逃れつつ、元の世界への帰還を目指して奔走します。

使用エンジンはUnity 6で、DCCツールとしてBlenderを採用。開発は主に山口氏が1人で行っています。

なお前回イベントの「GAME CREATORS CONFERENCE ’25」においても同氏は登壇し、本作の開発事例を取り上げた講演を実施。その際に使用したスライド資料などが公開されています。

2025年11月にSteamで発売された本作ですが、リリース以降ほどなくして低評価レビューが増加していき、ついには「圧倒的不評」という結果に。

それを受けて即座に謎解きのヒント追加や戦闘面のバランス調整などに取り掛かったそうですが、システムを変更すると致命的なバグが発生する恐れがあるのに対し、不具合のチェックに労力を割いてしまうと作業時間が取れなくなるというジレンマに悩まされたそう。

そこで、自動プレイ機能を活用してチェック作業を簡略化するアプローチが取られました。

『■■ノニラヤ』が備える自動プレイ機能には以下の特徴があります。

完全自動で回す都合上、敵や謎解きギミックには干渉せず素通りしてしまうため、全ての不具合は網羅できないものの、最低限ゲームを進行できる状態に仕上げることは可能であるとして、「自動プレイが通れば修正をリリースする」と決定。

自動プレイを走らせることにより、以下に挙げるような発見が困難なバグを速やかに検出できました。

また、自動プレイから修正・デプロイまでの流れを自動化するパイプラインを、ビルドエンジニアの協力のもと開発。

修正したコードをPerforceにサブミットするとJenkinsが自動でビルドを行い、それが完了すると自動プレイに移行。全てのチェックが成功した際、最後にチェックに成功したビルドがSteamの開発用ブランチにデプロイされる仕組みとなっています。

40項目の修正を支えた自動プレイの実装

自動プレイは「記録」と「再生」のふたつの機能だけを備えたシンプルなもので、記録中か再生中かに応じてそれぞれのシングルトン（※1）が生成される実装。行動データの定義にはinterface（※2）を利用し、それぞれの行動に合わせてクラスを作成することで行動を記録しています。
※1　オブジェクト指向プログラミングにおけるクラス設計パターンのひとつ「シングルトン（Singleton）パターン」によって生成されるインスタンス。特定のクラスに対して常に1つのインスタンスのみが存在し、そのインスタンスにグローバルなアクセスを可能とする
※2　クラスやオブジェクトが持つべきフィールド、メソッドの仕様を指定するためのもの

また、自動プレイにおける移動経路やギミックの操作などを可視化・編集できるツールを作成。

こうした環境整備により不具合検出の地盤を固められたことで、強気にバージョンアップを重ねられたとのこと。40個の修正をリリースし、Steamでの評価も「圧倒的不評」から「賛否両論」まで向上したそうです。

しかし自動プレイによるチェックも完璧ではなく、ゲーム進行に影響しない見た目や効果音などの不具合や、ゲームオーバー後の画面遷移の不具合などは発見できません。これらを網羅できる不具合検出の仕組み作りを、山口氏は今後の課題に挙げていました。

本作では当初レンダリングパイプラインとしてHDRPを採用していました。社内チェックの際は動作が安定していたそうですが、リリース後に「ゲームが動かない」という声が寄せられたため、モバイルタイトルを含めて幅広い採用事例のあるURPへ移行を決めました。

移行期間はおよそ2か月。主な作業内容は以下の通り。

AIエージェントを活用した、URPへのシェーディングモデルの移行

URPへの移行に伴い、以下5種類のシェーディングモデルを新規作成する必要がありました。

当初はHLSLで直接コードを記述し、既存の処理を拡張するという手法を取っていましたが、カスタムライティングは初経験だったため、各モデルについて調べて理解を深めながらコーディングする必要がありました。

タイトなスケジュールの中、この方式では作業進度に限界を感じたそうです。

そこで、AIエージェントの「Google Antigravity」（以下、Antigravity）を導入。テキストチャットで「このシェーディングモデルに基づいたカスタムライティングのコードと、LUTを生成するツールを作成して」と依頼するだけで、簡単なツールであればほぼ完璧に作成してくれたといい、作業ペースが大幅に向上したとのこと。

数あるAIエージェントの中からAntigravityを選んだ理由は「クレジット消費と生成結果の費用対効果が良いと感じたから」と山口氏。また、Antigravityで利用可能なAIモデルには「Google Gemini」シリーズのうち高速・安価な「Flash」と上位版の「Pro」が含まれていますが、Flashだけでも十分な成果が得られたといいます。

指示を送るためには技術的素養が必要となるものの、それさえ備えていれば数分でツールを作成可能。これにより想定より早く移行作業を完了できたそうです。

ベイク方式への移行で発生した問題とAIの活躍

URPのライティングシステムには、Deferred+においてカメラ1つにつき1フレームで描画できる光源が上限256個であることや、Point Lightがサイズを持たない、Specularをオフにできないといったさまざまな制限があり、これらも移行作業の壁となりました。

そこで、ライティングの計算を事前に行うベイク方式へ移行を決めました。

しかし本作のマップは他のステージのメッシュが同じ場所に重複して配置されているため、通常の手順でベイクすると意図しない場所に影が発生してしまいます。

これを解消するため、Unity公式のガイドに記載されていた以下の手順でベイクを行いました。

大量のメッシュからライトマップが設定されたものを探す作業や、ベイク時にシーン内のオブジェクトとライトの表示を切り替える作業を効率化するため、ここでもAIを用いて補助ツールを作成しました。

OSSをAIで改造。厳しいスケジュール内でのURP移行を実現した技術

ベイク関連の作業は効率化できたものの、ベイク時間そのものはどうしても短縮できなかったそう。そのため、ベイク進行中はポストプロセスと特殊描画の移行作業に充てたといいます。

膨大な数をすべてURPで作り直すのは難しいと判断し、移行作業は以下に挙げるOSSを主体として進行しました。

ただし、これらのOSSの機能は完全にHDRPと同一ではないため、AIを活用してOSSの内部構造を組み替え、HDRPでの処理と近い見た目を実現できるように修正しました。

一方、Shader Graphで組んでいた処理を移行する際、Deferred+のパス構成など技術的な詳細を把握しないままAIに指示した結果、想定通りにいかなかったケースも。最終的に手書きでシェーダーを記述することになったそうです。

URPだから軽いとは限らない。URP移行のまとめと教訓

ベイク処理を終え、URPへの移行が順調に進んでいた最中、描画負荷も無事に軽減できたと思っていたところ、なぜか膨大な処理負荷がかかり数fpsしか出せていないことが発覚。

原因を確認すると、ベイク用に配置していたライトがシーンの追加ロード時にリアルタイムライトに切り替わっていたため、ロード時に実行されるスクリプトを追加することで対処しました。

移行処理を経てゲームの実行速度は約1.5倍に向上。ただし、山口氏はこの要因として「URPへの移行より、影描画の処理を大幅に削減したことの恩恵が大きい」と述べ、URPにしたから高速化するわけではないという見解を示しました。

HDRPの代替OSSを調査した結果、Waterシステムの代わりとなる理想的なOSSを探し出せなかったため、AIで自作することにしたと山口氏。

この事例をもとに、バイブコーディングで効果的にR&Dを進めるために押さえておくべきポイントが紹介されました。

なお、講演で紹介された河川システムはGitHubで公開されています。

【コツ①】いきなり作り始めない

低品質なコードが生成されるのを防ぐためには、いきなりコーディングに着手せず、まずは自然言語でシステムの全体像を作り込ませることが重要です。ある程度構成が固まったら、新規チャットで順番に実装を指示していきます。

AIが実装意図を正しく理解しているか確認するために、先に実装プランを語らせて事前レビューを行うことも有効です。

【コツ②】一度あたりのコード生成量は、できるだけ少なくする

一度に長いコードを出力させるとレビューの負担が増大するため、少量のコードに分割して記述させて順番にレビューすることが推奨されます。

また、AIが出力するコードにはエラーが含まれていたり、そもそも正常に動作しないコードを渡されたりすることがあるため、レビュー前に動作確認を行うのが良いとのこと。

【コツ③】うまくいったら即コミット

コードが想定通りに動作してくれたとしても、次の指示を経て不具合が発生する恐れがあります。レビューが通ったコードは、すぐにロールバックできるようこまめにコミットしておくことが大切です。

【コツ④】必ず具体名で指示する

実装過程において仮名称で呼んでいたコンポーネントなどの具体的な名前が決まったら、以降は必ずその名称で指示することでAIの混乱を防止できます。

【コツ⑤】機能追加とチェックは細かく

コツ②やコツ③と同様に、機能追加の指示とチェックはできるだけ細かく行うことで成功率を高めることができます。

【コツ⑥】AIと一緒に悩む

研究開発では思うように結果を出せないこともしばしば。山口氏の場合、水面に生じる波の効果がうまく実装できず、AIと壁打ちをしながら試行錯誤を繰り返したそうです。

アイデアを練る中で、偶然「川底の地形を要因とする水流の変化によって波を発生させると上手くいくのでは？」と閃いたことで、見事理想の波を生み出すことに成功したのだとか。

こうして作業すること3週間、波のシミュレーションを満足できるクオリティに仕上げることができました。

一方、このシミュレーションは100×100mの広域で動作させることを想定しているため、次は処理負荷の軽減に取り掛かりました。

まずは不要な計算や変数の削除から最適化を進めていたところ、シミュレーションのフローが想定していたものと異なることが発覚。

本来は障害物の処理と水流のベイクを初期化時のみ行う予定だったはずが毎フレーム実行する仕組みになっており、処理負荷が嵩む要因となっていました。

しかし「ここで焦って雑な修正指示を出しても何も変わらない」と山口氏。問題のある処理の名称と対処方法を具体的に指示することで解決したそうです。

まとめとして山口氏は「AIとR&Dは相性がよく、専門知識がなくてもアイディアだけで楽しく開発できる」としたうえで、「AIはまだ万能ではないので、『問題を起きにくくする』『起きたとしても小規模に抑える』『事前レビューやコード生成量の最小化などによって問題を発見しやすくする』といったコントロールが必要となる」と述べました。

現状はAIが生成したコードの問題点を発見できるだけのコードレビュー力とデバッグ力が必須としつつも、将来的にAIの性能が向上すればアイデアをすぐにゲームにできる時代が来るのではないかと期待を寄せて講演を締めくくりました。