人によるレビュー

ほとんどのコンテンツは、エンジンが返した瞬間にそのまま公開できます。ですが、そうはいかないものもあります。規制対象の開示、医療上の指示、ブランドを背負う見出し。そうした内容では、顧客から苦情が来てからではなく、公開前に人が翻訳を読み、承認しておきたいはずです。

自動化フローに人の確認を入れる一般的なやり方は、たいてい厄介です。誰かが読むまでリクエストを開いたままにする、自前でレビューキューを作る、翻訳ベンダーのAPIを手作業でつなぎ込む。このステージなら、それをジョブの中で完結できます。humanEdit を有効にすると、非同期ジョブはエンジンを実行したあと、人による確認で一時停止します。対象は自社チームでも外部の専門家でもかまいません。修正内容を受け取るとジョブは再開し、その出力が後続のステージへそのまま引き継がれます。

これはローカライゼーションパイプライン内で、リフレーズの後、ポストエディットの前に実行されます。ほかの各段階と同様、適用されるのは非同期ローカライゼーションエーピーアイ経由で作成されたジョブだけです。パイプラインを初めて使う場合は、まず概要からご覧ください。

このページの内容

• 一時停止の仕組み
• 内部レビュー
• 権限
• 外部レビュー
• 品質しきい値
• タイムアウト
• ステージの有効化

一時停止の仕組み#

中核となる翻訳ステップの後、さらにその段階が有効な場合はリフレーズの後に、ジョブはエーアイ翻訳を人によるレビューに回します。レビュー担当者は内容を確認し、そのまま承認するか、編集版を送信します。ジョブが先に進むのはその後です。承認された場合も編集された場合も、その人による出力が以降すべての段階の入力となり、最終的にはジョブのoutputDataになります。

ジョブを数分、数時間、あるいは丸一日止めるとなると、まず気になるのはコストです。何も起きていない間も、開いたままのリクエストがリソースを消費し続けるのではないか。ですが、このステージはそうした仕組みではありません。

レビューには2つのモードがあり、エンジンごとに選べます。違うのは、実際に読む人が誰かだけです。一時停止、再開、その後のステージへの引き継ぎという挙動はどちらも同じです。

内部レビュー#

チームはLingo.devのダッシュボード上で翻訳を直接レビューできます。保留中のレビューはキュー（/orgs/<org-id>/queue）に人によるレビュー項目として表示され、新しい項目が届くとレビュー担当者に通知されます。レビュー担当者は項目を開き、必要なキーを編集したうえで、そのまま承認をクリックするか、編集後であれば編集して承認をクリックします。ボタンには編集件数も表示され、たとえば二件編集して承認のように表示されます。ジョブはその出力を使って再開します。

引き受けやロックの仕組みはありません。開いているレビューはひとつの一覧に置かれ、すべてのレビュー担当者が確認して判断できます。

内部レビューはEnterpriseプランで利用できます。これを含むプランでは、新しいエンジンは内部レビューで開始され、含まれないプランでは外部レビューで開始されます。また、内部レビューオプションにはEnterpriseタグが付きます。チーム内に言語の専門知識があり、第三者を介さず最終的な表現を完全にコントロールしたい場合に適しています。

権限#

内部レビューは、組織内の誰でも利用できるわけではありません。レビューキューへのアクセスは権限で制限されているため、レビュー中の翻訳を閲覧できるのは、アクセス権を付与されたユーザーのみです。組織管理者は、ロール（Settings → Roles）からアクセス権を割り当てます。

この二つの権限は、意図的に分けられています。レビュー担当者に必要なのは翻訳をレビューだけです。このひとつの権限で、編集、そのまま承認、編集して承認まで行えます。レビューを管理は運用全体を見守る担当者向けで、組織全体のレビュー履歴を追加しますが、それだけでキューにアクセスできるわけではありません。レビューもレポートも担うリードには両方を付与し、キューでの作業だけを行う人には最初のひとつだけを付与してください。

外部レビュー#

対象ロケールに社内レビュー担当者がいない場合は、代わりに外部プロバイダー経由で、資格を持つプロの翻訳者に翻訳が送られます。ジョブは同じように一時停止し、プロバイダーが修正済みの翻訳を返すと再開されます。コード側を変更する必要はありません。違うのは、誰が文字列を読むかであって、ジョブの振る舞いではありません。

選ぶべき階層はありません。マーケットプレイスが翻訳者そのものを評価します。外部レビューは一語ごとに課金されます。

外部レビューもキューに表示されます。開くと、レビュー担当者として認定翻訳者が表示されます。翻訳をレビュー権限を持つ人は、それを開いて引き継ぐことができます。そのまま承認または編集して承認を選ぶと、翻訳者を待たずにその場でジョブが完了します。このレビューを引き継ぐ確認画面には、確定前に費用が表示されます。引き継ぎが無料なのは、翻訳者がまだ作業を始めていない間だけです。いったん作業が始まると、その成果物を使うかどうかにかかわらず翻訳者への料金は発生します。

ここは率直にお伝えしておくべき点です。外部レビューの先にいるのは実際の人間の翻訳者であり、それに見合った納期とコストがかかります。より速いモデルではありません。人の判断そのものが必要な場面――規制対象の文面や重要なコピー――に使い、それを必要としない大半のコンテンツにはAIのみの経路を使うのが適切です。

品質しきい値#

すべての翻訳に人の確認が必要とは限りません。人によるレビュー設定で品質しきい値（一〜百）を設定すると、AI評価者が各翻訳をレビュー前に採点します。しきい値以上であれば、翻訳は人を介さずそのまま出荷され、humanEditステップはskippedとして記録されます。しきい値を下回る場合は、通常どおりレビューに進みます。すべてをレビューしたい場合は、この項目を空のままにしてください。設定では、humanEdit上のqualityThresholdです。

この方法で出荷された翻訳には人による出力がないため、ポストエディットは実行されません。

タイムアウト#

人が関わるステージには、AIステージにはないリスクがあります。人がまったく応答しない可能性です。レビュー担当者が休暇中かもしれない、プロバイダーが立て込んでいるかもしれない、項目そのものが見落とされるかもしれない。上限がなければ、ジョブはいつまでも待ち続けてしまいます。

そのため、待ち時間には上限があります。ワークフローが人による出力をどれだけ待つかは、人によるレビュー設定のタイムアウトで時間単位に設定します。設定ではtimeoutHoursです。これはどちらのレビューモードにも適用されます。応答がないままタイムアウトすると、その段階はskippedと記録され、ジョブはAI翻訳を最終出力として続行します。既定値は四十八時間です。キューでは、タイムアウトしたレビューは判断なしで終了と表示されます。

このコストは明確です。タイムアウトすると、未レビューのAI翻訳がそのまま公開されます。ほとんどのコンテンツでは、これは適切なフォールバックです。いつまでも止まったままのジョブより、公開された翻訳のほうが価値があるからです。ただし、これは現実的なトレードオフでもあります。何があっても人の承認が必要なコンテンツなら、長めのタイムアウトを設定し、スキップ時にアラートを上げてください。レビューはあれば望ましい程度のコンテンツなら、短めのタイムアウトでパイプラインを止めずに進められます。

ステージの有効化#

humanEdit は、ほかのパイプラインステージと同じように設定します。エンジンの Pipeline タブでエンジンレベルのデフォルトを設定し、必要に応じてリクエスト単位で上書きできます。この2層モデル全体については パイプラインを設定する にまとまっています。このステージ固有の設定項目は次のとおりです。

{
  "humanEdit": {
    "enabled": true,
    "provider": "internal",
    "tier": "standard",
    "timeoutHours": 48,
    "qualityThreshold": 85
  }
}

providerでモードを選択します。自社チーム向けはinternal、外部マーケットプレイス経由のプロ翻訳者向けはexternalです。tierは任意で、指定できるのはstandardだけです。timeoutHoursはタイムアウトの上限で、任意のqualityThreshold（一〜百）は品質しきい値の値です。単一の送信だけで上書きするには、このブロックを作成呼び出しのpipelineConfig内に渡してください。省略した場合、ジョブはエンジンの設定を引き継ぎます。

このステージが実行されると、ジョブ上の stepId: "humanEdit" に、completed、failed、または skipped のステータスで記録されます。これはすべてのステージで共通のステップ記録です。これらの記録の読み方は パイプライン実行を監視する で説明しています。

次のステップ#