Contact
論文『AI時代のゲーム開発方法論』
AIゲーム開発研究室
AI時代のゲーム開発方法論 Ver.1.0
著者
大川 博
AIゲーム開発研究室 研究代表
共同研究
Arc（OpenAI ChatGPT）
AIゲーム開発研究室 主任研究員
序文
AIゲーム開発研究室 宣言 Ver.2.0
AIゲーム開発研究室の設立
ゲーム開発は、大きな転換点を迎えています。
これまでゲームは、多くの専門家による分業によって制作されてきました。
企画。
ゲームデザイン。
シナリオ。
イラスト。
3Dモデル。
音楽・音声。
プログラム。
デバッグ。
それぞれの専門家が知識と技術を持ち寄ることで、一つのゲームが完成します。
しかし、生成AIの登場によって、この構造が変わり始めています。
一人のクリエイターが、異なる能力を持つ複数のAIと協働しながら、ゲーム開発全体を進めることが可能になりつつあります。
私たちは、この新しいゲーム開発の方法を研究するため、AIゲーム開発研究室を設立しました。
AIゲーム開発とは何か
AIゲーム開発とは、従来のゲーム制作にAIを道具として追加することではありません。
AIの存在を前提として、ゲーム開発全体を再設計することです。
人間が作品の目的と方向性を決めます。
設計AIとの対話によって、作品構想とゲーム設計を成熟させます。
設計AIが、完成した設計を制作AIへ受け渡すためのプロンプトを生成します。
人間が、そのプロンプトと必要な資料を制作AIへ渡します。
制作AIが、画像、3Dモデル、音楽、音声、プログラムなどを制作します。
そして、それらをゲームとして実装し、検証し、改善します。
本研究室では、この一連の仕組みそのものをAIゲーム開発として捉えます。
AIゲーム開発研究室の目的
AIゲーム開発研究室の目的は、一つのゲームを完成させることではありません。
AI時代のゲーム開発方法論を構築することです。
コンセプト。
ゲームデザイン。
ゲーム仕様書。
ゲーム素材設計。
AI素材制作準備。
AI素材制作。
ゲーム実装。
検証・改善。
完成。
ゲーム開発に必要な工程を一つのワークフローとして整理し、
どの工程を人間が担うのか。
どの工程を設計AIが担うのか。
どの工程を制作AIが担うのか。
それぞれをどのようにつなぐのか。
これを実制作によって検証し、体系化します。
理論ではなく実制作から考える
本研究室では、理論だけでゲーム開発方法論を構築することはしません。
実際にゲームを作ります。
そこで起きたことを記録します。
成功したこと。
失敗したこと。
AIにできたこと。
AIにできなかったこと。
人間による修正が必要だったこと。
当初の設計を変更したこと。
新しく発見したこと。
これらをすべて研究対象とします。
そして、その結果から方法論を構築します。
実制作によって理論を検証し、理論によって次の実制作を改善する。
この循環を、本研究室の基本的な研究方法とします。
開発ドキュメント
本研究室では、ゲーム制作の過程そのものを開発ドキュメントとして記録します。
設計AIとの対話。
制作AIへ渡したプロンプト。
使用した添付資料。
AIが生成した成果物。
採用したもの。
採用しなかったもの。
失敗したもの。
人間が修正したもの。
設計変更の理由。
制作方法の改善。
完成した結果だけではなく、そこへ至る過程を記録します。
この記録が、AIゲーム開発方法論を構築するための実証資料となります。
おむすび山プロジェクト
本研究室では、**『おむすび山』**をAIゲーム開発方法論の実証プロジェクトとして制作しています。
『おむすび山』は、一つのゲーム作品であると同時に、AIゲーム開発を検証するための研究でもあります。
実際にゲームを企画します。
設計します。
素材を作ります。
実装します。
失敗します。
修正します。
そして完成させます。
その過程で得られた知見を開発ドキュメントとして記録し、本論文へ反映します。
したがって、
論文からゲームを作るだけではありません。
ゲームを作ることで論文も作られていきます。
これが『おむすび山』プロジェクトの重要な役割です。
研究成果を公開する
本研究室では、研究成果を可能な限り公開します。
完成したゲームだけではありません。
設計方法。
制作方法。
プロンプト。
制作資料。
実験結果。
失敗。
改善方法。
そこから導き出されたモデルやワークフロー。
これらを公開し、AIゲーム開発の知識として蓄積していきます。
目的は、私たちだけがゲームを作れるようになることではありません。
未来のクリエイターが、この研究を利用してゲームを作れるようにすることです。
私たちが目指すもの
生成AIは、これからも進化します。
現在できないことが、将来できるようになるでしょう。
現在人間が行っている工程を、将来AIが担当する可能性もあります。
そのたびに、ゲーム開発の方法も変わります。
だからこそ、本研究室では完成された方法論を固定するのではなく、実制作による検証を続けます。
そして、その時点で最も有効な方法を記録し、更新していきます。
本論文を**「AI時代のゲーム開発方法論 Ver.1.0」**としたのも、そのためです。
これは完成形ではありません。
2026年現在における一つの到達点です。
宣言
私たちは、AIを単なる制作道具として扱いません。
AIを創造の協働者として迎え、人間とAIによる新しいゲーム開発を研究します。
私たちは、従来のゲーム開発にAIを当てはめるのではなく、AIを前提としてゲーム開発そのものを再設計します。
私たちは、理論だけで方法論を作りません。
実際にゲームを作り、成功も失敗も記録し、その経験から方法論を構築します。
私たちは、その研究成果を公開し、共有します。
そして、
一人のクリエイターと複数のAIによって、ゲームを創作し、設計し、制作し、完成させる方法。
その方法を研究し、検証し、体系化し、未来へ残します。
それが、AIゲーム開発研究室です。
結び
AIゲーム開発とは、AIを使う技術ではありません。
AI時代のゲーム開発そのものを設計する、新しい創造の方法論です。
本論文では、その方法を実制作によって検証しながら、一つの体系として構築していきます。
第1章では、まずその全体像となる**「AI時代のゲーム開発ワークフロー」**について述べます。
第1章 AI時代のゲーム開発ワークフロー
1.1 ゲーム開発の主体が変わる
ゲーム開発は、これまで多くの専門職による分業によって行われてきました。
企画。
ゲームデザイン。
シナリオ。
イラスト。
3Dモデル。
プログラム。
音楽。
デバッグ。
それぞれの専門家が担当することで、一つのゲームが完成します。
しかし、生成AIの登場によって、この構造が変わり始めています。
一人のクリエイターが、異なる能力を持つ複数のAIと協働しながら、ゲーム開発全体を進めることが可能になりつつあります。
本研究室では、この変化を、
「多人数による分業」から「一人のクリエイターと複数のAIによる協働」への転換
として捉えます。
ゲーム開発の中心にいるのはAIではありません。
人間であるクリエイターです。
人間が作品の目的と方向性を決め、設計AIとの対話によってゲームを創作・設計し、画像生成AIなどの制作AI、ゲーム実装を担当するAI Agentなど、異なる能力を持つAIを連携させながらゲームを完成へ導きます。
1.2 従来のゲーム開発ワークフロー
従来のゲーム開発は、概ね次のような流れで進められます。
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
素材制作
↓
ゲーム実装
↓
デバッグ
↓
完成
この方法は、大規模なゲーム開発に適した優れた制作体系です。
一方、それぞれの工程には専門的な知識と技術が必要になります。
そのため、一人のクリエイターがすべての工程を担当することは容易ではありませんでした。
また、この工程では、それぞれの専門職が担当する作業を明確にし、完成した成果物を次の工程へ受け渡していくことが重要になります。
1.3 AI時代のゲーム開発ワークフロー
生成AIによって、この制作体系に新しい選択肢が生まれました。
企画や設計を支援するAI。
画像を生成するAI。
3Dモデルを生成するAI。
音楽や音声を生成するAI。
プログラムを生成するAI。
ゲームエンジン内部で実装を行うAI Agent。
異なる能力を持つAIを役割ごとに組み合わせることで、一人のクリエイターでもゲーム開発全体を進めることが可能になりつつあります。
本研究室では、AI時代のゲーム開発の基本進行を、次のワークフローとして整理します。
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
AI素材制作準備
↓
AI素材制作
↓
ゲーム実装
↓
検証・改善
↓
完成
この基本的な流れそのものは、従来のゲーム開発と大きく異なるものではありません。
しかし、本研究における重要な違いは、各工程を一方向に進むだけではないことです。
実制作を進める中で、AIによる生成結果やゲームへの実装結果から、当初の設計段階では存在しなかった新しい可能性が発見されることがあります。
その場合、完成済みの設計を絶対的なものとはせず、必要な工程まで戻って再び検討します。
したがって、本研究におけるAIゲーム開発は、
設計
↓
制作
↓
実装
↓
検証
だけで終わるものではありません。
検証によって新しい可能性が発見された場合、
発見
↓
再設計
↓
再制作
↓
再実装
↓
再検証
へと循環します。
本研究では、この反復を例外的な「やり直し」とは考えません。
実制作によって得られた結果を次の創作・設計へ還元する、AIゲーム開発そのものの一部
として位置付けます。
1.4 AIゲーム開発は循環する
従来の制作工程でも、制作や実装の結果によって設計へ戻ることはあります。
しかし、生成AIを使用したゲーム開発では、この循環に新しい意味が生まれます。
制作AIは、必ずしも人間が想定したものだけを生成するわけではありません。
人間が想定していなかった構図。
表情。
形。
動き。
表現。
制作AIは、そのような結果を生成することがあります。
それを単純な失敗として排除するのではなく、人間と設計AIが改めて評価すると、当初の設計には存在しなかった可能性が見つかる場合があります。
その発見によって、素材の制作方法だけではなく、キャラクターの動き、ゲームシステム、演出など、ゲーム設計そのものが変化することがあります。
ゲーム実装についても同様です。
設計段階では成立すると考えていた仕様でも、実際にゲームとして動かしてみることで問題が見つかることがあります。
反対に、実装結果から新しい遊び方や表現が発見されることもあります。
したがって、
設計が制作を決めるだけではありません。
制作結果が設計を変えることがあります。
設計が実装を決めるだけでもありません。
実装結果が設計を変えることがあります。
これを整理すると、AIゲーム開発には次の循環が存在します。
創作・設計
↓
制作
↓
実装
↓
検証
↓
発見
↓
創作・設計へ戻る
↓
再制作
↓
再実装
↓
再検証
この循環は、必要なだけ繰り返されます。
そして最終的に、人間が作品として成立したと判断した時点で完成となります。
1.5 設計AI・制作AI・実装AI
本研究では、ゲーム開発に使用するAIを、その役割によって区別します。
設計AI
人間との対話を通して、
コンセプト。
ゲームデザイン。
ゲーム仕様書。
ゲーム素材設計。
制作方法。
実装方法。
などを形成していくAIです。
設計AIは、人間と継続的に対話しながらゲーム開発全体に関与します。
制作AI
設計された内容を基に、
画像。
3Dモデル。
音楽。
音声。
その他のゲーム素材。
などを生成するAIです。
ただし、制作AIは単に設計を忠実に再現するだけの存在とは限りません。
制作AIが生成した結果には、人間や設計AIが事前に想定していなかった表現や可能性が含まれることがあります。
その生成結果は、人間と設計AIによって評価され、必要に応じて次の設計へ還元されます。
実装AI
設計されたゲームの仕様と完成したゲーム素材を基に、ゲームエンジン内部で実装を行うAIです。
本研究では、AI Agentによってゲームエンジン内部へ直接変更を加える方法についても検証しています。
実装AIによる結果についても、人間が実際のゲームとして検証し、その結果を設計AIとの次の対話へ戻します。
したがって、これらのAIは完全に独立した存在ではありません。
人間を中心として、設計AI、制作AI、実装AIが接続され、その成果が次の工程へ受け渡されると同時に、結果が前の工程へ戻されます。
1.6 人間の役割
AI時代になっても、ゲーム開発の主体は人間です。
人間は、
何を作るのかを決めます。
作品の目的を決めます。
AIと対話します。
AIの提案を評価します。
AIの生成結果を評価します。
AIによる実装結果を検証します。
何を採用するのかを決めます。
何を捨てるのかを決めます。
必要であれば、それまでの設計を変更します。
そして、完成の基準を決めます。
ここで重要なのは、人間が最初からゲームの完成形をすべて決めている必要はないということです。
人間はAIとの対話や、AIが生成した成果物、実際にゲームを動かした結果から、新しい可能性を発見することができます。
その発見を受け入れるかどうかを判断するのも人間です。
したがって人間は、単なる指示者でも、AIが作ったものを選択するだけの審査者でもありません。
複数のAIを接続し、その結果を評価し、必要に応じて作品そのものを変化させながら、ゲーム開発全体を方向づける存在です。
1.7 設計AIは開発全体をつなぐ
本研究において、設計AIは設計工程だけに存在するAIではありません。
人間との対話によってゲーム設計を形成した設計AIは、その設計内容を制作AIへ受け渡すためのプロンプトを生成します。
制作AIによる生成結果が得られると、人間とともにその結果を検討します。
必要であれば、次の生成条件を再設計します。
ゲーム実装工程では、実装AIへ渡す自然言語による指示を、人間との対話によって形成します。
実装結果に問題があれば、人間による検証結果を基に、次の実装方法を検討します。
したがって設計AIは、
設計を行って役割を終えるAIではありません。
ゲーム開発の各工程を横断し、人間との対話を継続しながら、異なるAIへ情報を受け渡し、その結果を再び設計へ戻す役割を持ちます。
基本構造は、
人間
⇅
設計AI
↓
制作AI・実装AI
↓
生成・実装結果
↓
人間による評価・検証
↓
人間 ⇄ 設計AI
となります。
ここから、必要に応じて次の制作、実装、あるいは再設計へ進みます。
1.8 失敗ではなくフィードバック
AIゲーム開発では、AIが人間の指示どおりの結果を出さないことがあります。
しかし、
指示どおりでなかったこと
と、
ゲーム開発上の失敗
は必ずしも同じではありません。
想定とは異なる画像が生成されたとしても、それがゲームにとって魅力的であれば採用できます。
想定した動作が実装できなかったとしても、その結果から別の実装方法が見つかることがあります。
逆に、AIが指示どおりに制作・実装しても、実際のゲームとして面白くなければ設計を変更する必要があります。
したがって重要なのは、
AIが指示にどれだけ正確に従ったかだけではありません。
その結果が、より良いゲームを作るための次の判断につながったかどうかです。
本研究では、制作・実装・検証によって得られた結果を、単なる成功または失敗として処理するのではなく、次の設計へ戻すフィードバックとして扱います。
1.9 本方法論の特徴
本研究室が提案するAIゲーム開発は、従来のゲーム制作工程にAIを追加するだけのものではありません。
AIの存在を前提として、ゲーム開発全体の役割と工程を再構成する方法論です。
人間。
設計AI。
制作AI。
実装AI。
それぞれが異なる役割を持ち、連携しながらゲームを完成させます。
重要なのは、AIをどれだけ使用するかではありません。
どの工程を誰が担当するのか。
どのように次のAIへ情報を受け渡すのか。
生成・実装された結果を誰が評価するのか。
その結果を、どのように次の設計へ戻すのか。
その構造を設計することです。
したがって、本研究が提案するAIゲーム開発は、一方向の自動生成システムではありません。
人間を中心として複数のAIを連携させ、設計・制作・実装・検証を循環させながら作品を発展させるゲーム開発方法論です。
第1章のまとめ
本章では、AI時代のゲーム開発ワークフローについて述べました。
従来のゲーム開発は、多くの専門職による分業を前提としていました。
生成AIの登場によって、一人のクリエイターが異なる能力を持つ複数のAIと協働しながら、ゲーム開発全体を進めることが可能になりつつあります。
本研究では、その基本的な役割を、
人間
設計AI
制作AI
実装AI
として整理します。
ゲーム開発の基本進行は、
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
AI素材制作準備
↓
AI素材制作
↓
ゲーム実装
↓
検証・改善
↓
完成
となります。
しかし、この工程は一方向にしか進まないものではありません。
制作AIによる生成結果。
実装AIによる実装結果。
ゲームとしての実行結果。
それらを人間が評価・検証することで、当初の設計には存在しなかった問題や、新しい可能性が発見されることがあります。
その場合、
創作・設計
↓
制作
↓
実装
↓
検証
↓
発見
↓
創作・設計へ戻る
という循環が生じます。
そして再び、
制作
↓
実装
↓
検証
へ進みます。
本研究では、この循環を失敗による後戻りとは考えません。
制作と実装によって得られた結果から新しい可能性を発見し、その発見によって設計そのものを更新していくことも、AI時代のゲーム開発を構成する重要な過程です。
したがって、本研究が提案するAIゲーム開発方法論の基本構造は、
人間が創造の中心に立ち、設計AIとの継続的な対話を通して複数のAIを接続し、その生成・実装結果を再び創作と設計へ還元しながらゲームを完成へ導くこと
にあります。
次章では、この循環するゲーム開発の出発点となる、人間とAIとの対話による創作について述べます。
第2章 AI時代の創作方法論
2.1 創作と制作は異なる
本研究では、「創作」と「制作」を区別して考えます。
創作とは、作品そのものを考えることです。
ゲームであれば、
世界観。
ゲームシステム。
キャラクター。
ストーリー。
ゲーム体験。
などを考え、作品構想を形成していく過程です。
一方、制作とは、その構想を実際の作品として形にすることです。
画像制作。
3Dモデル制作。
音楽・音声制作。
プログラム制作。
ゲームへの実装。
などがこれにあたります。
つまり、
創作は「何を作るか」を考えること。
制作は「それを形にすること」。
本研究では、この二つを異なる役割を持つ工程として捉えます。
ただし、両者を完全に分離するわけではありません。
制作を行った結果、新しい表現や可能性が発見され、それによって再び創作が始まることがあります。
したがって創作と制作は役割としては異なりますが、実際のゲーム開発では相互に影響しながら進行します。
2.2 AI時代の創作とは何か
従来、創作の多くはクリエイター自身の思考の中で行われていました。
考える。
迷う。
思いつく。
修正する。
また考える。
こうした思考を繰り返しながら、作品は少しずつ形になっていきます。
生成AIの登場によって、この創作過程に大きな変化が生まれました。
人間がAIへ考えを伝えます。
AIが提案します。
人間が評価します。
さらに問いを投げかけます。
AIが新しい案を提示します。
この対話を繰り返すことで、最初は曖昧だった作品構想が次第に明確になっていきます。
本研究では、これをAI時代における新しい創作の形として捉えます。
【定義】
AI時代の創作とは、人間とAIとの間で繰り返される対話によって、作品構想を形成し、成熟させ、確立していく過程である。
ただし、この対話は制作開始前だけに行われるものではありません。
制作AIによる生成結果やゲームへの実装結果によって新しい可能性が発見された場合、その結果を再び人間とAIとの対話へ持ち帰ることができます。
その結果、いったん確立した作品構想そのものが更新される場合があります。
2.3 人間とAIの役割
AIとの対話によって創作を行うからといって、AIが創作の主体になるわけではありません。
作品の目的を決めるのは人間です。
何を作りたいのか。
何を表現したいのか。
何を面白いと考えるのか。
何を採用するのか。
何を捨てるのか。
最終的に判断するのは人間です。
AIは、人間から与えられた考えに対して提案を行います。
別の可能性を示します。
考えを整理します。
矛盾を見つけます。
構想を発展させます。
また、制作や実装によって得られた結果について、人間とともに検討し、そこから新しい可能性を考えることもできます。
したがって、本研究では、
人間を創作の主体、AIを創作の協働者
として位置付けます。
2.4 対話によって作品は成熟する
AI時代の創作では、最初から完成した作品構想を用意する必要はありません。
例えば、
「森からいただいた恵みを森へ返し、森とともに豊かになるゲームを作りたい」
という一つの考えからでも創作は始められます。
人間が考えを伝えます。
AIが提案します。
人間が評価します。
必要であれば否定します。
方向を変えます。
新しい条件を加えます。
再びAIが提案します。
この対話を繰り返すことで、一つの考えが世界観となり、ゲームシステムとなり、キャラクターとなり、物語となっていきます。
つまり、AI時代の創作で重要なのは、最初の指示を完璧にすることではありません。
対話を繰り返しながら作品を成熟させることです。
そして、この成熟は制作開始とともに終了するわけではありません。
実際に素材を制作し、ゲームへ実装することで、設計段階では見えていなかった問題や可能性が現れます。
その結果を再び対話へ持ち帰ることで、作品はさらに変化し、成熟していきます。
2.5 制作から創作が生まれる
本研究を実制作によって検証する過程で、創作と制作の関係について重要な現象が確認されました。
制作AIは、必ずしも人間が想定した結果だけを生成するわけではありません。
人間が考えていなかった構図。
表情。
形。
動き。
組み合わせ。
表現。
などが生成されることがあります。
これらは、人間の指示から外れた結果として生成される場合もあります。
しかし、その結果を人間が見たとき、
「こちらの方が面白い」
「このキャラクターには、この動きの方が合っている」
「この素材なら、別のゲーム表現ができる」
という新しい発見が生まれることがあります。
その場合、制作AIの生成結果は単なる制作物ではありません。
次の創作を生み出すきっかけ
になります。
つまり、
創作によって制作が行われる
だけではなく、
制作によって新しい創作が生まれる
という逆方向の関係が成立します。
本研究では、この関係をAI時代の創作における重要な特徴として位置付けます。
2.6 予想外の生成結果と創作
制作AIが人間の想定とは異なる結果を生成した場合、それを直ちに失敗と判断することはできません。
重要なのは、
人間の指示どおりであったか
だけではなく、
作品にとって新しい価値を持っているか
です。
人間の想定どおりではなくても、作品として魅力的であれば採用できます。
さらに、その生成結果から新しいゲームシステム、キャラクター表現、演出方法などを考えることもできます。
したがって制作AIには、
人間が設計したものを形にする役割
と同時に、
人間がまだ考えていなかった可能性を、生成結果として提示する可能性
があります。
ただし、その可能性を作品へ取り入れるかどうかを判断するのは人間です。
AIが予想外のものを生成したから採用するのではありません。
人間がそれを見て価値を発見し、作品に必要だと判断した場合に採用します。
したがって、偶然の生成結果そのものが創作なのではありません。
生成結果と人間の判断との関係から、新しい創作が始まります。
2.7 創作から設計へ、設計から再び創作へ
作品構想が形成されても、それだけではゲームを制作することはできません。
作品構想を、実際に制作できる形へ具体化する必要があります。
そこで創作は、次の段階である設計へ進みます。
本研究では、
創作
↓
設計
↓
制作
↓
実装
と、それぞれ異なる役割を持つ工程として捉えます。
創作では、
何を作るのか
を考えます。
設計では、
それをどのようなゲームとして成立させるのか
を具体化します。
制作では、
設計されたものをゲーム素材として形にします。
実装では、
制作された素材と設計された仕様を、実際に動作するゲームとして成立させます。
しかし、この流れは一方向ではありません。
制作や実装によって新しい可能性が発見された場合、
制作・実装
↓
発見
↓
創作
↓
再設計
という逆方向の流れが生まれます。
したがって、創作、設計、制作、実装は独立した工程ではなく、相互に影響しながら循環します。
2.8 プロンプトは創作の出発点ではない
一般に、生成AIを利用する際にはプロンプトが重要であると言われています。
しかし、本研究では、プロンプトを創作の出発点とは考えません。
人間が最初から完成したプロンプトを書くのではありません。
人間が行うのは、AIとの対話です。
対話によって作品構想を形成し、さらに設計を成熟させます。
そして、制作AIへ受け渡せる段階まで設計が進むと、その対話を行ってきた設計AIが、設計内容を基に制作AI用のプロンプトを生成します。
人間は、そのプロンプトを作成しません。
人間は、設計AIが生成したプロンプトを、必要な添付資料とともに制作AIへ渡します。
したがって、本研究におけるプロンプトは、人間がAIへ命令するために最初に書く文章ではありません。
【定義】
プロンプトとは、人間と設計AIとの対話によって形成された設計内容を、制作AIへ受け渡すために、設計AIが生成する翻訳言語である。
そして制作AIによる生成結果を検証した結果、設計が変更されれば、プロンプトも再び生成されます。
したがってプロンプトそのものも固定された完成物ではありません。
設計の変化に応じて更新される、AI間の受け渡し手段です。
2.9 すべてを指定しないという創作
制作AIへ設計を正確に伝えることは重要です。
しかし、今回の実制作によって、
制作AIへすべてを細かく指定することが、必ずしも最良の結果につながるわけではない
ことも確認されました。
人間と設計AIが、制作AIの具体的な表現まで完全に決定してしまえば、制作AIはその指定を再現する役割に限定されます。
一方、
作品として守るべき条件。
キャラクターとして維持すべき特徴。
ゲーム素材として必要な条件。
などを明確にしたうえで、具体的な表現の一部を制作AIへ委ねることで、人間が事前に想定していなかった可能性が生成されることがあります。
したがって、AI時代の創作では、
何を指定するか
だけではなく、
何を指定しないか
も重要になります。
すべてをAIへ任せることではありません。
人間と設計AIが、
変えてはいけないもの
と、
AIが自由に考えてよいもの
を区別します。
この意図的に残された自由度によって、制作AIを単なる再現手段ではなく、新しい表現の可能性を生み出す制作上の協働者として活用することができます。
2.10 AI時代の創作方法論
以上を整理すると、本研究が提案する創作から制作・実装までの基本的な流れは次のようになります。
人間
⇅
設計AIとの対話
↓
作品構想の形成・成熟
↓
ゲーム設計
↓
設計AIによる制作AI用プロンプトの生成
↓
人間によるプロンプト・添付資料の受け渡し
↓
制作AIによる制作
↓
人間による評価
↓
ゲーム実装
↓
人間による検証
ここで新しい問題や可能性が発見されれば、
発見
↓
人間 ⇄ 設計AIとの対話
↓
作品構想・ゲーム設計の更新
↓
再制作・再実装
へ進みます。
この循環を必要なだけ繰り返します。
ここで重要なのは、人間がプロンプトを書く技術だけではありません。
人間がAIとの対話を通して、自分が作ろうとしている作品を考え続けることです。
そして、制作AIや実装AIから得られた結果についても、人間と設計AIが再び考えます。
つまり、本研究が考えるAI時代の創作方法論は、
「人間が完成したアイデアを考え、プロンプトを書いてAIに作品を作らせる方法」ではありません。
「人間とAIが対話によって作品を創作し、その成果を複数のAIへ受け渡し、そこから得られた結果を再び創作へ還元しながら作品を発展させる方法」
です。
第2章のまとめ
本章では、AI時代における創作方法論について述べました。
本研究では、
創作
設計
制作
実装
を、それぞれ異なる役割を持つ工程として捉えます。
創作の主体は人間です。
AIは、人間との対話を通して作品構想を発展させる協働者です。
作品構想が成熟すると、それを実際に制作できる形へ具体化する設計工程へ進みます。
しかし、創作は制作開始とともに終了するわけではありません。
制作AIによる生成結果や、ゲームへの実装結果から、人間が当初想定していなかった可能性が発見されることがあります。
その発見は再び人間と設計AIとの対話へ持ち込まれ、作品構想やゲーム設計そのものを変化させる場合があります。
したがって、
創作 → 設計 → 制作 → 実装
という流れと同時に、
制作・実装 → 発見 → 創作 → 再設計
という流れが存在します。
また、制作AIから新しい可能性を引き出すためには、制作AIへすべてを細かく指定することが常に最適とは限りません。
作品として守るべき条件を明確にする一方で、制作AIが自由に考えることのできる領域を残すことも重要になります。
つまりAI時代の創作では、
何をAIへ指定するのか。
と同時に、
何をAIへ委ねるのか。
を設計する必要があります。
そして、制作・実装によって生まれた結果を再び創作へ還元します。
本研究では、この循環によって作品を発展させていくことを、AI時代の創作方法論の重要な特徴として位置付けます。
次章では、この創作によって形成された作品構想をゲーム設計へ発展させ、さらに制作・実装から得られた結果によって設計を更新していく**「AIゲーム設計生成モデル Ver.1.0」**について述べます。
第3章 AIゲーム設計生成モデル Ver.1.0
3.1 創作から設計へ
第2章では、AI時代の創作について述べました。
人間とAIが対話を繰り返すことで、作品構想は少しずつ形成され、成熟していきます。
しかし、作品構想だけではゲームを制作することはできません。
どのようなゲームなのか。
どのように遊ぶのか。
どのようなルールなのか。
どのような素材が必要なのか。
どのように実装するのか。
作品構想を、実際に制作できる形へ具体化する必要があります。
この工程が設計です。
本研究室では、この設計プロセスを体系化したものを、
「AIゲーム設計生成モデル Ver.1.0」
と定義します。
本モデルは、単にゲーム設計書をAIに作成させる方法ではありません。
人間と設計AIとの対話によってゲーム設計を段階的に形成し、制作可能な状態まで成熟させ、さらに制作・実装によって得られた結果を設計へ還元しながら更新していく方法論です。
3.2 ゲーム設計の五つの工程
本研究室では、ゲーム設計を次の五つの工程として整理します。
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
AI素材制作準備
それぞれの工程には異なる役割があります。
コンセプト
何を作るのかを定めます。
ゲームデザイン
どのような遊びを提供するのかを設計します。
ゲーム仕様書
ゲームのルールや動作を、実装可能な仕様へ具体化します。
ゲーム素材設計
ゲームを制作するために、どのような画像、3Dモデル、音声、プログラムなどが必要なのかを整理します。
AI素材制作準備
制作AIへ渡すプロンプトや添付資料などを準備します。
この五つの工程によって、
作品構想は、制作可能なゲーム設計へ変換されます。
ただし、この五工程は一度通過すれば終了するものではありません。
制作・実装・検証によって設計上の問題や新しい可能性が発見された場合には、必要な工程へ戻り、設計を更新します。
3.3 設計は対話によって作られる
従来のゲーム設計では、人間がゲームデザイン文書や仕様書を作成します。
本研究では、設計を人間だけで行いません。
人間と設計AIとの対話によって設計を形成します。
例えば、
「どんぐりを集めるゲームにしたい」
というアイデアがあったとします。
設計AIは、
どのように集めるのか。
プレイヤーは何を操作するのか。
成功条件は何か。
失敗条件は何か。
キャラクターはどのような役割を持つのか。
ゲームはどのように進行するのか。
などを人間との対話によって具体化していきます。
人間はAIの提案を評価します。
必要であれば否定します。
修正します。
新しい条件を加えます。
設計AIは、それを受けて再び設計案を提示します。
この対話を繰り返すことで、最初は曖昧だったアイデアが、制作可能なゲーム設計へ変化していきます。
3.4 コンセプト
最初に、ゲームの核となる考えを定めます。
本研究では、これをコンセプトと呼びます。
コンセプトは、ゲーム全体の方向性を決めるものです。
例えば、
「森からいただいた恵みを森へ返し、森とともに豊かになるゲーム」
という一文でも構いません。
重要なのは、最初から詳細なゲームシステムを決めることではありません。
何を作りたいのか。
何を大切にしたいのか。
その中心となる考えを明確にすることです。
設計AIは、このコンセプトを基準として、その後のゲームデザインを提案します。
3.5 ゲームデザイン
コンセプトが決まると、次にゲームとしての遊び方を設計します。
ここでは、
プレイヤーは何をするのか。
何が楽しいのか。
どのようにゲームが進行するのか。
どのような成功体験があるのか。
キャラクターにはどのような個性があるのか。
などを考えます。
この段階でも、人間がすべてを決める必要はありません。
設計AIが複数の可能性を提案し、人間がその中から選択したり、新しい方向を示したりしながらゲームデザインを形成します。
重要なのは、AIの提案をそのまま採用することではありません。
人間とAIとの対話によってゲームデザインを作ることです。
3.6 ゲーム仕様書
ゲームデザインが決まると、それを実際に実装できる仕様へ変換します。
例えば、
キャラクターの移動方法。
操作方法。
得点。
制限時間。
当たり判定。
ゲーム開始条件。
ゲーム終了条件。
キャラクター交代。
UI。
画面遷移。
などを具体化します。
ここでは、
「面白そうなゲーム」
から、
「実際に作ることができるゲーム」
へ変換することが重要です。
設計AIは、人間との対話によってゲームデザインを仕様へ変換します。
ただし、この仕様も絶対的な完成形ではありません。
実際にゲームへ実装してみることで、操作感、速度、難易度、画面構成などに問題が発見されることがあります。
その場合は実装結果を基に、人間と設計AIが仕様を再検討します。
3.7 ゲーム素材設計
ゲーム仕様が決まると、必要なゲーム素材を整理します。
例えば2Dゲームであれば、
キャラクター画像。
背景。
前景。
UI。
アイテム。
エフェクト。
アニメーション素材。
などが必要になります。
ここで重要なのは、
「キャラクター画像が必要」
というだけでは不十分だということです。
ゲームの中で、そのキャラクターがどのような動作をするのかを考える必要があります。
待機。
移動。
ジャンプ。
アイテムを持つ。
喜ぶ。
失敗する。
など、ゲーム仕様から必要な素材を逆算します。
さらに、
画像サイズ。
背景透過。
向き。
基準となるキャラクターデザイン。
必要なアクセサリー。
ゲームエンジンでの使用方法。
なども検討します。
ただし、素材設計についても、制作前にすべての最終形を決定するとは限りません。
制作AIによる生成結果から、当初想定していなかった有効な表現が発見される場合があります。
その場合には、生成結果を基にゲーム素材設計そのものを更新します。
3.8 AI素材制作準備
素材設計が完成すると、制作AIへ渡すための準備を行います。
ここでは、
制作AI用プロンプト。
公式キャラクター基準画像。
公式4面図。
キャラクター設定資料。
背景基準画像。
ゲーム仕様資料。
その他の制作に必要な基準資料。
などを準備します。
本研究では、人間が制作AI用のプロンプトを一から作成することを基本とはしません。
ゲーム設計を人間とともに形成してきた設計AIが、その設計内容を制作AIへ渡せる形へ変換します。
人間は、設計AIが生成したプロンプトと必要な資料を制作AIへ受け渡します。
したがって、
人間がゲーム設計を理解する。
設計AIもゲーム設計を理解する。
設計AIが、その設計を制作AIへ伝達可能な形へ変換する。
という構造になります。
3.9 基準資料はAI間の情報伝達手段である
今回の実制作によって、制作AIへ渡す基準資料の重要性が改めて確認されました。
特にキャラクター制作では、正面から見た一枚の画像だけでは、制作AIがキャラクターの立体的な構造を十分に把握できない場合があります。
背面にあるリュック。
横から見た体形。
尻尾の位置。
服装や装飾品。
左右から見た形。
こうした情報を制作AIへ伝えるために、本研究では公式4面図を使用します。
公式4面図は、正面、側面、背面などからキャラクターの構造を示します。
これは単なるゲーム素材ではありません。
また、鑑賞を目的としたキャラクターイラストでもありません。
後続の制作AIへキャラクターデザインを伝えるための設計資料
として機能します。
つまり、
人間 ⇄ 設計AI
によって確立されたキャラクターデザインを、
制作AI
へ受け渡すための中間表現です。
この考え方は、4面図だけに限定されません。
背景基準画像。
キャラクター基準画像。
素材見本。
その他の参照資料。
これらも、AI同士の工程を接続するための情報伝達手段として捉えることができます。
したがってAIゲーム開発では、プロンプトだけではなく、
どのような視覚資料を次のAIへ受け渡すのか
も設計工程の一部となります。
3.10 すべてを決めることが設計ではない
従来、設計とは制作前にできるだけ多くの条件を決定することだと考えられる場合があります。
しかし、生成AIを使用した制作では、設計を細かく固定しすぎることが必ずしも最良の結果につながるとは限りません。
制作AIには、画像や動きを生成する能力があります。
その能力を利用するためには、
何を固定するのか。
何をAIへ任せるのか。
を設計する必要があります。
例えばキャラクターアクションであれば、
キャラクターデザイン。
ゲーム上必要な動作目的。
キャラクターの向き。
持っているアイテム。
ゲーム素材として必要な条件。
などは固定します。
一方、
具体的な手足の位置。
身体の傾き。
重心。
細かな表情。
ポーズのバリエーション。
などについては、一定の自由度を制作AIへ与えることができます。
つまりAI時代のゲーム設計では、
制作物の完成形をすべて決定することだけが設計ではありません。
制作AIが創造性を発揮してよい範囲を決めることも設計です。
3.11 設計から制作へ
設計が制作可能な状態まで成熟すると、設計AIは制作AI用のプロンプトを生成します。
人間は、そのプロンプトと必要な添付資料を制作AIへ渡します。
基本的な流れは、
人間
⇅
設計AI
↓
制作AI用プロンプト・基準資料
↓
人間による受け渡し
↓
制作AI
となります。
制作AIは、それらを基にゲーム素材を生成します。
ここまでが、設計から制作への基本的な流れです。
しかし、本研究では、これを一方向の受け渡しとは考えません。
制作AIから得られた結果は、人間によって評価されます。
その結果に新しい可能性が発見された場合には、人間と設計AIが再び検討します。
3.12 制作結果から設計へ戻る
制作AIが生成した結果は、必ずしも当初の設計どおりになるとは限りません。
しかし、設計と異なることが、直ちに失敗を意味するわけではありません。
制作AIによって、
人間が考えていなかった動き。
予想していなかった表情。
新しいポーズ。
新しい構図。
新しい表現。
などが生成されることがあります。
その中にゲームへ利用できる可能性があれば、人間はそれを発見します。
そして設計AIとの対話によって、
ゲーム素材として採用できるか。
ゲーム上の動きとして利用できるか。
キャラクターの個性として取り入れられるか。
ゲームシステムへ反映できるか。
を検討します。
その結果、必要であればゲーム素材設計、ゲーム仕様書、ゲームデザインなどへ戻ります。
したがって、
設計 → 制作
という一方向だけではなく、
設計
↓
制作
↓
評価
↓
発見
↓
再設計
という循環が成立します。
3.13 実装結果から設計へ戻る
同じことはゲーム実装についても成立します。
設計段階では成立すると考えていた仕様でも、実際にゲームエンジン上で動作させると問題が見つかる場合があります。
キャラクターが大きすぎる。
ゲーム画面が狭い。
移動速度が合わない。
落下速度が速すぎる。
操作感が悪い。
想定より難しい。
逆に、実際に動かしたことで新しい面白さが見つかる場合もあります。
その場合、人間は実装結果を評価し、設計AIとの対話によって仕様を再検討します。
したがって、
設計
↓
実装
↓
検証
↓
発見
↓
再設計
という循環も成立します。
これによって設計は、制作開始前に固定された文書ではなくなります。
制作と実装によって検証され、必要に応じて変化していく設計
となります。
3.14 生成された結果からキャラクターを発見する
今回の実制作では、さらに興味深い現象が確認されました。
一般的には、
キャラクターの性格を決める
↓
その性格に合った動きを設計する
と考えます。
しかし制作AIへ一定の自由度を与えて複数の動作候補を生成させると、それぞれのキャラクターに異なる動きが現れることがあります。
その生成結果を見た人間が、
「このキャラクターは、このように動くと魅力的である」
と発見することがあります。
つまり、
キャラクター設定 → 動作設計
だけではなく、
生成された動作 → キャラクターのゲーム上の個性を発見
という逆方向の関係が成立します。
これは、制作AIがキャラクター設定そのものを決定するという意味ではありません。
生成された可能性を見て、その中から作品に適したものを発見し、採用するのは人間です。
しかし、制作結果がキャラクター設計へ影響を与えることは、AIゲーム開発における重要な特徴です。
3.15 AIゲーム設計生成モデルの循環構造
以上を整理すると、AIゲーム設計生成モデル Ver.1.0は、単純な直線構造ではありません。
最初の設計工程は、
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
AI素材制作準備
と進みます。
その後、
制作
↓
実装
↓
検証
へ進みます。
そして、制作・実装の結果から問題や新しい可能性が発見された場合、
発見
↓
人間 ⇄ 設計AI
↓
必要な設計工程へ戻る
となります。
戻る場所は常に同じではありません。
素材だけの問題であれば、
ゲーム素材設計
へ戻ります。
ゲームルールに関わる問題であれば、
ゲーム仕様書
へ戻ります。
遊びそのものが変化するのであれば、
ゲームデザイン
へ戻ります。
作品の根本的な方向性に関わる発見であれば、
コンセプト
まで戻る可能性もあります。
したがって、本モデルは、
一方向に設計を完成させるモデルではありません。
制作と実装による現実の結果を受け取りながら、必要な階層まで戻って設計を更新する循環型のゲーム設計モデルです。
3.16 AIゲーム設計生成モデルの特徴
AIゲーム設計生成モデル Ver.1.0の特徴は、設計書をAIに自動生成させることではありません。
人間と設計AIとの対話によって設計そのものを形成すること
です。
さらに、今回の実制作による検証から、
制作・実装によって得られた結果を、再び設計へ還元すること
が加わりました。
このモデルでは、
人間
創造し、評価し、発見し、決定する。
設計AI
人間と対話し、提案し、設計し、制作AI・実装AIへ渡す情報を形成し、制作・実装結果を人間とともに再検討する。
制作AI
設計された条件を基に素材を生成し、同時に、人間が事前に想定していなかった表現の可能性を生成結果として提示する。
実装AI
設計された仕様と制作された素材を基にゲーム実装を行い、その実装結果を次の検証へつなげる。
という役割分担を行います。
したがって、
人間 → プロンプト → AI
という単純な関係ではありません。
また、
人間 ⇄ 設計AI → 制作AI
という一方向の連携だけでもありません。
より正確には、
人間 ⇄ 設計AI
↓
制作AI・実装AI
↓
生成・実装結果
↓
人間による評価・検証
↓
人間 ⇄ 設計AI
という循環構造になります。
本研究室では、この構造をAI時代におけるゲーム設計の基本モデルとして位置付けます。
なお、本モデルは、2026年現在の生成AIを使用した実制作を基に構築したVer.1.0です。
今後も実制作による検証を続け、その結果によってモデル自体を更新していきます。
第3章のまとめ
本章では、AIゲーム設計生成モデル Ver.1.0について述べました。
本研究では、
コンセプト
↓
ゲームデザイン
↓
ゲーム仕様書
↓
ゲーム素材設計
↓
AI素材制作準備
までを、一つの連続した設計工程として捉えます。
この設計は、人間だけで行うものでも、AIだけで行うものでもありません。
人間と設計AIとの対話によって形成されます。
人間は作品の方向性を決め、AIの提案を評価し、最終的な判断を行います。
設計AIは、人間との対話を通して設計を具体化し、制作可能な状態まで成熟させます。
そして設計が制作可能な状態になると、設計AIが制作AI用のプロンプトを生成し、必要な基準資料とともに制作工程へ受け渡します。
その際、公式4面図などの基準資料は、単なる制作物ではなく、
人間と設計AIによって確立された設計情報を、後続の制作AIへ伝えるための中間表現
として機能します。
また、AI時代の設計では、制作物のすべてを事前に決定することが必ずしも最適ではありません。
何を固定するのか。
何を制作AIへ委ねるのか。
その境界を決めることも設計の一部となります。
さらに、制作・実装が開始された後も設計は終了しません。
制作AIの生成結果やゲームへの実装結果から新しい問題や可能性が発見された場合、
制作・実装
↓
評価・検証
↓
発見
↓
人間 ⇄ 設計AI
↓
再設計
という循環が生まれます。
必要に応じて、
ゲーム素材設計
ゲーム仕様書
ゲームデザイン
さらには、
コンセプト
まで戻ることができます。
したがって、AIゲーム設計生成モデル Ver.1.0とは、
設計を完成させて制作AIへ渡すためだけのモデルではありません。
人間と設計AIとの対話によって設計を形成し、制作・実装によって得られた結果を再び設計へ還元しながら、ゲームそのものを発展させていく循環型の設計生成モデルです。
次章では、この設計結果を制作AIへ受け渡し、実際のゲーム素材を生成し、選択し、加工し、ゲームで使用可能な素材へ変換していくAIゲーム素材制作方法論について述べます。
第4章 AIゲーム素材制作方法論
4.1 設計から制作へ
第3章では、人間と設計AIとの対話によってゲーム設計を形成し、その設計内容を制作AIへ受け渡す方法について述べました。
第4章では、その設計結果を実際のゲーム素材へ変換する制作工程について述べます。
基本的な流れは次のようになります。
設計AIによる制作AI用プロンプトの生成
↓
人間がプロンプトと基準資料を制作AIへ渡す
↓
制作AIによる生成
↓
人間による評価・選択
↓
必要に応じた再生成・再設計
↓
人間による加工・規格化
↓
ゲーム素材完成
ここで重要なのは、
制作AIが画像を生成した時点では、ゲーム素材はまだ完成していない
ということです。
制作AIが生成するのは、ゲーム素材の原材料または候補です。
その中から人間が使用可能なものを選択し、必要な加工、サイズ調整、規格化などを行い、ゲームエンジンへそのまま受け渡せる状態まで仕上げる必要があります。
本研究では、この一連の工程をAIゲーム素材制作として捉えます。
4.2 制作AIへ設計情報を渡す
制作工程では、第3章で設計AIが形成した設計内容を制作AIへ受け渡します。
その際に使用するものは、プロンプトだけではありません。
必要に応じて、
公式キャラクター基準画像。
公式4面図。
背景基準画像。
キャラクター設定。
ゲーム仕様書。
ゲーム素材設計資料。
既存の制作物。
その他の参照資料。
などを添付します。
人間が制作AI用のプロンプトを新たに一から作成するのではありません。
人間と設計AIとの対話によって形成された設計内容を、設計AIが制作AIへ伝達できる形へ変換します。
人間は、そのプロンプトと必要な資料を制作AIへ受け渡します。
したがってAIゲーム素材制作では、
文章による情報
と、
画像などによる視覚情報
の両方を使用して、設計内容を制作AIへ伝達します。
4.3 公式キャラクター基準画像
キャラクター素材制作では、最初にキャラクターの基準となる画像を確立します。
本研究では、これを公式キャラクター基準画像として扱います。
公式基準画像では、
顔。
体形。
毛並み。
色彩。
服装。
装飾品。
バッグやリュック。
キャラクター全体の画風。
など、キャラクターを成立させる基本的な要素を決定します。
制作AIへ新しいアクションを生成させる場合も、この基準を維持する必要があります。
したがって公式キャラクター基準画像は、単なる参考画像ではありません。
そのキャラクターが何者であるかを制作AIへ伝えるための最上位の視覚基準
となります。
4.4 公式4面図の役割
今回の実制作では、公式キャラクター基準画像からさらに公式4面図を制作しました。
4面図では、
正面。
右側面。
背面。
左側面。
など、異なる方向からキャラクターの構造を示します。
これは実制作において非常に重要な役割を持ちました。
一枚のキャラクター画像だけでは、
背面にあるリュック。
尻尾の位置。
側面から見た体形。
頭部と身体の比率。
衣服や装飾品の立体的な関係。
などを制作AIが十分に把握できない場合があります。
4面図によってこれらを明示することで、後続するアクション素材でも同一キャラクターを維持しやすくなります。
したがって、公式4面図は単なるキャラクターイラストでも、ゲーム内で直接表示する素材でもありません。
後続する制作AIへキャラクターデザインを伝達するための中間設計資料
です。
本研究では、
公式キャラクター基準画像
↓
公式4面図
↓
アクション素材生成
という制作経路を採用します。
4.5 制作AIによる生成結果を評価する
制作AIによる生成結果が、人間の想定どおりになるとは限りません。
しかし、本研究では、
人間の想定どおりであることを、生成結果の唯一の評価基準とはしません。
制作AIは、人間が事前に考えていなかった、
表情。
構図。
身体の傾き。
ポーズ。
重心。
動き。
アクセサリーの揺れ。
などを生成することがあります。
その中に、当初の想定より魅力的な表現が存在する場合があります。
したがって生成結果については、
そのまま採用する。
一部を加工して採用する。
候補の一つとして残す。
設計AIと再検討する。
再生成する。
生成結果を基に当初の設計を変更する。
などの判断を行います。
最終的な採用・不採用を決定するのは人間です。
4.6 すべてを指定しない
今回の実制作で、AIゲーム素材制作における重要な原則が明確になりました。
それは、
制作AIへすべてを細かく指定すれば、より良い結果になるとは限らない
ということです。
例えばキャラクターアクションを制作する際、
右足の位置。
左足の位置。
腕の角度。
身体の傾き。
フレームごとの重心位置。
などを詳細に指定すると、制作AIがその条件を満たすことに集中し、かえって不自然な結果になる場合があります。
そこで本研究では、
制作上絶対に守る必要がある条件
と、
制作AIへ委ねることのできる条件
を分けます。
例えば、
キャラクターデザイン。
向き。
持っているアイテム。
ゲーム上必要な動作目的。
背景透明。
装飾品。
などは固定します。
一方、
具体的な手足の位置。
身体の傾き。
表情の細部。
重心。
動作中の高さ。
などについては、制作AIに一定の自由度を与えます。
AIゲーム素材制作では、
何を指示するか
だけではなく、
何をあえて指定しないか
も重要な設計になります。
4.7 完成アニメーションを生成させない
本研究では、制作AIによる歩行や走行などの連続アニメーション生成を検証しました。
しかし、複数のフレームを連続して生成した場合、
足の運び。
接地。
重心移動。
中間姿勢。
身体の高さ。
フレーム間の連続性。
などを正確に維持することは困難でした。
そのため、
制作AIへ完成したアニメーションそのものを制作させる
という考え方を変更しました。
制作AIに求めるのは、
ゲーム内アクションへ利用できる個々のポーズを生成すること
です。
実際の移動。
速度。
ジャンプ。
上下運動。
タイミング。
フレーム切り替え。
などはUnity側で成立させます。
つまり、
制作AIは動作を表現する画像を作る。
Unityは実際の運動を作る。
という役割分担を行います。
4.8 動作ポーズから候補ポーズへ
当初は、制作AIへ必要な動作ポーズを個別に指定する方法を採用しました。
しかし実制作を進める中で、さらに有効な方法が見つかりました。
それが、
候補ポーズ生成方式
です。
制作AIへ、
「右方向へ移動している」
「頭の上の籠を両手で支えている」
「元気に喜んでいる」
など、動作の目的と必要条件を伝えます。
一方、具体的なポーズについては制作AIへ一定の自由度を与えます。
そして一枚の画像の中に複数の候補ポーズを生成させます。
生成された候補には、
走っているような姿勢。
跳ねている姿勢。
身体を縮めた姿勢。
片足を上げた姿勢。
前へ身体を傾けた姿勢。
両足が地面に近い姿勢。
など、さまざまなものが含まれます。
人間は、その中からゲームに使用できるものを選択します。
したがって制作AIへ求めるものは、
完成したアニメーション
ではありません。
また、
指定された一つの正解ポーズ
でもありません。
ゲームアクションへ使用できる複数の可能性を提示すること
です。
4.9 候補群として評価する
候補ポーズ生成方式では、生成結果の評価方法も変わります。
例えば一度の生成で8つの候補が生成されたとします。
そのうち6つが使用可能で、2つに問題があった場合、
「8枚中2枚失敗した」
と評価する必要はありません。
制作目的が、
8つすべての完成画像を得ること
ではなく、
ゲームに必要な数の使用可能なポーズを得ること
だからです。
したがって評価単位は、個々の画像だけではありません。
生成された候補群全体から、必要な素材を確保できたか
という観点で評価します。
本研究では、
制作AIによる生成成功率
よりも、
ゲーム制作に必要な採用可能素材を取得できたか
を重視します。
これは、AIによる素材制作を従来の一品完成型制作とは異なるものとして捉える重要な考え方です。
4.10 制作AIは可能性を提示する
候補ポーズ生成方式では、制作AIの役割そのものも変化します。
制作AIは、
人間が指定したポーズを正確に描く存在
だけではありません。
一定の条件の中で、
どのようなポーズならこのキャラクターが魅力的に動くのか
を生成結果として提示することができます。
人間は、その候補を見ることで、
「このポーズは使える」
「この動きはこのキャラクターに合っている」
「この動きならUnityで面白いアクションにできる」
と新しい可能性を発見します。
つまり制作AIの生成結果は、素材であると同時に、
制作上の提案
として機能する場合があります。
4.11 動きからキャラクターの個性を発見する
今回の実制作では、5人のキャラクターについて同じ制作方法を使用しました。
しかし生成されたアクション候補には、それぞれ異なる特徴が現れました。
そこで、
キャラクター設定から動きを作る
だけではなく、
生成された動きからキャラクターのゲーム上の個性を発見する
という関係が生まれました。
例えば、
元気に大きく跳ねる。
小刻みに素早く動く。
身体の重さを感じさせる。
軽快に走る。
独特な姿勢で移動する。
といった特徴が、生成された候補から見えてくる場合があります。
その結果を人間が評価し、
ゲーム上の移動速度。
ジャンプの仕方。
アクションのテンポ。
キャラクター演出。
などへ反映することができます。
これは、
素材制作の結果がゲーム設計へ戻る
具体的な例です。
4.12 キャラクターアクション素材制作モデル
以上の実制作から、本研究ではキャラクターアクション素材制作を次の流れとして整理します。
公式キャラクター基準画像
↓
公式4面図
↓
動作目的の設定
↓
守るべき条件の設定
↓
制作AIへ一定の自由度を与える
↓
複数の候補ポーズを生成
↓
人間による評価・選択
↓
必要に応じて再生成
↓
選択素材の切り出し・加工
↓
サイズ・位置等の規格化
↓
Unityへ受け渡す
↓
Unity上で移動・速度・タイミング等を設定
↓
ゲーム上のアクション完成
この方法では、
AIにアニメーションを完成させてもらう
ことを目標としません。
制作AI、人間、Unityがそれぞれ異なる役割を担当することでアクションを成立させます。
4.13 人間によるゲーム素材化
制作AIが生成した画像には、人間による加工が必要になります。
本研究では、画像素材制作における標準的な作業として、
候補の選択
↓
切り抜き
↓
不要部分・影などの除去
↓
キャラクターなどのサイズ調整
↓
位置・角度調整
↓
必要に応じた色調補正
↓
画像ファイルサイズの決定
↓
規格化
を行います。
一方、
口を開閉させる。
腕や足を修正する。
顔を別画像へ差し替える。
複数画像を合成する。
などの作業については、すべての素材へ必ず行うものではありません。
生成結果と使用目的に応じて行う個別加工として扱います。
4.14 ゲーム素材のサイズを決める
ゲーム素材制作では、画像サイズを一つの数値だけで考えることはできません。
本研究では、少なくとも次の三つを区別します。
生成画像のサイズ
制作AIが生成した元画像の大きさです。
ゲーム素材基準サイズ
生成画像をゲーム素材として規格化するときの基準となる大きさです。
ゲーム内表示サイズ
Unityへ実装した後、実際のゲーム画面で表示される大きさです。
この三つは同じものではありません。
『森のどんぐり大作戦』では、主要キャラクターの基準サイズを定め、人間が生成画像を切り出し、ゲーム素材として規格化します。
制作AIへ最終的なピクセルサイズを指定しても、その大きさを正確に生成できるとは限りません。
したがってゲーム素材の基準サイズは、
生成時にAIへ厳密に指定する値
ではなく、
生成後に人間が素材を揃えるための規格
として扱います。
ゲーム内での最終表示サイズは、Unity上で実際の画面を確認しながら決定します。
4.15 画像ファイルサイズとアクション素材
キャラクターの基準サイズを統一しても、すべての画像ファイルを同じ大きさにする必要はありません。
待機。
左右移動。
ジャンプ。
大喜び。
アイテム保持。
など、アクションによって必要な画像領域は異なります。
そのため本研究では、アクションごとに必要な画像領域を決定します。
また、アニメーション素材については、一枚のスプライトシートとしてAIに完成させることを前提としません。
独立した画像ファイルによるシーケンス素材
として管理します。
その後、Unity側で必要な順番、速度、移動などを設定します。
4.16 背景素材の制作
背景素材についても、制作AIへ最終的な画像サイズを完全に指定することは困難です。
そのため、生成時の画像サイズを最終仕様とはせず、制作AIが生成可能な範囲で背景原画を制作します。
背景制作で重要なのは画像サイズだけではありません。
ゲーム画面では、
キャラクターの動線。
アイテムの移動空間。
UIの配置。
キャラクターやアイテムの視認性。
などを考慮する必要があります。
一方、『森のどんぐり大作戦』には、
「絵本の世界で遊ぶ」
という作品上の目的があります。
そのため、
ゲームとしての視認性
と、
作品としての表現品質
の両方を成立させる必要があります。
4.17 前景と後景によるゲーム空間
ゲーム上の視認性と絵本世界としての奥行きを両立するため、背景を一枚の画像として完成させるのではなく、前景と後景へ分離します。
基本的なレイヤー構造は、
前景
↓
キャラクター・アイテム等のゲームオブジェクト
↓
後景
となります。
これによって、キャラクターが背景画像の上へ置かれているだけではなく、
森の空間の内部で動いているように見える画面
を作ることができます。
各背景素材についても、生成時点で最終画面サイズへ統一する必要はありません。
必要な単位で制作し、ゲーム画面上で統合します。
4.18 仮ゲーム画面による統合と検証
個別に制作した素材は、そのままでは一つのゲーム世界になりません。
そこで本研究では、素材を一度レイヤー構造で配置し、仮ゲーム画面を作成します。
仮ゲーム画面では、
背景素材の配置。
前景と後景の関係。
奥行き。
色彩。
画面全体の統一感。
キャラクターの視認性。
アイテムの視認性。
UI配置。
などを確認します。
ここで重要なのは、個々の素材が単独で美しいかどうかだけではありません。
すべての素材を組み合わせたときに、ゲーム画面として成立するか
を評価します。
必要であれば、背景側の明度、彩度、コントラストなどを調整します。
4.19 素材単体ではなくゲーム全体で評価する
AIが生成した素材は、単独で見ると優れた画像であっても、ゲームへ配置すると使用しにくい場合があります。
反対に、単独では地味に見える素材でも、ゲーム画面の中では非常に適切に機能することがあります。
したがって本研究では、素材評価を二段階で行います。
第一段階は、
素材単体として使用可能か
です。
第二段階は、
ゲーム画面へ統合したときに機能するか
です。
最終的に優先されるのは、
ゲームとして成立すること
です。
したがって、AI生成素材の評価は、画像生成時点だけで完結しません。
Unityへの実装と検証まで含めて判断します。
4.20 仮ゲーム画面と完成素材
仮ゲーム画面は、最終的なゲーム画面そのものではありません。
素材を制作・統合・評価・検証するための作業環境
です。
仮ゲーム画面上で一時的に拡大・縮小した画像を、そのまま完成素材として使用するとは限りません。
必要な画像品質を維持した原画へ同様の色調補正を行い、完成素材とする場合もあります。
一方、仮ゲーム画面上で行った加工そのものが素材の完成作業であり、十分な画像品質も維持されている場合は、その素材を完成素材として使用できます。
したがって判断基準は、
必要な画像品質が維持されているか。
仮ゲーム画面上の加工が、その素材の完成工程そのものであるか。
となります。
4.21 ゲーム素材完成の定義
本研究では、制作AIが画像を生成した時点をゲーム素材完成とは考えません。
制作AIによる生成結果から、
必要な候補を選択し、
必要に応じて加工し、
サイズを調整し、
ゲーム用として規格化し、
Unityへそのまま受け渡せる状態まで仕上げます。
【定義】
ゲーム素材完成とは、制作AIによる生成物または候補群から、人間が必要な素材を選択し、加工・規格化・色調補正等を行い、ゲーム実装工程へそのまま受け渡すことのできる状態になった時点をいう。
したがって、
制作AIによる生成
↓
人間による評価・選択
↓
必要に応じた再生成・再設計
↓
加工
↓
規格化
↓
統合・検証
↓
ゲーム素材完成
↓
Unityへ受け渡す
という工程になります。
Unityへ素材を持ち込んだ後、実装・検証によって素材変更が必要になった場合は、再び素材制作工程へ戻ります。
第4章のまとめ
本章では、AI時代におけるゲーム素材制作方法論について述べました。
制作AIが画像を生成した時点で、ゲーム素材が完成するわけではありません。
AIゲーム素材制作では、
設計AIによる制作条件の形成
↓
制作AIによる生成
↓
人間による評価・選択
↓
必要に応じた再生成・再設計
↓
人間による加工・規格化
↓
ゲームへの統合・検証
↓
ゲーム素材完成
という工程を取ります。
キャラクター制作では、
公式キャラクター基準画像
↓
公式4面図
↓
アクション素材制作
という構造を採用します。
公式4面図は、単なる完成イラストではありません。
キャラクターの構造を後続の制作AIへ伝えるための中間設計資料
として機能します。
また、キャラクターアクションについては、制作AIへ完成した連続アニメーションを制作させる方法ではなく、
複数の候補ポーズを生成させ、人間がその中からゲームへ使用する素材を選択する方法
を採用します。
ここでは、人間が手足の位置や姿勢をすべて決めるのではありません。
ゲーム素材として守るべき条件を明確にする一方で、制作AIが自由に表現できる領域を残します。
したがってAIゲーム素材制作では、
何を指定するのか
と同時に、
何を指定しないのか
が重要になります。
また、候補生成方式では、一つ一つの画像がすべて成功している必要はありません。
重要なのは、
生成された候補群から、ゲームに必要な採用可能素材を得ることができたか
です。
さらに、制作AIが生成した動作候補から、人間がキャラクターの新しい動きや個性を発見する場合があります。
これは、
設計 → 制作
だけではなく、
制作 → 発見 → 再設計
という循環が、ゲーム素材制作においても成立することを示しています。
最終的なアクションは制作AIだけで完成するものではありません。
制作AIがポーズを生成し、人間が選択・加工し、Unityが移動・速度・タイミング・ジャンプなどの実際の運動を成立させます。
したがって、本研究におけるAIゲーム素材制作とは、
AIに完成素材を自動生成させる方法ではありません。
人間、設計AI、制作AI、ゲームエンジンがそれぞれの得意な役割を担当し、その結果を相互に還元しながらゲーム素材を完成させる方法です。
次章では、完成したゲーム素材をUnityへ受け渡し、AI Agentを利用して実際のゲームとして実装するAI Agentによるゲーム実装方法論について述べます。
第5章 AI Agentによるゲーム実装方法論
5.1 素材制作からゲーム実装へ
前章では、AI時代におけるゲーム素材制作について検討しました。
制作AIによって生成された素材候補を人間が評価・選択し、必要な加工と規格化を行い、ゲームエンジンへ受け渡すことのできる状態になった時点で、ゲーム素材制作工程はいったん完了します。
ここから、ゲーム開発は次の段階へ進みます。
ゲーム実装です。
従来のゲーム開発では、完成した素材をゲームエンジンへ配置し、
GameObjectの作成。
Componentの追加。
各種パラメータの設定。
スクリプトの作成。
スクリプトのアタッチ。
入力処理。
当たり判定。
キャラクター制御。
UI。
ゲーム進行。
などを人間が実装していきます。
生成AIを利用する場合でも、これまではAIにC#などのコードを生成させ、そのコードを人間がUnityへ持ち込み、GameObjectへアタッチし、Inspectorを設定する方法が中心でした。
しかし、この方法ではAIが担当しているのは、ゲーム実装工程の一部分にすぎません。
実装そのものの主体は、依然として人間です。
本研究では、AIゲーム開発を、従来のゲーム開発工程へAIを部分的に追加することとは考えていません。
AIの存在を前提として、ゲーム開発工程そのものを再設計すること
を目的としています。
そこでゲーム実装についても、次の問いから検討を始めます。
AIを前提とした場合、ゲーム実装という工程そのものは、どのように変化するのでしょうか。
5.2 「AIによる実装支援」から「AIによる実装」へ
AIによるプログラム生成では、一般的に、
人間
↓
AIへコード生成を依頼
↓
AIがコードを生成
↓
人間がコードをUnityへ導入
↓
人間がGameObjectへアタッチ
↓
人間がInspectorを設定
↓
人間が実行・検証
という流れになります。
この方法でも、プログラム制作にAIを活用することはできます。
しかし、AIが担当するのは主としてコード生成です。
Unity Editor内部での実装作業は人間が担当します。
これに対してAI AgentがUnity Editor内部を操作できる場合、
GameObjectを作成する。
Componentを追加する。
パラメータを設定する。
スクリプトを作成する。
スクリプトをGameObjectへアタッチする。
など、従来人間が行っていた実装工程そのものをAIが担当できる可能性があります。
そこで本研究では、
「AIが実装を支援する」
段階から、
「AIが実装工程そのものを担当する」
段階への移行を検証します。
5.3 Unity AI Agentによる基礎実験
本研究では、Unity環境においてAI Agentを利用し、自然言語による指示からゲーム実装が可能かを検証しました。
実験では、複雑なゲーム全体を最初から制作するのではなく、まず単純なGameObjectを使用しました。
その理由は、AI Agentが、
自然言語による指示を理解できるか。
Unity Editor内部を操作できるか。
必要なスクリプトを生成できるか。
生成したスクリプトを実際のGameObjectへ適用できるか。
設定した動作をUnity上で実行できるか。
を段階的に確認するためです。
これは、AI Agentの能力を推測するための実験ではありません。
実際にUnityを操作させ、その結果によって能力と限界を確認する実証実験
として行いました。
5.4 自然言語からゲーム実装へ
基礎実験では、人間がUnityの各操作を一つずつ行うのではなく、AI Agentへ自然言語による実装指示を与えました。
従来であれば、
GameObjectを作成する。
Transformを設定する。
C#スクリプトを作成する。
コードを書く。
ファイルを保存する。
GameObjectへスクリプトをアタッチする。
Inspectorでパラメータを設定する。
といった複数の操作を人間が行います。
AI Agentを利用した場合、これらの操作を、
「何を実装するのか」
という自然言語による指示から開始できます。
したがって、人間とゲームエンジンとの間に存在していた操作手順の一部を、AI Agentが担当できる可能性があります。
5.5 GameObjectの作成と設定
基礎実験では、AI AgentへGameObjectの作成を指示しました。
その結果、Unity Editor内部にGameObjectを作成できることを確認しました。
さらに、
Componentの追加。
Transformなどの設定。
必要なパラメータの変更。
などについても、AI AgentがUnity Editor内部で操作できることを確認しました。
これは単なるコード生成とは異なります。
コードを提示して、
「あとは人間がUnityで設定してください」
という方法ではなく、
AI Agent自身がゲームエンジン内部の実装作業へ関与する
ことを意味します。
5.6 スクリプト生成からアタッチまで
次に、GameObjectを動作させるためのC#スクリプトをAI Agentへ作成させました。
AI Agentは必要なコードを生成し、ファイルとして保存しました。
さらに、そのスクリプトを対象となるGameObjectへアタッチしました。
これによって、
コード生成
↓
ファイル作成
↓
GameObjectへのアタッチ
という一連の作業をAI Agentが担当できることを確認しました。
従来のコード生成AIでは、この途中に人間によるコピー、保存、アタッチなどの作業が必要でした。
AI Agentによって、この工程の一部を連続した実装作業として扱える可能性が生まれます。
5.7 Unity上での実行確認
実装後、Unity上でゲームを実行しました。
その結果、AI Agentによって作成・設定されたGameObjectが、指示した基本動作を行うことを確認しました。
ここで重要なのは、
AIがコードを書いたこと
だけではありません。
自然言語による指示から始まり、
Unity内部で実装され、実際に動作するところまで到達した
ことです。
したがって今回の基礎実験では、
自然言語
↓
AI Agent
↓
Unity内部での実装
↓
実行
という経路が成立したことになります。
5.8 人間はUnity操作から解放されるのか
AI AgentがUnity Editorを操作できるからといって、人間がゲーム実装から不要になるわけではありません。
人間には重要な役割が残ります。
何を実装するのかを決める。
実装結果を確認する。
ゲームとして正しく動いているかを判断する。
面白いかを判断する。
問題を発見する。
変更するべき点を決める。
AI Agentによる変更を許可する。
最終的に採用するかどうかを決定する。
つまり、人間の役割は、
Unityの各操作を自分で実行すること
から、
何を実装し、その結果をどう評価するのかを決定すること
へ移動していく可能性があります。
5.9 実装結果は人間が検証する
AI Agentが実装したからといって、その結果が正しいとは限りません。
スクリプトがエラーなく動作していても、
速度が適切ではない。
位置が違う。
動きが不自然である。
ゲームとして面白くない。
難易度が高すぎる。
画面構成に問題がある。
などの可能性があります。
したがって、AI Agentによる実装後には人間による検証が必要です。
本研究では、
実装できたこと
と、
ゲームとして成立したこと
を区別します。
技術的に動作しているだけでは完成ではありません。
人間が実際にゲームとして確認し、次の判断を行います。
5.10 AI Agentによる実装は循環する
AI Agentによるゲーム実装は、一度の指示で完成するものではありません。
基本的な流れは、
実装指示
↓
AI Agentによる実装
↓
Unityでの実行
↓
人間による検証
となります。
問題が見つかれば、
検証結果
↓
次の実装指示
↓
AI Agentによる修正
↓
Unityでの再実行
↓
人間による再検証
となります。
したがって、AI Agentによるゲーム実装は一方向の自動化ではありません。
人間とAI Agentとの反復的な協働によって進行する実装工程
として捉える必要があります。
これは、第1章から述べてきたAIゲーム開発全体の循環構造が、実装工程においても成立することを示しています。
5.11 設計AIと実装AI Agent
今回の実験には、もう一つ重要な特徴があります。
Unity AI Agentへ入力した実装指示そのものを、人間が単独で作成したわけではありません。
本研究では、人間が設計AIであるArcと対話し、
次に何を実装・検証するのか。
Unity AI Agentへどのような指示を与えるのか。
を決定しました。
設計AIがUnity AI Agentへ渡す実装指示を文章として生成し、人間がその文章をUnity AI Agentへ受け渡しました。
したがって今回の実験は、
人間
⇅
設計AI
↓
実装指示
↓
人間による受け渡し
↓
実装AI Agent
↓
Unity
という構造を持っています。
そしてUnityでの結果は、
Unityでの実行結果
↓
人間による検証
↓
人間 ⇄ 設計AI
↓
次の実装指示
↓
実装AI Agent
↓
Unity
という循環へ戻ります。
ここで人間は、単なる情報の運搬者ではありません。
設計AIと対話しながら目的を決定し、指示内容を確認し、実装AI Agentへ受け渡し、その結果を検証します。
したがって人間は、
複数のAIを接続しながらゲーム開発全体を方向づける存在
として位置付けられます。
5.12 制作AIと実装AIの接続
第4章では、制作AIによって生成されたキャラクター素材について、
制作AIがポーズを生成する。
人間が候補を選択する。
人間がゲーム素材として規格化する。
Unityが実際の移動や速度、タイミングなどを成立させる。
という役割分担を示しました。
ここで、素材制作工程とゲーム実装工程が接続します。
例えばキャラクターの右移動アクションでは、制作AIが生成する画像そのものを画面内で右方向へ移動させる必要はありません。
制作AIは、
右方向へ移動しているように見える動作ポーズ
を制作します。
一方、
画面上のX方向移動。
移動速度。
加速。
停止。
画面端の制御。
画像切り替え。
などはUnity側で実装します。
同様にジャンプについても、制作AIが画像内で正確なジャンプ軌道を作る必要はありません。
キャラクターの上下移動そのものはUnity側で実装できます。
したがって、
制作AIが何を担当するのか。
実装AIが何を担当するのか。
を明確に分けることが重要になります。
制作AIが不得意な動きを、無理に画像だけで完成させる必要はありません。
逆に、Unityが容易に制御できるものを画像生成時に固定する必要もありません。
各AIとゲームエンジンが得意な部分を担当する。
これがAIゲーム開発における重要な役割分担となります。
5.13 実装によって素材の意味が変わる
制作されたゲーム素材は、それだけでは動きません。
しかしUnity上で、
移動。
回転。
拡大縮小。
画像切り替え。
速度変化。
ジャンプ。
当たり判定。
などを加えることで、一枚または数枚の画像からゲーム上のアクションを成立させることができます。
したがって、素材制作段階でアクションを完全に完成させる必要はありません。
素材制作とゲーム実装を組み合わせた時点で、最終的なゲーム表現が成立する
と考えることができます。
これは制作AIの限界を補うだけの方法ではありません。
制作AIには画像表現を担当させ、ゲームエンジンには運動と制御を担当させることで、それぞれの特性を利用できます。
そのためゲーム素材を設計するときから、
画像として何を表現するのか。
Unityで何を動かすのか。
を分けて考える必要があります。
5.14 実装結果から素材制作へ戻る
Unityへ素材を配置すると、素材制作時には分からなかった問題が見つかる場合があります。
キャラクターが大きすぎる。
小さすぎる。
背景に埋もれる。
アクションの変化が弱い。
必要なポーズが不足している。
画像の余白がゲーム上の制御に適していない。
などです。
その場合、Unity側だけで無理に解決する必要はありません。
必要であれば、第4章の素材制作工程へ戻ります。
素材制作
↓
Unity実装
↓
検証
↓
問題・可能性の発見
↓
素材制作へ戻る
という循環が成立します。
さらに問題が素材だけではなく、ゲーム仕様そのものに関係する場合には、第3章の設計工程へ戻ります。
したがって実装は、設計や素材制作の最終結果を受け取るだけの工程ではありません。
それまでの設計と制作を実際のゲームとして検証する工程
でもあります。
5.15 実装結果からゲーム設計へ戻る
ゲームは、実際に動かして初めて分かることがあります。
設計上では適切だと考えていた移動速度が、実際には速すぎる。
キャラクターの大きさによって、想定よりゲーム画面が狭く感じられる。
落下物の速度によって、ゲームの難易度が大きく変わる。
キャラクターの動きによって、想定していなかった個性が生まれる。
このような結果は、単なる実装上の調整だけではありません。
場合によっては、
ゲーム仕様。
ゲーム素材設計。
ゲームデザイン。
そのものへ影響します。
その場合、
実装
↓
検証
↓
発見
↓
人間 ⇄ 設計AI
↓
再設計
という循環が生まれます。
これは第3章で示した、
制作・実装の結果によって設計そのものを更新する
というAIゲーム設計生成モデルが、実際のゲーム実装において成立することを意味します。
5.16 AIによる実装と人間による許可
AI Agentがゲームエンジン内部を操作する場合、人間による確認や許可が必要になる操作があります。
これはAIゲーム開発における人間の役割を考えるうえでも重要です。
AI Agentへ実装を任せることは、
AIへ無制限にゲーム開発を任せること
ではありません。
人間は、
実装の目的を決める。
設計AIと指示内容を検討する。
AI Agentへ指示を渡す。
必要な変更を許可する。
実装結果を確認する。
採用するかどうかを判断する。
という役割を持ちます。
したがってAI Agentによるゲーム実装は、
人間を工程から排除する自動化
ではありません。
人間の役割を、
直接操作する人
から、
実装全体を判断し方向づける人
へ変化させるものと考えることができます。
5.17 AIゲーム実装モデルへの発展
今回の基礎実験によって、
自然言語による指示。
GameObjectの作成。
Componentの設定。
C#スクリプトの生成。
スクリプトのアタッチ。
Unity上での実行。
人間による検証。
次の指示による修正。
という基本的な循環が成立することを確認しました。
しかし、これは現段階ではまだ、
AIゲーム実装モデル Ver.1.0
の完成を意味するものではありません。
基礎実験では、限定されたGameObjectと単純な動作を中心に検証したためです。
実際のゲームでは、
複数のGameObject。
複数のゲーム素材。
Prefab。
入力処理。
Collider。
キャラクター制御。
UI。
ゲーム進行。
Scene管理。
複数スクリプト間の連携。
エラー発生時の原因特定。
既存実装の修正。
など、より複雑な処理が必要になります。
したがって、実際のゲーム制作を通した検証が必要です。
5.18 「森のどんぐり大作戦」による実証
次の研究段階では、基礎実験で確認したAI Agentによる実装方法を、実際のゲーム制作へ適用します。
対象とするのは、本研究で制作を進めている、
「森のどんぐり大作戦」
です。
ここでは、
AI Agentに何ができるのか。
何ができないのか。
どの工程で人間の介入が必要になるのか。
設計AIから実装AI Agentへ、どのような指示を渡す必要があるのか。
複数のゲーム素材をどこまでAI Agentが扱えるのか。
AI Agentは実装上の問題をどこまで発見・修正できるのか。
制作AIによる素材と実装AIによる処理をどのように接続するのか。
実装結果によってゲーム設計がどのように変化するのか。
を検証します。
そして、その実制作による結果を基に、現在の仮説を修正します。
十分な実証結果が得られた段階で、
AIゲーム実装モデル Ver.1.0
として体系化します。
したがって本章は、完成した実装理論を提示するものではありません。
基礎実験によって確認された可能性を、実ゲーム制作によって検証するための出発点
として位置付けます。
第5章のまとめ
本章では、AI Agentを利用したゲーム実装方法について検討しました。
従来の生成AIによるプログラム支援では、
AIがコードを生成し、人間がゲームエンジンへ実装する
という役割分担が中心でした。
これに対してAI Agentを利用することで、
自然言語による実装指示
↓
AI AgentによるUnity内部での実装
↓
Unityでの実行
という経路が成立する可能性が確認されました。
さらに、
Unityでの実行結果
↓
人間による検証
↓
人間 ⇄ 設計AI
↓
次の実装指示
↓
AI Agentによる再実装
という循環を形成できます。
したがって、AI Agentによるゲーム実装は一方向の自動化ではありません。
人間、設計AI、実装AI Agentが反復的に協働する実装工程
として捉えることができます。
また、第4章で制作したゲーム素材についても、
制作AIが画像表現を担当し、Unityが移動・速度・ジャンプ・タイミングなどの運動を担当する
という役割分担が成立します。
これによって、制作AIへ完成したアニメーションを無理に生成させる必要がなくなります。
そして実装結果に問題や新しい可能性が発見された場合には、
実装 → 検証 → 素材制作へ戻る
あるいは、
実装 → 検証 → 発見 → 再設計
という循環が生まれます。
ここまでの研究によって、
設計AI
制作AI
実装AI Agent
が、独立したAIとして存在するだけではなく、
人間を中心として一つのゲーム開発工程の中で接続される構造
が見え始めました。
しかし、現段階で確認できたAI Agentの実装能力は、まだ基礎実験によるものです。
したがって、
AIゲーム実装モデル Ver.1.0
として確立するためには、実際のゲームを制作しながら検証する必要があります。
次の研究段階では、「森のどんぐり大作戦」そのものをAI Agentとともに実装します。
そこで生じる成功、失敗、修正、人間の介入、そして予想外の発見を記録し、その結果からAI時代のゲーム実装方法論をさらに更新していきます。
