英語対応を足したら、遊ぶ人はどう変わるのか：変化を記録する設計

見えるものと見えないものを分ける

最初にやることは、手元で観察できる指標の一覧を作り、それぞれが何を教えて何を教えないかを書き出すことです。アソバースの確認済みの範囲で整理すると、次のようになります。

• プレイ回数、分かること：作品が起動された実測回数。同じ端末・同じ作品で30分以内の再起動は重複として除かれる、分からないこと：人数ではありません。どの言語の人が起動したかは、この数字だけでは判断できません
• いいね、分かること：1アカウント1件。「好きな作品」と連動する、分からないこと：いいねをした人の使用言語は分かりません
• レビュー、分かること：1〜5点と1〜2,000文字。本文を読めば書いた人の言語や困りごとが分かる、分からないこと：書かない人の体験は見えません。件数は少なくなりがちです
• ランキング、分かること：プレイ回数・いいね数・レビュー平均で切り替えられる。評価順はレビュー3件以上から掲載される、分からないこと：順位は他の作品の動きにも左右されます

プレイ回数の言語別の内訳が見られるかどうかは、この記事では断定しません。作者向けの画面でどこまで確認できるかは、現在の案内で確認してください。内訳が見られない前提で設計しておけば、見られた場合に精度が上がるだけで済みます。

もう一つ、制約があります。英語専用のURLは現在提供されていません。そのため「英語圏向けの入口を別に配り、そこからの起動を数える」という切り分けは使えません。入口が一つである以上、言語の影響は間接的にしか読めない、というのがこの記録の前提です。

変化の問いを三つに絞る

「遊ぶ人はどう変わったか」は大きすぎる問いです。数字で確かめられる単位まで割ると、次の三つが現実的です。

1. 入口の問い：作品を開いた人が、最初の画面で迷わず操作を始められているか。
2. 継続の問い：始めた人が、最初の数分を越えて遊んでくれているか。
3. 反応の問い：遊んだ人が、いいねやレビューという形で反応を残しているか。

それぞれに、見る場所が対応します。入口はプレイ回数の推移と、レビュー本文にある「どう操作するのか分からない」という類の記述です。継続は、ゲーム自体に記録を持たせるかどうかで見え方が変わります。反応はいいねとレビューの件数と本文です。

注意したいのは、三つの問いに同時に答えようとしないことです。レビューが数件しかない作品で、反応の変化を統計的に語ることはできません。件数が少ないうちは、数字ではなく本文を一件ずつ読む作業に切り替えます。「このレビューは英語で書かれていて、操作説明に触れている」という事実を一件ずつ拾えば、それが次の更新の材料になります。

公開前にやる準備：基準線を取る

変化を読むには、変化の前の状態が必要です。英語表示を足した更新を公開する前に、次の手順で基準線を残します。

1. 日付と版を決める。 更新を公開する日付を決め、その前の日までを「更新前」とします。同じ更新に、バランス調整や新ステージを混ぜないでください。言語以外の変更が混ざると、後から原因を切り分けられなくなります。
2. 更新前の数字を記録する。 公開前の1〜2週間ほど、毎日同じ時刻にプレイ回数・いいね数・レビュー件数をメモします。表計算ソフトで、日付・プレイ回数・いいね・レビュー件数・メモの5列があれば足ります。プレイ回数は累計と日ごとの差分の両方を残すと、後で比べやすくなります。
3. 既存のレビューを読み直す。 更新前のレビュー本文に、言語や文字に関する記述がすでにあるかを確認します。たとえば、すでに英語で書かれたレビューがあれば、英語で遊んでいる人は更新前から存在していた、という手掛かりになります。
4. 自作の「最初の5分」を書き出す。 起動してから最初のプレイを終えるまでに、画面に出る文字をすべて洗い出します。タイトル、ボタン、説明文、エラー表示、結果画面です。これが翻訳漏れを探すときの一覧になります。
5. 公開後に見る日を先に決める。 公開後の1日目、3日目、7日目、14日目のように、確認日を決めておきます。数字を見る回数が多すぎると、日ごとの揺れに引きずられます。

プレイ回数は日ごとにばらつきます。更新前の数日だけで平均を取ると、その平均自体が偶然に左右されます。可能なら二週間ほどの幅を取り、曜日による差も記録に残しておくと、後の比較が安定します。

英語化で壊れやすい箇所と、手元の確認

数字の変化を見る前に、そもそも英語表示が壊れていないかを確かめる必要があります。壊れた英語表示は、遊ぶ人の変化ではなく、離脱の原因になります。壊れやすいのは、次のような箇所です。

• 文字列の連結。 日本語の「3歩進みました」は、数字と文を並べれば成立します。英語では語順も複数形も変わります。文を部品に分けて繋ぐより、数字を受け取る関数ごと辞書に入れるほうが安全です。
• ボタンの幅。 英語の語は日本語より長くなる場合があります。日本語の幅に合わせて固定した枠から文字がはみ出さないか、狭い画面でも確認します。
• 画像に埋め込んだ文字。 画像の中の文字は辞書で差し替えられません。操作説明を画像で出しているなら、そこが取り残されやすい箇所です。
• フォント指定。 日本語向けのフォントだけを指定していると、英字の見た目が意図と違うことがあります。英語表示で実際の画面を見て判断します。
• 言語を切り替えた瞬間の進行。 対局や配置の途中で言語を切り替え、進行が消えないかを確かめます。

最後の点は、公式作品の設計から読み取れる考え方でもあります。公式の13作品は、言語の変更とプレイ画面の拡大で進行を保つ作りになっています。その具体的な挙動は、気になる作品を対局や操作の途中で開いて切り替え、実際に確かめてください。

では、自作で「言語を切り替えても状態が消えない」最小の形を考えてみます。ここでは、状態を一つのオブジェクトにまとめ、描画関数が毎回それを読んで文字だけを差し替える方式にしています。

<!doctype html>
<meta charset="utf-8">
<title>言語切替の最小例</title>
<p id="msg"></p>
<button id="go"></button>
<button id="toggle"></button>
<p id="log"></p>
<script>
const T = {
  ja: { msg: n => `${n} 歩進みました`, go: "進む", toggle: "English" },
  en: { msg: n => `You moved ${n} step${n === 1 ? "" : "s"}`, go: "Move", toggle: "日本語" }
};
const state = { lang: "ja", steps: 0, switches: 0 };
const $ = id => document.getElementById(id);
function render() {
  const t = T[state.lang];
  $("msg").textContent = t.msg(state.steps);
  $("go").textContent = t.go;
  $("toggle").textContent = t.toggle;
  $("log").textContent = `lang=${state.lang} switches=${state.switches}`;
}
$("go").onclick = () => { state.steps++; render(); };
$("toggle").onclick = () => {
  state.lang = state.lang === "ja" ? "en" : "ja";
  state.switches++;
  render();
};
render();
</script>

このコードをそのまま保存して開き、「進む」を数回押してから言語を切り替えてください。歩数が残り、1歩のときだけ英語の複数形が変わることが確認できます。最下行の表示は、言語を何回切り替えたかを数えています。自作のゲームに同じ仕組みを入れれば、手元のテストで「どの画面で切り替えが起きやすいか」を観察できます。

なお、アップロードした作品の中のlocalStorageやsessionStorageは一時メモリーとして動く互換処理です。言語設定や進行を長く残したい場合は、クラウドセーブ（作品ごとにJSONで128KiBまで）の仕組みを使うかどうかを、投稿向けの案内で確認してください。また、サイトの日本語／英語設定を作品側がどう受け取れるかも、SDKの案内で確認してください。

作品名と紹介文は、別に整える

ゲームの中の文字を英語にしても、作品ページの文字は別の話です。サイトの日本語／英語の切り替えは、作者が入力した作品名や紹介文を書き換えません。日本語で書いた紹介文は、英語表示で閲覧する人にも日本語のまま見えます。

つまり、ゲーム内を英語にしただけでは、作品を開く前の判断材料は日本語のままです。紹介文の中に英語の一文を添えるか、遊び方を短い英語でも書くかは、作者が決めることになります。

投稿画面の「紹介文と遊び方を作成」は、公開済みURLまたは本人の検証済みアップロードを読み取り、選択した言語で下書きを作ります。「この文章を使う」を押したときだけ反映され、生成の操作だけで公開されることはありません。下書きは出発点にして、操作名や用語が実際のゲーム内の表示と一致しているかを、自分の目で確認してください。利用には、利用者ごとに1時間3回、全体でUTC1日20回という上限があるため、続けて何度も試す前提では計画を立てないほうが安全です。

この紹介文の更新も、変化の記録では「変更」の一つです。ゲーム内の英語化と同じ日に公開するのか、日を分けるのかを、手順1の段階で決めておきます。同じ日に出すと、どちらが効いたかは切り分けられません。切り分けたいなら、日を分けてください。ただし、日を分けるほど記録の期間は長くなります。

結果の読み方

公開後、決めた確認日に数字を見ます。読み方の判断基準を、先に書いておきます。

• プレイ回数が増えた場合。 更新前の幅（日ごとのばらつき）の中に収まっているなら、言語の効果とは読めません。ばらつきを明らかに外れ、しかも他の変更を混ぜていないなら、言語が関係した可能性を考えます。それでも断定せず、「可能性がある」にとどめます。プレイ回数は人数ではないため、一人が何度も遊んだ影響も含みます。
• プレイ回数が変わらない場合。 変化なしは失敗ではありません。紹介文が日本語のままで、英語表示で閲覧する人に届いていないのかもしれません。あるいは、英語で遊ぶ人はそもそも少ないのかもしれません。次の一手は、数字を増やすことより、原因の候補を一つずつ潰すことです。
• レビューに英語の本文が現れた場合。 点数よりも本文を優先して読みます。操作の説明に触れているなら入口の問題、用語に触れているなら翻訳の質の問題、内容に触れているなら遊びそのものへの反応です。
• レビューやいいねが増えない場合。 件数が少ない時期は、比較に使えません。評価順のランキングはレビュー3件以上から掲載されるため、それまでは順位での比較自体ができません。

起こりやすい誤りは三つあります。一つは、更新直後の一日の増減を過大に読むことです。二つ目は、更新前の基準線を取らないまま比べることです。三つ目は、言語以外の変更を同時に入れてしまうことです。いずれも、記録の設計で防げます。

英語の翻訳が機械的な直訳のままだと、遊ぶ人が戸惑う可能性があります。自分以外の目で確認することも、記録の一部です。英語に慣れた知人がいれば、ゲームを開いた最初の5分を、横で黙って見せてもらう方法があります。口を挟まず、止まった場所だけをメモします。これは数字では拾えない種類の情報で、レビューが少ない時期の代わりになります。

次の行動

まず、いま公開している作品のプレイ回数・いいね・レビュー件数を、今日の日付で表に書き留めてください。次に、上のコードを参考に、言語を切り替えても進行が消えないかを自作で確かめます。英語化の更新は、他の変更と混ぜずに出すと、後で変化を読むときに迷いません。