専門用語が正しく訳されないのは、AIのせいではありません
「最新のLLM（大規模言語モデル）を導入したのに、『バリ取り（deburring）』が単なる『removal』と訳されてしまう」
「過去の翻訳データを学習させた途端、文体が崩れてしまった」
製造業の現場でDX推進を担当する方々から、こうした課題が頻繁に聞かれます。多くの企業が、翻訳精度の低さを「AIモデルの性能不足」だと結論づけ、より高価なエンジンや別のAPIへと乗り換えを検討します。しかし、断言させてください。そのアプローチは間違っています。
実務の現場で明らかになる現実は、AIの能力不足ではなく、AIに与える「データ」の問題です。特に製造業の技術文書は、一般的なビジネス文書とは異なり、極めて高い専門性と一貫性が求められます。ここで発生しているのは、汚れたデータがAIの判断を狂わせる「データ汚染」です。
AIは魔法の箱ではありません。入力された情報と、参照するデータベース（用語集や翻訳メモリ）に基づいて確率的に最適な答えを出力する計算機にすぎません。もし出力がおかしいのであれば、入力か参照データのどこかにノイズが混じっているのです。
本記事では、安易なモデル変更に走る前に、皆さんの手元にある「データ資産」を見直すための診断プロセスを共有します。これは、ITコンサルティングやシステム開発の現場で培われてきた、泥臭くも確実なトラブルシューティングの手法です。
精度95%の壁を突破するための鍵は、アルゴリズムの調整ではなく、データの「診断」と「治療」にあります。さあ、自社のデータに潜む病巣を一緒に特定していきましょう。
なぜ製造業のAI翻訳は「専門用語」でつまずくのか：診断の第一歩
まず、現状を正しく診断するためのフレームワークを共有します。翻訳精度が出ないとき、多くの人は「AIが賢くない」と考えがちですが、実際にはAIが「迷っている」状態であることがほとんどです。
モデル性能ではなく「データ品質」を疑うべき理由
近年のニューラル機械翻訳（NMT）やLLMの基礎能力は、すでに人間レベルに達しています。一般的な文脈であれば、文法的な誤りを犯すことは稀です。それにもかかわらず、製造業の現場で「使えない」と判断されるのはなぜでしょうか。
それは、製造業のドメイン知識が「一般常識」とは異なるからです。例えば「公差（tolerance）」や「焼きなまし（annealing）」といった言葉は、一般的な文脈では別の意味を持つことがあります。AIは文脈から確率的に最もありそうな訳語を選びますが、特化した指示やデータがない限り、一般的な（製造業にとっては誤った）訳語を選んでしまうのです。
これを修正するために「ファインチューニング」や「RAG（検索拡張生成）」を行いますが、ここで投入するデータの品質が低ければ、AIは誤った知識を自信満々に学習してしまいます。これを「ガベージイン・ガベージアウト（ゴミを入れればゴミが出る）」と呼びます。
精度低下の3大要因：用語集の不備、文脈不足、過去データのノイズ
問題の所在を切り分けるために、エラーを以下の3つに分類してください。
- 用語レベルのエラー: 特定の単語が定訳通りに訳されない。または、禁止用語が使われている。
- スタイル・文脈のエラー: 文法は合っているが、技術文書としてのトーン（命令形や受動態の使い分けなど）が不適切。
- 幻覚（ハルシネーション）: 原文にない内容が勝手に追加されている、あるいは重要な数値が改変されている。
製造業で特に致命的なのは1と3です。「ボルトを締める」が「ボルトを緩める」と訳されれば事故につながりますし、数値の誤りは仕様書の価値をゼロにします。
トラブルシューティング・フローチャート：問題の切り分け
以下の手順で診断を行ってください。
用語集（Glossary）は適用されているか？
- No → 用語集のフォーマットやAPI連携の設定ミス。
- Yesだが誤訳 → 症状1へ。
翻訳メモリ（TM）や過去データを学習させたか？
- Yes → 過去データの品質（整合性）に問題がある可能性が高い。 → 症状2へ。
原文（日本語）は明瞭か？
- 主語が省略されていないか？ 一文が長すぎないか？ → 症状3へ。
この3つの症状について、次章から詳しく解説し、具体的な処方箋を提示します。これは単なるツールの設定変更ではなく、組織としての「情報管理」の在り方を問う作業でもあります。
症状1：登録したはずの用語集が無視される・誤適用される
「用語集に『バリ取り＝deburring』と登録したのに、AIが『removing burrs』と訳してくる」。あるいは逆に、「文脈に関係なく無理やり用語集の訳語を当てはめて、文章が破綻する」。
これらは、用語集管理における典型的なトラブルです。原因はAIの反乱ではなく、用語集の定義そのものの「曖昧さ」にあります。
原因診断：用語の「多義性」と「品詞の衝突」
従来のルールベース翻訳と異なり、最近のAIモデルは「文脈」を重視します。そのため、用語集で強制的に単語を置き換える指示を出すと、AIが生成しようとする自然な文脈と衝突し、結果として用語集が無視されたり、文法がおかしくなったりします。
例えば、「逃げ（relief）」という用語を登録したとします。しかし、原文に「危険からの逃げ」という文脈があった場合、これを「relief」と訳すと意味が通りません。AIはこの違和感を検知し、用語集を無視して「escape」と訳すことがあります。これはAIの賢さゆえの挙動ですが、管理者から見れば「用語集無視」と映ります。
また、品詞の問題も深刻です。名詞として登録した用語が、原文では動詞として使われている場合、単純な置換を行うと文法が崩壊します。
解決策：強制置換ではなく「コンテキスト付与」による制御
この問題を解決するには、用語集を単なる「置換リスト」として扱うのをやめ、AIに対する「コンテキスト（文脈）指示書」として再定義する必要があります。
具体的には、LLMを活用した翻訳プロセスにおいて、プロンプト内で以下のような指示を与えます。
「以下の用語リストを参照し、文脈に応じて適切な品詞変形を行いながら翻訳してください。ただし、専門用語としての意味（例：機械加工における『逃げ』）が損なわれないように注意すること。」
さらに、用語集データ自体に「メタデータ」を付与することを強く推奨します。単に「日本語：英語」のペアだけでなく、「品詞」「定義」「使用カテゴリー」を付記するのです。
- 悪い例:
逃げ:relief - 良い例:
逃げ:relief(Category: Machining, Part of Speech: Noun, Context: Tools clearance)
このように情報量を増やすことで、AIは「この文脈での『逃げ』は加工用語だから『relief』を使うべきだ」と正しく推論できるようになります。
用語集整備の落とし穴：類義語と禁止用語の定義
もう一つの重要なテクニックは、「禁止用語（Negative Glossary）」の活用です。正解を教えるだけでなく、「何を使ってはいけないか」を明示することで、精度は劇的に向上します。
例えば、自社製品で「Assembly」を「組立」ではなく「アセンブリ」と統一したい場合、「Assembly = アセンブリ」と登録するだけでは不十分です。「Assembly ≠ 組立」という禁止ルールをセットで学習・指示させることで、表記揺れを確実に防ぐことができます。
用語集の整備は、AI翻訳の土台です。ここが揺らいでいると、どんなに高性能なモデルを使っても砂上の楼閣に終わります。
症状2：過去の翻訳資産（TM）を学習させたら逆に精度が落ちた
長年蓄積してきた翻訳メモリ（Translation Memory: TM）を活用し、これをAIに学習させれば完璧な翻訳モデルが構築できる。そう期待して実行した結果、かえって訳文の品質が低下し、文脈に合わない不自然な文章が生成されるようになったというケースは珍しくありません。
これは、データに基づくAI運用における「データ汚染」の典型的な症状です。過去の貴重な資産が、AIの学習プロセスにおいてはノイズとなり、出力精度を下げる要因になっているのです。
原因診断：レガシーデータに潜む「意訳」と「誤訳」のノイズ
人間が翻訳したデータは、常に機械的な「直訳」というわけではありません。読者の理解を助けるための「意訳」、原文の情報を補足した「加筆」、あるいは単純な「誤訳」が混入しているのが一般的です。
例えば、日本語のマニュアルで「安全第一で作業すること」という文に対し、英語の翻訳メモリに「Always wear protective gear（常に保護具を着用すること）」と記録されていたと仮定します。現場の運用マニュアルとしては適切な意訳かもしれませんが、AIがこれをそのまま学習すると、「安全第一＝保護具着用」という偏った相関関係を構築してしまいます。
その結果、全く別の文脈で「安全第一」という言葉が登場した際にも、前後の文脈を無視して「保護具を着用せよ」と誤って訳出するリスクが生じます。これが、クレンジングされていない過去データを学習させた際に引き起こされる過学習や、文脈からの逸脱（ハルシネーション）の根本的な原因です。
解決策：AI学習用データのクレンジング手順
過去の翻訳資産をAIの学習データとして活用する場合、特にファインチューニングや、良質な例示を数個提示するFew-Shotプロンプティングを実践する際には、徹底的なデータのクレンジング（洗浄）が不可欠です。
最新の動向において、Few-ShotプロンプティングはAIの出力形式やトーンを制御する上で最も推奨される手法の一つです。ClaudeやGeminiなどの最新モデルは文脈理解能力が飛躍的に向上しており、「あなたはプロの翻訳家です」といった複雑なロールプロンプトよりも、2〜3個の質の高い具体例を提示するシンプルなアプローチが重視されています。
また、複雑な翻訳タスクにおいては、推論精度を向上させる「Chain-of-Thought（思考の連鎖）」の活用も有効です。プロンプトで段階的な思考を促す従来の手法に加え、最新モデルでは問題の複雑さに応じて推論の深さを自動調整する「適応型思考（Adaptive Thinking）」機能が実装されつつあり、これらを組み合わせることでさらに高い精度が期待できます。
しかし、ここで与える「例示（ショット）」にノイズが含まれていると、最新のAIであってもその誤ったパターンを忠実に模倣してしまいます。以下の手順でデータを浄化し、AIにとって最適な「良質な教材」へと変換してください。
- 重複と矛盾の排除: 同じ原文に対して異なる訳文が存在する場合、最新かつ正しいもの一つに統一します。矛盾したデータはAIの推論を混乱させる最大の要因です。
- アライメント（対訳）の確認: 原文と訳文が文単位で正しく対応しているか確認します。一文対一文ではなく、一文対二文になっているような箇所は、AI学習用としては不適切と判断し、除外または分割します。
- 数値と固有名詞のチェック: 原文と訳文で数字や固有名詞が食い違っているデータは、即座に削除してください。これらは翻訳精度を著しく下げる致命的なノイズとなります。
- 短すぎる/長すぎる文の除外: 単語のみのペアや、極端に長い段落単位のペアは、学習効率を低下させるためデータセットから除外します。
「人間による読みやすさ」と「AI学習用データ」の乖離
ここで重要な視点は、「人間が読んで理解しやすいデータ」と「AIが学習しやすいデータ」は明確に異なるという事実です。
AIのベースモデルに学習させるためのデータは、「構造的に整合性が取れていること」が最優先されます。多少表現が硬直的であっても、原文の構造を忠実に反映した直訳的なデータの方が、AIが言語の基本ルールを学習するための素材として優れています。
意訳のニュアンスや自然な言い回しは、ベースモデルの学習段階ではなく、仕上げのプロンプト指示や事後編集（ポストエディット）の段階で調整すべき領域です。翻訳メモリをそのままシステムに流し込むのではなく、一度「正規化」というフィルターを通す。この工程を確実に行うことで、カスタマイズされたAIモデルの出力精度は見違えるほど安定します。
症状3：表記揺れとスタイル不統一が頻発する
用語集も整備し、データもクレンジングした。それでも翻訳結果が安定しない。その場合、原因は「入力する日本語」そのものにあります。
製造業の技術文書、特に現場で作成されるドキュメントは、独特の「曖昧さ」を含んでいることが多々あります。
原因診断：原文（日本語）側の曖昧さと構造的欠陥
日本語は「ハイコンテキスト」な言語です。主語を省略しても通じますし、係り受け（どの言葉がどの言葉にかかっているか）が曖昧でも、人間なら文脈で補完して理解できます。
例：「カバーを外し、洗浄して、油を差してから戻す。」
この文の「戻す」の目的語は何でしょうか？ 人間なら「カバー」だとわかりますが、AIは「油」を戻すのか、「洗浄液」を戻すのか、あるいは「作業員が元の場所に戻る」のか、迷う可能性があります。
また、「バリ取り作業実施のこと」のような体言止めの多用も、AIにとっては主語や動詞の時制を特定しにくくさせる要因です。
原文が曖昧であれば、訳文も曖昧になるか、AIが勝手に解釈して誤訳を生み出します。これを翻訳エンジンの責任にするのは酷というものです。
解決策：翻訳しやすい日本語（Controlled Language）への書き換え
この問題を解決する唯一の方法は、原文を「機械翻訳しやすい日本語」、いわゆる制限言語（Controlled Language）や簡潔化英語（Simplified English）のルールに基づいて書き換えることです。
これをプリエディット（前編集）と呼びます。主なルールは以下の通りです。
- 一文一義: 一つの文には一つの情報だけを含める。接続助詞（～して、～ので）で長く繋げない。
- 主語の明示: 誰が、何が、を省略せずに書く。
- 能動態の使用: 受動態は動作主を曖昧にするため、可能な限り能動態にする。
- 用語の統一: 同じ部品には常に同じ名称を使う。「筐体」「ケース」「ボックス」を混在させない。
前処理としての「原文リライト」自動化
「全技術者に書き方を教育するのは無理だ」と思われるかもしれません。そこで、ここでもAIを活用します。
翻訳にかける前に、一度AI（LLM）を通して「原文のリライト」を行わせるのです。
プロンプト例：
「以下の技術文章を、機械翻訳に適した明確で論理的な日本語に書き直してください。主語を補い、一文を短くし、曖昧な表現を排除してください。」
この「前処理」を挟むことで、翻訳エンジンの解釈ミスを大幅に減らすことができます。実際、適切に導入した場合、原文のリライト工程を入れただけで、翻訳後の修正工数が30%前後削減された事例もあります。
原文の品質管理こそが、翻訳品質管理の源流なのです。
運用フェーズでの品質保証：Human-in-the-loopの構築
診断と対策を行っても、AI翻訳が100%完璧になることはありません。言語は生き物であり、新しい技術用語は日々生まれます。重要なのは、エラーをゼロにすることではなく、エラーを迅速に検知し、システムを継続的に賢くしていく運用サイクルを作ることです。
エラー検知の自動化と人間によるレビューの役割分担
全ての訳文を人間がチェックするのは非効率です。AIの信頼度スコア（Quality Estimation）を活用し、AIが「自信がない」と判定した箇所や、重要なキーワードが含まれる箇所を重点的に人間がレビューする体制を組みましょう。
これをHuman-in-the-loop（人間が介在するループ）と呼びます。人間は「全量検査」ではなく「教師役」として振る舞うのです。
フィードバックループ：修正結果を用語集に還流させる仕組み
最も重要なのは、人間が行った修正（ポストエディット）を、必ずシステムにフィードバックすることです。
現場のエンジニアや翻訳者が修正した内容を、定期的に用語集や翻訳メモリに反映させるワークフローを確立してください。「修正して終わり」では、AIはいつまでたっても同じ間違いを繰り返します。
- 週次レビュー: 修正ログを集計し、頻出する修正パターンを特定。
- 月次メンテナンス: 新しい用語を用語集に追加し、不要なルールを削除。
このサイクルを回すことで、AI翻訳システムは自社のビジネスに合わせて「成長」していきます。
安心運用のためのチェックリスト
最後に、AI翻訳の品質を維持し続けるためのチェックリストを提示します。これを定期的に確認し、データの健全性を保ってください。
- 用語集の鮮度: 3ヶ月以内に更新されているか？
- 原文の品質: 制限言語のルールが守られているか？
- フィードバック: 前回の翻訳修正が、今回の出力に反映されているか？
- 数値整合性: 原文と訳文の数値チェックは自動化されているか？
まとめ：データ品質への投資が、最強の翻訳エンジンを作る
製造業におけるAI翻訳の精度向上は、魔法のような新技術によってではなく、地道な「データ管理」によって達成されます。
- 用語集を「コンテキスト指示書」として再定義する。
- 過去の翻訳資産を「クレンジング」し、ノイズを取り除く。
- 原文を「制限言語」で記述し、AIが解釈しやすい形にする。
これらは一見、遠回りで泥臭い作業に見えるかもしれません。しかし、これこそが「見えないデータ汚染」を取り除き、AIのポテンシャルを最大限に引き出す唯一の道です。
AIは企業の技術力を世界に伝える強力なパートナーになり得ます。ただし、それは正しい言葉（データ）を教え込んだ場合に限ります。今日から、モデルの選定カタログを閉じ、自社のデータを見直すことから始めてみてください。
コメント