実行するパイプラインステージは、2つのレイヤーで決まります。エンジンのデフォルト設定と、単一リクエストでの任意の上書きです。
コア翻訳ステップの前後に、どのステージを入れるかはすでに決まっているはずです。次に考えるのは2つだけです。その判断をどこに持たせるか、そして1件のジョブだけ他と違う設定が必要なときにどうするか。答えは、2つのレイヤーです。エンジンには、すべての非同期ジョブが継承するデフォルトがあります。単一の送信に含めるpipelineConfigオブジェクトは、その送信に限ってそのデフォルトを上書きします。上書きで省略したステージはエンジン設定を継承するため、リクエストでは差分だけを指定すれば十分です。
パイプラインが初めてなら、まずはパイプライン概要をご覧ください。各ステージの役割を説明しています。このページで扱うのは、各ステージの動作そのものではなく、有効化の方法と上書きの仕組みです。
非同期ジョブのみ
パイプライン設定が適用されるのは、Async Localization API経由で作成されたジョブだけです。同期の/localizeエンドポイントはコア翻訳ステップのみを実行し、どちらのレイヤーのパイプライン設定も完全に無視します。
エンジンレベルのデフォルト#
ダッシュボードでエンジンのPipelineタブを開き、各ステージを個別に切り替えます。この設定が、そのエンジンのデフォルトになります。そこにルーティングされたすべての非同期ジョブは、リクエストで上書きしない限り、このステージ構成で実行されます。一度設定しておけば、呼び出しのたびにパイプラインを指定し直す必要はありません。
各ステージは独立したスイッチです。どれも有効にしないことも、すべて有効にすることも、その中間の任意の組み合わせにすることもできます。
- Pre-localization AI edit – 翻訳前にソースを整えます。
- Post-localization human review – Internal または External のレビューに回します。同じパネルでモード、ティア、タイムアウトを選べます。
- Post-localization AI review – 人によるレビューが有効になるまで無効のままで、人の編集結果をエンジンルールに沿うよう調整します。
- Rephrase for natural copy – ネイティブらしく自然に読める表現へ書き換えます。ほかのステージとは独立しています。
- Back-translation check – 往復翻訳を経ても意味が保たれているかを確認します。ほかのステージとは独立しています。
Core localizationはスイッチではなく、常に実行されます。各ステージはその前後を囲む形で動作します。
デフォルトはすべてのジョブが継承するため、エンジン設定はpipelineConfigの上書き先となるベースになります。各ステージは1つのキーに対応します。
{
"preEdit": { "enabled": true },
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
},
"postEdit": { "enabled": false },
"rephrase": { "enabled": false },
"backTranslation": { "enabled": true }
}| キー | フィールド | ステージページで設定 |
|---|---|---|
preEdit | enabled | Pre-localization AI edit |
humanEdit | enabled, provider (internal | gengo), tier (standard | pro), timeoutHours | Human review |
postEdit | enabled | AI評価 |
rephrase | enabled | Rephrase for natural copy |
backTranslation | enabled | Back-translation check |
各フィールドが何を制御するのか――どのレビュー提供元を使うか、どのティアにするか、どれだけ待つか――は、それぞれのステージ専用ページで説明しています。このページのテーマは、設定がどこにあり、2つのレイヤーがどう組み合わさるかです。
リクエスト単位の上書き#
ほとんどのジョブは、エンジンのデフォルト設定のままで実行するのが基本です。例外は、別のパイプラインが必要な単発の送信です。たとえば、普段は無効にしているリフレーズステージを使いたいマーケティングコピーの一括処理や、逆にそれをスキップしたい法務向けペイロードなどです。1回限りのバッチのためにエンジン設定を変更すると、ほかのすべてのジョブにも影響してしまいます。
そこで、差分だけをリクエスト側で渡します。POST /jobs/localizationのボディにpipelineConfigオブジェクトを追加すると、その送信に限ってエンジンのデフォルトを上書きできます。エンジン自体の設定は変わらないので、次のジョブで上書きがなければデフォルトに戻ります。
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship in every language." },
"pipelineConfig": {
"rephrase": { "enabled": true },
"backTranslation": { "enabled": false }
}
}これが継承ルールであり、上書きをコンパクトに保てる理由でもあります。指定したステージは上書きされ、指定しないステージはエンジンのデフォルトを継承します。 上のリクエストでは、この1件のジョブに対してrephraseをオンにし、backTranslationをオフにしています。preEdit、humanEdit、postEditは指定されていないため、エンジンで設定されたとおりに実行されます。指定するのは差分だけです。
ステージを含めるなら、そのステージ全体を指定する
上書きはフィールド単位ではなく、ステージ単位です。含める各ステージは、そのステージ全体の完全なオブジェクトである必要があります。humanEdit: { "tier": "pro" }だけを送ってティアだけ変更し、残りを継承するといったことはできません。上書きするならステージ全体を含め、継承するなら省略します。1つのステージオブジェクトの中で部分的にマージされることはありません。
上書きでできないことが、もう2つあります。ここは何でもできそうに見える部分なので、はっきり書いておきます。
- 変更されるのはその送信だけです。エンジンに書き戻されることはないため、永続的な設定変更の手段ではありません。それを行う場所はPipelineタブです。単発対応には上書きを使い、新しい標準にするならタブで変更してください。
- ステージ固有の実行時ルールが緩和されるわけでもありません。Post-localization AI reviewは、人によるレビューで出力が生成された場合にのみ実行されます。そのため、人によるステージがなく調整対象がないジョブで
postEditを有効にしても何も起きません。どのレイヤーで有効にした場合でも同じです。
実行内容を確認する#
設定で決まるのは、どのステージを実行すべきかです。実際にどのステージが動いたかは、ジョブ自体の記録で確認します。ジョブにはsteps[]配列があり、リクエスト単位の上書きが本当に反映されたかを確認するのはこの配列です。送っただけでは確認になりません。
各ステージのstepIdの読み方、skippedステップの意味、重大ではない失敗がどこに現れるかについては、別ページで説明しています。
次のステップ#
デフォルトはエンジンで設定し、必要なときだけリクエストごとに上書きできます。次は、上書きを含むジョブを送信するか、ステップを確認してどのステージが実行されたかを見てみましょう。
