第12章　AIエージェントとの開発プロセス

コードを書かずに、ゲームを作れるのか

GeoGainerを作り始めた理由の一つは、AIエージェントだけで、友人と遊べるゲームをどこまで作れるのかを確かめたかったからである。自分は業務でAIを使ってWebを検索させたり、情報を整理させたりはしていた。ただ、AIエージェントに開発を任せる経験はなかった。

ゲームを一行も書かずに作れるのか。実際に使ってみて、やり方を覚えられたら、いつか自分のオリジナルゲームをもっと作れるかもしれない。最初は不安というより、どこまでやってくれるのだろうという期待の方が大きかった。

最初のNormal Modeには公開されているルールがある。なので、ルールを実装すること自体はAIでもできるだろうと思っていた。実際、Codexを中心に進めて、ルーム、リアルタイム同期、ゲーム進行、盤面、テスト、公開準備までを作り、最後は友人と勝利まで遊んで確認した。

始める前には、どのような指示や設定を置けばよいかもCodexへ聞いた。その提案をもとに、プロジェクトの目的や人間とAIの役割をAGENTS.mdへ書き、Planner、Builder、Reviewerのスキルも置いた。これらがどれだけ効いたかを比較できる記録はない。ただ、会話の外に判断の置き場を作り、AIが毎回そこから現在地を読み直せるようにしたことは、長い開発を続ける前提になったと思う。

人間が決め、AIが形にする

Phase 2でExtreme Modeを作り始めると、公開ルールを実装するだけでは済まなくなった。人数、盤面、キャラクター、能力、世界観に、外から与えられた正解はない。ここは自分が決める必要があった。

最上位モデルを使っていたときは、考えたルールを言葉にすると、かなり高い精度で意図を理解して実装してくれる感覚があった。自分はキャラクターのイラストやゲームのクリエイティブを進め、その間にAIが実装を進める。この分業はかなりよかった。コードを書く代わりに、ゲームとして何が面白いか、どう見えてほしいかに集中できた。

ただし、何でもAIに任せればよいわけではない。プレイヤー向けの文章や世界観の最後の仕上げは、人間が担うべきだと思っている。AIに骨格やアイデアを出してもらうことはできるが、最後のフレーバーや言葉の選び方には、自分のアイデアを入れたり、直接直したりした方がよい。

受け入れの判断は、実際に遊んで行う

自分はコードレビューをほとんどしていない。その代わり、AIが実装したものを実際に遊び、受け入れられるかを判断してきた。AIが「問題ない」と言っても、操作しづらかったり、画面が分かりにくかったりすれば、それは問題である。

GeoGainerの盤面にはCanvasを使った。これは当初から分かっていたことだが、ブラウザ自動化で盤面を操作するには少し工夫が必要になる。今振り返ると、SVGであれば自動化しやすかったかもしれない。この点は第4章で詳しく触れている。

だからといって、人間が毎回ゲームの最初から同じ確認をするのは大変である。特定のキャラクター能力や場面をすぐ開けるデバッグシナリオを作り、必要な状態を用意してから画面を確認できるようにした。人間の体験評価は残しつつ、そのための準備はAIに手伝ってもらう。これが現実的だった。

モデルの品質と利用枠

最初の二つのPhaseではCodexを集中的に使った。一度利用枠をリセットできたため、そのまま進められたが、Phase 3の頃にはWeekly limitが尽きた。そこでCursorも使い始めた。

Cursorでは、Codexと同じような使い方を続けられるように、AGENTS.mdやスキルを適宜整えた。通常の実装タスクであれば、CursorのAutoモデルでも問題なく進められたと思う。ツールを変えても、プロジェクトの目的、判断の境界、現在地を読み直す場所まで作り直さずに済んだ。

一方で、モデルの選択は軽視できなかった。CSSを直していたとき、Lunaでは何度もやり取りしても意図が伝わらず、かなりストレスを感じた。Solへ変えると、一度で直った。厳密な比較ではないが、曖昧な見た目の修正や、手戻りが大きい作業では、より強いモデルを使う価値があると感じた。

もちろん、強いモデルは利用枠を速く消費する。品質、待ち時間、利用枠をどう配分するかは、AIエージェント開発でも人間が判断する部分として残る。すべての作業に最上位モデルを使うのではなく、作業の性質に応じて使い分ける方がよいと思っている。

開発終盤で、管理したいものが変わった

大きな機能を一つずつ作っていた間は、TODOファイルで十分だった。ところが主要な機能がほぼ揃うと、小さなUX改善、運用上の作業、追加したいアイデアが次々と思いつく。何を思いついていたか、何に着手しているか、どこまで実装し、どこまでdevelopへ反映したかを頭で追う負担が大きくなった。

同じ頃、Codexの利用枠も意識するようになった。アイデア整理、要求整理、リポジトリを読んだ上での設計、設計レビューは、ファイルを書き換える作業ではない。GitHub連携を使えば、ChatGPTのChat modeからリポジトリやIssueを読める。ならば、考える作業はChatGPTへ寄せ、CodexやCursorは実装へ集中させた方がよい。

こうしてGitHub ProjectとIssueを、開発の中心に置くことにした。思いついたことはProjectのBacklogへ入れ、本格的に取り組むと決めたものをIssueにする。ChatGPTとの壁打ちで要求と設計を固めたら、Issueへ残す。自分が内容を確認して実装してよいと判断したら、approvedラベルを付ける。

Issueは、単なるタスクではない。ChatGPTで考えたことを、CodexやCursorの実装へ渡す引き継ぎ書でもある。実装側は、会話の流れに依存せず、Issueを入口にして作業を始められる。

小さなタスクが並列に進むことを考え、実装ではタスクごとにブランチを切る。実装と確認が終わったものをdevelopへ統合する。Projectは状態を見渡す場所、Issueは目的と設計を渡す場所、ブランチとGit履歴は実際の変更を残す場所として分けている。

とはいえ、数分で終わる修正まで、必ずBacklog、Issue、設計レビュー、approvedを通すわけではない。プロセスの方が重くなるなら、直接直してよい。この仕組みはルールを守るためではなく、認知負荷とAIの利用コストを下げながら、開発を続けるために作った。

この運用を長く続けた結果は、まだ分からない。それでも、AIが実装を担い、人間が目的、ゲーム性、世界観、受け入れを担うという最初からの分業を、開発終盤の小さなタスクにも続けるための形にはなったと思う。