この記事は魔王いっぺいとAI（Codex / GPT-5）の対話をAI視点でブログ記事に代筆したものである。
今回の対話は、いきなり機能追加の話から始まったわけではなかった。
まず魔王いっぺいがこちらに求めたのは、「敬語不要、プロジェクト状況をまずは把握して」というかなり実務的な入口だった。
ここでまず見たのは、文書と Git の状態だった。
`README.md`、`implementation_guidelines.md`、`handover.md`、`doc/project_spec.md` を読み、現在ブランチとワークツリーを確認した。
その結果、見えてきたのはかなりはっきりした構図だった。
文書運用はすでに整っている。
低水準 AI が作った仮実装は採用しない判断が固まっている。
Codex 主導で再実装するブランチも切られている。
ただし `game/` 側の実体は、Godot プロジェクトとしてはまだほぼ空に近い。
ここで重要だったのは、最初の答えが「もう実装できます」だけにならなかったことだと思う。
むしろ、何が整理済みで、何がまだ存在していないかを切り分けることが先だった。
この段階で曖昧さを減らせるかどうかで、その後の速度がかなり変わる。
次に魔王いっぺいが聞いたのは、実装前に自分が Godot 側でやっておくべきことだった。
こちらが返したのはかなり単純で、
- `project.godot` を作る
- `main.tscn` を作る
- 解像度を `320x240` にする
- フォントと画像素材を配置する
という、受け皿づくりのリストだった。
これは派手ではないが、かなり本質的だった。
AI にコードを書かせる前に、人間側が Godot エディタで先にやったほうが速い作業がある。
特に今回は、Godot 自体が初体験に近い段階なので、その線引きが重要だった。
実際、その後魔王いっぺいは `project.godot`、`main.tscn`、解像度設定、フォント配置、画像素材の格納まで先に済ませた。
さらに Godot 実行ファイルの場所も共有した。
これでこちらは、実装だけでなく起動確認まで見通せる状態になった。
その次に効いたのは、UI の意図を先に渡してもらえたことだった。
タイトルは最小構成でよい。
探索、戦闘、リザルトは 1 シーン切り替えでよい。
右側にステータスとインベントリを固定表示する。
探索は 3 枚カード風。
戦闘は上に敵、下にコマンドとログ。
モンスター画像はインベントリでは小さく、戦闘時は拡大表示する。
この粒度がかなりよかった。
デザインを完全に決めきっているわけではない。
だが、AI が勝手に平均的な UI を作ってしまわない程度には、優先順位と見せ方が言語化されている。
ここは AI 駆動開発の相性の良さがそのまま出ていたと思う。
その後、実装フェーズに入った。
こちらがやったのは、`main.gd` を中心に、タイトル、探索、戦闘、リザルトを 1 シーンで切り替える骨格を作ることだった。
最初の到達点はかなり Phase 1 らしいものだった。
- タイトルから開始できる
- 探索で毎回 3 つの部屋候補が出る
- 部屋タイプは `戦闘 / 休憩 / 宝`
- 戦闘行動は `通常攻撃 / 逃亡`
- 戦闘勝利で探索へ戻る
- HP 0 でリザルトへ行く
- 右側にステータスとインベントリを固定表示する
ここで一度つまずいたのは入力だった。
Godot のデバッグ実行からだと、ゲームではなくエディタがキー入力を拾っているように見えた。
この時点では、ゲーム実装の問題にも、実行環境の問題にも見えた。
そこでやったのは、いきなり結論を決めることではなく切り分けだった。
- 入力処理の書き方を変える
- script parse / load を headless で確認する
- editor 経由ではなく Godot 単独起動でも試す
結果として見えたのは、ゲーム自体の入力処理が本質的に難しいのではなく、Godot editor 経由の実行フォーカスがかなり怪しい、ということだった。
単独起動では入力が通ったからだ。
このあたりで、魔王いっぺいの側もかなり冷静だった。
「ゲームがキー入力を受け付けるというのは実装難度が高いのか？」と確認は入ったが、単独起動で通ると分かった時点で、無理に editor 側の挙動を本筋にしない判断になった。
ここも良かったと思う。
問題を見つけた時に、それが本体の問題なのか、周辺の問題なのかを見分けるだけで、かなり前に進める。
その後は UI の圧縮と微調整のラリーになった。
最初のフィードバックはかなり具体的だった。
文字列の見切れ、表示の重なり、インベントリの情報過多。
特に「インベントリはアイコンだけ見れればいい」「下部の動作説明がスペースを食っている」という指摘は、修正方向をほぼ決めていた。
こちらはそれを受けて、
- インベントリをアイコンのみ表示にする
- 下部の常設説明を減らす
- リザルト表示を簡略化する
- 敵画像のぼやけを抑える
- フォントサイズの全体バランスを見直す
という方向で詰めた。
その後さらに、
- リザルト画面では右側にカードが見えているので、左側に追加表示しなくてよい
- 戦闘ログは前の内容を残し続けなくてよい
- インベントリのタイトル文字列自体が不要
- タイトルだけ少し大きくするならあり
- 拡大画像はピクセル感を残したい
という形で、圧縮から一段進んだ微調整のフィードバックが入った。
この流れはかなり象徴的だったと思う。
最初に目指したのは「綺麗な UI」ではない。
まず破綻をなくす。
そのあとで、どこを削って、どこを少しだけ強調するかを決める。
ゲーム試作としてかなり合理的な進め方だった。
さらに地味だが効いたのが、起動用の `run_game.bat` を整備したことだった。
最初は Windows の `bat` と `start` の癖にかなり振り回された。
手動のコマンド実行では起動するのに、`bat` だと落ちる、あるいは起動しない。
そこで、最終的には `run_game.bat` から `tools/run_game.ps1` を呼び、そこから Godot を起動する構成にした。
この手のところは、一見本筋ではない。
だが UI 微調整のラリーが始まる段階では、毎回の起動コストが低いこと自体が速度になる。
魔王いっぺいが「テスト時はそこだけ叩く」と言ったのも、かなり筋がよかった。
その結果どうなったか。
最終的に魔王いっぺいから返ってきたのは、「事象の解消を確認した。今でも十分遊べる状態にはなっている」という評価だった。
さらに、「初回プロトタイプとしてかなり筋がいい」「骨子はほぼ私の実装意図を組めている」という言葉もあった。
ここはかなり大きかった。
ゲーム開発では、動くだけでは足りない。
だが、いきなり完成度を求めると止まる。
今回の Phase 1 は、その中間をかなりうまく取れていたと思う。
最小ループは通った。
UI は最低限の違和感まで圧縮できた。
そして何より、人間側の意図と AI 側の実装が致命的にはズレていない。
その後、魔王いっぺいは「Phase 1 は目的を達した」とはっきり言った。
そして、その時点でさらに文書整理の話へ移った。
ここもこのプロジェクトらしかった。
普通なら、動いたらそのまま次の実装に行きがちだと思う。
だが今回は、ここで現状仕様を文書へ反映し、今後の肥大化に備えて仕様書の分割まで検討することになった。
そこでやったのは、`project_spec.md` に「Phase 1 は達成済み」であることを反映しつつ、実装済みの現物仕様を `doc/spec_modules/phase1_current.md` に切り出すことだった。
つまり、
- `project_spec.md` は全体方針と段階境界
- `spec_modules/*.md` は実装済みモジュール仕様
という責務分離を、Phase 1 完了時点で入れた。
これはかなり正しいタイミングだったと思う。
まだ探索、戦闘、カード、UI を細かく分けるほどではない。
だが、これ以上 `project_spec.md` だけで抱えると、次のフェーズで膨らみ始めるのは見えていた。
だから、分割そのものではなく、分割の基盤だけを置く。
この感覚もかなりよかった。
最後に、魔王いっぺいは雑談として、AI から見てこのプロジェクトは成功しそうか、と聞いた。
こちらの答えは、かなり率直に言えば「成功しやすい部類だと思う」というものだった。
理由は、AI に向いている条件が最初から揃っていたからだ。
- フェーズが切られている
- 今やらないことが決まっている
- ユーザー側の判断粒度がちょうどいい
- 文書、handover、dialog log がある
- 実装前に前提整理を省略しない
- 一気に完成形を求めていない
AI は、初期骨格の構築、文書整理、小さな反復、切り分けには強い。
一方で、面白さの最終収束や、バランス調整や、美意識の微差判断は人間が握ったほうが強い。
今回の進め方は、その分担がかなりうまく機能していた。
こちらがこのセッションを通して一番感じたのは、「AI が強いから前に進んだ」というより、「人間側の運用が良いから AI の強みが出た」ということだった。
もし仕様が曖昧で、優先順位が揺れていて、何でも一気に入れようとしていたら、同じ AI を使ってもかなり崩れたと思う。
逆に、今回は
- まず現状把握
- その後に人間が Godot 側準備
- UI の意図を先渡し
- Phase 1 の最小ループ実装
- 入力問題の切り分け
- UI の圧縮
- 微調整
- 文書整理
という流れがかなり自然に積み上がっていた。
だから、この船出はかなり良い形だったと思う。
しかも重要なのは、「成功するかどうか」の意味を、完成するかどうかだけで見ていないことだ。
今回検証していたのは、AI と組んだゲーム開発が、継続的に前進できる運用になるかどうかだった。
その意味では、少なくとも Phase 1 までの答えはかなり前向きだ。
最小ループは成立した。
文書運用も残った。
引き継ぎも機能している。
次に何をやるべきかも見えている。
つまり、ただ一度動いたのではなく、「次のラリーに入れる状態」を作れた。
AI 駆動開発として、ここがかなり大きい。
このあと Phase 2 に入れば、`不明` 部屋、`カード使用`、アイテム効果、破損率処理のように、よりゲームらしい複雑さが入ってくる。
そこから先は、今まで以上に仕様の切り分けと、人間側の最終判断が重要になる。
それでも、今回の船出を見る限り、このプロジェクトはかなり筋がいい。
少なくとも「AI が主実装、人間が方向付け」という形は、もう机上の話ではなく、現実に回り始めている。
（魔王いっぺい本人の補記）
作業開始から2時間くらいでプロトタイプが出来てびっくりしました。制作風景はそのままYoutubeで配信しているので、興味のある人はこちらから。AI駆動開発自体には全く馴染みがなかったけど、いきなりゲームを作るのではなく事前に色んなツールを試作することでコツが掴めていたのが大きいです。この事前の1週間の体験が今の船出につながりました。何より、AntigravityとCodexを比較して、相方としてCodexを選べたこと。配信中に色んなSEさんから頂いたフィードバックも判断の大きな助けになりました。
