社内マニュアル、取引先への仕様書、海外拠点との議事録。翻訳の需要が出てきたとき、まず候補に挙がるのが機械翻訳サービスと、ChatGPT や Claude のような大規模言語モデル（LLM＝大量の文章で学習させた、文章生成が得意な AI）です。どちらも「それなりに読める訳文」はすぐに出します。
ところが業務システムに組み込んだ途端、評価が割れます。原因のほとんどは訳文の自然さではなく、用語がぶれることです。同じ「加工指示書」が、ある箇所では processing instruction、別の箇所では machining order になる。社内の正式な英語名があるのに、AI が勝手に一般的な訳語を当てる。読む側は「別のものを指しているのか」と悩み、結局人が全文を見直すことになります。
この記事では、翻訳サービスと LLM を「用語の統一がどこまで効くか」という一点で比較し、実装で詰まりやすい箇所と、発注前に決めておくべきことを整理します。
業務翻訳の品質は「上手さ」ではなく「ぶれなさ」で測る
一般向けの翻訳比較では、訳文の流暢さや意訳の自然さが話題になります。しかし業務システムでは評価軸が違います。
- 再現性：同じ原文を二度入れたら、同じ訳文が返るか
- 一貫性：文書をまたいで、同じ語が同じ訳語になるか
- 検索性：訳文を後から全文検索したとき、意図した語でヒットするか
- 監査性：なぜその訳語になったかを、後から説明できるか
たとえば次のような場面です。製造業で部品名の訳語が文書ごとに揺れていると、海外拠点の担当者が在庫システムを検索しても目的の部品に辿り着けません。訳文としては両方とも正しくても、業務としては誤りです。翻訳 AI の選定では、この「業務としての正しさ」を先に定義しておく必要があります。
翻訳サービスと LLM は、そもそも設計思想が違う
両者はよく同じ土俵で比べられますが、作られた目的が異なります。
| 観点 | 機械翻訳サービス | LLM による翻訳 |
|---|---|---|
| 主な設計目的 | 原文を忠実に、安定して別言語へ変換する | 指示に沿って文章を生成する（翻訳はその一用途） |
| 出力の安定性 | 比較的高い。同じ入力でほぼ同じ出力 | 設定により揺れる。同じ入力でも表現が変わりうる |
| 用語の指定方法 | 用語集（グロッサリー）機能として製品に組み込まれていることが多い | プロンプト（指示文）に用語リストを書き込む形が基本 |
| 文脈の扱い | 文・段落単位が中心。前後の文書全体は見ない場合がある | 長い文脈を渡せば、文書全体のトーンや前提を加味できる |
| 指示への追従 | 翻訳以外の加工（敬体への統一、注記の付与など）は不得手 | 「丁寧語で」「専門用語は原語併記で」などの指示が効く |
| コスト構造 | 文字数課金が中心で、見積もりやすい | 入力と出力のトークン量に応じる。用語集を毎回渡すと膨らむ |
ざっくり言えば、機械翻訳サービスは「安定した変換機」、LLM は「指示が効く編集者」です。用語の統一という観点では、前者は仕組みで担保し、後者は指示で担保します。この違いが、実装の難所の違いに直結します。
用語の統一を効かせる三つの方法と、それぞれの限界
用語を揃える手段は大きく三つあります。どれか一つで足りることは少なく、組み合わせるのが現実的です。
| 方法 | やること | 効きやすい場面 | 限界 |
|---|---|---|---|
| 用語集機能を使う | 原語と訳語の対応表をサービスに登録し、翻訳時に適用する | 固有名詞、製品名、部署名など、常に同じ訳語でよい語 | 活用形や複合語に当たらないことがある。言語ペアごとに登録が要る |
| プロンプトに用語を渡す | LLM への指示文に「この語はこう訳す」のリストを含める | 文脈で訳し分けたい語、注記や但し書きを付けたい場合 | リストが長いと守られない語が出る。毎回のコストが増える |
| 後処理で検査する | 訳文を用語表と突き合わせ、違反があれば差し戻すか置換する | どの方式を選んでも最後の砦として機能する | 単純置換は文法を壊す。検出と自動修正は分けて考える必要がある |
重要なのは、用語集を「登録したら効くもの」と思わないことです。たとえば「加工指示書」を machining instruction sheet と登録しても、原文が「加工指示」「加工の指示書」と揺れていれば一致しません。つまり用語集の精度は、原文側の表記ゆれ対策とセットでしか上がりません。
この構造は、社内文書を検索させる仕組みと同じです。元になるデータの整理が追いついていなければ、モデルを替えても結果は変わりません。RAG の精度はモデルではなく文書管理で決まるで触れた前提は、翻訳にもほぼそのまま当てはまります。
実装で詰まりやすい五つの箇所
1. 用語集の所有者が決まっていない
最初の壁はほぼここです。用語集は一度作って終わりではなく、新製品や組織変更のたびに更新が要ります。誰が追加を承認し、誰が反映するかを決めずに始めると、半年で誰も信じない表になります。登録・改訂の申請経路と、改訂日の記録を最初に設計してください。
2. タグやプレースホルダが壊れる
HTML タグ、変数の差し込み記号、製品コードなど、訳してはいけない要素が混ざる文書は多いものです。LLM は親切心でこれらを整形したり、記号を全角に変えたりします。翻訳前に保護対象を抜き出して記号に置き換え、翻訳後に戻す処理を用意するのが定石です。
3. 同じ語を文脈で訳し分けたい
「ライン」が製造ラインなのか、罫線なのか、製品群なのか。用語集は一対一対応が基本なので、こうした語は苦手です。LLM に文書種別や部門を併せて渡し、分野ごとに用語集を切り替える設計が要ります。
4. 出力が毎回変わる
LLM は設定によって出力が揺れます。生成のばらつきを抑えるパラメータを下げる、訳文をキャッシュして同じ原文には同じ訳文を返す、といった対策で再現性を確保します。「前回と違う訳文が出た」という問い合わせは運用負荷として無視できません。
5. 機密情報が外部に出る
未公開の仕様書や個人情報を含む文書を、そのまま外部サービスへ送っていないか。個人情報保護法の観点からも、入力前の判定と遮断は仕組みとして持つべきです。この設計は翻訳に限らず共通で、AIに渡せない入力を止める手順の考え方がそのまま使えます。
どう選ぶか — 判断軸を四つに絞る
| 条件 | 向いている方式 |
|---|---|
| 定型文書が大量。訳語は固定でよい | 機械翻訳サービス＋用語集。コストと安定性で有利 |
| 文書の種類が多く、トーンや形式の調整も要る | LLM。指示で出力形式まで制御できる |
| 訳文をそのまま社外へ出す | 方式を問わず人のレビュー工程を必須にする |
| 既存の翻訳資産（過去訳）がある | 翻訳メモリ（過去の原文と訳文の対）を活かせる仕組みを優先 |
実務では「一次翻訳は機械翻訳サービス、用語違反の検出と語調の調整は LLM、最終判断は人」という三段構成に落ち着くことが多い構造です。片方に寄せようとせず、工程ごとに役割を割り振ると設計が楽になります。
なお、翻訳サービスの品質管理には ISO 17100 のような国際規格も存在します。社外向け文書を扱うなら、どの工程を機械に任せ、どの工程に人のチェックを残すかを文書化しておくと、取引先への説明がしやすくなります。
精度の議論を「感覚」で終わらせないために
翻訳 AI の比較は「こちらの方が自然」という印象論になりがちです。それを避けるには、判定可能な指標に置き換えます。
- 自社の実文書から 50〜100 文程度を抜き出し、正解訳を人が作る
- 用語集に載せた語が訳文に正しく出現した割合（用語遵守率）を測る
- 同じ原文を複数回投げて、出力が一致する割合（再現率）を測る
- タグや数値が壊れていないかの機械チェックを通す
この四つなら、担当者が変わっても同じ基準で比べられます。評価の作り方そのものは、評価データセットの作り方と運用で整理した手順と同じ考え方です。モデルやサービスを乗り換えるときも、この組が残っていれば判断は数時間で済みます。
まとめ
翻訳 AI の選定で見るべきは、訳文の美しさではなく用語の扱いです。要点を整理します。
- 機械翻訳サービスは仕組みで、LLM は指示で用語を揃える。得意な場面が違う
- 用語集は登録すれば効くものではない。原文の表記ゆれ対策と、更新の担当者決めがセット
- 詰まるのはタグの破壊、文脈での訳し分け、出力の揺れ、機密情報の扱い
- 一次翻訳・検査・最終判断を分け、工程ごとに適した手段を割り当てる
- 比較は用語遵守率と再現率という数えられる指標で行う
「どちらが優秀か」ではなく「自社のどの文書を、どの基準で揃えたいか」を先に決めること。ここが固まっていれば、ツールの比較は難しい作業ではなくなります。