画面のスケッチだけ渡してゲームを作らせる

問いを絞る

「スケッチだけでゲームは作れるか」は大きすぎて、答えが「作れた」「作れなかった」の2択になってしまいます。次の3つに分けて考えてみます。

1. 絵に描かれた要素のうち、意図どおりの役割で実装されるものはどれか。
2. 絵に描かれていない振る舞い（勝ち負け、得点、終わり方）を、AIはどう補うか。
3. 同じ絵を何度渡しても、同じ読み方になるか。それとも回ごとに変わるか。

3つ目が重要です。誤読が毎回同じ要素に出るなら、原因は絵の曖昧さにあると考えられます。回ごとに違う場所で出るなら、AIの推測のゆらぎが原因の可能性が高く、スケッチを直しても効きにくいと見込めます。この切り分けが、実験の中心になります。

もう一点、ルールの推測と実装の出来は別物です。「読み取ったルールは正しいが、動かすとバグがある」場合と、「ルールの読み取り自体が違う」場合を混ぜると、誤解の記録が濁ります。そのため、手順では実装の前にAI自身にルールを文章で書かせ、二段階に分けます。

準備するもの

• 画像を読めるAI：スケッチの写真やスキャンを添付できるものを使います。実験中は同じAIとモデルに固定します。
• スケッチ3枚：画面1枚で完結するもの。たとえば次のように、曖昧さの種類を変えて描き分けます。
• A：要素が少なく、役割の手がかりも少ない絵（先ほどの数字・3×3マス・黒丸・矢印2つ）
• B：要素が多いが、ラベルが一語ずつ付いている絵
• C：Aと同じ絵に、矢印を1本足して「黒丸がこの向きに動く」と示したもの
• 意図メモ：各スケッチについて、描いた本人が考えているルールを事前に書いたもの。AIに見せる前に書き終え、保存しておきます。
• 固定の指示文：全スケッチ・全回で同じ文面を使います。
• 記録用の表：後述の誤解ログを、表計算ソフトか紙に用意します。
• ブラウザ：生成物を開いて動作を確かめるために使います。

指示文の例です。

添付はあるブラウザゲームの画面スケッチです。まず、この絵から読み取れるルール（操作方法、勝ち負け、得点、終わり方）を箇条書きで書いてください。質問はせず、推測で答えてください。次に、そのルールどおりに動く単一の index.html を作ってください。外部ライブラリと外部通信は使わず、素材は同じファイル内で完結させてください。

最後の一文は、実験の都合だけでなく、生成物をアソバースへ投稿したくなったときのためでもあります。アソバースへのアップロードは、直下の index.html が入口で、サーバー用コードやサービスワーカーは対象外です。最初から単独のHTMLで作らせておけば、後で手直しの手間が減ります。

意図メモの書き方にも注意が要ります。「黒丸は自分、矢印で左右に動かす、数字は残り手数、0になったら終了」のように、要素ごとに役割を1行で書いてください。「いい感じに遊べる」のような曖昧な書き方では、後で採点できません。

手順

1. スケッチAを撮影またはスキャンします。影や机の模様が映り込まないよう、明るい場所で真上から撮り、画像の向きを確認します。
2. 新しい会話を開き、スケッチと固定の指示文を送ります。会話の履歴は引き継がず、毎回まっさらな状態から始めます。
3. 返ってきた「読み取ったルール」の箇条書きを、そのまま保存します。この時点ではゲームを動かしません。
4. 続けて出力されたHTMLを保存し、ブラウザで開きます。1〜2分ほど実際に操作し、触れた要素と挙動をメモします。
5. 同じスケッチAで、手順2〜4をもう2回繰り返します（合計3回）。
6. スケッチB、スケッチCも同じ手順で各3回行います。合計9回です。
7. すべて終わってから、意図メモと突き合わせて誤解ログを埋めます。実施の途中で採点を始めると、次の回の指示文や見方が無意識にぶれやすくなります。

回数を3回としたのは、ゆらぎの有無を見るための最小限として、という考えです。余裕があれば5回に増やすと、傾向がより見えやすくなります。

記録の取り方

記録の単位は「スケッチ上の要素ごと」です。ゲーム全体に「良い・悪い」を付ける方式は使いません。スケッチAなら、要素は「上の数字」「3×3のマス」「黒丸」「左矢印」「右矢印」の5つです。これに加えて、絵にない「勝敗・終わり方」を1行足します。

各要素について、次の5つの区分のいずれかを付けます。

• 一致、意味：意図メモと同じ役割で動いた
• 補完、意味：絵にはないが、矛盾しない追加があった（例：終了時の表示）
• 誤読、意味：絵にある要素が、意図と違う役割になった
• 欠落、意味：絵にある要素が実装されない、または動かない
• 捏造、意味：絵に根拠のない大きな機能が加わった（例：敵キャラの追加）

誤解ログは、次のような形で作ります。

• A、回：1、要素：上の数字、意図メモ：残り手数、自己申告ルール：（転記）、実際の挙動：（観察）、区分：（判定）

「自己申告ルール」と「実際の挙動」を別の列にするのが要点です。この2列が食い違っていれば、ルールの理解ではなく実装段階の問題だと分かります。自己申告のほうが意図メモと食い違っていれば、スケッチの読み取りの問題です。

判定に迷った場合は、「意図メモの言葉で説明できるか」で決めます。説明できなければ誤読にします。迷った行には印を付け、最後にまとめて見直します。

結果の読み方

ログが埋まったら、まず要素ごとに「3回中何回が誤読か」を数えます。そのうえで次のように読みます。

• 同じ要素が3回中2回以上、同じ方向に誤読される：スケッチ側の曖昧さが原因と考えられます。その要素にラベル一語か記号を足す価値があります。
• 誤読の要素が回ごとにばらける：AIの推測のゆらぎが主因と考えられます。スケッチを細かく直すより、指示文で「不明な点は最も単純な解釈を採る」と方針を与えるほうが効く可能性があります。
• 欠落が多い：描いた要素の数に対して指示が長すぎるか、要素が小さくて読み落とされている可能性があります。要素を大きく描く、番号を振る、といった直し方が考えられます。
• 自己申告は正しく、挙動だけ違う：読み取りは成功していて、実装の段階で崩れています。ここはスケッチの問題ではないので、描き直しは不要です。
• 捏造が毎回同じ形で現れる：絵が「その機能がありそう」と思わせている可能性があります。余白、装飾、枠の描き方を見直してください。

スケッチCは、Aに矢印を1本足しただけの絵でした。AとCで誤読の数が変わったかを比べることで、「絵に1点足すと誤読は減るのか」に近づけます。差が出なければ、足した記号が効いていない、またはその要素の誤読の原因が別にあるという読み方になります。

起こりやすい誤り

• 一度に複数の点を変える：スケッチの描き方と指示文を同時に変えると、どちらが効いたのか分かりません。変えるのは1回に1点だけにします。
• 1回だけで判断する：1回の結果は、ゆらぎとの区別がつきません。最低でも3回を揃えてから読みます。
• 採点者の思い込み：描いた本人は意図を知っているので、挙動を意図に寄せて好意的に読んでしまいがちです。意図メモを先に書いて固定し、可能なら別の人に区分を付けてもらってください。
• 会話の持ち越し：同じ会話で2回目を頼むと、前回の出力に引っ張られます。必ず新しい会話にします。
• 画像の品質：斜めの写真、薄い鉛筆、紙の罫線は、要素の誤認や欠落の原因になります。誤読の原因が絵の内容ではなく画質だった場合を切り分けるため、画像は全回で同じファイルを使います。
• 遊び込みすぎ：1回の確認に時間をかけすぎると、後の回の観察が雑になります。1回あたりの操作時間は決めておきます。

次の行動

まず、スケッチAのような最小の絵を1枚描き、意図メモを書いてからAIに渡してみてください。3回分のログを取れば、誤読が出る場所が絵の側にあるのか、AIの側にあるのかが見えてきます。

誤読が少なかった生成物は、手を入れてアソバースに投稿することもできます。HTMLを直接アップロードできます（20MiB以内、直下に index.html）。投稿画面の「紹介文と遊び方を作成」は、アップロードしたゲームを読み取って説明の下書きを作ります。この下書きと自分の意図メモを見比べると、もう一段階の読み取りの確認にもなります。使うかどうかは、「この文章を使う」を押すかどうかで決められます。