多言語対応サイト
Multilingual Websiteたげんごたいおう・さいと
多言語対応サイトとは、言語ごとに固有のURLを持つページを用意し、その版どうしの対応関係を検索エンジンと訪問者の双方に正しく伝える設計のことです。翻訳ボタンを1つ置くことではありません。狙いは、日本語を読まない相手が自分の言葉で情報にたどり着き、そのまま問い合わせまで進める状態をつくることにあります。
翻訳を外注する前に、決めておくことが3つある
多言語化の相談は、たいてい「英語版をつくりたい」という形で始まります。しかし翻訳を発注した後に手戻りが起きる原因は、文章の質ではなく翻訳より前に決めるべき3つが決まっていないことにあります。1つ目がURL構造、2つ目が版どうしの関係の伝え方、3つ目が「どの言語の誰に、何を届けるか」の範囲です。この3つが決まっていれば、翻訳は作業として進みます。決まっていないと、公開後に構造ごと作り直すことになります。
URL構造は3つの選択肢に整理できます。国別ドメイン（ccTLD）は example.fr のように国ごとにドメインを分ける方式で、その国向けであることが最も明確に伝わる一方、取得と運用の手間が増えます。サブドメインは en.example.com のようにドメインの前に言語を置く方式。サブディレクトリは example.com/en/ のように既存ドメインの下に置く方式で、これまで積み上げてきた評価を1つのドメインに集められるため、専任担当がいない組織では最も扱いやすい選択になります。Googleは検索セントラルの多地域・多言語サイトに関するドキュメントでこれらの構成を挙げており、どれか1つが唯一の正解というより、それぞれ利点と手間が異なる選択肢として説明しています。重要なのは途中で方式を変えないことです。移行にはリダイレクトの整理が伴い、規模が大きくなるほど負担が増します。
2つ目の「版どうしの関係の伝え方」が hreflang です。これは各ページの HTML に <link rel="alternate" hreflang="en" href="…"> の形で記述し（HTTPヘッダーやサイトマップでも指定できます）、「このページの英語版はここにある」と検索エンジンに伝える仕組みです。要点は相互に指し合う必要があること。日本語版が英語版を指しているだけでは足りず、英語版からも日本語版を指し、さらに自分自身も含めて全言語版を列挙します。片方向のままだと指定は無視され、意図しない言語の版が検索結果に出ることになります。加えて、どの言語にも当てはまらない訪問者に見せる版を hreflang="x-default" で示せます。言語コードはISO 639-1、地域を足す場合はISO 3166-1 Alpha 2（例：en-au）を使います。
もう1つ、実装で事故が起きやすいのが自動リダイレクトです。訪問者のIPアドレスやブラウザの言語設定から国・言語を推測し、強制的に別の版へ飛ばす作り方は、Googleが避けるよう案内している挙動です。理由は単純で、訪問者も検索エンジンのクローラーも、他の言語版にたどり着けなくなるからです。日本語を読める海外在住者が英語版に飛ばされて戻れない、といった状況が起きます。自動で切り替えるのではなく、どのページからでも他の言語版へ移れるリンクを置くのが安全です。そして自動翻訳の扱いにも注意が必要です。Googleは、自動翻訳したテキストを人の確認を経ずにそのまま公開することを、品質の低い自動生成コンテンツの例として挙げています。機械翻訳を使うこと自体が問題なのではなく、人が確認せずに公開することが問題という整理です。
母語で読めるかどうかは、情報の問題ではなく「自分が客として想定されているか」の合図です。
顧客心理の視点で見ると、言語が合わないときに起きているのは「読めない」よりも先に「ここは自分向けではない」という判断です。海外の担当者が製品ページにたどり着いても、価格が円だけで表示され、問い合わせ先が国内の電話番号だけで、フォームの住所欄が都道府県の選択肢しかなければ、翻訳の質とは無関係に離脱します。逆に、完璧な文章でなくても、対応可能な国、通貨や単位の併記、返答までの目安時間、メールでの窓口が示されていれば、話は前に進みます。国内在住の外国籍のお客様に向けた多言語化でも同じで、必要なのは全ページの翻訳ではなく不安が集中する数ページ——料金、対応範囲、アクセス、問い合わせ方法——を確実に読める状態にすることです。ここでの判断基準は「全部訳したか」ではなく「その言語の顧客が最初に確かめたいことが読めるか」に置きます。
仕組み化の視点では、言語をページの複製ではなくデータの属性として持つのが要点です。CMSの多言語機能を使い、1つの記事に対して言語ごとの版をひも付ける形にすれば、hreflang の相互指定と言語切替リンクは自動で出力できます。ページを丸ごとコピーして別ディレクトリに置く運用は、初回は早く進みますが、料金改定のたびに更新漏れが発生し、やがて「英語版だけ去年の価格」という状態になります。公開フローも型にします。①原文を確定する、②機械翻訳で下訳を作る、③その言語が分かる人が確認する、④公開する、の4段階を固定し、③を飛ばせない手順として残す。加えて、翻訳しない範囲を最初に決めておくことも仕組みの一部です。全ページ翻訳を目標にすると、更新が止まった瞬間に全体が古くなります。対象を主要な数ページに絞り、そこだけは必ず最新に保つほうが、結果として信頼されます。
AI活用の視点では、下訳と確認の両方で使えます。翻訳そのものは生成AIで十分な精度が出るようになりましたが、成果を分けるのは用語の統一です。自社の製品名・サービス名・専門用語の対訳表をつくり、翻訳のたびに参照させれば、ページごとに訳語が揺れる問題は防げます。公開前の確認にも使えます。原文と訳文を並べて渡し、「数値・固有名詞・条件が食い違っている箇所」だけを指摘させると、人のレビュー担当は限られた時間を判断に使えます。問い合わせ対応でも、受信した外国語のメールを要約し、返信の下書きを作るところまでは自動化できます。ただし送信前の確認は人が行うという線は引いてください。取引条件や納期の誤訳は、後から取り返しがつきません。順序としては、まずURL構造を決め、次に主要ページを人の確認付きで訳し、そのうえで対象範囲を広げるのが失敗の少ない道筋です。
図解：URL構造の3方式と、hreflangの相互指定
上段は言語版をどこに置くかの選択肢です。下段は、置いた版どうしを検索エンジンにどう結び付けるかを示しています。片方向の指定では働きません。
事例で見る：国内・海外
Wikipediaの言語版 ── 「翻訳」ではなく「言語ごとの独立した内容」
多言語サイトの構造として広く知られているのが、Wikipediaの言語版です。日本語版は ja.wikipedia.org、英語版は en.wikipedia.org というように言語ごとにサブドメインを分ける方式を採り、各ページには他の言語版へのリンクが並びます。ここで注目したいのは技術構成よりも編集の考え方です。各言語版は同一記事の逐語訳ではなく、それぞれの言語圏の書き手によって独立に書かれ、内容も分量も異なります。同じ主題でも、その言語の読者にとって必要な説明が違うからです。これは事業サイトにもそのまま当てはまります。日本語のページで「創業以来の地域とのつながり」を丁寧に語っていても、初めて自社を知る海外の担当者が最初に確かめたいのは、対応できる範囲・条件・連絡手段です。原文の構成を保ったまま訳すと、その言語の読者にとって重要な情報が下のほうに残ります。全文を機械的に置き換えるのではなく、その言語の読者が最初に知りたい順に組み替える。多言語対応を「翻訳作業」ではなく「編集の作業」として捉えるほうが、結果は良くなります。
地方の食品メーカーのような形 ── 全ページではなく「5ページだけ」英語にした
たとえば、調味料を製造する地方の中小メーカーが、海外の輸入業者からの引き合いを増やしたい場合を考えます。よくある進め方は、サイト全体の英語版をまとめて発注することですが、これは公開後に止まります。ページ数が多いほど更新が追いつかず、日本語側だけが新しくなっていくからです。現実的なのは対象を絞ることです。英語にするのは、製品一覧・原材料と規格・輸出可否と最小ロット・会社概要・問い合わせフォームの5ページ。この範囲なら、価格改定や規格変更があっても同時に直せます。構造は example.com/en/ のサブディレクトリに置き、日本語版と英語版から互いに hreflang を指定し、全ページの上部に言語切替リンクを常設する。フォームには、住所の自由記述欄、国名の選択、返答までの目安日数を入れておきます。ここまで整えて初めて、「読める」から「問い合わせられる」に変わります。効果の確認は、英語ページの表示回数と問い合わせ件数、そして問い合わせ元の国を月単位で見れば足ります。これは特定企業の実績ではなく、更新体制が限られる組織で無理なく続く形として示しています。
現場での使い方：5ステップ
- 対象の言語と対象のページを先に決める全ページ翻訳を目標にすると更新が止まる。料金・対応範囲・問い合わせなど、その言語の顧客が最初に確かめる数ページに絞る。
- URL構造を1つ選び、途中で変えない専任担当がいない組織はサブディレクトリ（example.com/en/）が扱いやすい。方式の変更は移行コストが大きい。
- hreflangを相互に指定する各版が自分自身を含めた全言語版を列挙する。片方向では無視される。該当しない訪問者向けにはx-defaultを用意する。
- 自動リダイレクトではなく切替リンクを置くIPやブラウザ設定での強制切り替えは、訪問者もクローラーも他の版に届かなくする。選択はユーザーに残す。
- 機械翻訳の後に人の確認を必ず挟む下訳はAIで十分。ただし数値・固有名詞・取引条件は人が確認する。用語の対訳表をつくり、訳語の揺れを構造的に防ぐ。
関連用語
まとめ：訳す量ではなく、届く状態で判断する
多言語対応サイトは、言語ごとに固有のURLを持たせ、版どうしの関係を検索エンジンと訪問者に正しく伝える設計です。翻訳を発注する前に、URL構造・hreflangの相互指定・対象範囲の3つを決めておけば、公開後の作り直しは避けられます。訪問者にとって重要なのは文章の流暢さより、通貨や単位、対応できる国、返答までの時間といった自分が客として想定されているかどうかの手がかりです。全ページを訳して更新が止まるより、主要な数ページを常に最新に保つほうが信頼されます。下訳と用語の統一、原文との食い違いの検出はAIに任せ、数値と取引条件の最終確認は人が持つ。言語が変わっても必要な情報に同じ速さでたどり着けるなら、顧客は自分の判断で次に進めます。
