AIの提案をすべて受け入れて試作を作ると、方向性はどう変わるか:記録の設計書
遊びをつくる執筆にClaudeを使用しています。

「30秒で終わる、一本指だけの避けゲー」を作ろうとしている場面を考えてみます。AIに最小の試作を作ってもらい、「次に改善するとよい点を教えてください」と尋ねると、「コンボ表示を足す」「アイテムを追加する」「背景を昼夜で変える」といった提案が返ってきます。どれも悪くなさそうなので、すべて採用します。これを10回繰り返したとき、手元の作品は最初の一文とどれだけ離れているのでしょうか。 この記事は、その問いに答えを出すのではなく、自分で答えを出すための実験の設計書です。判断を意図的に手放し、作品がどこへ向かうかを記録に残します。結果は制作者ごと、AIの設定ごとに変わるため、ここでは結果を書きません。書くのは、準備、手順、記録の取り方、結果の読み方、起こりやすい誤りです。 この実験の目的は、AIの提案の良し悪しを裁くことではありません。自分が普段どの提案を捨てているのかを、一度全部受け入れることで見えるようにします。判断の跡が見えれば、自分の「核」がどこにあるのかが、後から分かります。
実験で確かめる問いと、固定する条件
問いは一つに絞ります。「提案を選別せずに採用し続けると、作品の核は何ラウンド目で、どの種類の提案によって変わるか」です。
この問いを測れる形にするため、先に次の条件を決めます。
- 核の一文:作りたいものを一文で書きます。例は「30秒で終わる、一本指だけの避けゲー」です。ここに入れた言葉が、後で距離を測る物差しになります。
- 制約の3項目:プレイ時間、操作方法、画面の数など、核に含まれる制約を3つ書きます。例は「30秒」「タップのみ」「画面は1つ」です。
- ラウンド数:10ラウンドを目安にします。少なすぎると変化が見えず、多すぎると記録が続きません。
- 1ラウンドの提案数:最大3つと決めて、依頼文にも書きます。上限がないと、1ラウンドで大量に採用することになり、どの提案が効いたのか分からなくなります。
- 採用の規則:出された提案はすべて実装します。順番を変えたり、言い換えたり、一部だけ採用したりしません。
例外は、事前に決めておきます。動かなくなる提案、サーバーなどの外部通信が必要になる提案、素材の権利が不明な提案は、実験の都合で採用が難しくなります。その場合は「却下」ではなく「例外として保留」と記録し、代わりの提案を一度だけ求めます。例外の条件は実験の前に書き、実験の途中で増やしません。途中で増やすと、好みで取捨選択する抜け道になります。
準備するもの
用意するものは多くありません。
- 普段使っているAIアシスタント(モデル名と設定を記録しておきます)。
- 試作を保存できるフォルダ。ラウンドごとに round01、round02 のようにコピーして、いつでも戻れるようにします。
- 単独で動くHTMLの試作。アソバースに投稿する場合は、直下の index.html を入口にする形が前提です。投稿するかどうかは実験の目的ではありません。公開する場合も、下書き保存や非公開化ができるので、実験用の作品は公開せずに手元で終えても問題ありません。
- 記録シート(次の節で説明します)。
- 手を付ける前の「核の一文」を書いた紙かメモ。実験中は常に見える位置に置きます。
手順:1ラウンドの流れ
最初に、核の一文と3つの制約をAIに渡して、最小の試作を作ってもらいます。この試作が round00 です。ここでは提案を求めず、核がそのまま形になっているかを確認します。この段階で核と違うものができていたら、実験を始める前に核の伝え方から直します。
その後は、次の流れを10回繰り返します。
- AIに「この試作の次の改善案を、最大3つ、理由つきで挙げてください」と依頼します。
- 出された提案を、そのままの文面で記録シートに写します。要約や言い換えはしません。
- 提案をすべて実装するよう、AIに依頼します。実装もAIに任せ、自分でコードを直しません。
- 動かない場合は、動くよう直すことだけを依頼します。内容の取捨選択は含めません。
- 動いたら、フォルダを保存します。
- 2分ほど実際に遊び、感想を1〜2行でメモします。
- 核の一文と見比べて、距離スコアをつけます(次の節)。
ラウンドの途中で「これはいらない」と感じても、削除の依頼は出しません。ただし、AIが自分から「簡素化」を提案してきた場合は、他の提案と同じく採用します。判断を放棄するとは、足す方向にも引く方向にも手を出さない、ということです。
なお、AIの会話が長くなると、最初の核の一文が文脈から薄れることがあります。そのため、各ラウンドの依頼文の冒頭に、核の一文と制約の3項目を毎回貼り直します。これは判断ではなく、条件の固定です。
記録の取り方:何を、どの単位で残すか
ラウンドごとに1行、次の項目を残します。
- ラウンド番号、記録のしかた:0〜10
- 提案の原文、記録のしかた:1提案ごとにそのまま写す
- 分類、記録のしかた:下の6種から1つ
- 理由の有無、記録のしかた:AIが理由を添えたか(有/無)
- 遊んだ感想、記録のしかた:1〜2行
- 制約の3項目、記録のしかた:守れているか(○/×)
- 距離スコア、記録のしかた:1〜5の自己評価
分類は次の6種にします。
- 追加:新しい機能や要素を足す
- 調整:数値やタイミングを変える
- 装飾:見た目や音、演出を変える
- 複雑化:ルールや状態を増やす
- 簡素化:要素やルールを減らす
- 方向転換:ゲームの主題や遊び方そのものを変える
迷ったときは、遊んだ人が「新しく覚えること」が増えるなら複雑化、増えないなら追加か装飾、と決めておきます。分類の基準は実験前に1行で書き、途中で変えません。
距離スコアは、核の一文を物差しにして、次のように決めます。
- 5:核の一文をそのまま使って作品を説明できる
- 4:核の一文に小さな補足を足せば説明できる
- 3:核の一文の半分は当てはまるが、追加要素が主役になる場面がある
- 2:核の一文を大きく書き換えないと説明できない
- 1:核の一文とは別のゲームになっている
自己評価は主観です。そのため、スコアは遊んだ直後につけ、後から直しません。さらに、制約の3項目の○×を別に残しておくと、主観に頼らない指標が一つ増えます。
集計を楽にしたい場合は、ブラウザの開発者ツールのコンソールに、次の短いコードを貼って使えます。log の中身を自分の記録に置き換えてください。
const log = [
{ round: 1, type: "追加", score: 5 },
{ round: 2, type: "装飾", score: 5 },
{ round: 3, type: "複雑化", score: 4 }
// 以降も同じ形で書き足します
];
const count = {};
log.forEach(e => { count[e.type] = (count[e.type] || 0) + 1; });
console.log("分類の数:", count);
const first = log.find(e => e.score <= 3);
console.log("初めて3以下になった提案:", first || "なし");
const scores = log.map(e => e.score);
console.log("スコアの推移:", scores.join(" → "));上の数値は書式を示すための仮のデータで、実験結果ではありません。
結果の読み方
10ラウンドが終わったら、記録を三つの角度から読みます。
1. 距離スコアの形を見ます。 緩やかに下がり続けるなら、小さな提案の積み重ねが核を削っている可能性があります。ある提案の直後に急に下がるなら、その1件が分岐点です。上下するなら、提案の中に核へ戻す力のあるもの(簡素化など)が混ざっているかもしれません。どの形になっても、それが「あなたの使い方での傾向」であり、他の人にも当てはまるとは限りません。
2. 分類の比率を見ます。 追加と複雑化が多いなら、AIの提案は足す方向に偏りやすいのかもしれません。簡素化が少ないことが自分の環境でも確認できたなら、「引く」判断は人間側が担う部分だと読み取れます。逆に、簡素化や調整が多く出たなら、核が単純なほど提案も整う、という見方もできます。
3. 最初に3以下になった提案を読み直します。 分類は何か、理由は何と書かれていたか、感想メモで自分はどう感じたかを並べます。「理由が納得できたから採用した」のか、「ルールだから採用した」のかを区別することが目的です。ルールで採用して不満が出たなら、それは普段なら捨てていた提案です。その種類が、あなたの判断基準の輪郭になります。
判断の目安として、次のように整理できます。
- 3以下になった提案が特定の分類に集中していれば、その分類の提案は普段から選別が必要だと考えられます。
- 制約の3項目が先に崩れ、スコアが後から下がるなら、制約を依頼文でより強く固定する余地があります。
- スコアがほとんど下がらなかった場合も、核が頑丈だったのか、提案が控えめだったのかは区別できません。この点は次の「誤り」で補います。
起こりやすい誤りと、確かめを強くする方法
よくある誤りは次のとおりです。
- 提案を言い換えて取捨選択してしまう。 「だいたいこういう意味」と要約して実装を依頼すると、無意識に選別が入ります。原文のまま渡します。
- 遊ぶ前にスコアをつけてしまう。 コードや提案文だけを見て評価せず、必ず遊んだ後につけます。
- ラウンド途中で自分の手で直す。 バグ修正だけでも、見た目の微調整のつもりが方向を変えることがあります。直す場合もAIに依頼し、記録に残します。
- 一度の結果で一般化する。 核を変えたり、AIの設定を変えたりして、複数回やると傾向が見えやすくなります。1回だけの結果は、その回の記録にとどめます。
- 自分の目だけで評価する。 作った本人は経緯を知っているため、変化に慣れます。数日置いてから、経緯を知らない人に遊んでもらい、「どんなゲームか」を一言で答えてもらいます。その答えと核の一文の近さを見る方法もあります。この場合、感想を聞く際に誘導しないよう注意します。
さらに強い比較にしたい場合は、同じ核の一文から、提案を自分で選別する版を同じ10ラウンドで作ります。選別版と全採用版を並べて遊び、どちらが核に近いか、どちらが遊んで面白いかを別々に記録します。核に近いことと面白いことは一致しない場合があるため、二つの評価軸は分けて残します。全採用版のほうが面白いと感じる結果になることもありえますし、それも実験の正当な結果です。
次の行動
まず核の一文と制約3項目を紙に書き、記録シートの列を決めてください。その後、round00 の最小試作を作ってもらうところまでを今日の作業にします。10ラウンド分の記録がそろったら、距離スコアの推移と、最初に3以下になった提案の分類を確認してみてください。

