保険会社が外国人の契約者に送る保険金請求の案内と必要書類の説明を、社内の用語集と承認済みの訳にそろえて多言語に訳し、確認に回す

処理の起点を決める

担当が、確認画面で「訳す」を押したときに動きます。 請求案内は、受付システムが日本語を作った時点で中身が確定しています。夜間にまとめて訳すと、送るのが翌日にずれます。 1件ずつ、その場で返します。

言語は、契約情報に登録された言語を初期値にします。 登録が無い契約者は、担当が選びます。翻訳メモリと用語集を整えた言語（英語・中国語・ベトナム語・ネパール語・インドネシア語・ポルトガル語の6言語）以外のときは、英語とやさしい日本語の2つを並べて作ります。

毎月1日の朝に、前月に生成AIが訳した文を集める処理が動きます。 同じ日本語の文が3回以上訳されたものを一覧にし、母語話者の確認に回す候補にします。

入力データを集める

質を決めるのは、下の3つです。 書類名の一覧が無いと、「入院証明書」と「診断書」が言語ごとに違う訳になり、第3章の（a）がそのまま残ります。 約束表現の一覧が無いと、第3章の（b）を機械で拾えません。

用語集は、保険の言葉を中心に作ります。 「給付金」「保険金」「受取人」「被保険者」「契約者」「免責」「告知」「支払事由」のように、日本語では区別しているのに、訳すと同じ1語になりがちな言葉が先です。たとえば「保険金」と「給付金」を同じ語に訳すと、どちらの請求の話なのかが分からなくなります。

契約者の氏名・証券番号・口座の情報は、生成AIに渡しません。 案内の宛名と証券番号は前処理で記号に置き換え、訳した後に機械の側で戻します。

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

書類名は、受付システムの書類コードで引きます。 日本語の書類名を文字で照合すると、「住民票」「住民票の写し」「住民票記載事項証明書」のような似た名前を取り違えます。 受付システムは必要書類をコードで持っているので、コードで引けば取り違えが起きません。

書類名の一覧の行は、たとえば次のような形です。

取り方の一言説明も、書類名と同じく一覧の訳で入れます。 「どこで頼むか」は書類ごとに決まっているので、毎回訳させる必要がありません。案内の中で契約者がいちばん読み返すのは、この欄です。

翻訳メモリの照合は、文の完全一致で行います。 似た文に近い訳を当てると、「〜をご提出ください」と「〜のご提出は不要です」のように、1語で意味が逆になる文を取り違えます。 請求案内の定型の文は受付システムが作るので、完全一致で十分に当たります。

翻訳メモリの行は、たとえば次のような形です。

2行目の文が、約束にしないための定型です。 「お支払いします」ではなく「お支払いの可否をご連絡します」とし、この文の訳を母語話者に確かめておきます。 最後の行のように「担当確認のみ」の文は照合に使わず、次に出たときも生成AIに送り、逆訳で確かめます。

AIへ渡す前に整形する

1. 記号への置き換え … 契約者の氏名を {NAME}、証券番号を {POLICY}、提出先の住所を {ADDR1}、問い合わせ先の電話番号を {TEL1} に置き換えます
2. 値の記号化 … 日付・期限・金額を {DATE1} {AMT1} のような記号にし、値は中継の処理の側で持ちます
3. 書類名の固定 … 書類コードで引いた書類名を {DOC1} のような記号にし、訳は書類名の一覧の訳と日本語の原語で入れます
4. 文への分割 … 案内を文に分け、1文が長すぎるもの（目安として80字を超えるもの）は、担当の補足なら担当に分けて書き直してもらいます
5. 翻訳メモリとの照合 … 一致した文は訳を取り出し、一致しない文だけを残します
6. 補足の言い回しの確認 … 担当の補足に「必ず」「間違いなく」のような言い回しがあれば、訳す前に画面で知らせます

3番目を軽く見ないでください。 書類名を生成AIに訳させると、言語ごとに自然な言い方に置き換わります。自然な訳ほど、日本の病院や市役所の窓口で通じません。 原語を並べるのは、契約者が窓口でその文字を見せれば頼めるようにするためです。

6番目は、日本語の段階で約束を止めるための手順です。 原文が約束になっていれば、正しく訳すほど約束が伝わります。訳す前に原文を直すほうが早く済みます。

AIに処理させる

させるのは、翻訳メモリに無かった文を訳し、その訳文を日本語に訳し戻し、使った用語を書き出すことです。

2行目がいちばん起きやすい失敗です。 生成AIは、読み手に親切な訳を作ろうとして、「書類がそろえば、お支払いの手続きに進みます」のような見込みを足します。 足された文は原文に無いので、逆訳を原文と並べれば見つかります。 そのために逆訳をさせています。

指示内容を固定する

あなたは保険会社の請求案内を、外国人の契約者のために訳す担当です。
渡すのは、承認済みの訳が無かった日本語の文の一覧です。

【すること】
1. 各文を {target_language} に訳してください。
2. 訳した文を、日本語へ訳し戻してください（逆訳）。
3. 各文で使った【用語集】の用語を書き出してください。
4. 意味が2通りに取れる、または原文が足りず訳せない箇所を書き出してください。

【厳守事項】
- 原文に無い説明・理由・見込みを足さないでください。
- 保険金・給付金が支払われる、受け取れる、と読める文を足さないでください。
  原文が「可否をご連絡します」なら、可否を連絡するという意味のまま訳してください。
- 「必ず」「確実に」「保証」にあたる語は、原文にある場合だけ使ってください。
- 【用語集】の訳語を使ってください。「使ってはいけない訳語」は使わないでください。
- 「保険金」と「給付金」、「契約者」「被保険者」「受取人」は、用語集の区別のまま訳してください。
  同じ1語にまとめないでください。
- {DOC1} {DATE1} {AMT1} {ADDR1} のような記号は、訳さず、消さず、そのまま残してください。
- 逆訳は、訳文から読み取れることだけを日本語にしてください。
  原文を見て直さないでください。
- 訳せない箇所は訳さずに unclear に書いてください。推測で埋めないでください。

【訳す文】{sentences}
【用語集（この文に関係するもの）】{glossary}

「逆訳は原文を見て直さない」を明記しないと、逆訳が原文と同じ文になります。 生成AIは手元に原文があるので、訳文からではなく原文から日本語を書いてしまいます。それでは、訳文に足された見込みが逆訳に出てきません。

「保険金と給付金を同じ1語にまとめない」も、書いておかないと崩れます。 英語などでは、どちらも同じ語で自然に訳せてしまいます。用語集で語を分け、指示でも念を押します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "target_language": "vi",
  "sentences": [
    {
      "id": "S1",
      "source": "",
      "translation": "",
      "back_translation": "",
      "terms_used": [ { "term": "", "rendered_as": "" } ],
      "placeholders": [ "{DOC1}", "{DATE1}" ],
      "unclear": ""
    }
  ]
}

1つ目の理由は、文ごとに逆訳と原文を並べられることです。 確認画面では、左に原文、右に逆訳を並べ、意味のずれた文だけを色分けします。 担当はその言語を読めなくても、日本語で確かめられます。

2つ目は、placeholders で記号の取りこぼしを機械的に見つけられることです。 原文の記号の数と並びと、訳文の記号が一致しなければ、その文は送らずに担当へ返します。 記号が1つ消えれば、書類名か期限が1つ消えたことになります。

3つ目は、terms_used で用語集との照合ができることです。 rendered_as が用語集の訳語と違えば、その文を照合の結果に出します。

構造化出力では、すべてのフィールドを必須にし、additionalProperties: false を設定する必要があります。訳せない箇所が無い文も、unclear を空の文字列で返させます。

後段の照合は、次の4つを機械で行います。

3行目が、この構成の要です。 約束表現が原文に無いのに逆訳に出てきたら、訳の途中で約束が生まれたということです。 その文は担当が直すまで送れないようにします。

システムへ連携する

翻訳メモリへの追加は、この構成からは自動で行いません。 生成AIが訳し、担当が確認して送った文は、「担当確認のみ」として控えに残るだけです。 承認済みの訳になるのは、母語話者が確かめた後です。

生成AIへは、1通の中の一致しなかった文をまとめて送ります。 文ごとに送ると前後の文脈が切れ、「それ」「こちら」が何を指すか分からなくなります。ただし、1通を超えてまとめることはしません。 別の契約者の案内が混ざらないようにするためです。

人が確認する

送付を決めるのは担当で、読む順番を決めておきます。

1. 送れないと出た文を先に見る … 記号の取りこぼしと、逆訳に出た約束表現です。原文の補足を言い直すか、文を分けて訳し直します
2. 用語の照合に引っかかった文を見る … 用語集の訳語に直します
3. 逆訳と原文を並べて読む … 意味が同じかを日本語で確かめます
4. 書類名と原語の並びを見る … 書類コードで入っているので誤りは少ないですが、書類の数が日本語の案内と合っているかを数えます
5. 送付を決める

1番目の文を、担当が訳文の側で直すことはしません。 その言語を読めない担当が訳文を直すと、確かめようのない文が生まれます。直すのは日本語の原文で、直した原文をもう一度訳させます。

請求の受付部門の責任者は、月に1回、送った案内から1言語あたり10通を抜き取り、母語話者に読んでもらいます。 逆訳で見えなかったずれが無いかを確かめ、見つかった言い回しを用語集と約束表現の一覧に足します。

例外に対処する

6行目を軽く見ないでください。 海外に住む受取人が取る書類は、国ごとに名前も発行元も違います。生成AIに「その国でいう死亡証明書」を考えさせると、存在しない書類名が出てきます。 一覧に無い書類は、人が調べてから一覧に足します。

記録を残す

• 日本語の請求案内と、送った対訳の控え（請求の記録に添付）
• 生成AIへ送った文（記号に置き換えた後のもの）と、返ってきたJSON
• 照合の結果（送れないと出た文と理由）と、担当が原文をどう直したか
• 翻訳メモリから使った文の番号
• 母語話者の抜き取りの結果と、用語集・約束表現の一覧への追加
• 記号と元の値の対応表（社内にだけ置く）

3つ目が、約束表現の一覧を育てる材料になります。 どの補足の言い回しが約束に変わりやすいかが分かれば、受付システムの定型の文や担当の書き方の側を直せます。

1つ目の控えは、後から苦情が来たときの材料です。 「案内に支払われると書いてあった」という申出があったとき、送った訳文そのものと、そのときの逆訳と照合の結果が残っていれば、何が書かれていたかを母語話者に確かめられます。控えは日本語の案内と対にして、請求の記録と同じ期間残します。