AIにゲーム開発を頼むプロンプト｜ルール・操作・完成条件の書き方

最初に、繰り返してほしい行動を決める

企画の出発点は、ジャンル名だけでなくプレイヤーの行動です。「パズルゲーム」なら、何を見て、何を選び、どう結果が変わるのでしょうか。同じ色をまとめるのか、順番を推理するのかで実装が違います。「四方向に動かすと盤面全体が滑り、同じ数のタイルが重なる」と書けば、操作とルールが一緒に伝わります。

ここでは独自作品の仕様例として、三つのスイッチで扉を開くゲームを考えます。押したスイッチの表示が変わり、指定の組み合わせになったら扉が開く。正解後は次の問題を選べる。この程度まで行動を分解してから、雰囲気や色を足します。参考作品がある場合も、名前だけで全機能を要求したことにしません。

難易度の表現は、変更できる値に置き換えます。「簡単に」なら、選択肢の数、ヒントの有無、失敗時に戻る範囲を書きます。「爽快に」なら、成功した瞬間の表示、待ち時間、入力を受け付けるタイミングを考えます。感覚の言葉を残しながら、それを確かめる観察点を添えるのがコツです。

開始・プレイ・結果を、別の状態として説明する

画面の状態を書いておくと、意図しない場所で操作が動く問題を考えやすくなります。開始前は説明と開始ボタン、プレイ中は問題と操作、結果では成功表示と再挑戦。各状態で有効な入力を決めます。結果画面で盤面を触ったときに、前の問題が変わってよいのかも明記しましょう。

再挑戦の条件は特に忘れがちです。得点、残り時間、選択、音、敵の位置のうち、何を初期状態に戻すのでしょうか。問題をランダムにするなら前回と同じ問題が出てもよいか、設定した難易度は保持するかを決めます。全部を消す、という短い指示では設定まで失うことがあります。

小さなゲームなら状態表を文章で十分に表現できます。大きな制作では、状態名、入る条件、受け付ける操作、次の状態を一覧にします。AIが提案した状態名と実装が対応しているかを確認し、仕様を変更したときも表を更新します。実装だけが先に変わると、後から不具合と仕様変更を区別しにくくなります。

依頼テンプレートには、しないことも必要な範囲だけ書く

OpenAIの公式資料は、明確な指示や必要な文脈を与えることを説明しています。以下は当ブログが用意した制作依頼の例で、公式の万能プロンプトではありません。対象端末と確認条件まで書き、機能の追加範囲を絞ります。今回は外部サービスを使わない、といった判断がある場合は理由と一緒に添えます。

制約は、制作に効くものを選びます。既存の構成を維持したい、音声素材をまだ使わない、通信を必要としない初期版にしたい、といった条件です。あらゆる例外を先回りして並べると、中心の遊びが見えにくくなります。重要な条件を優先順に置き、迷う点は実装前に整理するよう依頼しましょう。

参考画像やコードを渡す場合は、どこを参考にするかを注記します。画像の色だけを取り入れたいのに、画面内の文章や配置もすべて再現されると困ります。元の素材を使ってよいかという条件と、デザインの参考にすることも別です。制作の意図が一致しているか、最初の小さな出力で確認します。

目的：三つのスイッチの組み合わせを考える一人用パズル。
対象：PCとスマートフォンの縦画面。
操作：スイッチをクリックまたはタッチして切り替える。
状態：説明、問題、成功の三つ。成功後は盤面の入力を止める。
再挑戦：選択だけを初期化し、難易度は保持する。
初期版：一問と再挑戦まで。素材は仮の図形でよい。
確認：三つの正解・不正解例と、成功後の入力を実際に確かめる。

追加依頼は、観察結果から一つずつ作る

出力が期待と違ったときは「もっとよくして」だけで戻さず、何を見てそう思ったかを書きます。「ボタンを押した直後に色が変わらず、反応したか分からない」「成功の表示が盤面を隠して次の操作が見つからない」という形なら、改善の対象が具体的になります。変更後は同じ場面を見て判断できます。

仕様の変更と不具合の修正も分けます。初期仕様では三つのスイッチだったものを五つに増やすなら、それは機能変更です。一方、三つを押しても表示が更新されないなら修正です。新しい条件を足すたびに、元の再挑戦や端末対応が成立しているかを短く確認し、完成条件を失わないようにします。

プロンプトの良し悪しは文章の格好よさで決まりません。最初の一回を遊べたか、変更した場所を説明できるか、期待した結果を確かめられたかが判断材料です。このテンプレートがどのAIでも同じ結果を出すという検証はしていません。自分のゲームで違いが出た箇所を、次の仕様に反映して使ってください。