game-design-review

ゲームデザインレビュー

ルールや表現がプレイヤーの判断や体験にどのような影響を与えるかをたどり、デザインをレビューします。このレビューは、判断を支援するためのものであり、万能のチェックリストでも、プレイテストの代わりでもありません。

責任範囲

• すでにデザイン対象や判断事項があり、検討が必要な場合にこのスキルを使用してください。
• このスキルは単独で機能します。他のスキル、ワークフロー、リポジトリの構成、ドキュメント一式、ゲームエンジンが存在することを前提としないでください。
• レビューではなく新たな正式なデザインドキュメントが必要な場合は、その作成に必要な、明確化された方向性、制約、未解決の質問、検証基準を提示してください。
• デザイン上の推奨事項を、そのままコード構造、エンジン API、実装タスクに置き換えないでください。

レビューモード

すべてのレビューは、次の基本構成を共有します。

1. レビュー対象を明示します。 ゲーム全体、1つのループ、1つのメカニクス、レベル、インターフェースのフロー、物語上の場面、ソーシャル機能、生産上の選択などが対象になります。
2. 検討すべき判断事項を示します。 選択肢または検証可能な質問を提示します。どちらもない場合は、最も重要な未解決の前提を示します。
3. 根拠の基準線を作ります。 対象者、ルール、制約、プロトタイプの挙動、プレイテストでの観察をまとめ、繰り返し見られた傾向と逸話を区別します。重要な記述には、それぞれ confirmed、assumed、unknown のいずれかを付記します。
4. レビューを締めくくります。 優先順位を付けた所見、最小限で有効な介入、検証実験を提示します。

各モードでは、この前後の検討をどのように進めるかが異なります。該当する最も限定的なモードを選んでください。迷った場合は、包括的レビューを使用してください。

包括的レビュー（デフォルト）

方向性が決まり、検討対象となる正式な資料（ドキュメント、プロトタイプ、テレメトリー、プレイテストの記録など）があり、弱点、リスク、矛盾を網羅的にレビューすることが目的の場合に使用します。

1. 対象外を決めてから、範囲を網羅します。 レビュー対象と明らかに無関係な参照情報だけを対象外とし、少なくとも6つは残します。対象外とした項目とその理由を記録し、最終報告ではレビューしていない領域を明示します。
2. まとめて分担します。 残りの参照情報を、関連する領域ごとに2〜4件のまとまりに分類します。下記の「サブエージェントへのレビューの委任」に従い、まとまりごとに読み取り専用のサブエージェント1つへ割り当てます。サブエージェントを利用できない場合は、自分で順番に各まとまりを確認します。
3. 影響をたどります。 各まとまりを確認する担当者は、それぞれのデザイン上の選択が、プレイヤーの情報、判断、行動、フィードバック、結果にどうつながるかを示し、症状と原因を区別します。
4. 統合して整合性を確認します。 根本原因が同じ重複所見を統合し、深刻度を標準化したうえで、領域をまたいだ矛盾がないか確認します。各矛盾も独立した所見として扱い、区別のないチェックリストを作成しないでください。

集中的レビュー

レビュー対象が会話内にすべて収まる場合、つまりデザインや質問が短い場合、またはユーザーのメッセージ内のメモやキーワードだけで構成され、参照すべき正式なドキュメントがない場合に使用します。

1. ルーティング表から関連する参照情報を2つまたは3つ選び、自分で確認します。
2. 包括的レビューと同様に影響をたどり、判断を変える可能性のある所見だけを提示します。

探索的レビュー

方向性がまだ決まっておらず、デザインが問題点の洗い出しには未成熟で、候補となる方向性とそれを見分けるテストをまとめることが目的の場合に使用します。

1. プレイヤーへの約束と、中心となる不確実性を特定します。
2. 一貫性のある方向性を2つまたは3つ提示します。
3. 方向性を見分けるための小規模なテストを定義し、完全なデザインドキュメントへ展開する前に止めます。

比較レビュー

資料の量にかかわらず、明確に定義された2つ以上の選択肢から選ぶことが目的の場合に使用します。

1. すべての選択肢に同じ根拠と基準を適用し、いずれかの選択肢だけを厳しくレビューしないでください。
2. 比較対象が複数の領域にまたがる場合、選択肢ごとに1つのサブエージェントへ委任し、各サブエージェントに同じ参照情報一式を適用させてもかまいません。
3. 包括的レビューと同様に、選択肢ごとの所見を統合します。

サブエージェントにレビューを委任する

サブエージェントはこの会話を共有しないため、それぞれが必要とする情報をすべて簡潔に伝えてください。

• レビュー対象と、設計資料の場所；
• 判断が必要な点と、確定済みの事実を再検討しないための根拠；
• 担当する参照パスと、分析の前にすべて読み通すよう指示すること；
• 調査結果をマージできるだけの十分な内容にするため、以下の調査結果の品質基準；
• 境界：実装タスクではなく、設計上の調査結果と、バッチごとに推奨する最小限の介入を返すこと。

サブエージェントの報告形式は、必要な内容が含まれていれば問いません。サブエージェントが示した重大度や優先度を、確認せずそのまま採用しないでください。マージはあなたの役割です。

参照先の振り分け

レビューの観点	読む資料	注目点
対象プレイヤー、意図する体験、動機、理解度	references/experience-and-audience.md	プレイヤーへの約束、動機の連鎖、楽しさの要素、学習に関する前提、体験上のギャップ
中核となるコンセプト、テーマ、感情、ファンタジー、美的アイデンティティ、好奇心と新鮮さ	references/concept-theme-and-emotion.md	コンセプトの明確さ、想像の余地、テーマの一貫性、感情を生む要因、表現の統一感、記憶に残るアイデンティティ
行動、目標、ルール、情報、主体性、複雑さと戦略	references/actions-rules-and-agency.md	目標の階層、意思決定の質、パフォーマンスの評価、ルールの分かりやすさ、構造と状態、支配的な行動、システムの特性
難易度、スキル構成、リスク、ペナルティ、報酬、進行、経済とリプレイの奥深さ	references/challenge-progression-and-economy.md	難易度の推移、要求されるスキル、公平性、期待される見返り、報酬の意味、時間構造、リソースの流入と流出、実行可能な進め方
パズル、推理、ヒント、ボトルネック、目に見える進捗	references/puzzles-and-problem-solving.md	問題の提示、推論の流れ、解決の構造、立て直しとヒントの段階的な提示
レベル空間、遭遇、ナビゲーション、ペース配分	references/space-level-and-pacing.md	ルート選択、分かりやすさ、リズム、立て直し、空間的な圧力
注意の推移、記憶に残る瞬間、間接的な誘導、臨場感	references/attention-guidance-and-presence.md	時間の経過に伴う興味、自発的な誘導、自由、妨げ、自己投影と語り直し
操作、UI、フィードバック、実用面でのアクセシビリティ	references/interface-feedback-and-accessibility.md	意図から行動へのループ、情報を提示するタイミング、フィードバックの豊かさ、エラーからの回復、入力や知覚の障壁
物語、世界、キャラクター、プレイヤーが紡ぐ物語	references/narrative-world-and-characters.md	プレイを通じた物語の伝達、物語の構成、世界の因果関係、役割、主体性、地位、キャラクターの機能
競争、協力、友情、コミュニティ、有害な行動	references/social-community-and-safety.md	プレイヤー間のインセンティブ、信頼、関係の継続性、自己表現、モデレーション、観戦時の分かりやすさ
スコープ、プロトタイプ、プレイテスト、技術、市場、流通、ビジネス、責任	references/production-validation-and-responsibility.md	制作との適合性、エビデンスの質、リスクの解消、市場での実現可能性、持続可能性、プレイヤーのウェルビーイング

調査結果の品質

有用な調査結果には、以下が含まれます。

• 観察： 現在の設計やエビデンスが示していること；
• メカニズム： それがプレイヤーの理解、選択、行動、感情にどう影響するか；
• エビデンスの状態： 確認済みの事実、裏付けのある推論、仮定、不明；
• 影響： 問題が実在する場合、何がうまくいかなくなるか；
• 推奨事項： 試す価値がある最小限の変更；
• 検証： どのような結果が推奨を支持または否定するか。

個人的な好みだけに基づく調査結果は避けてください。エビデンスが不足している場合は、予測を事実として示すのではなく、仮説とテストを記載してください。

レポートの構成

依頼を解決できる最短のレポートを使用してください。正式なレビューでは、次の形式を使用してください。

# Design Review: [object]

## Decision at stake
[The choice or uncertainty this review should resolve.]

## Evidence baseline
- Confirmed: ...
- Assumed: ...
- Unknown: ...

## Priority findings
### [Severity] [Finding]
- Observation:
- Mechanism:
- Evidence status:
- Recommendation:
- Validation:

## Tradeoffs
[What improves, what may get worse, and who is affected.]

## Next experiment
[Smallest build, simulation, or playtest; participants; observable signals; decision rule.]

優先順位付けに役立つ場合に限り、深刻度として critical、major、minor を使用してください。

• critical：中核となる約束を損なう、または有意義な検証を妨げるもの。
• major：一般的なプレイヤーの進行を大きく損なう、または後工程で大規模な手戻りを生じさせるもの。
• minor：局所的な不便や磨き込みの問題であり、現在の方針を無効にするものではないもの。

ガードレール

• プレイヤーの反応、テレメトリー、市場の事実、プレイテストの証拠を捏造しないでください。
• 相反する目標を隠さないでください。トレードオフを示し、最終決定を誰が行うのかを明確にしてください。
• デザイン上の弱点に答えるためだけに機能を増やさないでください。機能の削除、明確化、またはより小規模なルール変更のほうが適切な場合があります。
• 技術アーキテクチャを指示しないでください。後続の技術プロセスで特定のツールやワークフローを必要とせずに活用できるよう、確認済みのデザイン上の制約と検証基準を示してください。