LQAとは — ローカライズQAの設計・依頼・受け入れの実務
LQA は localization quality assurance の略で、翻訳したテキストを納品ファイルの中だけでなく、実際に動くゲームの中で検査する工程です。言語QA、ローカライズQAとも呼びます。文として正しい翻訳がソフトウェアの部品としては壊れていることがあり、その逆もあるため、翻訳とは別の工程になります。
LQA と書かれていても、ビルドでの確認、ネイティブレビュアー、修正後の再テストまで含むかは明記がなければ分かりません。金額を比べる前に、どれを買うのかを確定させてください。
この記事は、LQAを実施する人ではなく、発注・設計・受け入れをする側に向けています。範囲の決め方から自動化の線引きまでを、必要になる順に扱います。
バイリンガルレビュー・実機の言語QA・機能QAは別の作業
同じ略語で呼ばれる作業は三つあります。拾えるバグも必要な人も違うので、どれを指すかを先に決めることが最も効きます。
バイリンガルレビューと実機の言語QAには、対象言語をネイティブ水準で読み、かつそのゲームを遊べるレビュアーが必要です。機能・フォーマットQAに必要なのは、ビルドを操作でき、欠落・文字切れ・文字化けに気づける人です。言語が読めなくても見えるので、社内に話者がいない言語でも自社で回せます。
この違いは見積書を読む基準にもなります。LQA と書かれていて納品物がスプレッドシートのコメント列だけなら、買っているのはバイリンガルレビューです。ビルドも近くのセーブデータも、バグの提出方法も要求されないなら、実機パスは含まれていません。三つが拾うものは次のとおり。
- バイリンガルレビュー(翻訳レビュー)。別の翻訳者が納品ファイル上で原文と訳文を突き合わせ、後述の言語面の分類の誤りを拾います。ビルドが不要なので納品当日から始められますが、画面上にしか存在しない問題は見えません。
- 実機での言語QA。同じ判断を、プレイヤーがテキストに出会う場所で行います。意味は正確だがこのキャラクターの口調に合わない語。台本では成立するが、ゲームが与える二秒では成立しない冗談。
- 機能・フォーマットQA。言い回しの良し悪しとは無関係に、文字列がソフトウェアの部品として正しく振る舞うかを見ます。対象は後述の機能面の分類そのものです。
範囲の決め方 — 固定ルート、リスクの重み付け、崩れやすい一言語
全画面を全言語で見る全数検査は、小規模タイトル以外では予算に収まりません。二言語目の途中で尽きる前に決め方を選びます。
- 固定ルートを作る。すべてのUI面、発生させられるシステムメッセージ、序盤数時間のストーリーに到達する一本道の手順書を作り、どの言語でも同じ順に通します。ルートが同一なら言語間の結果を比較できます。
- リスクで重みを付ける。避けられない箇所と取り返しがつかない箇所は全数にします。最初の一時間、チュートリアルと操作説明、ストアと課金の文言、エラーメッセージ、セーブと削除の確認、年齢表記と法務文。終盤のフレーバーや収集要素は抜き取りで足ります。
- 崩れやすい一言語だけ全数にする。レイアウトのバグは言語ではなくレイアウトの性質なので、原文から最も離れて長くなる言語が大半を露出させます。幅はドイツ語やロシア語、折り返しとフォント網羅は日本語や中国語が試します。
テストケース、端末マトリクス、擬似ローカライズと実施時期
テストケースは「メニューを見る」ではなく、到達手順付きの状態で書きます。最初の店に着く、所持金が足りない状態で購入を試す、断りのメッセージが一行に収まり通貨名が正しいかを見る、という粒度です。この形なら再テストでもそのまま使え、担当者が代わっても再現できます。
マトリクスの一軸は言語、もう一軸は描画を変えるすべての条件です。プラットフォームでフォントのフォールバックが違い、片方で出る文字列が他方では箱になります。UIスケール、OSの言語と地域設定(数値と日付の書式はゲームよりOSに従うことが多い)、コントローラとキーボードで別のボタン記号が入る箇所も軸です。全マスは不要で、すべての軸をどこかで通し、危険な組み合わせは直接通します。
実施の前に擬似ローカライズ(原文をアクセント付きの長い文字列に置き換えたビルド)を一度通します。置き換わらず原文のまま読める箇所はコードに直書きされており、切れる箇所は実際の言語ではもっと切れます。抽出の側はコードに直書きされた文字列の外し方で扱います。
提出直前にLQA週間を一つ置く形は失敗します。言語レビューの出力は書き直しなので、テキストがまだ変えられるフリーズ前に行います。機能パスの出力はレイアウトと描画のバグで、フリーズ後にしか安定しません。前に回すと、一行直すたびに同じはみ出しを再発見します。
擬似ローカライズ 実テキスト前の早いビルドで キットと用語集の送付 原文が見積もれる程度に固まった時点 バイリンガルレビュー インポート前、ファイル上で インポートと自動チェック ここから毎ビルド 実機の言語QA・機能QA テキストフリーズ後のリリース候補で 修正ラウンド テキスト変更はレイアウト問題を再び開く 再テスト チケットと、修正が触れた画面 プラットフォーム提出 手前に修正1サイクル分の余裕を残す
バグ報告テンプレート — 両方の担当者が動ける形
ローカライズのチケットは、原文か画面の特定が抜けていると「再現しない」「仕様です」で閉じられます。対象言語を読めないプログラマと、ビルドを動かせない翻訳者の両方が一枚で動ける必要があります。
- ストリングキー。修正を一行の編集に変えるのはこれです。テスターがキーを見られないなら、パスの前に直します。カーソル下の文字列のキーを出すデバッグ表示があれば、チケットごとの問い合わせ往復が一つ消えます。命名はストリングキーの命名設計で扱います。
- 原文と現在の訳を必ず両方。プログラマは現在の訳で該当箇所を探し、レビュアーは原文で修正の妥当性を判断します。
- 期待と修正案は分ける。機能バグの期待は挙動(このサイズで一行に収まる)、言語バグの期待は文言です。一つの欄にまとめると、プログラマが訳語の議論を裁く羽目になります。
- 分類と重大度は報告者が埋める。分類はチケットを翻訳者かプログラマに振り分け、重大度はリリースを止めるかを決めます。両方空のチケットは、最も文脈を持たない人が仕分けます。
- 見た目の問題にはスクリーンショット、すべてのチケットにビルド番号。ビルドがないと生きているバグと直ったバグを区別できず、再テストが二回目の全数検査になります。
タイトル: [de] 設定/音声 - 音量ラベルが切れる 言語 / ロケール: de-DE ビルド: 1.4.2-rc3 / Steam / Windows 11 / UIスケール100% 場所: 設定 > 音声 > 1行目のラベル 再現手順: 1. タイトル > 設定 2. 音声タブ 3. 1行目を見る ストリングキー: ui.settings.audio.master 原文: 音量 現在の訳: Hauptlautstärke 期待: このサイズでラベル枠内に収まる(切れない) 修正案: Lautstärke 分類: 機能 / 文字切れ 重大度: 重 スクリーンショット: 添付あり 他の発生箇所: ポーズメニュー > 音声(同じキー)
分類と重大度 — 何がリリースを止めるか
チケットは二軸で分類します。分類は誰が直すかに答え、重大度は直さずに出荷できるかに答えます。どちらの基準表もパスの前に合意します。
確立した枠組みを使うなら、よく参照されるのは MQM(Multidimensional Quality Metrics)です。正確性・流暢性・用語・文体・ロケール慣習といった次元の誤り類型に重大度を掛けて点数にします。類型は改訂されているので、閾値や重み付けを引用する前に現行の公開仕様を確認してください。
表が効くのは境界事例です。任意で読む用語集項目の文字切れは重か軽か、切れているのがキャラクター名なら答えは変わるか。分類は次のとおり。前半が言語面、後半が機能面です。
- 誤訳。原文と意味が違う。
- 訳抜けと、原文にない内容の追加。
- 用語の不統一。同じ概念に複数の訳語。
- 文体の誤り。敬語の水準やキャラクターの口調が合わない。
- 文法と表記の誤り。
- 不自然な言い回し。意味は通るが人の文章に読めない。
- 変数の差し込み順で文が成立しなくなるもの。
- 文字切れ、はみ出し、重なり。セーフエリアで切れる場合や絵との衝突も含みます。
- プレースホルダーがそのまま表示される、または壊れて値が差し込まれない。
- 文字化け。バイトは正しく、デコードの指定が誤っている状態です(文字化けの解読と復元手順)。
- 文字が空の箱になる。文字コードではなくフォント網羅の問題です(文字が四角い箱になる原因)。
- 禁則に反する改行。行頭に句読点や閉じ括弧が来る不具合が代表例です。
- ロケール書式。小数点記号、日付の順、通貨記号の位置、並び順。
- 未翻訳のまま、または原文がコピーされたままの文字列と、壊れたインラインタグ。
- 音声と字幕がずれる、または言語ごとの行数制限を超える(字幕の表示時間と行数制限)。
致命 進行不能・誤誘導・読めない
- チュートリアルの指示にプレースホルダーが露出
- 警告や購入画面で否定が落ちている
- 出荷する言語で文字化け・豆腐が出る
- ストアページに掲げた言語のUIが未翻訳
- 価格・年齢区分の表記・法務文が誤っている
重 明らかに誤っているがプレイは続けられる
- 意味が残る範囲の文字切れ
- 同じゲーム内用語が三通りに訳されている
- キャラクターに合わない敬語水準
- 日付が原文ロケールの順で表示される
軽 力量のあるレビュアーなら別の書き方をする
- 約物の全角半角、字間、より滑らかな言い回し人にしか判断できないこと、外注の線引き、毎ビルドの自動チェック
スクリプトで判定できるかどうかの境界は難易度ではなく、誰が問うても答えが一つに決まるかどうかです。
人に残るのは、そのテキストが何のためにあるかを知らなければ答えが出ないものです。正確な訳がこの場所で適切か、文化的な適合、冗談と言葉遊び、そして画面上でテキストの周りにあるもの。
自分で下せない判断は外に出します。ネイティブの文章と単に正しい文章を見分けられる人がいないなら、プロセスでは埋まりません(英語から日本語で実際に変わることが具体例です)。社内に残すのは、自動チェック、機能面の実機パス、仕分けと重大度の判断、再テスト。外に買うのは言語の判断であってテスト工数ではないので、ビルド、固定ルート、用語集、重大度の基準表、チケットのテンプレート、テキストを送る前に用意するローカライズキットを渡します。
次はいずれもそうなので、毎ビルド全文字列に回します。
- プレースホルダーの一致。同じトークンが同じ数あるか、位置指定形式ならコードが期待する順か。複数形と性別には別の規則があり、ICU MessageFormatの解説で扱います。
- 用語集の遵守。言語ごとに、承認語が使われているか、禁止語が使われていないか。
- 文字列ごとの長さ上限。Master volume は13文字でUTF-8でも13バイトですが、訳の「マスターボリューム調整」は11文字で33バイト、画面では等幅で数えて半角22桁ぶんの幅です。バイト数では収まる訳を弾き、文字数ではみ出す訳を通すので、上限は出荷するフォントでの描画幅で持ちます。
- 未翻訳の検出。訳文が原文と同一、空、または既定値のまま残っているもの。
- 双方向の一貫性。同じ原文に二つの訳があるものと、別の原文に同じ訳が当たっているもの。
- エンコーディングの妥当性、出荷フォントに無い文字、壊れたタグ、制御文字、重複した空白と行末の空白。
LQAと呼べる最小構成 固定ルート1本を、出荷する全言語で同じ順に通す 上の自動チェックを毎ビルド・全文字列に対して 出荷する言語ごとに、リリース候補で実機パス1回 ビルド番号とストリングキーが入ったチケット 誰かが見始める前に合意した重大度の基準 提出の手前に、修正1ラウンドと再テストの時間