tva
← コラム

一つのWebサイトを数十言語で:ECの実践的な国際化

ECサイトの対応言語を数言語からさらに増やすと、単一のロケール向けに作られたコードベースに埋め込まれた前提が次々に表面化します。文字列の抽出、ロケールに応じた書式設定、右から左に読むRTL言語向けのレイアウト調整といった基盤整備は、原理はよく知られていても、実作業は非常に煩雑です。それほど理解されていないのは、真に地域に合った体験になるか、文字だけは正しい明らかな機械翻訳のサイトになるかを左右する、一連の判断です。

数十のロケールを対象とするサイトでこの作業を進めてきて、最も明確になったのは、技術実装が問題の小さな部分にすぎないということです。翻訳パイプライン、URL設計、hreflang設定は、技術的に解決できます。多くのローカライズ案件で不足するのは、日本、ドイツ、ブラジルで、それぞれ何が商品ページの信頼につながるかを理解し、文化に合わせる作業です。完全には自動化できず、知識の習得に費用がかかるためです。


URL構造:後から最も変更しにくい判断

多言語サイトのURL構造は最初に決める必要があり、最も変更しにくい判断です。主な方式は、ロケール別ドメイン(example.de、example.fr)、ロケール別サブドメイン(de.example.com、fr.example.com)、ロケール別サブディレクトリ(example.com/de/、example.com/fr/)の3つです。SEO評価の蓄積、デプロイの複雑さ、運用負荷への影響は、それぞれ異なります。

ドメインを分けると利用者に最も分かりやすく、市場ごとに完全に独立したホスティングが可能です。ただし、ドメインの評価は分散します。example.comに何年も蓄積した被リンクの効果は、example.deに直接引き継がれるわけではありません。自然検索の流入をすでに確立したサイトでは、大きな損失です。国・地域別TLDが信頼につながる市場を狙う新規サイトなら、判断は異なります。

SEO評価を集約したいサイトでは、ロケール別サブディレクトリが最もよく推奨されます。ドメイン単位で市場を分ける明確な理由がないECサイトには、通常これが適切です。その代わり、すべてのロケールがインフラを共有するため、あるロケールへのデプロイが全体に影響する可能性があります。多くのチームにとって、これは許容できる運用上の制約です。

最も重要なのは、SEOと運用への影響を十分に理解したうえで、早い段階に意識的に決めることです。被リンクと検索インデックスが蓄積してからURL構造を変更する費用は高く、弱点が明らかになっても当初の方式を使い続けることになりがちです。


翻訳パイプライン

数十言語の翻訳パイプラインには、混同されがちな3つの作業があります。まず機械翻訳で初稿を作ること、人が誤りを直して語調を調整すること、原文の変更に合わせて継続的に保守することです。それぞれ費用構造と到達できる品質の上限が異なります。

機械翻訳は、西欧の多くの言語で十分に使える出発点となるまで改善しました。日本語、中国語、複雑な敬語体系を持つ言語でも使えますが、制約はより大きくなります。品質にかかわらず、人の確認は必要です。機械翻訳が常に誤るからではなく、内容は正しくても語調が合わない文章を繰り返し生成するためです。機械翻訳した法的文書は、そのままでは機械翻訳らしく響き、ローカライズで築くはずの信頼を損ないます。

コンテンツ更新に合わせた翻訳の保守は、展開計画で日常的に過小評価される運用課題です。原文を一つの言語で更新すると、他のすべてのロケールに翻訳の更新待ちが生じます。どの翻訳が最新かを明示的に追跡しなければ、古い内容が気付かれないまま蓄積します。そして非英語圏の利用者が、昨年の価格や提供終了した機能を載せた商品ページを見て初めて発覚します。

翻訳管理システム、フラットファイル、データベースを使うコンテンツ管理基盤のどれを採用するかは、初回の翻訳量ではなく、この保守フローで決めるべきです。フラットファイルは立ち上げが速くても、更新待ちの翻訳を特定して優先順位を付ける仕組みがなければ、規模拡大に伴い負担になります。


hreflang:実装とよくある失敗

hreflangタグは、ページのどの言語・地域版をどの利用者に表示するかを検索エンジンに伝えます。文書上の実装は単純に見えます。各ページに、ロケールごとの<link rel="alternate">タグを正しい言語コード(ISO 639-1の言語コードに、必要に応じてISO 3166-1 alpha-2の地域コードを続けたもの。例:de、de-AT)とともに追加するだけです。しかし実際には多くの落とし穴があり、誤った実装は例外というより一般的になっています。

最も多い誤りは、hreflangの参照が揃っていないことです。各ロケールは、自分自身も含めたすべてのロケールをタグで参照する必要があります。8ロケールのうち7つしか記載しないページでは、欠けているページの組み合わせで相互参照が成立しなくなり、Googleは互いに参照し合っていないページ間のhreflangアノテーションを無視します。対応ロケールの単一リストからタグを自動生成すれば防げますが、ロケールの追加・削除に合わせてリストを正確に保守することが前提です。

次に多いのは、hreflangの参照先が一致しない誤りです。英語ページのタグが/de/product-nameを指すのに、ドイツ語ページの正規URLは/de/produktnameである、といった例です。現地語キーワードがSEO上重要な市場でスラッグを翻訳しながら、hreflangの参照を更新しないと起こります。大規模なサイトで確実に検出するには、自動監査でサイトをクロールし、各タグが実在する正規URLを指しているか検証する必要があります。

hreflangのx-defaultは、よく誤解される値です。「既定の言語」ではなく、「指定されたどのロケールにも該当しない利用者向け」を意味します。多くのサイトでは主要言語版を指すべきですが、ロケール選択ページや位置情報に基づくリダイレクトがあるサイトでは、別のページを指すのが正しい場合もあります。


RTL:レイアウトの反転だけでは不十分

アラビア語、ヘブライ語、ペルシャ語(ファルシ)、ウルドゥー語など、右から左に読む文字体系への対応は、多くの案件でCSSの問題として扱われます。ルート要素にdir="rtl"を追加し、Flexboxの方向と余白を反転させれば完了、という考え方です。実際には、RTL対応によって、方向が変わるまで見えなかったレイアウト上の前提が表面化します。

最も見落とされやすいのは、アイコンの向きです。ナビゲーションの矢印、進捗表示、左右を示すアイコンには意味があり、RTLでは反転が必要です。LTRで左を向く「戻る」の矢印は、RTLでは右を向くべきです。CSSのtransform: scaleX(-1)で機械的に反転できますが、UI内のすべての方向を示すアイコンを確認し、適切な箇所だけ反転させる必要があります。

数字、電話番号、郵便番号はRTLの文章内でも左から右に読み、反転させません。Unicodeの双方向アルゴリズムは数字とその区切り文字を弱い文字または中立文字として扱うため、配置は周囲の文章に左右されます。そのため、これらの値は<bdi>やdir="ltr"などで分離する必要があることがよくあります。型番を含む商品説明のように、一つのテキストブロックにLTRとRTLが混在する場合は、Unicodeの双方向制御を明示するか、HTMLのdir属性を慎重に使い、ブラウザーの双方向アルゴリズムによる表示の乱れを防ぐ必要があります。


翻訳を超えた文化的適応

ローカライズと翻訳は同じ作業ではありません。翻訳は言葉を変換します。ローカライズは意味を伝え直します。そのためには、特定の読者にとってメッセージが何を意味するかを左右する、文化的背景の理解が必要です。

商業上最も大きい違いは、信頼につながる要素です。商品ページの信頼を築く要素は市場で大きく異なります。ドイツの顧客は認証マークと技術仕様、日本の顧客はブランドの評判と梱包の品質、米国の顧客は他の購入者の評価と返品条件の分かりやすさを重視します。翻訳の質が同じでも、レイアウトと強調点が市場に合わなければ、ある市場で売れるページが別の市場では売れないことがあります。

決済方法も文化に関わる要素ですが、ローカライズではなく技術連携の問題として扱われがちです。ドイツでは銀行振込(Überweisung)とSEPA口座振替が依然重要です。日本ではコンビニ決済が広く使われています。こうした市場でクレジットカードとPayPalだけを提供するのは、翻訳上の失敗ではなく、顧客の実情に合わせられていないという実務上のローカライズの失敗です。

率直に言えば、多くの多言語ECサイトは、ローカライズではなく翻訳されたサイトです。文章は正しい言語でも、体験は市場に合っていません。現地の事業者と競争する企業にとって、翻訳とローカライズの差が、自然検索経由のコンバージョン率の差を生みます。


関連記事

関連記事