会社情報
採用情報
お問い合わせ
Article

多言語サイトへのリニューアル：グローバル対応のステップと注意点

高田晃太郎
多言語サイトへのリニューアル：グローバル対応のステップと注意点

CSA Researchの“Can’t Read, Won’t Buy”では、消費者の 約65% が母語のコンテンツを好み、 約40% は母語でない場合に購入しないと回答しています（2020）¹。グローバル展開で売上を取りに行くなら、言語を後回しにできないことは数字が物語ります。一般に、英語だけのサイトを適切に多言語化すると、対象ロケールの自然検索流入やCVRが改善する事例が多く報告されています。問題は、翻訳を追加するだけでは持続的に伸びないことです。URLとhreflangの整合、ロケール別のパフォーマンス最適化、法規対応、運用可能な翻訳プロセスまで設計して初めて、再現性のあるグローバル成長が実現します²。

戦略と要件定義：どの市場から始め、何を“多言語化”するか

最初に決めるべきは、対象ロケールの優先順位と、翻訳の範囲です。単に言語を増やすのではなく、市場規模、既存流入、物流・決済の実装容易性、法規の厳しさを天秤にかけて、投資対効果が高い順に着手するのが堅実です。ロケールコードはBCP 47（言語・地域・文字体系を表す標準）に準拠し、言語だけでなく地域とスクリプトまで明示します。たとえば中国語ならzh-Hans-CNとzh-Hant-TWの分離が運用上の混乱を防ぎます³。価格や在庫は翻訳対象外と見なされがちですが、実務的には通貨表示、税の内外表示、配送可否の文言、返品ポリシーまでセットでローカライズしないと、カート離脱を招きます。

法規対応は設計初期から織り込むべきです。EU圏ならGDPR、ブラジルはLGPD、シンガポールはPDPA、カリフォルニアはCPRA/CCPAと、求められる同意管理やデータ主体の権利が異なります。クッキーバナーは対象ロケールの言語で表示し、同意の粒度、拒否の容易性、記録保存を実装に落とし込む必要があります。実務では、クッキーバナーをローカライズし、同意管理（CMP：Consent Management Platform）の設定を各地域の要件に合わせるだけでも、広告配信の安定化や計測欠損の低減につながることが広く観測されています。計測が安定すれば最適化が機能し、最適化が機能すれば収益は積み上がるという、当たり前の循環を取り戻せます。

翻訳スコープとKPI：品質を定義し、測り続ける

多言語リニューアルでは、何をどこまで翻訳すべきかを明確にし、品質の定義とKPIを先に決めると走りやすくなります。ブランドページや決済導線は人手のプロ翻訳とレビュー、ブログやヘルプは機械翻訳の後編集、ユーザー生成コンテンツは表示言語を明示しつつ機械翻訳のオンデマンド提供といった線引きが現実解です。KPIは翻訳カバレッジ、ロケール別の自然検索セッション、CVR、返品率、NPSなど、事業KPIと紐づくものにします。翻訳メモリと用語集を整備し、継続開発に耐えうるワークフローを**TMS（Translation Management System）**とリポジトリに接続することが、運用の肝です。

hreflangとカノニカル：検索エンジンに“対応表”を正しく伝える

多言語SEOの初期不良の大半は、hreflangの相互参照漏れやカノニカルとの矛盾です。hreflangはページの言語・地域バリエーションを検索エンジンに伝える仕組み、カノニカルは重複候補の中でそのページの正規URLを示す指定です。すべてのバリエーションが互いを指し合い、かつ各ページの正規URLを自己参照カノニカルで示すという基本を崩さないことが重要です²。ホームの自動言語振り分けを採用する場合でも、x-defaultを用意して、検索エンジンに既定の受け皿を提示します⁴。Googleのガイドラインに従い、サイトマップ形式のhreflangを併用すると、大規模サイトでの保守性が上がります²。

<!-- HTML head 内の例 -->
<link rel="canonical" href="https://example.com/ja/" />
<link rel="alternate" href="https://example.com/ja/" hreflang="ja-JP" />
<link rel="alternate" href="https://example.com/en/" hreflang="en" />
<link rel="alternate" href="https://example.com/zh-hans/" hreflang="zh-Hans" />
<link rel="alternate" href="https://example.com/" hreflang="x-default" />

情報設計とSEO：URL戦略、検出、リダイレクトの実務

URL戦略は、ドメイン分割、サブドメイン、サブディレクトリの三択が基本軸です。ブランドを国ごとに独立させるならccTLD（国別コードトップレベルドメイン）が最も強力ですが、ドメインの分散は運用・評価の分散でもあります。サブドメインはインフラ分離がしやすい一方で、メインドメインの評価を素直に引き継ぎにくい場面があります。多くのB2B/B2Cでは、サブディレクトリが運用と評価のバランスを取りやすいため、まずここから検討することを勧めます²。

言語検出は初回のみ控えめに行い、ユーザーの選択を最優先にするのが信頼を損ねないコツです。Accept-Language（ブラウザが送る希望言語のHTTPヘッダ）と粗いジオ判定を参考に、初回訪問で提案を行い、ユーザーが選んだ言語をクッキーやローカルストレージに保存して以降は強制しない、という振る舞いが推奨されます。検索エンジン向けには自動リダイレクトを抑制し、Vary: Accept-Language（キャッシュ分岐の宣言）を適切に送出しつつ、静的に解決可能なURLとhreflangで対応表を提供します²。

// next.config.js の例（Next.js i18n）
/** @type {import('next').NextConfig} */
const nextConfig = {
  i18n: {
    locales: ['ja', 'en', 'zh-Hans'],
    defaultLocale: 'ja',
    localeDetection: false // 自動検出は初回のみアプリ側で制御
  },
  experimental: {
    optimizeCss: true
  }
};
module.exports = nextConfig;

サーバでの初回リダイレクトは、クローラを巻き込まないようにUA判定やクエリフラグで明示的に回避し、クッキーの存在で二重リダイレクトを防止します。Nginxならマッピングと条件分岐で、簡潔に表現できます。

# Nginx: Accept-Language から緩やかに推定（例）
map $http_accept_language $pref_lang {
  ~*zh zh-hans;
  ~*en en;
  default ja;
}
server {
  listen 443 ssl;
  set $has_lang_cookie 0;
  if ($http_cookie ~* "site_lang=") { set $has_lang_cookie 1; }
  if ($request_uri = "/" ) {
    if ($has_lang_cookie = 0) {
      return 302 /$pref_lang/; # 初回のみ提案的に振り分け
    }
  }
  add_header Vary "Accept-Language" always;
}

検索対応の堅牢性を上げるには、サイトマップでのhreflang宣言が有効です。大規模構成では、ページのheadに全バリエーションを出すよりも、生成ジョブで確実に整合性を担保できます²。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/ja/product/123</loc>
    <xhtml:link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/product/123"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/product/123"/>
    <xhtml:link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh-hans/product/123"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/product/123"/>
  </url>
</urlset>

翻訳運用：ICUメッセージ、TMS、開発フローの接続

多言語化の保守性を左右するのは、コンポーネント設計とメッセージフォーマットです。ICU MessageFormatで数や性の一致、単複や序数を正しく扱い、UI分解の粒度を粗すぎず細かすぎずに保つと、翻訳コストと不具合が一気に減ります⁵。キーは意味的に安定したものを採用し、テキストを組み立てるのではなく、文として翻訳するのが鉄則です。TMS（Phrase、Lokalise、Transifex等）とGitHub Actionsを繋ぎ、プルリクごとに抽出・配布・検収・反映までを自動化すると、リリースと翻訳の遅延が解消されます。

// ICU MessageFormat の例（JSON）
{
  "cart.items": "{count, plural, one {# 点の商品} other {# 点の商品}}",
  "hello.name": "{gender, select, male {こんにちは、{name}さん} female {こんにちは、{name}さん} other {こんにちは、{name}さま}}",
  "eta": "配達予定：{date, date, ::yyyy/MM/dd}"
}

// React（react-intl）での使用例
import {IntlProvider, useIntl, FormattedMessage} from 'react-intl';

function CartSummary({count}) {
  const intl = useIntl();
  return (
    <div>
      <FormattedMessage id="cart.items" values={{count}} />
      <div>{intl.formatMessage({id: 'eta'}, {date: new Date()})}</div>
    </div>
  );
}

export default function App({locale, messages}) {
  return (
    <IntlProvider locale={locale} messages={messages}>
      <CartSummary count={3} />
    </IntlProvider>
  );
}

辞書管理では、用語集とスタイルガイドが要です。特にSaaSや金融のように専門用語が多いドメインでは、禁止訳、推奨訳、原語維持のルールを決めると、レビューループの往復回数が劇的に減ります。テキストをUIに当て込んだ後のレイアウト崩れも、ヒンディー語やドイツ語の長文、タイ語の単語分割、アラビア語の双方向テキストなど、言語固有の事情を前提にデザインすれば、事後の手戻りを最小化できます。

データとフォーマット：Intl APIで通貨・日付・文の単位を正しく扱う

フロントエンドでは、ECやSaaS課金で通貨と日付の表記が信用に直結します。Intl.NumberFormatとIntl.DateTimeFormat、そしてIntl.Segmenterを活用すると、ブラウザ標準で多くの課題が解けます。ゼロからフォーマッタを実装するより、ロケールに任せることで、細部の規約を外すリスクを避けられます⁶⁷。

// 通貨・日付フォーマット（JavaScript）
const price = new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1999.99);
const date = new Intl.DateTimeFormat('ja-JP', { dateStyle: 'long', timeZone: 'Asia/Tokyo' }).format(new Date());
console.log(price, date); // 1.999,99 €  2025年9月1日

// 文の単位（改行や省略の判断に）
const seg = new Intl.Segmenter('th', { granularity: 'word' });
console.log([...seg.segment("ยินดีต้อนรับสู่เว็บไซต์ของเรา")].map(s => s.segment));

配信とパフォーマンス：ロケール別に“速くて読める”を担保する

言語が増えるほど、配信のボトルネックは増えます。フォント、画像、CDN、キャッシュ、レンダリング戦略をロケール単位で最適に組み直すと、Core Web Vitals（LCP/最大視覚コンテンツの表示、CLS/視覚の安定、INP/応答性）の改善が横断的に効いてきます。CJK向けにはフォントのサブセット化が最重要で、Woff2で必要なグリフだけを配布すれば、初期描画の安定性が増します。中国本土向けは一部の外部フォントCDNがブロックされる懸念があるため、セルフホストが安全策です。画像内テキストは翻訳不能になるので、可能な限りテキストをHTMLに逃がし、テキストを含む必要がある場合はロケール別アセットを用意します。

キャッシュ設計では、言語別パスにする方が単純です。ドメインやクエリで言語を切り替える場合は、CDNのキャッシュキーにロケールを含め、Vary: Accept-Languageをむやみに拡散させないようにします。SSR/SSGの選択は、コンテンツの鮮度要件とトラフィック分布で決めます。価格や在庫をクライアントで差し込む設計にする場合、LCPとINPに影響が出やすいため、折衷案として初期HTMLに最重要パーツだけ注入し、後から補完するストリーミングを活用すると良い結果が出ます。

/* CSS: RTL 言語に備えた論理プロパティ活用 */
:root { direction: rtl; }
.card { padding-inline: 16px; margin-inline-start: 8px; }
.button { border-start-start-radius: 8px; border-end-end-radius: 8px; }

// Edge/Server: 言語に応じたキャッシュキー（Node/Express 例）
app.use((req, res, next) => {
  const lang = (req.cookies.site_lang || req.acceptsLanguages('ja', 'en', 'zh-Hans') || 'ja');
  res.set('Cache-Control', 'public, max-age=600');
  res.set('Vary', 'Accept-Language');
  res.locals.lang = lang;
  next();
});

計測もロケール別に管理します。Search Consoleのプロパティをディレクトリ単位で追加する、あるいはデータポータルでクエリやランディングページをロケールで切ると、インデックスの偏りやhreflangの齟齬が可視化されます。パフォーマンスはロケール別にWebPageTestやLighthouse CIを走らせ、TTFBやLCP、CLS、INPを国別CDNルートと合わせて監視すると、国際配信のボトルネックが早期に見つかります。フォント最適化や配信経路の見直しだけで、LCPが数百ミリ秒規模で改善し、製品詳細ページなどのCVRに好影響を及ぼすケースも珍しくありません。こうした小さな積み重ねが、言語ごとの収益差を詰めていきます。

法規・アクセシビリティ：ロケールの“常識”に合わせる

ローカリゼーションは、単に文字が読める状態にするだけでは不十分です。日付の並び、単位、敬称、氏名の順、住所の書式など、社会的な常識に合わせることが信頼の前提です。フォームは姓名の順やフリガナ、郵便番号、都道府県など日本固有の項目に合わせたコンポーネントへ差し替えます。アクセシビリティでは、言語切替時にlang属性（文言の言語）とdir属性（テキスト方向）を正しく設定し、スクリーンリーダーが読み上げ言語を切り替えられるようにします³。言語混在のテキストにはインラインでlangを付与し、適切な発音を促すと、読み上げの品質が目に見えて向上します。

<!-- 言語・方向の切り替え例 -->
<html lang="ar" dir="rtl">
  <body>
    <p><span lang="en">NOWH</span> の最新号へようこそ。</p>
  </body>
</html>

実装を前提にした移行計画：止めない、壊さない、迷わせない

リニューアルは、既存の評価とトラフィックを落とさないことが勝ち筋です。まずステージングでURLの対応表、hreflang、カノニカル、サイトマップの整合を自動テストに落とし込み、スクレイピングで既存ページとのパリティを比較します。言語別の404やメタの抜け、テンプレートの差異由来の構造化データ崩れは、早期に洗い出せます。ローンチは全世界一斉ではなく、対象ロケールの一部セクションから徐々に公開し、Search Consoleでの検出状況とログのエラーを確認しながら、範囲を広げるのが安全です。

計測タグは同意管理（CMP）との連携を確認し、ロケール間で計測の欠損や二重計測がないかをログで突き合わせます。CDNとアプリのキャッシュの境界を明文化し、キャッシュ無効化の権限と手順をプロダクト、SRE、マーケが共有できる運用設計にしておくと、問題発生時の復旧が迅速になります。翻訳の緊急修正は、TMSからホットフィックス可能にしておくと、アプリのリリースサイクルに翻訳の修正を縛られずに済みます。

// URL パリティのチェック例（Node）
import fetch from 'node-fetch';
const pairs = [
  ['https://old.example.com/ja/product/123', 'https://example.com/ja/product/123'],
  ['https://old.example.com/en/product/123', 'https://example.com/en/product/123']
];
for (const [oldUrl, newUrl] of pairs) {
  const [a, b] = await Promise.all([fetch(oldUrl), fetch(newUrl)]);
  console.log(oldUrl, a.status, newUrl, b.status);
}

最後に、多言語のサポート体制を準備します。お問い合わせやチャットサポートは、一次対応の自動翻訳＋二次対応の人手というハイブリッドが現実解です。サポートログから頻出の質問を抽出し、ヘルプセンターを優先ロケールで整備すると、問い合わせ削減と顧客満足の両方が改善します。サポートとプロダクト、マーケが言語横断のインサイトを共有し続ける限り、コンテンツと機能は市場の言葉で磨かれ、検索にも強くなります。

サンプル：ユーザー選択を尊重する言語スイッチ

UXで最も重要なのは、ユーザーが自分で選べることです。初回提案後は、選択を記憶し、どのページからでも確実に切り替えられるUIを提供します。下の例は、選択をクッキーに保存し、URLにロケールを反映した上で、次回以降の振る舞いを安定させるシンプルな実装です。

// 言語スイッチ（Next.js）
'use client';
import Cookies from 'js-cookie';
import {useRouter, usePathname} from 'next/navigation';

export function LangSwitcher() {
  const router = useRouter();
  const pathname = usePathname();
  const switchTo = (locale) => {
    Cookies.set('site_lang', locale, { expires: 365 });
    const parts = pathname.split('/').filter(Boolean);
    parts[0] = locale; // /ja/... を置換
    router.push('/' + parts.join('/'));
  };
  return (
    <div>
      <button onClick={() => switchTo('ja')}>日本語</button>
      <button onClick={() => switchTo('en')}>English</button>
      <button onClick={() => switchTo('zh-Hans')}>简体中文</button>
    </div>
  );
}

まとめ：グローバルは“翻訳プロジェクト”ではなく“事業設計”

多言語サイトへのリニューアルは、翻訳の発注では終わりません。URLとhreflangの整合、ユーザー選好を尊重する検出と切替、法規・計測・配信の足回り、運用可能な翻訳フローが揃って初めて、事業としての再現性が生まれます。今のチームが明日からできることとして、現行サイトのロケール戦略を一枚に可視化し、重要導線の文をICU化し、優先市場のサイトマップhreflangを発行してSearch Consoleに登録する、という三つの着手を提案します。どれも一週間以内に始められ、完了すれば計測と改善の土台が整います。あなたのプロダクトが、より多くの人の「読める」「買える」「使える」へと届くように、次のスプリントでどの一手から進めますか。小さく正しく始めた一歩が、最短でグローバルな成果へ繋がります。

参考文献

  1. CSA Research. Consumers Prefer their Own Language – Can’t Read, Won’t Buy (2020). https://csa-research.com/Blogs-Events/CSA-in-the-Media/Press-Releases/Consumers-Prefer-their-Own-Language
  2. Google Search Central. Manage multi-regional and multilingual sites. https://developers.google.com/search/docs/advanced/crawling/managing-multi-regional-sites
  3. W3C Internationalization. Internationalization Best Practices: Specifying Language in XHTML & HTML Content (Using BCP 47). https://www.w3.org/TR/2007/NOTE-i18n-html-tech-lang-20070412/
  4. Google Search Central Blog. On the hreflang x-default value (2023). https://developers.google.com/search/blog/2023/05/x-default
  5. Unicode ICU. MessageFormat User Guide. https://unicode-org.github.io/icu/userguide/format_parse/messages/
  6. MDN Web Docs. Intl.NumberFormat. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat
  7. MDN Web Docs. Intl.DateTimeFormat. https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat