翻訳が返ってきました。ドイツ語、フランス語、日本語。どれも埋まっていて、体裁も整っています。ぱっと見では問題なさそうです。ですが、自分で読めない言語で「問題なさそう」に見えることは、検証ではなく思い込みです。そして翻訳が静かに取り違えうるものの中で、いちばん困るのが、いちばん正しくあってほしいもの――意味です。
backTranslation ステージは、そのギャップを人のダブルチェックなしで埋めます。各出力をソースロケールに逆翻訳し、その往復結果をAIが元の原文と比較して、意味がずれた箇所を検出します。往復しても意味が保たれたはずだと信じる必要はありません。パイプライン自身が、それを確かめます。
stepId: backTranslationこのページでは、このステージだけを取り上げます。各ステップで何をするのか、意味のずれをどう判定するのか、どのケースが自動修正されるのかを説明します。パイプラインが初めてなら、各ステージが中核の翻訳ステップをどう包むのかは パイプラインの概要 から確認してください。有効化するには パイプラインを設定する、実行結果の読み方は パイプライン実行を確認する を参照してください。
このページの内容
チェックの仕組み#
このステージは中核の翻訳のあとに実行され、rephrase が有効な場合はそのあとに続いて実行されます。つまり、常にその時点での最良の出力、すなわちそのまま公開されるテキストを検証します。流れは 3 ステップです。
逆翻訳する
翻訳済みの出力は、同じ エンジン設定――glossary、ブランドボイス、instructions――を逆方向向けに調整したうえで、ソースロケールへ翻訳し直されます。単なる参照や照合ではなく、実際にもう一度翻訳します。
意味のずれを検出する
AIエージェントが逆翻訳と、あなたが送った元の原文を比較し、差異があればその重大度を minor、major、critical のいずれかで判定します。
必要なら修正する
判定が major または critical の場合は、追加の AI パスで順方向の翻訳を調整し、意味のずれを解消します。minor の差異は可観測性のために記録され、そのまま残されます。言い回しの違いだけで出力を書き換えることはありません。
つまりこのチェックは、意味がずれたことを知らせるだけではありません。重要なケースでは、その翻訳がユーザーに届く前に順方向の翻訳まで修正します。
意味のずれの判定方法#
往復翻訳しても、原文が一語一句そのまま返ってくることはありません。翻訳者が二人いれば――あるいは一つの AI が二方向に訳しても――同じ内容を別の言い回しで表現するのは自然なことで、不具合ではありません。重要なのは、無害な言い換えと、意味そのものが動いてしまったケースを切り分けることです。
| 重大度 | 意味 | ステージの動作 |
|---|---|---|
minor | 表現は違っても、意味は保たれている状態。類義語への置き換え、語順の入れ替え、文体上の選択などです。 | 記録のみで、修正はしません。 |
major | 意味が無視できない程度に変わっている状態。強調点の変化、限定条件の脱落、主張内容の変化などです。 | 修正パスで順方向の翻訳を調整します。 |
critical | 意味が誤っている状態。否定の反転、数値の変化、用語の逆転などです。 | 修正パスで順方向の翻訳を調整します。 |
この切り分けこそが重要です。言い換えられたすべての文を「修正」するチェックでは、良い翻訳まで無駄に揺り戻して、本当に重要な問題を埋もれさせてしまいます。逆に、すべてを検出して何も直さないチェックでは、ただレポートが長くなるだけです。判定があるからこそ、このステージは無害なケースには手を入れず、本当に意味が動いた場合にだけ修正パスを使えます。
自動修正されるもの、されないもの
修正パスが走るのは major と critical のずれだけです。minor のずれは可観測性のために可視化されますが、出力は変更されません。判定にかかわらず、すべての差異を人の目で確認したい場合は human review を使ってください。逆翻訳は自動のガードであって、レビュー担当者の代わりではありません。
定番の手法を自動化#
逆翻訳は Lingo.dev 独自の発明ではありません。人手翻訳の現場で長く使われてきた、定番の品質保証手法です。第二の翻訳者がターゲットテキストをソース言語に戻し、編集者がその二つを比較することで、意味が失われた箇所をあぶり出します。これによって、一度の順方向翻訳では見えにくい失敗――自然に読めるのに、意味が少しずれている翻訳――を捉えられます。
このパイプラインは、その同じ手法を、第二の翻訳者と編集者の代わりに LLM を使って実行します。手法そのものは、すでに確立されています。自動化しているのは、手間と待ち時間です。だからこそこのステージがあります。AIらしさを付け足すためではなく、広く認められた意味チェックを、すべてのロケールに対して毎回ジョブの流れの中で実行するためです。
有効にすべき場面#
逆翻訳が真価を発揮するのは、意味を取り違えるコストが高く、しかも自分ではターゲットロケールを読んで見抜けない場面です。たとえば次のような場合に向いています。
- コンテンツが 法律・医療・金融・技術 分野である場合。否定の反転や限定条件のずれが、単なる文体差ではなく実際のリスクになります。
- チーム内の誰も読めないロケール に向けて配信する場合。逆翻訳は、意味が保たれているかを確かめるための唯一の窓口になります。
- 出力が 高リスクかつ低ボリューム の場合。契約条項、用量指示、コンプライアンス通知のように、追加の確認コストよりも、誤るコストのほうがはるかに大きいケースです。
二度目の翻訳が走るので、コストは上がります
すべての出力に対して完全な逆翻訳と AI 比較を行い、さらに判定が major または critical の場合は修正パスも追加されます。そのため、逆翻訳を有効にしたジョブは、順方向翻訳だけの場合より多くのモデル処理を行います。有効な各ステージは、それぞれのコストをジョブに記録するため、このチェックによる追加分を正確に確認できます。意味の忠実性にそのコストを払う価値がある場面で有効にし、順方向の翻訳だけで十分な大量・低リスクの文字列では無効のままにしてください。
rephrase とも自然に組み合わせられます。rephrase はコピーを自然な表現に整え、逆翻訳は、その自然な言い換えが原文の意味を保っているかを確認します。両者は独立して切り替え可能です。詳しくは パイプラインを設定する を参照してください。
結果の読み方#
他のパイプラインステージと同様に、有効な逆翻訳チェックはジョブの steps 配列に独自の記録を書き込みます。GET /jobs/localization/:jobId でジョブを取得すると、backTranslation ステップを見れば、このチェックが実行されたことと、どう解決されたかがわかります。
{
"id": "ljb_C3d4E5f6G7h8I9j0",
"status": "completed",
"outputData": { "clause": "Diese Vereinbarung darf nicht ohne schriftliche Zustimmung übertragen werden." },
"steps": [
{
"stepId": "localize",
"type": "action",
"status": "completed",
"errorMessage": null,
"createdAt": "2026-04-17T10:00:00Z",
"startedAt": "2026-04-17T10:00:00Z",
"completedAt": "2026-04-17T10:00:09Z"
},
{
"stepId": "backTranslation",
"type": "action",
"status": "completed",
"errorMessage": null,
"createdAt": "2026-04-17T10:00:09Z",
"startedAt": "2026-04-17T10:00:09Z",
"completedAt": "2026-04-17T10:00:21Z"
}
]
}completed が backTranslation のステップであれば、チェックが最初から最後まで完了したことを意味します。判定が major または critical のずれだった場合、そこで読む outputData はチェック前のものではなく、修正後の順方向翻訳です。チェックが付けた重大度の内訳や、ステージの failed または skipped がジョブ全体に対して何を意味するかといった詳細は、パイプライン実行を確認する にあります。ここが steps と warnings を読むための正式な参照先です。
これがこのステージの全体像です。逆翻訳し、段階付きで比較し、意味が動いた場合だけ修正する。これにより、各出力の忠実性は想定ではなく、ジョブの流れの中でその場で検証されます。リクエストごとに有効化することも、エンジンのデフォルトとして設定することもできます。そのうえでステップを見れば、往復しても意味が保たれたかを確認できます。
