AI翻訳の品質をチェックする方法|抜け・誤訳を確認する

AI翻訳は自然な文章かだけで判断せず、原文と訳文をsegment単位で並べ、Accuracy、Terminology、Fluency、Styleを分けて確認します。

AIものさし編集部

AI翻訳の品質は、読みやすさだけでなく、原文の意味、条件、数字、用語が正しく保たれているかで確認します。原文と訳文を段落や文の単位で並べ、Accuracy、Terminology、Fluency、Styleを別々に評価してください。否定、条件、金額、安全上の説明など、誤ると判断が変わる箇所から先に確認し、曖昧な原文は機械的に直さず担当者へ戻します。

訳文を確認する範囲を決める

翻訳対象の言語、読者、媒体、利用目的を記録します。技術手順、UI、契約、販促文では、同じ語や表現でも許容できる誤差が異なることがあります。原文の承認版、翻訳ツール、用語集、モデルや設定、翻訳日を記録し、どの条件で作られた訳文を確認しているか分かるようにします。

複数ファイルを確認するときは、原文と訳文のファイル名、版、ページやsegmentの対応を保ちます。ファイル更新後に以前のQA結果を使い回さず、変更箇所と影響を再評価します。翻訳対象外の箇所、未翻訳のコメント、画像の中の文字などがある場合は、対象範囲として明示してください。

Translation QA Matrix

Accuracy:原文にある情報が訳文にあるか。追加や省略、意味の反転がないか。

Terminology:承認済み用語集、製品名、固有名詞、略語に合っているか。

Fluency:文法、語順、綴り、句読点、読みやすさが目標言語として自然か。

Style:敬体、専門度、見出し、ブランド表現、数値表記が媒体に合っているか。

Formatting:箇条書き、リンク、コード、表、タグが崩れていないか。

Locale:日付、通貨、単位、住所、数字の区切りが対象地域の条件に合うか。

各項目は別々に確認します。自然な文章でも意味が誤っていることがあり、正確でも読者に理解しにくい場合があります。全体の流暢さでAccuracyの失敗を打ち消さないでください。

重大度を決めて修正を回す

組織で承認済みのSeverity定義があれば、それを優先します。標準がないときは、仮の分類を使い、正式な品質基準として扱わないでください。

Critical:意味が逆になる、支払額や安全条件が誤る、重要な条件や否定が抜けて利用者の判断を変える。

Major:専門用語、対象範囲、期限、手順の誤訳が読者を誤った行動へ導く可能性がある。

Minor:意味を大きく変えない表記揺れ、読みづらさ、句読点の問題。

Review:原文が曖昧で正しい訳を決められない、または専門家の判断が必要。

Critical/Majorは翻訳者またはSubject Matter Expertが原文と照合し、修正後に該当箇所を再確認します。Minorは用語集や文体ガイドへ反映し、同じ誤りが広がっていないか検索します。Reviewは翻訳AIへ再質問して決めず、原文のownerへ確認します。

条件・数字・否定を先に見る

翻訳の初期確認では、全文章を同じ速さで読むより誤りの影響が大きい要素を先に探します。

・not、unless、only、at least等の否定・例外・範囲表現。

・日付、金額、割合、人数、単位、通貨、桁。

・比較級、優先順位、条件分岐、責任主体。

・安全、法務、支払い、期限、申請に関わる文。

・表の行列、脚注、画像内文字、リンク先。

翻訳後の数字を表だけで拾い、本文の説明と対応しない場合があります。原文と訳文の該当段落を並べ、数値の対象、期間、単位、条件を確認します。数字の表記が現地形式に変わっても、値と意味が一致していることを確かめます。

文単位の照合方法

  1. 原文と訳文を文またはsegment単位で並べる。

  2. 追加・欠落・誤訳をAccuracyとして記録する。

  3. glossaryとUI用語をTerminologyとして照合する。

  4. 意味が正しい部分だけFluencyとStyleを編集する。

  5. Critical/Major/Minor/Reviewを割り当てる。

  6. 修正後に原文と再照合し、未解決点を記録する。

AIへ確認を依頼するなら、「原文の文、訳文、懸念カテゴリ、根拠となる対応箇所、未確認点」を表にさせます。「正しい訳に直して」だけでは、原文にない説明を加えたり、条件を弱めたりすることがあります。AIの修正案は候補として扱い、承認済み訳のownerが最終確認します。

DeepL Translation Quality Evaluationの範囲

DeepLの公式Helpは、Translation Quality Evaluation(TQE)がファイル翻訳をsegment単位で確認し、潜在的なissueをcategoryやseverityとともに報告し、自動で修正はしないと説明しています。利用にはBusinessまたはDeepL for EnterpriseとTranslation Flow add-onなどの条件があり、契約条件や画面で確認が必要です。日本語を含むlanguage pairは掲載されていますが、対応pair、file type、利用場所は更新され得るため、実際に使う時点のHelpを確認します。

TQEの報告は、読み直す箇所を探す補助になります。人間のレビューや組織独自の承認基準を置き換えません。誤りが見つかったら、原文へ戻って修正し、修正版を再度確認します。ツールが指摘しなかったことも、誤りがない証明にはなりません。用語集の意図的な訳し分けや社内用語など、文脈が不足すると誤りに見えるケースもあるため、根拠を確認します。

QAレポートに残す項目

Project / document:[対象文書と版]

Source / target language:[翻訳元と翻訳先]

Tool / settings:[サービス、機能、用語集、確認日]

Scope:[確認したページ・segment・対象外範囲]

Issue:[原文、訳文、カテゴリ、該当位置]

Severity:[Critical / Major / Minor / Review等]

Owner:[翻訳修正者、専門家、承認者]

Resolution:[修正内容、原文ownerへ確認した内容]

Status:[未確認、修正済み、再確認済み、受容理由]

この記録を残せば、レビュー結果を次回翻訳や用語集へ反映できます。個人情報や機密内容があるファイルは、外部翻訳・評価サービスへ渡す前に契約、アクセス、保持条件を確認します。

失敗例とやり直し方

原文の条件文が抜けた:該当segmentの前後を読み、条件が段落や脚注へ移動していないか確認します。抜けていれば翻訳を修正し、利用者へ影響する範囲を調べます。

専門用語が一貫しない:用語集の登録、language pair、対象ファイルを確認し、修正後は関連ファイルも検索します。

文章は自然だが意味が違う:Fluency評価だけで承認せずAccuracyから再確認します。

原文が曖昧:AIへ「自然な訳」を繰り返し依頼せず、原文ownerへ意図を確認し、判断後に訳文を直します。

TQEがissueを検出しない:高リスク箇所は独立した人手チェックを続けます。自動レポートの対象外となる内容も確認します。

ファイルの配置が崩れた:テキストだけでなく表、注記、リンク、コード、レイアウトを別のQA対象として扱います。

AIものさし編集部の判断

翻訳の検品では、Accuracyと影響の大きい条件から確認し、その後に用語、読みやすさ、文体へ進みます。訳文が自然でも、意味や責任の範囲が変われば公開できません。原文の曖昧さは翻訳者の推測で埋めず、ownerへ返します。

TQEなど自動評価は、確認箇所を探す手段として使い、修正と承認は人が行います。まず少量の代表文書でレビュー基準を試し、重大な誤りが何か、誰が再確認するかを決めてから対象を広げてください。

レビューを完了とする条件

文書を承認する前に、重要な主張の原文と訳文が対応していること、Critical/Majorが未解決のまま残っていないこと、Reviewerが変更後を再確認したことを確かめます。Review扱いの曖昧な原文は、ownerの回答または受容理由が記録されるまで未完了とします。

レビュー結果が修正に反映されても、周辺段落や他のlanguage pairで同じ表現が崩れていないか検索します。用語集を直した場合は、関連する見出しや定型文も確認します。ファイルの翻訳品質が合格していても、リンク、画像文字、レイアウト、法的レビューなど別の公開条件が残っているなら、それぞれの承認状態を区別して記録します。

全ページを同じ深さで読むのが難しい場合、全体スキャンに加え、料金・期限・安全条件、表、見出し、ファイル更新部分を優先的に確認します。サンプリングする場合は対象範囲と選定理由を記録し、未確認範囲を「全件確認済み」と扱わないようにします。

例:利用条件の一文を照合する

原文に「利用開始前に管理者の承認が必要」と書かれた文が、訳文で「利用開始後に管理者へ通知する」と変われば、文は自然でも意味が逆転しています。Reviewerは、時点(開始前/開始後)、行為(承認/通知)、責任者(利用者/管理者)を別々に照合し、CriticalまたはMajorとして記録します。修正後はその一文だけでなく、前後の手順が矛盾しないか、申請フォームや画面表示も確認します。

これは架空のQA例であり、実際のDeepL出力を試した結果ではありません。誤りの見つけ方を示す例として、実機の評価や翻訳性能を主張しません。

原文側にも問題がある場合

翻訳品質の修正が必要に見えても、元の文に指示の矛盾、未定義語、複数の解釈があれば、訳者だけで意図を決めません。原文のownerへ質問し、確定した原文、採用した訳、判断日を記録します。複数の訳が業務上許容されるなら、その条件を用語集や文体ルールへ反映します。

;

次に読む・使う

この記事の次に必要な情報へ進めます。