AIでゲームを作る方法｜コードを書かない私が35分で動かし、当日公開までいけた実録

35分で動いた。でも、その日いちばんの山場はそのあとだった

先に結論から。AIでゲームを作ることは、コードを書かない私でもできた。ブラウザで遊べる反射神経テストのミニゲームをAI（Claude Code）に任せたら、着手から35分で動くものが完成。型チェックもビルドも一発で通り、その日のうちにサイトで公開できた。

できたものは、画面が緑に変わった瞬間にタップして反応速度を測るゲームだ。説明を読むより触るほうが早い。まず遊んでみてほしい。

反射神経テストで遊んでみる（無料・登録不要）

ただし、この記事の本題は「35分で作れた」ではない。実装したAIの検証はすべて合格だったのに、公開前のレビューで本物のバグが1件見つかった。しかも見つけたのは人間ではなく、実装したのとは別のAIだ。「動く」と「公開してよい」の間に何があったのか。そこまで含めての実録になる。

なぜ反射神経テストだったか

思いつきで作ったわけではない。先にキーワード調査ツール（ラッコキーワード）で調べたところ、「反射神経 テスト」には月4万回ほどの検索があった。遊びのミニゲーム1本でも、探している人がいると確かめてから作るのとでは、公開後の意味が違ってくる。1ページで完結して、データベースもログインも要らない。最初のゲーム題材としての作りやすさも決め手だった。

手順1: 仕様書はコードではなく日本語——しかも書いたのは主にAIだ

正直に書くと、仕様書の文面すら私は書いていない。私が決めたのは「反射神経テストでいく」という題材の選択と、最後のGOだけだ。企画の相談をしていたAIが、画面の流れ（スタート→赤い待機画面→ランダムな時間の後に緑→タップで計測、これを5回→平均タイムと称号を表示）、フライングしたらそのラウンドはやり直し、称号にハズレを作らない、計測結果を外部に送信しない——という日本語の仕様書に整えてくれた。私の仕事は、それを読んで「これでいこう」と判断することだった。

仕様書には「実装しながら、過程をログに残して」という一文も入っていた。この記事が時間や出来事を具体的に書けているのは、AI自身が残した作業ログが手元にあるからだ。あとで振り返りたい人、記事にしたい人には、この一手をすすめたい。

手順2: AIが35分で実装した

着手は夜の19時ごろ。AIはまず、サイトにすでにある診断ページのコードを読み、デザインや部品の使い方をそっくり踏襲する方針を取った。新しく書いたファイルは3つ、既存ファイルの変更はサイトの目次にあたる1行だけ。19時35分には型チェックとビルドが一発で通り、ブラウザでの動作確認まで済んでいた。

一発で通った理由をログから拾うと、「既存ページの作りを先に読んでから書いた」のが大きかったらしい。ゼロから発明させず、動いているものの真似をさせる。人間の新人と同じで、AIにも効くやり方だと思う。

細かい作りにも、AIなりの判断が詰まっていた。たとえばタップの検知。普通のクリック判定は「押して離した」完了時に反応するため、指を離すまでの時間が計測に混ざる。そこで「押した瞬間」に反応するイベントで測る作りになっていた。連打で画面が飛ばないよう、状態が切り替わった直後の0.3秒は入力を無視する保険も入っている。ただし緑の画面だけはこの保険の対象外——0.3秒未満で反応する正当な高速タップまで弾いてしまうからだ。この例外が、のちのち伏線として効いてくる。

「バグか？」と2回焦って、2回とも濡れ衣だった

ブラウザでの検証中、バグを疑う場面が2回あった。結果から言うと、どちらもバグではない。

1回目は、緑になるはずの画面が検証ツール上では赤いままに見えた件。調べると、ゲーム側は正しく緑を指定していて、検証に使ったツールの画面描画が省エネ状態で止まっていただけだった。疑うべきは自分の観測手段、という教訓が残った。

2回目は、自動テストで3ラウンド目が先に進まなくなった件。原因はテスト側が計測タップの0.08秒後に「次へ」を押していたことで、さきほどの0.3秒の保険が設計どおり弾いていた。バグどころか、ガードが働いている証拠だった。

ちなみにこの検証では、ツール経由の操作が遅すぎて「反応速度91秒」という珍記録も生まれている。緑になった瞬間から律儀に測り続けた結果なので、これはこれで実装が正しい証拠ではある。

本題。検証全PASSのコードに、本物のバグはいた

ここからが核心だ。実装したAIの検証項目はすべて合格、コンソールにエラーもない。本来なら、このまま公開して終わりの流れだった。今回は、実装したAIとは別のセッションでもう1つAIを立ち上げ、レビュー役をやらせてみた。

レビュー役の質問は意地悪だった。「同じ瞬間に、入力が2発届いたらどうなる？」

実際に2発同時の入力を撒いてみると、緑の画面への1回のタップで同じタイムが2件記録され、ラウンドが1つ飛んだ。本物のバグだ。

原因をかみ砕くとこうなる。ゲームは「いま計測待ちか、計測済みか」という状態のメモを見て、入力を受け付けるか決めている。ところがこのメモの書き換えは、画面の描き直しと同じタイミングでしか行われない仕組みになっていた。1発目の入力が「計測済みにして」と頼んでも、描き直しが走る前に届いた2発目は、まだ「計測待ち」のメモを読んでしまう。そして緑の画面は、例の0.3秒の保険の対象外。2発目を止めるものが何もなかった。

机上の意地悪に見えるかもしれないが、そうではない。スマホで二本の指が同時に画面に触れれば、入力はまさに2発届く。公開すれば早晩、誰かが踏む道だった。

修正自体は小さい。状態のメモを、頼んだ瞬間に書き換えるよう5か所を直しただけだ。再テストで記録は1件になり、5ラウンド通しの動作も、型チェックもビルドも問題なし。ここまで確認して、ようやく公開した。

教訓: 作る役と疑う役を分ける

今回いちばんの学びはこれに尽きる。AIのコードは動く。検証もする。でも「二本指でタップしたら？」という意地悪な質問は、作った本人からは出てこなかった。人間の開発現場でレビューを書いた本人以外がやるのと同じ理屈が、AIにもそのまま当てはまる。

自分の作ったものの穴は、自分では見えない。AIも例外ではなかった、という話だ。幸い、AIは何人でも呼べる。作る役と疑う役でセッションを分ける。コードを書かない人間がAI開発の品質を上げる方法として、これがいまの私の答えになっている。

AIでゲームを作る方法——真似する場合の4ステップ

私と同じことをするなら、手順は4つ。

1. 作りたいゲームを日本語の仕様書にする。画面の流れを時系列で書き、「してほしくないこと」も忘れずに添える。コードの知識は要らないし、仕様書づくり自体をAIに相談してもいい。私もそうした
2. AIに渡すとき、「作業の過程をログに残して」と一言頼む。あとで振り返る材料になり、記事や共有にも使える
3. できあがったら、別のAI（別のセッション）に「壊すつもりで質問して」と頼む。同時入力、連打、途中でやめる、変な順番で操作する——作者が想定しない角度が出るほど価値がある
4. 公開は、レビューを通ってから

お金の面では、各社のAIに無料枠があるので、小さなゲームを1本試すだけなら無料でも入り口には立てる。ただ、実装からレビューまで何往復もさせる使い方だと、私は有料プランを使っている。このあたりは目的次第だ。

かかった時間とお金

AIの実装と検証が35分。その前の需要調べと仕様づくり、あとのレビューとバグ修正を合わせても、夜に始めてその日のうちに公開までたどり着いた。私自身がやったのは決めることと判断で、コードは1行も書いていない。仕様書もAIとの共同作業だ。

お金は、AIツールのサブスク代と、検索需要を調べたキーワードツールの費用だけ。今回のゲームのために新しく払ったものはない。

AIと組んで作ること自体を学びたい人へ

ゲームに限らず、生成AIとの共同作業は「何をどう頼むか」で結果が大きく変わる。私は実地の遠回りで覚えてきたが、体系立てて学ぶなら実務目線の講座から入る道もある。仕様の書き方やレビューのさせ方は、どの分野でも使い回しが利く。

まとめ: 「動く」と「公開してよい」は別物

AIでゲームを作る方法は、突き詰めれば「日本語で仕様を書いて、AIに任せて、別のAIに疑わせる」だ。コードを書かない私でも35分で動くものができて、その日のうちに公開できた。同時に、検証を全部通ったコードにもバグは残っていた。作る力より、疑う段取りのほうが公開の決め手になる——それが今回の実感だ。

腕試しはこちらからどうぞ。5回の平均タイムで称号が出る。記録は端末の中にだけ残り、外部には送られない。

反射神経テストで遊ぶ（無料・スマホ対応）

このサイトでは、AIだけで何かを作って公開するまでの過程を制作記録として残している。診断アプリの回や、FXの検証システムの回もあわせてどうぞ。