ゲームのプロトタイプとは｜AIで面白さを最速で確かめる試作の進め方

2026年10月4日

プロトタイプ（試作）は、企画で立てた「これは面白いはず」という仮説を、できるだけ少ない手間で確かめる工程です。この連載の工程の順では、企画のすぐ後、仕様書（GDD）の前に置いています（全体の流れは「ゲーム開発の全工程マップ」）。資料によっては、企画と試作をまとめて「プリプロダクション（作るべきか・作れるかを、企画と試作で確かめる段階）」と呼ぶこともあります。

本記事では、プロトタイプの定義と、ファーストプレイアブル・バーティカルスライスとの違い、紙とデジタルの使い分け、確かめる問いの絞り方、期間の区切り方、誰に遊んでもらうか、続ける・変える・捨てるの判断までを、個人〜少人数の開発を基準にまとめます。後半では、AI エージェントで試作が安く速く作れるようになったとき、何が変わり、何が変わらないかを整理します。ステージを単純な形で仮組みする工程は「グレーボクシングとは」、一部分を製品版に近い品質で作る工程は「バーティカルスライスとは」で扱います。

夕宮たいだ

ふぁ……みんな〜、今日はプロトタイプの話だよぉ。きれいに作り込む前に、まず「それ、本当に面白い？」を確かめる工程なんだぁ。一緒に見ていこ〜。

プロトタイプとは

ひとことで：遊びが成立するか（作るべきか）を確かめる、使い捨ての試作です。

プロトタイプは、アイデアや仕組みを試すための試作で、紙で作ることもあります（Wikipedia: Video game development）。インディースタジオ Vlambeer の共同創業者として知られる Rami Ismail 氏は、プロトタイプはそのゲームを作る「べきか」を見極めるためのもので、質の高さ・整った構造・再利用を目指さず、問いに素早く答えることだけに集中すべきだと書いています（Prototypes & Vertical Slice、2022年9月）。

似た言葉に、ファーストプレイアブルとバーティカルスライスがあります。どれも開発途中の版ですが、確かめることが違います。

版	確かめること	見た目の品質	作った物のその後
プロトタイプ	遊びが成立するか（作るべきか）	仮のまま。手触りに関わる所だけ作る	コードと素材は捨て、わかったことを持ち越す
ファーストプレイアブル	主要な遊びが初めて通しで動くか	仮の素材が多い	以後の開発で作り足していく
バーティカルスライス	この品質で作れるか	一部分を製品版に近い品質まで作る	品質の基準と見積もりに使う

ファーストプレイアブルは「主要な遊びが初めて通しで動く版」で、会社によってはアルファと同じ意味で使います。バーティカルスライスは「ゲームの一部分を製品版に近い品質まで作り、この品質で作れることを示す版」です。Rami Ismail 氏は、プロトタイプが「作るべきか」を確かめるのに対し、バーティカルスライスは「作れるか」を確かめる、制作のための試作だと区別しています。

1本のゲームで、試作が1つとは限りません。わからない点が複数あれば、問いごとに小さな試作を分けて作ります。

作る範囲と見た目の品質の2軸に、プロトタイプ（作るべきか）、ファーストプレイアブル（主要な遊びが通しで動くか）、バーティカルスライス（この品質で作れるか）を置いた図 — 図1：3つの版は確かめることが違う。プロトタイプは作るべきか、バーティカルスライスは作れるかを確かめる

プロトタイプの目的

ひとことで：作り込む前に、いちばん大きな「わからない」を安く確かめることです。

量産に入ってから「遊んでみたら面白くない」と気づくと、それまでに作った素材や仕組みの多くが無駄になります。試作なら、同じ判断を数日〜数週間の手間で下せます。試作で確かめることは、主に次の4種類です。

確かめること	問いの例
面白さ	コアループを10回繰り返しても飽きないか
手触り	操作して気持ちいいか、思ったとおりに動くか
伝わるか	説明なしでルールがわかるか
作れるか	敵を100体出しても重くならないか（技術の試作）

作れるかを確かめる技術の試作もありますが、本記事では主に遊びの試作を扱います。反対に、試作だけでは答えられない問いもあります。「売れるか」は類似作の調査やストアページへの反応で、「全体を通して飽きないか」は、より後のプレイテストで確かめます。

試作は、予想していなかった面白さが見つかる場でもあります。任天堂の『スプラトゥーン』は、約70のアイデアの中から選ばれた試作が出発点で、豆腐のような形のキャラクターがインクを撃ち合うものでした。試作の時点で4人対4人の対戦ができ、自分の色のインクの上では姿が見えなくなるため、待ち伏せのような駆け引きが生まれることがわかったと、開発者が語っています（任天堂「社長が訊く『Splatoon（スプラトゥーン）』」）。キャラクターはその後、人の形やウサギを試したうえで、インクを吐く生き物としてイカに決まりました（同インタビューの3ページ目）。

夕宮たいだ

豆腐からイカになったんだねぇ。見た目は後から変わっても、「塗って隠れる」面白さは、試作の時点でもう見えてたんだぁ。

プロトタイプの進め方

ひとことで：問いを1つ決め、期限を切り、手触りに関係ない所は作らずに遊べる形にします。

確かめる問いを1つに絞る

「面白いか」は広すぎて、遊んでも答えが出ません。遊べば Yes か No かが言える大きさまで、問いを絞ります。

ジャンル	広すぎる問い	1つに絞った問い
アクション	爽快なアクションになるか	壁を蹴って登る動きは、10回続けても気持ちいいか
パズル	新しいパズルになるか	重力の向きを変える操作だけで、3手先を考える楽しさが出るか
ノベル	分岐が面白いか	好感度を見せないまま分岐させると、選ぶときに迷うか
カードゲーム	戦略性があるか	手札を1枚だけ相手に見せるルールで、読み合いが生まれるか

問いと一緒に、「どうなったら Yes とするか」も先に書きます。例：「初めて遊んだ5人のうち3人以上が、説明なしでもう1回遊びたがる」。後から基準を決めると、都合のよい解釈をしてしまいます。

紙のプロトタイプとデジタル

試作は、コードを書くとは限りません。問いに合う、いちばん安い方法を選びます。

方法	向いている問い	例
紙（カード・方眼紙・付箋）	ルール、ターン制の駆け引き、画面の流れ	手書きのカードで対戦する、方眼紙で盤面を作る、付箋で画面の移り変わりを並べる
表計算	数値の増え方、お金の流れ	1時間遊んだときの所持金の増え方を計算する
文章だけ	ノベルの分岐、文章の手触り	選択肢と結果だけのテキスト版を読んでもらう
デジタル（ゲームエンジン）	タイミング、操作、カメラ、物理	カプセルと立方体だけでジャンプを試す

カードゲームやボードゲーム風のルールなら、紙で1日に何度も遊べます。反対に、ジャンプの気持ちよさやカメラの動きは、紙では確かめられません。ジャンルごとの「最小の試作」と「作らない物」の例は次のとおりです。

ジャンル	最小の試作	作らない物
2Dアクション	四角いキャラクター1体と足場だけの1部屋。ジャンプの数値をスライダーで変えられる	敵の種類、ステージの数、タイトル画面
パズル	方眼紙か表計算で10問を手作りし、人に解いてもらう	問題の自動生成、演出、ヒントの機能
ノベル	選択肢と結果だけのテキスト版。10分で読める長さ	立ち絵、背景、演出
カードゲーム	手書きのカード20枚と、1枚の説明書	カードの絵、CPU の対戦相手、ネット対戦

夕宮たいだ

ほよ？紙でもプロトタイプになるんだぁ。カードゲームなら、手書きのカードで今日から試せるねぇ。

期間を区切る

試作は、始める前に期限を決めます（例：1つの問いに3日）。期限が来たら、途中でも遊んで判断します。期限内に答えが出ないのは、問いが大きすぎるサインです。問いを2つに分け、小さい方から試します。Rami Ismail 氏も、プロトタイプは速く、安く、狙いを絞って作るものだとしています。

たとえば、カードゲームの「手札を1枚だけ相手に見せる」ルールを3日で確かめるなら、次のように回します（日数は例です）。1日目は手書きのカードで自分と身内が遊び、ルールの穴を直します。2日目は、直したルールで初めての人に遊んでもらい、迷った所と「もう1回」の有無を記録します。3日目に Yes の条件と照らして、続ける・変える・捨てるを決めます。デジタルで作るのは、このルールで読み合いが生まれると確かめてからです。

見た目より手触り

試作の見た目は、灰色の箱や丸で十分です。見た目がきれいだと、遊びの弱さに気づきにくくなります。その代わり、手触りに関わる所は試作でも作ります。手触りとは、入力への反応の速さ、動きの速さと重さ、当たったときの音や画面の揺れなど、触った感触を決める要素です。

調整したい数値（ジャンプの高さ・重力・敵の速さなど）は、遊びながら画面上で変えられるようにしておくと、1回の試作で多くの案を比べられます。

ただし、見た目そのものが遊びの核になるゲーム（光と影で道を作るパズルなど）では、見た目が問いの一部になります。その場合も、確かめたい見た目の要素だけを作り、ほかは仮のままにします。

捨てる前提で作る

Rami Ismail 氏は、試作のコードや素材を、試作の段階が終わった後に使わないよう勧めています。他のゲームから、使ってはいけない素材を借りていた場合はなおさらです。理由は次のとおりです。

速さを優先して書いたコードは、例外の処理や構造が足りず、直すより作り直した方が早いことがあります
仮に借りた画像や効果音が、権利を確かめないまま本番に紛れ込む危険があります
「とりあえず動く」で済ませた所に、原因を確かめていない不具合や思い込みが残ります

持ち越すのは、わかったことと、決まった数値（ジャンプの高さなど）です。これらは仕様書に書きます（「ゲームデザインドキュメント（GDD）の書き方」）。本番と取り違えないように、試作は本番とは別のフォルダで作ります。

夕宮たいだ

ぁぅ……試作のコード、もったいなくて本番に持っていきたくなるんだよねぇ。持ち越すのは「わかったこと」だけにしておこうねぇ。

誰に遊んでもらうか

ひとことで：自分、身内、ターゲットに近い初めての人、の順に広げ、説明せずに遊ぶ様子を見ます。

遊ぶ人	確かめられること	注意
自分	手触りの調整、明らかな問題	ルールを知っているので、わかりにくさに気づけない
身内・チーム	最初の反応、大きな詰まり	気を遣って褒めがち
ターゲットに近い初めての人	説明なしで伝わるか、もう1回遊びたいか	人数を重ねて見る。公開前の内容を見せる範囲を決めておく

遊んでもらうときは、ルールを説明せず、どこで手が止まるか、何を言うか、終わった後にもう1回遊ぼうとするかを見ます。感想を聞くのは遊び終わった後です。「面白かった？」と聞くと相手は気を遣って答えがちなので、「どこで迷った？」「もう1回やるならどこから？」のように、具体的な場面を聞きます。人の集め方や記録の取り方は「ゲームのプレイテストのやり方」で扱います。

続ける・変える・捨てるの判断

ひとことで：期限が来たら問いへの答えを見て、続ける・変える・捨てるのどれかを決め、わかったことを記録します。

判断	こんなとき	次にすること
続ける	問いに Yes と言え、遊んだ人が自分から「もう1回」と言う	次の問いの試作か、仕様書・ステージの仮組みへ
変える	面白さの芽はあるが、問いの立て方か作り方がずれていた	問いを立て直し、変える所を1つに絞って作り直す
捨てる	何度直しても Yes にならない／面白さが見た目や演出に頼っている	わかったことを記録し、企画に戻る

試作の完了の条件は、「動いた」ではなく「問いに答えが出た」です。試作を終えるときは、次の5つを短いメモに残します。

確かめた問いと、Yes の条件
答え（Yes／No／わからない）と、その根拠（遊んだ人の反応・数値）
持ち越す数値（ジャンプの高さ、1戦の長さなど）
意外だった発見
次に確かめる問い

捨てた試作も、このメモがあれば無駄になりません。同じ問いを別の企画で試すときの出発点になります。

続けると決めたら、試作で答えが出たことを仕様書の数値と条件に書き写し、本番は改めて作ります。次の工程はゲームの種類で変わります。ステージを歩き回るゲームなら、単純な形でステージを仮組みして大きさと動線を確かめます。ノベルやカードゲームなら、仕様書と素材の一覧づくりに進みます。量産の前に「この品質で作れるか」を確かめる段階が、バーティカルスライスです。

問いを1つ決める、条件と期限を決める、作る、遊んでもらう、判断の5段階と、続ける・変える（最初へ戻る）・捨てるの3つの分岐。下に記録の帯 — 図2：試作は「問い→期限→作る→遊ぶ→判断」で一巡し、わかったことを記録して次へ渡す

AIゲーム開発でのプロトタイプ

ひとことで：AI で試作は短時間で作れるようになり、案を並べて比べられます。その分、問いを立てる・遊んで判断する・捨てる、という人の仕事が重くなります。

試作が数時間で作れると、何が変わるか

Claude Code や Codex のような AI エージェントに頼むと、操作・当たり判定・仮の画面がそろった小さな試作なら、数時間で動く形になることも珍しくありません。筆者の場合も、派生作の試作は1日でできました。これで変わるのは、試作の「数」です。

1つの問いに、案を並べて比べられる：ジャンプの物理を3案作り、キー1つで切り替えて遊び比べる
別々の問いを並行して試せる：フォルダを分けて、複数の試作を同時に作らせる（「Claude Code サブエージェント・並列作業ガイド」）
調整の道具まで作れる：数値のスライダー、遊んだ記録を残す仕組み、図形やコードで描いた仮の絵と音

GDC の2026年の調査（回答2,300人超）でも、業務で生成AIを使う人に使い道を聞くと、35%がプロトタイピングを挙げています（GDC 2026 State of the Game Industry）。

ただし、作る時間が縮んでも、遊んで確かめる時間は縮みません。3案を作るのは数時間でも、3案を何人かに遊んでもらって記録を見比べるには、数日かかります。案を並べて比べるときは、比べる観点を先に決め、遊ぶ順番の影響が出ないように順番を人によって入れ替えます。

AI に頼む作業と、人が決めること

作業	AI に頼めること	人が決めること・確かめること
問いを立てる	企画書から、確かめるべき問いの候補を挙げる	どの問いを先に確かめるか
試作を作る	操作・判定・仮の画面、案の切り替え、調整用のつまみ	期限と、作り込まない範囲
遊ぶ・判断する	遊んだ記録の集計、自動で何百回も遊ばせる計測	遊んだ感触、面白いかどうか
片付ける	わかったことのメモの下書き、持ち越す数値の一覧	続ける・変える・捨てるの決断

自動で遊ばせる計測は、ルールが壊れていないか、ある手が強すぎないかを調べるのに役立ちますが、「面白いか」には答えられません。AI は遊んだ感触を持たないからです。操作の気持ちよさや音の心地よさを、体で感じて決めるのは人の役割です。試作の価値は「問いに答えが出たか」で決まり、その答えを出すのは遊んだ人です。

落とし穴

作れてしまうので作り込みすぎる：頼めばすぐ形になるので、問いと関係ない所（メニュー、見た目、演出）まで作りがちです。依頼文に期限と「作らない物」を書きます
試作のコードが、そのまま製品の土台になる：動いている物を捨てるのは惜しく感じます。本番は作り直すと先に決め、移すなら移すと決めたうえで、原因を確かめていない動きがないかを見直します
動いたことで、面白さを確かめた気になる：AI の「完成しました」は、動いたという報告です。問いに答えが出たかどうかは、自分で遊んで判断します

依頼文の例

Goal: 2Dアクションの壁キックが気持ちいいかを確かめる試作を作る
Context: prototypes/wallkick/ に新しく作る。本番のコード（src/）は読まない・使わない
Constraints: 見た目は四角と線だけ。メニューやタイトル画面は作らない。
  ジャンプの高さ・重力・壁の摩擦は、画面のスライダーで変えられるようにする
Done when: キーボードで遊べ、壁キックの3案を数字キーの1〜3で切り替えられる。
  起動の手順が README に3行で書いてある

依頼文の組み立て方は「Claude Code プロンプト設計」で解説しています。

筆者の実例

筆者は、霧で駒が見えなくなる将棋のルールを、開発中の将棋ゲームとは別の、実験用のフォルダで先に作りました（霧で駒が隠れる将棋は、ブラウザ版の「霧将棋」で遊べます）。本番へ移す作業の中で、実験版で「フリーズ」だと思い込んでいた現象の本当の原因が、見えないダイアログが入力を塞いでいたことだとわかりました。試作の「だいたい動く」の中には、こうした思い込みが残ります。本番へ移すときの見直しは、それを見つける機会にもなります。

また、「ドット絵や効果音をコードで作れるか」を確かめる試作もしました。56×84ピクセルのキャラクターを文字のグリッドで打ち込んで待機アニメを24コマ作り、効果音は数値計算で3案を作りました。筆者の評価は「アニメは最高」でした。一方、筆者の環境の Claude は音を聴けないため、効果音は数値で検証しました。

夕宮たいだ

「動いた」と「面白い」は別物だよ！ AI が「完成しました」って言っても、遊んで確かめるまでは試作は終わってないんだぁ。

よくある失敗と対処

ひとことで：試作の失敗は、問いがぼやける・作り込みすぎる・捨てられない、の3つに集まりがちです。

失敗	原因	対処
何を確かめたのかわからない	問いを書かずに作り始めた	問いと「Yes の条件」を先に書く
試作が何週間も終わらない	期限を決めていない、問いが大きい	期限を決め、問いを分ける
見た目を作り込んでしまう	見た目が良いと進んだ気がする	灰色の箱と仮の音で判断する
試作のコードが製品の土台になった	作り直す時間を惜しんだ	本番は作り直す。移すなら見直しの時間を取る
仮の素材が本番に残った	他の作品の素材を仮に使った	試作でも権利を確かめた素材だけを使い、仮の素材の一覧を作る
作った本人しか遊んでいない	見せるのが怖い、時間がない	身内、初めての人の順に、説明せずに遊んでもらう
AI の「完成」をそのまま信じた	動作の確認だけで終えた	自分で遊び、問いに答えが出たかで判断する