パイプライン実行を確認する

有効になっている各パイプラインステージはジョブに1件ずつ記録を残すため、動いたと信じるのではなく、実際に何が実行されたかを確認できます。

いくつかのpipelineステージを有効にしたとします。たとえば、ソースを整えるpre-editや、ズレを検出するback-translationです。するとジョブが completed_with_warnings で返ってきました。どのステージで止まったのか。人手のレビューは本当に行われたのか、それともタイムアウトしたのか。追加したステージはいくらかかったのか。ロケールごとにAIと人手の複数ステップが走るパイプラインは、まさにブラックボックス化しやすい仕組みです。結果だけが返ってきて、その途中のステージがきちんと仕事をしたかどうかは、信じるしかない状態になりがちです。

でも、ここでは信じる必要はありません。有効な各ステージは、ジョブのsteps[]配列に1件ずつ記録を書き込みます。どのステージか、どんなステータスだったか、いくらかかったか、いつ始まっていつ終わったか。各ステージが何をしたかを読むのであって、実行されたと鵜呑みにするわけではありません。 それがこのページの役割です。

このページの内容

• 記録はどこにあるか
• steps 配列
• stepId とステージの対応
• ステップのステータス: completed、failed、skipped
• ステップの失敗がジョブ警告になる仕組み

記録はどこにあるか#

steps[]配列は、ローカライゼーションジョブのフィールドです。別で取得する必要はなく、ジョブを読むたびに一緒に返ってきます。

GET /jobs/localization/:jobId

APIキーは X-API-Key ヘッダーで認証します。完全なエンドポイント、job status の値、そして outputData ペイロードについては、単一ジョブのページで説明しています。このページで扱うのは、そのレスポンスの中の1フィールド、つまりステージごとの実行履歴と、そこから読み取れることです。

ルールはシンプルです。取得したすべてのジョブには、すでにそのジョブ自身の監査ログが含まれています。パイプラインを有効にしていないジョブでも、core localization が常に走るため、記録は1件あります。任意ステージを2つ有効にすれば、記録は3件です。配列はパイプラインに応じて増え、ステージごとに1エントリずつ、実行順で並びます。

steps 配列#

steps[]の各エントリは、1つのステージの記録です。実行内容を監査するときに見るフィールドは次のとおりです。どのステージか、どんな結果だったか、いくらかかったか、そしていつ動いたかです。

"steps": [
  {
    "stepId": "preEdit",
    "type": "action",
    "status": "completed",
    "errorMessage": null,
    "costUsd": 0.0012,
    "externalRefType": null,
    "externalRefId": null,
    "externalRefUrl": null,
    "createdAt": "2026-03-16T10:30:01.000Z",
    "startedAt": "2026-03-16T10:30:01.000Z",
    "completedAt": "2026-03-16T10:30:02.000Z"
  },
  {
    "stepId": "localize",
    "type": "action",
    "status": "completed",
    "errorMessage": null,
    "costUsd": 0.0184,
    "externalRefType": null,
    "externalRefId": null,
    "externalRefUrl": null,
    "createdAt": "2026-03-16T10:30:02.000Z",
    "startedAt": "2026-03-16T10:30:02.000Z",
    "completedAt": "2026-03-16T10:30:05.000Z"
  }
]

各レコードには outputData フィールドもあります。ここにはそのステージが生成したコンテンツが入り、形はジョブの outputData と同じです。このペイロードは監査ログではなく翻訳そのものなので、ジョブレベルの outputData とあわせて 単一ジョブのページで説明しています。パイプラインが何をしたかを見るなら、読むべきなのは上のフィールドです。

これらのレコードからは、単一のoutputDataブロブでは見えないことが2つわかります。まず、コストがジョブ合計ではなくステージごとに明細化されること。だから back-translation を有効にして請求額が動いたときも、どのステージが押し上げたのかを正確に確認できます。次に、時間もステージ単位で見えること。humanEdit レコードで startedAt と completedAt の間が何時間も空いていれば、待ち時間の原因がエンジンではなく人手だったとわかります。

stepId とステージの対応#

各 stepId は1つのパイプラインステージを表します。以下は、レコードの値と、それが指すステージ、そのステージの動作を説明するページの対応表です。

localize は、パイプラインの有無にかかわらずすべてのジョブに現れる唯一の stepId です。これは コア翻訳ステップ で、常に実行されます。残りの5つは、そのステージをエンジンまたはリクエストで有効にしたときにだけ現れます。

ステップのステータス: completed、failed、skipped#

各ステップは独自の status を持ち、ジョブ全体や他のステップとは独立して設定されます。値は3つです。

completed と failed はそのままの意味です。少し立ち止まって見るべきなのは skipped で、これは "disabled" と同じではありません。そもそも有効にしていないステージは、レコード自体が作られません。一方で skipped レコードは、そのステージが有効だったにもかかわらず、パイプラインのルールに従って今回は通過したことを意味します。いちばんわかりやすいのは human review です。レビュー期間が人手からの応答なしで終了すると、そのステージは skipped と記録され、AI翻訳がそのまま最終結果として引き継がれます。レコードは残るので、スキップは見えないままにはなりません。

ステップの失敗がジョブ警告になる仕組み#

非クリティカルなステージが失敗すると、その失敗は同時に2か所に現れます。見ているのは同じ出来事の2つの表示です。steps[] レコードでは failed と errorMessage になり、これが詳細ビューです。同じ失敗は、ジョブ最上位の warnings 配列にも1エントリとして現れます。こちらは、ステータス処理コードが分岐に使う要約ビューです。

{
  "id": "ljb_A1b2C3d4E5f6G7h8",
  "status": "completed_with_warnings",
  "outputData": { "title": "Hallo" },
  "warnings": [
    { "step": "backTranslation", "message": "Back-translation check did not complete" }
  ],
  "steps": [
    { "stepId": "localize", "type": "action", "status": "completed", "errorMessage": null, "costUsd": 0.0184, "completedAt": "2026-03-16T10:30:05.000Z" },
    { "stepId": "backTranslation", "type": "action", "status": "failed", "errorMessage": "Back-translation check did not complete", "costUsd": 0.0031, "completedAt": "2026-03-16T10:30:11.000Z" }
  ]
}

各 warnings エントリは { step, message } で、そこでの step は失敗したレコードにある stepId と同じ値です。つまり2つの配列は対応しています。warnings は何が問題だったかの短い一覧で、各項目の詳細を見る場所が steps[] です。ロケールを人手確認に回すべきか判断するなら warnings を読み、対応する steps[] レコードを見れば、その背景にある errorMessage、コスト、タイミングまで追えます。

これが completed_with_warnings の仕組みです。コア翻訳は成功しているので、使える outputData はあります。ただし少なくとも1つの非クリティカルなステージで failed レコードと対応する警告が残っています。出力はそのまま出荷可能なものとして扱い、警告は可視化すべき品質シグナルとして扱ってください。翻訳そのものが存在しないのは、ジョブの status が failed のときだけです。この判断と完全な job status テーブルについては、単一ジョブのページにあります。

次のステップ#