ライブサービス運用のための多言語対応

発売日が一度きりのゲームは一度だけ多言語対応を行い、そのあとは基本的に既存のものを維持する。ライブサービス型のゲームにはその安定が訪れない。イベント、シーズン、コンテンツ配信のひとつひとつが、それぞれ独自の締切を持つ小さな多言語対応プロジェクトであり、しかも前のものと重なり合っていることも多い。一度きりの発売のために作られたプロセスは、繰り返されるリリースカレンダーの前ではもたない。最初から「繰り返される」ことを前提に設計する必要がある。

テキストフリーズの期間と、それが破られたときの対応

テキストフリーズとは、リリース前のある時点でテキストの変更を止め、翻訳が対象にできる安定した状態を作ることだ。ライブサービスタイトルでは、このフリーズを大型リリースだけでなく、すべてのコンテンツ配信の前に実施する必要がある。つまりチームはフリーズを「推奨」ではなく実際のカレンダーとして守らなければならない。

それでもフリーズ後にテキストが変わることはある — バグ修正で文言が変わる、デザイン側が土壇場で名前を変える、といったことだ。その場合の正直な選択肢は限られる。次の翻訳パスまでそのテキストを原語のまま保持する、締切に余裕があれば翻訳者に小さな修正バッチを緊急対応してもらう、あるいはその一文だけ未翻訳で出荷される短い期間を受け入れる、のいずれかだ。やってはいけないのは、テキストを黙って変更し、翻訳が引き続き対応していると思い込むことだ。

翻訳が部分的な状態は失敗ではなく、実際に起こる本番状態

ライブサービスのペースでは、翻訳のレビューが完全に終わる前にコンテンツが本番環境に届いたり、ビルドを出荷しなければならない時点である言語がまだ作業中だったりするのは、例外ではなく通常のことだ。これを毎回緊急事態として扱うとチームが消耗する。あらかじめ想定された状態として扱えば、後手で反応するのではなく、部分的な状態がどう見えるべきかを意図的に決めておける。

リリースに合わせてローカライズファイルをバージョン管理する

ローカライズファイルは、ゲーム本体とどちらか一方だけが変更された瞬間からずれ始める。ローカライズファイルのバージョンをゲームコードと同じリリースやビルドの識別子に紐づけておけば、インシデント発生時の基本的だが重要な問いに答えられるようになる — 今実際に本番で使われている翻訳はどれで、それは今のビルドと一致しているか、という問いだ。

release-2026.08.1/
  strings.en.json
  strings.ja.json
  strings.ko.json   # 部分対応 — イベント名のみ。同じバージョンで管理

言語が混在したままイベントを出さないために

ライブサービスのチームが最もよく遭遇する失敗パターンは、UIの一部だけが翻訳され、一部が未翻訳のままイベントが公開されることだ — バナーは英語のまま、アイテム名は未翻訳、というように。同じイベントの異なる部品が別々のスケジュールで書き出され、翻訳され、取り込まれた結果として起こる。解決策は技術的なものではなく、手続き上のものだ。

• 一つのイベントのテキストは複数のファイルが別々に届く形ではなく、一つの締切を持つ一つのバッチとして扱う
• フリーズの前に、そのイベントがどの言語で出荷され、どの言語を意図的に見送るかを決め、その決定をリリース当日に発見させるのではなく事前に周知する
• リリース前に、書き出したテキストファイルだけでなく、出荷する各言語の実際のビルドを確認する
• ある言語が締切に間に合わない場合、そのイベントは原語のまま出荷するのか、完全に見送るのかを明示的に決める。目に見える形で選ばれた欠落は、意図せず起きた欠落とはプレイヤーへの印象がまったく違う

実際に持っているカレンダーに合わせて設計する

ここで言いたいのは「プレッシャーの中で速く動く」ことではない。ライブサービスゲームの多言語対応の作業量は無限に繰り返されるという前提を受け入れ、カレンダー上のフリーズ日、遅れた変更への決まった対応、バージョン管理されたファイル、イベントごとの明示的な言語別出荷判断といったプロセスを、一度きりではなく数週間おきに回し続けられる形で設計することだ。