翻訳は正確で、用語集も合っている。それでも、どこか「翻訳っぽく」読めてしまうことがあります。rephrase は、その最後のひと押しを担うパイプラインステージです。AIエージェントが現在の出力を書き換え、意味やプレースホルダー、タグは保ったまま、対象ロケールでネイティブが書いたような自然なコピーに整えます。
このページでは、rephrase ステージ単体に絞って、何を書き換え、何を変えず、処理が失敗したときに何が起こるのか、そして最終的に判断すべき「有効にするか、スキップするか」について説明します。パイプラインが初めてなら、まずは Async ローカライゼーションパイプラインの概要 で各ステージのつながりを確認してください。rephrase は async 専用で、Async ローカライゼーション API 経由で作成されたジョブでのみ実行され、同期の /localize 呼び出しでは実行されません。
できること#
逐語的な翻訳では、元の表現がそのまま対象ロケールに持ち込まれてしまうことがあります。文法的には正しくても、いかにも訳文らしく見えてしまう状態です。rephrase ステージは、その時点での最良の出力を、対象ロケールで自然かつこなれたネイティブらしいコピーへ書き換えます。語句を一語ずつなぞるのではなく、より自然な慣用表現を優先しつつ、元の意味と意図は保ちます。また、書き換えにはエンジンの glossary、ブランドボイス、instructions がそのまま適用されます。つまり、翻訳を生み出したのと同じ設定で、この書き換えも行われます。
実行されるのは、AI と人手による refinement ステップの後で、その時点までに到達した出力が対象になります。つまり、human review や AI post-edit が有効かどうかに関係なく、常にその時点の最良版を書き換えます。さらに back-translation check も有効な場合は、rephrase 前ではなく rephrase 後の出力が検証対象になります。
literal パスは原文の言い回しに寄せ、rephrase はネイティブライターならどう書くかに寄せます。役割が違うので、両者は置き換え可能ではありません。どちらを選ぶかは、以下の判断次第です。
プレースホルダーとタグはそのまま#
文章を書き換えるステージだと聞くと、まず気になるのは「本文以外まで触ってしまわないか」という点でしょう。心配はいりません。rephrase は、プレースホルダー、変数、タグ、書式を完全にそのまま維持します。書き換えるのは周囲の文面だけで、アプリが依存するトークンには手を加えません。
そのため、次のような文字列でも、補間やタグはすべて保たれ、変わるのは人が読むコピーだけです。
Source (en): "Hi {firstName}, you have <b>{count}</b> new messages."
Translated (de): "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
After rephrase (de):"Hey {firstName}, <b>{count}</b> neue Nachrichten warten auf dich."{firstName}、{count}、そして <b> タグは、3つすべてで完全に同一です。ドイツ語のコピーはより自然になっていても、ランタイムが依存する構造は変わっていません。
失敗しても、ジョブは止まらない#
rephrase は非クリティカルなステージです。AI による書き換えは失敗したり、タイムアウトしたりすることがあります。それでも、すでに対価を払った翻訳が失われることはありません。前の出力がそのまま引き継がれ、ジョブは続行されます。つまり、正確な翻訳をスタイル調整の処理に賭けることにはなりません。
rephrase が失敗しても、ジョブ全体が失敗することはありません。結果は status: failed を伴うステップ記録として現れ、ジョブ自体は completed_with_warnings として完了し、outputData に格納されるのは rephrase 前の翻訳です。
{
"id": "ljb_C3d4E5f6G7h8I9j0",
"status": "completed_with_warnings",
"outputData": {
"greeting": "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
},
"warnings": [
{ "step": "rephrase", "message": "<the failure reason for this step>" }
],
"steps": [
{ "stepId": "localize", "type": "action", "status": "completed" },
{ "stepId": "rephrase", "type": "action", "status": "failed" }
]
}de の翻訳はそのまま出荷されました。ここで示している正確な message テキスト自体はあくまで一例ですが、固定なのはその形です。つまり、step と message を持つ warnings[] エントリがあり、rephrase ステップは failed として記録され、rephrase 前の出力は outputData に保持されます。今回の実行ではコピーが磨かれなかったことは step フィールドを見れば分かるので、そのロケールで自然な言い回しが重要なら再実行できます。完全な steps[] と warnings の形や、非クリティカルな失敗がどう completed_with_warnings に集約されるかについては、パイプライン実行を観察する を参照してください。
非クリティカルとは、設計上のベストエフォート
rephrase を有効にしても、ジョブの信頼性が下がることはありません。最悪でも、このステージがなければ出荷していた翻訳に警告が付くだけです。だからこそ、幅広く有効にしても、磨かれたコピーを依存条件ではなく上乗せの品質改善として扱えます。
有効にするべき場面、スキップするべき場面#
rephrase が最適化するのは、ただ一つ。ネイティブが最初から書いた文章のように読めることです。これがぴったりなコンテンツもあれば、まったく向かないコンテンツもあります。だからこそ、これはグローバルなデフォルトではなく、コンテンツごとに判断すべき選択です。
有効にする対象: マーケティングコピー、ランディングページ、製品説明、オンボーディングなど。原文の言い回しに寄せることより、ネイティブが書いた自然なコピーとして読めることのほうが重要な場面です。
スキップする対象: 技術文書や法務コンテンツ。ここでは逐語的な正確さが最優先です。rephrase は自然に響くよう表現を書き換えるため、契約条項、API リファレンス、コンプライアンス関連の文言では、原文に近い wording のほうが安全です。そうしたコンテンツでは rephrase をオフにして、core localization ステップの出力をそのまま使ってください。
自然な言い回しには、必ずトレードオフがある
rephrase は、意図的にコピーを原文の言い回しから離します。それがマーケティングでは価値になり、文言の正確さに法的・技術的な重みがある場面ではリスクになります。どちらに当たるか迷うペイロードなら、rephrase はスキップしてください。より安全なデフォルトは literal です。
有効にする方法#
rephrase の設定方法は、他のすべてのステージと同じです。エンジンレベルのデフォルトに加え、リクエストごとの任意オーバーライドも使えます。詳しい設定手順は パイプラインを設定する にありますが、要点だけ言えば、すべてのジョブに適用するならエンジンの Pipeline タブで切り替え、単一の送信だけに適用するなら pipelineConfig を設定します。
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship global products faster." },
"pipelineConfig": {
"rephrase": { "enabled": true }
}
}省略したステージはエンジン設定を引き継ぎます。つまり、上記のオーバーライドなら他のステージには触れず、この送信に対してだけ rephrase をオンにできます。これにより、逐語性が重要なコンテンツではエンジン側で rephrase をオフのままにしつつ、必要なマーケティング向けペイロードでだけリクエスト単位でオンにできます。
