多言語対応は4つの層に分かれる
「多言語対応の可否」を1問で聞くと、必ず「対応しています」という回答が返ってきます。層を分けて聞くと、回答が変わります。
第1層しか見ていない要件定義書は、稼働直前に第2層から第4層の追加開発が発覚します。RFPには4層それぞれについて対応可否を書き分けさせてください。
見落とされる12項目
層の話をより具体的にすると、次の12項目になります。
| # | 項目 | 何が起きるか |
|---|---|---|
| 1 | 品目名・工程名の多言語 | マスタに言語別カラムがないと、現場端末に日本語の品目名が出る |
| 2 | 不良コードの名称 | コード値は共通、名称は現地語という設計が必要。コード自体を現地語にすると全社集計が崩れる |
| 3 | 自由記述のメモ | 現地語で書かれ、本社で読めない。選択式に構造化するか、翻訳運用を決める |
| 4 | 日付・時刻の書式 | 2026/08/25 と 25/08/2026 と 08/25/2026 が混在し、帳票の読み違いが起きる |
| 5 | タイムゾーンと日跨ぎ | 実績の時刻をUTCで持つかローカルで持つか。夜勤シフトの日跨ぎ定義も拠点で異なる |
| 6 | 数値の小数点・桁区切り | 「1.234」が千二百三十四なのか一・二三四なのか。CSV連携で事故になる |
| 7 | 文字コードと文字集合 | 中国語の簡体字・繁体字、ベトナム語の声調記号、絵文字の混入。DBの照合順序まで確認が必要 |
| 8 | ソート順 | 品目一覧が拠点ごとに違う順で並ぶ。日本語の読み仮名ソートは特に注意 |
| 9 | 単位系 | インチ・ポンド系との併記。換算をどの層で行うかを決めていないと二重換算が起きる |
| 10 | ラベル・バーコードの印字 | 文字数が言語で変わり、レイアウトが崩れる。フォントの埋め込み可否も確認が必要 |
| 11 | 帳票の紙サイズと余白 | A4とレターサイズ。監査提出用の帳票では致命的になる |
| 12 | 監査証跡の言語 | 誰が何をいつ変更したかの記録を、現地の査察官に読める形で提示できるか |
このうち、あとから直すのが最も難しいのは2番と12番です。不良コードの名称を現地語で登録してしまうと、全社の品質集計が拠点ごとにバラバラになり、統一には過去データの再マッピングが必要になります。監査証跡の言語は、記録の生成時点で決まるため、後から遡って変換できません。
翻訳と、ロケールと、業務の3つは別問題
多言語対応の議論が混乱するのは、性質の異なる3つが同じ言葉で語られるからです。
翻訳（Translation）は、文字列を別言語に置き換えることです。これは辞書の問題であり、量の問題です。
ロケール（Locale）は、日付書式、数値書式、通貨、ソート順、単位といった地域慣習の問題です。翻訳とは独立しており、英語UIを使っていてもロケールの問題は残ります。シンガポール拠点が英語UIを選んでも、日付書式と通貨は現地仕様が必要です。
業務の違いは、そもそも言語の問題ではありません。承認段階が国によって違う、記録保存期間が違う、シフト定義が違う。これらを「多言語対応」の枠で処理しようとすると、必ず設計が破綻します。業務差はリージョン層の設計として切り出してください。この切り分けはマルチサイトMESの設計で扱っています。
用語集は運用フェーズの資産になる
多言語対応で最も見落とされるのは、稼働後の運用です。品目は増え、工程は変わり、不良コードは追加されます。そのたびに翻訳が必要になります。
運用設計で決めておくべきことは4つです。
- 翻訳の責任者は誰か。本社のマスタ管理者か、拠点か。拠点に任せると訳語がばらつき、本社に集めると登録が遅れます。コア定義（不良コード、KPI名称）は本社、拠点固有マスタは拠点という分担が現実的です
- 未翻訳のときにどう表示するか。空欄にするのか、原語のまま出すのか、コード値を出すのか。空欄が最も危険です
- 用語集をどこで管理するか。MESの中に持つのか、外部の用語管理台帳に持つのか。ERPやPLMと共通の用語を使う項目は、MESの外で一元管理したほうが整合が取れます
- 訳語の変更をいつ反映するか。過去の実績記録に遡って適用するのか、以後のみか。監査証跡については遡及変更してはいけません
この設計判断が効いてくる規模感
Rockwell が2026年7月28日に公開した調査は17か国1,560名を対象としており、回答企業の58%は年商10億ドル超です。この規模の企業では、MESが単一言語で完結することはまずありません。Tulip Interfaces は2026年1月13日のシリーズD発表時点で、45か国1,000拠点、60,000名の現場作業者への展開を公表しています。
つまり多言語対応は、グローバル企業にとって「追加要件」ではなく前提条件です。にもかかわらず、RFPでは1行しか書かれないことが多い項目でもあります。
機械翻訳で自由記述を処理してもよいですか？
参考情報としては有用ですが、品質記録や是正処置の正式記録として機械翻訳の出力を使うのは避けてください。規制産業では、記録の正確性に責任を持つ主体が不明確になります。現実的な設計は、自由記述そのものを減らすことです。頻出する記述内容を選択式のコードに構造化すれば、翻訳は選択肢の名称だけで済み、全社集計も可能になります。自由記述は補足欄として残し、原語のまま保存します。
現場端末のフォントは何を確認すればよいですか？
3点あります。第一に、対象言語の文字が端末のOSに標準搭載されているか。中国語繁体字やベトナム語では、標準フォントで表示できない文字が残ることがあります。第二に、帳票・ラベル出力側でフォントを埋め込めるか。PDFやラベルプリンタでは、埋め込めないと文字化けします。第三に、文字サイズを大きくしたときのレイアウト崩れです。現場端末は視認距離が長いため、フォントサイズを上げる要求が必ず出ます。
導入後に対応言語を追加できますか？
第1層（UI固定文字列）は追加できる製品がほとんどです。問題は第2層のマスタ名称で、言語別カラムが最初から設計されていれば追加は容易ですが、単一名称カラムで作られていると、マスタ構造の変更と全データの移行が必要になります。将来使う可能性のある言語は、実際に使わなくても設計時に器だけ用意しておくのが安全です。器を用意するコストは小さく、後から作るコストは大きい項目です。
