プロンプトの失敗例集：ゲームが完成しなかった指示の共通点

失敗パターン1：ゲームの「終わり」を指定していない

最もよく見られる失敗は、ゲームのループ構造を曖昧にしたまま依頼することです。

「シューティングゲームを作って」という指示を受けたAIは、弾を撃つ動作・敵の出現・当たり判定まではそれなりに書けます。しかし「スコアが何点でクリア」「ライフが0になったらゲームオーバー画面へ遷移」「リトライボタンで最初の状態に戻る」といった終端条件を指示しないと、AIはループの出口を設計しません。結果として、永遠に続くか、エラーで止まるかのどちらかになります。

終わりを決めるとは、次の三つを指示に含めることです。

1. クリア条件：スコア・ステージ・時間など数値で指定する
2. 失敗条件：体力・ミス回数・制限時間切れなど
3. 終了後の遷移先：リザルト画面・タイトルへの戻り方

「RPGを作って」のように開放的なゲームでも、「チュートリアル1ステージ分だけ」「ボスを倒したらエンディング画面を出す」と範囲を区切れば、AIは完結するコードを書けます。

失敗パターン2：複数の要素を一度に詰め込む

「縦スクロールシューティングで、アイテムが3種類あって、ボスが出て、BGMが鳴って、スコアがランキングに保存されて」という指示は、AIが生成できる1回の出力の限界を超えることがあります。

このとき起きる現象は二種類あります。一つは途中で出力が打ち切られてコードが不完全になること。もう一つはすべての要素を「書いたつもり」で生成するが、実際には動かないダミーのような関数が混入することです。後者は表面上は完成しているように見えるため、気づくのが遅れます。

判断の目安は「機能の数」です。一つのプロンプトで依頼する機能は、大まかに3〜4個が上限と考えておくと安全です。アイテムシステムを加えたいなら、まずアイテムなしで動く最小版を完成させ、そこに追加依頼する形にします。

積み上げ型で依頼するメリットはもう一つあります。最小版が動いている状態でエラーが出たとき、「どこを追加したときに壊れたか」がすぐ特定できます。すべてを一度に書くと、エラーの原因が何十行にもわたって分散します。

失敗パターン3：「雰囲気」だけ伝えて仕様を省く

「レトロな感じのパズルゲーム」「かわいいアクション」「難しいローグライク」——方向性を言葉で伝えることは悪くありませんが、それだけではAIは仕様を推測で埋めます。推測で埋まった部分は、依頼者の想像と一致しないことがほとんどです。

特に問題になりやすいのは次の三点です。

• 操作方法：キーボードかタッチか、何キーで何をするか
• 画面サイズ：固定かレスポンシブか、基準となる縦横比
• 難易度の数値的定義：敵の速さ・出現間隔・ダメージ量など

「かわいいアクション」と書けばAIはそれらしいコードを出しますが、スマートフォンで横持ちにするつもりだったのにキーボード前提で書かれた、タッチ操作に対応していない、といったことが起きます。これは修正にかなりの追加指示が必要になります。

仕様を固める手順として有効なのは、依頼する前に箇条書きメモを作ることです。「操作：左右矢印キーで移動、スペースでジャンプ」「画面：640×480px固定」「敵：3秒ごとに右から出現、接触でゲームオーバー」程度の粒度があれば、AIは推測に頼らず書けます。

失敗パターン4：エラー対応を「直して」だけで依頼する

コードを出力してもらったあと、動かなかったので「エラーが出ました。直してください」と送る——これは依頼として不完全です。AIはエラーの文面を見ていないため、コードを眺めて問題を推測するしかなく、別の場所を誤って変更したり、動いていた部分を壊したりします。

エラー対応の依頼に含めるべき情報は三つです。

1. エラーメッセージの全文：ブラウザの開発者ツール（コンソール）に表示される文字列をそのまま貼る
2. どの操作をしたときに起きるか：「ゲームを起動した瞬間」「ジャンプキーを押したとき」など
3. 変更した内容：前回の出力から自分で手を加えた箇所があれば明記する

開発者ツールはほぼすべてのブラウザでF12キーか右クリック→「検証」で開けます。Consoleタブに赤字で表示されるメッセージがエラーの本体です。「Uncaught TypeError: cannot read properties of undefined」のような文字列を丸ごとコピーして渡すことで、AIは問題箇所を正確に特定できます。

失敗パターン5：前の指示を引き継いでいると思い込む

会話形式のAIツールは、同じセッション内であれば文脈を保持しますが、その保持範囲には限界があります。長い会話で多くのコードを生成していると、AIが参照できる「記憶」の範囲から早い段階の指示がこぼれ落ち、新しい指示に答えるときに以前と矛盾した実装をすることがあります。

具体的には「キャラクターの速度は5に固定する、とさっき言いましたよね」という前提が通じなくなる状態です。

対策は、節目ごとに「現在の仕様まとめ」を自分でコメントとして貼ることです。たとえば「現在の状態：プレイヤー移動速度5、ジャンプ力10、敵は3種類実装済み」という1〜2行のメモを新しい依頼の冒頭に添えるだけで、AIは現状を正確に把握して追加作業に入れます。

また、大きな機能を追加するタイミングで「今のコードを全部貼るので、このコードをベースに〇〇を追加してください」と現物を渡し直す方法も安定しています。AIが推測で補う余地をなくすことが、長期の制作で一貫性を保つ最短経路です。

失敗を防ぐ指示の最小構成

上記の5パターンから逆算すると、ゲームを完成させるプロンプトには次の要素が必要です。

• ゲームの範囲、含めること：今回作るのはどこからどこまでか（1ステージ・チュートリアルなど）
• 操作仕様、含めること：何キー・何タップで何が起きるか
• 終了条件、含めること：クリア・失敗それぞれの条件と遷移先
• 画面仕様、含めること：サイズと対応デバイス
• 機能の数、含めること：一度に3〜4機能まで

これらすべてを最初から完璧に書く必要はありません。最小限動く版を完成させ、一つずつ足していく手順が現実的です。

次の行動

まず手元にある過去のプロンプトを見直し、終了条件・操作仕様・画面サイズの三点が書かれているか確認してみてください。抜けている項目を補足した上で再依頼すると、出力の完成度が変わります。動くゲームができたら、HTMLまたはZIPでアソバース（https://aso-verse.com）に投稿して公開できます。