ゲームの作り方プロンプト集【コピペOK】企画から公開まで32本
ゲームの作り方を調べてAIに頼んでみたものの、思ったものと違うゲームが出てきた。直してと頼んだら別の場所が動かなくなった。こうしたつまずきの多くは、プロンプトの書き方を少し変えるだけで減らせます。
この記事は、ゲーム作りの工程ごとにそのままコピーして使えるプロンプトを集めたものです。企画、最初のコード、修正依頼、素材、テスト、公開の6つの段階に分け、合わせて30本以上を載せました。ChatGPTやGeminiのようなチャット型でも、Claude CodeやCodexのような開発エージェントでも使える書き方にしています。
【】や（）の部分を自分のゲームに合わせて書き換えれば、そのまま送れます。内容は2026年10月時点の各サービスの仕様に合わせました。
この記事の目次
ゲーム作りのプロンプトで押さえる4つの原則
具体的なプロンプトに入る前に、どの段階でも共通する原則を4つ確認しておきます。この4つを守るだけで、AIが的外れな答えを返す回数はかなり減ります。
| 原則 | 理由 | プロンプトに書く一文の例 |
|---|---|---|
| 1回に1つだけ頼む | 一度に多く頼むと、どこで不具合が入ったか分からなくなる | 今回は得点表示だけを追加してください |
| 変えない範囲を書く | 頼んでいない箇所まで書き換えられるのを防ぐ | ほかの部分は変更しないでください |
| 止まる位置を書く | エージェントは気を利かせて先の作業まで進めてしまう | ここまでできたら説明して止まってください |
| 数字で伝える | 「もっと」「少し」は人によって幅がある | 移動速度を今の1.5倍にしてください |
もう1つ覚えておきたいのが、チャット型と開発エージェントの違いです。チャット型は会話の中でコードを返すだけなので、毎回「コード全体を省略せずに出して」と書く必要があります。開発エージェントは自分でファイルを書き換えるため、出力形式の指定より「どのファイルを触ってよいか」「作業後に何を確かめるか」を書くほうが効果的です。
道具ごとの始め方はChatGPT・Geminiでブラウザゲームを作る方法とClaude Code・Codexでゲームを作る方法で説明しています。この記事では、どちらにも使えるプロンプトそのものに集中します。
企画段階のプロンプト
何を作るかが固まっていないうちにコードを頼むと、AIは平均的なゲームを作って終わります。企画の段階では、アイデアを広げ、1つに絞り、仕様のメモにまとめるところまでをAIと進めます。
アイデアを条件つきで出してもらう
ブラウザで遊べるミニゲームのアイデアを10個出してください。
【条件】
・1回のプレイは1〜3分
・操作はタップかクリックだけ（ボタン1つ）
・画像がなくても図形だけで成り立つ
・作る人は初心者で、制作期間は1週間
それぞれ「一行の説明」「おもしろさの中心」「作る難しさ（易・中・難）」を表で出してください。
よくあるアイデア（もぐらたたき、ブロック崩し、スネーク）は除いてください。最後の一文のように、ありがちな案を先に除外しておくと、少しひねった案が出やすくなります。
アイデアを一行のコンセプトにする
次のアイデアを、ゲームの一行コンセプトにまとめてください。
形式は「（どこで）（誰が）（何を）して（どうなる）ゲーム」です。
案を3つ出し、それぞれ「プレイヤーが1秒ごとに繰り返す操作」を一言で添えてください。
【アイデア】
（気に入ったアイデアを貼る）仕様のメモ（PLAN.md）を作ってもらう
コードを書く前に、仕様をファイルにまとめておくと手戻りが減ります。開発エージェントでは、このメモをPLAN.mdとして保存しておくと毎回の指示が短くなります。
次のコンセプトのゲームの仕様メモを、Markdownで作ってください。まだコードは書かないでください。
【コンセプト】
（一行コンセプトを貼る）
【書いてほしい項目】
1. ゲームの目的と終わる条件
2. 操作方法（PCとスマホ）
3. 画面の一覧（タイトル、プレイ中、結果）と画面の移り方
4. 得点やライフなどの数値と初期値
5. マイルストーン（最小版から完成までを4〜5段階に分ける）
6. 今回は作らないもの（やらないことリスト）
不明な点は勝手に決めず、最後に質問として並べてください。「今回は作らないもの」を書かせるのがこのプロンプトの要です。オンライン対戦、ランキング、ガチャのような大きな機能を最初から外しておくと、完成までの距離が読めるようになります。
大きすぎる企画を削ってもらう
次の仕様メモを、初心者が1週間で完成できる規模に削ってください。
・削った機能と、削った理由を表にする
・残す機能だけで遊んでおもしろいかを一言で評価する
・削った機能は「完成後に足す候補」として最後にまとめる
【仕様メモ】
（貼り付け）最初のコードを書かせるプロンプト
企画が固まったら、遊べる最小版を作ってもらいます。最初から完成形を頼まず、動きと当たり判定だけのゲームを作るのがコツです。
HTMLファイル1つで作る（チャット型向け）
次の仕様のゲームの最小版を、HTMLファイル1つで作ってください。
【今回作る範囲】
・（仕様メモのマイルストーン1だけを貼る）
【技術の条件】
・HTML、CSS、JavaScriptを1ファイルにまとめる
・外部ライブラリ、画像ファイル、音声ファイルは使わない（図形で代用）
・画面は縦長、幅360×高さ640を基準に画面サイズに合わせて拡大縮小
・PCのキーボードとスマホのタッチの両方で操作できる
・調整に使う数値（速度、出現間隔など）はコードの先頭に定数でまとめる
【出力】
・コード全体を省略せずに出す
・最後に、遊んで確かめてほしい点を3つ挙げる「遊んで確かめてほしい点を3つ挙げる」と頼んでおくと、AI自身が想定している動きが分かります。実際に遊んで、その3点が想定どおりかを見れば、最初の確認は済みます。
Phaserでフォルダごと作る（開発エージェント向け）
PLAN.md のマイルストーン1だけを実装してください。
・ViteとPhaserを使う
・画像はまだ使わず、四角形と円で代用する
・シーンは Title、Game、Result の3つに分ける
・数値の設定は src/config.js にまとめる
・完了したら npm run dev で起動できる状態にして、変更したファイルの一覧を出して止まる
マイルストーン2以降には手を付けないでください。ジャンル別に差し替える一文
上の2つのプロンプトの「今回作る範囲」に、ジャンルに合わせた次の文を足すと、そのジャンルで崩れやすい部分を先に押さえられます。
| ジャンル | 足す一文 |
|---|---|
| 横スクロールアクション | ジャンプの高さと落下速度を定数にし、地面の判定が足元だけで行われるようにする |
| 落ち物パズル | 盤面を二次元配列で管理し、消える判定と落下の処理を別の関数に分ける |
| シューティング | 画面外に出た弾と敵は配列から削除し、処理が重くならないようにする |
| ノベル・アドベンチャー | 本文と選択肢はJSONのデータに分け、コードには文章を書かない |
| ターン制RPG | 敵とスキルのデータはJSONに分け、ダメージ計算は1つの関数にまとめる |
| 放置・クリッカー | 大きな数値は「1.2万」「3.4億」の形で表示し、経過時間はページを閉じても計算できるよう保存する |
機能追加と修正依頼のプロンプト
最小版が動いたら、機能を足しながら不具合を直していく段階に入ります。ゲーム作りで一番やり取りが多いのがこの段階です。頼み方の型を持っておくと、同じ不具合を何度も直してもらう状態から抜け出せます。
機能を1つ足す
次の機能を1つだけ追加してください。ほかの部分は変更しないでください。
【追加する機能】
（例：敵に当たるとライフが1減り、1.5秒間は点滅して無敵になる）
【できたかの確かめ方】
（例：敵に2回続けて触れても、ライフは1しか減らない）
チャット型の場合：変更後のコード全体を省略せずに出してください。
エージェントの場合：変更したファイルと変更点を説明して止まってください。「できたかの確かめ方」を先に書いておくのがポイントです。AIが完成の基準を理解するので、作ったつもりで抜けている、という結果が減ります。
不具合を報告する
次の不具合を直してください。
・やったこと：（例：ゲームオーバー後に「もう一度」を押した）
・起きたこと：（例：前の回の敵が画面に残ったまま始まる）
・期待する動き：（例：敵と弾が消え、得点0・ライフ3から始まる）
・起きる頻度：（毎回／ときどき／一度だけ）
・エラー表示：（ブラウザのコンソールの赤い文字をそのまま貼る。なければ「なし」）
原因を先に説明し、そのあとで直してください。エラー文の意味を教えてもらう
ブラウザのコンソールに出た英語のエラーが読めないときは、直してもらう前に意味を聞くのも手です。何が起きているかが分かると、次からの報告が正確になります。
次のエラーの意味を、プログラミング初心者にも分かる言葉で説明してください。
・何が起きているのか
・コードのどこを見ればよいか
・よくある原因を2〜3個
まだコードは直さないでください。
【エラー】
（コンソールの赤い文字をそのまま貼る）原因だけ調べてもらう
同じ不具合が2回直らないときは、いきなり直させず、原因の調査だけを頼みます。AIは推測で直そうとして、別の場所まで動かなくしてしまうことがあるからです。
まだコードは変更しないでください。
次の不具合の原因として考えられるものを、可能性の高い順に3つ挙げてください。
それぞれ「どのファイルのどの処理か」「確かめる方法」を書いてください。
【不具合】
（やったこと・起きたこと・期待する動きを貼る）挙がった原因のうち、どれを直すかを自分で選んでから「1つ目の原因を直して」と頼みます。開発エージェントなら、確かめる方法として一時的にログを出すコードを入れてもらうのも有効です。
直前の状態に戻す
直前の変更で、ジャンプができなくなりました。
直前の変更を取り消して、その前の状態に戻してください。
戻したあと、なぜジャンプができなくなったのかを説明してください。直すのはそのあとです。開発エージェントでGitを使っているなら、動いた時点ごとに「ここまでをコミットして」と頼んでおくと、このプロンプトで確実に戻れます。チャット型の場合は、動いた版のコードをファイル名に日付を付けて保存しておくのが同じ役割を果たします。
遊びやすさを数値で調整する
遊びやすさを次のように調整してください。数値はコード先頭の定数を変えるだけにしてください。
・プレイヤーの移動速度：今の1.5倍
・敵の当たり判定：見た目より2割小さく
・最初の5秒間は敵を出さない
・30秒ごとに敵の出現間隔を1割ずつ短くする（下限は0.4秒）スマホに対応させる
このゲームをスマホでも快適に遊べるようにしてください。
・画面の向きは縦に固定し、どの機種でも画面全体に収まるように拡大縮小する
・キーボード操作の代わりに、画面下に半透明のボタン（左・右・ジャンプ）を表示する
・ボタンを押している間の長押しに対応する
・画面をダブルタップしても拡大されないようにする
PCでの操作は今のまま変えないでください。セーブ機能を付ける
ゲームの進み具合をブラウザに保存する機能を付けてください。
・保存するもの：ハイスコア、クリアしたステージ、音のオンとオフ
・localStorageを使い、保存するデータにはバージョン番号を付ける
・保存データが壊れていたり古い形式だったりしたら、初期値で始める
・タイトル画面に「記録を消す」ボタンを付け、押したら確認の表示をゲーム画面内に出すコードを整理してもらう
機能を足し続けると、コードが長くなってAIも扱いにくくなります。区切りのよいところで、動きを変えずに整理してもらいます。
ゲームの動きは一切変えずに、コードを整理してください。
・1つの関数が50行を超えるものは分ける
・同じ処理が2か所以上にあるものはまとめる
・使われていない変数や関数は削除する
整理の前後で動きが変わっていないかを確かめる方法も教えてください。素材づくりのプロンプト
図形で動くゲームができたら、画像と音に差し替えます。素材はゲームの中の大きさと形式を先に決めてから作ると、組み込みで困りません。ツールごとの選び方や商用利用の条件はゲーム素材をAIで作る方法にまとめているので、ここでは指示文の型を紹介します。
キャラクターの画像
2Dゲームのプレイヤーキャラクターの画像を作ってください。
・キャラクター：（例：オレンジ色のマフラーを巻いた小さな白い猫）
・向き：右向きの横向き、全身
・画風：太めの輪郭線、影は1段階、明るい色
・背景：無地の単色（あとで透過するため）
・ほかの要素は描かないドット絵とスプライトシート
32×32ピクセルのドット絵キャラクターを作ってください。
・キャラクター：（見た目を書く）
・歩きのアニメーション4コマを横1列に並べる（全体で128×32ピクセル）
・使う色は16色以内、アンチエイリアスなし
・背景は透過画像生成AIはピクセル数を正確に守れないことが多いので、出てきた画像は画像編集ソフトで縮小して整えます。ドット絵専用のツールを使うと、この手間が少なくなります。
背景
横スクロールゲームの背景を作ってください。
・場所：（例：夕暮れの港町）
・比率：横長の16:9
・手前にキャラクターが立つので、画面の下3分の1は平らな地面にする
・文字、人物、看板は描かない
・左右の端が自然につながるようにするタイトル画面とボタン
ゲームのタイトル画面のデザインを考えてください。画像生成は使わず、CSSと図形で作れる範囲にしてください。
・ゲームの雰囲気：（例：夜の遊園地、少しレトロ）
・配色：メイン、背景、強調の3色をカラーコードで提案する
・ボタン：「はじめる」「遊び方」「音のオンとオフ」
・タイトルの文字はWebフォントを使わず、端末の標準フォントで見栄えがするようにする
案を2つ出し、選んだほうを実装できるコードにしてください。効果音（音声ファイルを使わない場合）
Web Audio APIを使って、音声ファイルなしで次の効果音を鳴らす関数を作ってください。
・ジャンプ：短く上がる音
・コイン取得：高い音が2回
・ダメージ：低くにごった音
・ゲームオーバー：ゆっくり下がる音
スマホでも鳴るように、最初のタップで音の準備をしてください。音のオンとオフを切り替えるボタンも付けてください。スマホのブラウザは、画面に一度触れるまで音を鳴らせない仕組みです。最後の一文はその対策として入れています。
BGMの指示文を作ってもらう
音楽生成AIに渡す指示文は、ゲームの場面から逆算すると作りやすくなります。指示文そのものをチャットAIに書いてもらう方法です。
次のゲームの場面に合うBGMを、音楽生成AIで作りたいです。
英語のスタイル指定（ジャンル、テンポ、楽器、雰囲気）を3案出してください。
・場面：（例：タイトル画面／通常ステージ／ボス戦）
・ゲームの雰囲気：（例：かわいいけれど少し切ない）
・条件：歌なし、ループして使う、30〜60秒素材をゲームに組み込む
assets フォルダに次の素材を置きました。図形で描いているものを、この素材に差し替えてください。
・assets/images/player.png（32×32、横4コマの歩きアニメ）
・assets/images/bg.png（背景）
・assets/audio/jump.mp3、coin.mp3
当たり判定の大きさは今のまま変えないでください。
画像が読み込めなかったときは、今の図形で表示が続くようにしてください。「当たり判定は変えない」と書いておかないと、画像の大きさに合わせて判定まで変わり、遊んだ感触が変わってしまうことがあります。
テストのプロンプト
自分で何十回も遊んで確かめるのは大変です。確かめる項目をAIに洗い出してもらい、自動で確かめられる部分は自動にします。
確認項目のリストを作ってもらう
このゲームを公開する前に確かめるべき項目を、チェックリストにしてください。
・操作、画面の移り変わり、得点、ゲームオーバー、リトライ、音、スマホ表示の観点で分ける
・項目ごとに「どう操作して」「どうなれば合格か」を書く
・不具合が起きやすい順に並べる自動テストを書いてもらう（開発エージェント向け）
Playwrightを使って、次の流れを自動で確かめるテストを書いてください。
1. ページを開くとタイトル画面が表示される
2. スタートボタンを押すとゲームが始まる
3. 10秒待ってもエラーがコンソールに出ない
4. スマホの画面サイズ（幅390）でもスタートボタンが画面内にある
テストを実行して、結果を報告してください。失敗したテストがあっても、ゲームのコードはまだ直さないでください。「失敗してもまだ直さない」と書くのは、テストを通すためにゲームの仕様を変えてしまうのを防ぐためです。結果を見てから、直すかどうかを自分で決めます。
難易度をシミュレーションで確かめる
ゲームの難易度を確かめるシミュレーションを作ってください。
・プレイヤーの操作を「一定の確率でミスする自動操作」に置き換え、ミス率10％・20％・30％の3通りで各200回プレイさせる
・平均プレイ時間、平均得点、60秒を超えて生き残った割合を表で出す
・ゲーム本体のコードは変更しない動作が重いときに調べてもらう
ゲームを2分ほど遊ぶと、動きがカクカクしてきます。
・まだコードは直さず、重くなる原因の候補を挙げてください
・候補ごとに、確かめるために一時的に入れるログやカウンターのコードを示してください
・画面に1秒あたりの描画回数（FPS）を表示するコードも付けてくださいほかのAIにレビューしてもらう
作ったAIとは別のAIにコードを見せると、見落としに気づくことがあります。
次のゲームのコードをレビューしてください。修正版のコードは出さず、指摘だけにしてください。
・不具合になりそうな箇所（理由と起きる条件）
・スマホで問題が出そうな箇所
・処理が重くなりそうな箇所
重要度を高・中・低で付けてください。
（コードを貼る）公開のプロンプト
完成したゲームは、公開するところまでAIに手伝ってもらえます。公開先の選び方は作ったゲームの公開先と広告収入で比べています。
公開用のファイルを整える
このゲームをitch.ioにHTMLゲームとして公開します。
・ビルドして、公開用のファイルを dist フォルダにまとめてください
・index.html が一番上の階層に来るZIPを作る手順を教えてください
・ファイルの読み込みが絶対パス（/ から始まるもの）になっていたら相対パスに直してください
・alert() や confirm() を使っている箇所があれば、ゲーム画面内の表示に置き換えてください最後の項目は、itch.ioのように別のページに埋め込まれて遊ばれる場合の対策です。ブラウザ標準の確認ダイアログは、埋め込みや全画面表示のときに表示が崩れたり警告が出たりする原因になります。
GitHub Pagesで公開する
このゲームをGitHub Pagesで公開したいです。
・リポジトリ名は（例：star-catch）です
・ビルドの設定で、公開URLのパスに合わせた base を設定してください
・GitHub Actionsで、mainブランチに変更を送るたびに自動で公開されるようにしてください
・設定が終わったら、GitHubの画面で私が操作する手順を順番に書いてくださいゲームページの説明文を書いてもらう
次のゲームの紹介文を書いてください。
・一行のキャッチコピーを3案
・遊び方の説明（100字以内）
・操作方法（PCとスマホ）
・誇張した表現や「最高の」「究極の」などの言葉は使わない
【ゲームの内容】
（仕様メモを貼る）英語にも対応させる
itch.ioのように海外の人も遊ぶ公開先なら、英語表示を付けると遊んでもらえる幅が広がります。
ゲーム内の文字を日本語と英語で切り替えられるようにしてください。
・画面に出る文章はすべて lang.js に日本語と英語の組で書き出す
・最初はブラウザの言語設定に合わせ、タイトル画面で切り替えられるようにする
・英訳は短く自然な表現にし、ボタンの文字は1〜2語に収める
・英語にしたときに文字がボタンからはみ出す箇所がないか確かめる方法も教えてください素材のクレジットと生成AIの開示文を整理する
このゲームで使った素材とツールを一覧にして、クレジット表記の下書きを作ってください。
・素材ごとに「種類」「作ったツールまたは配布元」「ライセンスや利用条件で確認すべき点」を表にする
・プレイヤーが目にする部分（画像、音、文章）に生成AIを使ったものと、開発の補助だけに使ったものを分ける
【使ったもの】
（例：キャラ画像はGeminiで生成、効果音はWeb Audio APIで自作、BGMはフリー素材サイトの曲）Steamでは、プレイヤーが目にする画像や音、文章に生成AIを使った場合に申請時の開示が必要です。この一覧を作っておくと、開示の記入や規約の確認がすぐに済みます。
うまくいかないプロンプトの直し方
最後に、よくある失敗のプロンプトと、その直し方を表にまとめます。どれも「AIが推測で埋めている部分」を減らす方向の直し方です。
| うまくいかない頼み方 | 起きやすいこと | 直した頼み方 |
|---|---|---|
| おもしろいゲームを作って | ありきたりなゲームが出る | 条件（操作・時間・対象）を付けてアイデアを10個出させ、選んでから作る |
| マリオみたいなゲームを作って | 既存作品に寄せすぎて権利の問題が出るおそれ | 「ジャンプで足場を渡る横スクロール」のように仕組みで説明する |
| 動かないので直して | 推測で直して別の所が動かなくなる | やったこと・起きたこと・期待する動き・エラー表示を書く |
| もっと気持ちよくして | 何が変わったか分からない調整になる | 速度、効果音、画面の揺れなど、変える項目と量を指定する |
| ついでに〇〇と△△も | どれが原因で動かなくなったか分からない | 1回に1つ。動いたら保存して次を頼む |
| （長い会話の末に）最初の仕様どおりに | AIが古い指示と新しい指示を混同する | 仕様メモと最新のコードを貼って新しい会話で頼み直す |
注意
既存の有名なゲームのタイトルやキャラクター名をプロンプトに入れて「そっくりに」と頼むのは避けてください。文化庁のガイダンスでは、作品名などを入力すると既存の作品に依拠したと認められやすくなるとされています。公開前の確認はAIで作ったゲームの著作権と規約チェックリストで行えます。
ポイント
うまくいったプロンプトは、テキストファイルにためておくと次の作品で使い回せます。開発エージェントを使う場合は、毎回書いている注意書き（変えない範囲、止まる位置など）をCLAUDE.mdやAGENTS.mdに書いておけば、毎回のプロンプトから省けます。
関連記事AIでノベルゲーム・RPGを作る方法【2026年版】ツール別の手順とプロンプト
よくある質問
ChatGPTとGeminiとClaudeでプロンプトを変える必要はありますか
この記事のプロンプトは、どのサービスでもそのまま使えます。変えたほうがよいのは出力の指定です。チャット型ではコード全体を出してもらい、Claude CodeやCodexのような開発エージェントでは、触ってよいファイルと止まる位置を書きます。
プロンプトは英語で書いたほうがよいですか
日本語で問題ありません。2026年時点の主なサービスは日本語の指示を十分に理解します。ただし音楽生成AIのスタイル指定のように、英語の単語で指定するほうが狙いどおりになりやすいものもあります。
長いプロンプトと短いプロンプトはどちらがよいですか
最初の1回は長めに、条件をしっかり書きます。そのあとの修正は短く、1つの変更に絞るほうがうまくいきます。毎回同じ注意書きを書いているなら、仕様メモや指示ファイルに移して短くしましょう。
「プロのゲームデザイナーとして答えて」のような役割の指定は必要ですか
なくても動きます。役割を書くより、作る範囲や条件、確かめ方を具体的に書くほうが結果に差が出ます。企画の相談で視点を変えたいときに「辛口のレビュアーとして」のように使う程度で十分です。
無料プランの回数制限が気になります
調整用の数値をコード先頭の定数にまとめておくのがおすすめです。細かな調整は自分で数字を書き換えるだけになります。修正を頼むときも1回で1つの変更に絞ると、やり直しが減るぶん、送る回数も少なくて済みます。
まとめ
ゲーム作りのプロンプトは、工程ごとに型を持っておくと迷わなくなります。企画では条件を付けてアイデアを出し、仕様メモに「作らないもの」まで書かせます。コードは最小版から始め、修正は「やったこと・起きたこと・期待する動き」で伝え、2回直らなければ原因の調査だけを頼みます。素材は大きさと形式を決めてから作り、テストと公開の作業もプロンプトで手伝ってもらいましょう。
この記事のまとめ
- 1回に1つ、変えない範囲、止まる位置、数字の4原則を守る
- 企画は仕様メモにまとめ、作らないものを先に決める
- 不具合が2回直らなければ、直させずに原因だけ調べてもらう
- 素材は大きさと形式を指定し、組み込むときは当たり判定を変えない
- テストは確認リストと自動テスト、公開はZIPやGitHub Pagesの設定まで頼める
