「スマホで遊べるように」と添えるだけで何が変わるか

比べる条件を2つに絞る

条件は2つだけにします。変える要素が増えると、何が効いたのか分からなくなるためです。

• 条件A：お題だけを渡す
• 条件B：同じお題の末尾に「スマホで遊べるように」と一文を添える

お題は、入力方法の違いが出やすいものを選びます。たとえば次の文です。

左右に動いて、上から落ちてくる障害物をよける1画面のゲームを、外部ライブラリなしの1つのHTMLファイルで作ってください。

条件Bはこの文の直後に「スマホで遊べるように。」を足すだけです。言い換えたり、理由を書き足したりしてはいけません。「一言」の効果を見る実験なので、添える言葉は一言のままにします。

そろえるものは次のとおりです。

• 使うAIとモデル、各種設定
• 毎回、履歴のない新しい会話で依頼すること
• 出力形式の指定（「HTMLファイル1つで」など）
• お題の文面。AとBで違ってよいのは添える一文だけです

生成物を取る回数と保存のしかた

AIの出力は毎回少しずつ違います。1回ずつの比較では、一言の効果なのか、たまたまの揺れなのか区別できません。そこで各条件5回、合計10本を生成します。

保存のルールは次のとおりです。

1. ファイル名は A1.html〜A5.html、B1.html〜B5.html とし、生成した順に番号を振ります。
2. コードに手を入れず、返ってきたまま保存します。動かなくても直さず、「動かなかった」と記録します。
3. AIが説明文を付けてきた場合も、コード以外は別のメモに分けます。説明文に「スマホ対応しました」と書いてあっても、記録の根拠にはしません。確かめるのはコードと実際の動きです。
4. 外部ファイルや画像を求められたら、その回は「単独で動かない」と記録します。お題の段階で「1つのHTMLで」と指定しているのは、このためです。

記録シートとチェックスクリプト

10本それぞれについて、次の項目を記録します。コードの記述を見る項目と、実機で動かして見る項目に分けています。

• コード、項目：viewportの指定、記録のしかた：あり／なし、内容
• コード、項目：入力イベントの種類、記録のしかた：キーボード、pointer、touch、mouseのどれがあるか
• コード、項目：画面サイズへの追従、記録のしかた：固定サイズか、画面幅に合わせて変わるか
• コード、項目：画面上の操作ボタン、記録のしかた：あり／なし、最小の辺の長さ（CSSピクセル）
• コード、項目：touch-actionやpreventDefaultの扱い、記録のしかた：あり／なし
• 実機、項目：始められたか、記録のしかた：はい／いいえ
• 実機、項目：最後まで遊べたか、記録のしかた：はい／一部／いいえ
• 実機、項目：気になった点、記録のしかた：一文で自由記述

コード側の項目は、次のスクリプトで機械的に拾えます。生成したHTMLをPCのブラウザで開き、開発者ツールのコンソールに貼って実行します。

(() => {
  const src = document.documentElement.outerHTML;
  const vp = document.querySelector('meta[name="viewport"]');
  const sizes = [...document.querySelectorAll('button,[role="button"],a')]
    .map(e => e.getBoundingClientRect())
    .filter(r => r.width > 0 && r.height > 0)
    .map(r => Math.min(r.width, r.height));
  const cv = document.querySelector('canvas');
  const box = cv ? cv.getBoundingClientRect() : null;
  console.table({
    viewport: vp ? vp.content : 'なし',
    keyboard: /keydown|keyup/.test(src),
    pointer: /pointerdown|pointermove/.test(src),
    touch: /touchstart|touchmove|touchend/.test(src),
    touchAction: /touch-action/.test(src),
    preventDefault: (src.match(/preventDefault/g) || []).length,
    resizeAware: /resize|innerWidth|innerHeight|\bvw\b|\bvh\b|dvh/.test(src),
    canvasAttr: cv ? cv.width + 'x' + cv.height : 'なし',
    canvasShown: box ? Math.round(box.width) + 'x' + Math.round(box.height) : 'なし',
    minButton: sizes.length ? Math.round(Math.min(...sizes)) : '該当なし'
  });
})();

読み取るときの注意があります。

• この結果は「記述がある」ことを示すだけで、「正しく動く」ことは示しません。touchstart の文字列があっても、操作が効くとは限りません。最終判断は実機でします。
• canvasAttr と canvasShown が大きく違えば、CSSで拡大縮小されています。どちらもウィンドウ幅を変えて、2回測ってください。幅を変えても値が動かなければ、固定サイズと考えられます。
• minButton はHTMLのボタン類だけが対象です。canvasの内側に描かれたボタンは測れません。その場合は、実機で指で押して確かめます。

スマホ実機で確かめる手順

PCの開発者ツールには端末エミュレーションがあり、手早い確認には便利です。ただし、指で押したときの感触、ブラウザのアドレスバーによる表示領域の増減、画面の端の切り欠きといった要素は、実機でしか確かめられません。エミュレーションは下見に使い、判定は実機で行います。

実機での手順

1. 10本をランダムな順に並べ替え、AとBの区別がつかないようにファイル名を伏せます。自分の期待が評価に混ざるのを防ぐためです。
2. 各ファイルを、自分のスマホのブラウザで開きます。開く方法は、クラウドストレージ経由、自分宛のメール添付など、普段使う手段で構いません。
3. 縦持ちで開き、画面を見て、始められるかを判定します。
4. 始められたら、30秒ほど遊びます。時間は全ファイルで同じにします。
5. 横持ちに回して、レイアウトが崩れないかも見ます。
6. 記録シートに「始められたか」「最後まで遊べたか」「気になった点」を書き込みます。

「最後まで遊べたか」は、次のように決めておきます。

• はい：操作が一貫して効き、ゲームオーバーまで到達できた
• 一部：操作は効くが、画面外にはみ出す、ページがスクロールやズームしてしまうなど、遊びを妨げる問題があった
• いいえ：開始できない、または操作が効かない

アソバースの投稿画面で見る場合

アソバースへの作品投稿は、「入力→表示の確認→公開」の3段階です。アップロードしたコードは、sandbox付きのiframeの中で、メインサイトとは別のオリジンから配信されて動きます。ローカルのファイルとして開いたときと、同じ動きになるとは限りません。投稿を考えているなら、最終確認として、表示の確認の段階で一度は動かしてみてください。投稿にはメールアドレスの確認が必要です。まだ実験の段階なら、公開せずに下書きまでにとどめるのが安全です。

生成コードの中に localStorage でハイスコアを保存する処理があれば、メモしておきます。アップロードした作品内の localStorage と sessionStorage は、一時メモリーとして扱われる互換処理です。記録がずっと残る前提で作られたコードは、期待と違う動きになるかもしれません。

結果の読み方

10本の記録がそろったら、項目ごとにAとBを並べます。数えるのは「5本中何本で現れたか」です。

判断の目安

• Bだけで4〜5本に現れ、Aでは0〜1本の項目：一言の影響が比較的安定して出ている、と読めます。
• Bで1〜2本、Aでも1〜2本の項目：ばらつきの範囲かもしれません。一言の効果とは言い切れません。
• AとBの両方で5本中5本に現れる項目：お題の時点で、AIが標準的に入れる要素と考えられます。「スマホで」と添えなくても出るものです。
• Bで減った項目：副作用の候補です。たとえばキーボード操作の記述がBで消えていたら、「スマホ向け」と引き換えにPC向けの操作が失われた可能性があります。

各条件5本という数は少なく、ここから統計的に言える結論はありません。出てくるのは「この条件で、この傾向が見えた」という手がかりです。気になる傾向が見つかったら、お題を変えて同じ手順をもう一度行い、同じ方向になるかを見ます。

見るときの視点

差が出そうな場所は、実験の前に予想として書き留めておくと、後で見落としが減ります。たとえば次の観点です。

• 入力が、キーボードだけからタッチやpointerへ広がるか
• 画面サイズの扱いが、固定からウィンドウ幅への追従に変わるか
• 画面上の操作ボタンの有無や、大きさが変わるか
• ページ自体のスクロールやズームが、遊びの邪魔をしないよう抑えられているか

予想が外れても問題ありません。外れた箇所こそ、記録する価値があります。

間違えやすい点

添える位置や言い回しを回ごとに変える。 文末に添えた回と冒頭に置いた回が混ざると、効果の比較になりません。位置と文言は固定します。

1回の出力で結論を出す。 5本中1本で出た特徴を、一言の効果と見なすのは早計です。必ず本数で比べます。

説明文を証拠にする。 AIの文面が「対応しました」と書いていても、コードに入っているとは限りません。コードと実機で確かめます。

見た目と動作を混同する。 ボタンが大きく表示されていても、押して反応しなければ操作は成立していません。「見える」と「効く」は別々に記録します。

ブラウザや端末の差を無視する。 同じファイルでも、ブラウザやOSで挙動が変わることがあります。たとえば音は、スマホでは画面に触れるまで鳴らないことが一般的です。音が鳴らなかった場合は、コードの不備なのか、端末の仕様なのか、切り分けて記録します。

直してから評価する。 少し直せば動くコードでも、そのまま評価します。この実験で測るのは、一言で生成物がどう変わるかであり、直せば動くかどうかではありません。

次の行動

まず、お題を1つ決めて、条件Aと条件Bをそれぞれ5回ずつ生成し、ファイルに保存してください。次に、コンソール用スクリプトでコードの項目を埋め、ファイル名を伏せてスマホで30秒ずつ遊びます。差が見えた項目があれば、「タッチとキーボードの両方で」「縦画面で」のように具体的な指示を足した条件Cを作り、同じ手順で比べると、一言の限界が見えてきます。