Tesujiつながりから、次の一手を
人・AI・サービスが、ひとつのネットワークでつながる

出会い、知恵、仕事がつながり、次の一手を生み出す。

公開

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

変更履歴

Unity開発でAIエージェントを使う際に、企画・実装・Scene変更・テスト・レビューを小さな変更単位へ分け、GitHub上で追跡可能にする運用を理解する。

この記事をシェア

Xでシェア

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

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

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

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

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

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

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

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

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

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

悪い依頼はこうです。

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

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

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

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

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

この単位なら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でロック表示

手動確認

  1. Stage 1を開始
  2. クリアする
  3. Stage Selectへ戻る
  4. Stage 2が選べることを確認
  5. アプリ再起動
  6. 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つ選びます。

そのタスクについて、

  1. 目的
  2. 変更してよい範囲
  3. 変更禁止範囲
  4. Code Done
  5. Editor Done
  6. Play Done
  7. PRでの確認手順

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

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