「うちの業種でも多言語化はうまくいきますか」という質問をよく受けます。
数百サイトの多言語化に関わってきて分かったのは、業種によって変わるのは翻訳の難しさではなく、運用の設計だということです。文章を訳すこと自体の難易度は、業種が違ってもそれほど変わりません。差が出るのは、誰がいつ承認するのか、どのくらいの頻度で更新が発生するのか、誤訳したときに何が起きるのか、という部分です。
ここを読み違えたまま導入すると、翻訳の品質には問題がないのに運用が回らなくなります。この記事では、業種差を決める要因を整理したうえで、業種ごとの勘所を扱います。
多言語化そのものの進め方は失敗しないWebサイト多言語化の進め方、SEOの実装は多言語サイトのSEO実装ガイドで扱っているので、この記事は業種固有の話に絞ります。
業種差を決める4つの軸
業種ごとの違いは、次の4つでほぼ説明できます。自社がどこに位置するかを先に把握しておくと、必要な体制が見えます。
1. 更新頻度
年に数回しか更新しないコーポレートサイトと、毎日新しいページが増えるメディアやECでは、必要な仕組みがまったく違います。
更新が稀なら、翻訳の品質を人手で丁寧に確認する運用が成立します。更新が多いなら、確認を全ページに入れること自体が不可能なので、自動翻訳を前提にしたうえで重要ページだけ人が見る、という設計が要ります。
2. 用語の固さ
型番、仕様値、制度名、法令名、成分名のように訳し方が一意に決まる語が多いか、ブランドメッセージのように訳し方に幅がある語が多いか。
前者が多い業種では、用語集の整備が品質のほとんどを決めます。逆に後者が多い業種では、用語集より文体の統一が課題になります。
3. 誤訳したときの実害
誤訳が「読みにくい」で済む業種と、法的な問題や事故につながる業種があります。
IR情報の数値、医薬品の用法、金融商品の条件、機械の安全上の注意。これらは誤訳が実害に直結するため、確認の工程を省けません。ここを軽く見積もると、公開後に慌てることになります。
4. 承認者が誰か
見落とされがちですが、運用が止まる原因の多くはここです。
マーケティング部門だけで完結する業種もあれば、法務・IR室・現地法人・監督官庁への確認が必要な業種もあります。承認者が多いほど、翻訳を出してから公開までの時間が伸びます。翻訳の速度を上げても、承認の速度が上がらなければ全体は速くなりません。
この4軸で見ると、業種ごとの必要な体制がかなり具体的に決まります。以下、業種別に見ていきます。
インバウンド観光・宿泊
対象言語を欲張らない
観光分野でまず起きるのが、対応言語を増やしすぎることです。「アジア圏を広く」と考えて10言語を一度に立ち上げ、更新が追いつかなくなる例をよく見ます。
訪日客の構成を見れば、繁体字中国語、簡体字中国語、韓国語、英語で大半をカバーできます。まずこの4つを確実に運用し、実際の流入を見てから広げるほうが確実です。言語の選び方はウェブサイトを多言語化するならどの言語が必須？で詳しく扱っています。
予約導線まで翻訳されているか
観光サイトで最も多い失敗が、紹介ページは多言語化したのに予約フォームや外部予約システムが日本語のままという状態です。
読んで興味を持った訪日客が、予約の直前で日本語の画面に突き当たって離脱します。多言語化の効果を測っても数字が出ないので、「効果がなかった」と結論づけられてしまいます。
予約エンジンが外部サービスの場合、そのサービス側の多言語対応状況を先に確認してください。iframe で埋め込まれている場合、翻訳スクリプトは基本的に中身に触れません。別ドメインのコンテンツを外部から書き換えることはブラウザの仕組み上できないためです。
季節と告知の即時性
観光は繁忙期・閑散期で情報が大きく変わり、天候や交通の影響で急な告知が出ます。「本日は強風のため運休」のような情報が日本語だけで出ていると、現地に来ている訪日客が困ります。
更新頻度が高く、かつ即時性が要る。ここが観光分野の運用の難所です。緊急告知だけは自動翻訳で即時に出し、通常ページは確認を挟むという二段構えが現実的です。
BtoB製造業
型番と仕様表が壁になる
製造業のサイトで最も手間がかかるのが、製品ページの仕様表です。
型番は訳してはいけません。単位は現地の慣習に合わせる必要があるかもしれません。材質名や規格名には正式な英語名があります。そして仕様表はHTMLの表として組まれているため、翻訳でセルの中身が伸びるとレイアウトが崩れます。
ここは用語集の整備がほぼすべてを決めます。型番のパターンを翻訳対象から除外し、規格名・材質名を対訳で固定する。この準備をせずに自動翻訳をかけると、型番が英単語に訳されるといった事故が起きます。
PDFカタログをどうするか
製造業では、詳細情報がPDFカタログに入っていることが多くあります。PDFはWebページの翻訳スクリプトの対象外です。
現実的な選択肢は3つあります。主要製品のPDFだけ人手で多言語版を作る。PDFの内容をHTMLページとして作り直す。あるいは当面は日本語PDFのままとし、製品ページ側で仕様を網羅する。
検索流入を考えるとHTML化が最も効きますが、工数は大きくなります。製品数と引き合いの規模で判断してください。なお、PDFに対しても他言語版の存在を検索エンジンへ伝えることはできます。HTTPヘッダーで指定する方法をhreflangタグ完全ガイドで扱っています。
現地法人がいる場合の承認
海外現地法人がある製造業では、現地法人が翻訳内容を確認したがることが多くあります。これ自体は品質面で望ましいのですが、確認の依頼と回収が滞ると公開が止まります。
最初に「どのページを現地確認の対象にするか」を決めておくことをおすすめします。全ページを対象にすると回りません。製品ページと会社情報は現地確認、ニュースリリースは自動翻訳のまま公開、といった線引きが要ります。
IR・企業情報
適時開示の即時性と正確性の両立
IRは、更新頻度こそ高くないものの、即時性と正確性の両方が同時に要求されるという点で特殊です。
決算短信や適時開示は、開示のタイミングが決まっています。日本語版と英語版の公開に時間差があると、情報の非対称が生じます。一方で数値や条件の誤訳は許されません。
現実的な運用は、定型部分と非定型部分を分けることです。決算短信の様式部分、財務諸表の科目名、注記の定型文は用語集で固定できます。一方、社長メッセージや今後の見通しといった文章部分は、表現の裁量が大きく確認が要ります。
数値と単位は翻訳の対象外にする
IRで最も避けたい事故が、数値の変化です。百万円と千円の単位表記、和暦と西暦、決算期の表記。これらは翻訳エンジンが「親切に」変換してしまうことがあります。
数値部分を翻訳対象から除外する設定を入れておくことを強く推奨します。訳文が多少硬くなっても、数値が変わらないことのほうが重要です。
免責事項と将来見通し
将来見通しに関する記述には、各国の規制に応じた免責文言が必要になる場合があります。日本語の免責文をそのまま訳すのではなく、英語版として適切な文言を法務と用意しておくべき箇所です。
ここは翻訳の問題ではなく法務の問題なので、多言語化プロジェクトの初期に法務部門を巻き込んでおいてください。
採用
制度説明は正確に、カルチャーは自然に
採用サイトは、性質の異なる文章が同居しています。
福利厚生、給与体系、勤務地、選考フローといった制度説明は、正確性が最優先です。一方、社員インタビューやカルチャー紹介は、読み物として自然でなければ応募につながりません。
同じサイト内で求められる翻訳の性質が違うため、一律の設定では品質が揃いません。ページの性質に応じて処理を変える必要があります。当社が単一のAIモデルに固定していないのもこの理由です。詳しくは翻訳エージェントの設計で解説しています。
応募フォームと選考連絡
観光の予約導線と同じ構図です。採用サイトを多言語化しても、応募フォームが日本語のままでは応募が発生しません。
さらに見落とされるのが、応募後の連絡です。書類選考の結果や面接日程の案内が日本語だけで届くと、そこで候補者が離脱します。サイトの多言語化だけでなく、応募後のやりとりまで含めて設計してください。
在留資格に触れる情報
外国籍の候補者にとって、在留資格の扱いは応募判断を左右する重要な情報です。ビザ支援の有無、必要な資格、入社時期の制約などを明記しておくと、ミスマッチが減ります。
これは翻訳の話ではなく、原文に何を書くかの話です。多言語化を機に、日本語版の内容自体を見直す価値がある領域です。
自治体・公共
やさしい日本語という選択肢
自治体サイトで見落とされがちなのが、やさしい日本語です。
在住外国人の中には、母語版よりもやさしい日本語のほうが読みやすい層がいます。多言語対応というと外国語への翻訳を考えがちですが、日本語のまま平易にするという選択肢も検討する価値があります。
制度名と固有名詞の一貫性
自治体サイトには、制度名、窓口名、施設名、条例名といった固有名詞が大量に出てきます。同じ制度が別々の訳語になっていると、住民が窓口で照会できません。
ここも用語集の整備が効きます。特に、既に公式に訳語が決まっている制度名（国が定めた制度の英語名など）は、それに合わせる必要があります。
災害・緊急情報の扱い
公共性の観点から、災害情報や緊急のお知らせは最優先で多言語化されるべき情報です。同時に、最も即時性が求められる情報でもあります。
確認を挟んでいる余裕がない場面があるため、緊急情報だけは自動翻訳を即時公開する運用を、平時のうちに合意しておくことをおすすめします。
越境EC
ECについては、商品説明の物量、レビューの扱い、決済画面、送料と関税の表示といった固有の論点が多いため、多言語化は難しい？ECにおける多言語化まとめに独立してまとめています。
1点だけこの記事の文脈で補足すると、ECは4軸のうち更新頻度が突出して高い業種です。商品の入れ替えが日常的に発生するため、人手の確認を前提にした運用は最初から成立しません。自動翻訳を前提に、売れ筋商品だけ人が見るという設計から始めるのが現実的です。
業種をまたいで共通すること
ここまで業種別に見てきましたが、実際に多くのサイトを見てきて、業種を問わず共通する落とし穴が3つあります。
入口だけ多言語化して、出口が日本語のまま。予約フォーム、応募フォーム、問い合わせフォーム、決済画面。どの業種でも、コンバージョンの直前で日本語に戻る構成をよく見ます。多言語化の効果測定をする前に、まず導線の最後まで通しで確認してください。
画像内のテキストが残る。バナー、図解、キャンペーン告知。日本語の画像は翻訳スクリプトの対象外です。重要な情報が画像に入っていないか、多言語化の前に棚卸ししておく価値があります。
承認の設計を後回しにする。技術的な導入は短時間で終わります。運用が止まるのは、ほぼ例外なく「誰が確認するか決めていない」ことが原因です。導入の前に、ページの種類ごとに確認要否と担当を決めておいてください。
まとめ
業種によって変わるのは、翻訳の難易度ではなく運用の設計です。更新頻度、用語の固さ、誤訳の実害、承認者の数。この4軸で自社の位置を把握すれば、必要な体制はかなり具体的に決まります。
観光なら予約導線と即時性、製造業なら用語集とPDF、IRなら数値の保護と法務連携、採用なら応募後の体験、自治体ならやさしい日本語と固有名詞の一貫性。それぞれ勘所は違いますが、入口だけでなく出口まで通すという点はすべてに共通します。
当社では出版、金融、ガス、ホテル、公的機関、メーカーなど幅広い業種のサイトを多言語化しています。実際の事例は導入事例でご覧いただけます。自社の業種でどこが難所になるかを知りたい場合は、実サイトを見ながらお話しするのが早いので、お気軽にご相談ください。
