製品カタログと技術仕様書を、用語集と過去の訳をそろえて多言語化する

処理の起点を決める

日本語の原稿が、指定フォルダへ登録されたことを起点にします。改訂版と前版の両方が必要なため、版の番号をファイル名に含める運用を決めてください。

原稿はDTPソフトのファイルではなく、テキストを抽出できる形（Word、または構造化されたテキスト）で登録してもらいます。 DTPファイルから直接処理しようとすると、レイアウト情報に引きずられて文の分割が崩れます。

新規の資料（前版がないもの）は、全文が「改訂された文」として扱われます。処理の流れは同じです。

入力データを集める

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

改訂箇所の特定： 前版と改訂版を文単位で比較します。段落単位ではなく文単位にしてください。 段落単位だと、1文だけ直った段落全体が「改訂」となり、再利用できる文まで訳し直すことになります。

承認済み訳データベース： 原文の文をキーに検索します。完全一致だけでなく、文末の表現だけが違う文（「です」「ます」の違い、句読点の違い）も一致とみなす正規化を入れてください。これだけで一致率が大きく変わります。

用語集： 1,200語をそのまま渡す必要はありません。その文に含まれる語だけを抜き出して渡します。 1文につき数語から十数語です。

原稿が長い場合： 章単位でまとめて渡すこともできます。Gemini は100万トークン規模の入力を受け取れるモデルが提供されており、資料1冊分でも収まります。まとめて渡すと、章の中での訳語の一貫性が上がります。 ただし文単位の対応関係が取りにくくなるため、この構成では文単位を基本とし、一貫性の確認だけ章単位で行う形にしています。

AIへ渡す前に整形する

1. 文への分割 … 句点で分割します。表の中のセルは1セル1文として扱います
2. 正規化 … 全角・半角の統一、スペースの除去、句読点の統一を行い、既訳の検索に使うキーを作ります
3. 型番・数値の目印化 … 型番（XP-3200A）、数値と単位（0.75 MPa）を [MODEL1] [NUM1] のような目印に置き換えます。訳文を作った後、目印を元に戻します。これが数値の誤りを防ぐ一番確実な方法です
4. 注意・警告の分離 … 「警告」「注意」で始まる記述を別扱いにします。この部分は定訳を機械的に当て、AIに訳させません
5. 既訳の引き当て … 正規化したキーで承認済み訳データベースを検索し、完全一致した文を確定させます。この時点で、実際に訳す必要のある文は半分以下になります

AIに処理させる

型番と数値の検算は、AIではなく機械で行います。 目印に置き換えてあるので、訳文に目印がすべて残っているかを数えるだけで済みます。AIに「数値が合っているか確認して」と頼む必要はありません。

注意・警告の表記も、AIに訳させません。 「危険」「警告」「注意」の区別は、規格や業界の慣行で定訳が決まっていることがあります。定訳の表を持ち、機械的に当てます。

指示内容を固定する

あなたは産業機械の技術資料を翻訳する翻訳者です。
下の日本語の文を、{target_language} に訳してください。

【厳守事項】
- [MODEL1] [NUM1] のような目印は、そのまま残してください。
  中身を推測したり、訳したりしないでください。
- 下の用語集にある語は、必ず用語集の訳語を使ってください。
  用語集と違う訳語を使わないでください。
- 下の「近い既訳」と同じ意味の文なら、既訳の言い回しに合わせてください。
  理由なく別の言い回しにしないでください。
- 原文にない情報を足さないでください。
  「一般に」「通常」といった補足を入れないでください。
- 原文にある情報を省かないでください。
  条件（「〜の場合」「〜を除く」）を落とさないでください。
- 用語集にない技術用語が出てきた場合、訳語を1つ選んだうえで、
  unresolved_terms にその語を入れてください。
- 断定の強さを変えないでください。「〜することがあります」を
  「〜します」に変えないでください。

【原文】
{source_sentence}

【この文に含まれる用語集の語（日本語 / 訳語）】
{glossary_subset}

【近い既訳（原文 / 訳文 / 出所）】
{similar_approved_translations}

「断定の強さを変えない」の1行は、技術資料では特に重要です。 「損傷することがあります」を「損傷します」に変えると、意味が変わります。製品の性能や安全に関わる記述では、この差が問題になります。

出力形式を固定する

{
  "sentence_id": "",
  "source_text": "",
  "target_language": "",
  "translated_text": "",
  "glossary_terms_used": [
    { "source": "", "target": "" }
  ],
  "unresolved_terms": [],
  "reused_from": "",
  "deviation_reason": "",
  "placeholder_check": "ok | missing | extra",
  "needs_review": []
}

Gemini API では、JSONを返させる際に response_format にオブジェクト型を指定し、mime_type を application/json にしたうえで、schema にスキーマを渡します。スキーマは JSON Schema の一部（string number integer boolean object array など）に対応しています。

placeholder_check は、目印がすべて訳文に残っているかの判定です。missing なら数値や型番が落ちているため、その文は自動で再処理し、2回失敗したら人へ回します。

reused_from は、既訳のどの文を参考にしたかです。訳の出所が追えることが、資料間の一貫性を保つ土台になります。

システムへ連携する

出力は対訳表としてスプレッドシートに作ります。1行1文で、列は次のとおりです。

確定した訳文は、承認済み訳データベースへ登録します。この登録を忘れると、次の改訂でまた同じ文を訳すことになります。 確定の操作と登録を一体にしてください。

DTPソフトへの流し込みは、対訳表から訳文の列を書き出して行います。この部分は使っているDTPソフトによって方式が異なります。

人が確認する

全件、技術資料課が確認します。既訳を再利用した文も含めます。

既訳の再利用まで確認する理由は、前の資料で正しかった訳が、新しい文脈では合わないことがあるためです。ただし、再利用した文の確認は「文脈が同じか」を見るだけなので、新規に訳した文より短時間で済みます。

確認の優先順位は次のとおりです。

1. placeholder_check が missing の文 … 数値か型番が落ちている。最優先
2. unresolved_terms に語が入っている文 … 用語集にない技術用語。ここで決めた訳語を用語集へ追加します
3. deviation_reason が書かれている文 … 既訳と違う訳にした理由を読み、妥当かを判断する
4. 新規に生成した文 … 通常の確認
5. 既訳を再利用した文 … 文脈の一致だけを見る

2番の扱いが、この構成を育てます。 未解決の用語を毎回放置すると、用語集はいつまでも育たず、訳語のばらつきも減りません。確認のたびに数語ずつ用語集へ追加する運用を決めてください。

翻訳会社の校正は、文書の種類で分けることをおすすめします。 取扱説明書と安全に関わる記述は必ず出し、カタログの製品紹介文は社内確認で済ませる、といった切り分けです。

例外に対処する

記録を残す

この構成のログは、訳の一貫性を保つ資産そのものです。

• 承認済み訳データベース（原文／訳文／出所の資料／承認日／承認者）
• 用語集の変更履歴（いつ、どの語を、どの訳語で追加したか）
• 対訳表の各版（生成時点と確定時点）
• 人が修正した訳文と、修正前後の値
• unresolved_terms に挙がった語の一覧

修正前後の差分が、次の改善材料になります。 「特定の用語が毎回直されている」と分かれば、用語集の訳語が実態と合っていないということです。

承認済み訳データベースは、担当者が変わっても残る資産です。 現在は「あの人が訳したから一貫していた」という状態が、データベースに置き換わります。