JA
元のCottonロゴから背景と文字を取り除いた、笑顔の綿のキャラクター
展示室へ戻る

Cotton

Translation workflow

生成された翻訳を、レビューできる結果へ。

ゲームのセリフのための翻訳ワークフローです。

2026.05.06 — 2026.05.26

業務プロジェクト · 翻訳の処理、判定、レビューの経路

  • Webアプリ実装済み · 開発環境

スコア、再試行、人によるレビューを、それぞれの境界に。

生成と判定は用語集を共有し、判定モデルが報告したハードゲートの失敗は平均スコアで相殺できません。翻訳と判定の中間状態を記録し、再試行とコストの上限を認証情報の枯渇とは区別し、停滞したジョブは原因に応じてキューかレビューに戻します。

この業務プロジェクトは、翻訳の生成、モデルが報告する品質判定、再試行、人によるレビューを1つの流れにつないでいます。

リポジトリの開始から、参加期間中に確認した作業まで

翻訳の編集・承認画面、API、ジョブワーカーからなるWebアプリで、開発環境で動作しています。

判定フロー構成図 · 非公開の実装記録に基づく
Cottonの翻訳判定 · 再試行 · 復旧APIは原文と対象ロケールをデータベースにコミットした後、対象ロケールごとにジョブをキューに入れます。ワーカーは行をロックして試行を確認し、draftと進捗状態を作成し、用語集を使って翻訳を生成したうえで、同じ用語集で判定モデルを別途呼び出します。翻訳（Tx1）と、根拠を伴う判定（Tx2）は別々のトランザクションで記録されます。コードが判定を集計するため、ハードゲートの失敗は平均で相殺されません。通過すれば確定し、失敗すれば次のターンへ、ターンまたはコストの上限に達すれば人によるレビューへ、クォータや認証のシグナルがあれば支出を止めて認証情報の確認を待ちます。停滞スイープは10分を超えたdraftを最大200件調べ、試行が残っているのにキューにないものは再びキューに入れ、試行を使い切ったものは結果の有無に応じてレビューか認証情報の確認へ送ります。原文 · 対象ロケール保存されたセグメント人によるレビューneeds_review · 承認ではない認証情報の確認needs_credentialAPI · ジョブ登録コミット後にキューへジョブキューBullMQ · ジョブIDジョブの開始行ロック · 試行の確認用語集 · コンテキストワークスペースの用語集翻訳ターン生成 · モデル呼び出し判定モデル呼び出し · パース判定ルールハードゲート · 加重平均再試行 · 支出ターン · コスト · クォータ翻訳の状態draft · 進捗翻訳 · 判定の行状態 · 呼び出しログ確定確定トランザクションキューの確認キュー状態の比較停滞スイープ10分超のdraft · 最大200入力 · キュー生成 · 判定状態 · 受け入れ復旧 · 人の判断1原文2コミット後3 ジョブの受け渡し · BullMQ · ジョブID → 行ロック · 試行の確認34進捗行5試行を許可1用語集2同じ用語集3Tx1 · 翻訳4Tx2 · 判定5スコア · ゲート6判定7pass8確定記録1判定2次のターン3上限 · 中断4クォータ · 認証5手動再開1停滞したdraft2上限未満3再投入4結果あり5結果なし

登録 → 開始

データベースのコミット後にキューに入れ、ワーカーが行をロックして試行を確認し、draftを作成します。

  1. 原文 · 対象ロケール原文コミット後にキューへAPI · ジョブ登録

    原文のセグメントとプロジェクトの対象ロケールがデータベースに保存されます。顧客データは表示しません。

  2. コミット後にキューへAPI · ジョブ登録コミット後BullMQ · ジョブIDジョブキュー

    データベースのコミット後、有効な対象ロケールごとに、リクエスト単位で決まるIDを持つジョブをキューに入れます。キュー登録に失敗しても警告をログに残すだけで、コミットは巻き戻しません（アトミックなoutboxはありません）。停滞スイープがあるのはそのためです。

  3. BullMQ · ジョブIDジョブキュージョブの受け渡し行ロック · 試行の確認ジョブの開始

    BullMQがジョブをワーカーへ非同期に渡します。

  4. 行ロック · 試行の確認ジョブの開始進捗行draft · 進捗翻訳の状態

    トランザクション内で進捗行をロックし、draftの翻訳を作成します。確定済みのジョブや認証情報の問題で一時停止したジョブの自動再試行は飛ばし、手動の要求は別に扱います。

  5. 行ロック · 試行の確認ジョブの開始試行を許可生成 · モデル呼び出し翻訳ターン

    試行回数を上限内で1つ増やしてから、翻訳ターンを始めます。

生成 → 判定 → 確定

生成と判定は同じ用語集を使い、翻訳と判定を別々に記録したうえで、コードが判定を集計して確定します。

  1. ワークスペースの用語集用語集 · コンテキスト用語集生成 · モデル呼び出し翻訳ターン

    ワークスペースの用語集とコンテキストを照会し、生成に渡します。

  2. ワークスペースの用語集用語集 · コンテキスト同じ用語集判定モデル呼び出し · パース翻訳ターン

    判定にも同じ用語集の制約を渡します。

  3. 生成 · モデル呼び出し翻訳ターンTx1 · 翻訳翻訳 · 判定の行翻訳の状態

    モデルを直接、またはen-USのピボットを介して呼び出し、呼び出し、イベント、進捗を1つのトランザクションで書き込みます。クラッシュ後にジョブが再実行されると、翻訳の呼び出しとそのコストが繰り返されることがあります。

  4. 判定モデル呼び出し · パース翻訳ターンTx2 · 判定翻訳 · 判定の行翻訳の状態

    判定スコアと根拠は翻訳とターンごとに1回だけ挿入し、重複時は既存の行を見つけます。引用は最初の挿入時にだけ書き込みます。翻訳と同じトランザクションではありません。

  5. 判定モデル呼び出し · パース翻訳ターンスコア · ゲートハードゲート · 加重平均判定ルール

    判定モデルの応答をパースして、次元ごとのスコアとゲートの結果にします。用語集を通過したかどうかは、判定モデルが報告するものです。

  6. ハードゲート · 加重平均判定ルール判定ターン · コスト · クォータ再試行 · 支出

    報告されたハードゲートの失敗が1つでもあれば0点で不合格とし、そのあとで加重平均と次元ごとの基準を適用します。総合基準の8.0は設定の既定値であり、観測された翻訳品質ではありません。

  7. ターン · コスト · クォータ再試行 · 支出pass確定トランザクション確定

    通過した翻訳はtranslatedとして確定します。

  8. 確定トランザクション確定確定記録状態 · 呼び出しログ翻訳の状態

    候補、状態、スコア、ターンを確定し、進捗のfinalizedと状態ログを1つのトランザクションで書き込みます。翻訳完了イベントはtranslatedの場合にのみ発行します。

再試行 · 支出の上限

通過しなければ次のターン、上限に達すれば人によるレビュー、クォータや認証なら支出を止めて運用者の再開を待ちます。

  1. ハードゲート · 加重平均判定ルール判定ターン · コスト · クォータ再試行 · 支出

    報告されたハードゲートの失敗が1つでもあれば0点で不合格とし、そのあとで加重平均と次元ごとの基準を適用します。総合基準の8.0は設定の既定値であり、観測された翻訳品質ではありません。

  2. ターン · コスト · クォータ再試行 · 支出次のターン生成 · モデル呼び出し翻訳ターン

    通過しなかった翻訳は、前回の翻訳と講評を添えて再生成されます。ハードゲートの失敗でも、すぐに人へ回さず、先に再試行することがあります。

  3. ターン · コスト · クォータ再試行 · 支出上限 · 中断人によるレビュー

    ターンを使い切るかコストの上限に達すると、needs_reviewとして確定します。finalizedは処理の終了を意味し、人による承認を意味しません。

  4. ターン · コスト · クォータ再試行 · 支出クォータ · 認証認証情報の確認

    クォータや認証のシグナルがあると支出を止め、needs_credentialにします。別のアカウントやプロバイダーへの自動切り替えはありません。停止シグナルを伴わない通信エラーは、BullMQの再試行に戻します。

  5. 認証情報の確認手動再開BullMQ · ジョブIDジョブキュー

    認証情報を確認した運用者が、明示的に再開します。

停滞ジョブの復旧

古いdraftを理由別に分け、キューになければ再投入し、試行を使い切っていれば人の判断に回します。

  1. draft · 進捗翻訳の状態停滞したdraft10分超のdraft · 最大200停滞スイープ

    10分を超えてdraftのままの候補を、古い順に最大200件読み取ります。クエリはロックを取らず、更新とログの書き込みは別々の文として実行されるため、競合のない一括処理とは記述していません。

  2. 10分超のdraft · 最大200停滞スイープ上限未満キュー状態の比較キューの確認

    試行が上限（3回）未満なら、ジョブをactive、waiting、delayed、prioritizedのキュー状態と照合します。コード上では、試行を使い切った場合の分岐がこのキュー照合より先に来ます。

  3. キュー状態の比較キューの確認再投入BullMQ · ジョブIDジョブキュー

    キューになければ、ジョブを再びキューに入れます。APIはリクエスト接尾辞の付いたIDを使い、スイープはセグメントとロケールのIDで探すため、処理中のすべてのリクエストと一致するとは記述していません。

  4. 10分超のdraft · 最大200停滞スイープ結果あり人によるレビュー

    3回の試行を使い切り、翻訳結果がある場合はneeds_reviewへ送ります。

  5. 10分超のdraft · 最大200停滞スイープ結果なし認証情報の確認

    3回の試行を使い切り、結果がない場合はneeds_credentialへ送ります。

すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。

  • 実線 · 入力、結果、記録の流れる方向
  • 破線 · 実行、判定、要求
  • 長い点線 · 観測と報告、判定とは別
  • 短い破線 · 失敗、停止、上限
  • 太い黒線 · 選んだフロー。番号は順序
  • ボックス · コードまたは状態の境界、見出しに名前
  • 内側のチップ · その境界の構成要素
  • 点線ボックス · その境界の外
  • オレンジの枠 · モデルが判断する場所
  • 生成 · 支出 · 確定
  • 開始 · 判定ルール · スイープ
  • キュー · 状態 · 記録
  • 登録 · キューの確認

非公開の実装記録と開発記録から作図しました。顧客データとコードパスは表示していません。

1回のスイープ
2026年5月26日、開発環境でのスイープ1サイクル：200件を確認、106件の状態遷移、2件を再投入。状態遷移は翻訳の成功ではなく、106件の移行先状態ごとの内訳は記録されていません。
厳密に1回ではない理由
記録は重複なく書き込まれますが、クラッシュ後にジョブが再実行されると、モデル呼び出しとそのコストは繰り返されることがあります。同時実行の上限はプロセス単位で、クラスター全体のものではありません。
判定の範囲
平均が用語集の失敗を覆い隠さないようにするのは、報告されたゲートに対する集計ルールです。すべての禁止語を見つけることも、ネイティブ水準の品質も証明しません。