AI駆動開発 × Unity × GitHub：AIにゲーム開発を任せても破綻しにくい作業単位の切り方

AIでゲーム開発が速くなるほど、「何を変えたか」が分からなくなる

Unity開発にAIを入れると、C#コードはかなり速く増やせます。

しかしゲームはコードだけで動いていません。

Scene
Prefab
Inspector設定
ScriptableObject
Animator
Material
Addressables
Input設定
Project Settings

など、リポジトリ内の複数の要素が組み合わさって動きます。

そのためAIに「この機能を作って」と大きく投げると、実装は終わったように見えても、あとから

どのPrefabを変えたのか
なぜこのフィールドが増えたのか
どのSceneで確認したのか
何をもって完了にしたのか

が追えなくなることがあります。

AI駆動開発で重要なのは、AIが何行コードを書いたかではなく、変更を人間が理解・検証・戻せる単位に保つことです。

1タスク = 1つの「検証可能な変化」にする

悪い依頼はこうです。

ステージ選択機能を全部作って。UIもセーブもアンロックも演出もお願いします。

これでは変更範囲が大きすぎます。

代わりに、たとえば以下へ分けます。

ステージ一覧データを定義する
ステージ選択UIに3件表示する
選択したステージIDを保持する
Playボタンで対象Sceneを開く
クリア済みステージだけ次を解放する
再起動後も解放状態を保持する

各タスクに「目で確認できる結果」を付けます。

この単位ならAIも作業しやすく、人間もレビューしやすい。

GitHubを「変更の正本」にする

AIエージェントとの会話だけに実装理由が残ると、数週間後に追えません。

最低限、変更には次を残します。

Issue / タスク: 何を変えるか
Branch: その変更だけを隔離
Commit: 実際に何を変更したか
PR: なぜ変更したか、どう確認したか
Review: 人間または別AIが妥当性を確認

AIとのチャットログは補助情報であり、最終的な変更履歴はGitHub側にも残す方が長期運用しやすくなります。

Unityでは「コード変更」と「Editor変更」を分けて考える

AIがC#だけを直しても、SceneやPrefabのInspector設定が必要なケースがあります。

たとえば新しいHealthComponentを作ったとしても、

PrefabへAdd Componentしたか
初期HPを設定したか
UIのHPバーと参照がつながっているか
Scene上の既存キャラにも反映されているか

まで確認しないと、機能は完成していません。

そこで完了条件を次のように分けます。

Code Done

コンパイルが通る
自動テストが通る
変更箇所の責務が明確

Editor Done

対象Prefabへ設定済み
Inspector参照が欠けていない
Sceneでエラーが出ない

Play Done

実際にプレイして期待挙動を確認
リトライやScene再読込でも壊れない

この3段階を分けるだけで「コードはできています」という未完成状態を減らせます。

PRには「変更内容」より「検証方法」を書く

AIが生成したPR説明にありがちなのは、変更ファイルの要約だけです。

しかしレビューする側が欲しいのは、どう確認すればよいかです。

良いPRには、たとえば次を残します。

目的

ステージクリア後に次ステージを解放する。

変更

StageProgressを追加
クリア時に保存
StageSelectでロック表示

手動確認

Stage 1を開始
クリアする
Stage Selectへ戻る
Stage 2が選べることを確認
アプリ再起動
Stage 2が引き続き解放されていることを確認

壊してはいけないもの

未クリア時にStage 2が解放されない
既存セーブデータ読み込みが落ちない

これならAIが作った変更でも、人間が短時間で検証できます。

AIへ渡す前に「変更禁止領域」を決める

Unityプロジェクトは依存関係が多いため、必要以上に触らせない方が安全です。

たとえば、

このタスクではProject Settingsを変更しない
Package追加は禁止
Scene構造を全面変更しない
既存セーブ形式を壊さない
Public API名を変えない

といった制約を先に書きます。

AIは「最短で動く方法」を選ぶことがありますが、それが「プロジェクト全体にとって最小の変更」とは限りません。

AIレビューをもう1枚挟む

実装したAIと同じ文脈だけでレビューすると、同じ思い込みを引き継ぐ可能性があります。

そこで、別のAIまたは別プロンプトで、

既存仕様を壊していないか
無駄に複雑ではないか
Unity特有の参照漏れがないか
例外ケースが足りないか
テスト不能な設計になっていないか

だけをレビューさせると、品質が上がります。

重要なのは「もう一度実装させる」のではなく、批判役に固定することです。

KPIは開発速度だけでは足りない

AI駆動開発の効果を見るなら、少なくとも次を見ます。

タスク開始 → Play確認までの時間
PRあたりの平均変更ファイル数
PR後の手戻り回数
main merge後の不具合率
1機能あたりの人間レビュー時間

特に「速度は上がったが手戻りが2倍」なら、実際には速くなっていません。

小さなチームほど「作業単位」がMoatになる

大企業はレビュー担当、QA、テクニカルアーティスト、PMを分けられます。

小さなチームでは、AIで人数差を埋められますが、ルールがないと逆に変更が散らかります。

そのため、

Issue → AI実装 → Unity確認 → PR → Review → Merge

を極端に軽く、しかし毎回同じ形で回せるようにする方が強い。

AIモデルそのものは他社も使えます。

差が付くのは、AIが迷わず動き、人間が短時間で検証できる開発プロセスの方です。

次の一手

既存Unityプロジェクトから、30〜90分で終わる小機能を1つ選びます。

そのタスクについて、

目的
変更してよい範囲
変更禁止範囲
Code Done
Editor Done
Play Done
PRでの確認手順

を先に書いてからAIへ渡す。

この型が1つできれば、次からAIへ仕事を振る速度だけでなく、完成判定の速度も上がります。