ゲームのプレイテストのやり方｜AIゲーム開発の観察・アンケート・改善

2026年10月4日

ゲームは、作った本人がいくら遊んでも「初めて遊ぶ人がどこで迷うか」が見えません。作り手は操作も目的も答えも知っているからです。そこで、作っていない人に遊んでもらい、その様子と感想から設計の問題を見つけて直します。これがプレイテストです。工程では、最初から最後まで通して遊べる αROM（アルファ版）ができたころから本格的に始まり、バランス調整やローカライズと並行して続きます。ただし、企画やプロトタイプの段階から小さく何度も行うのが理想です（全体の流れは「ゲーム開発の全工程マップ」）。

本記事では、プレイテストの種類と頼む相手、観察とアンケートのやり方、記録の取り方、Steam Playtest、情報漏れの防ぎ方、結果の読み方までを、個人〜少人数の開発を基準にまとめます。後半では、AI エージェントに遊ばせる「仮想プレイテスト」の置き所も扱います。Steam の規則は2026年10月時点の公式ドキュメントで確認したものです。

夕宮たいだ

ふぁ……みんな〜、今日はプレイテストの話だよぉ。自分で何百回遊んでも、初めての人がどこで止まるかは見えないんだぁ。ほかの人の手を借りるコツを、一緒に見ていこ〜。

プレイテストとは

ひとことで：作っていない人に遊んでもらい、狙いどおりに遊ばれているかを確かめる作業です。

プレイテストで見るのは、「動くかどうか」ではなく「狙いどおりに遊ばれ、狙いどおりに感じてもらえるか」です。Valve の Mike Ambinder 氏は GDC 2009 の講演「Valve’s Approach to Playtesting」で、プレイテストの目的を「面白さ」とし、バグ探しでもバランス調整でもない、と整理しています。同じ講演では、ゲームの設計を「仮説」、プレイテストを「実験」と位置づけています。

似た言葉との違いは次のとおりです。呼び方は会社によって違うので、チームの中で意味をそろえておきます。

呼び方	目的	主に誰が	見るもの
テストプレイ（試し遊び）	作ったものが動くか、手触りはどうか	作った本人・チーム	操作の感触、組み込みの確認
プレイテスト	狙いどおりに遊ばれるか、面白いか、わかるか	作っていない人	迷う・止まる・笑う・やめる瞬間
QA（品質保証）	仕様どおりに動くか、出荷してよいか	テスト担当・QA 会社	不具合の再現手順と重さ

QA が探すのは「仕様と違う動き」、プレイテストが探すのは「仕様どおりなのに伝わらない所」です。テストの途中で見つかった不具合は、QA の流れ（報告・優先度・修正の確認）に回します（「ゲームのデバッグとQA」）。

プレイテストの目的と種類

ひとことで：1回のテストで確かめる問いを1〜2個に絞り、問いに合う形を選びます。

「とりあえず遊んでもらう」と、感想は集まっても何を直せばよいかが決まりません。始める前に「今回は何を確かめるか」を1文で書きます。目的ごとの代表的な形は次のとおりです。

目的	確かめる問い（例）	向く時期	主な方法
面白さ	パズルの1面を、言われなくてももう1回遊ぶか	プロトタイプ〜	観察、遊んだ後の聞き取り
わかりやすさ	説明なしで、ノベルの選択肢やセーブの場所がわかるか	αROM の前後	観察と思考発話
難しさ	2Dアクションの3面のボスで、何回やられ、どこで諦めるか	αROM〜βROM	記録とアンケート
初めて遊ぶ人の体験	タイトル画面からチュートリアルの終わりまで、離脱しないか	体験版の前	初見の人だけで観察
長く遊んだときの体験	カードゲームで、10戦目にもデッキを組み替えたくなるか	βROM の前後	自宅で遊んでもらい記録

「初めて遊ぶ人の体験」は FTUE（First Time User Experience）とも呼ばれ、体験版の印象やレビューを左右しやすい区間です。「長く遊んだときの体験」は短い試遊ではわからないので、数日かけて遊んでもらいます。1回で全部を見ようとせず、時期に合わせて問いを入れ替えます。

プレイテストの1回の流れ。問いを1つ決め、相手と人数を選び、説明せずに観察し、アンケートと記録の集計から症状と処方を分け、直して別の初見の人で確かめる — 図1：問いを1つ決め、観察と記録から直し、別の初見の人で確かめる

誰に頼むか・何人に頼むか

ひとことで：問いに合った「初めての人」を選び、少人数のテストを何回も繰り返します。

頼む相手	強み	弱み	向く問い
自分	いつでもできる	知りすぎていて迷えない	動作と手触り（テストプレイ）
身内（家族・友人・開発仲間）	頼みやすく、何度も頼める	気を遣って褒める。ゲームに慣れた人が多い	早い段階の面白さ、修正の効果
知らない人	正直で、本当に初見	集めるのに手間がかかる	わかりやすさ、初めて遊ぶ人の体験
ターゲットに近い人	狙った層の反応がわかる	探すのが大変	難しさ、面白さの最終判断

初見の反応は、同じ人からは一度しか取れません。2回目からはルールも答えも知っているからです。わかりやすさを確かめるテストには新しい人を回し、身内には修正の効果や遊び込んだ感想を頼む、というように使い分けます。

人数については、使いやすさの調査で知られた目安があります。Jakob Nielsen 氏は2000年の記事「Why You Only Need to Test with 5 Users」で、5人のテストで使いやすさの問題の約85%が見つかるとし、15人に1回頼むより、5人ずつ3回に分けて間に直す方がよいと書いています。同じ記事では、利用者の層が大きく違うなら層ごとに分けること、数値を測る調査にはもっと多くの人が要ることも述べています。これはウェブサイトなどの使いやすさの調査の数字で、面白さの評価にそのまま当てはまるわけではありませんが、ゲームでは次のように考えると無理がありません。

問題を見つけるテスト（迷う所・止まる所）：1回に5人前後。直してから、別の人でもう1回
数で判断するテスト（クリア率・難しさの評価）：もっと多くの人に頼み、ゲームの記録と組み合わせる
大勢に遊んでもらうテスト：Steam Playtest などで外部に配る（後述）

夕宮たいだ

ほえ〜、一度にたくさん集めるより、5人ずつ何回も、なんだぁ。直してはまた見てもらう方が、見つかる問題が多いんだねぇ。

テスターの集め方

ひとことで：身近な所から始め、問いに合う人がいる場所へ広げていきます。

身内・開発仲間：最初の相手。遠慮なく言ってほしいことを先に伝えます
開発者の集まり・SNS：条件（ジャンルの経験・遊ぶ環境）を書いて募ります
展示会や即売会の試遊台：知らない人の初見の反応を一度に多く見られます。ただし1人あたりの時間は短めです
自分のコミュニティ：Discord などに集まった人は作品に好意的な分、厳しい意見が出にくいことがあります（集め方は「インディーゲームの宣伝」）
Steam Playtest：Steam の利用者から申し込みを受けて配ります（後述）
ユーザーリサーチを請け負う会社：費用はかかりますが、人集めから観察・分析まで任せられます

募集の文には、ジャンル、所要時間、遊ぶ環境（PC・コントローラーの有無）、期間、謝礼、守ってほしいこと（SNS に載せてよい範囲など）、記録や録画の扱いを書きます。

説明しないで観察する

ひとことで：遊び方を教えず、手も口も出さずに、迷う・止まる・やめる瞬間を記録します。

プレイテストでいちばん難しいのは、黙って見ていることです。テスターが迷うと、つい「そこはジャンプしながらダッシュです」と言いたくなります。しかし製品を買った人の横に作り手はいません。説明したくなった所は、ゲームが説明できていない所です。その場で教えず、メモに印を付けます。

準備として、次のことを決めておきます。

渡すのは、買った人が手にするものと同じもの（ビルドと、ストアページの説明文程度）
声をかける条件。例：同じ場所で数分進めなくなったら、ヒントを1つだけ出す
録画（画面・手元・表情）をするなら、事前に伝えて同意を取る
観察する人は少なくし、テスターの視界に入らない位置にいる

Valve の講演資料は、直接の観察について「人が言うことより、することが大事」とする一方、観察者がいること自体が結果をゆがめうる点を短所に挙げています。

声に出して遊んでもらう（思考発話）

思考発話（シンクアラウド）は、遊びながら考えていることを声に出し続けてもらう方法です。Nielsen 氏は「Thinking Aloud: The #1 Usability Tool」（2012年）でこの方法を勧めつつ、ふだんしない話し方なので続けにくい、賢く見せようと考えを整えてから話してしまう、進行役の問いかけが行動を変えてしまう、という短所も挙げています。

アクションのように話すと操作が遅れる場面は黙って遊んでもらい、後で録画を見ながら「ここで何を考えていましたか」と振り返ってもらう方法もあります。メニューやパズル、ノベルの選択肢のように手が止まる場面では、思考発話がよく効きます。

メモの取り方

メモは、起きた事実と観察者の推測を分けて書きます。混ぜると、後で事実と想像の区別がつかなくなります。

時刻	場所	したこと（事実）	言ったこと	推測（観察者）
03:12	1-2 の崖	ジャンプで4回落ちる。ダッシュを使わない	「届かない」	1-1 のダッシュの説明を読み飛ばした？
07:40	ショップ	何も買わずに出る	「何が強いのかわからない」	装備の比較の表示が無い
15:05	2面のボス	3回やられて手が止まり、休憩する	なし	回復の手段に気づいていない

時刻は録画と照らし合わせるために書きます。「迷」「詰」「笑」「止」など1文字の印を決めておくと、速く書けて、後で数えるのも楽です。

事実と推測を分けた観察メモの例。時刻・場所・したこと（事実）・言ったこと・推測（観察者）の5列と、迷・詰・笑・止の印の凡例 — 図2：事実と推測は列を分け、1文字の印で数えやすくする

夕宮たいだ

迷ってる人に「そこはね〜」って教えちゃうの、ほんとダメだよぉ。お店で買った人の横には、だれもいないんだからねぇ。

アンケートの設計

ひとことで：遊んだ直後に、誘導しない質問で、数値と自由記述の両方を集めます。

アンケートは記憶が新しいうちに、短く行います。Valve の講演資料では、聞き取りの流れを「アンケート → 1人ずつの聞き取り → 全員での聞き取り」の順にしています。全員で話すと、最初の発言に引っぱられたり周りに合わせたりするので、1人ずつの答えを先に集めるわけです。

質問は2種類を組み合わせます。

数値で答える質問：難しさ・面白さ・わかりやすさを、1〜7などの段階で聞きます。Valve の資料には、敵ごとの難しさを「1＝とても簡単〜7＝とても難しい」で聞く例があります。毎回同じ質問を入れておくと、回ごとの変化を比べられます
自由に書く質問：「いちばん覚えている場面」「やめたくなった所と理由」「わかりにくかった所」など。数値の理由がここに出ます

質問の書き方で答えは変わります。作り手が聞きたい答えをにじませない書き方にします。

誘導してしまう聞き方	中立な聞き方
ボス戦は楽しかったですか？	ボス戦はどうでしたか？
新しいダッシュは気持ちよかったでしょう？	ダッシュの操作感を1〜7で教えてください
操作がわかりにくい所はありましたか？（はい／いいえ）	操作で迷った所があれば、場所と内容を教えてください

「なぜそうしたか」を本人に聞いても、正確な答えが返るとは限りません。Valve の資料も、人は自分がなぜそうしたかを知らないことがある、と注意しています。行動の理由は、観察の記録と照らし合わせて読みます。

データを記録する

ひとことで：どこで止まり、どこでやめたかを、ゲーム自身に記録させて数で見ます。

観察できる人数には限りがあるので、テスト用のビルドに記録の仕組みを入れておきます。

進んだ場所と時刻、各ステージ・各章の所要時間
やられた場所と原因、やり直しの回数
選んだ選択肢・カード・装備と、使われなかった機能
遊ぶのをやめた場所（最後に記録が残った場所）

集めた記録は、マップの上に色で重ねるヒートマップや、「何人がどこまで進んだか」を段階ごとに並べた表にすると、詰まる所がひと目でわかります。Valve の資料にも、『Team Fortress 2』のマップでやられた場所の集まり方をヒートマップにした例が載っています。

一方で同じ資料は、平均が極端な例を隠すこと、数字には文脈（なぜそうなったか）が欠けることも挙げています。平均のクリア時間が狙いどおりでも、1人だけ30分詰まっていたなら、その記録を観察メモと合わせて読みます。外部の人から記録を集めるときは、何を記録するかを事前に伝え、要らない個人情報は集めません（プライバシーポリシーは「ゲーム開発の権利と規約」）。

Steam Playtest を使う

ひとことで：本編とは別の枠を Steam に作り、申し込んだ利用者に無料でテスト版を配る仕組みです。

2026年10月時点の公式ドキュメントでは、「Steam Playtest」は次のように説明されています。

本編に関連付けた別の「子」のアプリ（AppID）でテストする、無料の機能
独自のストアページは無く、本編のストアページに参加の申し込み欄が出る
参加の方式は、既定の「限定」（申込者からランダムに選んで追加。国の指定も可）、申込者を自動で入れる「オープン」、参加者の友だちを招く方式から選べる。キーでも配れ、ストアページの公開前でも使える
有料にしてはいけない（参加の販売もゲーム内課金も不可）。お金を取るなら早期アクセスを使う
参加者とは秘密保持の契約がないので、秘密が守られる前提のテストには向かない
プレイ時間・ウィッシュリスト・レビュー・返金は本編と別に扱われる（Playtest だけの参加者は本編をレビューできない）

また、Steam Next Fest の期間中に Playtest を公開することは勧められていません。体験版（デモ）は宣伝のために誰でも遊べる形で出すもの、Playtest は改善のために参加の範囲を決めて配るもの、と考えると使い分けやすくなります（体験版は「体験版（デモ）の作り方」）。

情報漏れに注意する

ひとことで：テスト版は外に出るものと考え、出て困るものを入れず、出たときに経路がわかるようにします。

テスト版の画面や動画は、思ったより簡単に広まります。特に Steam Playtest には秘密保持の契約が無いので、遊んだ人が画面を公開しても止められない前提で準備します。

入れない：未発表の内容、物語の核心、他社との契約に関わる素材は、テスト版から外すか隠す
伝える：SNS に載せてよい範囲や、配信してよいかを、配る前にはっきり書く
約束を書面にする：配る相手が限られる非公開のテストでは、秘密保持の約束を文書で交わす
印を付ける：画面の隅にテスターの番号を小さく出すなど、出回った版の出どころがわかるようにする
期限を付ける：決めた日付を過ぎたら起動しないビルドにする
消す：デバッグ用のメニューや開発用の表示を外す

本節は一般的な注意で、法的な助言ではありません。秘密保持の契約や記録の扱いの最終確認は、公式の規約や専門家にお願いします。

夕宮たいだ

ぁぅ……テスト版のスクショって、ほんとにすぐ広まっちゃうんだよねぇ。出て困るものは、最初から入れないのがいちばん安全だよぉ。

結果の読み方と直す優先順位

ひとことで：全員の意見には従わず、「何が起きたか（症状）」を集めて、「どう直すか（処方）」は作り手が決めます。

テスターの声には、症状と処方が混ざっています。「3面が難しい」は症状、「敵を減らした方がいい」は処方です。作家のニール・ゲイマン氏は、英ガーディアン紙（2010年2月）に寄せた小説を書く心得で、「どこかがおかしい」という指摘はほぼ正しいが、「どこがどう悪く、どう直すべきか」という指摘はほぼ間違っている、という趣旨を書いています。ゲームでも、症状は信じ、処方は参考にとどめます。3面が難しい原因は、敵の数ではなく、回復の手段に気づいていないことかもしれないからです。

集計は、問題ごとに「何人が・どこで・どれくらい困ったか」を表にします。

問題（症状）	人数	重さ	判断
ダッシュに気づかず、1-2 の崖で詰まる	5人中4人	進めなくなる	直す（1-1 にダッシュを必ず使う地形を置く）
ショップで装備の違いがわからない	5人中3人	迷うが進める	直す（比較の表示を足す）
2面の音楽が単調	5人中1人	好みの差	様子を見る
もっと難しくしてほしい	5人中1人（上級者）	狙いと違う	難易度の選択で受け止める

優先順位は、重さ（やめてしまう・進めない＞迷うが進める＞好みの違い）、人数、狙いとの関係（ターゲットの人に起きているか）の3つで決めます。「難しい」こと自体が魅力のゲームなら、難しいという声だけで易しくはしません。誰の体験を優先するかは、企画の段階で決めたターゲットに戻って判断します。

直したら、同じ場所を別の初見の人に遊んでもらい、本当に解消したかを確かめます。2002年に Microsoft のゲーム開発の現場から報告された RITE（Rapid Iterative Testing and Evaluation）は、問題と直し方がはっきりした時点で、1人目の後でもすぐ直して次の人で確かめる方法です（『Age of Empires II』での事例。MeasuringU の解説）。個人や少人数でも、回と回の間に直す時間を挟めば同じ考え方を取り入れられます。

1回のプレイテストを終えてよい目安は、次の3つがそろったときです。

その回の問いに、答え（はい・いいえ・まだわからない）が出た
重い問題（進めない・やめてしまう）の一覧ができ、直すか直さないかが決まった
次の回に確かめることが決まった

AIゲーム開発でのプレイテスト

ひとことで：AI に遊ばせる「仮想プレイテスト」は人のテストの前段に置き、人のテストを面白さと初見の体験に集中させます。

仮想プレイテストは人のテストの代わりではない

画面を見てマウスやキーボードを操作できる AI エージェントなら、実際のビルドを遊ばせられます。疲れず、何度でも、決めた視点で隅々まで触ってくれるので、「進めない」「記録されない」「文字が読みにくい」といった問題を、人に見せる前に洗い出せます。

一方で、AI は人の代わりにはなりません。多くのゲームの作法を知識として持っているので、本当の意味での初見にはなりにくく、面白いか、怖いか、悔しいかといった感情も、AI の感想からはわかりません。そこで、AI の仮想プレイテストで粗い問題を先に減らし、人のプレイテストでは面白さと初めて遊ぶ人の体験を見る、という2段にします。人に頼める回数は限られるので、その貴重な回を「ボタンが反応しない」で使い切らないための前段です。

順番としては、人のテストの前に AI の仮想プレイテストを回し、指摘を直したビルドを人に渡します。AI を使うと、テストの回数を増やすこと自体は安くなります。その分、重心は「どの結果を信じ、何を直すか」を決める側へ移ります。

AI の仮想プレイテストで進めない所や読みにくい文字などを先に洗い出し、コードで裏取りして直してから、人のプレイテストで面白さと初めて遊ぶ人の体験を見る — 図3：AI で粗い問題を減らしてから、人のテストで面白さと初めての体験を見る

任せやすいこと

実際のビルドを遊ばせて、問題の一覧を作らせる：想定するプレイヤーを何人か決め、それぞれの視点で遊ばせる
アンケートの自由記述を分類・要約させる：同じ意味の回答をまとめて件数を数える。元の文は消さずに残す
観察メモや録画の書き起こしから、問題の一覧を作らせる：場所・症状・人数・重さの列にそろえる。メモの時刻をもとに、録画から該当する場面を切り出させると、直す人が見返しやすくなる
指摘をコードで裏取りさせる：本当に起きるか、原因はどこかを確かめさせる
募集文・アンケート・同意の文面の下書き：質問が誘導になっていないかも点検させる

人が決めること

誰の体験を優先するか（ターゲット）と、今回の問い
AI の指摘のうち、どれを直し、どれを人のテストで確かめ直すか
直すか直さないか、どう直すか（処方）
面白いか、狙った感情になっているか
人のプレイテストをいつ、誰に頼むか

落とし穴

AI の感想を「プレイヤーの声」と取り違える：AI の指摘は人数に数えません。「5人中4人が詰まった」と「AI が詰まった」は別の情報です
AI の指摘をうのみにする：誤った指摘もありうる前提で、コードと実機で裏を取ってから直します
AI に知識を与えすぎる：仕様書やソースコードを読ませてから遊ばせると、初見の視点ではなくなります。配布物だけを渡し、隔離した環境で遊ばせます（隔離の考え方は「Codexの権限と安全設定」）
個人情報を外部に渡す：アンケートを AI のサービスに渡す前に、名前や連絡先を消します

筆者の実例

筆者の「つみこめ！イカサマ魔法麻雀」では、Codex に実際のビルドをマウスで遊ばせました。隔離した環境で、3人の仮想プレイヤーの視点を決めて遊ばせたところ、指摘は6件でした（練習など別の遊び方を始めると中断していた対局のデータが上書きされる、チュートリアルを終えても修了が記録されない、文字のコントラストが足りない、など）。加えて、「実行時エラーがテストの失敗に数えられていない」という、テストの仕組みの穴も見つかりました。

Claude Code が全件をコードで裏取りしたところ、誤報は0件でした。直す順番は、まずテストの穴（以後の修正を正しく確かめるため）、次にデータが消える中断の上書き、そのあと記録・表示・操作の問題、と優先順に進めました。

もう1つは、開発中の将棋ゲームの CPU の強さです。強さの物差しには市販の将棋アプリを使い、筆者が市販アプリと自作の CPU を対局させて段級を測り、CPU が1手ごとに読む局面の数を調整しました（4,000局面では市販アプリの6級に負けたので引き上げ）。一方で、筆者自身が遊んだときの「自分は弱いのに毎回勝てる」という感想を受けて、弱い段を作り直しています。物差しの数字と、人が遊んだ感想の両方を使った例です。

依頼文の例

仮想プレイテストは、次のように頼みます。書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

Goal: 配布用ビルドを初めて遊ぶ人の視点で遊び、迷う所・進めない所・読みにくい所を一覧にする
Context: 使うのは build/playtest/ の実行ファイルだけ。仕様書とソースコードは見ない。
  想定プレイヤーは3人（ジャンル未経験の人、経験者、キーボードだけで遊ぶ人）
Done when: 指摘ごとに「場所・したこと・起きたこと・画面の画像」がそろった表がある。
  事実と推測を分け、推測には「推測」と書いてある
Constraints: セーブは一時フォルダに作り、本物のセーブデータには触れない

夕宮たいだ

AI の感想と、人の感想……ごっちゃにしやすいんだよねぇ。AI は人数に入れない、って覚えておくと迷わないよぉ。

よくある失敗と対処

ひとことで：多くは「教えてしまう」「聞き方が偏る」「意見を全部入れる」の3つから起きます。

失敗	起きること	対処
作り手が横で説明する	わかりにくい所が見えない	声をかける条件を決め、説明したくなった所をメモする
同じ人に何度も初見のテストを頼む	初めての反応が取れない	初見が要るテストは新しい人に頼む
誘導する質問をする	聞きたい答えしか返らない	中立な聞き方にし、別の人に読んでもらう
意見をそのまま全部入れる	狙いがぼやけ、作業が膨らむ	症状と処方を分け、ターゲットに照らして決める
テスト版が出回る	未発表の内容が広まる	入れない・印を付ける・約束を書面にする
直した後に確かめない	直したつもりで、別の所で詰まる	次の回で同じ場所を新しい人に見てもらう