公開前に翻訳品質を測定可能な判断へ変える
翻訳品質保証とは、納品直前に文章をもう一度読むことではありません。「自然な訳にしてほしい」という主観的な依頼を、再現可能な公開判断に変える運用の仕組みです。実務的なワークフローでは、対象読者、目的、リスクを先に定義し、翻訳、独立レビュー、LQA 評価、実環境テスト、公開承認を分けます。さらに、エラー分類、重大度、サンプリング、修正と再テストの記録によって、各言語版を公開できる理由、または保留すべき理由を説明します。
発注者に必要なのは、あらゆるコンテンツに使える万能スコアではなく、指定用途に適していることを示す証拠です。医療指示、ソフトウェアのボタン、法的通知、広告見出し、社内ナレッジでは、誤りの影響が異なります。本ガイドは、ローカリゼーション担当者、調達部門、グローバルコンテンツ責任者が受入基準を設計し、ベンダーの LQA レポートを比較し、検証不能な「ネイティブ品質」という約束を避けるための方法をまとめます。
翻訳 QA と校正の違い
校正は、より広い品質システムの一工程です。通常はターゲット言語の綴り、文法、句読点、一貫性、明らかな表示上の問題を確認します。しかし、原文との意味照合、実際の UI における変数やリンクのテスト、公開を止めるほど重大な問題かどうかの判定までは含まれない場合があります。
完全な工程には、原文準備、用語承認、翻訳者の自己チェック、バイリンガルレビュー、自動チェック、言語品質評価（LQA）、機能・コンテキストテスト、修正、回帰確認、最終承認が含まれます。ISO 17100は翻訳サービスの資源と中核プロセスを扱い、ISO 11669:2024は発注者向けにプロジェクト仕様、ニーズ分析、リスク評価、ワークフロー上のコミュニケーションを示します。ただし、規格名だけで案件固有の受入仕様を代替することはできません。
制作前に役割を定めます。翻訳者は訳文を作成して自己チェックし、リバイザーは原文と訳文を比較して意味・用語・目的を確認します。LQA 評価者は合意したモデルでサンプルまたは納品物を評価し、コンテキストテスターは製品、ページ、文書、メディア上で確認します。公開責任者は残存リスクを受け入れ、最終判断を行います。小規模案件で一人が複数の役割を兼ねても、工程と証拠は追跡可能にします。
レビュアーが一貫して使えるエラー分類
エラー分類は、十分な範囲を持ちながら、レビュアーが安定して区別できる粒度にします。発注者向けには次の分類が実用的です。
- 正確性：誤訳、抜け、不当な追加、未翻訳、原文との関係の誤り
- 用語：承認用語の不使用、用語不統一、分野に不適切な語
- 言語：文法、綴り、句読点、構文、流暢さ、不自然な表現
- スタイルとレジスター：トーン、ブランドボイス、丁寧さ、読者レベルの不一致
- ロケールと規制：日付、数値、単位、住所、法令参照、文化慣習、必須表示の誤り
- 機能と書式：タグ、プレースホルダー、リンク、改行、文字切れ、レイアウト、文字方向、ファイル動作の問題
W3C ITS 2.0は、ツール間で交換可能なローカリゼーション品質問題の種別と、問題種別・コメント・重大度の記録方法を定義しています。参考として有用ですが、案件ではレビュアーが確実に判断できる粒度だけを採用します。欧州委員会翻訳総局の2024年品質評価資料は、品質要求をエラーコードへ対応させ、ランダムサンプルを評価する公開事例です。
重大度はレビュアーの好みではなく、影響で決めます。クリティカルは安全、法務、財務、プライバシー、重大な評判リスクを生じさせ、必要な機能を壊すか、コンテンツを使用不能にする問題です。メジャーは意味を変え、ユーザーを誤導し、重要な指示に反し、タスクを実質的に損ないます。マイナーは主要な意味や操作を妨げない限定的な言語・表示の問題です。
コンテンツごとの例を用意します。投薬量の小数点はクリティカルになり得ます。ボタン名の不一致が誤操作を招くならメジャーです。改行禁止スペースの欠落は通常マイナーですが、法定書式を崩す場合は重大度が上がります。カテゴリだけで重大度を自動決定してはいけません。
エラーを実行可能な受入ルールへ変える
ISO 5060:2024は、エラー種別とペナルティ点を使ってエラースコアと品質評価を作る分析的評価、サンプリング、評価者の力量を扱います。発注者はこの考え方を使えますが、一つのスコアが全案件に通用するとは考えないようにします。
たとえば、マイナーを1点、メジャーを5点とし、確認済みクリティカルが一つでもあれば自動保留とします。点数はレビューした1,000語、セグメント、画面など安定した単位で正規化します。「クリティカルなし、レビュー1,000語当たり加重点10以下、すべての機能障害を修正、すべてのメジャー修正を回帰テスト済み」と記載できます。数値は例であり、実際の閾値はリスク、パイロットの証拠、関係者の許容度から決定します。
繰り返しエラーの数え方も定義します。誤った用語が80回あれば根本原因は一つでも、ユーザーへの影響は80か所です。発生数と固有の根本原因を両方報告します。原文不備、好みの変更、範囲外の書き換えはベンダーのエラースコアから除外できても、解決対象として別途追跡します。
リスクを隠さないサンプリング戦略
常に100%の人手レビューが経済的とは限りません。しかし「10%を確認」は、選択方法がなければ戦略になりません。レビュー開始前に、サンプリング単位、母集団、規模、選択方法、拡大ルールを定めます。
堅牢な計画では、一般コンテンツを偏りなく見るランダムサンプルと、安全文、価格、主張、法的通知、CTA、高トラフィック画面、新用語を対象にするリスクベースのサンプルを組み合わせます。ファイル、翻訳者、言語、コンテンツ種別、制作バッチを横断し、クリティカルまたは特定層に集中したメジャーが出たらレビュー範囲を広げます。
10万語のリリースなら、各ファイルからランダムに抽出し、安全警告、数値、新規承認用語は100%確認する設計が考えられます。ある層でクリティカルが出る、またはメジャーが閾値を超えた場合、その言語の公開を保留し、当該層を全件確認します。割合が大きいからではなく、サンプルと判断が結びついているため説明可能です。
複数言語を一つの平均値にまとめないでください。全体平均の合格が小規模市場の不合格を隠すことがあります。言語別・高リスクコンテンツ群別に、サンプル数、エラー数、重大度、正規化スコア、公開状態を報告します。
本番採点の前にレビュアーをキャリブレーションする
レビュアー間の不一致は遅延と不要な手戻りを生みます。キャリブレーションは、スコアが支払いや公開に影響する前にルール解釈を合わせる作業です。
意図的に曖昧な例を含む代表的セグメントを全員へ渡します。それぞれが問題範囲、カテゴリ、重大度、修正案、根拠を独立して記録します。その後、案件仕様、用語集、スタイルガイド、製品コンテキストに照らして差を解消し、エラーガイドへ例を追加します。主要な区別を安定して適用できるまで再実施します。
一致は複数レベルで見ます。同じ問題を検出したか、同じカテゴリを選んだか、同じ重大度を付けたかを分けて確認します。一つの一致率では不一致の原因が隠れます。裁定結果を継続的な判断ログに残し、同じ境界事例をバッチごとに議論し直さないようにします。
レビュアーの好みも管理します。正しい訳文を個人的な表現へ書き換えるべきではありません。採点対象には、明示された指示、意味上の欠陥、読者上の問題、機能への影響のいずれかを求めます。スタイル上の提案は「好み」として別に記録し、受入指標を歪めないようにします。
実際のコンテキストで最終訳文をテストする
バイリンガルファイル内で正しい文字列も、製品へ配置すると失敗することがあります。コンテキストテストでは、エクスポートされたテキストではなく利用者の体験を確認します。
ソフトウェアとウェブサイトでは、文字拡張、切れ、折り返し、ボタン、リンク、変数、複数形、性、並び順、検索、右から左への表示、日付・数値形式、高リスクフローを確認します。文書は表、ページ参照、ヘッダー、フォント、図、PDF・印刷出力を確認します。字幕はタイミング、話者の文脈、改行、読み負荷、画面内文字を見ます。マーケティングでは見出し、ビジュアル、CTA、ランディングページ、市場別主張が一体として機能するかを確認します。
各問題を文字列ID、セグメント、ページ、画面、タイムスタンプ、ファイル位置に結び、スクリーンショットやレンダリング済みファイルを証拠にします。修正後は該当箇所と周辺を回帰確認します。修正が新たな文字切れ、タグエラー、用語不一致を生む場合があるためです。
制作方式とレビュー深度の選択には、翻訳ワークフローにおける人手レビュー、翻訳と MTPE の比較、ウェブサイトローカリゼーションと翻訳の違いも参照してください。
公開判断に使える LQA レポートを求める
有用なレポートは結論のないコメント一覧ではありません。プロジェクトと版、言語・ファイル、評価者・日付、適用仕様・用語集・スタイルガイド・分類版、母集団・サンプル数・選択方法・リスク層、各問題の位置・原文・訳文・カテゴリ・重大度・根拠・修正案を含めます。さらに言語・カテゴリ・重大度・コンテンツ群別の正規化結果、クリティカル・体系的問題、根本原因、修正担当と期限、再テスト証拠、未解決例外、合格・条件付き合格・不合格の推奨を明記します。
調達部門は総合点だけでなく、ベンダーが受入基準、サンプル、レビュアー調整、異議申立て、修正証明をどう扱うか比較します。匿名化されたサンプルレポートを求め、一つの問題が検出、裁定、修正、回帰確認、公開判断までどう流れるか説明してもらいます。
ローカリゼーション公開チェックリスト
公開前に次を確認します。
- 最新原文、範囲、読者、市場、リスクを記録した。
- 言語名だけでなく正確な対象ロケールを指定した。
- 用語、スタイル、製品参照、翻訳禁止項目を承認した。
- 翻訳者、リバイザー、評価者、テスター、公開責任者の役割が明確である。
- 分類、重大度、サンプル、閾値、拡大ルールを採点前に合意した。
- 数値、タグ、プレースホルダー、用語、完全性の自動チェックが成功した。
- 必要なバイリンガルレビューとリスクベース LQA が完了した。
- 最終レンダリングがコンテキスト・機能テストに合格した。
- すべてのクリティカル・メジャーに処理結果、担当者、再テスト記録がある。
- LQA 後の変更を回帰テストした。
- 最終報告書に残存リスクと承認者を記載した。
- 原文、承認訳、報告書、判断、版履歴を方針に従い保管した。
品質保証の成果は、監査可能な選択、すなわち公開、明記した例外付き公開、または修正のための保留であるべきです。候補ベンダーには LQA レポートのサンプルと文書化された受入基準を求めてください。Smart Language Service は、リスクベースの翻訳品質保証ワークフローを設計し、翻訳・レビューを実施し、最終公開判断を支える言語別証拠を提供できます。