自作ゲームの英語版の作り方 — 何をどの順番でやるか

どこかの時点で、自分のゲームに英語版を用意しようと思ったはずです。プレイヤーから「英語版はありますか」というコメントが来たのかもしれませんし、ストアページを見に来ている人の国を眺めていて、その大半が日本語を一文字も読めないことに気づいたのかもしれません。いずれにせよ、いま知りたいのは実務的なことのはずです。具体的に何をすればいいのか。

結論から言うと、英語版を作る作業は五つの段階からなる小さなプロジェクトで、翻訳はそのうちの一つでしかありません。残りの四つ — どこまでを訳すか決める、翻訳できる形でテキストを取り出す、訳文をゲームに戻す、動くゲームの中で確認する — に作業量の大半と、失敗のほぼ全部が集まっています。

この記事は個別の深掘りではなく地図です。段階ごとに何を判断する必要があるのかを並べ、順番を示します。この一連の作業をまとめて「ローカライズ」と呼びます。翻訳そのものに加えて、別の言語のプレイヤーがちゃんと遊べる状態にするための周辺作業まで含んだ言葉です。他の用語も、出てきたところで一言ずつ説明します。

文字が入っている場所を全部数える

翻訳から始めるのではなく、棚卸しから始めます。ここはほとんどの人が自分のゲームを過小評価するところです。「テキスト」と言われて思い浮かべるのは会話文で、それ以外に文字が出てくる場所が何十とあることは忘れられがちだからです。

• メニュー、設定画面、ボタン、確認ダイアログ
• 会話文、地の文、キャラクターがしゃべるもの全部
• アイテム名・スキル名・敵名・地名と、そのすべての説明文
• チュートリアル、ヒント、ツールチップ
• エラーメッセージやシステムメッセージ(ほとんど表示されないものを含む)
• 実績の名前と説明 — これはプロジェクト内ではなくストア側に入力するもの
• クレジット、権利表記、タイトル画面
• 画像に描き込まれた文字。ロゴ、看板、UI素材、テクスチャに焼き込んだもの全部
• ストアページ、アップデート告知、SNSの投稿文

この中で二つだけ、先に注意しておく価値があります。画像に焼き込まれた文字は、どんなツールからも文字数集計からも見えません。だから発見が遅れます。たいていは英語ビルドを誰かが遊んでいて、世界の真ん中の看板だけ日本語のままだと気づく、という形で見つかります。もう一つは実績で、これはプロジェクトのファイルではなくプラットフォームの管理画面側にあるため、初めての英語対応で最も忘れられる項目です。

全部を訳す必要はありません。ただし、どれを外すか決める前に、全部の存在を把握している必要はあります。意図して絞った範囲と、たまたま抜け落ちた範囲は、プレイヤーからの見え方がまったく違うからです。

テキストをゲームの外に取り出す

翻訳者はあなたのプロジェクトの中では作業できませんし、させるべきでもありません。必要なのはファイルです。ゲーム内のすべての文が、意味の通る順番で並んでいて、その隣に訳文を書き込む列が空いている一枚の表。

そのファイルを作るのに一晩で済むか二週間かかるかは、たった一点で決まります。テキストがコードやシーンの中に直接書かれているか、別の場所にまとめてあるか。関数の引数や会話ノードに直接打ち込まれた文字列を「ハードコード(直書き)」と呼びます。直書きされたテキストは書き出せず、数えられず、実行中に差し替えることもできません。これを外に出す作業は、初めての英語対応で最も大きなエンジニアリング作業になるのが普通で、しかも翻訳の後ではなく前にやらなければならない作業です。

目指す形は単純です。コード側は短い名前で行を指し示し、その名前が各言語で何を意味するかは別のファイルが持ちます。

// Before — 文字がコードに溶接されている
showMessage("所持金が足りません。");

// After — コードは行の名前を呼び、文字はファイルが持つ
showMessage(t("shop.error.not_enough_gold"));

// strings.csv
key,ja,en
shop.error.not_enough_gold,"所持金が足りません。","You do not have enough gold."
ui.button.confirm,"決定","Confirm"

主要なエンジンにはこの仕組みが用意されていて、自作するより既存の仕組みに乗るほうが確実です。Unity には文字列テーブルを中心にした Localization パッケージがあり、Unreal には String Table と FText を軸にしたローカライズの仕組みがあり、Godot は CSV や PO ファイルから翻訳を読み込めます。RPGツクールMZ はデータベースを JSON で保持しているので、外部ツールから読める形になっています。ただしメニューの位置やボタン名はバージョンで変わるので、数年前の解説記事ではなく、使っているエンジンの公式ドキュメントのローカライズの章を読んでください。

同じ作業のついでに、もう一つ直しておきたい癖があります。コード側で文を継ぎ足して組み立てるやり方です。アイテム名の後ろに「を手に入れた!」という断片をつなげる書き方は、日本語では動きますが多くの言語で壊れます。語順が言語によって違いますし、翻訳者のもとには意味を成さない断片だけが届くからです。文全体を一行にして、中に差し込み位置の目印を入れておけば、翻訳者は文全体を見たうえで、その言語の文法が要求する位置に目印を動かせます。

誰が訳すかを決める

ここに唯一の正解はなく、お金・時間・許容できるリスクの三つの交換があるだけです。それぞれを正直に書くとこうなります。

• 自分で訳す。本当に英語力があるなら安くて速い方法です。ただし自分の癖は自分では聞こえません。自分には自然に思える文が、ネイティブには微妙にずれて読める — これは自己診断がとても難しい種類の問題です
• 機械翻訳・AI翻訳にかける。ほぼ無料で一瞬、下訳としては実用的です。そしてゲームで一番難しいところで正確に失敗します。見たことのない固有名詞、前後の文脈がない一行、冗談、文字数が決まっている枠。放置すると、一文ずつ読むと問題ないのに全体としては間違っている、という状態の訳文ができあがります
• 英語ができる友人・家族に頼む。自然かどうかの判断は機械よりずっと信頼できます。ただしバイリンガルであることと翻訳できることは別の技能です。ゲームテキストには作法があり、友人には「ここは訳すのではなく書き換えるべきだ」と言える立場も知識もありません
• ゲームを扱うフリーランス翻訳者に依頼する。本気の販売を考えるなら標準的な選択肢です。作法を知っていて、こちらに質問を投げてくれて、何千行にもわたってキャラクターの口調を保てます
• 翻訳会社に依頼する。分量が大きい、複数言語を同時に出す、締切があるなど、翻訳そのものより進行管理のほうが本題になったときに効いてきます

初めての英語版なら、現実的には組み合わせになることが多いはずです。リスクの低い大量部分は機械翻訳やAIで下訳を作り、プレイヤーが最もよく読む部分 — 冒頭一時間、ストアページ、キャラクター性が出るところ — は人が訳し、公開前に全体をネイティブの目で通す。

誰に頼むにせよ、文脈を渡してください。誰のセリフか、どこに表示されるのか、何文字入るのかが一切書かれていない、切り離された行だけの表 — これが「誰のせいでもない誤訳」の最大の原因です。キャラクター一覧、スクリーンショット数枚、文字数制限のメモ、そして遊べるビルド。これらは、それがない状態で予算だけ増やすより結果に効きます。

ゲームに戻して、実際に遊ぶ

訳文をビルドに戻す作業自体は、取り出しの段階をきちんとやってあれば単純です。列が埋まったファイルが返ってきて、それを読み込ませるだけ。本当の作業はその後にあります。

表計算ソフト上で訳文を読んでも、それがゲームの中でどう振る舞うかはほとんど分かりません。新しい言語でゲームを遊び、テキストファイルからは見えない問題を探す工程には名前があります。ローカライズQA、略して LQA です。ここを飛ばすことが、翻訳自体は悪くないのに初めての英語版が雑に見えてしまう最大の理由です。

• 枠からはみ出す・切れる・読めないサイズまで自動縮小される文字。同じ内容でも英語は日本語より横に長くなることが多く、日本語のテキストに合わせて組んだUIがそのまま収まるとは限りません
• 直書きのまま拾い漏れて、日本語で表示されたままの行
• 差し込み位置の目印が画面にそのまま出ている、あるいは順番が入れ替わって別の値が入っている箇所
• 変な位置で改行される行と、フォントに文字が無くて四角い豆腐になる箇所
• 単体では正しいのにその場所では間違っている訳。動詞だったボタンが名詞になっている、上の質問文と噛み合わなくなった「はい/いいえ」など

英語が苦手でも、この確認は自分でやってください。レイアウトの崩れは一語も理解できなくても目で見えますし、それが不具合のかなりの割合を占めます。そのうえで、英語を普通に読める人に、少なくとも冒頭一時間と到達できるメニュー全部を触ってもらいます。

ストアページも訳す — おそらく最初に

大多数の人が読む唯一のテキストはストアページです。ページを読めない人はゲームまで辿り着きません。ゲーム本体を丁寧に英語化したのに、その手前のストアページが日本語のまま、というのは奇妙な着地点です。

しかもこれは全工程で最も安い項目です。検索結果やおすすめ枠に出る短い説明文、長い説明文、スクリーンショットの説明、そして可能なら英語UIのスクリーンショット。合わせても数百語程度です。

ストア側では対応言語の申告も求められます。多くの場合、インターフェース・字幕・音声が別々のチェックになっています。ここは正直に。機械翻訳しただけの言語を「対応」と申告すれば必ず露見しますし、露見する場所はレビュー欄です。結果として、その言語に対応していなかった場合より評判を落とします。

ここには実は戦略が隠れています。ゲーム本体に一切手を付けず、ストアページだけ英語化するのは、英語圏のプレイヤーが自分の作ったものを欲しがるかどうかを確かめる最も安い方法です。ページを公開した後の英語圏からのウィッシュリスト・アクセス・フォローは、それまで持っていなかった需要データであり、本編を翻訳するかどうかを自分の勘で決めるよりはるかに確かな判断材料になります。

今週やることの順番

以下は、途中で止めてもそこまでが無駄にならない順に並べてあります。最初の時点で「英語版を完全に出す」と決断している必要はありません。

• 一晩かけて棚卸しを書く。画像内の文字と実績を含めて、テキストがある場所を実際に列挙する
• いまテキストを全部書き出せるかを確かめる。できないなら、それが最初のプロジェクト。翻訳するかどうかに関係なくやる価値があります
• ストアページを訳して公開する。そのあと数週間、国別の数字を眺める
• 翻訳する前に原文を整える。継ぎ足しで組み立てている文をほどき、文字数制限をメモし、翻訳者が質問しそうなことを書き出しておく
• 本編を訳す。プレイヤーが最初に見るところ — オープニング、メニュー、チュートリアル — から
• 通しプレイでの確認時間を最初から予定に入れる。日本語版と英語版の両方で。これは仕上げの飾りではなく、受け取られ方を決める工程です