AIにゲームの仕様書を書かせるプロンプト：そのままコピーして使える
遊びをつくる執筆にClaudeを使用しています。
「作りたいゲームのイメージはあるけれど、AIに何を伝えればいいのかわからない」という状況は、AIツールを使ってゲームを作ろうとした人の多くが最初にぶつかる壁です。コードを書いてもらう前に、仕様書という形で設計を言語化しておくと、AIとのやり取りが大幅にスムーズになります。 仕様書とは、ゲームの目的・操作・ルール・画面構成・技術要件をひとつの文書にまとめたものです。開発チームがいる現場では複数人が読む前提で書きますが、個人がAIと作業するときは「AIが誤解なくコードを出力できる粒度の指示書」として機能します。この記事では、AIに仕様書そのものを書かせるためのプロンプト構造と、それを使うときの判断基準を具体的に示します。
なぜ仕様書を先に作るのか
AIにいきなり「ブロック崩しを作って」と頼むと、コードは出てきます。しかし「ボールが壁で反射する角度」「ブロックを全部消したときの処理」「スコアの加算タイミング」などが暗黙の前提として処理されるため、あとから「ここを変えたい」と伝えると整合性が崩れやすくなります。
仕様書を先にAIへ書かせる目的は二つあります。一つは設計の抜け漏れを早い段階で発見すること。もう一つは、以後の会話で「仕様書の〇〇節に従って」と参照できる共通の土台を作ることです。仕様書があると、コード修正の依頼を「3.2節の衝突判定を変更して」という形で伝えられるようになり、AIが文脈を見失いにくくなります。
仕様書生成プロンプトの基本構造
プロンプトには「ゲームの概要」「プレイヤーの操作」「ゲームの目的と終了条件」「画面・UI」「技術要件」の五つのブロックを渡すと、AIが構造化しやすくなります。以下はそのままコピーして使えるテンプレートです。【 】の中を自分のゲームに合わせて書き換えてください。
あなたはゲーム開発の仕様書ライターです。
以下の情報をもとに、HTML+JavaScriptで実装するブラウザゲームの仕様書を作成してください。
## ゲーム概要
【ゲームの一言説明。例：マウスで操作するシンプルなブロック崩し】
## プレイヤーの操作
【操作方法を箇条書きで。例：マウスの左右移動でパドルを動かす】
## ゲームの目的と終了条件
【勝利条件・失敗条件・スコア。例：全ブロックを消すとクリア。ボールを3回落とすとゲームオーバー】
## 画面・UI
【画面サイズ、表示要素。例：640×480px。スコア・残機を上部に表示】
## 技術要件
【使うAPIや制約。例：Canvas API使用。外部ライブラリなし。単一HTMLファイルで完結】
---
出力形式：
1. ゲーム概要（1〜2文）
2. 画面仕様（サイズ・座標系・フレームレート）
3. ゲームオブジェクト一覧（名前・初期値・動作）
4. 操作仕様
5. ゲームロジック（状態遷移・スコア計算・衝突判定の方針）
6. UI仕様（表示項目・フォント・レイアウト）
7. 未決事項（情報が不足していて判断が必要な点）
不明な点は推定せず、「7. 未決事項」として列挙してください。このプロンプトで重要なのは末尾の「不明な点は推定せず未決事項として列挙する」という指示です。これを入れないと、AIは都合よく穴を埋めてコードを出し、後で「そこが違う」という修正が発生します。
出力を受け取った後の確認ポイント
AIが仕様書を出力したら、コードに進む前に「7. 未決事項」を必ず読みます。ここに列挙された問いに答えると仕様書は完成に近づきます。よく出てくる未決事項の例を挙げます。
- 難易度設定：ボールの初速、加速タイミングをどう決めるか
- ブロックの種類：全ブロックが同じ耐久値か、複数ヒット必要なブロックがあるか
- ゲームオーバー後の処理：リスタートボタンを表示するか、自動でリセットするか
- モバイル対応：タッチ操作を想定するか
これらを決めずに「コードを書いて」と進めると、AIがいずれかを選択して実装し、後から変更するコストが生じます。未決事項に答えてから「上記を踏まえて仕様書を更新して」と続けるのが最も効率的な進め方です。
仕様書の粒度を調整する二つのケース
すべてのゲームに同じ粒度の仕様書が必要なわけではありません。目安として二つのケースで使い分けられます。
シンプルなミニゲーム（操作1〜2種類・画面1枚）
基本テンプレートそのままで十分です。仕様書は1,000字前後になることが多く、コード生成を1回で完結させやすいサイズです。仕様書とコードを同一の会話スレッドに置いておけば、AIが文脈を保持しやすくなります。
複数画面・セーブデータを扱うゲーム
仕様書を「セクションごとに分けて複数回に出力してもらう」方法が有効です。以下のように追加指示を加えます。
ゲームロジックが複雑なため、仕様書を次の3部に分けて出力してください。
・第1部：画面遷移と状態管理
・第2部：ゲームオブジェクトと衝突判定
・第3部：セーブデータの構造とUI
それぞれ独立して参照できるよう、各部に概要を1段落で書いてください。分割することでAIの出力1回あたりの情報量が適切になり、見落としが減ります。コードを書かせるときも「第2部に基づいて衝突判定の関数だけ実装して」という形で範囲を絞れます。
仕様書をコード生成につなぐときの注意点
仕様書が完成したら、コード生成の最初のメッセージに仕様書全文を貼り付け、「この仕様書に従って実装してください」と伝えます。このとき失敗しやすい点が二つあります。
一つ目は仕様書を要約して渡すことです。「スコアをカウントするブロック崩し」のように圧縮すると、AIはふたたび詳細を推定し始めます。仕様書は全文そのまま渡します。
二つ目は会話の途中で仕様書を変更することです。実装中に「やっぱりボールの速度を変えたい」と思ったとき、仕様書を更新せずにコードだけ変えるよう頼むと、仕様書とコードが乖離し始めます。変更を依頼するときは「仕様書の2.3節を〇〇に変更したうえで、その箇所のコードを書き直して」とセットで伝えることが、後々の混乱を防ぎます。
次の行動
上記のテンプレートを使って、作りたいゲームの仕様書をAIに出力させてみてください。「7. 未決事項」に答えながら仕様書を育て、すべての項目が埋まった段階でコード生成に進むと、手戻りが少なくなります。完成したゲームはHTMLファイルまたはZIPファイルとしてアソバースに投稿できます。
