AIにテストプレイをさせる:想定操作を列挙させるプロンプト
遊びをつくる執筆にClaudeを使用しています。

ゲームを作り終えたとき、「自分でプレイして問題なかった」のに公開後に想定外のバグが出た、という経験をした方は少なくないはずです。作者は無意識に「正しい操作」しかしないため、テストが偏るのは構造的な問題です。 AIはゲームを実際にプレイできません。しかしプロンプトの工夫次第で、「このゲームでプレイヤーが試みそうな操作の一覧」を生成させることはできます。人間が見落としがちな斜め方向の入力、連打、ゼロや負の値の入力、ゲームの想定外の順番での進行といった「意地悪な操作」を網羅的に列挙させ、それを自分でひとつずつ確認するという流れです。 この記事では、AIに想定操作を列挙させるプロンプトの書き方と、出力を実際のテストに使う手順を具体的に説明します。
なぜ「操作の列挙」をAIに任せるのか
テストプレイの難しさは、抜け漏れが生じやすいことにあります。人は過去の経験や先入観から「まずAボタンを押す」「メニューから始める」といった想定ルートをたどります。一方プレイヤーは、ルールを知らないまま触り、意図せず端の座標をクリックしたり、ボタンを長押ししたり、タイトル画面をすっ飛ばそうとしたりします。
AIにゲームの仕様を伝えると、AIは「このゲームのジャンルであれば一般にどんな操作が起こりうるか」という知識と、「仕様から想像できる境界値や例外ケース」を組み合わせて、操作リストを生成できます。作者が思いつかなかった視点が混じることが多く、テストの網羅性が上がります。コードのレビューをAIに頼む感覚に近いですが、対象がロジックではなく「ユーザー行動」です。
効果的なプロンプトの構造
AIに想定操作を列挙させるプロンプトには、次の四つの要素を含めると出力の質が上がります。
1. ゲームの概要と操作手段
ジャンル、ゴール、プレイヤーが使えるインターフェース(マウスクリック、キーボード、スワイプなど)を1〜3文で説明します。AIはこれをもとに「このゲームで起こりうる物理的な入力の種類」を絞り込みます。
2. ゲームの状態一覧
タイトル画面・プレイ中・クリア・ゲームオーバーなど、画面や状態の名前を列挙します。「各状態で何ができるか」を推論するためのリストです。これがないと、AIは「プレイ中」だけを考えがちです。
3. 依頼の形式指定
「各状態について、プレイヤーが試みうる操作をすべて列挙してください。正常系だけでなく、意図しない・誤った操作、境界値(最大値・最小値・ゼロ)、連続入力、高速連打、順番の逆転も含めてください。」と明示します。「意地悪なプレイヤーを想定する」という言葉を加えると、通常の手順から外れたケースが増える傾向があります。
4. 出力フォーマットの指定
「状態名/操作内容/期待される結果/バグが起こりやすい理由(推測)」の4列のリストで出力するよう指示すると、そのままテストチェックリストとして使えます。Markdown表形式を指定しておくと、スプレッドシートへの転記も楽になります。
まとめると、プロンプトの骨格はこうなります。
あなたはゲームQAエンジニアです。
以下のゲームについて、プレイヤーが試みうる操作をすべて列挙してください。
【ゲーム概要】
(ジャンル・ゴール・操作手段を記入)
【状態一覧】
(タイトル、プレイ中、クリア、ゲームオーバーなど)
条件:正常系の操作だけでなく、誤操作・境界値・連打・想定外の順番・意地悪なプレイヤーの行動を含める。
出力形式:Markdown表。列は「状態」「操作内容」「期待結果」「リスク(推測)」の4列。出力を実際のテストに変換する手順
AIが出力した表は、そのままコピーしてスプレッドシートやNotionに貼り付け、「確認済み/バグあり/スキップ」を記録する列を追加します。項目数が多い場合は、まず「リスク(推測)」列に記入があるものから優先して確認します。
テスト中にバグを見つけたら、その操作手順をそのままAIに伝えて「このバグが起きた場合、関連して発生しうる別の問題は何ですか」と追加質問します。バグはひとつの操作が原因でも、複数の状態に影響することがあるため、派生ケースの洗い出しにも使えます。
AIが列挙しない種類の問題として、描画・音・通信遅延・外部フォントの読み込みなど、環境依存の問題があります。操作の列挙では拾えないこれらは、別途スマートフォン・低速回線・別ブラウザでの確認として手動テストに組み込む必要があります。
出力の精度を上げる追加テクニック
一度で完璧なリストは出ません。最初の出力を受け取ったあと、次の問いかけで精度を上げます。
- 状態を深掘りする:「プレイ中の状態を、さらに『キャラクター移動中』『アイテム取得直後』『残機ゼロ寸前』に分けて列挙し直してください」と細分化を依頼します。
- 特定の操作系を追加する:「タッチ操作のジェスチャー(スワイプ、ピンチ、長押し)も追加してください」のように、最初に漏れた操作手段を後から足せます。
- 別のペルソナを設定する:「このジャンルをはじめて遊ぶ子どもを想定して、追加の操作を挙げてください」とすると、チュートリアルを無視する行動や、説明文を読まずに進もうとする操作が出てきます。
注意点として、AIは「ゲームの実装を見ていない」ため、「リスク(推測)」列の内容は正確とは限りません。あくまで「確認すべき箇所への誘導」として使い、実装を見て判断するのは自分です。AIの出力を鵜呑みにしてテストを省略すると本末転倒になります。
HTMLゲームへの応用
単一HTMLで作ったゲームをアソバースに投稿する前のチェックとして、このプロセスは特に有効です。ファイルが一つにまとまっているため、完成後に「仕様を改めて整理してAIに渡す」コストが低く、出力したチェックリストをブラウザで開きながらそのままテストできます。
プロンプトに渡す「ゲーム概要」は、ゲームのREADMEや投稿時の説明文を流用できます。ゲームを公開するための説明文を書く作業と、テスト用の仕様整理を同時に進めると効率が上がります。
次の行動
手元にあるゲームのタイトル・操作手段・状態一覧をメモし、この記事の骨格プロンプトに当てはめてAIに投げてみてください。出てきたリストの中から「リスク」列が埋まっている項目だけを選んで確認するだけでも、公開前の見落としを減らせます。テストリストが完成したら、アソバースへの投稿準備を進めましょう。

