多言語サイトの品質について相談を受けるとき、実際に出てくる不満はほとんどが同じです。「訳が間違っている」ではなく、「ページによって言い方が違う」です。
製品名がAページでは英語のまま、Bページでは訳されている。同じ機能が「ダッシュボード」と「管理画面」に分かれている。ある記事は丁寧な文体で、別の記事はくだけている。1ページずつ見れば、どれも誤訳ではありません。しかしサイト全体で見ると、統一感がなく、読み手は同じものだと気づけません。
これは翻訳エンジンの精度の問題ではありません。何を固定するかを決めていないという、運用設計の問題です。この記事では、訳のブレを止めるために何を決め、誰が承認し、どう維持するかを整理します。
多言語化そのものの進め方は失敗しないWebサイト多言語化の進め方、検索エンジンへの実装は多言語サイトのSEO実装ガイドで扱っているので、この記事は品質の管理に絞ります。
なぜ訳がブレるのか
原因は3つに分けられます。それぞれ対処が違うので、まず切り分けてください。
同じ語に複数の訳が成立する
「ソリューション」「解決策」「サービス」。どれも Solution の訳として成立します。文脈だけ見れば、どの訳も間違っていません。
翻訳エンジンは1回ごとに最適な訳を選ぶため、別のページで別の訳を選ぶことがあります。人が訳しても、担当者が違えば同じことが起きます。訳が複数成立する語について、どれを使うか決めていないことが原因です。
訳してはいけない語が訳される
製品名、サービス名、ブランド名、型番。これらは訳してはいけません。しかし翻訳エンジンから見れば普通の名詞なので、意味のある単語に置き換えられます。
自社の製品名が別の単語になって表示されていても、日本語版しか見ていなければ気づけません。
文体の基準がない
同じサイト内でも、プレスリリースと技術ブログでは文体が違うのが自然です。しかしその違いを言語化していないと、翻訳のたびに文体が揺れます。とくに複数の担当者や複数のエンジンが関わると顕著になります。
用語集で固定すること
用語集は、訳語を1対1で固定する仕組みです。まず訳してはいけない語と訳が複数成立する語の2つを登録してください。
最初に登録すべきもの
完璧を目指すと着手できません。次の優先順で30〜50語も登録すれば、体感できるほど揃います。
- 製品名・サービス名・ブランド名 — 訳さない指定にする
- 自社の造語や独自機能名 — 公式な英語名を決めて固定する
- 業界用語で訳が割れるもの — 社内で使っている呼称に合わせる
- 組織名・役職名・部署名 — 英語表記を決めて固定する
- 数値の単位や規格名 — 正式名称に合わせる
逆に、一般的な語をすべて登録する必要はありません。翻訳エンジンが正しく訳せる語まで登録すると、維持の手間だけが増えます。
6種類の辞書を使い分ける
単純な語の置き換えだけでは足りない場面があります。私たちのサービスでは、扱う対象に応じて6種類を用意しています。用語集を設計するときの考え方として参考になるはずです。
- 通常辞書 — 単語やフレーズを一律に置き換える。最も使う
- 条件付き辞書 — URLや言語ごとに適用を切り替える。製品ページだけ別の訳語にしたい場合など
- HTML辞書 — HTML要素の単位で置き換える。タグ構造を保ったまま差し替えたい場合
- 正規表現辞書 — パターンで一致させる。型番のように規則性のある文字列に効く
- 画像辞書 — 言語ごとに画像を切り替える。日本語が焼き込まれたバナーの差し替え
- リンク置換 — URLを書き換える。言語別のフォームや外部サービスへ振り分ける
最後の2つは見落とされがちです。画像の中の文字は翻訳の対象になりませんし、日本語版のフォームへリンクしたままでは、読めても申し込めません。
用語集は誰が作るか
翻訳担当者ではなく、その言葉を使っている部門が決めるべきです。製品名は製品部門、組織名は人事、法的な表記は法務。翻訳側で推測して決めると、後から覆ります。
実務的には、翻訳側が「訳が割れている語」の一覧を出し、各部門が訳語を確定する形が回ります。ゼロから網羅しようとするより、実際に揺れた語から埋めるほうが早く形になります。
スタイルガイドで決めること
用語集が「語」を固定するのに対して、スタイルガイドは文章の書き方を決めます。用語集ほど厳密でなくてよく、A4で1〜2枚から始められます。
最低限決めること
- 文体 — です・ます調か、だ・である調か。英語なら一人称を we とするか会社名とするか
- 読み手の想定 — 専門家向けか、一般向けか。専門用語に説明を添えるかどうか
- 数値と日付の表記 — 桁区切り、日付の順序、単位系
- 記号の扱い — 全角と半角、括弧の種類、感嘆符を使うか
- 敬称と呼称 — 顧客をどう呼ぶか、自社をどう名乗るか
英語版だけでなく、対象言語ごとに必要です。とくに敬語のある言語（韓国語、タイ語など）では、丁寧さのレベルを決めておかないと訳文が安定しません。
ページの種類で変えてよい
サイト全体で1つの文体に統一する必要はありません。むしろ無理に統一すると不自然になります。
IR情報や利用規約は硬く、ブログや採用ページは柔らかく。種類ごとに基準を決めて、その中で揃えるのが現実的です。種類をまたいだ揺れは問題になりませんが、同じ種類の中での揺れは目立ちます。
誰が承認するかを決める
用語集とスタイルガイドを作っても、承認の設計がなければ運用は止まります。ここが実務で最も詰まる部分です。
ページの種類ごとに線を引く
全ページに同じ確認をかけると回りません。次のように分けてください。
- 確認なしで公開 — ニュース、ブログ、更新頻度の高いページ
- 担当者が目視 — 製品・サービス説明、料金ページ
- 法務や現地法人の確認 — 契約条件、法的表示、IR情報
この線引きを最初に決めておけば、更新のたびに「これは誰に聞くのか」で止まることがなくなります。
現地確認の対象を絞る
海外現地法人がある場合、現地に確認してもらうのは品質面で望ましいことです。しかし全ページを対象にすると、依頼と回収だけで日が過ぎます。
製品ページと会社情報は現地確認、ニュースは自動翻訳のまま公開。このように対象を明示的に絞ることで、確認が形骸化するのを防げます。
業種によって、どこが重いかは変わります。IRや医療のように誤訳が実害になる領域と、そうでない領域では設計が違います。詳しくは業種別・Webサイト多言語化の勘所で扱っています。
修正を次に活かす
ガバナンスで最も差が出るのは、指摘を受けたあとの処理です。
その場で直して終わりにしない
現地の担当者から「この訳はおかしい」と指摘を受けたとき、該当ページを直して完了とすると、同じ問題が別のページで再発します。
直すと同時に、その訳語を用語集へ登録してください。次回以降の翻訳に自動で反映されるため、指摘の件数は時間とともに減ります。逆に、個別修正だけを続けていると件数は減りません。
指摘の件数が減っているかどうかが、ガバナンスが機能しているかの指標になります。
翻訳メモリと用語集の役割を分ける
混同されやすいので整理します。
- 用語集 — 語の訳し方を固定する。人が意図して登録する
- 翻訳メモリ — 過去に確定した訳文を蓄積し、再利用する。運用の中で自動的に貯まる
翻訳メモリの価値は、コスト削減よりも一貫性にあります。人手で修正した訳文がメモリへ戻る設計になっているかを、導入時に確認してください。戻らない仕組みだと、同じ修正を毎回することになります。
誰も見ていない状態を作らない
公開後、自社の多言語版を定期的に開いている人がいない、という状態がよくあります。日本語版は担当者が毎日見ているので崩れにすぐ気づきますが、英語版や中国語版は公開時に確認したきりです。
月に一度でよいので、主要な多言語ページを実際に開く担当を決めてください。CMSの改修やデザイン変更で表示が崩れても、発見までの時間が大きく縮まります。
着手の順序
最初から完全な体制を作ろうとすると、いつまでも始まりません。次の順で進めるのが現実的です。
- 訳してはいけない語（製品名・ブランド名）を用語集に登録する
- 訳が割れている語を洗い出し、各部門に訳語を確定してもらう
- スタイルガイドをA4で1〜2枚作る。文体と数値表記だけでよい
- ページの種類ごとに、確認の要否と担当を決める
- 指摘を受けたら用語集へ戻す運用を回す
1と2だけでも、体感できるほど訳は揃います。3以降は運用しながら育ててください。
まとめ
多言語サイトの品質問題の多くは、誤訳ではなく訳のブレです。そしてブレは、翻訳エンジンの性能を上げても解決しません。何を固定するかを決めていないことが原因だからです。
用語集で語を固定し、スタイルガイドで文章の基準を決め、ページの種類ごとに承認の線を引く。そして受けた指摘を用語集へ戻す。この4つが回っていれば、翻訳の手段が何であっても品質は安定します。
逆に、この設計がないまま高性能なエンジンを導入しても、ページごとに違う訳が出てくる状態は変わりません。ガバナンスは翻訳の前提であって、翻訳の結果ではありません。
どこを機械に任せ、どこに人手をかけるかの配分はプロフェッショナルな翻訳者の利用：メリットとデメリット、公開後の運用体制はメンテナンスと更新：多言語ウェブサイトの持続的な運用で扱っています。
