|
ドキュメント
デモを予約プラットフォーム
プラットフォームMCPCLIAPI
ワークフロー
ガイド変更履歴

ようこそ

  • 概要
  • 認証
  • エラーとステータスコード
  • Webhookシグネチャ

ローカライゼーション

  • 概要
  • ジョブを作成
  • 翻訳対象外のキーをロックする
  • ジョブグループを追跡
  • 単一ジョブを取得
  • ジョブ一覧
  • Webhook配信
  • リアルタイム進捗(WebSocket)

パイプライン

  • 概要
  • ローカライズ前のAI編集
  • 人によるレビュー
  • AI評価(ポストエディット)
  • 自然なコピーに言い換える
  • 逆翻訳チェック
  • パイプラインを設定
  • パイプライン実行を確認する

プロビジョニング

  • 概要
  • プロビジョニングジョブを作成
  • ソースの種類
  • AIが抽出するもの
  • Webhook配信
  • ライブ進行状況(WebSocket)

同期

  • Localize
  • Recognize

エンジン管理

  • エンジン提案

単一ジョブを取得

1 つのロケールの翻訳結果と、その生成過程を示すステージ別の記録を取得します。

このエンドポイントを使うのは、すでに jobId を持っているときです。これは create の 202 レスポンスで返されることもあれば、webhook で受け取ることもあり、job group の一覧に含まれることもあります。グループエンドポイントでわかるのは、完了したロケールが いくつ あるか。このエンドポイントでわかるのは、特定の 1 ロケールが 何を 生成したか、そして途中で何が起きたかです。

text
GET /jobs/localization/:jobId

非同期ローカライゼーションが初めてなら、まずは 概要 からどうぞ。

この違いこそが、このページの要点です。グループレスポンスはスコアボードのようなもので、件数とジョブごとのステータスを返します。詳しくは job group のページをご覧ください。一方、単一ジョブは 1 つのロケールに関する完全な記録 です。翻訳済みの outputData、最終的な status、必要に応じた warnings、そして pipeline が実行したすべてのステージをたどれる steps[] の履歴が含まれます。データベースにドイツ語コピーを書き込む段階になったら、そのドイツ語コピーを受け取るのがこの呼び出しです。

認証#

API キーは X-API-Key ヘッダーで渡します。キーは組織スコープで、その組織内のすべてのエンジンにアクセスできます。詳しくは Authentication を参照してください。

レスポンス#

outputData フィールドは、入力した data の構造をそのまま反映します。文字列の値はすべて翻訳され、文字列以外の値(数値、ブール値、null)はそのまま保持されます。キーもネストも配列順も変わらず、変わるのは文字列だけです。

json
{
  "id": "ljb_A1b2C3d4E5f6G7h8",
  "groupId": "ljg_A1b2C3d4E5f6G7h8",
  "targetLocale": "de",
  "status": "completed",
  "outputData": {
    "id": "course_101",
    "title": "Einführung in maschinelles Lernen",
    "steps": [
      { "heading": "Was ist ML?", "body": "Maschinelles Lernen ist ein Teilbereich der künstlichen Intelligenz." },
      { "heading": "Überwachtes Lernen", "body": "Trainieren eines Modells mit gelabelten Daten." }
    ],
    "metadata": { "author": "Dr. Smith", "difficulty": "beginner" }
  },
  "errorMessage": null,
  "warnings": [],
  "callbackStatus": "delivered",
  "createdAt": "2026-03-16T10:30:00.000Z",
  "startedAt": "2026-03-16T10:30:01.000Z",
  "completedAt": "2026-03-16T10:30:04.000Z",
  "steps": [
    {
      "stepId": "localize",
      "type": "action",
      "status": "completed",
      "errorMessage": null,
      "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:04.000Z"
    }
  ]
}

上の metadata ブロックは手つかずのまま残っています。Dr. Smith と beginner は文字列ではないリーフ値なので、エンジンは変更していません。返ってきた outputData は送信時と同じ形を保っているため、ペイロードを組み立てたのと同じコードで、そのまま翻訳結果を扱えます。

フィールド説明
idこのジョブ自身の ID(ljb_…)。パスに渡した値です。
groupIdこのジョブが属する親ジョブグループ(ljg_…)。job-group エンドポイント に渡せば、同じグループ内のロケールをまとめて確認できます。
targetLocaleこのジョブの翻訳先である BCP-47 ロケール。ジョブはターゲットロケールごとに 1 件ずつ作成されます。outputData を適切な列やファイルに振り分ける際に分岐するのがこのフィールドです。
statusqueued、processing、completed、completed_with_warnings、または failed。
outputData入力構造に対応する翻訳済みコンテンツ。status が completed または completed_with_warnings の場合に含まれます。
errorMessageエラー内容。status が failed の場合に含まれ、それ以外では null です。
warnings非クリティカルな pipeline ステージの失敗。各エントリは { step, message } です。status が completed_with_warnings でない限り空です。
callbackStatusWebhook の配信状態。pending、delivered、または failed。コールバック URL が設定されていない場合は null です。
createdAtジョブが受理された時刻(作成時の 202 のタイムスタンプ)。
startedAtエンジンがこのロケールの翻訳を開始した時刻。ジョブが queued を抜けると設定されます。
completedAtジョブが終端状態に到達した時刻。status が completed、completed_with_warnings、または failed になると設定されます。
stepsステージごとの実行記録。常に localize ステップを含み、有効化した任意の pipeline ステージごとに 1 エントリずつ追加されます。完全な記録形式は Observe pipeline runs を参照してください。

ジョブ完了まで outputData は null

status が queued または processing の間は、outputData は空で、errorMessage は null です。つまり、まだ読むべき内容はありません。status が completed または completed_with_warnings になってから outputData を読み、failed の場合は代わりに errorMessage を確認してください。まず status で分岐し、そのあとでペイロードに触れましょう。

ジョブステータス値#

ジョブは queued から processing へ進み、その後は必ず 1 つの終端状態に到達します。ほかのフィールドを見る前に、まず status で分岐してください。どのフィールドに値が入るかは、これで決まります。

ステータス意味読むもの
queued受理済み。まだ開始していません。まだ何もありません。ポーリングするか、webhook を待ってください。
processingエンジンがこのロケールを翻訳中です。まだ何もありません。
completed翻訳が完了し、有効なすべてのステージが成功しました。outputData。
completed_with_warnings翻訳は完了しており、outputData も揃っていますが、非クリティカルな pipeline ステージのいずれかが失敗しています。outputData を確認し、そのあと warnings を見てください。
failedこのジョブでは翻訳結果が生成されませんでした。errorMessage。

completed_with_warnings でも翻訳は返ります

completed_with_warnings はソフトエラーではありません。完全な outputData が返されるため、コアの翻訳ステップ自体は成功しています。違いは、非クリティカルなステージ(たとえば pre-edit や back-translation)のいずれかが完了しなかった点であり、その失敗はそれぞれ warnings に { step, message } として記録されます。出力自体は利用可能なものとして扱い、warnings は翻訳をレビューする人に共有すべき品質シグナルとして捉えてください。翻訳結果そのものが存在しないのは failed の場合だけです。

未知のステータス値に備える

現時点での契約は、上記 5 つのステータス値です。ただし pipeline ステージは進化していくため、status は開かれた集合として扱ってください。既知の値には分岐を用意し、想定外の値は、outputData があればそれを読み、なければログを残すデフォルト処理に流すのが安全です。フォールバックのない switch は、新しい状態が追加されたその日に壊れるコードになりがちです。

steps 配列#

steps[] は、単一ジョブのステージ別の実行履歴です。エンジンが実行した各ステージについて、順番どおりに 1 レコードずつ入ります。すべてのジョブには最低でも localize ステップが含まれます。コア翻訳は必ず実行されるためです。有効化した各 pipeline ステージごとに、さらに 1 レコードが追加されます。つまり、追加ステージがなければ localize ステップが 1 つだけ、pre-edit と back-translation を有効にしていれば 3 つのレコードが並びます。

これによって、ジョブはブラックボックスではなく、監査可能なものになります。ステージが実行されたかどうかを信じる必要はありません。記録を見れば、どのステージか(stepId)、それが completed したのか、failed したのか、あるいは skipped されたのか、いくらかかったのか(costUsd)、いつ開始していつ終わったのかまで確認できます。人手によるレビューのステージでは、externalRef* が外部レコードを指します。

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

ここで failed エントリがあっても、必ずしもジョブ全体が失敗したことにはなりません。非クリティカルなステージが失敗した場合、その steps[] レコードは failed となり、同じ失敗がジョブ上位レベルの warnings にも現れます。それでもジョブは、完全な outputData を伴ったまま completed_with_warnings に到達します。完全な記録形式、つまり全フィールド、すべての stepId、completed/failed/skipped の意味については、正規の 1 ページである Observe pipeline runs にまとまっています。このページではジョブ内のどこを見るかを示し、詳細な仕様はそちらで定義しています。

完了済みジョブを読む#

一般的な利用側の実装では、まず status で分岐し、成功時には outputData を書き込み、失敗時には errorMessage をログに残します。以下のそのまま使える呼び出しは、上で示したペイロードを返します。

javascript
const jobId = "ljb_A1b2C3d4E5f6G7h8";
const response = await fetch(`https://api.lingo.dev/jobs/localization/${jobId}`, {
  headers: { "X-API-Key": process.env.LINGO_API_KEY },
});

const job = await response.json();

switch (job.status) {
  case "completed":
  case "completed_with_warnings":
    // outputData is populated; warnings may carry non-critical stage failures
    await db.content.update({
      where: { id: job.outputData.id },
      data: { [`content_${job.targetLocale}`]: job.outputData },
    });
    if (job.warnings.length) console.warn(job.targetLocale, job.warnings);
    break;
  case "failed":
    console.error(`${job.targetLocale} failed: ${job.errorMessage}`);
    break;
  default:
    // queued or processing - nothing to read yet; also catches future states
    break;
}

ポーリングとプッシュ

このエンドポイントは、その時点の状態を返す読み取りです。ほとんどのジョブで、エンジンはロケールごとに 2〜8 秒かかるため、ポーリングするなら 2 秒間隔から始めるのが妥当です。ポーリングを完全に避けるなら、webhook を登録して、ロケールの完了通知を受けたときだけジョブを取得するか、WebSocket でグループ全体を監視してください。どちらの場合でも、ここで得られる最終的な GET が outputData の正規の読み取り結果です。

このエンドポイントがエラーを返す場合—たとえば未知の jobId やキーの欠落など—は、標準の JSON エラーモデルに従います。詳しくは Errors and status codes を参照してください。

次のステップ#

ジョブグループを追跡
全ロケールをまたいだ集計件数を確認し、部分的な失敗にも対応する
ジョブ一覧
カーソルベースのページネーションでジョブをたどり、ステータスやエンジンで絞り込む
ライブ進捗(WebSocket)
ポーリングせずに、各ジョブの完了に応じたロケール別ステータスを確認する

このページは役に立ちましたか?

Max PrilutskiyMax Prilutskiy·更新済み 約2か月前·3分で読めます