AI翻訳はどこで失敗するか — ローカライズファイルの構造的な落とし穴

AI翻訳は、対象言語として自然で流暢な文を生成するように最適化されています。だからこそローカライズファイルの中では厄介です。壊れた翻訳であっても、文としては整った形で出てくるため、出力単体を見ても何もおかしく見えません。どこがどう壊れうるかをあらかじめ知り、意図的に確認する必要があります。

以下はどれも特定の製品の話ではありません。これらのシステムが最適化しているもの(対象言語の文としての流暢さ・もっともらしさ)と、ローカライズファイルが実際に必要とするもの(地の文以外の要素の完全な保持)のズレから構造的に導かれる失敗パターンです。

プレースホルダーと変数

ローカライズ文字列には{playerName}や%d、{0}のような、実行時に置き換わるプレースホルダーが含まれます。文全体を翻訳するモデルには、プレースホルダーを不可侵のトークンとして扱う義務はありません。対象言語として自然な位置に語順を入れ替えたり、綴りや大文字小文字を変えたり、まれに文の意味上冗長に見えると判断して丸ごと落としたりすることがあります。

原文: "You found {itemName} x{count}!"
リスク: "{itemName}を{count}個見つけた!" -> プレースホルダーの順序が入れ替わる、
        あるいは長い文の中で片方が黙って消える

マークアップ・タグ

文字列内に埋め込まれた装飾タグ(太字、色指定、改行タグなど)は文の意味そのものではありませんが、モデルが書き換えている文の内部に存在します。タグの位置が意図した単語を囲まなくなる、開始タグか終了タグの片方だけが消える、属性値が変わる、といったことが起こり得ます。翻訳結果を文章として読むだけではタグ構造の破損には気づけません。

書式・空白文字

UI上の余白調整に使われる先頭・末尾の空白、複数行セリフ内の意図的な改行、ノーブレークスペース、句読点の全角・半角の一貫性は、いずれも「文の意味」の外側にある情報です。自然な出力を目指すモデルにとって、これらを保持する義務は特にありません。

長いファイルでの用語のぶれ

1文ずつ独立して翻訳する場合、3000行前に同じ用語をどう訳したかをモデルは記憶していません。長いファイル全体で見ると、本来固定であるべき用語 — アイテム名、ステータス名、繰り返し出るUI語彙 — が途中から別の(それ自体は妥当な)訳語に切り替わることがあります。各セグメントが独立に生成される以上、これは自然に起こります。1文ずつ読むと問題なく見え、全体として見ると用語がばらついている、という形で現れます。

流暢だが文脈を読めていない

文字列単体を翻訳するモデルは、それがボタンラベルなのか、セリフの完全な一文なのか、ツールチップなのかを知りません。多くの言語ではこの文脈によって正しい文法形が変わります。短い命令形のUIラベルが、完全な一文として返ってくることがあります。一人称のセリフが、ナレーターのような中立的な語り口で返ってくることもあります。訳文自体は流暢でも、その場所には合っていません。

未翻訳の素通りと敬語レベル

一部の行は変更されずにそのまま通過することがあります — 翻訳ではなくコピー — 原文がたまたま対象言語として成立しうる文字列(短い文字列、数字や記号だけの文字列、外来語など)に見える場合、それは一見もっともらしく通ってしまいます。また、日本語のように敬語レベルが文法化されている言語では、行ごとに丁寧語とくだけた言い方が入り混じったり、同じファイル内で他の箇所で確立されたキャラクターの人格と矛盾する丁寧さで訳されたりすることがあります。

機械で検出できる範囲・できない範囲

ここが実務上の線引きです。プレースホルダーの有無・個数・種類、タグの開始終了の対応関係は機械的に検証可能です。原文と訳文のプレースホルダー集合を1行ずつ突き合わせるだけなら、どちらの言語も理解する必要すらありません。書式や空白文字の差異も、文字列同士の比較として同様に検出できます。

一方で、用語の一貫性、トーンや敬語レベルの整合、その訳がUI上の場所に合っているかどうかは、文字列だけからは機械的に判定できません。参照できる用語集があるか、対象言語と文脈を理解する人間の読み手が必要です。自動チェックは「どこを見るべきか」を絞り込んでくれますが、その読みそのものの代わりにはなりません。

• 機械的に検出できる: プレースホルダーの欠落・改変、タグの破損や不整合、空白・改行の差異、原文と完全一致する未翻訳行
• 人間または用語集による確認が必要: 用語のぶれ、敬語・トーンの一貫性、UI上の場所にトーンが合っているか、意味が実際に保たれているか