ゲームを作ってみようとCodexを使い始めたら、気付けばAIに役割を付け、Sprintまで回していました。ゲーム作りの横で、AIの仕事の割り振りまで試し始めています。
1. 最初は、Codexにゲームを一本作ってもらった
ゲーム開発の苦労を味わってみたい、というところから始めました。ChatGPT Plusを契約したので、じゃあCodexも試してみようと、自宅PCで個人開発を始めました。題材に選んだのがProject Ashfallという小さなブラウザゲームです。敵に印を付け、敵同士を縫うように移動してまとめて起爆する「灰縫い」が、遊びの中心です。
最初の依頼文はChatGPTと相談して作りました。小規模なアクションローグライトを、遊べるプロトタイプにする。ゲームデザインや技術スタックの細部はCodexに任せ、動くものを作り、テスト、不具合修正、自己レビューまで進めてもらう、という依頼です。
動かしてみると、ちゃんと遊べるゲームになっていて、AIでここまで形になるのか、と驚きました。しかもCodexは、実装するだけでなく、自分でテストを増やしながら検証している。ゲームを触るのも、どう作っていくのかを見るのも面白くて、今度は自分が遊んで気になったところを直してもらいたくなります。
私が遊んだ感想をChatGPTへ伝えると、改善内容がプロンプトになって返ってくるので、それをVS CodeのCodex拡張へ渡しました。修正後のものをまた遊び、気になるところを返して、次の修正を頼む。設計は私とChatGPT、実装・テスト・自己レビューはCodexという分担で、このやり取りを続けていました。
2. 毎回同じ説明を書くのが、面倒になってくる
次の修正を頼むたびに、共通ルールも依頼文へ入れていました。バランスを勝手に変えない、mainへ勝手にmergeしない、日英対応を維持する、といった注意まで毎回書くので、今回直したいことを足すとプロンプトが長くなります。また同じ説明を書いているな、とだんだん面倒になってきたうえに、必要な注意を全部入れたかも気になるようになりました。
この頃、ChatGPT Plusでもまだ試していないことをやってみたくて、ChatGPTに相談したところ、Project Ashfallの開発を複数AIに役割を割り当てて組織化する案が出てきました。実装とレビューと進行を別の担当にする、という使い方もできるのか。それなら試してみようと、提案された5役を置くことにしました。
一人で趣味ゲームを作るにしては、急に大げさな体制になりました。
| 役割 | 担当する仕事 |
|---|---|
| Human Producer／私 | 何を作るか、遊んでどうだったか、採用するかを決める |
| Director／ChatGPT | 感想や要望を目標・作業範囲へ整理し、レビュー結果をまとめる |
| Implementer／Codex | 承認した範囲を実装し、テストと自己検証を行う |
| Game Design Reviewer／AI | 手応え、分かりやすさ、ゲームバランスを見る |
| QA Reviewer／AI | 不具合、回帰、確認不足を見る |
レビューは、Implementerとは別の会話・コンテキストへ依頼します。これまでの作業ではQA Reviewerを使い、ゲームバランスを扱うGame Design Reviewerはまだ未稼働です。
3. 共通Markdownを渡したら、本当にSprintが回り始めた
毎回同じ説明を書き直す代わりに、共通ルールはAGENTS.mdへ、今回の目標・作業範囲・完了条件はplans/current-sprint.mdへ置く形にしました。Sprintと共通Markdownを使う案も、ChatGPTとの相談から出てきたものです。
作業範囲を承認したら、Codexには「AGENTS.mdとplans/current-sprint.mdを読んで進めてください」くらいの指示で頼めます。実際にこれで実装が始まったので、毎回あの長いプロンプトを用意しなくていいのはかなり楽でした。
最初の実装テーマとなったSprint 1〜2では、ElectronとTauriでWindows向けポータブル版を試作・比較しました。Implementerが試作と測定結果を返し、QAが未確認事項や懸念を出してくれるので、私も実際に遊んで採否を決めます。私の環境では、Electronは時折カクつき、Tauriは全画面時のカーソル挙動が気になりました。遊べるところまではできたけれど、この状態で採用したいかというと引っかかるので、どちらも一旦保留にしました。
こんな短い依頼から試作が返り、別の担当のレビューが加わって、私が採否を決めると次の作業へ進める。本当にSprintが回るんだ、と分かると、この形でもう一つ作ってみたくなります。会話を切り替えて渡すのは私ですが、実装結果や採否がcurrent-sprint.mdに残るので、文書を更新する手間はあっても、次の担当へまた最初から説明し直さずに渡せます。
4. QAが、実装担当の見ていない不具合を拾ってくれた
ポータブル版は保留にして、次に進めたのが、調整や確認に使える開発用デバッグUIです。v0.8.0で進めたSprint 3では、任意の強化を付けたり、敵やボスを呼び出したりして、試したい場面をすぐ用意できるようにしました。
実ブラウザで未確認の範囲はSprintに記録されていましたが、Implementer側の自動テストは通っていたので、まぁ大きな問題はないだろう、くらいの気持ちで、別会話のQAに確認してもらいました。すると、操作前のタイトル画面に開発モードの表示が出ていない、という指摘が返ってきました。デバッグモードなのに、この画面では通常起動と見分けがつかなかったのです。
自己検証ではテスト側で先にゲームを開始していたため、操作前のタイトル画面を見ておらず、QAがそこをブラウザで確認していました。Implementerに表示を修正してもらい、QAの再確認で解消を確かめました。「ちゃんと別担当にした意味があるな」と思いながら、今度はその結果と自分で触った感触を合わせて、採用条件を決めていきます。
5. 私が決めるのは、何を良しとするか
デバッグUIは、自分で使ってみてもかなり便利で、今後の調整や確認にも使いたくなりました。でも、一般向けの公開版で開発者向けの機能が使える状態にはしたくないので、QAの結果を受け取ったうえで、「公開用ZIPではデバッグ機能を使えないこと」を採用条件に加えました。追加の実装で対応してもらい、公開用ZIPもQAで再確認しました。
Human Producerという名前を付けてからは、自分が何をする役なのかも考えやすくなりました。設計の整理や実装方法、テストの組み立てはAIに任せながら、私は遊んで「面白いか」「この方向へ進めたいか」「この問題を許容するか」を決めます。
実装と検証が終わった後のレビュー用commitまではAIに任せ、mainへのmerge、push、tag、公開は人間の明示指示で行う、という境界も決めています。
細かい実装指示を書くより、今は遊んで「これは面白い」「これは気になる」「次はこっちを試したい」を返すことに時間を使っています。気になるところを見つけたら方向を決めて、また直してもらい、遊んで確かめる。ここはやっぱり難しいし、実装をAIに任せていても、自分のゲームを作っている手応えがあります。
6. ここまで回るなら、Issueから始めてみたい
今は、次の担当へ渡すたびに私が会話を切り替えて、結果をまとめています。ここももう少し省力化できないかと思うと、GitHub Issueを入口にしてみたくなります。Issueに「やりたいこと」「背景」「完了イメージ」を置いて、そこからSprint案を作ってもらい、自分が作業範囲を承認したら実装やレビューへ渡せるようにしたい。
でも、Codexに自由に進めてもらおうとすると、権限が気になります。開発中もGitへの書き込みやコマンド実行の承認で止まることがあって、強い権限の設定を一度試しました。任せたいけれど、ゲームのフォルダ外まで操作が届く可能性があり、Windows本体の広い範囲へ権限を渡すのは怖い。それなら、Dockerの中へ実装やテストを閉じ込めて、その中で自由に動いてもらえばいいのでは、と考えるようになりました。
実装や自動テストはコンテナの中で進めてもらい、自分の実機確認はWindows側へ残す、くらいの分担を考えています。Issue連携もDocker化もまだアイデア段階ですが、人間が採否や公開を決める今の形を保ったまま、もっと任せられるところを試してみたいです。
ゲームを作るためにCodexを触っていたのに、今度はIssueの入口や、AIが動く場所まで試したくなっています。ゲームの横で、小さなAI開発組織を育てる遊びも始まってしまって、次はこの二つを自分の開発でどう回せるか見てみたい。
作っているゲームも、よければ遊んでみてください
せっかくなので、実物も置いておきます。この記事で作っているゲーム、Project Ashfall（itch.io）です。ブラウザでそのまま遊べます。
よければ遊んでみて、灰縫いの手応えや、最初に迷ったところなどを教えてもらえるとうれしいです。ほかの人がどう感じるかも、次の開発を考える楽しみの一つです。