企業の翻訳自動化2026｜タイ工場で訳のブレを止める3層設計

翻訳の自動化を企業で進めると、たいてい同じ場所で止まる。エンジンを変えても、プロンプトを練っても、現場からは「訳がブレる」という声が消えない。原因は精度ではなく設計にある。社内文書を1本のパイプラインに流し込んでいる限り、統制文書も日報も同じ扱いになり、どこまで機械に任せてよいかが誰にも判断できなくなる。本記事では、文書を4クラスに分け、用語・生成・承認の3層で組み直す方法を、タイの日系工場を前提に整理する。

翻訳の自動化が企業で止まる本当の理由

タイやベトナムに拠点を持つ日系製造業では、日本語・タイ語・英語の3言語、場合によってはベトナム語や中国語を加えた4〜5言語が日常的に行き交う。本社からの技術通達、現地の作業標準書、顧客監査への回答、日々の生産日報。これらすべてに翻訳が発生し、その多くが誰かの残業で処理されている。

「エンジンを変えれば解決する」という誤解

翻訳が滞っているとき、最初に検討されるのはたいてい翻訳エンジンの入れ替えである。従来型の機械翻訳からLLMベースの翻訳へ、あるいは汎用LLMから翻訳特化サービスへ。しかしエンジンを入れ替えても、現場からの不満はほとんど変わらない。

理由は単純で、不満の中身が「訳が下手」ではなく「訳が揃わない」だからである。先月の作業標準書では「段取り替え」が「การเปลี่ยนรุ่น」と訳されていたのに、今月の改訂版では別の語になっている。同じ設備名が文書ごとに違う呼ばれ方をする。この現象は用語の揺れ（terminology drift）と呼ばれ、汎用LLMを文脈なしで使う限り構造的に発生する。LLMは毎回もっともらしい訳語を生成するが、「前回どう訳したか」を記憶していない。

2026年時点の評価でも、機械翻訳が扱える範囲は明確に広がった一方で、企業のローカライズから人の判断を取り除く水準には至っていないとされている。文脈情報が与えられない状態でのLLM翻訳は、言語ペアによって55.7〜80%の割合で「良好」と評価されたという比較結果がある。ただしこれは英語から独語・ポーランド語・ロシア語といった欧州言語ペアでの数字であり、日本語からタイ語・ベトナム語という本記事の対象では、学習データ量の差からこれより厳しく出ると考えておいた方がよい。欧州言語ペアの数字を採ってさえ、2割から4割は良好とは言えない計算になる。しかもどの2割が外れるかは事前に分からない。

「1本のパイプライン」が生む破綻

多くの企業が最初に組む構成は、社内文書をひとつの翻訳ワークフローに集約するものだ。ファイルを投入すれば訳文が返る。一見効率的だが、この構成には致命的な前提の混同がある。

作業標準書と社内メールを同じ処理に流すと、次のどちらかが起きる。品質基準を作業標準書に合わせれば、メール1通の翻訳にまで承認フローがかかり、誰も使わなくなる。品質基準をメールに合わせれば、作業標準書が無検証で現場に出て、監査で指摘を受ける。中間を取ろうとすると、どちらの要求も満たさない中途半端な運用になる。

翻訳の自動化が企業で失敗するのは、翻訳エンジンの精度が足りないからではない。文書ごとに異なるはずの「機械に任せてよい範囲」を、ひとつの設定で決めようとしているからである。

判断の単位を「文書クラス」に移す

解決の方向は明快で、判断の単位を「ツール」から「文書クラス」に移すことだ。どのエンジンを使うかではなく、この文書はどのクラスに属し、そのクラスではどこまで機械に任せ、どこから人が署名するかを先に決める。エンジン選定はその後で構わない。むしろクラスごとに違うエンジンを使い分けても何も問題はない。

社内文書を4クラスに分ける

以下の4分類は、タイの日系工場で実際に流通している文書を、「誤訳が起きたときに何が壊れるか」で切り分けたものである。業種によって細部は変わるが、この4つで大半は収まる。

クラスA 統制文書 — AIは下訳まで

ISO 9001 の管理対象になる文書群である。箇条7.5「文書化した情報」は、必要なときに利用可能で使用に適した状態であること、識別でき、意図しない改変から十分に保護されることを求めている。統制文書は正式なレビューと承認を経て発行され、配布と保管が管理される。

ここで訳がブレると、単に読みにくいでは済まない。日本語版の作業標準書とタイ語版で締付トルクの表現が食い違えば、どちらが正なのかを監査で問われる。用語ベース（承認済み訳語）と翻訳メモリ（承認済みの文単位の訳）は、コンプライアンス文脈では「統制された語彙の層」を成すものと位置づけられ、監査人はその文書化を期待する。つまり用語ベースは品質向上のための道具であると同時に、監査で示すべき証跡でもある。

このクラスでAIに任せてよいのは下訳までだ。下訳の生成は速く、そこから人が直す方が白紙から訳すより明確に速い。ただし承認署名は人が行い、誰がいつどの版を承認したかを残す。

クラスB 運用文書 — 全自動でよい

日報、社内連絡、議事録、メール。このクラスは誤訳コストが低く、速度そのものが価値になる。読み手はその場で文脈を持っているため、多少不自然な訳でも意図は伝わる。伝わらなければ聞き直せばよい。

ここが議事録の自動作成AIや文字起こしAIの活用が最も効く領域である。日本人管理職とタイ人スタッフが同席する会議で、日本語とタイ語が交互に飛ぶ。従来は誰かが手でメモを取り、後から両言語版を作っていた。生成AIによる議事録作成では、録音から文字起こしを行い、決定事項と担当者と期限を抽出し、両言語で出力するところまでを一連で処理できる。投資対効果が最も読みやすいのもこのクラスである。

文書作成AIやレポート自動作成AIの導入検討も、まずこのクラスから始めるべきである。定型の生産報告や月次サマリーは、テンプレートが固定されており、数値はシステムから取れる。文章生成と翻訳を同時に自動化しても、失敗したときの被害が限定される。

「全自動でよい」は「誰も見なくてよい」ではない。月に数件を抜き取って読み、意図が変わる誤訳が出ていないかだけを確認する。目的は品質保証ではなく、エンジンや設定を変えたときに劣化に気づくためのセンサーである。1件あたり数分で足りる。

クラスC 対外文書 — AIは訳出ではなく整合チェックに使う

顧客提出資料、監査回答、契約書、クレーム回答。誤訳が取引関係や法的責任に直結するため、訳出そのものを機械に任せるのは避ける。

ただしAIを使わないという意味ではない。使いどころが違う。人が訳した文書に対して、AIに逆翻訳させて元の日本語と突き合わせる、数値・型式・日付の転記漏れを検出させる、社内の用語ベースに反する語が混ざっていないかを照合させる。こうした整合チェックは機械が得意で、人間のレビュアーが見落としやすい部分でもある。AI翻訳のビジネス活用としては地味な使い方だが、事故を減らす効果は大きい。

クラスD 現場UI文言 — これは翻訳ではなく設計である

見落とされやすいのがこのクラスだ。HMI画面のボタンラベル、アンドンのメッセージ、帳票の列見出し、ポカヨケ装置の警告表示。これらは文字数と表示幅に厳しい制約がある。

日本語で「異常停止」と4文字で収まる表示が、タイ語では「หยุดเนื่องจากความผิดปกติ」と大きく伸びる。既存の翻訳ワークフローに流せば、文法的には正しいが画面からはみ出す訳文が返ってくる。現場は結局それを手で詰め、詰めた結果が用語ベースに戻らないため、次の改修でまた同じことが起きる。

現場UI文言は翻訳工程から切り離し、画面設計の一部として扱う。 表示可能文字数を仕様として先に決め、その制約下で各言語の文言を作る。翻訳者ではなく、現場を知っている人間が決める。この切り分けをしないまま自動化を進めると、UI文言の手直しが延々と残り、「自動化したのに楽にならない」という評価につながる。

訳のブレを止める3層設計

クラス分けが「何をどこまで任せるか」の判断だとすれば、3層設計は「どう組むか」の実装方針である。用語層・生成層・承認層の3つを分けて考える。

第1層 用語層 — 用語ベースと翻訳メモリ

最下層に置くのが用語ベース（Term Base）と翻訳メモリ（Translation Memory）である。用語ベースは語の単位で「この語はこう訳す」を固定する辞書、翻訳メモリは文の単位で「この文は過去にこう訳して承認された」を蓄積する記録だ。

この層が無いと、どれだけ優れたLLMを使っても同じ語が毎回違う訳になる。逆にこの層があれば、生成層のエンジンを入れ替えても訳語の一貫性は保たれる。エンジンは数年で世代交代するが、用語ベースは資産として残る。先に投資すべきはエンジンではなく用語層である。

登録すべき語は、社内固有語、製品名、工程名、設備名、部署名、帳票名、品質用語。数としては200語程度から始めれば足りる。最初から網羅しようとして頓挫するより、頻出語200語で運用を始めて、揺れが見つかるたびに追加する方が続く。

第2層 生成層 — LLMと社内文脈の注入

中間層が実際に訳文を作る部分である。ここでLLMを使うが、素のLLMに投げるのではなく、用語ベースと過去の承認済み訳、そして文書が属する工程の文脈を一緒に渡す。検索拡張生成（RAG）の構成を取り、過去に承認された訳文を参照させるのが基本形になる。

社内文脈をどう注入するかは実装上の勘所が多い。どの文書を検索対象にするか、版が複数ある文書のどれを正とするか、機密度の高い文書をどう分離するか。この辺りの考え方はRAG構築の費用と進め方で扱っているので、生成層の設計を検討する段階で参照してほしい。

用途によってモデルを変えるのも有効である。技術文書やコードのローカライズに適したモデルと、ブランド色の強いマーケティング翻訳に適したモデルは異なるという比較結果が出ている。工場文書は前者に寄るが、対外向けの会社紹介資料などは後者の性格を持つ。1つのモデルで全部を賄おうとしない。

第3層 承認層 — 版管理と承認署名

最上層が承認である。誰がいつどの版を承認したかを記録し、承認済みの版だけが現場に配布される状態を作る。ISO 9001 箇条7.5の管理下に置くというのは、具体的にはこの層を実装するということだ。

承認層で決めておくべきことは4つある。

• 承認者は誰か（クラスAは品質保証責任者、クラスCは部門長など、クラスごとに定義する）
• 何をもって承認とするか（電子署名、ワークフローツール上の承認記録、紙の押印のいずれか）
• 旧版をどう扱うか（現場から回収するのか、システム上で無効化するのか）
• 承認済み訳をどう用語層に返すか（ここを設計しないと3層が循環しない）

4つ目が特に重要である。承認された訳文が翻訳メモリに戻らなければ、次回また同じ修正を人がやることになる。3層設計は用語層から承認層への一方通行ではなく、承認層から用語層へ訳が戻ってくる循環があって初めて機能する。

3層を図で持つ意味

この3層構造は、社内説明の道具としても効く。「AIで翻訳を自動化します」と言うと、経営層からは「品質は誰が保証するのか」、現場からは「また新しいツールか」という反応が返る。3層の図を示し、承認層は人が持つ、用語層は現場の呼び名を登録する、と説明すれば、議論の対象が具体化する。導入の合意形成は、技術の説明ではなく責任分界の説明で進む。

KPIを「精度99%」から「TTE」に置き換える

翻訳自動化のプロジェクトが迷走する典型パターンは、KPIを翻訳精度の百分率で置いてしまうことである。

精度の%は工程の負荷を表さない

精度95%と聞けば十分に思えるが、実務では意味を持たない。1文書に100文あって5文が誤っている場合、その5文を見つけるために人は100文すべてを読む。読む時間は精度が上がってもほとんど減らない。精度99%になっても、どの1文が誤りか分からない以上、全文の確認は必要になる。

さらに悪いことに、LLM翻訳の誤りは「明らかにおかしい」形では出ない。流暢で自然な訳文の中に、用語だけが違う語に置き換わっている。従来型の機械翻訳のような不自然さがないぶん、見落としやすい。精度の数字が上がるほど、確認者の緊張感は下がり、見落とし率は上がる。

TTE（Time to Edit）とは何か

代わりに置くべき指標が TTE（Time to Edit） である。機械が出した訳文を、人が実用水準に直し終えるまでの実測時間を測る。2026年の機械翻訳評価では、TTEはプロの翻訳者が機械翻訳の出力を人間品質まで引き上げるのに要する時間として定義されており、本番環境で導入効果を見るのに向いた指標として扱われている。作業が減ったのか、下流に移っただけなのかは、この時間を測らないと分からない。

測り方は単純だ。同じ文書について、白紙から人が訳した場合の所要時間と、機械の下訳を人が直した場合の所要時間を比べる。後者が明確に短ければ自動化は効いている。ほぼ同じか長ければ、その文書クラスでは自動化が機能していない。

TTEを測るときの注意点

TTEは文書クラスごとに分けて測る必要がある。クラスB全体でTTEが8割削減されていても、クラスAで削減ゼロなら、クラスAは自動化の対象から外すか、用語層の整備が足りていない。全体平均で見ると、この判断ができない。

もう一点、TTEには「直す人の熟練度」が効く。導入直後は誰も直し方に慣れておらず、TTEが実力より長く出る。最初の1か月の数値で判断せず、3か月程度の推移を見る。逆に、3か月経ってもTTEが下がらない領域は、人の慣れの問題ではなく設計の問題である。

タイ語・ベトナム語で崩れる場所

言語ごとの固有事情を無視すると、設計が正しくても現場では機能しない。ASEAN地域で特に注意すべき点を挙げる。

タイ語 — 分かち書きの誤りが訳を崩す

タイ語は単語と単語の間にスペースを置かない。したがって機械が処理する際には、まず文字列をどこで単語に区切るか（word segmentation）を判定する必要がある。ここを誤ると、その後の訳がまとめて崩れる。

固有名詞や社内造語、日本語のカタカナ語をタイ文字に音写した語などは、辞書に無いため区切りを誤りやすい。「ポカヨケ」「アンドン」「かんばん」といった製造用語をタイ文字表記した場合が典型だ。用語ベースにこれらを登録しておくことが、単なる訳語統一以上の意味を持つ。

トークン数とAPIコストの非対称性

多言語LLMのトークナイザは言語によって効率が異なる。同じ内容を表現しても、タイ文字は英語に比べてトークン数が増えやすいことが指摘されている。APIの課金がトークン単位である以上、これはそのままコスト差になる。日本語も英語よりは分が悪いため、タイ語との差は英語基準で見たときほど大きくはならないが、英語ベースの単価から出発すると読み違える。

見積もりの段階で英語ベースの単価を使うと、タイ語運用に移した時点で想定を超える。試算の段階では、対象言語で実際にサンプルを流してトークン数を実測してから単価を置くべきである。翻訳量が多い企業ほど、この差は無視できない規模になる。

なお、タイ語をはじめとする東南アジア言語のLLM評価は近年整備が進んでおり、SEACrowd や SEA-HELM といった東南アジア横断の取り組みに加えて、タイ語では WangchanThaiInstruct のような指示追従データセットや、文化・基礎能力を測るベンチマークが公開されている。モデル選定の際は、英語中心のベンチマークだけでなく、こうした地域言語の評価も参照する価値がある。

ベトナム語 — 声調記号の脱落

ベトナム語では声調記号の有無が語の意味を変える。記号が落ちた状態のテキストが混入すると、機械はそれを別の語として扱う。原因は翻訳エンジンではなく、多くの場合その手前にある。古い基幹システムからのCSV出力、文字コードの取り違え、フォントが対応していない帳票テンプレート。

対策は翻訳工程の外側にある。文字化けや記号脱落を検出するチェックを入力側に置き、翻訳エンジンに渡す前に弾く。翻訳の品質問題として扱うと原因にたどり着かない。

多言語の社内問い合わせをどう受けるか

言語が増えると、翻訳そのものより「誰に聞けばいいか分からない」問題が大きくなる。タイ人スタッフが日本語の通達を読んで疑問を持ったとき、日本語で書かれた社内規程を検索する手段がなければ、結局は日本人管理者に直接聞くしかない。ここが管理者の時間を食う。

社内問い合わせの一次受けを多言語対応させる方法はチャットボット導入の費用と進め方で整理している。翻訳自動化と問い合わせ自動化は別プロジェクトとして立てられがちだが、参照する用語ベースは共通化できる。

自動化しても残る手間の正体

翻訳自動化の投資判断が外れる最大の理由は、自動化されない領域を数えていないことである。

図中文字 — テキスト翻訳の射程外

CAD図面の注記、設備写真に写った銘板、スキャンPDFの中の表。これらの文字はテキストとして扱えないため、通常の翻訳ワークフローには乗らない。そして工場文書において、これらの割合は決して小さくない。

現場の手間の大部分はここに残る。作業標準書の本文だけを自動翻訳しても、図の中の指示が日本語のままなら、現場は結局読めない。ここを処理するにはAI-OCRとの組み合わせが要る。画像から文字領域を検出し、テキスト化し、翻訳し、元の位置に戻す。最後の「元の位置に戻す」が最も難しく、完全自動化は現実的でない場合が多い。

導入検討の際は、対象文書のうち図中文字を含むものの割合を先に数えておくべきである。この数字を知らないまま「作業標準書の翻訳を自動化する」と決めると、稼働後に想定の半分しか効果が出ない。

「読めるが従わない」問題

もう一つの伏兵が、訳文の品質とは別の次元にある。訳が文法的に正しくても、現場用語が本社の直訳語のままだと、タイ人スタッフは実際の呼び名と一致しないため読み飛ばす。

たとえば本社が「予防保全」と呼ぶ活動を、タイの現場では英語由来の別の言い方で呼んでいる。直訳した訳語を標準書に載せると、読んだスタッフは自分の仕事の話だと認識しない。文書としては正しく、監査でも問題にならないが、行動は変わらない。

用語ベースに登録すべきは「正しい訳」ではなく「現場で実際に使われている語」である。 これを決めるには、翻訳担当者ではなく現場のリーダー層に聞くしかない。用語ベース構築を翻訳会社に丸投げすると、正しいが使われない訳語の一覧ができあがる。

定着させる側の設計

ツールを入れただけでは運用は変わらない。翻訳自動化の場合、変わるのは「翻訳を依頼していた人」ではなく「訳文を確認する人」の仕事である。これまで翻訳を外に出していた担当者は、これからは機械の訳を承認する立場になる。役割が変わる以上、教育が要る。

生成AI関連の教育が定着しない典型的な原因は生成AI研修が定着しない4つの原因にまとめている。翻訳自動化に限らず、業務自動化をAIで進める取り組み全般で同じ壁にぶつかるため、導入計画の中に教育の枠を最初から取っておく方がよい。

タイの製造現場では、OJTにおける言葉の壁が学習負担として指摘されており、タイ語話者スタッフ向けの教材整備が推奨されている。翻訳自動化はこの教材整備を安くする手段でもある。翻訳工数の削減だけを効果として数えると、この側面が見えなくなる。

タイ中規模日系工場でのコスト試算

以下は、タイに製造拠点を持つ従業員300名程度の日系工場を想定した年間試算である。実測値ではなく、複数の案件で見た標準的な水準から置いた想定値であることを先に断っておく。自社の数字を入れて計算し直すための骨組みとして使ってほしい。

前提条件

金額はすべてTHB建てで置いている。為替は変動するため円換算での比較は避け、THBのまま意思決定するのが実務的である。なお外注のリードタイムも設計変数になる。自動車部品メーカーの品質マニュアルや点検チェックリストを日本語からタイ語へ翻訳する場合、翻訳会社の提示で納期3週間程度という水準が示されている例がある。改訂の多い統制文書では、この3週間が現場への展開遅れとしてそのまま効いてくる。

3シナリオの比較

太字部分が総額である。上2行が見積書や請求書に載る費用、下5行が社内の時間として消えていく表に出ないコストにあたる。ここで差が出るのが本記事の主張である。

承認者の確認工数は、外注翻訳100%とクラス分割の両方に同額を積んでいる。クラスAとクラスCの承認署名は誰が訳したかに関係なく発生するからで、外注に出したからといって消えるものではない。AI全自動100%の列だけが空欄なのは、このシナリオがそもそも承認の席を用意していないためであり、安く済んでいるのではなく手順を飛ばしている。なお外注翻訳100%は、比較の便宜上クラスDの現場UI文言も含めて外注に出し、表示幅の制約を発注仕様に含めた前提で計算しているため、この列には表示崩れの改修費を計上していない。

表の読み方

外注翻訳100%は、直接費が突出して大きい。総額のおよそ89%が翻訳会社への支払いで、残りが内部工数である。管理は楽だが、量が増えるとそのまま費用が増える構造になっている。

AI全自動100%は、直接費が劇的に小さくなる一方で、訳語照合と手戻りが950,000 THBまで膨らむ。クラスAで用語が揺れた文書を後から是正し、再発行し、配布し直す工数がここに入る。UI文言の表示崩れ改修250,000 THBが3シナリオで唯一この列にだけ立つのも、表示幅の制約を仕様として渡す相手がいないためである。

そして最も重要な点として、AI全自動100%の総額が示していないリスクがある。統制文書に承認署名の記録が無い状態は、金額では表れないが監査で問題になる。是正処置につながった場合の費用は状況に依存しすぎるため、この表には計上していない。総額が安いことをもって全自動を選ぶ判断は、この欠落を見落としている。

クラス分割は、承認工数252,000 THBを外注シナリオと同じだけ残したまま、直接費と手戻りの両方を下げている。承認は削減対象ではなく、意図して残したコストである。用語ベースが効くぶん訳語照合の手戻りが154,600 THBまで下がり、監査時の説明工数も承認履歴が残るため20,000 THBに収まる。

この試算に書かなかったこと

クラス分割シナリオの初期セットアップ570,000 THBには、用語ベース構築、翻訳メモリ整備、クラスD文言の設計切り出しが含まれる。このうち相当部分は初年度に偏る一時費用であり、2年目以降は下がる。ただし何年で回収できるかという数字は、翻訳量の伸びや文書改訂頻度に依存しすぎるため、根拠を置けない。ここでは書かない。

同様に、誤訳が原因で発生した品質事故のコストも計上していない。発生確率を置く根拠がないためである。この種の数字を含む試算を見かけたら、その前提がどこから来ているかを確認した方がよい。

90日で回す導入手順

大掛かりな計画を立てるより、90日で1周させて実測値を得る方が早い。以下は最小構成の進め方である。

第1〜30日 現状の棚卸しとクラス分け

最初の1か月は、既存の翻訳作業を全部書き出すことに使う。誰が、何を、どのくらいの頻度で、どれだけの時間をかけて訳しているか。外注に出しているものと社内で処理しているものを分ける。

その上で、書き出した文書を4クラスに割り当てる。この作業は品質保証、製造、管理部門の3者で行う。1人でやると必ずクラスAとクラスCの境界で判断がぶれる。同時に、図中文字を含む文書の割合をここで数えておく。

第31〜60日 用語ベース構築とクラスB先行導入

2か月目は用語層の構築と、クラスBでの先行運用を並行させる。用語ベースは頻出語200語から始め、現場リーダーに実際の呼び名を確認しながら埋める。翻訳部門だけで決めない。

クラスBでは、議事録の自動作成、日報の自動翻訳、定型報告の自動生成といった用途を1つか2つ選んで実際に回す。ここでの目的は効果測定より、運用の型を作ることにある。失敗しても被害が小さいクラスで先に慣れておく。

第61〜90日 TTE測定とクラスA試行

3か月目に、クラスAでの下訳＋人承認を試行する。対象は改訂頻度の高い作業標準書を数点に絞る。ここでTTEを実測し、白紙から訳す場合と比較する。

同時に、クラスB運用の実績値も集計する。90日終了時点で手元に残るべきものは、クラス別のTTE実測値、用語ベース200語、クラスBの運用実績、そして次の投資判断に使える自社の数字である。この4つが揃えば、本格展開の意思決定ができる。

よくある質問

翻訳の自動化は企業でどこまで任せられる？

文書クラスによって答えが変わる。日報・議事録・社内連絡といった運用文書は全自動で問題ない（月数件の抜き取り確認だけは残す）。作業標準書や品質マニュアルなどの統制文書は下訳までで、承認は人が行う。顧客提出資料や契約書は人が訳し、AIは整合チェックに使う。HMI画面などの表示文言は翻訳工程から外し、設計として扱う。「どこまで任せられるか」を全社一律で決めようとすると、必ずどこかで無理が出る。

AI翻訳の費用はどれくらい？

API費用そのものは、文書量が本記事の試算程度であれば年間で1万THB台の規模に収まる。問題は付随する費用の方で、用語ベース構築、承認フローの整備、既存文書の整理といった初期費用が数十万THB規模になる。見積もりを取る際は、API単価ではなく初期整備の範囲を明確にした上で比較すべきである。なお、タイ語は同じ内容でもトークン数が増えやすいため、英語ベースの単価表をそのまま当てはめると想定を超える。

議事録の自動作成AIは日本語とタイ語が混ざる会議でも使える？

使えるが、条件がある。話者ごとにマイクが分かれている、あるいは録音環境が静かであることが前提になる。工場の会議室で騒音がある状態、複数人が同時に話す状態では、文字起こしの精度が落ちる。まず録音環境を整えるのが先である。また、社内固有語や設備名は事前に辞書登録しておかないと聞き取りを誤る。用語ベースを文字起こし側にも共有する構成が有効になる。

タイ語だけ訳の品質が安定しないのはなぜ？

複数の要因が重なっている。タイ語は単語間にスペースが無いため、まず文字列をどこで区切るかの判定が必要で、ここを誤ると訳が崩れる。加えて、学習データの量が英語や中国語に比べて少ない。さらに、社内固有語や製造用語をタイ文字で音写した語は辞書に存在しないため、区切りも訳語も外れやすい。用語ベースへの登録が効くのは、この3つ目の要因に直接作用するからである。

用語ベース（用語集）はどう作ればよい？

3つの原則がある。第一に、頻出語200語程度から始める。網羅を狙うと終わらない。第二に、訳語は辞書ではなく現場リーダーに聞いて決める（理由は本文の「読めるが従わない」問題の節に書いた）。第三に、承認された訳文から自動的に語を拾って追加する仕組みを作る。人手だけで維持しようとすると、半年で更新が止まる。

既存の翻訳会社との契約はどうすべき？

すべて内製化する必要はない。クラスCの対外文書は引き続き外注する判断が合理的な場合が多い。また、用語ベースの初期構築を翻訳会社に依頼するのも選択肢だが、その場合も現場の呼び名の確認は自社で行う。外注をゼロにすることが目的ではなく、クラスごとに最適な処理経路を選ぶことが目的である。

ISO 9001の監査で何を求められる？

箇条7.5「文書化した情報」の管理が対象になる。文書が利用可能で読みやすいこと、識別できること、意図しない変更から保護されていることが求められる。翻訳版についても、どの版が承認済みでどう配布されたかを説明できる状態にしておく必要がある。承認済み訳語の管理を文書化していれば、監査人への説明が明確になる。逆に、機械翻訳の出力がそのまま現場に配布されている状態は説明が難しい。

まとめ

翻訳の自動化が企業で止まるのは、エンジンの性能ではなく設計の問題である。文書を分けずに扱う限り、どの訳に誰が責任を持つのかが最後まで決まらない。

打ち手は3つに整理できる。第一に、文書を統制文書・運用文書・対外文書・現場UI文言の4クラスに分け、クラスごとに機械と人の分担を変える。第二に、用語層・生成層・承認層の3層で組み、承認済み訳が用語層に戻る循環を作る。第三に、KPIを精度の百分率ではなくTTE（Time to Edit）に置き換え、作業が本当に減ったのかを実測する。

タイ・ASEANの現場では、分かち書き、トークン効率、声調記号、図中文字、そして「読めるが従わない」問題が固有の障壁になる。これらは翻訳エンジンの選定では解決しない。文書クラスの設計と用語ベースの作り方で解決する。まずは90日、クラス分けとTTEの実測から始めるのが現実的である。

自社の文書がどのクラスにどれだけあるか、どこから自動化すべきかを整理する段階でも構いません。TOMAS TECHはタイの日系製造業向けにIT・OT・AIの導入を手がけており、翻訳自動化についても現状の棚卸しからご相談いただけます。検討段階での情報交換をご希望の場合はお問い合わせページからご連絡ください。

参考

• Machine Translation 2026 Assessment（Translated）
• Best LLM for Translation 2026（Alconost）
• What is the Best LLM for Translation（Lokalise）
• Compliance Best Practices for Translation: 2026 Guide（Adverbum）
• Assuring Quality Through Document Control（QualityWeb360）
• WangchanThaiInstruct: タイ語の指示追従データセットと評価（arXiv:2508.15239）
• タイ語LLM開発のための文化・基礎能力ベンチマーク（arXiv:2410.04795）
• 多言語LLMのトークナイザに関する実証研究（arXiv:2606.15044）
• タイ語翻訳サービス（翻訳会社川村インターナショナル）