ゲーム制作プロンプトの書き方：操作・状態・反応を具体化する

企画書の言葉が機能の指示にならない理由

ゲームを企画するときの言葉と、機能を実装するときに必要な言葉は異なる。「敵を倒す爽快感」「難易度が上がっていく」「プレイヤーが成長する」——こうした表現は体験の方向性を共有するには便利だが、コードに変換できる情報がほぼ含まれていない。

AIはプロンプトに書かれていない部分を何らかの前提で補う。「ジャンプ」という単語を見たとき、キーボードのスペースキーを使うゲームを想定するかもしれないし、モバイル向けのタップ操作を想定するかもしれない。高さや滞空時間はどこにも指定がなければ適当な値を選ぶ。空中ジャンプを許可するかどうかも、ゲームのジャンルによって判断が分かれる。

つまりAIが出力する解釈の幅は、プロンプトが省略した情報の量と比例する。企画の意図を正しく実装に変換するには、「何がどうなる」を曖昧にせず書き切る必要がある。

操作・状態・反応という3つの切り口

ゲームの一つの機能を記述するとき、次の3要素を明示すると指示の粒度が安定する。

• 操作（トリガー）：何が起点になるか。キーの押下、クリック、タッチ、タイマー経過、別のオブジェクトとの接触など。
• 状態（条件）：その操作が有効になる場面。地面に触れているとき、HPが1以上のとき、特定のフラグが立っているとき、など。
• 反応（結果）：何がどう変わるか。位置・速度・スコア・HP・アニメーション・音・画面遷移、など変化するものを列挙する。

この3要素を埋めるだけで、「ジャンプ」は「スペースキーを押した瞬間」「プレイヤーが地面に接触している」「Y方向の速度を上向きに変更し、着地アニメーションからジャンプアニメーションに切り替える」という記述に変わる。書き方として固定する必要はないが、3点が揃っているかどうかを自分で確かめる基準として使える。

曖昧な指示と具体的な指示を見比べる

同じ「ジャンプ機能を作って」という意図でも、指示の書き方によって伝わる情報量はまったく違う。以下は、説明のための対比例として挙げる。

曖昧な指示の例

プレイヤーがジャンプできるようにしてください。

この指示が返すコードには「何で起動するか」「どんな条件下か」「どれくらい飛ぶか」が含まれない。AIはそれぞれを適当に補完する。

操作・状態・反応を書いた指示の例

スペースキーを押したとき、
プレイヤーオブジェクトが地面（Ground レイヤー）に接触している状態であれば、
プレイヤーのY方向の速度を -400 に設定してください。
空中にいるときにスペースキーを押しても何も起きません。
着地したとき速度は 0 にリセットしてください。

速度の数値はゲームエンジンや座標系によって変わるため、ここで挙げた「-400」はあくまで構造の例示であり、実際の実装では自分のプロジェクト設定に合わせて調整する必要がある。重要なのは数値そのものではなく、「何を数値で渡すか」を明示している点だ。

「Ground レイヤー」のような固有名詞は、自分のプロジェクトで実際に使っている変数名やオブジェクト名に置き換えてプロンプトに渡すと、AIが既存のコードと整合したコードを返しやすくなる。

すぐ使えるプロンプト構造テンプレート

機能ごとに1枚の指示として書けるよう、以下の構造を使ってみてほしい。穴埋め形式にしたが、記述が長くなる場合は箇条書きに変えてもかまわない。

【機能名】（例：ジャンプ、弾の発射、ゲームオーバー判定）

[トリガー] が起きたとき、
[状態・条件] であれば、
[変数 / オブジェクト / 状態] を [どう変えるか] してください。

[条件を満たさないときの動作]（何もしない、別の処理をする、など）
[副作用として変えたくないもの]（触れてはいけない変数・オブジェクト名）

「副作用として変えたくないもの」は見落とされやすいが重要な欄だ。AIはプロンプトに書かれていない変数を書き換えることがある。影響を受けてほしくない変数名や処理を明示しておくと、意図しない変更が減る。

一度に一つの機能だけ頼むのが原則だ。「敵AIと弾の発射と当たり判定をまとめて実装して」という指示は、それぞれの機能が独立して動作することをAIが確認できないまま進んでしまう。まず一つを動かし、確認してから次に進む方が、後から問題を切り分けるコストを下げる。

状態が複数あるときの整理方法

プレイヤーが「通常・ジャンプ中・ダッシュ中・無敵中」のように複数の状態を持つ場合、それぞれの状態で「どの操作が有効か」「どの状態に移れるか」を先に整理しておく必要がある。AIに渡す前に、紙や簡単な表で状態の一覧を作ると指示の漏れが見えやすくなる。

たとえばダッシュ中にジャンプできるか、無敵中にダメージ処理が走るかは、意図を決めておかないとAIが勝手に判断する。「ダッシュ中はジャンプを受け付けない」「無敵フラグが立っているときはHP減算処理をスキップする」のように、各状態での制約を明示的に書く。

プロンプトに渡す前の整理に使えるシンプルな表の形は次のとおりだ。

• 現在の状態：通常、ジャンプ中、ダッシュ中、無敵中
• 有効な操作：その状態で受け付ける入力の一覧
• 遷移先：操作や時間経過によって移行できる次の状態
• 禁止：その状態では受け付けない操作や処理

この表を作ってからプロンプトに変換すると、「ダッシュ中にスペースキーを押しても何もしない」という記述が自然に出てくる。指示の中に「何をしないか」を書くのが、状態が複数あるゲームでは特に大切だ。

返ってきたコードを確認し次の指示につなげる

AIが返したコードを実行して動作を確認したら、次の指示はその確認結果から出発する。「さっきのジャンプ実装を前提に、着地時にパーティクルを出してください。パーティクルの生成と削除はjump.jsとは別のファイルに書いてください」のように、前回の成果物を起点に範囲を絞ると、変更の影響が広がりにくい。

思った通りに動かなかった場合は、「ジャンプしない」という観察だけでなく、「スペースキーを押してもY速度が変化しない」「地面への接触判定が常にfalseを返している」など、どの要素が期待と違うかを特定してから次の指示を書く。症状の記述が具体的であるほど、修正の指示も絞り込める。

一つの機能を完成させてコミットした後に、次の機能の実装に進む——このサイクルを短く回し続けることが、AIを使ったゲーム制作での問題を小さく保つ方法だ。プロンプトの書き方は、そのサイクルの入り口に過ぎない。操作・状態・反応の3点を埋める習慣が身についてくると、自分がゲームに何を求めているかを整理する力にもなる。

この記事の本文はClaude（Anthropic）が執筆しています。掲載しているコード例はプロンプト構造の説明用であり、特定のゲームエンジンや環境での動作を保証するものではありません。