AI翻訳が本当に正しいか、どうやって確認する?

家主へのメッセージを入力し、翻訳ボタンを押すと、滑らかで自然な文章が返ってくる。聞こえは良いが、それが問題だ。AI翻訳が本当に正しいかどうかを確認するのは、今までで一番難しい時代になった。間違った翻訳であっても自然に聞こえるようになったからだ。不安は残る。間違った単語一つで、賃貸契約の条項、ビザの回答、提出しようとしている論文の一文が変わってしまうかもしれないからだ。機械はためらわない。だから、ためらうことになる。

そのためらいは、もはや当たり前のことになった。昔は、壊れたフレーズ、文法の崩壊、意味が漏れといった明らかな傷跡があった。今では、翻訳結果は人間が書いたように読める。ただ、その人間が間違っていた可能性があるだけだ。流暢さはもはや証拠ではない。問題は、ネイティブのように聞こえるかではなく、送り手が意図した意味を、意図したトーンで、必要な精度で伝えているかだ。

だから、本当の作業は最初の下書きの後に始まる。翻訳は完成したように見えるが、チェックが始まったばかりだ。AI翻訳が正しいかどうかは、感覚ではなく手順で確認する。その手順とは、それぞれが他のチェックでは見逃すエラーを捉える、一連のテストの積み重ねだ。

「正しい」の本当の意味 #

翻訳が正しいとは、原文の意味を保ち、訳し先の言語で自然に聞こえ、意図したレジスターに合い、イディオムの使い方を尊重している場合を指す。

評価文献における古典的な分類は、適切性（adequacy）対流暢性（fluency）だ。正しいことを伝えているか、そしてネイティブスピーカーが言うように伝えられているかという2点だ。しかし、この2つだけでは十分ではない。テキストは正確であっても、文脈に対して硬かったり、不自然にフォーマルだったりする。あるいは、美しく読めても、イディオムが翻訳されないために重要なニュアンスが欠けている場合もある。Juliane Houseは著書『Translation Quality Assessment: Past and Present』の中で、正しさを機能に結びつけている。新しい言語でその目的を果たす翻訳は、その目的のために正しい。トーンや構造が原文と異なっていてもだ。そのため、一つの翻訳が、正確だが不自然、自然だがレジスターが間違い、文法的には正しくてもイディオム的におかしいという場合もある。「正しいか」と尋ねるとき、どの軸を指すのかを言っていなければ、答えはない。

流暢な嘘 #

人々を不安にさせる翻訳は、まさに問題なく見える翻訳だ。磨かれ、自信に満ちており、機械翻訳の古い傷跡がない。それが問題だ。流暢な文章は今や簡単に生成できるが、送り手がそれを自分一人で確認することは不可能だ。Douglas HofstadterはThe Shallowness of Google Translateでこれを実証した。バイリンガルの著者が自身の文章をツールに入力すると、滑らかに読めるのに、原文の意味をほとんど伝えていない文章が返ってくる。流暢で、自信に満ちていて、中身は空っぽだ。

転機は2016年だった。GoogleがFound in translationというタイトルの投稿でニューラルシステムを発表したときだ。付随するGNMT論文では、新システムは人間による並列評価で、置き換えられたフレーズベースシステムに比べて平均60パーセント翻訳エラーを削減し、実験でサンプリングされた単純な孤立文では、人間と機械の翻訳がほぼ区別できない場合があると報告された。それが、流暢さが品質のシグナルでなくなった瞬間だ。間違った翻訳であっても、正しく聞こえるようになったからだ。技術的な理由が知りたければ、なぜLLMは翻訳が得意なのかで説明されている。簡単に言えば、モデルは妥当な出力に向けて訓練されているため、エラーであっても自信に満ちた文章のように読める。

この失敗モードは仮説ではない。Hofstadterの記事についてのHacker Newsスレッドで、あるコメント者が自身の長年のベンチマークを紹介している。「その単語はギリシャ語の『χελιδόνι』で、『ツバメ』（鳥）を意味する。この小さな実験を試してきた限り、Googleはそれをフランス語の『avaler』（『飲み込む』という動詞）と翻訳してきた。」完璧に流暢なフランス語だが、品詞が間違っており、意味も間違っており、目に見える傷跡はない。これが、自分で確認できない文章で起こると考えると、リスクの形が見えてくる（スレッド）。

翻訳ツールを作る人々も同じ不安を感じている。Offline Translateの作者はこう書いている。「長い間、医者や公的機関に送るメールなど、個人情報を含む文書を翻訳アプリで書くことに不安を感じていた。」ローカルファーストの翻訳ツールLoqiの作者も同様だ。「オプトアウトの選択肢やプライバシーポリシーがあっても、仕事の文書、個人的な文章、機密情報などには、特に安心できなかった。」コミュニティのアドバイスも率直だ。r/languagelearningで広く共有されたPSAのタイトルは、「DeepLは時々、入力した内容と全く無関係のランダムな翻訳を生成するので、必ず他のソフトウェアや先生でダブルチェックしよう」だ。では、Google Translate、DeepL、その他のツールを信用できるか。気軽な使用なら、ほとんどの場合はいい。流暢さは本物だ。しかし、重要なことには、流暢さは証拠ではない。正直な答えは、テキストがどう聞こえるかに依存しないチェックを実行することだ。

訳文を元の言語に戻してみる #

逆翻訳は、最も古い検証テクニックだ。翻訳を元の言語に再翻訳し、戻ってきたものを読む。往復の翻訳で、元の意味が戻ってくれば、翻訳はおそらく大切なものを保持している。戻ってきたものが意図と異なっていれば、読者が気づく前に問題を見つけることができる。これは、r/Koreanのスレッド「How do I check if my translation is correct?」など、あらゆる言語学習コミュニティでよく聞かれる質問だ。

このチェックが機能するのは、翻訳の2つの方向が同じように失敗することはめったにないからだ。出力時に生じたエラーは、往復で無傷のまま戻ってくることはほとんどない。エラーは、母国語で読める不一致として表面化する。訳し先の言語への不完全な理解の裏に隠れることはない。可能であれば、戻しの翻訳には別のツールを使い、共通の盲点が繰り返されないようにする。そして、結果を意味についての主張として読むのであって、スタイルを判断する文章としてではない。

この方法の限界は正直で、知っておく価値がある。往復翻訳では、両方向で同じ間違った前提を共有している場合、誤りがそのまま通過してしまうことがある。誤りは確認のふりをして戻ってくる。往復翻訳で変化がないことは、証拠ではあるが、証明ではない。そのため、これは一連のチェックの一つであって、すべての答えではない。また、同じメカニズムには、学習テクニックとして全く異なる第二の用途がある。逆翻訳を使った学習方法でその側面を扱っている。

ネイティブのように、声に出して読む #

原文の言語を知らなくても、多くの翻訳の問題を発見できる。これは、r/booksでの長年の議論「How do you judge the quality of a translation without being familiar with the original language a work is written in?」の前提だ。コミュニティがたどり着く答えは、訳文をその言語の観点から判断することだ。訳し先の言語の話者が翻訳を読むと、不自然なリズム、間違ったレジスター、ネイティブが使わないイディオム、段落の途中でフォーマルからカジュアルに変わるトーンなどを発見できる。これらのいずれも、原文を見る必要はない。

話者が構造的に発見できないのは、意味が一致しているかどうかだ。訳文のネイティブ話者がチェックしているのは、流暢さ、レジスター、イディオムという、訳し先の言語に完全に存在する軸だ。正確性は2つのテキストの間の関係に存在し、片方しか読めない人は、構造的にそれを見ることができない。この非対称性こそが、単言語チェックと往復翻訳が同じルーティンに属する理由だ。それぞれが他方の盲点をカバーする。

分業は生産的でさえありうる。機械翻訳の人間による修正についてのHacker Newsスレッドで、あるコメント者はこう述べている。「中国語を1語も翻訳できないが、良い機械翻訳を修正するのは通常うまくできる」（スレッド）。機械は送り手にできない方向を処理し、ネイティブ話者は自分が完璧に知っている言語で結果を確認する。そして、このチェックの最も安価なバージョンは、第二の人物を全く必要としない。翻訳を声に出して読むのだ。耳は、目が見逃すものを捉える。リズムのずれ、誰も言わない文章、技術的には正しいが実際には使われない単語などだ。