AIでゲームを作る方法：仕様から遊べるビルドまで

アイデアを願望リストではなく、テストできる形にする

AIでゲームを作るには、まず一つの遊べる基本ループを定義し、小さな実装を依頼して、機能を増やす前に結果を確認します。プロンプトは入力であり、求めた機能が動く証拠ではありません。生成後に問うべきなのは「ゲームらしく見えるか」ではなく、「プレイヤーは操作し、目標に到達し、失敗の理由を理解して、再開できるか」です。

この記事では、記録が残るSEELEの既存事例と、別に用意した学習用の仕様を扱います。事例には既存のプレイ可能なリンクと録画がありますが、学習用の仕様はこの記事のために生成・テストされていません。両者を区別することで、もっともらしい手順が実証済みの成功事例と誤解されるのを防げます。

記録されたゾンビサバイバルの事例から分かること

元の記事は、Three.jsによる一人称視点のゾンビサバイバルゲームを依頼した、2026年10月のSEELE生成記録を紹介しています。要求された機能には、ポインターロックを使う移動、銃、リロード、照準を覗いて狙う動作、しゃがみ、ダッシュ、アイテム取得、ミニマップが含まれていました。

元の記事による結果の録画の説明では、一人称視点の武器、体力と弾薬のHUD、ミニマップ、ウェーブ数、敵、アイテム取得の表示が確認されています。21.5秒のプレイ録画に映っているのは最初のウェーブの一部だけです。これらの表示だけでは、リロードやしゃがみの動作、すべてのアイテム取得操作、全5ウェーブの完走、他のブラウザーとの互換性までは証明できません。これは公開済み事例の証拠の範囲であり、新たに実機で完走を確認した報告ではありません。

この画像は、このプロジェクト固有のプロンプト主導の制作過程を記録したものです。

既存のプレイ可能なプロジェクトを開く。

最初のビルド向けに小さな仕様を使う

シューティングゲームでは相互に関わるシステムが多すぎて最初の試作が難しい場合、次の学習用の例を使ってください。

学習用の例であり、テスト済みのビルドではありません。Signal Runという、1画面で遊べる見下ろし型のブラウザーゲームを作成してください。プレイヤーはWASDまたは矢印キーで移動し、3個のバッテリーを集めて、見える場所にある出口に到達します。バッテリーの数と操作方法を表示します。障害物を1つ、固定された2点の間で水平に移動させます。接触すると敗北画面を表示し、バッテリーをすべて集めずに出口へ到達した場合は必要条件を表示します。3個すべてを集めて出口へ到達した場合は勝利画面を表示します。勝敗どちらの後もRキーで再開でき、プレイヤー、バッテリー、カウンター、障害物を初期状態に戻します。見分けやすい仮の図形を使います。敵、武器、セーブ、ネットワーク、追加ステージ、決済は追加しません。変更したプロジェクトの構成要素を説明し、移動、取得、勝利、敗北、再開の確認方法を示してください。

SEELEのプロンプトによるゲーム制作は、仕様からプロトタイプへ進む段階で役立ちます。ただし、要求した操作やリセット動作は実際の生成結果で検証する必要があります。プロンプトに書いただけでは保証されません。

ステップ1：最初の遊べるループを確認する

見た目を整える前に、想定する環境でビルドを実行し、画面内に示された操作に従います。すべての方向への移動を確認し、プレイ領域の外へ出られないことを確かめます。バッテリーを1個取得し、元の位置を再び通ってください。カウンターが二重に増えてはいけません。

先に出口へ行き、表示されるメッセージを記録します。次にすべて集めて勝利を確認します。意図的に障害物に触れて敗北も確認し、それぞれの後に再開します。障害物はリセットされるのにバッテリーは戻らない場合、AIに単に「ゲームを修正して」と頼むのではなく、その違いを具体的に伝えます。

ステップ2：事例を使って検証台帳を作る

各機能について、要求した動作、利用可能な証拠、観察した動作、状態の4項目を記録します。ゾンビの事例では、ミニマップが見えることは証拠欄に記載できますが、位置を正確に追跡しているかはテストするまで未検証です。リロードの要求は、弾薬の変化とリロード操作を記録できるまでは仕様欄に置きます。

Signal Runにも同じ姿勢を適用します。「バッテリーを3個要求した」ことと「異なる3個の取得が正しく数えられた」ことは同じではありません。不確かな項目を断定的なキャプションで埋めず、未検証と記します。この台帳があれば、次のプロンプトを絞り込み、共同作業者にビルドの状態を正確に伝えられます。

ステップ3：一つのルールを変更し、ループを再テストする

動作する版を保存したら、変更を一つだけ依頼します。障害物の経路とすべての取得ルールを維持したまま、その移動速度を20％下げます。同じ出発点から同じ横断を繰り返し、所要時間を比較して、勝敗両方の状態を再テストします。

無関係な見た目の変更後に移動が壊れた場合は、動作が確認できている版に戻し、依頼の範囲を絞ります。正確なエラー、対象環境、期待する動作、再現に必要な最短の手順を伝えます。原因不明の不具合に対して、広範囲な書き直しを重ねるのは避けてください。

ステップ4：開発用の引き継ぎを別途確認する

プレイ可能なリンクは、ソースプロジェクトの引き渡しとは異なります。継続開発をツールに依存する前に、現在のプランでプロジェクトにアクセスできるか、どの形式でエクスポートできるか確認してください。必要な形式が利用できる場合は、版を管理したコピーを保存し、エントリーポイント、ソースファイル、アセット、依存関係のマニフェスト、ロックファイル、実行手順を一覧にします。何が生成されたものか、何が依存関係か、何に別のサービスが必要かを確認します。認証情報、非公開エンドポイント、アカウントトークンをプロジェクトと一緒に公開しないでください。

別の空のフォルダーで、該当するエンジンまたはフレームワークのインストール・実行手順に従います。ランタイムのバージョンと不足している依存関係を記録します。ホストされた作業環境に頼らず、移動、取得、勝利、敗北、再開を再確認します。ローカルビルドが失敗した場合やエクスポートできない場合は、その制約を記録します。ホストされたプレビューでは不足する証拠を補えません。既存のゾンビの事例については、ソースのエクスポートもローカル実行も確認されていません。

ステップ5：確認できた範囲を正直に共有する準備をする

共有前に、クリーンな環境での読み込み、読みやすい操作表示、音声があればその動作、キーボードフォーカス、再開を確認します。予定している用途に照らし、ツールとアセットの最新の利用条件を確認します。別のブラウザーやデバイスへの対応をうたう前に、実際にテストします。性能について述べるときは、埋め込み動画が滑らかに見えることではなく、使用したハードウェアと記録した測定方法に基づけます。

上記の仕様を使って、SEELEで小さなプロトタイプを作り始めましょう。追加の変更を依頼する前に、動作するビルド、正確なプロンプト、テストの記録を保存します。目標は長い機能一覧ではなく、検証済みの一つのループです。初めてのプレイヤーが移動し、目標を理解し、勝敗の両方に到達して、再開できます。制作者の説明なしにそのループを実演できてから、ステージやより豊かなアセットを追加します。作業環境の外で開発を続ける必要がある場合、ソースの引き渡しとクリーンなローカル実行は、プレビューから推測するのではなく別々の受け入れ条件として扱います。

よくある質問

短いプレイ動画でゲーム全体が動作すると証明できますか？

いいえ。録画された時間内に見えることしか裏付けられません。HUDが表示されていても、その背後にあるすべてのルールが正しいとは限りません。機能チェックリスト、再現可能な入力、対象を絞った長めの録画を使って動作を確認します。制作過程の動画、見た目のプレビュー、完了したプレイテストは区別してください。

生成されたすべてのファイルを理解する必要がありますか？

ゲームをテストし、動作する版を守り、関連する変更箇所を見つけられる程度の理解は必要です。構成要素と前提を平易な言葉で説明するようアシスタントに依頼してください。エンジン固有の未知の動作については、最新のドキュメントを確認します。説明が技術的にもっともらしいという理由だけで、大規模なコードの書き直しを受け入れるのは避けてください。

仮のアートはいつ差し替えるべきですか？

基本ループが理解しやすく、繰り返し動作するようになってからです。アセットは少しずつ差し替え、その都度、当たり判定、大きさ、コントラスト、読み込み、権利を確認します。魅力的な画像は伝わりやすさを高めますが、未テストの仕組みを検証することはできません。コンセプト画像はその旨を明示し、生成されて動作している結果のスクリーンショットとして見せないでください。

次のプレイ可能なマイルストーンのワークフローを選択してください

次の決定をブラウザーでプレイ可能な 1 つのループでテストできる場合は、ゲーム メーカーを使用します。プロジェクトにすでにエンジン、アセット、またはコードベースがある場合は、その環境内の 1 つの限定された変更に対してアシスタントをテストします。エクスポートとアセットのチェックリストをプレイテスト ノートと一緒に保管しておくと、プレイ可能な結果と移植可能なプロジェクトを別々に評価できます。