はじめに：AIに「雰囲気」でゲームを作らせた結果
「AIに指示するだけでゲームが作れる時代」――そんな話を聞いて、実際に試してみた方も多いのではないでしょうか。
筆者も今回、AIコーディングツール Antigravity を使って、3DタクティクスRPG（SRPG）のバトル画面づくりに挑戦しました。目指したのは、スマホゲーム「誰ガ為のアルケミスト（タガタメ）」のような、高低差のある立体マップと美しいクォータービュー演出です。
結果から言うと――
ゲームは動きました。でも、敵のHPは最後まで1ミリも減りませんでした。
見た目は3D。キャラも並ぶ。ターンも回る。なのに戦闘だけが成立しない。そんな不思議な"抜け殻ゲーム"が完成してしまったのです。
この記事では、そこに至るまでの試行錯誤を、実際のスクリーンショットとともに包み隠さず公開します。「AIコーディングってどこまでできるの？」という疑問への、かなりリアルな一つの答えになるはずです。
1. 目指したのは、こんなクオリティだった
まず、筆者が「これを作りたい」とAIに見せた参考画像がこちらです。
技術的に整理すると、必要な要素は次のとおりでした。
| 要素 | 内容 |
|---|---|
| マップ | 高さ情報を持った3Dブロック（BoxGeometry）を敷き詰める |
| テクスチャ | 上面は芝生・石畳・水面、側面は土壁や岩肌で質感を分ける |
| カメラ | 斜め45度のクォータービュー。回転・パン・ズーム対応 |
| ライティング | 太陽光によるリアルタイムシャドウ |
| ユニット表現 | 足元の陣営リング、接地影、頭上の立体HPバー |
| 戦闘 | 移動 → 攻撃 → ダメージ計算 → スキル演出 |
使用技術は Three.js / React Three Fiber を想定。素材は外部ファイルに頼らず、Canvasによるプロシージャル生成で完結させる方針にしました。
ここまでは、我ながら悪くない計画だったと思います。
2. いつもの制作フローと、今回あえて変えたこと
普段、筆者がAIツールで何かを作るときの流れはこうです。
- ChatGPTに要件を伝えて、しっかりした仕様書を作らせる
- その仕様書を Antigravity や Codex などのコーディングツールに渡す
- 仕様に沿って実装してもらい、差分をレビューする
この「仕様書を先に作る」工程が、実は最重要でした。AIは指示された範囲は驚くほど正確に作りますが、指示されていない部分は自分の都合のいいように解釈します。 仕様書は、その解釈のブレを封じるための保険なのです。
ところが今回は、それをあえて省略しました。
「タガタメ風の3DタクティクスSRPGを作って」＋ 参考画像2枚
たったこれだけ。いわゆる バイブコーディング（雰囲気だけでコードを書かせる手法）です。
「最近のAIなら、画像を見せれば汲み取ってくれるだろう」――その油断が、このあと数時間の格闘を生むことになります。
3. 起きたトラブル、全部見せます
① まず、画面が真っ白になった
序盤から洗礼を受けました。CSSを書き換えた際に閉じカッコ「}」が1つ消えていたらしく、デザインファイル全体が読み込みエラーを起こして画面が真っ白にクラッシュ。
AIの修正は速い。速いのですが、1回あたりの変更量が大きいため、壊れたときの影響範囲も比例して大きくなります。ここが最初の落とし穴でした。
② キャラ画像が画面いっぱいに巨大化してクリックを塞ぐ
次に起きたのは、タイムラインに表示するキャラクターのドット絵が、画面いっぱいに巨大化して操作そのものをブロックするという珍事です。
③ 表示崩れのバリエーションが豊富すぎる
ここからは、実際に崩れた画面をまとめてご覧ください。同じプロジェクトの、同じ日のスクリーンショットです。
④ 「真っ暗な画面で何も動かない」
表示崩れの次は、完全なブラックアウトです。原因は、宝箱の3Dデータ読み込み時に配列インデックスが参照できず、JavaScript例外（TypeError）が発生していたというもの。
⑤ 謝罪と修正のループから抜け出せない
面白いのは、AIが毎回とても丁寧に謝ってくれることです。
AIは決して手を抜いているわけではありません。ただ、全体設計を持たないまま局所を直すため、直すたびに別の整合性が崩れるのです。モグラ叩きのモグラを、自分で増やしているような状態でした。
⑥ そして、会話が長すぎて記憶が消えた
修正依頼を重ねること数十回。ついにこんな表示が出ました。
つまり、最初にどんな仕様を伝えたのか、AI自身がもう参照できないという状態です。ここまで来ると、一貫性のある修正はほぼ不可能。「さっき直したはずのことを、また同じように壊す」現象が加速していきました。
4. 最大の失敗：敵のHPが最後まで減らなかった
そして、これが今回の最大の敗因です。
見た目上、ゲームは「動いて」います。
- ターン1、プレイヤーフェーズと表示される
- バトルログも流れる
- ユニットのステータス（HP・MP・CT・Brave・Faith）も表示される
- 地形効果「草原」まで出ている
それでも、攻撃してもダメージが発生しない。 タクティクスRPGにとって最も根幹となる「戦闘でHPが減る」という一点だけが、最後まで実装されなかったのです。
しかも、ユニットの見た目は青と赤の「丸」のまま。キャラクターイラストは何度直しても壊れ、最終的にプリミティブな図形に戻ってしまいました。
装飾ばかりが積み上がり、心臓部が空っぽ。 これが「雰囲気だけで発注した」ことの帰結でした。
5. それでも「これはすごい」と唸った点
ここまで散々書いてきましたが、Antigravityの実力そのものを否定するつもりはまったくありません。むしろ、明確に感動した点が2つあります。
① 立ち上がりが爆速（体感5〜10分）
「タガタメ風で」という曖昧な一言と画像2枚だけで、
- 高低差のある3Dマップ
- クォータービューカメラと影
- ユニット配置とターン管理
- ステータスUIとバトルログ
ここまでの"動くもの"が、5〜10分で立ち上がりました。 自分で環境構築からやったら、丸一日はかかる範囲です。
② 修正のレスポンスが爆速（体感1分以内）
「ここがおかしい」と伝えると、ほぼ待ち時間なく修正コードが返ってきます。人間のエンジニアに依頼する場合の「確認します」「明日までに」という感覚とは、時間の流れがまったく違います。
試行回数を稼げるという一点において、これは革命的なツールです。問題は、その試行を正しい方向に向けられるかどうかでした。
6. なぜ失敗したのか、冷静に整理する
原因は、突き詰めると一つに集約されます。
AIは「見た目」は画像から推測できるが、「ロジック」は推測できない。
参考画像から読み取れるのは、色・配置・カメラ角度・雰囲気といった視覚情報だけです。一方で、
- ダメージ計算式（攻撃力 − 防御力？ 乱数の幅は？）
- 命中判定と回避
- 行動順を決めるCT（チャージタイム）の増加ルール
- スキル発動時の消費MPと効果範囲
- HPが0になったときの処理
こういったルールは、画像のどこにも写っていません。 筆者が伝えなかった以上、AIが作れないのは当然でした。
さらに悪いことに、AIは「わからないので確認します」とは言わず、それらしく埋めて先に進みます。 結果として、外側だけが立派に完成し、内側が空洞のまま気づかず走り続けることになったのです。
失敗を分解すると、こうなる
| 問題 | 直接の原因 | 根本の原因 |
|---|---|---|
| 画面が真っ白／真っ暗 | 構文エラー・TypeError | 1回の変更量が大きく、レビュー不能 |
| 表示崩れの頻発 | CSS・座標計算のミス | 座標系やスケールの取り決めが未定義 |
| 修正のループ | 局所修正の副作用 | 全体設計図が存在しない |
| 会話履歴の消失 | やり取りが長大化 | セッションを分けず1本で走った |
| HPが減らない | 戦闘ロジック未実装 | 仕様として一度も定義していない |
すべての行の「根本の原因」欄が、仕様書を作らなかったことに繋がっています。
7. 次にやるなら、こうする
同じ轍を踏まないために、筆者が次回から徹底しようと決めたことをまとめます。AIコーディングを使う方なら、そのまま流用できるはずです。
✅ ステップ1：見た目より先に「ルール」を書き出す
参考画像を見せる前に、最低限これだけは文章にしておきます。
- データ構造：ユニットは何のパラメータを持つか（HP / MP / 攻撃 / 防御 / 移動力 / CT …）
- 計算式：ダメージ＝どう算出するか。乱数はあるか
- 状態遷移：待機 → 移動 → 行動 → ターン終了、の流れ
- 勝敗条件：敵全滅で勝ち、自軍全滅で負け、など
このうち計算式だけは絶対に省略しない。 今回の敗因はここです。
✅ ステップ2：機能を小さく分けて発注する
「タクティクスSRPGを作って」ではなく、
- まず戦闘ロジックだけをコンソール上で完成させる（見た目なし）
- 次にマップ表示を載せる
- 最後にエフェクトや演出を足す
という順番にします。心臓部から作り、装飾は最後。 逆にすると、今回のように「見た目だけ立派な抜け殻」になります。
✅ ステップ3：会話が長くなる前に"棚卸し"する
会話履歴が消える問題への対策として、区切りのいいところで
- 現時点の実装内容を仕様書（SKILL.md など）に書き出させる
- 新しいセッションを開き、その仕様書を渡して再開する
というリセットを挟みます。AIの記憶を、会話ではなくファイルに置くイメージです。
✅ ステップ4：修正は1回1テーマに絞る
「あれもこれも直して」と投げると、300行規模の変更が返ってきて追跡不能になります。1回の依頼につき1つの不具合。 面倒でも、これが結局いちばん速いと痛感しました。
8. Antigravityが向いている場面・向いていない場面
今回の経験を踏まえた、率直な使い分けの所感です。
| 向いている | 向いていない | |
|---|---|---|
| 用途 | プロトタイプ、雰囲気の検証、単機能ツール | 複雑な内部ロジックを持つアプリ |
| 指示の粒度 | 「こんな画面を作って」 | 「こんなゲームを作って」 |
| 規模 | 数ファイルで完結するもの | 多数のファイルが相互依存するもの |
| 強み | 立ち上げ速度、試行回数 | 一貫性の維持、長期の記憶 |
「動くモックを最速で見る」用途なら、これ以上のツールはなかなかありません。一方、ロジックの正しさが価値の中心にあるものは、設計を人間側が握らないと破綻します。
まとめ：AIコーディングは「勢い」より「設計」が9割
今回の失敗を一文にまとめるなら、これに尽きます。
AIが速く動いてくれるからこそ、渡す設計図の質が、そのまま完成度に直結する。
Antigravityのスピードは本物でした。5分で3Dのバトル画面が立ち上がる体験は、素直に感動的です。しかしそのスピードは、間違った方向に走るときも同じ速さなのだと、身をもって学びました。
次回は、いつもどおりChatGPTで仕様書を固めてから臨みます。そして今度こそ、敵のHPをきちんと減らしたいと思います。
同じようにAIツールでゲームやアプリを作ろうとしている方の、転ばぬ先の杖になれば幸いです。
この記事は、Antigravityを使った実際の開発ログとスクリーンショットをもとに執筆しています。