「動くけどつまらない」ゲームを改善するためのAIへの質問集
遊びをつくる執筆にClaudeを使用しています。
ゲームが一通り動くようになったとき、作った本人でも「何かが足りない」と感じることがあります。バグはない、操作もできる、でも繰り返し遊びたいとは思えない。この感覚は、ゲームデザインの問題であってコードの問題ではないため、エラーログを読んでも原因が見つかりません。 AIはこの種の問題に対して、質問の仕方を工夫すると有効なフィードバックを返します。ただし「このゲームを面白くして」という依頼では抽象的な提案しか返ってきません。AIに「つまらない理由を言語化させる質問」と「改善の優先順位をつける質問」を使い分けることが、実際に手を動かせるレベルの答えを引き出す鍵です。 この記事では、「動くけどつまらない」という状態を具体的に分解し、AIに投げかけるべき質問のパターンを場面ごとに整理します。プロンプトの言葉そのものよりも、何を問うべきかという視点を持ち帰ってください。
この記事の目次
なぜ「つまらない」は言語化が難しいのか
つまらないと感じるとき、実際に起きていることはいくつかに分類できます。「次に何をすればいいかわからない」「何をしても同じ結果になる」「リスクを取る理由がない」「うまくなっている実感がない」「繰り返しに変化がない」。これらは別々の問題であり、それぞれ別の改善策を必要とします。
作者が「つまらない」と感じているとき、多くの場合は上記のうち複数が重なっています。AIにそのまま「つまらないと感じる原因を教えて」と問うと、網羅的なリストが返ってきますが、自分のゲームのどこが該当するかは判断できないまま終わります。有効な質問を作るには、まず「自分のゲームの何がつまらないのか」を観察しておく必要があります。
最初にやるべき「症状の観察」
AIへの質問の質は、ゲームの描写の精度に比例します。質問を作る前に、次の点を自分でメモしておきます。
- プレイヤーが最初にとる行動は何か
- 同じ操作を何回繰り返したら飽きを感じたか
- 「もう一回やろう」と思わなかった瞬間はどこか
- 失敗したとき、何が原因だったかわかったか
この観察ができていると、AIに「開始後30秒で同じ操作を繰り返すだけになる。プレイヤーが選択を迫られる場面を作るにはどんな要素が有効か」という具体的な質問ができます。「つまらない」という形容詞より「30秒で選択肢がなくなる」という事実の方が、AIは精度の高い返答を出しやすくなります。
診断フェーズ：つまらない理由を引き出す質問パターン
以下は、症状ごとにAIへ投げかける質問の構造です。ゲームの内容を2〜3文で説明したうえで、これらの問いを続けます。
選択肢の問題を疑うとき「このゲームでプレイヤーが意思決定をしている場面はどこだと思うか。また、その決定に意味がある（結果が変わる）かどうかを評価してほしい」
この質問は、AIに「意思決定の有無」と「その意思決定が結果に影響するか」の二点を分けて評価させます。操作はあっても選択がない、あるいは選択はあっても結果が変わらない、という状態をAIが指摘することで、改修の方向が絞れます。
難易度曲線の問題を疑うとき「プレイヤーが最初の1分間で直面する障害を順番に説明した。この障害の並び方は、習熟に合わせて適切に変化しているか。また、プレイヤーが『うまくなっている』と感じられるタイミングはどこに設計されているか」
難易度設計の問題は「難しすぎる」ではなく「成長の実感がない」として現れることが多いです。AIにこの観点で評価させると、「報酬のフィードバックが遅い」「障害がランダムで学習不能に見える」といった指摘が返ってきやすくなります。
繰り返しの問題を疑うとき「このゲームを2回目にプレイしたとき、1回目と異なる体験になる要素はどれか。同じになる部分と変わる部分を分けて整理してほしい」
同じ体験が繰り返されることは、パズルなら許容されますがアクションや戦略ゲームでは飽きに直結します。AIに1回目と2回目の差を整理させることで、「変化を生む仕組みがそもそもない」という構造上の問題が見えてきます。
改善フェーズ：優先順位をつける質問パターン
診断の後、AIから複数の改善案が出てきた場合、すべてを実装しようとすると迷走します。次の質問で絞り込みます。
最小の変更で最大の変化を探す「今挙げた改善案のうち、コードの変更量が少なく、プレイ感への影響が大きい順に並べてほしい。また、それぞれ何を変えればいいか一行で説明してほしい」
AIに「影響の大きさ」と「実装コスト」の二軸で並べさせることで、最初に試すべき一手が決まります。完成に近いゲームを大幅に作り直すより、数値や出現タイミングを変える小さな修正を先に試す方が、改善のサイクルが速く回ります。
根本原因か症状かを分ける「この問題は独立した問題か、それとも別の設計上の問題から派生しているか。根本にある問題から直せば、他の問題も解決しそうか」
一つの症状に対して直接修正を加えると、別の問題が出てくることがあります。AIに「これは症状か、根本か」を問うことで、遠回りに見えても設計を直した方が早いケースを先に判断できます。
フィードバックを受け取るときの注意点
AIは批判的なフィードバックを求めると答えてくれますが、デフォルトでは穏やかな評価を返す傾向があります。厳しい視点が欲しいときは「このゲームを初めて触った人が10分でやめると仮定して、その理由を5つ挙げてほしい」という形で、ネガティブなシナリオを前提にした問いを使います。
また、AIが提案する改善策は一般的なゲームデザイン論に基づいたものが多く、自分のゲームの文脈に合わないこともあります。提案を受け取ったあと「その方法はこのジャンルのゲームにそぐわない理由はあるか」と問い返すことで、提案の前提を検証できます。AIに提案させる・疑問をぶつける・取捨選択する、という往復を繰り返すことが、自分で判断できるレベルまで整理するうえで有効です。
AIへの質問はゲームの完成度を直接上げるのではなく、自分がまだ言語化できていない問題を引き出すための道具です。「何がつまらいのかわからない」という状態から「どこを直せばいいかわかった」という状態に移るためのプロセスとして使うのが、最も効果を発揮します。
次の行動
自分のゲームの「飽きを感じた瞬間」を一つ具体的に書き出してから、この記事の診断フェーズの質問をAIに投げてみてください。改善案が出たら「最小の変更で最大の変化」の質問で絞り込み、まず一つだけ実装して変化を確認します。改善したゲームはアソバースに投稿して、実際の読者のプレイ反応を次の診断材料にするのが最も速いフィードバックループです。
