英文の契約書・仕様書を訳すときに、過去の対訳と用語集から似た文を探し、社内の訳にそろえた訳文の案を根拠の対訳付きで返す

処理の起点を決める

受付フォルダ（Amazon S3）に原文のファイルが保存されたことを起点にします。 依頼のメールから原文を保存するだけで、数分後に訳文の案が出ます。依頼は1件ずつ来るので、まとめ処理にはしません。依頼者は「明日の稟議に間に合わせたい」と言ってくることが多く、待たせる理由がありません。

もう1つの起点は、訳文の承認です。上長が承認した訳文を承認済みのフォルダに保存したとき、文の対応を付けて対訳の索引に足します。この2つ目の起点が無いと、索引は導入時のまま古くなります。

用語集の更新は、スプレッドシートの変更を週1回取り込みます。用語集の索引は小さいので、全件を入れ直すほうが単純です。

入力データを集める

質を決めるのは、2行目の「承認済み」です。 下書きや差し戻された訳を対訳に入れると、誤った訳が根拠として何度も出てきます。索引に入れるのは、上長が承認した訳だけです。

最初の対訳は、過去の訳から作ります。 過去3年分の契約書と和訳の組を、文の対応付きに直して入れます。これがこの構成でいちばん手間のかかる準備で、第14章の1〜2週目はほぼこの作業です。

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

ハイブリッドクエリには絞り込みを付けます。 対訳の索引には、契約の種類（売買・代理店・秘密保持・仕様書）、承認の状態、取引先の区分を持たせ、filter で「承認済み」に限ります。契約の種類で絞るかどうかは、件数を見て決めます。 種類で絞ると近い訳が出やすくなる一方、件数が少ない種類では候補が出なくなります。

重みは単語の一致0.4・埋め込み0.6から始めます。 合計1.0になるように決め、第8章の試行で、過去の訳が見つかった・見つからなかったの数を見ながら動かします。ハイブリッドクエリに入れられる検索は最大5つで、入れ子にはできず、最上位のクエリとして書く必要があります。

対訳の索引の1件は、次のような形にします。英文・和訳・埋め込み・絞り込みに使う属性を1つの文書に持たせます。

{
  "tm_id": "TM-2025-0412-018",
  "source_en": "Neither party shall be liable for any indirect or consequential damages.",
  "target_ja": "いずれの当事者も、間接損害または結果損害について責任を負わない。",
  "source_hash": "",
  "source_vector": [0.0],
  "contract_type": "distribution",
  "clause_type": "limitation_of_liability",
  "status": "approved",
  "approved_on": "2025-04-12",
  "access_group": "legal_all"
}

source_en は英語の解析、target_ja は Sudachi の解析、source_vector は1,024次元の k-NN の項目として定義します。access_group は、第13章の文書の単位の権限に使います。 契約の種類や条項の種類は、過去の契約から対訳を作るときに付けます。条項の種類は見出しから機械で付けられるものが多く、付かなかったものだけを人が付けます。

完全に一致する英文は、ハイブリッドクエリと別に引きます。一字一句同じ文なら、過去の訳をそのまま使えるので、点数で並べる必要がありません。

AIへ渡す前に整形する

1. 文の分割 … ピリオドで単純に切らず、「Section 1.2」「Inc.」「e.g.」などの略記を例外にします
2. 条項番号の分離 … 「12.3 Limitation of Liability.」のような見出しと本文を分けます
3. 定義語の抽出 … 定義条項で引用符に囲まれた語と、本文で頭文字が大文字の定義語を一覧にします
4. 数値と日付の抽出 … 金額、日数、パーセント、日付を、文番号付きで取り出します
5. 正規化 … 空白、引用符の種類、改行を揃えたうえでハッシュ値を作ります
6. 埋め込み … 文ごとに Titan Text Embeddings V2 で1,024次元の埋め込みを作ります
7. 長すぎる文の扱い … 契約の1文は数百語になることがあります。入力の上限には余裕がありますが、検索の精度のために、セミコロンや項目の区切りで分けた単位も索引に持ちます

3番目と4番目は、生成AIに頼らずプログラムで取り出します。 後段の検査で、訳文の数値と定義語が原文と合っているかを照らすための材料です。訳した本人（AI）に照らさせると、同じ誤りを見逃します。

AIに処理させる

させるのは、文ごとに訳文の案を作り、どの対訳にそろえたかと、そろえなかった理由を書くことです。

3行目が、契約の訳でいちばん怖い失敗です。 「within thirty (30) days」を「1か月以内」と訳すと、読みやすくなる代わりに期限が変わります。数値と単位は原文のまま訳させ、後段のプログラムでも照らします。

指示内容を固定する

あなたは商社の法務部で、英文の契約書・仕様書の社内向け和訳を作る担当です。
和訳は社内の稟議と理解のための参考訳で、契約の正文は英文です。
社内でこれまで承認された訳にそろえることを最優先にしてください。

【文ごとにやること】
1. 候補の対訳（過去に承認された英文と和訳の組）を読み、
   原文と趣旨が同じものがあれば、その id を used_tm に入れてください。
2. 選んだ対訳の和訳の言い回しに合わせて訳してください。
   原文と対訳の英文で違う部分だけを訳し変えてください。
3. 用語集の決まった訳を必ず使ってください。
   使ってはいけない訳は使わないでください。
4. 原文の定義語は、文書全体で同じ訳にしてください。
5. 過去の対訳と違う訳にした箇所があれば、deviations に
   どの語をどう変えたかと、その理由を書いてください。

【厳守事項】
- 数値・日付・期間・金額・通貨は、原文の単位のまま訳してください。
  換算や言い換え（30 days → 1か月など）をしないでください。
- 原文に無い説明や補足を訳文に足さないでください。
- 条項の解釈、どちらに有利か、受け入れてよいかは書かないでください。
- 候補に無い対訳を、過去の訳として示さないでください。
- 趣旨が同じ候補が無い場合は used_tm を空にし、match を "new" にしてください。
- 訳に自信が無い箇所は、訳したうえで reviewer_note に理由を書いてください。

【原文の文】{segments}
【文ごとの候補の対訳（id、英文、和訳、契約の種類、承認日）】{tm_candidates}
【用語集（英語、決まった訳、使ってはいけない訳）】{glossary_hits}
【原文の定義語】{defined_terms}

「違う部分だけを訳し変える」が、この指示の要点です。 生成AIに似た対訳を見せて訳させると、自分の言い回しで訳し直してしまいがちです。それでは過去の訳にそろえた意味がなくなります。 対訳の言い回しを保ったまま、差分だけを変えるように指示します。

「候補に無い対訳を示さない」も明記します。 根拠として示された id は、後段のプログラムで候補の一覧と照らし、一覧に無い id が出たら、その文を要確認にします。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す）を使います。Amazon Bedrock 上の Claude（Claude in Amazon Bedrock）では構造化出力が使えないため、Bedrock を使う場合は受け取った JSON を Lambda 側で検証します。

{
  "doc_id": "",
  "segments": [
    {
      "seg_no": 0,
      "source": "",
      "draft_ja": "",
      "match": "exact | fuzzy | new",
      "used_tm": [ { "tm_id": "", "score": 0 } ],
      "glossary_applied": [ { "term": "", "ja": "" } ],
      "deviations": [ { "what": "", "why": "" } ],
      "reviewer_note": ""
    }
  ],
  "defined_terms": [ { "term": "", "ja": "" } ]
}

1つ目の理由は、match で人が見る順番を決められることです。 exact は過去の訳そのまま、fuzzy は似た対訳をもとに訳したもの、new は候補が無く新しく訳したものです。上長は new と、deviations のある fuzzy から読みます。

2つ目は、used_tm で根拠を開けることです。 訳文の横に過去の対訳の英文と和訳、承認日を並べて表示します。「去年の代理店契約でもこう訳した」が、画面の上で確かめられます。

3つ目は、後段の検査に使えることです。 検査はプログラムが行います。

システムへ連携する

訳文は、原文と並べた対訳表の Word ファイルで返します。 担当者は Word の上で直し、直したファイルを承認に回します。新しい画面を覚えてもらう必要がないことが、運用に乗るかどうかを分けます。

索引への追加は、承認済みのフォルダからだけ行います。 受付から出た案を直接足す経路は作りません。

人が確認する

担当者と上長は、match と検査結果で見る範囲を絞ります。

1. 検査で引っかかった文を先に直す … 数値・定義語・禁止された訳語。ここは必ず直します
2. new の文を訳として読む … 候補が無かった文で、AI の訳がそのまま出ています。原文と照らして読みます
3. deviations のある fuzzy の文を読む … 過去と違う訳にした理由が妥当かを判断します
4. exact と、deviations の無い fuzzy の文は根拠と並べて流し見る … 根拠の対訳と訳文が同じ言い回しかを確かめます
5. 用語集に足す語を決める … AI が reviewer_note で挙げた新しい語の訳を、法務部で決めます

2番目を省かないでください。 new の文は、過去の誰の目も通っていない訳です。索引に足されれば、次からは根拠として出てきます。 ここで誤りを残すと、その誤りが社内の標準になります。

目標は、80件をならして1件30分です。 過去の対訳が育つほど exact と fuzzy が増え、30分を下回ります。導入直後は対訳が少ないので、30分を超えます。

例外に対処する

7行目の「キーワード検索だけで続けない」には理由があります。 片方の検索だけで出した案は、根拠の対訳の質が変わります。同じ見た目の案が、違う質で出るほうが危険です。

最後の行のために、どの訳がどの対訳を根拠にしたかを残します。 次の「保存・ログ」の3つ目です。

記録を残す

• 原文と、文の分割の結果、取り出した定義語・数値
• 文ごとの検索の結果（候補の対訳の id と点数、そのときの重みの設定）
• 訳文の案と used_tm・deviations・検査の結果
• 担当者と上長が直した後の訳文と、直した箇所
• 索引に足した対訳と、その承認者・承認日
• 用語集の変更の履歴

3つ目の used_tm を残すのは、根拠の誤りをたどるためです。 承認済みの訳に誤りが見つかったとき、その対訳を根拠にした訳文を一覧にでき、直す範囲が決まります。

4つ目の「直した箇所」は、検索と指示の改善に使います。 毎回同じ語を直しているなら、用語集に足すべき語です。