ClaudeCodeとCodexにコーディングを全て任せて商用レベルのUnityゲーム開発を行う【後編】

こんにちは、Liseと申します。

現在のゲーム開発現場では恐らく、どんな会社でもどんなプロジェクトでも、ClaudeCodeやCodexを利用した開発のAI補助を行っていたり、ゲームジャム等のイベントで「試しにAIに小規模なゲームプログラミングをさせてみよう」みたいな動きがあると思います。

しかし既にAIを活用しているエンジニアでも、どうしても心の中に心配としてあるのが、
「ゲーム開発や設計を丸ごとAIに投げることが出来ないのか？」 というテーマだと思います。

この投稿はそんな「一からゲーム開発をAIで行ってみた」というチャレンジの備忘録になります。

作業リポジトリ

前編のおさらい

前編の総評・結論としては
「ClaudeCode/Codexにコーディングを全て任せてUnityゲーム開発は出来る」
でした。

ただしこれは、手放しでAIにぶん投げて良いんだ、という話ではなく

• 「データ構造を先に設計する」ことで技術的な負債が発生する余地を減らし、
• 「コード品質ガイドラインをレビューから逆算して作る」ことで技術的な負債を発生し難くするガードレールを効率よく作る

という前提です。

今回はその続き、実際にゲーム開発を続けてみて得た知見をまたまとめていこうと思います。

タイトルの「商用レベル」の定義

前編で言ってませんでした。ここでは以下のような内容を指します。

技術的負債が「人間が開発する一般的なゲーム開発」程度に収まること

観点としては

• AIによる実装にありがちな動くだけのスパゲッティコードを作らないこと
• 将来的な拡張性を鑑みた機能設計になっていること
• AIが使用できなくなっても、人間のエンジニアが引き継ぎ、改修出来るコード品質であること

です。

「いや手元では出来てるけどな」と思う人はいるかもしれませんが、
ゼロベースで設計からAIにぶん投げると1ファイル5000行とか詰め込まれるため、
とてもじゃないですがプロジェクト立ち上げのタイミングで開発出来るベースとして利用できません。

今回はそれをなんとかして解決できないか、という話になります。

成果物

実は前編と比べて、方針転換や手法の大きな変化はありません。
これはとても良いニュースで、一定のパフォーマンスを継続してアウトプットし続けることが出来ているということです。
（まぁ実際にはその成果物を利用してゲーム量産することが出来て初めてゴールなのですが）

後編ではそのワークフローと考え方、AIが利用するルールを記載したドキュメントについて解説していきます。

さっさと見せろという方はこちらからどうぞ。
ブランチはdevelop2です。（うっかりdevelopを前編の参照ブランチとしてしまったので）

ゲームについて

本題ではないので、どんなゲームを作ったのかだけ簡単に画像と動画とWebGLビルドだけ乗せておきます。

AIでゲームを作った人は経験あるかもしれませんが、
適当に作らせるとおそらくこれぐらいの複雑度に到達する前に、頭打ちになると思います。

↑WebGLビルドで実際に遊べます

カメラ移動: WASD
フロア切り替え: Q/E
マウスで選択

AIだけでUnityゲームを作るためのワークフロー

前編と少し被りますが、途中から見せられてもわかりにくいと思うので1から説明します。
どうせ読んでる人は色んなAI記事読んでると思うので、大事だと思ったことに絞って書いていきます。

一点だけ先に書いておくと、このワークフロー全体の核心は作業の合間のdocs化です。
ステップ2で詳しく解説します。

1. どんなゲームを作るか決める

「決める」というのはつまり「決める」ということです。

「まぁ大体決まってるんだけど」とか思っているかもしれませんが、
ふんわりしたゲーム像を持ったままプログラムを書かせ始めても必ず迷子になります。

どんなジャンルで、どんな画面で、どんなUIがあって、どんな操作が出来て、どんなゲームサイクルで、どんな体験をするのかここで決めてください。
目を閉じてゲームを頭の中で再現出来るようになるまで詰めてください。

Claudeと壁打ちしてもいいです。
ここで決めないと仕様の曖昧さがこの後のデータ設計に現れてボディーブローのように効いてきます。

2. データ設計を行うプロンプトを作る

データ設計と言っても一般的にはマスタデータとDomainオブジェクトの2種類ありますが、
マスタデータ→Domainオブジェクトの順番で設計すると気持ち楽です。

「マスタデータ」とはゲーム起動中、不変となるデータを言います。
ポケモンで言うと名前や種族値、出現する道路などの情報です。

「Domainオブジェクト」とはゲーム実行中に扱うデータオブジェクトのうち、ビジネスロジックに利用されるものです。
ポケモンで言うと、「存在していて状態を持っていて変化するもの全て」です。
なんの例えにもなってないですが、まぁゲーム起動中に状態が変化する情報を指します。

マスタデータ

まずはマスタデータのテーブルの一覧から作りましょう。
今回の「冒険者ギルド経営ゲーム」では

• アクター
  • アクターテーブル
  • 冒険者ステータステーブル
  • 冒険者ルックテーブル
  • モンスターステータステーブル
  • モンスタールックテーブル
  • AIテーブル
  • レベルテーブル
  • ...
• アイテム
  • アイテムテーブル
  • 武器テーブル
  • 装備テーブル
  • ...
• ダンジョン
  • フロアテーブル
  • モンスタースポーンテーブル
  • ダンジョン生成設定テーブル
  • ダンジョンルックテーブル
  • ...

という感じでしょうか。

コードを書かせる前に、テーブル名と列名だけの状態で、第三正規形までやっておくと良いです。
ClaudeCodeやCodexにいい感じにやってもらいましょう。

参考コミット（ノイズが多めです）

Domainオブジェクト

Domainオブジェクトは最初から完成させられません。ゲームの機能は後からどんどん追加されていくからです。

このタイミングで意識すべきことは、

• Domainオブジェクトの本懐が「状態を持つこと」だということ
• ゲームの最低限のループに必要な状態だけ定義すること

です。

最初は、アクターだったらマスタIDや座標情報だけでいいでしょう。

最終的にはこんな形になります。

そのキャラクターがどんな名前でどんな種族なのかという情報はマスタデータのキーを持つ事で表現します。

作業の合間にDocs化する（超重要）

ここでdocs化の話を差し込みます。これはワークフローの特定のステップではなく、ステップ1〜6の開発全体を通して並行して行うことです。

AIでのゲーム開発ワークフローで一番重要なのがdocs化です。
Unityプログラムは一般的な作り方だと1ファイル1クラスですが、
ファイル数が多いとAIが全体像を一度のコンテキストで読み込めず、インターフェースやクラス間の関係を読み取るには効率が悪くノイズも多いです。

世の中には「実装が仕様書だろ」という過激派が居ることも理解出来ますが、
AIはセッションを繋ぎ直すたびに読み込みが必要で、コードから読み取らせるとトークンの使用量はもちろん一番重要な精度が埋もれてしまいます。

自然言語で注釈や将来的な構想をメモすることが出来るのも重要なポイントです。

AIの作業は全てdocsから始まりdocsに終わると言っても過言ではありません。

これは「やったほうが良いんだろうな」程度の話ではなく、必ずやりましょう。
ただし、貴方が書く必要はありません。
「こういうこと考えてるんだよね」とAIに壁打ちして着地したらそれをdocsに記載してもらいましょう。

ドキュメントの種類

前述の通り、ClaudeCodeやCodexはその特性上定期的にセッションをリセットする必要があります。
リセットをせずに使い続けると徐々にトークン効率が落ち、ベテランエンジニアのような風格が消え、入力したプロンプトにうまく従わなかったりします。

新人エンジニアがプロジェクトに参画した時のように、
最初に読ませるドキュメントのように、
素早くキャッチアップ出来るように準備をしておく必要があります。

私が今回の検証開発で行き着いたドキュメントの種類は以下の4つです。

1. design

ゲームの仕様を置くフォルダ。
思ったことや将来の構想、ゲームシステム、機能などはすべてここに置きます。
マスタやDomainオブジェクトの設計意図などもここです。

• 例
  • ゲーム全体の仕様
  • 戦闘システム
  • ゲームサイクル
  • アクターが振る舞えること
  • アイテムやゴールドのシステム

2. guidelines

ゲームの実装ルールに関するフォルダ
他のプロジェクトにも流用出来るものをここに置きます。

この検証開発は、guidelinesを作成・拡充し、精度を上げるために今回のゲームを作っています

• 例
  • コーディングルール
  • デバッグ方法
  • フレームワークの使い方
  • レビューガイドライン
  • セルフレビュープロンプト

新しくゲームを作る時、これらのファイルだけコピーして引き継ぐのが理想。

3. roadmap

ゲームの実装ロードマップ
roadmap -> phase -> task という親子関係
phaseはroadmap内の作業をまとまりごとに分割した単位です（例：「戦闘システム」「アイテムシステム」など）
guidelinesが安定するとroadmap単位で丸ごとそこそこ品質の良い実装が納品されるようになる

• 「ゲームの開発完了に向けてロードマップをdocs/roadmapの下にmdファイルで作ってください」

4. self-review

セルフレビュー置き場。
ClaudeCodeとCodexにそれぞれセルフレビューをさせる。
性格の違いか、割とそれぞれがそれぞれとも適切な指摘を行うのでレビュー内容をマージさせて修正させるのを繰り返す。

仕様を考えた時、新しい機能を作る時には必ずdocsに記載して永続化しましょう

3. データ設計をコードに落とし込む

（コミットをもうちょっとちゃんと分けておけばよかったと今後悔しています。）

作成したマスターデータとDomainオブジェクトを実際のコードに落とし込みます。

しかしマスタデータのためにSQLiteやらMasterMemoryやらこのタイミングで導入するとコストが高いですし、何よりClaudeCodeやCodexに気軽に編集してもらえません。

今回は全てDictionaryでハードコードで作ってもらいます。

アイテムの例。
immutableであることは確認しましょう。
マスタ1テーブルに対応するクラスを1つ作ります。

マスタデータ

Domainオブジェクト

Prefix/Suffixの補足（リポジトリを参照する人向け）

PrefixやSuffixの役割についてまとめて載せておきます。
（「私がこういう意味で使っている」だけで一般的なのは書きません）

• ~Table
  • マスタデータのテーブルを表現するクラス
  • 最終的にはSQLiteやMasterMemoryになるので開発が進むにつれて消えてしまう
• ~Master
  • マスタデータの1レコードを表現するクラス
  • immutableなデータクラス
  • 内容はマスタデータと一致している必要がある
• ~Spec
  • マスタデータを組み合わせたimmutableなデータクラス
  • 状態を持たないが加工はok
  • マスタ単体では表現しにくい時に利用する
  • 例えばActorをスポーンする時に、スポーンテーブルIDからマスタを参照してアクターの種類や位置、初期武器、装備といった情報を引っ張って利用しやすい形で提供する
• ~Orchestrator
  • 複数のUseCaseを利用することが出来るApplication層のUseCase
  • 逆に言うと ~UseCase は単体責務しか持てない（Orchestratorへの昇格が必要）
• Advance~
  • 定期的に更新する処理
  • Updateが多義語過ぎるのでよくこちらを使う
• Product~
  • プロダクト側でミドルウェアなどをOverrideする時に利用するPrefix
  • プロジェクト名にすると意図がわかりにくくなるのでProductで統一している
  • この対策がないと DungeonInnCameraManager とか悲惨な名前になってしまう
• 他

4. Orchestrator/UseCaseを作る

次にOrchestratorとUseCaseを作ります。
OrchestratorというのはUseCaseを呼び出せるUseCaseです。

一般的に「UseCaseは他のUseCaseを呼び出せる」とすることが多いのですが、
クモの巣状に依存が絡まるのが嫌なので私は分けています。

UseCaseが何かわからんという人は「クリーンアーキテクチャ」で検索してください

気の迷いで作った「ずんだもんのクリーンアーキテクチャ解説」も載せておきます
https://github.com/lisearcheleeds/Lighthouse/blob/master/Docs/ja/zundamon/CleanArchitecture.md

簡単に言うと「UseCaseとはデータの操作手順ごとに作られるクラス」です。

実はこの時点で、designのドキュメントが充実し、マスタデータ・Domainオブジェクトをしっかり作ることができていれば、この作業を全てAIに任せることが出来ます。

このステップは 「designの内容に合わせてUseCaseを作ってください」 だけでいいです。

AIがわけのわからない実装を始めるのは「データ設計」とそれを利用する「処理」を一度に作らせるからです。
ClaudeやCodexが既にある構造への修正や拡張において発揮するパワーは言うまでもないでしょう。

5. roadmapの作成

ここからいよいよroadmapによる作業を始めます。

データ設計からroadmapを定義してもいいのですが、
データ設計はClaude/Codexの調教出来るまで苦労すると思うので、それまで変に予定を立てても大して効力はありません。
また、このワークフローでroadmapのmdファイルを作る目的は「AIにぶん投げられるようにする」ためにあります。

designに記載されているゲームの内容を実装し完成するまでのroadmapをmdファイルで作ってください。
roadmapは作業しやすく動作確認が可能な単位で区切ってファイル化してください。
roadmapにはゴールと対象範囲を記載してください

これで十分です。

初めからどのような実装をするか全てのroadmapに具体的に書いてしまうと、
そのroadmapの作業に入る時にノイズになります。

まずは抽象的な予定だけを記載しましょう。

6. roadmapの作業を行う

ここからはこのroadmapの作業の繰り返しです。
ただし、進め方は重要です。
roadmapの作業を開始する直前にそのroadmapの内容を記入します。

Step1. 機能の詳細を記載する

roadmap{N}の内容を精査し、どのような機能が必要か詳細に記載してください

Step2. 機能の理想の設計を記載する

roadmap{N}の内容を精査し、実際のコードを参照しながら理想的な設計を追記してください。
ただし互換性を維持するための実装やバイパスは一切しないでください。
理想的な設計のために行われる破壊的変更は全て許容します。

Step3. 機能の実装をする

roadmap{N}の内容を実装してください

重要なのは実装の直前に2つのステップを挟むことです。

Step1は、それまでの作業によってプロジェクトの状態が変化していたり、方針が変わっている可能性があるため、このタイミングでコードを見て具体的な作業方針をroadmapに記載します。

Step2は、ClaudeCodeやCodexが機能実装の完了を優先するために横着した実装をすることを抑制する効果があります。

AIは特に「動いてるけどこれ実装としてダメじゃない？」というコードを書きがちですが、
それは「動かすこと」を目的としてコード設計しているからです。

熟練のエンジニアは理想的な設計をコードを書きながら組み立てられますが、
AIはNavMeshのように経路をちゃんと作ってあげないと壁にぶつかってしまいます。

これは特に重要なので、コピペしましょう。

それで、結論として商用レベルのコード品質になったのか？

結論としては十分なコード品質でゲームが作れています。

完璧な設計、完璧な実装にはほど遠いですが、
ゲームとしてコンテンツを増やしやすいスケーラビリティの高い設計を保てています。

私の経験上、実際のゲーム開発現場でいうと偏差値55ぐらいのコード品質です。

作業時間はGW（4/29〜5/6）の連休 + 土or日 + 平日夜1~2時間でおおよそ10人日ぐらいなので十分な成果だと思います。

副産物まとめ

Codex+バイブコーディング用のAGENTS.md

コーディングルール

Domain設計ガイドライン

他

感想・教訓

• ゲーム開発において、AIに最初から100点満点を求める必要はない
  • 設計が得意な人は設計に、実装が得意な人は実装に、50点と50点を取れればそれでよい
  • いわゆる divide and conquer 🍆
• 開発中も改善すべき振る舞いが見られたらguidelinesにどんどん追加する
• 定期的に（マイルストーンごとに）セルフレビューを行わせる
• EditModeTest/PlayModeTestだけでなく実行してテストさせる
  • UnityCLILoop作ってくれてありがとうございます

よくわからない解説図

「設計」と「実装」をまとめて投げてしまうと、AIはそれを達成するためにエネルギーが注がれるので、汎用性や拡張性を加味しない成果物が出来てしまう。

それぞれにゴールを設定し分けてAIに渡すことで、設計として高品質なゴールと、実装として高品質なゴールの両方に到達出来る

この図いらなかったかもしれません

宣伝

業務用にガチで設計したUnityアーキテクチャをMITライセンスで公開しました！

シーン基盤、ダイアログ基盤、ローカライズ、アセット管理、シーンアニメーション、入力のレイヤー制御など、
「ゲーム本編と関係ないのにゲームとして成立させるためには、めんどくさいけど絶対に作らないといけない機能」
そんなところを全部任せられるアーキテクチャフレームワークです。

もちろんAIとの親和性も◎！

VContainer + UniTask + クリーンアーキテクチャなので、
まぁ…ほんの少し難しいかもしれませんが、Unity開発にありがちなバグが減り、安定した品質を高速に実装・開発することが出来ます！

そして今ならAIに安定して利用させるためのプロンプトもついてきます！