外注した翻訳を受け入れる前に、訳抜けと数値違いと用語の不統一を点検する

処理の起点を決める

SharePoint の受入フォルダにファイルが保存されたことを起点にします。 納品はメールで届きますが、メールの受信は起点にしません。 添付の付け方が案件ごとに違い、1通に複数言語がまとまって届くこともあるためです。「受入フォルダに1言語分ずつ置く」という人の操作を1つ挟むほうが、後の処理が安定します。

フォルダは言語ごとに分け、ファイル名に文書IDと言語コードを入れます（例: CAT-2410-03_de.docx）。原文は同じ文書IDで原文フォルダにあります。原文が見つからないときは起動しません。 比べる相手が無ければ、この構成は何もできません。

定時実行にしない理由もあります。翻訳会社への差し戻しは納品から何日以内という取り決めがあることが多く、1日1回にすると実質の締め切りがその分だけ縮みます。

入力データを集める

この構成の質を決めるのは用語集です。 日本語の語と対訳が1対1で並んでいれば突き合わせは機械でできますが、「対訳が空欄」「1つの語に訳語が3つ」の状態では、何とも比べられません。 準備作業はここに集まります。

用語集には「使ってはいけない訳語」の欄も作ります。 前回に差し戻した訳語をここへ移しておくと、同じ指摘を毎回書き直さずに済みます。

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

Power Automate のフローは4つの動作だけです。

Word ファイルは、そのままの形では比べません。 見出し・段落・箇条書き・表のセルに分け、それぞれに h3 p12 l17-3 t4-2 のような位置の符号を振ってから渡します。 位置の符号が無いと、指摘に「どこが」を書けません。ここを省くと、出てくるのは「訳文の後半で単位が抜けているようです」という、翻訳会社が探すところから始める指摘になります。

訳文の側にも同じ規則で符号を振ります。 段落数が原文と違う時点で符号は1対1になりませんが、ずれていること自体が最初の指摘になります。

AIへ渡す前に整形する

点検するのは次の5点です。上の4つは前処理で機械的に済ませ、AIに渡すのは5つ目だけです。

前処理の中身は6つです。

1. 符号付け … 見出し・段落・箇条書き・表のセルに、原文と訳文の両方で位置の符号を振ります
2. 数の比較 … 段落数、見出し数、箇条書きの項目数、表の行数を原文と訳文で数え、差を出します
3. 数値と単位の抜き出し … 原文から数値と単位を全部抜き、訳文の対応する位置の近くに同じ値があるかを見ます
4. 英数字の並びの抜き出し … 型番、規格番号、型式記号を抜き、訳文にそのまま現れるかを見ます
5. 用語集の突き合わせ … 原文に用語集の語が何回出るかを数え、訳文に対訳が何回出るかを数え、数が合わない語だけを候補に残します
6. 過去の指摘の付け合わせ … 前回差し戻した箇所と同じ語が残っていれば印を付けます

3で、けた区切りと小数点の規則を先に決めておいてください。 1,000 が 1.000 になるのは誤りではなく、言語による書き方の違いです。ここを機械が食い違いとして出すと、初回の指摘一覧の大半がこれで埋まります。 言語ごとの規則を設定に書き、前処理の側で吸収します。

5で「数を数える」だけにしているのにも理由があります。 どの位置の語が正しいかまで機械で決めようとすると、語形の変化や語順で外れます。数が合わない語を人とAIに渡すところで止めるのが、いちばん外れません。

AIに処理させる

させるのは、原文の各文が訳文のどこに対応するかの対応づけと、対応の見つからない箇所の指摘の2つだけです。

原文の文を上から順に見て、訳文のどの符号に対応するかを答えさせます。対応が見つからない文は unmatched_source_segments に残します。逆に、原文のどの文にも対応しない訳文の記述は extra_content として出させます。あわせて、前処理で出た食い違いの候補に前後の文を添えて、差し戻しの指摘として読める形にします。

1行目がいちばん大事です。 点数を出させると、担当者はその点数を見て受入を決めるようになります。80点の訳文に訳抜けが1か所あるのと、60点の訳文に訳抜けが無いのとでは、受け入れてよいのは後者です。 点数は、この構成が見つけたい欠けを覆い隠します。確実なのは、出力のスキーマに点数を書く場所を作らないことです。

指示内容を固定する

あなたは、外注した翻訳の受入検査を手伝う立場です。
訳文の品質を評価するのではなく、原文にあって訳文に無いもの、
原文と食い違うものを見つけてください。

【渡すもの】
- 原文（位置の符号つき。h=見出し、p=段落、l=箇条書き、t=表のセル）
- 訳文（同じ規則の符号つき）
- 用語集の対訳（この言語の分だけ）
- 前処理で出た食い違いの候補（数値・型番・用語・数の差）

【やること】
1. 原文の文を上から順に見て、訳文のどの符号に対応するかを答えてください。
   対応が見つからない文を、近い段落へ無理に割り当てないでください。
   見つからないことを unmatched_source_segments に書いてください。
2. 原文のどの文にも対応しない訳文の記述を extra_content として出してください。
3. 前処理で渡した食い違いの候補それぞれに、原文の位置と訳文の位置、
   原文の該当文と訳文の該当文を付けてください。

【厳守事項】
- 訳文の点数や評価（自然さ、読みやすさ、総合的な出来）を書かないでください。
  「良い訳です」「不自然です」と書いてはいけません。
- 訳文の修正案を書かないでください。指摘するところまでが役目です。
- 原文と訳文に書かれていない数値・型番・語を書かないでください。
  単位の換算も、けたの丸めもしないでください。
- 原文の該当箇所が読み取れないときは、source_text を空にせず
  「不明」と書いてください。推測で埋めないでください。
- 用語集に対訳の記載がない語は、glossary_mismatch にしないでください。
  「用語集に記載がない」と needs_human の理由に書いてください。
- severity は次の規則で付けてください。
  数値・単位・型番の食い違いと、対応の見つからない原文の文は must_fix。
  用語集との不一致と、余分な追記は check。
  迷ったときは check にし、needs_human を true にしてください。

【原文】{source_doc}
【訳文】{target_doc}
【用語集の対訳】{glossary}
【前処理で出た候補】{machine_findings}

「点数や評価を書かない」を2か所に分けているのは、書き方を変えて出てくるためです。 総合評価を禁じると、指摘の1つ1つに「軽微」「重大」といった評価語が付き始めます。評価語は severity の2つの値だけに閉じ込めます。

「無理に割り当てない」も欠かせません。 何も言わないと、対応の見つからない文をいちばん近い段落に割り当てて、対応づけを完成させようとします。そうなると訳抜けは1件も出ません。 対応が見つからないことこそ、この構成が探しているものです。

「用語集に記載がない語」の扱いを書くのも同じ理由です。 記載が無いときに、訳文の語をそのまま正解と見なすか、一般的な訳語を持ち出して食い違いにするかで、指摘の数が大きく変わります。記載が無いという事実を、そのまま人に返させます。

出力形式を固定する

返させるのは、次の形のJSONです。

{
  "doc_id": "CAT-2410-03",
  "language": "de",
  "findings": [
    { "type": "number_mismatch", "source_ref": "p42", "target_ref": "p41",
      "source_text": "", "target_text": "", "severity": "must_fix" },
    { "type": "missing", "source_ref": "l17-3", "target_ref": "",
      "source_text": "", "target_text": "", "severity": "must_fix" }
  ],
  "counts": {
    "paragraphs": { "source": 0, "target": 0 },
    "headings":   { "source": 0, "target": 0 },
    "list_items": { "source": 0, "target": 0 }
  },
  "unmatched_source_segments": [ { "source_ref": "", "source_text": "" } ],
  "needs_human": { "value": true, "reason": "" }
}

type は missing（訳抜け）、number_mismatch（数値の違い）、code_mismatch（型番の違い）、glossary_mismatch（用語集との不一致）、extra_content（原文に無い追記）の5つです。

構造化する理由の1つ目は、source_ref と target_ref を必ず持たせるためです。 差し戻しの指摘は「どこが」が書けないと通じません。項目として用意しておけば、空のままにはできません。自由文で返させると、位置はほぼ落ちます。

2つ目は、指摘一覧を機械で並べ替えるためです。 severity が must_fix のものを上に置き、同じ種別をまとめて出せば、担当者は同じ判断を続けてできます。種別がばらばらに並ぶと、数値を見る頭と用語を見る頭を1件ごとに切り替えることになり、確認の12分が伸びます。

3つ目は、counts を先に見れば全体の欠けが分かることです。 段落数が原文12・訳文11なら、個別の指摘を読む前に1つ足りないと分かります。点数の欄は作りません。「AIに何をさせるのか」のとおりです。

システムへ連携する

書き戻す先はありません。 訳文のファイルには触れず、指摘一覧を別のファイルとして置くだけです。訳文に直接コメントを入れる形にすると、翻訳会社へ戻すときに、どれが自社の書き込みか分からなくなります。

翻訳会社への送信も、この構成には含めません。 メールは担当者が書きます。理由は第13章に書きます。

人が確認する

全件、人が確認します。指摘一覧をそのまま翻訳会社へ送る設計にはしません。

1. must_fix を全部見る … 数値・単位・型番の食い違いと訳抜けです。原文の該当箇所を開いて、指摘そのものが正しいかを確かめます
2. check を絞る … 用語集との不一致と余分な追記です。文脈によっては許容します。許容したものは用語集に反映します
3. needs_human が真のものを先に読む … 用語集に記載が無い、対応づけが揺れた、といった箇所です

確認の目標は1件18分です。 内訳は指摘一覧の確認12分と、原文との突き合わせ6分です。それ以上かかるなら、check が多すぎます。 多くの場合、原因は用語集の対訳の欠けか、けた区切りの規則の設定漏れです。プロンプトで指摘を減らすのではなく、前処理の規則を直します。 指示で抑えると、本当に必要な指摘まで一緒に消えます。

例外に対処する

4行目を軽く見ないでください。 段落数が大きく違う訳文は、レイアウトの都合で段落がまとめられただけのことも、章がまるごと抜けたこともあります。この見分けは人がやります。機械が「11対12だから1つ足りない」と出し、人が中身を見る。 順番を逆にしません。

記録を残す

• 原文・訳文・用語集の版（どの原文の、どの版と比べたか）
• 指摘一覧のJSONの全文と、担当者が採用した指摘・見送った指摘
• 見送った指摘の理由（許容した／前処理の誤検出だった／用語集の欠けだった）
• 翻訳会社へ送った指摘と、その回答、修正版の受領日
• 受け入れた日と、受け入れた担当者

3つ目が、この構成を良くする材料です。 「前処理の誤検出だった」が続く種別は規則を直し、「許容した」が続く語は用語集に足します。 記録が無いと、同じ誤検出を毎月見続けることになります。

保存の設計より先に、契約の確認です。 訳文を用語集へ蓄積してよいかは、翻訳会社との契約で決まります。