個人開発でAI翻訳を使う — 事故らないゲーム翻訳の手順
ゲームは完成した、翻訳の予算はない、けれど「英語版はありますか」というコメントが少しずつ増えてきた。現実的に手が届くのはAI翻訳だけで、おそらくすでに何行かをチャット画面に貼り付けて、返ってきた結果を眺めたことがあると思います。ちゃんとした英語に見えた、という感想も含めて。
問題はまさにそこにあります。AI翻訳の出力は、正しくても正しくなくても「完成しているように見える」からです。そして対象言語が読めない開発者には、間違いが自分から名乗り出てくる瞬間がありません。あなたが丁寧な挨拶だと思っている一行が、大人のNPCに幼児へ話しかけるような口調で話しかけている可能性があり、それを知るのはレビューで指摘されたときです。
これはAI翻訳を使うなという話ではありません。AI翻訳を併用して出している小規模タイトルはいくらでもありますし、プレイヤーがそれを受け入れている例も多くあります。荒れる作品とそうでない作品を分けているのは、たいていモデルの性能ではなく、その周りの手順です。始める前に何を決めておくか、モデルに絶対に触らせないものは何か、出す前に全行で何を確認するか。以下は、実際に必要な順番で並べた手順です。
AIに訳させるもの、絶対に触らせないもの
あなたのテキストは一枚岩ではありません。一行も訳し始める前に、「間違えたときにどれだけ高くつくか」で分類してください。ここで決めた優先順位が、あとから限られた時間とお金をどこに使うかを決めます。
メニュー項目、システムメッセージ、アイテム名、設定画面は最も安全な部類です。繰り返しが多く、話者に依存せず、語の選択を間違えても文脈で気づきやすい。この部類の本当のリスクは意味ではなく長さで、日本語では収まっていたボタンが訳したとたんに溢れます。
物語テキストはその逆です。会話、掛け合い、冗談、そして二人のキャラクターの関係性が表れている台詞。ここがAIの「もっとも説得力のある失敗」が起きる場所です。文法的にきれいな文章のまま、キャラクターの個性が均されて誰でもない声になったり、どちらが敬意を払っている側なのかが入れ替わったりします。数少ない人のレビュー予算を取っておくべきなのは、この部類です。
そしてもう一つ、そもそも文章ではなく、可能なら送らないほうがよいものがあります。
- プレースホルダーと変数 — {name} や %s や [count] は一バイトも変わってはいけない
- エンジンが解釈するリッチテキストタグ(色・サイズ・ルビなど)
- キー列・識別子 — これは中身ではなく住所であり、書き換えられた瞬間その行はビルドから静かに消える
- 約束事を含む法務・ストア向けの文言 — 返金に関する記述、年齢レーティング用のコンテンツ記述、課金まわり
最初のプロンプトより先に用語集を作る
訳し始める前にできることの中で、費用対効果が最も高いのは「訳がぶれてはいけない語」を書き出すことです。キャラクター名、地名、アイテム名、スキル名、その作品固有の造語、そしてスタミナ・セーブスロット・パーティといったシステム用語。それぞれに一言の説明を添えてください。説明のない固有名詞は、人間の翻訳者にとってと同じくらい、モデルにとっても曖昧です。
これは後回しにできない作業です。長いファイルを訳させるとモデルは必ずぶれます。同じスキル名が数千行の中で三通りに訳され、しかもどれも単体では間違っていない、という状態になります。あとから語彙を決めるのは、用語集を適用しているのではなく、読めない言語のテキストに対して置換をかけているだけです。
用語集はテキストの隣に小さなファイルとして置き、プロンプトに貼り付けられて、あとから検索もできる形式にしておきます。素のCSVで十分です。
原文,訳語,種別,メモ カエデ,Kaede,キャラクター,主人公。10代女性。くだけた口調 虚ろの街,Hollow Reach,地名,第3章の廃墟都市。訳語を固定する 魂結び,Soulbind,スキル,仲間2人を繋ぐプレイヤースキル スタミナ,Stamina,システム,HPの下に表示されるゲージ
翻訳者なら聞いてくるはずの文脈を渡す
単体の文字列は、自分のプロジェクトの中に何年もいると気づかなくなるほど曖昧です。「開く」はメニューを開くのか、ドアを開けるのか、店を開くのか。「閉じる」はボタン名なのか動作なのか。「戻る」は画面遷移なのか物理的に引き返すのか。モデルはこれを推測するしかなく、しかも流暢に推測します。
解決策は安上がりです。書き出すデータに文脈の列を足し、テキストと一緒に渡すだけです。話者、その行が出る画面やシーン、収まるべき最大文字数、意味が自明でない場合の一言メモ。いま使っている書き出し形式にこれを置く場所がないなら、訳す前に直す価値があります。人間の翻訳者に依頼する場合でも、まったく同じ情報を求められるからです。
加えて、作業を始めるたびに短いプロジェクト説明を最初に渡します。ジャンル、トーン、想定プレイヤー、ゲームがプレイヤーに対してどれくらい丁寧に話すか、そしてすでに決めてある言語ごとの方針。英語なら二人称の距離感、ドイツ語やフランス語なら親称と敬称のどちらを使うか。日本語から訳す場合、原文にある敬語の階層は英語にはそのまま存在しないので、「この関係をどう表すか」を先に決めておかないと、モデルが毎回別の答えを出します。
key,原文,話者,画面,最大文字数,メモ ui.btn.close,閉じる,-,設定,8,ボタン名 ch01.kaede.012,いくよ!,カエデ,戦闘開始,40,仲間への掛け声。強気 item.086.desc,ひび割れたレンズ。,-,インベントリ,60,フレーバー。少し物悲しい
往復を「作業」ではなく「処理」にする
AI併用のローカライズで実際にプレイヤーまで届いてしまう不具合は、たいてい翻訳品質の問題ではありません。往復の事故です。行が消える、行が結合される、順番が入れ替わる、キーが書き換えられる、引用符の扱いが変わる、エンジンが必要としていた末尾の空白が削られる。どれも翻訳そのものが間違っている必要すらありません。
ですからモデルとのやりとりは、会話ではなくデータ変換として扱ってください。各行にキーを付けて送り、キーをそのまま返させる。返ってきた行数と送った行数を照合できる程度の単位に分割し、数が合わないバッチは手で直さずまるごとやり直す。送ったのと同じ機械可読な形で出力させ、チャット画面から一行ずつコピーして最終ファイルを組み立てることは絶対にしない。
そして、頼んでいない親切に注意してください。モデルは原文の誤字を直したり、直線的な引用符を約物に変換したり、プレースホルダーの書き方を「より標準的な」形に揃えたり、開いていない閉じタグを足したりします。どれもビルドに入るまで表面化しません。
毎回のバッチに含める指示:
- 行数と順序を送ったとおりに保つこと。
- key列はそのままコピーすること。
- { } や < > の中身は空白も含めて一字も変えないこと。
- 行の追加・結合・分割・並べ替えをしないこと。
- 原文列を修正・書き換えしないこと。
- 訳せない行はそのまま返し、備考列に理由を書くこと。
とくに高くつく4つの失敗パターン
AIの間違いは、すべてが同じ重さではありません。小規模タイトルで実際に痛手になるのは主に4種類で、それぞれ壊れ方の仕組みが違います。
プレースホルダーと変数は、モデルがそれを訳してしまったとき、順序を入れ替えたとき、前後の空白を変えたときに壊れます。表計算ソフト上では問題なく見え、そこに到達したプレイヤー全員の画面に {playerName} という文字がそのまま表示されるか、書式処理が実行時に落ちます。
固有名詞は、モデルがそれを固有名詞だと認識しなかったときに壊れます。主人公の名前が九割の行では名前のままなのに、残りで普通名詞として訳される。プレイヤーにはバグではなく「雑な仕事」として映ります。
長さは静かに壊れます。日本語から英語やドイツ語に訳すと文字列は伸びやすく、レイアウトに収まっていたラベルが溢れる、切れる、ボタンを画面外へ押し出す。テキストファイルの中には何の異常も現れません。
そして口調です。英語から日本語に訳す場合、モデルは全行について敬語のレベルを選ばなければならず、文脈がなければ無難なところに落ち着きます。その結果、威圧的な敵役から粗野な傭兵まで全員が同じ丁寧な口調で話す、という均一化がスクリプト全体で起きます。逆方向でも同じことが起きていて、日本語で書き分けていた一人称や語尾の差が、英語では消えます。
全行を機械的に検査し、人の目は効く場所に使う
AI出力にはひとつ厄介な性質があります。均一ではないことです。腕のよい翻訳者は安定して腕がよいので、抜き取りで数十行読めば残りについてもある程度のことが言えます。モデルは、二百行の見事な訳文の中に、変数を落とした一行を混ぜてくることがあり、両者を見分ける手がかりは文面にありません。きれいなサンプルが、以前ほど多くを保証してくれなくなったということです。
幸い、前節の失敗のうち機械的な部分は、全行に対して自動で確認できます。半日あれば書けるスクリプトでも、かなりの範囲をカバーできます。各行について原文と訳文のプレースホルダーの集合が一致しているか。タグが対で開閉しているか。訳文が原文とまったく同じ行(未翻訳の素通り)がないか。記録しておいた最大文字数を超えている行がないか。原文ファイルのキーがすべて訳文ファイルにあり、増えてもいないか。
そこまでやると残るのは判断の部分で、そここそ使えるお金や人の好意を投じる場所です。優先順位は、まずストアページ。分量が短いのに、大半の人が読む唯一のテキストだからです。次に最初の30分のプレイ体験。レビューの評価はここで決まります。それからキャラクターの声が出る箇所、最後にエラー・購入・セーブデータ関連のメッセージ。誤解がプレイヤーの実害になる場所です。
ネイティブに見てもらえるときは、表計算のシートを読ませるのではなく、実際にプレイしてもらってください。ここまでに挙げた失敗の半分は、セルの中では見えず、画面の上では一目でわかります。そして公開後は、おかしな訳文を報告できる窓口を分かりやすく用意しておくこと。フォームでも、コミュニティのチャンネルでも、固定投稿でも構いません。報告された行を次のパッチで直すゲームは、放置するゲームとはまったく違う扱いを受けます。