ゲームを英語圏に公開する：最低限の翻訳と表記
遊びを届ける執筆にClaudeを使用しています。
日本語で作ったゲームを英語圏のプレイヤーに届けたいとき、真っ先に悩むのは「どこまで翻訳すればいいか」という線引きです。全文を流暢な英語に書き直す必要はありません。ゲームジャンルによっては、操作説明と主要テキストだけを整えれば、海外のプレイヤーは十分に遊べます。 大切なのは「伝わる最低限」を見極めることです。翻訳の量を増やしても、プレイヤーに届く情報が増えるとは限りません。むしろ意味の曖昧な英語が増えると、ゲームへの信頼感が下がります。この記事では、ブラウザゲームを英語圏に公開する際の翻訳範囲の判断基準と、よくある表記ミスを防ぐ手順を整理します。
この記事の目次
翻訳が必要な箇所と不要な箇所を仕分ける
まず、ゲーム内のテキストを三つに分類します。
① 必ず翻訳するもの：操作説明・ゲームオーバーやクリアのメッセージ・エラー表示。これらはプレイヤーが「次に何をすればよいか」を判断するために読みます。ここが日本語のままだとゲームが詰まります。
② できれば翻訳するもの：タイトル画面のキャッチコピー・ストーリーの冒頭数行・スコアや難易度の説明。ゲームの世界観を伝えるテキストです。パズルや反射神経系のゲームなら省略しても成立しますが、ナラティブ寄りなら優先度が上がります。
③ 翻訳しなくてもよいもの：BGMやSEのクレジット・開発後記・詳細な設定メニューのラベル（「音量」は音量スライダーの隣にあれば文脈で伝わります）。
この分類で作業量の見積もりが変わります。アクションゲームならカテゴリ①だけで10〜30文程度に収まることが多く、一日で対応できます。
最低限の英語表記で失敗しやすい4点
翻訳自体より、表記の一貫性や慣習の違いがプレイヤーの違和感につながります。以下の四点は特に確認してください。
大文字・小文字のルール
英語のUI表記には「Title Case（各語の頭を大文字）」と「Sentence case（文頭だけ大文字）」の二つの流派があります。どちらが正しいというものではありませんが、一つのゲームの中で混在させないことが重要です。Start Game と Play game が同じ画面に並ぶと、作り込みが甘い印象を与えます。ゲーム全体でどちらかに統一してください。
数字と単位の書き方
日本語では「3回」「10秒」と書きますが、英語UIでは 3 lives・10 sec のようにスペースを入れるのが一般的です。また、スコア表示の桁区切りは日本式の「10,000」と同じカンマ区切りで通じますが、小数点はピリオド（1.5）を使います。日本語版で「・」や「、」を使っていた箇所は英語向けにそれぞれ置き換えてください。
「Please」の多用を避ける
日本語の「〜してください」を直訳して Please press the button のようにすると、英語ネイティブには過剰に丁寧な印象や、場合によっては指示が曖昧に聞こえることがあります。UIのボタンラベルやチュートリアルでは Press to start・Tap to continue のように動詞で始める命令形が自然です。
フォントと文字化け
WebフォントをCSSで指定している場合、英語フォントと日本語フォントが混在する状態になります。英語版では日本語グリフを含まないフォントに切り替えると読みやすくなります。特にカスタムフォントを使っている場合、英字だけが別フォントで表示されてデザインが崩れるケースがあります。HTMLファイル内のフォント指定を英語版専用に調整するか、両言語に対応したフォントを選んでください。
機械翻訳を使う場合の確認手順
DeepLやGoogle翻訳などの機械翻訳はゲームテキストにも十分使えますが、出力をそのまま使うと不自然な表現が残ります。次の手順で品質を上げてください。
- 短い文に分割してから翻訳する。一文が長いほど誤訳や語順のズレが起きやすくなります。「矢印キーで移動、スペースキーでジャンプします」は「Use arrow keys to move.」「Press space to jump.」と二文に分けて翻訳します。
- 動詞の時制と主語を確認する。説明文では現在形・命令形が混在しがちです。チュートリアルは命令形（Press・Collect）、仕様説明は現在形（The player moves...）と役割を分けると読みやすくなります。
- 同じ単語を何と訳したか記録する。「敵」を enemy と訳したなら全箇所を enemy に統一します。foe や monster が混在すると別の意味に取られることがあります。翻訳メモをスプレッドシートで管理するのが最も手軽です。
- 英語話者の目で一度通しプレイする。自分で英語UIに切り替えてプレイし、詰まる箇所がないか確認します。英語ネイティブの知人にレビューを頼めれば理想的ですが、難しい場合はRedditのゲーム開発コミュニティや、英語フィードバックを求められるプラットフォームのフォーラムを活用する方法もあります。
ゲームページの説明文（メタテキスト）の書き方
ゲーム本体の翻訳と同じくらい重要なのが、公開ページの説明文です。英語圏の検索エンジンや配信サイトでは、ゲームタイトルと説明文が発見のきっかけになります。
説明文は最初の2〜3文でジャンル・操作・目標を伝えるのが基本です。「A puzzle game where you rotate tiles to guide light to the goal.（タイルを回転させて光をゴールに導くパズルゲームです。）」のように、ジャンル＋動作＋目的の形にすると検索にも引っかかりやすくなります。
タグやジャンルラベルには英語圏でよく使われる表現を選んでください。「アクション」は action、「パズル」は puzzle、「放置ゲーム」は idle game や clicker が一般的です。「脱出ゲーム」は escape room game または point-and-click adventure が近い概念として通じます。日本語の固有ジャンル名（弾幕シューティングなど）は bullet hell shooter のように英語圏での定着名称を調べて使います。
スクリーンショットや動画があれば、テキストより先にゲームの雰囲気を伝えられます。説明文が多少ぎこちなくても、ビジュアルでカバーできる部分は大きいです。
多言語切り替えを実装するかどうかの判断基準
「最初から日英切り替えを入れるべきか」はよく受ける質問です。判断の目安は次のとおりです。
- テキスト量が少ない（50文以下）：HTMLやJavaScript内で文字列を変数化し、言語フラグで切り替える実装が現実的です。ゲームファイルを一本化できます。
- テキスト量が多い（100文以上）：i18n（国際化）ライブラリや外部JSONファイルでの管理が安定します。ただし実装コストが上がるため、まず英語版のみ先行公開して反応を見る方法もあります。
- ストーリーが主体のゲーム：翻訳品質がゲーム体験に直結するため、量が多くても丁寧に翻訳する価値があります。逆に、反射神経や数字が主体のゲームは最小限の翻訳でも問題ありません。
ZIPファイルで公開する場合は、index.html（日本語版）と index_en.html（英語版）を分けて置き、アソバースの公開URLを英語版に設定するという方法も手軽です。ゲーム内部の言語切り替えを実装する前の試験公開に向いています。
次の行動
まずゲーム内のテキストをリストアップし、「操作に関わるか否か」で優先順位をつけてください。操作説明と主要メッセージを英訳して公開ページの説明文を2〜3文書けば、英語圏への最初の一歩として十分です。アソバースではZIPまたはHTMLファイルを直接アップロードして公開できるため、英語版を別ファイルとして用意してすぐに試せます。
参考資料
- MDN Web Docs（Web internationalization・i18n の実装ガイド）
- W3C Internationalization Activity（多言語Webコンテンツの設計指針）
