AI翻訳時代に「サンプリングチェック」が機能しなくなる理由
すべての行を読む余裕がないとき、サンプリング(抜き取り)チェックは合理的な手法です。いくつかの文字列を選んで丁寧に読み、問題がなければ残りもそのまま出す。ほとんどのローカライズチームが何らかの形でこれをやっていますし、長らくそれで十分機能してきました。ただ、サンプリングが実際に証明しているのは「そのファイル全体」ではなく、「品質はファイル内でほぼ均一である」という前提そのものです。この前提が崩れた瞬間、きれいなサンプルが持つ意味は、みんなが思っているものとは違ってきます。
この前提は、ファイル全体を一人の熟練翻訳者が訳している場合には、そこそこ成り立っていました。一人の翻訳者のスキルや集中力や判断力は、同じ作業セッション内で行ごとに激しく揺れ動くことは普通ありません。ファイルの真ん中から抜き取ったサンプルは、読んでいない行の妥当な代理指標になります。機械翻訳やAI翻訳の出力は、これと同じようには振る舞いません。
AIの出力が人間の出力ほど「均一」でない理由
人間の翻訳者はファイル全体を通してコンテキストを保持します。3行前のキャラクターの口調を覚えていますし、ある用語が既に決まっていることを知っていますし、文がゲームの文脈に合わないことにも気づきます。一方AIシステムは、使われ方によって、文字列ごとに参照できる周辺文脈の量が違ったり、用語集の適用がファイル内で一貫しなかったりします。そして、流暢で自信ありげな一文でありながら、与えられたその行にはただ単に合っていない、ということが起こり得ます。
これは「機械翻訳のほうが平均的に劣る」という主張ではありません。ばらつき(分散)についての話です。調子の悪い翻訳者でも、翻訳者らしい訳し方は崩れません。しかしAIモデルに短い・曖昧な・文脈依存の強い文字列を訳させると、単体で読めば完璧に自然に見えるのに、実際にそれが使われる場面では間違っている、ということが起こります。ランダムに10行読んでも、11行目については何も分からないのです。
帰結: きれいなサンプルが証明する範囲は昔より狭い
品質が文字列ごとに激しく揺れ得るなら、サンプリングはサンプルにした文字列についてしか教えてくれません。一人の一貫した翻訳者のときのように、そこから外挿できません。人間翻訳のファイルで使っていたのと同じ抜き取り比率をそのまま使い続けているチームは、気づかないうちに、リスクのうちどんどん小さくなる割合しかレビューしていないことになります。ファイルの見た目のサイズは以前と同じでも、そのサンプルが残りについて教えてくれる情報量は変わってしまっているのです。
人の目が必要ない性質もある
有効な対処は、判断が必要な部分とそうでない部分を切り分け、後者を人間にやらせるのをやめることです。ローカライズの不具合の多くは言語的なものではなく機械的なもので、文の意味を理解する必要はなく、その「形」を読むだけで検出できます。
- 原文にあるプレースホルダーや書式指定子が、訳文で欠落・不正な形になっている
- タグの対応が崩れている、または原文と順序が違う
- 訳文が原文とバイト単位で完全一致していて、未翻訳を示唆している
- 文字化け — 置換文字や、マルチバイト文字列の破損
- 原文ファイルに対してキーが重複している、または欠落している
これによって人間のレビューが本来の仕事に集中できる
これらのチェックはどれも意味を読む必要がなく、サンプルではなく全件に適用しても信頼性が落ちません。スクリプトはレビュアーと違って4000行目で疲れたりしないからです。ファイルの100%に対してこれを実行するコストはほぼゼロで、人がファイルを開く前に、不具合のカテゴリを丸ごと一つ排除できます。
これが全件チェックの本当の意味です。人間の判断を置き換えるためではなく、コンピュータが確実に検証できることに人間の判断力を浪費するのをやめるためです。人に残るのは意味とトーンのレビューです。そのセリフがキャラクターに合っているか、ジョークが成立しているか、場面のレジスターと一致しているか。ここはまさに、少数のサンプルから推測するのがサンプリングにとって一番苦手だった部分であり、サンプリングの有無にかかわらず今も人間が必要な部分です。
実務での結論
翻訳パイプラインのどこかにAIの出力が入っているなら、機械的な正しさは全件チェックの対象として扱い、限られた人間のレビュー時間は意味の確認に使うべきです。サンプリングという手法自体が間違っているわけではありません。全件に実行できるはずのチェックの代用として使うのが間違っているのです。あるチェックについて問うべきなのは「何件サンプリングすればいいか」ではなく、「これは本当に人間が必要な作業なのか、それとも単にずっとそうしてきただけなのか」です。