スクエニのゲームデザイナーが生成AIでアクションRPGを試作|コードを書かずにUnity開発できた理由【CEDEC2026】
本記事にはアフィリエイト広告(Amazon・楽天市場等)のリンクが含まれています。
コードを書かずにUnity未経験から開発できた理由
ゲームの企画を思いついても、プログラミングの知識がなければ実際に動くものへ形にするのは難しいものです。文章や企画書だけでは、操作した時の手触りや面白さを人に伝えにくいという壁もあります。
スクウェア・エニックスのゲームデザイナー、遠矢司氏はCEDEC2026で、この壁を生成AIで乗り越えた事例を紹介しました。自身はコードを一行も書かず、ChatGPTやClaudeなどにコードを生成させながら、Unity未経験の状態からアクションRPG風のプロトタイプを完成させています。
ただし、短い指示を入力するだけでAIがゲームを自動的に完成させたわけではありません。AIが間違った実装を加えたり、同じ回答を繰り返したり、古いUnityの情報を提示したりする問題も起きており、そこにどう対処したかが今回の講演の核心です。
目次
要点まず何が起きたか
スクウェア・エニックスのゲームデザイナー、遠矢司氏がCEDEC2026(2026年7月24日)で、生成AIを使い、自身は一行もコードを書かずにUnity製のアクションRPG風プロトタイプを制作した事例を発表しました。ChatGPTやClaudeなどにコードを生成させ、Unity未経験の状態からキャラクター・ステージ・バトル・BGMを備えたプレイ可能なデモへ仕上げています。
経緯CEDEC2026でスクウェア・エニックスのゲームデザイナーが発表
今回の事例は、2026年7月22日から24日にかけてパシフィコ横浜ノースで開催されたゲーム開発者向けカンファレンス「CEDEC2026」で発表されました。
講演タイトルは「ゲームデザイナーによる生成AIを活用したゼロからのゲームプロトタイピング」です。登壇したのは、スクウェア・エニックスのAI&エンジン開発ディビジョンに所属するゲームデザイナー、遠矢司氏で、7月24日に行われています。
遠矢氏は、家庭用ゲームのゲームデザイナー・ディレクターとして複数のRPGやアクションRPG開発に携わった後にスクウェア・エニックスへ入社し、『ファイナルファンタジーXV』『ファイナルファンタジーVII リメイク』『ハーヴェステラ』などの開発に従事してきた人物です。共同著書に『FINAL FANTASY XVの人工知能』があります。ゲーム制作の経験は豊富な一方、今回使用したUnityについては未経験だったとされています。
そこで生成AIへ相談しながら開発環境を構築し、アクションRPG風のゲームデモを完成させました。これは製品として販売する完成版ではなく、企画やゲームシステムを検証するためのプロトタイプです。文章や企画書だけでは操作感や面白さを共有しにくい開発初期の段階で、企画を考えたゲームデザイナー自身がプレイ可能なデモを用意できれば、チーム内の相談や仕様検討を早められるというのが、今回の取り組みの狙いです。
内訳使用した生成AIツールの顔ぶれ
ゲームデモの制作には、単一の生成AIではなく複数のサービスが用途ごとに使い分けられました。
| 生成AIツール | 今回の用途 |
|---|---|
| ChatGPT・Gemini・Copilot・Claude | チャット形式で仕様の相談、アイデア整理、コードの生成を担当 |
| Codex・Claude Code(VS Code上) | Unity側の実装作業でコードを生成・修正 |
| Tripo・Meshy・TRELLIS v2 | キャラクターなどの3Dモデルを画像から生成 |
| Suno AI | BGMや効果音を生成 |
遠矢氏自身はコードを直接書かず、必要な機能や発生している問題を自然言語でAIへ伝え、生成されたコードをUnityへ反映する形で開発を進めました。最初のゲームエンジン選びについてもAIへ相談し、ノートPCでも動かしやすいことなどを理由にUnityを採用したといいます。開発環境の構築、企画の整理、タスクの分解、素材の生成、ゲームエンジンへの実装、完成度を高める調整まで、幅広い工程に生成AIが取り入れられた事例です。
前提AIを無条件に信じると開発が止まる
生成AIを使えば順調にゲームが完成するようにも見えますが、実際の制作では数多くのトラブルが発生しました。指示していない処理を勝手に追加したり、同じやり取りを繰り返して先へ進めなくなったり、使用しているUnityのバージョンと一致しない古い情報を提示したりすることがあったといいます。
そこで遠矢氏は、AIを無条件に信用しないことを前提に、いくつかの作業ルールを整えました。
長い指示を一度だけ出すより、作業を小さく分けて一つずつ確認するほうが安定しやすい、というのがこの方法から見えてくる傾向です。生成AIをゲーム開発で使う場合、プロンプトを書く技術だけでなく、仕様管理や進捗管理も重要になります。
整理バトルシステムの仕様はMarkdownで先に固める
今回のゲームデモには、盾の破壊や背面攻撃といった、アクションRPGらしいバトルシステムも実装されています。複数の条件が絡むこうしたシステムをいきなりAIに作らせると、実装漏れや仕様の食い違いが起きやすくなります。
そこで、バトルのルールを仕様書としてMarkdown形式にまとめ、AIと内容を確認してから実装を始めました。さらに作業を細かなタスクへ分解し、一つずつ完成させることで、大規模な手戻りを減らしたといいます。
ゲームデザイナーには、プログラムを直接書く能力とは別に、遊びのルールを具体的な条件へ落とし込む能力があります。たとえば「背後から攻撃した場合はダメージを増やす」といったアイデアを、発動条件・判定方法・例外処理まで整理できれば、生成AIへ実装を依頼しやすくなります。その意味で、生成AIはゲームデザイナーの設計能力を、プレイ可能な形へ変換する役割を担っています。
素材3Dモデル生成は部位ごとに画像を分けると精度が上がる
キャラクターなどの3Dモデル制作では、Tripo・Meshy・TRELLIS v2という3種類の3D生成AIが比較されました。
全身が映った1枚の画像をそのまま渡すと、顔や装備品といった細部の再現性が下がる場合がありました。そこで、顔や装備品などを部位ごとの画像へ分けて生成AIに渡したところ、元画像に近い3Dモデルを作りやすくなったといいます。リギングについても、コートを脱がせたAポーズの画像を用意することで安定しました。
生成AIへ渡す情報は、多ければ多いほど良いとは限りません。ひとつの画像にキャラクター・衣装・武器・装飾品など大量の情報が含まれていると、AIがどの部分を優先すべきか判断しにくくなります。対象を分割し、一度に処理する情報量を減らすことが、生成結果の改善につながりました。
一方で、同じ画像を使用しても毎回同じモデルが完成するわけではなく、狙った造形をパラメーターで完全に制御する機能も不足していました。プロトタイプ用の素材を短時間で作る用途には便利ですが、製品版で使うキャラクターを安定して量産するには、人間による修正や選別が必要です。
修正画像生成では変更したくない部分も指定する
2D画像の修正でも、生成AI特有の問題が確認されています。一度の指示に複数の変更を詰め込むと、すべての条件を正しく反映できる確率が下がりました。反対に、修正を一つずつ行うと、変更する必要のない場所まで少しずつ変化してしまうことがあったといいます。
そこで、プロンプトそのものをAIに考えさせ、変更する部分だけでなく、変更してはいけない部分も明記する方法が使われました。日本語より英語のプロンプトの方が成功しやすい傾向も確認され、コードボックスに英語の指示文、チャット欄に日本語訳をあわせて出力させる運用に落ち着いたとされています。
生成AIを使った画像制作では、「何を変えるか」だけを伝えるのでは不十分です。キャラクターの顔は維持する、カメラの角度は変えない、背景は修正しないといった保持条件を具体的に伝える必要があります。
効率ゲーム素材だけでなくUnity用ツールもAIに作らせた
今回の取り組みで特に興味深いのは、AIにゲームの素材を作らせるだけでなく、Unity上の作業を自動化するツールまで作らせた点です。
ステージの大まかな形を作るグレーボックス工程では、それぞれのボックスにID・サイズ・座標を設定し、ボタン一つで複数のボックスをUnity上へ自動配置するツールを生成AIに開発させました。寸法と角度を入力するとカーブした階段を自動生成する仕組みも作られています。
同じ作業を何度も繰り返す場合、完成した結果だけをAIへ作らせるより、結果を作るためのツール自体を開発させたほうが効率的です。ステージの配置を修正するたびにAIへ新しいコードを書かせるのではなく、ゲームデザイナー自身が数値を変更できるツールを用意すれば、その後の試行錯誤を速められます。
事例画像を見せなければ解決できなかったバグもある
水面の反射に関するバグでは、AIが何度もパラメーターや設定の変更を提案したものの、問題を解決できませんでした。そこで、実際に発生している状態を画像付きで詳しく説明したところ、AIが設定ではなくプログラム側の問題だと判断し、コードを修正することで解決に至ったといいます。
この事例は、エラーメッセージだけではAIが正しい原因へたどり着けない場合があることを示しています。画面の表示がおかしい、エフェクトの位置がずれている、キャラクターの動きが不自然といった視覚的な問題では、スクリーンショットや動画をあわせて渡すことが有効です。ただし、AIが提示する修正案が常に正しいとは限らず、修正後に別の機能が壊れていないかを人間が実際に動かして確認する工程は残ります。
位置今回の方法は単純なバイブコーディングではない
今回の取り組みは、アイデアを入力して制作をすべてAIへ任せる、いわゆるバイブコーディングとは異なる方法だと位置付けられています。
遠矢氏はゲームの企画を考え、必要な機能を整理し、AIへ渡すタスクを分解しています。生成されたものが正しく動いているかも確認し、問題があれば原因を探して修正方法を提案しました。コードを直接入力していなくても、何も考えずにゲームが完成したわけではありません。
むしろ、AIが生成したコードをそのまま信用できないからこそ、人間側に明確な完成イメージが必要になります。何が正しい動作なのかを人間が理解していなければ、AIが間違った実装を出しても気付けません。
現実プログラミング未経験でもゲームを作れるのか
今回の事例を見る限り、プログラミング経験がなくても、生成AIを利用してプレイ可能なゲームデモを作れる範囲は広がっています。ただし、誰でも短時間で商用ゲームを完成させられるという意味ではありません。
プロトタイプの制作でも、ゲームの仕様を言葉にする能力、問題の起きている場所を見つける能力、AIの回答を疑う姿勢、複雑な作業を小さく分ける能力が必要です。ゲームとして面白いか、操作感が適切か、難易度が狙い通りかといった判断も、生成AIだけでは完結しません。
製品として販売する段階では、パフォーマンスの最適化、幅広いPC環境での動作確認、セーブデータの安全性、ネットワーク処理、権利関係の確認など、プロトタイプ以上に厳しい品質管理が求められます。生成AIによって下がるのは、最初のプレイ可能な形を作るまでのハードルです。完成品として発売できる品質へ仕上げる難しさまで、すべてがなくなるわけではありません。
環境AIを使うゲーム開発にどれだけのPC性能が必要か
今回のゲームデモでは、ノートPCでも作業しやすいことがUnityを選ぶ理由の一つになりました。ChatGPTやClaudeなど、クラウド上で処理される生成AIを利用するだけなら、必ずしも高性能なGPUを搭載したPCは必要ありません。
一方で、Unity上で3Dステージを表示しながら、コードエディター、複数のAIサービス、画像編集ツールを同時に使用する場合、PC性能が低いと操作が重くなる可能性があります。Unity公式のシステム要件では、Unity Editorを動かすために最低8GBのメモリが必要とされています。実際の動作速度や描画品質は、制作するプロジェクトの複雑さによって変わります。
実用面では、軽い2Dゲームや小規模な3Dプロトタイプならメモリ16GBでも始められますが、多数のブラウザタブを開きながらUnityや画像生成ツールを併用するなら、32GBあるほうが余裕を持ちやすくなります。高性能なGPUは、ローカル環境で画像生成AIを動かす場合や、高品質な3Dグラフィックスを扱う場合に重要度が増します。まずは手元のPCで小規模なデモを作り、処理の重さを確認してから必要な性能を判断するのが現実的です。
分業生成AIとゲームデザイナーの役割はどう変わるか
生成AIがコードを書けるようになると、ゲームデザイナーとプログラマーの境界はこれまでより曖昧になります。ゲームデザイナーが自分のアイデアを動くデモへ変えられれば、プログラマーへ実装を依頼する前に、操作感やゲームルールを検証できます。プログラマー側も、企画段階の曖昧な説明だけでなく、実際に動くデモを確認しながら本番用の設計を進められるようになります。
- 仕様が明確な条件をコードへ落とし込む作業
- 3Dモデルや音楽といった素材のたたき台づくり
- 同じ作業を繰り返すツール自体の開発
- 遊びのルールを条件や例外まで具体化する設計
- AIの回答が正しいかどうかを見極める検証
- 操作感や面白さといった感覚的な評価
コードを書く作業の一部がAIへ移っても、ゲーム開発そのものが簡単になるわけではありません。自分でコードを書けるかどうかだけでなく、AIが作ったコードや素材をどう管理し、ゲームとして成立させるかが重要になります。
FAQよくある質問
総括まとめ|コードを書かないアクションRPG制作から見えたこと
スクウェア・エニックスのゲームデザイナーである遠矢司氏は、ChatGPT・Claude・Codex・Claude Codeなどの生成AIを活用し、コードを直接書かずにアクションRPG風のプロトタイプを制作しました。Unityの導入からコード生成、3Dモデル、BGM、バトルシステム、ステージ制作の自動化まで、幅広い工程で生成AIが使われています。
一方で、AIが指示と異なる実装を加える、古いUnityの情報を提示する、同じ提案を繰り返すといった問題も発生しました。完成まで進められた理由はAIの性能だけではなく、タスクへ番号を付け、仕様をMarkdownで整理し、変更範囲を限定し、生成結果を一つずつ確認するという、人間側の管理があったからです。
今回の事例が示すのは、生成AIがゲーム開発者を完全に置き換える未来ではなく、プログラミングを専門としないゲームデザイナーでも、自分のアイデアをプレイ可能な形へ変えられる範囲が広がっているという現実です。面白さを設計し、正しい完成形を判断する役割は、引き続き人間側に残ります。


