日本語と英語で同じゲームを頼む：違いが出るのはどこか

「同じ依頼」の作り方：固定する項目と空けておく項目

最初に決めるのは、何を同じにして何を空けるかです。次の表をそのまま仕様表として使えます。

• 形式、扱い：固定、内容：1ファイルのHTML。外部通信、外部ライブラリなし
• 制限時間、扱い：固定、内容：30秒
• 基本ルール、扱い：固定、内容：的をクリックまたはタップすると得点が入る
• 表示、扱い：固定、内容：残り時間と得点を常に表示。終了時に最終得点とやり直しの操作を出す
• 難易度の変化、扱い：空ける、内容：指定しない
• 見た目の雰囲気、扱い：空ける、内容：指定しない
• ゲーム名・用語、扱い：空ける、内容：指定しない
• 画面の文言の言語、扱い：空ける（本実験）、内容：指定しない

最後の行が、この実験でいちばん面白い部分です。依頼文の言語だけを変え、ゲーム内の表示言語は指定しません。AIが依頼文の言語に合わせて画面の文言を決めるのか、日本語の依頼でも英語の画面を返すことがあるのかを観察できます。本実験を終えたあとで、「画面の文言は日本語にしてください」「in English」と指定する追加条件を同じ手順で回すと、指定の効き方も分かります。

二つの依頼文の作り方

依頼文は、翻訳ツールに通して作らないほうが安全です。直訳は片方の言語の語順や敬語表現を引きずり、「丁寧にお願いする調子」まで持ち込んでしまうためです。次の手順で作ります。

1. 日本語版を、上の表の固定項目だけを使って短く書きます。
2. 英語版は、日本語版を見ずに、同じ表の項目から別に書き起こします。
3. 英語版を日本語に訳し戻して、日本語版と情報量が同じかを確かめます。足りない条件や、余計な条件が混じっていないかを見ます。
4. 文字数や単語数が極端に違わないかを確認します。ただし言語が違えば長さは揃いません。条件の数が同じであれば十分です。

依頼文には「楽しいゲームにしてください」「かっこよく」のような評価語を入れないでください。評価語は言語ごとに含意が違い、差の原因を特定できなくなります。

準備と手順

準備するものは次のとおりです。

• 使うAIのサービスとモデルを一つに決めます。途中でモデルが更新されないよう、実験は同じ日にまとめて行います。
• 日本語の依頼文と英語の依頼文を、テキストファイルとして保存しておきます。
• 生成物を保存するフォルダと、記録用の表（スプレッドシートでかまいません）を用意します。
• 生成物を開く複数のブラウザを用意します。可能なら、PCと手元のスマートフォンの両方で開けるようにします。
• 盲検化のため、ゲームを遊んで評価する人を、依頼文を書いた人とは別にできると理想的です。難しければ後述の工夫で補います。

手順は次の流れです。

1. 毎回、新しい会話を開始します。前の会話の履歴や、保存された指示が残っていないことを確認します。
2. 日本語の依頼文を送り、返ってきたコードを、手を加えずに保存します。
3. これを日本語で5回、英語で5回、合計10回繰り返します。順番は日本語と英語を交互にするか、くじで決めます。片方を先にまとめて行うと、順序の影響が混ざります。
4. 返答に説明文やコードブロックが付いている場合は、HTML部分だけを取り出します。取り出し以外の編集はしません。バグを直したくなっても直しません。
5. 保存するときは、run01.html のように、言語が分からない連番のファイル名にします。どの番号がどの言語かは、別の対応表に記録して、評価が終わるまで見ません。

5回という数は最低ラインです。可能なら各言語10回に増やすと、言語内の揺れがよく見えます。また、一度の依頼で返ってきたものの不具合を指摘して直させるやり取りは、この実験には含めません。最初の一発の出力だけを比べます。

記録の取り方：何を、どの単位で

記録は、機械的に数えられるものと、人が見て判断するものに分けます。

機械的に数えるもの

1ファイルごとに次を記録します。

• バイト数と行数です。生成物の規模の目安になります。
• 日本語文字の数です。画面の文言とコードのコメントの両方を含むため、あくまで目安です。
• 外部URLを読み込む記述の有無です。外部通信なしという条件が守られたかを見ます。
• alert、confirm、prompt の使用回数です。ダイアログで済ませる設計かどうかが分かります。
• <html> タグの lang 属性です。ページの言語を宣言しているか、何と宣言しているかを見ます。

手で数えると間違えるので、次の小さなHTMLを手元に保存して使えます。ファイルをブラウザで開き、保存した生成物をまとめて選ぶと、表に一覧が出ます。外部通信はせず、ブラウザ内だけで動きます。

<!doctype html>
<meta charset="utf-8">
<title>生成物の計測</title>
<input type="file" id="f" multiple accept=".html">
<table id="t" border="1"><thead><tr>
<th>ファイル</th><th>バイト</th><th>行数</th><th>日本語文字</th><th>外部URL</th><th>alert系</th><th>lang属性</th>
</tr></thead><tbody></tbody></table>
<script>
document.getElementById('f').onchange = async (e) => {
  const body = document.querySelector('#t tbody');
  body.innerHTML = '';
  for (const file of e.target.files) {
    const text = await file.text();
    const ja = (text.match(/[\u3040-\u30ff\u4e00-\u9fff]/g) || []).length;
    const ext = (text.match(/(src|href)\s*=\s*["']https?:\/\//gi) || []).length;
    const dlg = (text.match(/\b(alert|confirm|prompt)\s*\(/g) || []).length;
    const lang = (text.match(/<html[^>]*\blang\s*=\s*["']?([\w-]+)/i) || [,'なし'])[1];
    const row = body.insertRow();
    [file.name, file.size, text.split('\n').length, ja, ext, dlg, lang]
      .forEach(v => row.insertCell().textContent = v);
  }
};
</script>

この計測には限界があります。外部URLの検出は src と href の属性だけを見ているので、CSSの @import や fetch による通信は拾えません。そのため、数字が0でも安心せず、コード内を「http」で検索して目視で確かめます。

人が見て判断するもの

実際にプレイして、次の項目を記録します。

1. 起動して最後まで遊べたか。エラーで止まった、的が出ない、終了後にやり直せない、などを分けて書きます。
2. 仕様表の固定項目を満たしたか。項目ごとに「○・△・×」で付けます。
3. 画面の文言の言語です。日本語、英語、混在のどれかを記録します。混在なら、どの部分がどちらかを書きます。
4. 難易度の変化があったか。的が小さくなる、速くなる、数が増える、などを言葉で記録します。変化がないのも記録になります。
5. ゲーム名や用語の選び方です。「スコア」と「得点」、「Start」と「開始」のように、そのまま書き写します。
6. 見た目です。背景色、的の色と形、効果音の有無を短く記録します。
7. スマートフォンの縦画面で破綻しないか。的が画面外に出る、文字がはみ出す、などを確認します。

遊ぶ回数は、1作品につき最低2回にします。1回目は様子見で、2回目から記録します。ここで、ファイル名の対応表を見ずに評価することが盲検化の要になります。

結果の読み方：言語間の差と言語内の揺れ

記録が揃ったら、まず同じ言語の5回の中でどれだけ違いが出たかを見ます。日本語の5本の間で、文言の言語、難易度の変化、色の傾向がどの程度ばらけたかを確かめます。英語でも同じことをします。

次に、日本語の群と英語の群を比べます。判断の基準は次のとおりです。

• 言語内のばらつきが大きく、群の間に境界が見えない場合は、言語の影響を主張できません。単なる出力の揺れの可能性が高いです。
• ある項目が、日本語の群では5本中ほぼ同じ傾向で、英語の群では別の傾向にそろっている場合は、言語の影響を疑う価値があります。たとえば画面の文言の言語が依頼文の言語にそろう、といった形です。
• 傾向が見えても、各群が5本では偶然を除けません。10本に増やして同じ傾向が続くかを確かめます。
• 機械的な数値（行数やバイト数）は、差が出ても意味づけに注意します。日本語の文字は1文字あたりのバイト数が大きいため、文言が日本語だとファイルサイズは上がります。内容の厚みの差と混同しないようにします。

見る価値のある仮説を三つ挙げておきます。結果を予言するものではなく、記録を読むときの視点です。

1. 画面の文言は、依頼文の言語に引っ張られるのか、それとも依頼文の言語とは無関係なのか。
2. 空けておいた難易度の変化や見た目の判断に、言語ごとの偏りがあるのか。
3. 起動エラーや仕様の取りこぼしの頻度に、言語の差があるのか。

三つ目は特に慎重に扱ってください。取りこぼしは数本の違いで大きく見えやすいためです。

起こりやすい誤り

• 依頼文の情報量が揃っていない。 英語版にだけ条件が一つ多い、といった状態では、差の原因が言語なのか条件なのか分かりません。逆翻訳の確認を省かないでください。
• 途中でバグを直したり、追加で指示したりする。 1回目の出力の比較が目的なので、やり取りを続けると別の実験になります。
• ファイル名や文言から言語が分かった状態で評価する。 英語の画面のほうが洗練されて見える、といった先入観が入りやすいです。連番名と対応表で防ぎます。
• 実施日がばらける。 サービス側の更新で条件が変わる可能性があります。まとめて行います。
• 文言の言語を「差」として数える際に、依頼文の言語指定と混同する。 本実験では指定しません。追加条件で指定した場合は、別の表に分けて記録します。
• 好みの優劣を結論にする。 「英語のほうが良いゲームができる」という結論は、評価の基準が人によって違うので、この設計からは言えません。この実験で言えるのは、どの項目に差があったか、そして差が言語内の揺れを超えたか、です。
• 少数の例を一般化する。 1つのモデル、1つのお題での結果です。別のお題、別のモデルでは変わりえます。

次の行動

まず、仕様表の固定項目を自分の言葉で日本語と英語の依頼文に起こし、逆翻訳で情報量が揃っているかを確かめてください。そのうえで、各言語5回の生成を同じ日に行い、連番のファイル名で保存します。生成物を遊んで気に入ったものがあれば、直下に index.html を置いた形でアソバースに投稿できます。投稿画面の「紹介文と遊び方を作成」は選択した言語で下書きを作るので、作品内の表示言語や紹介文の言語をどう揃えるかも、仕上げの段階で確かめてみてください。