ゲームの企画書をAIで作る方法【2026年】テンプレートと仕様書への変え方

ゲームの企画書をAIに書かせるときは、1枚の企画書と、コード生成AIに渡す仕様書を分けて作るのが近道です。AIへの依頼は「質問」「下書き」「辛口レビュー」の3回に分け、道具と期間と作る範囲は人が決めます。

企画書は人が「作る価値があるか」を判断するための紙で、仕様書は作る側が迷わないように数値と条件を埋めた紙です。1つの文書で両方を兼ねようとすると、企画書としては細かすぎ、仕様書としては曖昧なものになります。

この記事の目次

1. 01ゲームの企画書と仕様書は何が違うのか
2. 02企画書に書く項目と、個人制作で省ける項目
3. 03コピーして使える1枚企画書のテンプレート
   1. 記入例
4. 04AIに企画書の下書きを書かせる5つの手順
   1. プロンプト1　足りない情報を質問させる
   2. プロンプト2　テンプレートに沿って下書きを書かせる
   3. プロンプト3　辛口でレビューさせる
5. 05企画書をそのままAIに渡すと、足りない値をAIが埋める
   1. 企画書の言い回しを仕様書の書き方に直す
6. 06コピーして使えるAI向け仕様書のテンプレート
   1. 記入例
7. 07AIに仕様書の穴を探させる
8. 08仕様書をコード生成AIに渡して更新していく
   1. 失敗しやすいパターン
9. 09よくある質問
10. 10まとめ
11. 11次に読みたい記事

ゲームの企画書と仕様書は何が違うのか

企画書は「何を・なぜ作るか」を伝えて承認をもらう資料、仕様書は「どう作るか」を作る人に伝える資料です。元コナミのプランナーが監修したGPCの2本のコラム（企画書編と仕様書編）は、この2つをそう区別しています。企画書編は企画書を開発の方向を定める資料と、仕様書編は仕様書を企画書が通ったあとに作る設計図と位置づけます。

個人で作る場合は、見せる相手が自分とAIだけになることも多いはずです。それでも文書を分ける意味は残ります。違いは次の図と表のとおりです。

	1枚企画書	詳しい企画書	仕様書
目的	おもしろさを一目で伝え、作るか決める	遊びの仕組みと続けたくなる理由を説明する	作る側が迷わないように、動きを決め切る
読む人	自分、相談相手、提出先	共同制作者、提出先	プログラマー、そしてコード生成AI
主な中身	コンセプト、画面、遊びの流れ	サイクル、続ける理由、体制と期間	画面遷移、数値、条件、作らないもの
曖昧さ	多少あってよい	少しあってよい	残さない
AIに渡すか	下書きを書かせる対象	下書きを書かせる対象	コード生成に渡す対象

企画書は枚数の違う2つの形で使い分けられます。企画書編には、チームや採用担当者に通すための「5枚企画書」と、忙しい人が1枚で理解できる「ペライチ企画書」の使い分けが載っています。ペライチは5枚版が完成してから作るのが鉄則とのことですが、これは仕事や提出用の話なので、個人制作では1枚を先に作り、足りない項目を足していく進め方が現実的です。

呼び方や書式に決まりはありません。仕様書編も、仕様書には絶対に正しい形はなく、様式は書く人によってまったく違うと述べています。ゲームデザインドキュメントのような名前の文書に出会ったときも、中身が判断のための文書か、作る人向けの文書かで見分けられます。以下の呼び分けは、前者が企画書、後者が仕様書です。

全体の工程は次の5つです。この記事は、アイデアが1つに決まったあとのSTEP 2から始まります。

• STEP 1アイデア一行コンセプト
• STEP 2企画書（1枚）AIと下書き
• STEP 3仕様書数値と条件に直す
• STEP 4穴探しAIにレビューさせる
• STEP 5コード生成範囲を区切って渡す

STEP 1のアイデアの出し方は、次の記事で扱っています。

関連記事ゲームのアイデアをAIで出す方法【2026年】7つのプロンプトと絞り方

企画書に書く項目と、個人制作で省ける項目

個人制作では、コンセプト、遊びの流れ、作る範囲などを必ず書き、売上目標と開発費は省いてかまいません。企画書の項目は資料によって少しずつ違いますが、よく挙がるものは共通しています。

ChatGPTでの企画書づくりを紹介した記事では、構成要素としてタイトルとキャッチコピー、企画の意図とコンセプト、ゲーム概要を挙げています。ほかに、ジャンルとターゲットとプラットフォーム、世界観、画面と操作方法、ゲームシステム、市場ニーズと競合優位性、開発規模とスケジュールも挙がる項目です。

5枚企画書の側では、1枚目が目的とコンセプト、2枚目がゲーム概要と画面、3枚目がゲームサイクル、4枚目がモチベーションフロー、5枚目がスケジュールと制作体制です。ゲームサイクルは遊びがどう回るかの図、モチベーションフローはプレイヤーが遊び続ける理由を言葉にしたものを指します。

これらを個人で作るゲームに当てはめると、省いてよい項目と省かないほうがよい項目に分かれます。次の表は、この記事での整理です。

項目	書くこと	個人制作では
コンセプト	一行で、どこで何をしてどうなるゲームか	必ず書く
なぜ作るか	解消したい不満や不便、遊んでほしい場面	必ず書く。短くてよい
遊びの流れ	数秒ごとに繰り返す行動のまとまり	必ず書く
続けたくなる理由	もう一度遊ぶ動機になる仕組み	必ず書く
画面イメージ	メイン画面で何が見えるか	文章か手書きの図で足りる
作る範囲	入れるものと入れないもの	必ず書く。完成までの距離が読める
道具と期間	使うツールと、作業に使える時間	人間が決めて書く
世界観とあらすじ	舞台、登場人物、物語	物語が主役でなければ数行でよい
市場と競合の分析	想定する客層と似たゲームとの差	公開先を決めるときに調べる。企画書では一言でよい
売上目標と開発費	金額の計画	仕事として受注するときだけ

AIに「ゲームの企画書を書いて」とだけ頼むと、売上目標や開発費の欄まできれいに埋まって出てきます。先ほどのChatGPTの記事も、詳しい情報を与えていない開発規模の欄は根拠のない回答や現実的でない回答になるかもしれないと注意しています。道具と期間、作る範囲は人が決めて渡す項目です。

項目が決まったら、次はそれを1枚にまとめたテンプレートです。そのままコピーして使えます。

コピーして使える1枚企画書のテンプレート

次のテンプレートは、上の表で「必ず書く」とした項目を1枚にまとめたものです。AIとの会話や手元のメモに貼って使えます。

【ゲームのタイトル（仮）】

【一行コンセプト】
どこで・何を・どうなるゲームか

【遊ぶ人と場面】
誰が、いつ、どんな姿勢で遊ぶか

【なぜ作るか】
解消したい不満や不便、遊んでほしい理由

【遊びの流れ】
プレイヤーが数秒ごとに繰り返す行動を、矢印でつないで書く
例）見る → 判断する → 操作する → 結果が出る

【続けたくなる理由】
失敗しても「もう一度」と思える仕組み

【ほかのゲームとの違い】
似たゲームと比べて、違う点を1〜2つ

【画面イメージ】
メイン画面に何が見えるかを2〜3行で

【作る範囲】
入れるもの
入れないもの

【道具と期間】
使うツール
作業に使える時間

【完成の目安】
何ができたら完成とするか

記入例

上のテンプレートを埋めた例です。ゲーム名と内容は説明用に作った架空のもので、次の仕様書の章でも使い続けます。

項目	記入例
タイトル（仮）	ねこの引っ越しレーン
一行コンセプト	道路の3つのレーンを切り替えて、落ちてくる荷物を避けながら猫の引っ越し荷物を運ぶゲーム
遊ぶ人と場面	通勤電車の中で、片手のスマートフォンで遊ぶ人
なぜ作るか	電車の中で音を出さず、一度ごとに終わる短い遊びが欲しい
遊びの流れ	荷物が来るのを見る → 避けるレーンを選ぶ → スワイプで切り替える → 当たるかどうかが分かる
続けたくなる理由	拾った荷物の得点がハイスコアとして残り、あと少しで更新できる
ほかとの違い	運ぶ荷物の中に、避けずに拾うと得点になるものが混ざっている
画面イメージ	縦長の画面に3つのレーン。下に猫のトラック、上から荷物が降りてくる
作る範囲	入れるのは1つのステージ、得点、ゲームオーバー。入れないのはランキング、課金、複数ステージ
道具と期間	ブラウザで動くHTML1ファイル。休日に少しずつ進める
完成の目安	タイトルから遊び始めて、ゲームオーバーまで通して遊べること

AIに企画書の下書きを書かせる5つの手順

企画書は一気に書かせず、AIへの依頼を質問、下書き、辛口の見直しの3回に分けて進めます。その前後に、人が答える作業と削る作業を挟んだ5つの手順です。AIが空欄を想像で埋める場面が減り、人が決めるべきところを先に決められます。

1. 材料を渡して質問させるアイデアと制約を貼り、足りない情報をAIに質問させます。
2. 質問に答える道具、期間、遊ぶ場面など、人間にしか決められないことを答える段階です。
3. テンプレートに沿って下書きを書かせる上の1枚企画書の項目名をそのまま指定します。
4. 辛口でレビューさせる褒めずに、弱いところと矛盾を指摘させます。
5. 人が削って確定する作る範囲を削り、完成の目安を自分の言葉で書き直す仕上げです。

プロンプト1　足りない情報を質問させる

これから、ゲームの1枚企画書を一緒に作ります。
まだ企画書は書かないでください。
最初に、企画書を書くために足りない情報を質問してください。

【アイデア】
（一行コンセプトや、気に入った案を貼る）

【決まっている制約】
・作る人は自分だけで、プログラミング初心者
・使う道具：（例：ブラウザで動くHTML1ファイル）
・作業に使える時間：（例：休日に少しずつ）

質問は重要な順に最大5つまでにしてください。
こちらの答えを待たずに、勝手に想像して進めないでください。

「勝手に想像して進めないでください」と書くのがこのプロンプトの要です。質問を5つまでに絞らせると、答える側の負担も小さくなります。

プロンプト2　テンプレートに沿って下書きを書かせる

次の材料から、ゲームの1枚企画書を書いてください。
項目は下の【テンプレート】の見出しをそのまま使ってください。

【材料】
（アイデアと、質問への自分の答えを貼る）

【テンプレート】
（上の1枚企画書のテンプレートを貼る）

【守ること】
・材料にない情報は書かず、「未定」と書く
・開発費や売上の予想は書かない
・遊びの流れは、プレイヤーの操作を主語にして書く
・作る範囲は、入れるものと入れないものを分けて書く

「材料にない情報は書かず、未定と書く」の一文が効きます。ここで未定と書かれた項目が、人が決める宿題になります。

プロンプト3　辛口でレビューさせる

次の企画書を、辛口のレビュアーとして読んでください。褒める必要はありません。

・おもしろさが伝わらない箇所
・作る範囲に対して大きすぎる箇所
・項目同士で矛盾している箇所
を、重要な順に最大5つ挙げ、直し方を1行ずつ添えてください。

【企画書】
（下書きを貼る）

AIは頼んだ人に合わせて褒める方向に寄りやすいので、最初に立場を指定します。指摘された箇所を直して、作る範囲を削れば、1枚企画書は完成です。

企画の段階で使えるプロンプトは、次の記事にもまとめています。

関連記事ゲームの作り方プロンプト集【コピペOK】企画から公開まで32本

1枚企画書ができたら、次はコード生成AIにそのまま渡すとどうなるかです。

企画書をそのままAIに渡すと、足りない値をAIが埋める

小さな試作ならそのままでも動きますが、少し遊べる形にしたい場合は仕様書に直したほうが確実です。理由は、企画書が人に向けた文章だからです。

仕様書編では、作る側が見ているのは「自分たちの作業に落とせるか」と「判断を丸投げされていないか」の2点だとしています。曖昧な部分を自分たちで埋めさせられないか、という見方です。コード生成AIでも、書かれていない値はAIが一般的な値で埋めて先に進むことが多くなります。

速度や出現間隔をAIが決めた結果が、「それっぽいが思っていたのと違う動き」になりがちです。AIに仕様書を書かせる取り組みを紹介した記事には、AIの出力がぶれる理由のひとつは、どういう構成で書けばよいかが曖昧なことだとあります。書かせる場面の話ですが、構成が曖昧だとぶれるという点はコード生成にも当てはまると考えられます。

次の4種類の変換が、企画書の言い回しを仕様書に近づける方法です。これはこの記事での整理です。

企画書の言い回しを仕様書の書き方に直す

企画書の書き方	仕様書での直し方
テンポよく進む	一度のプレイの長さの目標と、荷物が出る間隔の値を決める
だんだん難しくなる	段階ごとの速度と出現数を表にする。何が基準で次の段階に移るかも書く
気持ちよく操作できる	「左にスワイプしたら、1つ左のレーンに移る」のように、入力と結果を1対1で書く
かわいい見た目	最初は図形で代用すると決める。色と大きさだけ指定する
スマホでも遊べる	基準になる画面の大きさと、縦持ちか横持ちかを書く
やられたらやり直し	やり直したときに、リセットされるものと残るものを分けて書く
あとでランキングも	「作らないもの」の欄に入れる

変換のしかたが分かったところで、次は骨組みになるテンプレートです。Markdownのテキストにして、コード生成AIにそのまま読ませます。

コピーして使えるAI向け仕様書のテンプレート

仕様書はMarkdownのテキストにしておくと、コード生成AIにそのまま読ませられます。次のテンプレートは、1枚企画書から仕様書を作るときの骨組みです。

# SPEC.md（ゲーム名）

## 0. このファイルの使い方
・この仕様書を正とする
・書かれていないことは勝手に決めず、質問する
・今回の作業範囲は「マイルストーン◯」だけ

## 1. 目的と勝ち負け
・プレイヤーが何を目指すか
・ゲームが終わる条件

## 2. 画面と遷移（表）
| 画面 | 表示するもの | 次に移る条件 |

## 3. 操作（入力と結果の表）
| 入力 | 条件 | 結果 |

## 4. 数値（定数の表）
| 名前 | 値 | 単位 | 意味 |

## 5. ルールの詳細
・出現のルール、得点のルール、段階の変わり方

## 6. 受け入れ条件
・できたかの確かめ方を「〜したら〜になる」で並べる

## 7. 作らないもの

## 8. 未決事項（人が決める）

## 9. マイルストーン
・最小版から完成までを4〜5段階に分ける

## 10. 更新履歴
| 日付 | 内容 | 理由 |

見出しの順に埋めれば、そのまま仕様書になります。ChatGPTやGeminiに頼むときは、1枚企画書とこのテンプレートを貼り、「項目に沿って仕様書を作って。決められない値は未決事項に入れて」と頼みます。プロンプトの全体は、次の記事の手順に重ねて使えます。

関連記事ChatGPT・Geminiでゲームを作る手順【2026年】プロンプト例と公開方法

記入例

先ほどの「ねこの引っ越しレーン」を仕様書にすると、次のとおりです。ここに載せる値は説明用の設計値で、実際に遊んで調整する前提のものです。

画面と遷移の表です。

画面	表示するもの	次に移る条件
タイトル	ゲーム名、ハイスコア、スタートボタン	スタートボタンを押したらプレイ中へ
プレイ中	レーン、猫のトラック、荷物、得点	ライフが0になったら結果へ
結果	今回の得点、ハイスコア、もう一度ボタン、タイトルへボタン	もう一度ボタンを押したらプレイ中へ。得点とライフはリセット。タイトルへボタンを押したらタイトルへ

操作の表です。

入力	条件	結果
左へスワイプ	トラックが左端のレーンにいない	1つ左のレーンへ移る
左へスワイプ	トラックが左端のレーンにいる	何も起きない
右へスワイプ	トラックが右端のレーンにいない	1つ右のレーンへ移る
短いタップ（スワイプではない接触）	プレイ中	何も起きない

数値の表です。値はコードの先頭に定数としてまとめさせると、あとで調整できます。

名前	値	単位	意味
LANE_COUNT	3	本	レーンの数
START_LIFE	3	個	開始時のライフ
SPAWN_INTERVAL	1.2	秒	荷物が出る間隔の初期値
FALL_SPEED	0.4	画面の高さ/秒	荷物が落ちる速さの初期値
SPEED_UP_EVERY	20	秒	速さが上がる間隔
HIT_INVINCIBLE	1.0	秒	ぶつかったあとの無敵時間
SCORE_PICKUP	50	点	拾う荷物の得点

受け入れ条件です。ゲームを遊んで1つずつ確かめられる形にします。

番号	条件
A-1	避ける荷物にぶつかったら、ライフが1減り、無敵時間のあいだはライフが減らない
A-2	拾う荷物にぶつかったら、得点が増え、ライフは変わらない
A-3	ライフが0になったら、結果画面に移る
A-4	結果画面でもう一度を押したら、得点0とライフ3で始まり、前の回の荷物は残っていない
A-5	得点がハイスコアを超えたら、次にタイトル画面へ戻ったときに新しい値が表示されている

最後に、作らないものと未決事項です。

仕様書は、書いた本人には穴が見えません。次は、その穴をAIに探させます。

AIに仕様書の穴を探させる

仕様書の穴探しは、実装する担当者の立場でAIに読ませ、迷いそうな点を挙げさせるのが近道です。仕様書編では、仕様書は書くより見ることが大切で、初稿を完璧にするのはプロでも不可能としています。書いたあとは、作る側の立場で読み直すのが基本です。

次の仕様書を、これから実装する担当者の立場で読んでください。
仕様書に書かれていないために、実装中に迷いそうな点を、重要な順に最大10個挙げてください。

・答えを推測で埋めないでください
・それぞれ「何が決まっていないか」「決めるときの選択肢」を書いてください
・矛盾している箇所があれば、別に挙げてください

【仕様書】
（SPEC.md を貼る）

出てきた質問に人が答えて、仕様書に書き足します。そのうえで、ゲームで穴が出やすい場所を次の表で点検してください。この表もこの記事での整理で、公式の基準ではありません。

確認する場面	決めておくこと
起動した直後	最初に出る画面と、保存された値がないときの表示
ゲームオーバーのあと	リセットされるものと、残るもの
同時に起きたこと	2つの荷物に同時にぶつかったときの処理順
連打や同時の入力	短い間に続けて入力したときに、全部受けるか、最初の一度だけか
中断して戻ったとき	別のタブや別のアプリから戻ったときに、止まるか、進み続けるか
画面の大きさ	縦長と横長、小さい画面での配置
数値の上限と下限	得点やライフが取りうる範囲。0より小さくならないか
保存するもの	何をどこに保存し、いつ消えるか
音	音を出すかどうかと、出す場合の初期状態
遊び方の説明	初めて遊ぶ人に、何をどこで伝えるか

10項目のすべてを書き切る必要はありません。決めないものは「作らないもの」か「未決事項」に入れておけば、AIが勝手に決める余地を減らせます。

穴が埋まったら、仕様書をコード生成AIに渡す段階です。渡し方には3つの決まりがあります。

仕様書をコード生成AIに渡して更新していく

仕様書はファイルとして保存し、マイルストーンごとに区切ってコード生成AIに渡します。Claude Codeのドキュメントでは、CLAUDE.mdは毎回のセッションの開始時に読まれる、プロジェクトの持続的な指示とのことです。同じドキュメントは、指示は具体的で短いほど守られやすいこと、1つのファイルを200行以内に収めるのが目安だとも書いています。

CodexのドキュメントにはCodexは作業の前にAGENTS.mdを読むとあります。そこで、仕様書の全文をCLAUDE.mdやAGENTS.mdに入れるのではなく、別ファイルのSPEC.mdに置くのが基本です。CLAUDE.mdには「SPEC.mdを正とする。今回の作業範囲はマイルストーン1だけ」のように短く書くのが扱いやすい形です。これもこの記事での運用案です。

道具ごとの始め方は、次の記事で説明しています。

関連記事Claude CodeとCodexでゲームを作る手順【2026年版】導入から公開まで

渡すときの決まりは3つです。

1. マイルストーンごとに渡す仕様書の全体を渡しても、実装を頼むのは「今回の範囲」だけです。
2. 受け入れ条件で確かめるできあがったら、受け入れ条件を1つずつ遊んで確かめ、結果を伝えます。
3. 変えるときは仕様書を先に直すコードだけを直すと、仕様書と実物がずれます。

3つ目の根拠は、仕様書編にあります。仕様書編は、バグの発生原因を「最初から存在していたバグ」と「仕様変更で生まれたバグ」に分け、圧倒的に多いのは後者だとしています。そして「いつ・何を・どう変えたから・どうなったか」が更新履歴で追えれば、原因究明が格段に速くなると述べています。

同じコラムは更新履歴の項目に、更新日と該当シート、更新内容、更新理由、レビュー済みの有無、実装済みの有無の5つを挙げています。自分だけで作るなら、日付と内容と理由の3つで足りるでしょう。

失敗しやすいパターン

やりがちなこと	起きること	直し方
企画書をそのまま渡して全部作らせる	平均的なゲームが出てくる。足されていない機能もある	仕様書に直し、作る範囲を区切る
AIが書いた数値をそのまま採用する	遊んでみると難しすぎる、または簡単すぎる	数値は定数表にまとめ、遊んで人が調整する
未決事項を空欄のまま渡す	AIが勝手に決めて、気づかないまま進む	「質問すること」と明記する
会話の中で仕様を変えていく	長い会話の末に、古い仕様のコードが残る	変更は仕様書に書き、更新履歴に残す

よくある質問

まとめ

ゲームの企画書をAIで作るときは、企画書の下書きまでをAIに頼み、コードを書かせる前に数値と条件を埋めた仕様書へ直します。この1手間で、AIが空欄を勝手に埋める場面を減らせます。まずは1枚企画書のテンプレートを埋め、AIに質問させるところから始めてください。作る範囲と完成の目安だけは、自分の言葉で書き切るのがコツです。

次に読みたい記事