海外向け取扱説明書の翻訳の途中稿を、章ごとに用語集と画面表示の文言に照らし、訳語の不統一と訳抜けの候補を修正案付きで翻訳者に返す

処理の起点を決める

Schedule Trigger で30分ごとに動かし、Google ドライブの「受領」フォルダを確かめます。 公式ページでは、Schedule Trigger は分・時間・日などの間隔や Cron の式で動かせ、ワークフローに時間帯の設定が無ければ n8n のインスタンスの時間帯に従い、自前で置いた場合の既定は America/New York とされています。ワークフローの設定で Asia/Tokyo を指定してから、平日の8時〜20時に絞ります。

翻訳者がファイルを置いた瞬間に動かす必要はありません。 返すのは担当が確かめた後で、担当の確認は勤務時間の中で行います。30分の遅れより、置きかけのファイル（書き込みの途中）を読まないことのほうが大事です。そのため、最終更新から10分以上たったファイルだけを対象にします。

Google Drive ノードの「Search files and folders」で「受領」フォルダのファイルを探し、「Download a file」で取り出します。処理が終わったら「Move a file」で「処理済み」へ移します。 移すのは一覧を翻訳会社に送った後だけにします。「受領」に残っているファイルの数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、用語集の「使い分けの注記」です。 「原点」が機械原点を指すときと、ワークの原点を指すときで承認訳が違う、という類の注記が無いと、規則もAIも一律に同じ訳を求めてしまいます。 注記がある用語は、候補の判定でAIに注記をそのまま渡します。

画面表示の文言表は、説明書が対象とする制御ソフトの版で引きます。 ファイル名の版から文言表の版を決め、版が文言表に無ければ照合をせずに担当へ知らせます。 古い版の文言で照合すると、正しい訳文を誤りとして返すことになります。

データの取得方法を決める

画面表示の文言表は、開発部門が版を出すたびに Data Table へ取り込みます。 公式ページでは、Data Table ノードの行の操作に Insert・Update・Upsert・Get・If Row Exists などがあります。文言IDと版を組にして Upsert し、版ごとに引けるようにします。

用語集は Google スプレッドシートのまま技術文書課が直します。ワークフローは読むだけで、書き込みません。 用語集を直すのは人の仕事で、翻訳者の不採用の理由を見て決めます。

AIへ渡す前に整形する

1. 書式の確認 … 4列がそろっているか、セグメントIDに重複や空欄が無いかを見ます。崩れていれば照合をせずに担当へ知らせます
2. 正規化 … 全角・半角、連続した空白、引用符の種類をそろえます。画面表示の文言の照合だけは正規化しない文字列でも比べます
3. 見出し語の最長一致 … 原文から用語集の見出し語を、長いものから順に探します。「原点復帰」が見つかった箇所では、「原点」を重ねて拾いません
4. 候補の拾い出し … 次の表の規則で候補を作ります
5. 文脈の付与 … 候補ごとに、前後1つずつのセグメントと、その候補に関係する用語集の行だけを添えます

3番目を省くと候補が倍に増えます。 日本語には語の区切りが無いので、短い見出し語は長い見出し語の一部として何度も当たります。長い語を先に取り、その範囲を短い語の探索から外します。

ui_mismatch と untranslated と number_mismatch は、AIの判定を通さずに確定の候補にします。 文言表と一致しない、空である、数値が違う。これらは文字列の事実で、AIに「許される範囲か」を聞く性質のものではありません。

AIに処理させる

Basic LLM Chain に、残りの候補（term_missing・term_forbidden・length_outlier・inconsistent）の判定と修正案を作らせます。 公式ページでは、Basic LLM Chain はモデルに渡すプロンプトを決めるノードで、Require Specific Output Format を有効にすると出力の形を決めるパーサーをつなぐとされています。

「acceptable」を判定に入れているのが、この構成の要です。 ドイツ語の複合語では承認訳が別の語の一部になり、中国語では語順の都合で語が分かれることがあります。規則は機械的なので、こうした正しい訳文も候補として拾います。 それを誤りとして返すと、翻訳者は「直さなくてよい指摘」に答える時間を使います。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは工作機械メーカーの技術文書課で、取扱説明書の翻訳の用語を点検する担当です。
翻訳者から届いた途中稿のうち、照合の規則で拾われた「候補」だけを判定します。

【入力】
- 対象言語
- 候補の一覧（候補ID、種類、セグメントID、原文、訳文、前後のセグメント）
- 候補に関係する用語集の行（用語ID、見出し語、承認訳、禁止訳、使い分けの注記）

【判定の選び方】
- error ......... 承認訳を使うべき箇所で使われていない、または禁止訳が使われている
- acceptable .... 承認訳が語形変化・複合語・語順の都合で形を変えて含まれている、
                  または使い分けの注記により別の承認訳が正しい
- unsure ........ 上のどちらとも決められない
迷ったときに error を選ばないでください。unsure にしてください。

【修正案の書き方】
- error のときだけ suggested_target を書いてください。
- 訳文のうち、差し替える語とその前後の数語だけを変えてください。
  文の構成を変えたり、言い回しを整えたりしないでください。
- 修正案に使う訳語は、用語集の承認訳だけにしてください。
- 数値、単位、型番、記号は訳文のまま残してください。

【訳抜けの候補（length_outlier）】
- 原文にあって訳文に無い内容があれば、missing_source に原文の言葉をそのまま写してください。
- 無ければ acceptable にしてください。長さの違いだけで error にしないでください。

【厳守事項】
- 候補の一覧に無い箇所について指摘しないでください。
- 用語集に無い訳語を提案しないでください。
- 根拠の用語IDを示せない error は出さないでください。
- note_ja には、判定の理由と、該当部分の意味を日本語で1〜2文で書いてください。
- 翻訳の巧拙や文体の評価は書かないでください。

「迷ったときに error を選ばない」を明記しないと、AIは候補をほぼ全部 error にします。 規則が拾ったという事実を、誤りの根拠のように扱うからです。unsure を逃げ道として用意し、担当が見る候補として扱います。

「長さの違いだけで error にしない」も効きます。 ドイツ語は日本語より長く、中国語は短くなりがちです。長さは訳抜けを疑うきっかけで、訳抜けそのものではありません。 原文の言葉を写せたときだけ訳抜けとします。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、JSON の例から生成するか JSON Schema で定義するかを選べ、例から生成するとすべての項目が必須として扱われ、$ref を使った参照には対応しないとされています。入れ子の定義は参照を使わずに直接書きます。

{
  "file": "MC-500_ch12_de_v3.xlsx",
  "language": "de",
  "results": [
    {
      "candidate_id": "C-0412",
      "segment_id": "12-087",
      "type": "term_missing",
      "verdict": "error | acceptable | unsure",
      "term_ids": ["T-0231"],
      "suggested_target": "",
      "missing_source": "",
      "note_ja": ""
    }
  ]
}

1つ目の理由は、候補IDで規則の記録と結び付けられることです。 拾った候補とAIの判定を突き合わせ、判定が返らなかった候補があれば unsure として残します。 候補が黙って消えることがありません。

2つ目は、修正案をワークフローが検査できることです。 suggested_target が承認訳を含んでいるか、元の訳文と比べて数値・単位・型番が変わっていないかを Code ノードで見ます。どちらかを満たさない修正案は消し、判定を unsure に落とします。

3つ目は、翻訳者に返す一覧がそのまま作れることです。 一覧は次の列で作ります。

システムへ連携する

担当への確認には、Slack ノードの Send and Wait for Response を承認の形で使います。 公式ページでは、承認する人が Slack の中で承認・却下でき、承認できる人を指定でき、誰が応じたかが出力に残るとされています。承認できる人を、その言語の担当に限ります。条件として、n8n が Slack から公開の HTTPS で届く場所にあること、Slack のアプリの Interactivity の受け口を登録すること、資格情報に Signing Secret を入れることが要るとされています。

メールは Gmail ノードの Send a message で送り、一覧のファイルを添付します。 公式ページでは、添付するファイルを入力のどの項目から取るかを指定でき、既定では本文の末尾に n8n から自動で送られた旨の一文が付くとされています。取引先への連絡なので、この一文を付けるかは設定で決めておきます。

Anthropic Chat Model ノードでは、Prompt Caching を有効にします。 公式ページでは、システムプロンプトなどをリクエストの間で保持でき、5分か1時間を選べるとされています。判定の規則を書いたシステムメッセージは毎回同じなので、章をまとめて処理するときに効きます。

人が確認する

その言語の担当が、Slack の知らせから一覧を開いて確かめます。

1. ui_mismatch を先に見る … 文言表の版が説明書の対象と合っているかを確かめます。版が合っていれば、そのまま返します
2. error を確かめる … 用語IDと承認訳が、その文脈で正しいかを見ます。使い分けの注記がある用語は特に見ます
3. unsure を判断する … 消すか、error にして修正案を書くかを決めます
4. 訳抜けの疑いを確かめる … missing_source の原文の言葉が、訳文の前後のセグメントに移っていないかを見ます
5. 「返す」を押す … 一覧から消した指摘は、記録に「担当が消した」として残ります

読めない言語でも、1番と2番は確かめられます。 文言表との一致と承認訳の有無は、文字列の問題だからです。3番と4番に読める人の判断が要るので、読める担当が不在の週は、その2つだけを次の週に回します。 1番と2番を先に返すと、翻訳者の手が止まりません。

目標は、1件をならして10分です。 候補が数件の章は数分で終わり、新機種の最初の章のように用語が多い章は20分を超えます。

例外に対処する

最後から2行目は、AIの問題ではありません。 別の機種の文言表で照合した、列が入れ替わっていた、というときに候補が跳ね上がります。上限を置くと、取り違えがAIの費用になる前に止まります。

記録を残す

• 対訳表のファイル名、機種・章・言語・版、受け取った日時
• 照合の規則が拾った候補の全件と、使った用語集・文言表の版
• AIの判定と修正案、ワークフローが消した修正案とその理由
• 担当が消した・直した指摘と、応じた人と時刻
• 翻訳者の回答（採用／不採用）と不採用の理由
• 用語IDごとの、error の数と不採用の数

最後の行が、用語集の見直しの材料になります。 ある用語の指摘がいつも不採用になるなら、承認訳が実際の文脈に合っていないか、使い分けの注記が足りません。 翻訳者の理由を読んで、用語集を直します。