game-playtest

AlterLab GameForge -- 構造化プレイテスト分析

プレイテストとは、プレイヤーに楽しかったかを尋ねることではありません。プレイヤーの行動を規律正しく観察し、デザインのどこがうまく機能し、どこに問題があるかを特定することです。プレイヤーの口は嘘をつきますが、手は嘘をつきません。任天堂は数十年にわたり、このことを理解してきました。宮本茂氏は有名な話ですが、プレイヤーを黙って観察し、お世辞よりもプレイヤーの戸惑いを信頼しています。LarianはBG3の早期アクセス期間中に数千回に及ぶコミュニティプレイテストを実施し、主要なシステム変更はすべて、フォーラムの投票ではなく行動データに基づいていました。このワークフローは、生のプレイテストセッションを実行可能なデザイン上の知見に変える、厳密な行動観察の枠組みを提供します。

目的と実施のきっかけ

次の場合にこのワークフローを使用してください。

• ビルドを外部の人に見せる準備が整い、単なる感想ではなく、体系的なフィードバックが必要な場合
• 「ゲームは良いですか？」ではなく、「プレイヤーはクラフトシステムを理解していますか？」といった具体的なデザイン上の疑問に答える必要がある場合
• オンボーディングの流れを検証する必要がある場合――新規プレイヤーはチュートリアルなしでコアメカニクスを習得できるでしょうか？
• 難易度曲線を評価する場合――プレイヤーはフローチャンネルに入っているでしょうか、それとも退屈とフラストレーションの間を行き来しているでしょうか？
• 新機能を統合したものの、ゲーム体験全体への影響がわからない場合
• リリース前の仕上げにあたり、どの粗削りな部分がプレイヤーにとって最も重要かを示すデータが必要な場合
• 参考ゲームと横並びで比較する競合分析が必要な場合

次の場合はこのワークフローを使用しないでください。

• 生のメカニクスを単体でテストしたい場合（代わりに game-prototype を使用してください）
• ビルドの不具合が多すぎて、テスターの大半の時間がバグへの対処に費やされてしまう場合（まず重大なバグを修正してから、プレイテストを実施してください）
• マーケティング用のコメントや好意的な推薦文が欲しい場合（それはPRであり、プレイテストではありません）

重要なルール

1. テスターを招く前に質問を決めてください。 すべてのプレイテストでは、具体的な質問に答えます。「楽しいですか？」は質問ではなく、祈りです。「プレイヤーは最初のダンジョンを、2回を超えて死亡せずにクリアできますか？」は質問です。Celesteのプレイテストでは、「プレイヤーは最初の3画面以内にダッシュのメカニクスを習得できるか？」と尋ねました――具体的で、観察可能で、実行につながる質問です。
2. 進行役はプレイしません。 あなたは観察し、メモを取ります。助けたり、説明したり、提案したり、反応したりしてはいけません。ポーカーフェイスは科学的な測定器です。
3. 1回のセッションにつき、テスターは最低5人必要です。 5人未満では、データではなく逸話を集めることになります。少人数のサンプルでは、個々のプレイヤーの癖が結果を左右します。テスターが5人以上になると、パターンが現れます。
4. 開発チームでテストしてはいけません。 開発チームは知りすぎています。筋肉の記憶、メンタルモデル、コンテキストがあるため、新規プレイヤーとしてゲームを体験できません。任天堂の社内プレイテストチームは、各セッションに先入観なく臨めるよう、開発に関する議論から意図的に遠ざけられています。開発者は、すでに自分たちが慣れてしまったオンボーディング上の問題に気づけません。
5. 言語データより行動データを重視してください。 プレイヤーが「操作感は問題ない」と言っても、10分間のセッションで間違ったボタンを11回押しているのを観察したなら、行動データを優先します。必ずです。LarianはBG3のプレイテスターの行動を入力レベルで追跡しました。プレイヤーが選択する前にどの会話の選択肢にカーソルを合わせたかを把握し、そのためらいのデータをもとにAct 1を書き直しました。
6. 観察と解釈を分けてください。 セッション中は、何が起きたかを記録します。セッション後に、それが何を意味するかを解釈します。リアルタイムで両者を混ぜると、確証バイアスが生じます。
7. プレイヤーのエンゲージメントや感情的な反応を分析する際は、フロー理論とMDAフレームワークについて docs/game-design-theory.md を参照してください。

ワークフロー

ステップ1：プレイテストの事前準備

テストの目的を決めます。このプレイテストで答える具体的な質問を3～5個書き出します。各質問は、次の条件を満たす必要があります。

• 観察可能である（尋ねるだけでなく、観察して答えを判断できる）
• 実行につながる（答えがデザイン上の決定に直接反映される）
• 範囲が明確である（1回のプレイセッション内で答えられる） 良いテスト質問：
• 「プレイヤーは最初の2回の遭遇の中で、回避ロールの仕組みを自然に発見しますか？」
• 「進行曲線のどの時点で、プレイヤーは自発的に探索するのをやめ、目標へ急ぐようになりますか？」
• 「Act 2のリソース不足は、緊張感を生みますか、それとも苛立ちを生みますか？」

観察シートを準備します。各テスト質問について、以下を定義してください。

• 成功を示す具体的なプレイヤーの行動（肯定的な兆候）
• 失敗を示す具体的なプレイヤーの行動（否定的な兆候）
• 特に注意深く観察すべきゲームセッション内のタイミング（重要な観察時間帯）

プレイヤーごとの記録フォームを作成します：

Player ID: ___
Session Date: ___
Session Duration: ___
Test Build Version: ___

Timestamped Observations:
[MM:SS] [Observation] [Category: Action/Hesitation/Confusion/Emotion/Verbal]

Post-Session Survey Responses:
Q1: ___
Q2: ___
Q3: ___

録画環境をセットアップします：

• 音声付きの画面キャプチャ（必須 -- 録画が捉えるリアルタイムでは見逃すことがあります）
• 利用可能であればフェイスカメラ（顔の微細な表情から、プレイヤーが言葉にしないエンゲージメント、混乱、苛立ちが分かります）
• エンジンが対応していれば入力ログ（プレイヤーがクリックした場所、死亡した場所、時間を費やした場所のヒートマップ）
• プレイヤーの表情とゲーム内イベントを照合できるよう、録画にタイムスタンプを付け、同期させます

テスト環境を準備します：

• すべてのテスターでハードウェア構成を統一します（フレームレートや入力デバイスの違いは結果を汚染します）
• 開発用オーバーレイ、デバッグメニュー、コンソールへのアクセスを取り除きます
• 開発者用のショートカットやゴッドモードの切り替えを無効にします
• すべてのテスターが同じ地点から開始できるよう、クリーンなセーブデータを用意します
• 最初のテスターが到着する前に、リハーサルを行って録画環境をテストします

進行役に説明します（補助者がいる場合）：

• 役割は観察と記録だけです。手助けはしません。説明もしません。反応もしません。
• テスターに「何をすればいいですか？」と聞かれた場合、正しい返答は「何をすべきだと思いますか？」です。
• テスターが重要でない経路で90秒以上完全に行き詰まった場合は、中立的なヒントを一度だけ伝えてもかまいません（「光っているオブジェクトを調べてみましたか？」）。これを重要な発見として記録します。
• 進行役はプレイヤーのすぐ隣に座らないでください。見られているという周辺意識によって行動が変わります。後方の斜め位置に座ります。

ステップ2：プレイテスト中 -- 黙って観察するプロトコル

ここでは規律が最も重要です。この段階では、ゲームに対するあなた個人の感情は関係ありません。

リアルタイムの観察カテゴリー：

行動 -- プレイヤーは何をしていますか？

• その瞬間ごとの判断を記録します。「プレイヤーがボスと戦った」だけでなく、「プレイヤーは攻撃する前に15秒間ボスの周囲を回った。弱点を探していたか、覚悟を決めていたと考えられる」のように記録します。
• 移動パターンを追跡します。プレイヤーは意図した場所へ行きますか？それとも、別の場所へ向かいますか？意図しない探索経路からは、環境が実際に何を伝えているか、あなたが伝えていると思っている内容との違いが明らかになります。
• 入力パターンを記録します。ボタン連打（パニックまたは退屈）、意図的な入力（戦略的な取り組み）、失敗した入力の繰り返し（操作方法の混乱）。

ためらい -- プレイヤーはどこで立ち止まりますか？

• ドアの前で立ち止まるのは、向こうに何があるのか予想していることを意味します（良い兆候です -- 緊張感を作り出せています）。
• メニューで立ち止まるのは、選択肢を理解できていないことを意味します（悪い兆候です -- UIが分かりにくくなっています）。
• 戦闘中に立ち止まるのは、戦略を練っている（良い兆候）か、圧倒されている（悪い兆候）かのどちらかです。顔の表情とその後の行動を見れば、どちらかを判別できます。

混乱 -- プレイヤーはどこで誤解していますか？

• 「期待との食い違い」、つまりプレイヤーが明らかにある結果を期待していたのに、別の結果になった瞬間を追跡します。これは、あらゆるプレイテストで最も価値の高い発見です。
• プレイヤーがメカニクスを誤って使いながら、正しく使えていると思っている場面を記録します。これは、フィードバックの仕組みが状態を明確に伝えられていないことを示します。
• プレイヤーが同じツールチップや看板を何度も読む様子に注意します。情報が不明確だったか、自分の理解に確信が持てていないことを意味します。 感情 -- プレイヤーはどのように感じているか？
• 喜びの指標：身を乗り出す、目を見開く、思わず笑う、「いいね」や「すごい」といった声を上げる、近くにいる人に画面を見せる
• フラストレーションの指標：ため息をつく、背もたれに寄りかかる、腕を組む、クリックが強くなる、ぶつぶつ言う、目をくるりと回す
• 没入の指標：時間を忘れる、スマートフォンの通知を無視する、終了時に「まだプレイしてもいい？」と聞く
• 集中の途切れを示す指標：スマートフォンを確認する、部屋を見回す、注意力が落ちた状態でプレイする、「あとどれくらい？」と聞く
• フロー状態の指標：静かに集中する、リズミカルな入力パターン、終了時刻を告げられて驚く、具体的な場面を思い出しにくい（「没頭していた」）。Hadesのプレイテストでは、プレイヤーが時計を確認せずに30分以上過ごしたという報告があります。これはフロー状態を確認するための理想的な基準です。

感情の反応をゲーム内の具体的な場面に対応付けます。これにより、プレイセッションの感情的なヒートマップが作成されます。盛り上がりと落ち込みはどこにあるでしょうか？設計ドキュメントで意図した感情の流れと比較してください。

言葉による観察（思考発話プロトコルを使用する場合）：

• プレイヤーのリアルタイムの発話を、編集や訂正をせずに記録します。
• プレイヤーの発言と行動が食い違う場面に印を付けます。こうした場面は非常に重要です。「簡単だね」と言った直後に3回続けて死亡した場合、プレイヤーが感じているスキルと実際のスキルに隔たりがあることが分かります。

ステップ3：セッション後の振り返り

短時間で済ませます。最長でも5～7分です。体験が新鮮なうちのプレイヤーの注意は最も貴重ですが、プレイセッションの後はすぐに疲労が生じます。

振り返りで中心となる質問（この順番で尋ねます）：

1. 「このゲームはどんな内容でしたか？」 -- 中心となるファンタジーとテーマが明確に伝わったかを確認します
2. 「ほとんどの時間、何をしようとしていましたか？」 -- プレイヤーが主な目的とコアループを理解していたかが分かります
3. 「特に良かったと思う場面はありましたか？」 -- プレイヤーの視点から喜びのピークを特定します（観察結果と照らし合わせます）
4. 「分かりにくかった、またはイライラした場面はありましたか？」 -- プレイヤーの視点から摩擦を特定します
5. 「何か1つ変えられるとしたら、何を変えますか？」 -- プレイヤーが最も気にしている問題が分かります

追加の掘り下げ質問（時間に余裕があり、回答がテストの質問に役立つ場合のみ）：

• 「その時点でどのような選択肢があるのか、理解できていると感じましたか？」 -- 意思決定の明確さを確認します
• 「難易度はちょうどよかったですか？簡単すぎましたか、それとも難しすぎましたか？」 -- 主観的な難易度を評価します（行動データと照らし合わせます）
• 「ゲームでできなかったことで、やりたいと思ったことはありましたか？」 -- アフォーダンスの不足が分かります

尋ねてはいけない質問：

• 「気に入りましたか？」 -- 役に立ちません。社会的なプレッシャーにより、肯定的な答えが返ってきます。
• 「購入したいと思いますか？」 -- この段階では関係がなく、プレイヤーを評価する側の意識にさせるため、率直なフィードバックが抑えられます。
• 誘導的な質問：「洞窟の照明が変化したことに気付きましたか？」 -- 知ってほしい観察結果をこちらから伝えてしまいます。

ステップ4：プレイテスト後の分析

最後のセッションから少なくとも2時間待ってから分析します。すぐに分析すると、直近性バイアスの影響を受け、最後のテスターの体験が思考を支配してしまいます。

プレイヤー間のパターンの特定：

• 観察結果をマトリックスにまとめます。行にはゲーム内の場面や機能を、列にはプレイヤーを配置します。
• 3人以上のプレイヤーが同じ行動を示した場面を強調します。これらは個人特有の振る舞いではなく、システム上の問題を示しています。
• 分岐点を特定します。プレイヤーが異なる行動グループに分かれる場面です（解消するか、受け入れるかを検討すべき設計上の分岐が明らかになります）。

調査結果の分類： すべての調査結果を深刻度別に分類します：

重大度	定義	必要な対応
Critical	コア体験を損ないます。プレイヤーが先に進めない、または意図した感情が逆転します（達成感ではなくフラストレーションを感じるなど）。	次のプレイテストまでに必ず修正します。
Major	体験を大きく損ないます。プレイヤーは先に進めますが、体験の質が明らかに低下します。	現在のマイルストーン内に修正します。
Minor	改善の余地があります。プレイヤーは気づきますが、大きな影響は受けません。	可能なときに修正するか、仕上げの作業にまとめます。
Observation	問題を示すものではありませんが、今後の設計判断に役立つ可能性のある興味深い行動上の気づきです。	参考情報として記録します。対応は不要です。

推奨事項の作成： Critical と Major の各所見について、具体的で実行可能な推奨事項を作成します。

• 何を変更するか（具体的にします。「難易度を下げる」ではなく「部屋 3 の敵の数を 5 体から 3 体に減らす」）
• なぜ効果があるのか（推奨事項を観察された行動と結び付けます）
• 期待される効果（修正が機能した場合、次のプレイテストで何が変わるべきか）
• 起こり得る副作用（この修正によって、ほかの箇所に新たな問題が生じないか）

長期的な比較： 過去のプレイテストデータがある場合は、各イテレーションの結果を比較します。

• 前回のプレイテストの所見のうち、どれに対応し、修正は効果があったか？
• 修正を試みたにもかかわらず、どの問題が残ったか（表面的な問題ではなく、構造的な問題である可能性があります）？
• 全体的な傾向は改善しているか？ 問題を新たに生み出す以上に、修正できているか？

ステップ 5：レポートの作成と配布

分析内容を標準のプレイテストレポート形式（下記の出力形式を参照）にまとめます。冒頭に 2 文のエグゼクティブサマリーを付けて、チーム全員に配布します。リードデザイナーとプロデューサーが 10 ページすべてを読まなくても要点を把握できるようにします。

出力形式

## Playtest Report: [Build Name / Version]
## Date: [YYYY-MM-DD]
## Facilitator: [Name]
## Testers: [Count] ([demographic notes if relevant])
## Session Duration: [Average across testers]

### Executive Summary
[2 sentences: What was the most important finding? What is the recommended priority action?]

### Test Objectives
1. [Question 1] -- [Answered / Partially Answered / Unanswered]
2. [Question 2] -- [Answered / Partially Answered / Unanswered]
3. [Question 3] -- [Answered / Partially Answered / Unanswered]

### Findings Matrix

| ID | Finding | Severity | Players Affected | Game Moment | Recommendation |
|----|---------|----------|-----------------|-------------|----------------|
| F1 | [desc]  | Critical | 4/5             | [moment]    | [action]       |
| F2 | [desc]  | Major    | 3/5             | [moment]    | [action]       |
| F3 | [desc]  | Minor    | 2/5             | [moment]    | [action]       |

### Emotional Response Map
[Timeline showing emotional peaks and valleys across the session, with game moments annotated]

Opening -> [emotion] -> [event] -> [emotion] -> [event] -> [emotion] -> Close

### Onboarding Assessment
- Core mechanic understood without explanation: [X/5 players]
- Time to first successful use of primary mechanic: [average time]
- Tutorial/hint engagement: [how many players read vs. skipped]
- First death/failure cause: [most common reason]

### Flow Analysis (per docs/game-design-theory.md)
- Estimated flow channel adherence: [percentage of session time in flow]
- Anxiety spikes (challenge > skill): [moments]
- Boredom dips (skill > challenge): [moments]
- Flow entry points: [moments where players appeared to enter flow state]

### Player Behavior Patterns
- **Navigation**: [Where did players go? Where did they NOT go? Where did they get lost?]
- **Combat/Core Loop**: [How did players engage with the primary mechanic?]
- **Exploration**: [What did players investigate voluntarily?]
- **Resource Management**: [How did players handle scarcity/abundance?]

### Comparison to Previous Playtest
| Previous Finding | Status | Notes |
|-----------------|--------|-------|
| [Finding from last time] | Fixed / Improved / Unchanged / Regressed | [details] |

### Prioritized Action Items
1. [Highest priority action] -- addresses findings [F1, F3]
2. [Second priority action] -- addresses finding [F2]
3. [Third priority action] -- addresses finding [F4]

### Raw Observation Notes
[Attached or linked per-player observation sheets]

### Recording Index
| Player | Recording File | Key Timestamps |
|--------|---------------|----------------|
| P1     | [filename]    | [MM:SS notable moments] |
| P2     | [filename]    | [MM:SS notable moments] |

品質基準

• 質問の具体性：すべてのテスト目標が観察可能で、実行可能であり、範囲が明確です。計画段階で「楽しいか？」のような曖昧な質問はすべて取り除かれています。
• 観察の厳密さ：所見の少なくとも 80% が、発言データ（プレイヤーが言ったこと）ではなく行動データ（プレイヤーが実際にしたこと）に基づいています。発言データは補足的な証拠であり、主要な証拠ではありません。
• パターンの妥当性：体系的な問題（Major または Critical）に分類された所見は、5 人中少なくとも 3 人のテスターからの観察によって裏付けられています。1 人のプレイヤーのみの観察は Minor または Observation に分類します。
• 推奨事項の具体性：Critical と Major のすべての所見に、具体的で実装可能な推奨事項があります。「改善する」ではなく、「部屋 3 の敵の数を 5 体から 3 体に減らし、遭遇の前に回復アイテムを追加する」とします。
• 長期的な追跡：過去のプレイテストがある場合、レポートには少なくとも 1 回分の比較が含まれ、以前の所見に対応したか、修正が効果的だったかを追跡しています。
• 感情のマッピング：レポートには、セッションのタイムライン上で喜びやフラストレーションが生じた箇所を示す感情反応マップが含まれ、具体的なゲーム内イベントと照合されています。
• ファシリテーターの中立性：ファシリテーターが介入（説明、支援、ヒント）した事例をレポートに記録し、それらの瞬間をデータが影響を受けた可能性のある箇所として示しています。

AI プレイテストエージェント

プレイヤー体験を評価するうえで、人間によるプレイテストが今なお最も信頼できる方法です。一方、AI プレイテストエージェントを活用すれば、人間のテスターでは実施が現実的でないカバレッジテスト、回帰テスト、夜間のストレステストによって、人間によるテストセッションを補完できます。

nunu.ai のパターン： テスト目標を平易な英語で定義します（例：「死なずにチュートリアルを完了する」「レベル3でボスを見つけて倒す」「ロックされたドアを突破して、想定外の順序で進行しようとする」）。AI ボットを夜間に実行し、セッションの録画と行動ログを作成します。以下の用途に活用できます。

• バランス調整後の回帰テスト（このパッチによって、チュートリアルの完了率が下がっていないか？）
• カバレッジテスト（レベルデザイン内のどの経路でもソフトロックが発生する可能性はないか？）
• ストレステスト（マルチプレイヤー環境で100体のエージェントが同時にプレイすると、何が起きるか？）

modl.ai のパターン： 特定の目標を与えずにゲームを探索し、到達可能な状態をマッピングして、ボットが行き詰まる場所を特定する自律型テストボットです。以下の用途に活用できます。

• 経路探索の検証（ナビゲーションメッシュに穴はないか？）
• ステートマシンの整合性（ボットが回復不能な状態に陥る可能性はないか？）
• コンテンツのカバレッジ（レベルのジオメトリのうち、実際に到達可能な割合はどれくらいか？）

AI テストで代替できないもの：

• 感情的な反応の測定（喜び、苛立ち、没入感）
• 美的評価（気持ちよく感じられるか？）
• マルチプレイヤーにおける社会的な力学（AI は人間の社会的行動を再現できません）
• 第一印象のテスト（AI には、裏切られるような期待がありません）

カバレッジと回帰には AI テストを使いましょう。体験と感情の評価には人間によるテストを使いましょう。どちらか一方をもう一方の代わりに使ってはいけません。

構造化セッション計画テンプレート

プレイテストセッションを始める前に、この計画テンプレートに記入して、焦点を明確にし、再現性を確保しましょう。

SESSION PLAN
Date: [YYYY-MM-DD]
Build Version: [version string]
Session Type: [First Impression / Targeted Feature / Regression / Full Playthrough]
Duration: [planned session length per tester]
Tester Count: [number of testers scheduled]

Test Questions (max 5):
1. [Specific, observable, actionable question]
2. [Specific, observable, actionable question]
3. [Specific, observable, actionable question]

Focus Areas:
- [Game section or feature under scrutiny]
- [Specific interaction or flow to observe]

Recording Setup:
- Screen capture: [tool and settings]
- Face camera: [available / not available]
- Input logging: [enabled / not available]

Facilitator Notes:
- [Any special instructions for this session]
- [Known issues to ignore during testing]

4つの質問でプレイテストの焦点を定める

時間が限られている場合や、テスターから迅速に情報を得たい場合は、振り返りを次の4つの質問に絞ります。テスターの疲労を最小限に抑えつつ、価値の高い洞察が得られる順に並んでいます。

1. 「何が分かりにくかったですか？」 — オンボーディングの不備、分かりにくいゲームの仕組み、情報伝達の不足を特定します。混乱は、再設計が必要な具体的な場面を直接示すため、最も対処しやすい発見事項です。
2. 「いつ退屈しましたか？」 — ペース配分の停滞、報酬の不足、プレイヤーを引き込めないコンテンツを特定します。退屈しているプレイヤーは礼儀からプレイを続けることが多いため、観察だけでは見つけにくいものです。
3. 「いつやめたいと思いましたか？」 — 苛立ちが高まる場面、疲労の限界、ゲームの自然なセッション時間を特定します。「ボス戦でやめたいと思った」と「インベントリ管理中にやめたいと思った」の違いから、どのシステムがプレイの妨げになっているかが分かります。
4. 「友人に見せたいと思うのはどこですか？」 — 喜びが最も高まる場面と、ゲームが自然に訴求できる魅力を特定します。テスターが友人に見せたいと思う場面は、トレーラーで最初に見せるべきであり、ストアページでも強調すべきです。

セッション時間が限られている場合は、この4つの質問を、より長い振り返りの代わりに使います。ただし、セッション中の行動を十分に観察することの代わりにはなりません。

リモートプレイテストの準備

ほとんどのインディー開発者は、対面セッションを継続的に実施できません。リモートプレイテストが現実的な標準となり、いくつか特有の要件があります。

録画環境：

• テスターに OBS をインストールしてもらうか、OS に組み込まれた録画機能（Windows の Xbox Game Bar、macOS の QuickTime）を使ってもらいます。事前に文書でセットアップ手順を提供し、セッション中に録画ソフトのトラブルシューティングに時間を使わないようにします。
• テスターの同意が得られたら、正面向きのウェブカメラ映像を依頼します。ほとんどの人が同意します。低画質のウェブカメラでも、最も価値の高い調査結果につながる感情的な反応を捉えられます。
• 音声には Discord、Zoom、Google Meet を使います。観察中は自分のマイクをミュートにします。自分の呼吸音が聞こえると、テスターの行動が変わります。
• ビルドの配布には、非公開の itch.io リンク、Steam の早期アクセスキー、または直接ダウンロードを使います。実行ファイルをメールで送るのは絶対に避けてください。セキュリティソフトに検知され、最初の印象を損ないます。

セッションの進行管理：

• 90 分を確保します。セットアップに 10 分、プレイに 60 分、振り返りに 20 分です。予定時間を超えて進めると、テスターは振り返りの質を自然と切り詰めます。
• 振り返りの内容をリアルタイムで書き起こさずに済むよう、共有ドキュメントやフォームを使って記録します。標準化された質問には Google Forms が、自由回答には共有 Google Doc が適しています。
• 非同期のリモートテストでは、構成された観察用プロンプトを用意します。「終了後、次のことを書き留めてください。驚いた瞬間、混乱した瞬間、特に夢中になった瞬間をそれぞれ一つずつです。考えすぎないでください。熟考した反応よりも、その場の率直な反応のほうが価値があります。」

リモートテストでは把握できないこと：

• ウェブカメラがない場合の、自然な顔の微細な表情（一部のテスターはウェブカメラを使わないことを選びます）
• 物理的な環境の状況（気を散らすもの、ハードウェアの品質、音響環境）
• テスターがスクリーンショットやトレーラーを見たことがある場合の、真の初回プレイ時の行動

リモートテストは、具体的な障害箇所の特定を目的とする開発中盤のプレイテストに適しています。コアとなるオンボーディングの第一印象をテストする場合は、実施可能であれば進行役が同席する対面セッションが望ましいです。

証拠の基準を見極める

一人のテスターが強い反応を示したからといって、調査結果を「重大」と呼ぶのは避けてください。分類する前に、次の証拠の基準を適用します。

重大度	最低限必要な証拠
重大	5 人中 4 人以上のテスターにその行動が見られた、または 1 人のテスターにセッションを終了させる完全な失敗（クラッシュ、ソフトロック、進行不能）が発生した
大	5 人中 3 人以上のテスターにその行動が見られ、行動による裏付けがある（口頭での報告だけではない）
小	5 人中 2 人が口頭で指摘した、または 1 人のテスターに行動上の証拠が見られた
観察事項	将来の参考のために記録する価値がある、より小さな兆候

証拠が曖昧な場合（例：2 人のテスターにその行動が見られ、3 人には見られなかった場合）は、報告書に明確にその内訳を記載します。5 人中 2 人という兆候は、すぐに対応すべき調査結果ではなく、次のプレイテストで注視すべき調査結果です。次のセッションでも再び見られた場合は、「大」に引き上げます。

使用例

1. 「最初のプレイ可能なビルドが完成しました。体系的なプレイテストセッションの計画を手伝ってください。どのような質問をすればよいですか。また、観察の準備はどのようにすればよいですか？」
2. 「先週プレイテストを実施し、6人のプレイヤーについてメモを取りました。生の観察記録を以下に示します。データの分析と、優先順位を付けた調査結果レポートの作成を手伝ってください。」
3. 「レベル3の同じ場所でプレイヤーが何度も倒れます。難易度が急上昇しているのだと思いますが、確信はありません。問題を診断するための対象を絞ったプレイテストの設計を手伝ってください。」
4. 「先月のプレイテストのフィードバックをもとに、操作方法を変更しました。特定した問題が実際に解決したかを確認するための、フォローアップテストの設計を手伝ってください。」
5. 「私たちのゲームには20分間のオンボーディングがあり、プレイヤーがコアループにたどり着く前に離脱しているのではないかと考えています。追跡する具体的な指標を設定したうえで、初回ユーザー体験のプレイテストを準備するのを手伝ってください。」
6. 「私は個人開発者で、対面セッションを実施できません。Discord と OBS を使って、アクションRPGのリモートプレイテストを準備するのを手伝ってください。」
7. 「過去2か月間に行った3回の別々のセッションから、プレイテストレポートが6件あります。複数のセッションで継続して見られた調査結果と、一度だけの観察を特定するのを手伝ってください。」