LQA(ローカライズQA)とは何か — 一つの言葉にまとめられがちな二種類のチェック

ローカライズQA、通常LQAと略される言葉は、翻訳されたテキストが正しく、かつ実際のゲームの中で使い物になっているかを確認する作業全般を指す総称です。実務では、翻訳されたテキストに関わるという共通点以外ほとんど接点のない二種類のチェックを含んでいます。言葉として正しいかどうかと、テキストとして機能するかどうかです。

この二つを区別せずに一つの作業として扱うことが、多くのLQAプロセスの効率を落としている原因です。片方はその言語を話す人間が必要で、もう片方は自動化できるし、自動化すべきものです。

言語面の品質 — 言葉として正しいか

言語面の品質は、翻訳の中身そのものに関わります。原文の意味を正確に伝えているか、対象言語として自然に読めるか、文脈にふさわしいトーンになっているか(メニューのラベルと悪役の挑発台詞では求められる文体が違います)、ゲーム内の他の箇所と用語が一貫しているか。

これらは一般的な意味で機械が検証できるものではありません。対象言語を流暢に読み、ゲームの文脈を理解し、技術的に正確な翻訳が同時にその言語のネイティブスピーカーが実際に口にしそうな言い回しになっているかを判断できる人間が必要です。

機能・フォーマット面の品質 — テキストとして機能するか

機能・フォーマット面の品質は、言い回しの良し悪しとは無関係に、翻訳された文字列がソフトウェアの部品として正しく振る舞うかに関わります。プレースホルダーは分かりやすい例で、テンプレートの変数トークンは翻訳を経てもコードが解釈できる形のまま正確に残らなければなりません。

• プレースホルダーが存在し、正しい形になっている — 変数トークンの欠落・誤った書き換え・不正な形式がない
• テキストが表示枠に収まっている — 翻訳文(多くの場合原文より長い)を描画したときにはみ出し・切れ・重なりが起きない
• エンコーディングが正しい — 対象スクリプトの文字を表示したときに文字化けや欠落グリフが起きない
• テキストの欠落がない — 未翻訳のまま、空欄のまま、あるいはプレースホルダーの値のまま表示される項目がない
• リッチテキストのマークアップが無傷である — タグのペアとネストが保たれている(詳しくは別記事で扱っています)

パイプライン上のそれぞれの置き場所

この二つのチェックはまったく異なるリソースを必要とするため、QAパイプラインの中で置かれる場所と頻度も異なります。フォーマット・機能面のチェックは低コストで機械的に判定できるため、すべての文字列に対して、すべてのビルドで自動的に実行すべきです。スクリプトがミリ秒で検証できるものに、人間のレビュアーの時間を割く理由はありません。

言語面のレビューはコストが高く、有資格者のスケジュールを確保する必要があるため、頻度を落とし、対象を絞って実施するのが理にかなっています。毎回全ファイルを見直すのではなく新規・変更された文字列を中心にし、レビュアーによって基準がぶれないよう、できればチェックリストの助けを借りて行います。

実機レビューとファイルレビュー

スプレッドシート上では完璧に読める翻訳が、画面に表示された瞬間に問題を起こすことがあります。意味は正しいが長すぎてボタンに収まらない言い回し、単独で読めば問題ないがそのシーンのトーンと衝突する用語、UIが使う特定のフォント・サイズだからこそ起きるはみ出しなどです。

実機レビュー — ファイルの中だけでなく、実際に動いているゲームの中でテキストを見ること — は、ファイルレビューでは構造的に拾えないこの種の問題を捉えます。準備にコストがかかるため、チームが投資を怠りがちな部分でもありますが、プレイヤーが実際に目にするものを反映できる唯一のレビュー方法です。

フォーマットチェックは自動化でき、言語チェックはできない理由

この境界線は恣意的なものではありません。フォーマット・機能面のチェックは、このトークンは存在するか、この文字列はこの枠に収まるか、このエンコーディングは有効か、といった構造的な比較であり、誰が確認しても答えは一つに決まります。一方、言語面の品質は、特定の文化的・物語的文脈の中での意味・トーン・自然さについての判断であり、これはまさに、その言語の中で生きている人間による判断が今なお必要な領域です。

実務的なLQAプロセスは、この区別を明確に保ちます。決定的な正解があるチェックはすべて自動化し、本当に人間が必要なチェックにだけレビューの時間を使う。そして両者を、レビュアーが変わっても時間が経っても一貫させる橋渡し役として、チェックリストを置きます。