流暢な文でも、意味が正しいとは限らない
翻訳されたニュースは、読みやすくても、人物の身元が変わっていたり、否定が抜けていたり、予測が確定した出来事に置き換わっていたりすることがある。多言語メディアにとって、こうした誤りは不自然な文体より重大な影響を及ぼしかねない。言語を増やすと検証が必要な版の数は増えるが、読者に届ける価値まで自動的に増えるわけではない。
本稿では、2026 年 10 月 20 日に確認した一次資料に基づき、制作工程で使う受け入れ判定の枠組みを提案する。これは編集上の分析であり、モデルのベンチマークでも、独自実験の報告でも、特定の事業者の実コストが最も低いという主張でもない。
米国と中国の文書から実際に分かること
Google Cloud Translation の文書では、用語を統一するための用語集が説明されている。原言語から訳出先言語への方向を持つリストと、多言語の同義語セットが含まれる。制約も記されている。照合は既定で大文字と小文字を区別し、一部のストップワード項目は無視され、用語集リソース自体にはバージョン管理がない。そのため、制作チームは独自にバージョン管理した用語ファイルと、ロールバックの記録を持つ必要がある。用語集は有用な制御手段だが、出力が正しいことの証明にはならない。
Alibaba Cloud の Qwen-MT 文書には、用語ペア、翻訳メモリの文ペア、分野別プロンプトが記載されている。また、分野別プロンプトは現時点では英語でなければならず、モデルはシングルターンでシステムメッセージに対応せず、こうした追加の制御情報は入力トークンを消費すると説明されている。これらを考慮しないワークフローでは、コストを見誤ったり、未対応の指示を送ったりする可能性がある。
これらは異なるインターフェースの例であり、米中の品質ランキングではない。どちらも用語管理を具体的なエンジニアリング課題としている。いずれの文書も、自社で扱う各言語での相対的な正確さを示したり、公開可能なニュースの生成を保証したりするものではない。選定前に、対応する言語ペア、導入要件、同じ素材から得られる実際の出力を比較すべきだ。
モデルを選ぶ前に、不合格の条件を決める
MQM のエラー分類は正確さと流暢さを区別し、固有名詞などのエンティティ、数値、日付、単位、否定に関する誤りを含む。MQM Council の採点指針では、致命的な誤りがあれば総合点にかかわらず翻訳を不合格にする合否判定の例が示されている。これらは品質評価の資料であり、W3C 勧告でも、普遍的な法的基準でもない。
ニュース制作では、致命的な誤りをあらかじめ定義することを勧める。人物や組織の取り違え、立場の逆転、引用の捏造、金額や日付の重大な誤り、または主張を裏付けなくなった出典リンクなどだ。平均点が高くても、こうした誤りが1つあれば埋め合わせにはならない。軽微な文体上の問題は編集待ちに回せるが、意味を変える欠陥があれば、修正と再確認が済むまで公開を止めるべきだ。
自動承認1回ではなく、2段階の判定を設ける
第1段階：構造と事実の照合。 原文と訳文を比較し、承認済みの名称と別名、単位と通貨を伴う数値、日付、リンク、参照識別子、段落の欠落を確認する。原文のタイトル、URL、公開日は独立したメタデータとして保持する。見た目の変更をすべて却下するのではなく、差分を確認対象として示す。1,000 と 1.000 は地域によって同じ値を表すことがあり、名称には定着した現地表記がある場合もある。単位を伴わない数字の確認だけでは不十分だ。
第2段階：文脈の中での意味。 両言語を扱える確認担当者が、否定、不確実性、情報の帰属、引用の範囲、因果関係の主張を原文と照合する。「コストを削減する可能性がある」を「コストを削減した」に変えてはならない。「同社によると」を消してもいけない。見出しと要約も本文と同じくらい慎重に確認する。慎重な記事でも、翻訳の過程で誤解を招く見出しが付くことがある。別のモデルや逆翻訳は問題箇所の検出に役立つが、モデル同士の一致は忠実性を独立に証明するものではない。
まず、代表的な原文記事 20 本による試行を提案する。原文の言語が8言語のうちの1つなら、各記事を残り7つの対象言語に翻訳する。専門用語、引用、財務数値、日付、曖昧な名称を含める。各候補に同じ原文と合格基準を使う。これは試験設計の提案であり、統計的に検証された標本数ではない。後の確認用に独立したホールドアウトセットも確保し、試行用記事の修正を繰り返すだけで評価が終わらないようにする。
生成後の作業も数える
有用な分母は、公開基準を満たした「記事と言語の組み合わせ」の版数だ。以下の架空の例では、「記事」はその1つの版を意味する。不合格の草稿を納品済み記事として数えてはならない。
ワークフロー A と B が、それぞれ合格記事を 100 本納品すると仮定する。A は1本あたりのモデル呼び出し費用が 0.01 ドルで、確認に6分かかる。B は1本あたり 0.05 ドルで、確認に3分かかる。確認作業の人件費を1時間あたり 30 ドルと仮定すると、次のようになる。
- A：モデル呼び出し費用 1 ドルに、10時間分の確認費用を時給 30 ドルで加え、合計 301 ドル。合格記事1本あたり 3.01 ドル。
- B：モデル呼び出し費用 5 ドルに、5時間分の確認費用を時給 30 ドルで加え、合計 155 ドル。合格記事1本あたり 1.55 ドル。
ここでの価格と確認時間はすべて仮定だ。これは計算例であり、測定された性能でも、事業者の現在の料金でもない。初期設定、品質保証ツール、再試行、公開後の訂正は含まれていない。実際の比較では、こうした費用が発生するなら加算する。この例が示すのは、生成で節約した4セントが、追加の編集時間によって簡単に帳消しになり得るということだ。高価なモデルが常に優れていることを示すものではない。
大きな約束より、小さな運用記録
言語ペアごとに、モデルとそのバージョン、プロンプトのバージョン、用語ファイルのバージョン、原文の識別子、初回の合否、致命的な誤り、確認にかかった分数、再試行、最終的な処理結果を記録する。言語別に報告することも重要だ。良好な平均値が、弱い言語ペアを隠すことがある。モデルや用語ファイルが変わった際は、固定したサンプルを再確認する。
8言語のサイトで実務上優先すべきなのは、信頼できる公開判定と、読者に見える訂正プロセスであり、単位コストの削減はその後だ。致命的な誤りが見つかったら自動公開を止め、単発の問題と決めつけずに関連する版を調べる。読者が受け取るのは最終的な意味であって、トークンの値引きではない。
図：多言語編集の検証を表す、AI 生成によるオリジナルの概念画像。測定結果を描いたものではない。