ソースの誤字は、増える前なら一度直せば済む誤字です。非同期ジョブでは、1つのソースペイロードがすべてのターゲットロケールに展開され、各ロケールは受け取ったテキストをそのまま翻訳します。つまり、ソース内のスペルミス、抜け落ちた単語、不完全な文は、それ単体の問題では終わりません。ドイツ語でも、フランス語でも、そのジョブが触れる他のすべてのロケールでも同じ問題になり、後からそれぞれ修正する必要が出てきます。
ローカライズ前のAI編集（preEdit）は、そのギャップをソースの段階で埋めます。これはasync localization pipelineの最初のステージです。中核の翻訳ステップが走る前に、AIエージェントがソースペイロードをレビューし、誤字、文法ミス、スペルミスを修正します。翻訳されるのは、この整えられたソースです。つまり、同じエラーを何本もの出力で後から拾うのではなく、展開前に一度だけ直せます。
これはasync pipelineのステージなので、Async Localization API経由で作成されたジョブでのみ実行されます。同期の/localize endpointでは中核の翻訳ステップだけが実行され、パイプライン設定は無視されます。
このステージでできること#
preEditが対象にするのは翻訳ではなくソースです。AIエージェントがソースペイロードを読み取り、誤字、文法、スペルといった表層的なエラーを取り除くように書き直したうえで、修正済みのテキストを中核のローカライゼーションステップに渡します。すべてのターゲットロケールは、その整えられたソースをもとに翻訳されます。
対象範囲は意図的に絞られており、そこが重要です。これはリライトではなく、コピーを整えるためのパスです。翻訳モデルにとってソースを曖昧にしてしまう表層ノイズを取り除くことで、モデルが崩れた文の意味を推測するのではなく、翻訳そのものに集中できるようにします。ソースがきれいになるほど、ロケール間での翻訳の一貫性も高まります。各モデルが同じエラーをそれぞれに解釈するのではなく、すべてのロケールが同じ修正済みテキストから始まるからです。
慣用的でネイティブらしい出力、つまり翻訳そのものを、ネイティブのコピーライターが書いたような自然な文章に整える処理は別のステージです。自然なコピーのためのリフレーズを参照してください。preEditは入力を整え、rephraseは出力を磨きます。
ジョブを悪化させることはありません#
翻訳前にコンテンツを編集するAIステップについて、慎重なエンジニアが最初に気にするのはもっともです。そのステップが間違えたらどうなるのか。あるいは、そもそも動かなかったらどうなるのか。
preEditは非クリティカルなステージです。事前編集の呼び出しが失敗したりタイムアウトしたりしても、元のソースは変更されないまま通過し、ステージがオフだった場合とまったく同じようにジョブは翻訳ステップへ進みます。ここで失うのは、そのジョブでのクリーンアップだけであって、ジョブそのものではありません。翻訳はそのまま出荷されます。
事前編集が失敗したりタイムアウトしたら？
ジョブは失敗しません。非クリティカルなステージは入力にフォールバックします。preEditで失敗が起きた場合は、未編集のソースがそのまま翻訳され、ジョブは最後まで完了します。ジョブステータスはcompleted_with_warningsになり、preEditステップはfailedとして記録され、その理由はジョブのwarnings配列に格納されます。つまり、配信を止めることなく、何が起きたかを確認できます。これらのステップ記録の読み方については、パイプライン実行を観測するで説明しています。
率直に言えば、最低ラインはこうです。preEditを有効にしても、本来なら成功していたジョブが失敗することはありません。最悪でも、そのジョブでは役に立たず、静かに脇に回るだけです。
できないこと#
ここは、つい期待を大きくしたくなるところだからこそ、はっきりしておく価値があります。preEditはベストエフォートであり、表層的なエラーを整えるためのコピークリーンアップです。あなたのドメインを理解した校正者でも、主張の正しさを検証するファクトチェッカーでもありません。修正するのは誤字、文法、スペルです。価格が正しいか、製品名が最新か、その文が本当に意図どおりの内容を伝えているかまでは確認しません。ソースに事実誤認があれば、preEditはその誤った文の文法だけを整え、それを各ロケールにきれいに翻訳します。
どのAIパスを通っても、必ずそのまま維持したい語句 — 製品名、商標、コード識別子など — は、ソース側で固定してください。エンジンのglossaryで非翻訳としてマークするか、特定のペイロード内の構造フィールドであればlockedKeysで除外します。これらはデータに対する保証です。preEditは、その周囲で動くベストエフォートのクリーンアップにすぎません。
有効にするべきタイミング#
preEditが追加の1パスに見合うのは、ソースにノイズが含まれがちな場合です。逆に、ソースがすでにきれいなら冗長です。
- 有効にするべき場合: ソースコンテンツがユーザー生成、機械抽出、スクレイピング、OCR処理済み、または編集プロセスを経ずに作成されたものである場合。こうしたケースでは表層的なエラーが起きやすく、それがロケール全体に広がるコストも無視できません。
- スキップすべき場合: すでに編集または人手のレビューを通過した、キュレーション済みのコンテンツ。ソースがきれいなら、このステージに直すものはありません。やることのないAIパスにコストを払うだけです。有効にした各ステージは、ジョブに追加される1ステップであり、コストにも1行加わります。ソース品質が不確かなときには価値がありますが、そうでなければ無駄になります。
トレードオフはそれだけです。ソース品質が不確かなジョブでは最初に1パス使って、展開前に一度だけ直す。そうでなければ、配信後に各ロケールで同じエラーを何度も直すことになります。
preEditはエンジンのPipelineタブで切り替えられ、そのエンジンにルーティングされるすべての非同期ジョブに適用されます。あるいは、create-jobsリクエストのpipelineConfigで、個別の送信に対して上書きすることもできます。この2つのレイヤーと、省略されたステージがどのようにエンジンのデフォルトを引き継ぐかについては、パイプラインを設定するで説明しています。
