英語と日本語の翻訳で、機械翻訳か翻訳者かを決めるとき、文章の長さだけでは判断できません。何のために読むのか、誤った場合にどのような影響があるか、原文と訳文を確認できる人がいるかが重要です。機械の出力を人が修正する方法も含め、必要な工程から考えましょう。
ここでは日常の情報収集から社外向け文書まで、翻訳方法を選ぶための判断軸を説明します。特定のサービスの精度を測定した比較や順位ではありません。同じサービスでも原稿・分野・言語・設定で結果が変わるため、実際の対象に近い資料で確認することが出発点です。
最初に「読むだけ」か「相手に渡す」かを決める
公開記事の話題をつかむために読む場合と、顧客へ送る正式な案内を作る場合では、誤りが与える影響が違います。前者でも重要な数字や条件は原文に戻りますが、後者では読者が訳文を基に申し込んだり、契約したりする可能性があります。利用場面と確認責任を先に決めてください。
| 使う場面 | 検討する進め方 | 残す確認 |
|---|---|---|
| 公開記事の内容を大まかに知る | 機械翻訳で概要を把握 | 引用・判断に使う箇所は原文で確認 |
| 社内の定型案内を下書きする | 承認された環境で下訳を作成 | 担当者が条件と表現を照合 |
| 顧客向け説明や製品文書を公開する | 翻訳・校閲・画面確認を設計 | 内容責任者による最終承認 |
| 官公庁などへ文書を提出する | 提出先の翻訳要件から選択 | 言語、形式、翻訳者や証明の要件 |
この表は作業を選ぶための例です。社内向けでも安全に関する指示や未公表の重要情報なら、確認を軽くする理由にはなりません。「社内だから自由」「短いから簡単」という区分ではなく、文章の役割に応じて判断します。
現在の機械翻訳を単語の置換と考えない
Googleは2026年4月の公式記事で、ニューラルネットワークへの移行と、現在のGoogle翻訳でGeminiモデルを利用していることを説明しています。現在の機械翻訳を、単語を一つずつ辞書で置き換えるだけの仕組みとして説明するのは適切ではありません。
一方、自然に読める文章が出ることと、対象文書の条件が正しく伝わることは分けて考えます。専門用語、数字、否定、話者、文脈に依存する省略は、採用する前の確認対象です。提供元が機能の改善を説明していても、自社の文書で確認が不要になるという意味ではありません。
また、ブラウザの翻訳、一般利用者向けアプリ、業務向けAPIを同一の条件とみなさないでください。対応する入力形式、用語集、情報の保存、管理者設定などはサービスごとに確かめます。名前が似ていても、契約や利用する機能が違えば、業務への適用条件も変わります。
入力できる原稿かを品質より先に確認する
顧客の未公開資料や個人情報を含む文書では、利用するツールへの入力が認められているかを先に確認します。保存期間、学習への利用、第三者への共有、データの処理場所、契約上の守秘義務を、実際に利用するサービスの条件と照合します。
例えばGoogle Cloud Translation APIのデータ利用FAQは、送信内容を翻訳機能の学習・改善に使わないと説明しています。これは同APIについての案内です。一般利用者向けのGoogle翻訳や、別会社のサービスにも同じ条件が適用されるとは読み替えられません。
入力が許可されない原稿は、ツールの精度が高くてもその環境では扱えません。使ってよい資料、伏せるべき情報、利用可能なアカウントを組織で決めます。氏名を消しただけで機密性がなくなるとは限らず、取引内容や技術情報も含めて確認する必要があります。
人による修正を頼むなら範囲を具体化する
機械翻訳の出力を人が確認・修正する工程は、ポストエディットと呼ばれます。ISO 18587:2017の公開概要は、機械翻訳出力に対する人によるフルポストエディットの工程と担当者の能力を対象にしています。単に日本語の誤字を直すだけの作業とは範囲が異なります。
依頼時は「機械翻訳を直してください」だけでなく、原文対照、専門用語、抜けや追加、数字、文体、レイアウトのどこまでを含むかを決めます。意味が崩れている箇所を一から訳し直す判断も必要です。下訳を用意すれば必ず安くなる、必ず短く済むとは限りません。
翻訳者へは出力だけでなく、原文、使用目的、用語集、採用したツールと設定、変更してはいけない表現を渡します。原文が途中で変わった場合は、変更箇所を知らせてください。どの版を確認したかが曖昧なままでは、修正した条件が別の版で失われることがあります。
代表原稿で「確認に掛かる手間」を比べる
方法を選ぶための試作には、簡単な紹介文だけでなく、実際に扱う表、注意事項、専門用語、長い文、曖昧な短文を含めます。同じ原稿で、翻訳に掛かった時間と、照合・修正・納品形式の調整に掛かった時間を別々に記録します。出力が速いことだけで工程全体を評価しないようにします。
確認した誤りは、意味、抜け、用語、表記などに分けます。JTFの翻訳品質評価ガイドラインも、品質の共通認識と合意を形成するための資料として利用できます。社内の評価でも、読み手の目的と、問題が起きたときの影響を共有してから比べることが大切です。
評価に使った文章と、その後の本番原稿が違う分野なら、結果をそのまま広げないでください。サービスやモデルが変わった場合、用語集を更新した場合にも、必要な範囲で再確認します。「以前よかった」という印象だけで継続するのではなく、実際の確認結果を判断の材料にします。
最終的に誰が使用を承認するかを残す
翻訳者が意味を確認し、業務担当者が取引条件や製品仕様を確認し、公開担当者が表示を確認するように、役割を分けます。法的・医学的な判断や提出先の受理判断は、翻訳そのものと同じではありません。必要な専門家や提出先への確認を工程に含めます。
納品時には最終原文と訳文、使用した用語集、未解決の照会、確認済みの範囲をそろえます。機械と人のどちらを選ぶかは、一方への信頼だけで決める問題ではありません。入力してよい環境と、目的に必要な確認工程を確保できる方法を選びましょう。
