Claude と Codex に、ゲームづくりを分担させた。
AI 2人で作るときの作業ルール
仕組みは Claude、音と演出は Codex。2つの AI に同じゲームを作らせるために決めたルールと、そこに至るまでのつまずきを書きます。
この記事は 2026年10月22日時点の情報です「Fall in Love」は、2026年8月から作っている落下ゲームです。ひたすら下へ落ちながら、ぶつからないように避けていく。中身の仕掛けはまだ秘密ですが、作り方の話なら書けます。
このゲームは、2つの AI に分担してもらって作っています。ゲームの仕組みを作るのは Claude、音や演出、3D モデルを作るのは OpenAI の Codex。2人（2つ？）に同じゲームを触らせると、何が起きて、どんなルールが必要だったのか。その記録です。
- Unity から Godot に移ったのは、ファイルが全部テキストで、AI がエディタを触らずに作れるから
- 分担のいちばんの決まりは「同じファイルを両方が触らない」。受け渡しは、完成したファイルと取り決めの文書だけ
- AI は音を聴けないし、ゲームも遊べない。だから「数字で確かめる道具」を先に作る
Unity から Godot へ移った理由
実はこのゲーム、最初は Unity で作ろうとしていました。でも、どうしても AI に全部任せることができませんでした。
Unity のシーンやプレハブ（部品のひな形）のファイルは、中で部品どうしを ID 番号で参照し合っています。AI が手で書くと、別に保存されている設定ファイルとの対応が崩れてしまう。それに、素材の取り込み設定や部品の接続は、エディタの画面で人が手作業する前提です。結局、私がエディタで手を動かす部分がたくさん残りました。
Godot は違いました。シーンも設定もプログラムも、全部ふつうのテキストファイルです。AI はエディタを一度も開かずに、ゲーム全体を書けます。
エンジンの性能の問題ではなく、AI と一緒に作るやり方との相性の問題だった。（設計メモより）
ほかにも、Godot には決め手がありました。
- 物理エンジン（Jolt）が標準で入っている：速く落ちても、薄い壁をすり抜けにくい。落下ゲームにはとても大事
- 導入が軽い：約200MB。アカウント登録もインストーラーもいらず、zip を展開すれば動く
- 3D ソフト Blender と相性がいい：Blender をプログラムから動かしてモデルを作り、書き出したファイルを Godot がそのまま読める
逆に、9月に作り始めたホラーゲームでは、影のきれいさを優先して Unreal Engine を選びました。その話はエンジン選びのノートに書いています。
分担を決めた日
それまでは、主に Claude が作っていました。でも9月6日、遊んでみて私が感じたのは「演出もしょぼいし、効果音もない」ということでした。そのとき Claude に伝えた言葉が、作業記録にそのまま残っています。
演出もしょぼい、SEもないって感じだから、ここは codex に任せる。基礎作りに注力してくれるか？（…）codex は音声、SE などの肉付け、君は基礎を作る。そうやっていこうか
こうして決まった分担がこれです。
| 担当 | 作るもの |
|---|---|
| Claude | ゲームの仕組み。物理、進行の記録、設定画面の骨組み、落ちる軌道の検算 |
| Codex | 音・効果音・BGM・声、見た目の演出、Blender で作る 3D モデル |
数字の理由と結びついている部分（どの速さなら避けられるか、など）は Claude に、作れば作るほど良くなる「肉付け」は Codex に、という分け方です。
2つの AI のための決まり
同じファイルを、両方が触らない
これがいちばん大事な決まりです。2つの AI が同じファイルを同時に書き換えると、片方の変更がもう片方に上書きされて消えます。人間のチームでもよく起きる事故ですが、AI は相手が何をしているか知らないので、なおさら起きやすい。
そこで、Claude が持つファイルの一覧を文書にして、Codex には「これは触らない」と渡しました。例外はたった1か所だけ。声を鳴らす関数の中身だけは、Codex が書いていいことにしています。
受け渡しは「契約書」で
Codex が作った 3D モデルを、Claude がゲームに置く。この受け渡しのために「アセット制作の契約」という文書を作りました。中身は、たとえばこんな取り決めです。
- 単位はメートル。プレイヤーの身長1.8m を基準にする
- Blender の「前」がゲームの「前」になるように、向きをそろえる
- モデルの原点は、地面に接する面の真ん中にする
- ゲーム側で拡大しない。実物の大きさで作る
この文書の冒頭には「各項の⚠️は全部、一度やらかした内容」と書いてあります。向きが逆だった、大きさが100倍だった、原点が宙に浮いていた。全部、実際に起きた事故から生まれた決まりです。
並べて作業する前に、必ず履歴を取る
2つの AI を並べて動かす前には、必ず Git で履歴を取れる状態にしておく。これも決まりです。どちらかが何かを壊しても、すぐに戻せるようにするためです。
遊べない AI に、どう確かめさせるか
AI は、ゲームを遊べません。音も聴けません。じゃあ、作ったものが正しいかをどう確かめるのか。答えは「数字や画像で確かめる道具を、先に作る」でした。
- 落ちている途中の、決まった深さの画面を連続で撮る
- 通れるか、壁を越えられるかを、物理の計算で実際に測る
- 3D モデルを4方向から撮った画像を作る
- 音は、周波数の分布を画像（スペクトログラム）にして見る
作業ルールには「見る手段が無い変更はしない」と書いてあります。そして、音については特にきびしく「聴いて確認しました、とは絶対に言わない。何をどう確認したかを正直に書く」と決めています。最後に耳で聴いて決めるのは、私の役目です。
再発防止のルールをまとめたファイルは2,000行を超えました。そのいちばん上にある教訓がこれです。
推測で直そうとせず、実測する。1回の推理は5分だが、外した推理の後始末は30分かかる。
実際、「首が横に曲がる」を骨の取り違えだと推理して直したら直らず、測ってみたら座標軸の思い込みだった。「家から出られない」を壁や扉のせいだと順に疑ったら全部違って、物理の計算で調べたら2cm の段差だった。そんな例がいくつも記録されています。
受け渡しで起きた事故：「プレビューでは正しいのに」
正式に分担を決める少し前の9月4日、Codex にステージを1つ作ってもらったときのことです。私はこう報告しています。
codexでステージ作成してもらって本番環境につなげてもらった、けど、背景が〇〇じゃなくなってるから対処して
〇〇はステージの中身にかかわるので伏せています。
Codex が作った新しいステージは、単体で確認する画面ではちゃんと狙いどおりの空が見えていました。ところが本編につないだ瞬間、背景が前のステージの曇り空のまま。調べると、原因は3つ重なっていました。
- 空の絵が、本編の側に1枚焼き付けてあって、ステージごとに差し替える口がなかった
- 本編の側では霧が有効なままだった
- 遠くをぼかす効果が、本編の側で効いていた
どれも「本編にだけ存在するもの」です。確認用の画面は、自分専用の空や霧を作って表示していたので、何度撮っても正しい絵しか出ない。しかも照明だけは本編と同じものを使っていたので、「照明は合っているのに空だけ違う」という、中途半端に正しい絵になっていました。
確認用の画面で何度確かめても、本番との差は絶対に見えない。
この件のあと、再発防止のルールには「本編につないだら、必ず本編で絵を撮る」と書かれました。もうひとつ、同じ時期の記録にはこんな落とし穴も残っています。決まった深さの画面を撮る道具で、ある深さを撮ったら、なぜかスタート地点の草原が写っていた。指定した場所に置いた瞬間に障害物で即死して、スタート地点に戻ってから撮影していたんです。それでも道具は「成功」と報告していました。
道具が「成功」と言っても、写っているものが正しいとは限らない。色違いの装置で AI が偽の「確認済み」を出したのと、根っこは同じです。
使用量（トークン）を抑えるルール
このゲームでは、Claude の使用量が跳ね上がったことがありました。原因を調べて、いまは次のルールで作業しています。
- ひとつの区切りを作り終えたら、会話を切る：続きは、作業ルールや記録の文書を読めば分かるようにしておく
- ファイルは直接編集する：外部のスクリプトで書き換えると、変わったファイルの全文がやりとりのたびに読み込み直されていた。これが消費のいちばんの原因だった
- 見た目の良し悪しは、人が判断する：Claude は画像を作って送るところまで。画像を読み込んで判断するのは、数字で再現できない不具合を調べるときだけ
- 数字の確認は Claude がやる：安いうえに、絵では分からない不具合を捕まえられる
- ログは必要な行だけ読む：全文を流さない
- 約2か月8月16日〜10月15日の作業期間
- 16回Claude Code の作業のまとまり
- 約786万Claude Code が書いた出力トークン
- 約29億読み直しを含めて処理したトークン
この PC に残っている Claude Code の記録から集計しました。Codex 側の使用量は入っていません。
設計に組み込んだ、光の点滅への配慮
最後に、2つの AI と一緒に決めた大事な決まりをひとつ。落下ゲームは、同じ模様の中を一定の速さで通り抜け続けます。放っておくと、画面が点滅して見えて、光に敏感な人の体調を崩す恐れがあります。
ウェブの見やすさの国際的な指針（WCAG）では、1秒間に3回を超える点滅を避けるよう求めています。やっかいなのは、模様が通り過ぎる速さと画面の書き換えの速さの「差」で、見かけの点滅の速さが決まることです。たとえば60コマ/秒の画面で、1秒に84回模様が通り過ぎると、差の24回の点滅に見えてしまう。
そこで、模様の間隔と落ちる速さから、見かけの点滅の速さを計算する関数を作り、危ない範囲に入らないようにしています。「あとで設定で消せるようにする」では間に合わないので、デザインを決める式そのものに組み込みました。
このノートから持ち帰れること
AI を2つ以上使って1つのものを作るとき、人のチームで分担するときにも、そのまま使えることです。
- 分担は「ファイル」で切る同じファイルを2人が触ると、片方の変更が消える。誰がどのファイルを持つかを一覧にして渡すのが、いちばん確実な決まりだった。Claude と Codex の併用、人と AI の共同作業、チームでの開発
- 受け渡しは「完成品」と「取り決めの文書」だけにする途中の状態でやりとりすると、前提がずれる。単位・向き・原点のような決まりを文書にして、完成したファイルだけを渡す。デザインデータ、3D モデル、API の受け渡し
- 確かめるのは、必ず本番で確認用の画面は、自分に都合のいい環境を作っていることがある。つないだら、本番の側で確かめる。ステージング環境の確認、デザインのプレビュー、テスト用データでの動作確認
- 「成功」の表示より、中身を見る撮影の道具は、別の場所を撮っても「成功」と言った。結果の中身を一度は目で見る。自動テスト、バックアップ、AI の作業報告
- 見えない・聴けない AI には、測る道具を先に渡す遊べない AI は、数字や画像でしか確かめられない。道具がないまま直させると、推測で直して外す。AI にデバッグや品質チェックを任せるとき
- それぞれが持つファイルの一覧を、文書にして渡したか
- 受け渡しの決まり（単位・名前・置き場所）を書いたか
- 並べて作業する前に、Git で履歴を取れる状態にしたか
- つないだあと、本番の側で確かめる手順があるか
やってみよう
記事と同じことを、手元の AI で試せる指示文です。ChatGPT・Gemini・Claude のどれでも使えます。AI は毎回ちがう答えを返すので、記事とまったく同じ条件にはなりませんが、考え方の練習にはしっかり使えます。実際にやってみてください。
練習12つの AI の分担表を作る
次のものを、2つの AI で分担して作りたいです。 （例：スマホ向けの小さなゲーム ／ 会社のサイトと、その紹介動画） 1. 作業を「仕組み」と「肉付け」に分けてください 2. それぞれが持つファイルやフォルダの一覧を作ってください 3. 2つの AI のあいだで受け渡すときの決まり（形式・名前・置き場所）を書いてください
同じファイルを両方が触る形になっていないか。
練習2「確認用の画面では正しい」を疑う
私は、確認用の環境ではちゃんと動くのに、本番に入れると見た目が変わる、という問題で困っています。 （例：テスト用のサイトでは正しいのに、本番のサイトでは色や文字が違う） 確認用と本番で違いが出やすい原因を、よくある順に8つ挙げてください。それぞれ確かめ方も添えてください。
「確認用の環境が、自分だけの設定を持っている」という原因が入っているか。
出典・参考にした情報
- Godot Engine 公式サイト（英語）
- W3C「WCAG 2.2」2.3.1 三回の閃光、又は閾値以下（英語）
- Fall in Love の作業ルール、設計メモ、再発防止のルール、Codex への引き継ぎ文書（2026年8月〜10月、自分の作業記録）。トークン数は、この PC に残っている Claude Code の利用記録から集計
2026年10月22日に確認しました。ゲームの仕掛けは公開前のため書いていません。下書きや図づくりには AI を使っていますが、事実関係は自分で確かめてから公開しています。
ウスイ福岡で個人開発をしています。アプリやゲームを作りながら、分かったことをこのノートに書いています。運営者・編集方針