「スマホでも」と「スマホで」の違い：対象の優先順位

実験の設計：変えるのは一字だけ

問いと予測

問いは「『スマホでも』と『スマホで』で、生成されるゲームの主役の入力方式と画面設計は変わるか」です。結果を見る前に、予測を紙に書いておきます。たとえば次のようなものです。

• 「でも」ではキーボード操作が主で、タッチは補助として付く。
• 「で」ではタッチ操作が主で、キーボードは付かないか、後ろに回る。
• どちらも両対応になり、差は説明文の順序くらいにとどまる。

予測を先に固定しておくと、結果を見たあとに都合よく解釈する誤りを避けられます。

準備するもの

• 同じ生成AIを一つ。モデルと設定は途中で変えません。
• 新しい会話を6回分。過去のやりとりが残った会話は使いません。
• ブラウザ（開発者ツールが使えるもの）と、可能ならスマホ実機。
• 記録用の表（次の節で示します）。

二つのプロンプト

題材は固定します。ここでは「落ちてくる星をよける」を例にします。

• A（でも）：スマホでも遊べる、落ちてくる星をよけるブラウザゲームを、単独の index.html 一枚で作ってください。
• B（で）：スマホで遊べる、落ちてくる星をよけるブラウザゲームを、単独の index.html 一枚で作ってください。

「遊べる」の語尾まで揃えているのは、差を「も」だけにするためです。「遊べる」と「遊ぶ」のように動詞まで変えると、どちらの違いが効いたのか区別できなくなります。

手順

1. 新しい会話を開き、Aを貼り付けて送ります。出てきたHTMLを A1.html として保存します。
2. 別の新しい会話でAをもう2回行い、A2.html、A3.html を保存します。
3. 同じ要領でBを3回行い、B1.html〜B3.html を保存します。
4. 途中で「ここを直して」といった追加の依頼はしません。最初の出力だけを対象にします。
5. 保存したあと、まだ中身を読みすぎないうちに、次の節の表を埋めていきます。

同じ条件を3回ずつ繰り返すのは、AIの出力が毎回少しずつ変わるためです。1回ずつの比較では、「も」の影響と偶然のばらつきを区別できません。

記録の取り方：優先順位を数える

「両方に対応しているか」だけを記録すると、差は見えにくくなります。ここで見たいのは、対応の有無ではなく優先順位です。両対応のゲームでも、どちらを先に説明し、どちらを大きく見せ、どちらを初期状態で出すかには差が出ます。

目で見て記録する項目

各ファイルをブラウザで開き、次の項目を埋めます。

• 入力の手段、記録の仕方：キーのみ／タッチのみ／両方
• 操作説明の先頭、記録の仕方：最初に書かれている操作（キー or タップ）
• 画面上の操作ボタン、記録の仕方：有無と個数
• 開始の操作、記録の仕方：スペースキー、クリック、タップなど
• 画面の向き、記録の仕方：縦持ち前提か、横長前提か、可変か
• ホバーへの依存、記録の仕方：マウスを乗せないと見えない要素の有無

画面の向きを見るには、開発者ツールのデバイス表示（スマホの画面サイズを模す機能）で、幅を375px前後にして開きます。そのあと向きを入れ替えて、崩れ方も確認します。

数字で記録する項目

目視に加えて、HTMLの中身を機械的に数えると、採点が自分の印象に引きずられにくくなります。次の短いコードを、開発者ツールのコンソールに貼って実行します。外部通信は行わず、開いているページを読むだけです。

(() => {
  const html = document.documentElement.outerHTML;
  const count = (re) => (html.match(re) || []).length;
  const vp = document.querySelector('meta[name="viewport"]');
  const targets = [...document.querySelectorAll(
    'button, a, [role="button"], input')];
  const small = targets.filter(el => {
    const r = el.getBoundingClientRect();
    return r.width > 0 && (r.width < 44 || r.height < 44);
  });
  console.table({
    viewportMeta: vp ? vp.content : 'なし',
    keydown: count(/keydown|keyup/g),
    pointerOrTouch: count(/pointerdown|touchstart|touchmove/g),
    hoverCss: count(/:hover/g),
    mouseover: count(/mouseover|mouseenter/g),
    mediaQuery: count(/@media/g),
    操作要素: targets.length,
    小さい操作要素: small.length,
    横スクロール: document.documentElement.scrollWidth > innerWidth,
  });
})();

44pxという基準は、タップしやすさの目安として広く使われている大きさです。厳密な合否の線ではなく、A群とB群を比べるための共通の物差しとして使います。これを幅375px前後の状態で、6ファイルすべてに同じ条件で実行します。出力の表は、そのままファイル名と並べて記録します。

数えているのはあくまで文字列の出現回数です。keydown が3回出てくることは、キー操作の実装が厚いことの目安にはなりますが、動作を保証するものではありません。実際に押して動かして、目視の記録と照らし合わせます。

結果の読み方：差とばらつきを比べる

6つのファイルが記録できたら、見るのは「A群の中の揃い方」と「A群とB群の違い」の二つです。

判断の表

• A群3回が同じ傾向、B群3回が別の同じ傾向、読み方：「も」の有無に文言として反応している可能性が高い
• A群もB群も3回の中で傾向がばらばら、読み方：この題材と頼み方では、一字より偶然のほうが大きい
• 両群とも両対応だが、説明の先頭やボタンの大きさに偏りがある、読み方：対応の有無ではなく「優先順位」に差が出ている
• 両群とも似ており、差は数字（小さい操作要素の数など）だけ、読み方：設計の中心は動かず、細部だけが動いている

最初の行に当てはまった場合でも、3回ずつでは「可能性が高い」止まりです。確信したいときは、題材を替えて（たとえば「ブロックを積む」「迷路を抜ける」）同じ手順をもう一巡します。題材を替えても同じ向きに差が出れば、一字の読み取りとして信頼しやすくなります。

「できている」と「優先されている」を分ける

どちらのプロンプトでも、両対応のゲームが出ることは十分にあり得ます。そのときは、次の三点を比べます。

• 操作説明の最初に書かれているのはどちらの操作か。
• 画面上のボタンは常設か、タッチを検出したときだけ出るのか。
• 画面幅の基準が固定ピクセルか、可変か。

この三つは、設計者が「まず誰を想定したか」を最も素直に表す箇所です。「でも」で説明がキー操作から始まり、「で」でタップから始まるなら、一字が優先順位に反映された証拠として読めます。

参考に、公式作品「紙ひこうき郵便」は、左右キー、ドラッグ、矢印ボタンの三つの操縦手段を備えています。この並びからは、キーボードとタッチのどちらも想定した設計であることが読み取れます。どの手段が最初に目に入るか、どれが大きいかは、作品を開いて確かめてください。同じ見方を、生成されたゲームにも当てはめられます。

誤りやすい点

• 同じ会話で続けて試す。 Aのあとに同じ会話でBを送ると、直前のやりとりに引きずられます。必ず会話を分けます。
• 途中で直しを頼む。 「ボタンも付けて」と一度でも頼むと、プロンプトの差が追えなくなります。比較するのは最初の出力だけです。
• 一字以外も変わっている。 語尾、句読点、改行まで揃っているか、貼り付ける前に二つの文を並べて見比べます。
• 採点基準を後から足す。 結果を見てから項目を増やすと、見つけたい差に合わせて物差しを作ってしまいます。表は最初に決めて、途中で変えません。
• エミュレーションだけで判断する。 デバイス表示はタッチ操作の再現が完全ではありません。可能なら実機でも、開始から終了まで一度は遊んでみます。
• ばらつきを無視する。 A1だけが極端でも、A群全体の傾向とは言えません。3回の揃い方を先に見ます。

次の行動

まず題材を一つ決めて、AとBを3回ずつ生成し、記録表とコンソールのコードで6本を比べてみてください。差が見えたら、次は「スマホとPCの両方で」「スマホ専用で」の言い回しを加えて、語の幅で優先順位がどう動くかも確かめられます。確かめたゲームは、そのまま index.html を入口にしてアソバースに投稿できます。公開前の表示確認の段階で、スマホの画面幅でも崩れていないかをもう一度見ておくと安心です。