internationalization

国際化

ユーザー、検索エンジン、コンテンツの保守を担うチームにとって機能する方法で、言語と地域を追加します。特定の技術スタックには依存しません。

---

使用する場面

• 英語以外（またはデフォルト以外）の言語を初めて追加する
• すでに国際化されているサイトにロケールを追加する
• 言語ごとの URL 構造を選ぶ
• hreflang タグを実装する
• 翻訳ワークフローを設計する
• 通貨、日付、時刻、数値の形式に対応する
• RTL 言語向けのレイアウトを設計または修正する
• 効果が出ていない国際化の展開を監査する

使用しない場面

• 単一言語のサイト（他のスキルを使用してください）
• 言語に基づかないドメイン戦略（domain-strategy を使用してください）
• ロケールに依存しないコンテンツ戦略（content-strategy を使用してください）
• マーケティングコピーの制作（content-and-copy を使用してください）

---

必要な入力

• 対象となるロケール（言語 + 地域。例：en-US、de-DE、fr-CA）
• ロケールごとのビジネス上の理由（優先度、対象者数）
• 既存のサイトアーキテクチャ
• 翻訳リソース（社内、代理店、AI 支援、コミュニティ）
• コンテンツの量と更新頻度

---

フレームワーク：5 つのレイヤー

国際化はあらゆる要素に関わります。それぞれに独自の判断事項がある、5 つのレイヤーで構成されます。

レイヤー 1：URL 構造

ロケールを URL にどう反映するか。

パターン	例	適用する場面
ccTLD	example.de、example.fr	特定の国に重点を置く場合、個別の法人がある場合、別々のドメインを維持する意思がある場合
サブドメイン	de.example.com、fr.example.com	論理的に分離する場合、別々にホスティングする意思がある場合、大規模サイトで一般的
サブフォルダー	example.com/de/、example.com/fr/	SEO の評価を統一でき、管理が最も簡単で、ほとんどのサイトでデフォルトに適している
URL パラメーター	example.com?lang=de	避けてください。SEO シグナルが弱くなります

ほとんどのサイトでは、サブフォルダーがデフォルトです。サブドメインや ccTLD を選ぶのは、特定の理由（法務、インフラ、ブランド）がある場合に限ります。

選択したパターンの中で、次の点を決めます。

• 言語のみ（/de/）にするか、言語と地域（/de-de/、/de-at/、/de-ch/）にするか
• デフォルトロケールを最上位（example.com）に置くか、フォルダー（example.com/en/）に置くか

デフォルトロケールを最上位に置くパターンは一般的ですが、hreflang が複雑になります（最上位の URL に x-default が必要となり、デフォルト言語の canonical も設定する必要があります）。

レイヤー 2：コンテンツ構造

ロケール間でコンテンツをどう整理するか。

パターン A：ミラー型。 すべてのロケールにすべてのページを用意します。翻訳がそのままページになります。コンテンツを管理できるマーケティングサイトに適しています。

パターン B：一部対応型。 すべてのロケールにあるコンテンツと、特定のロケールにのみあるコンテンツが混在します。製品ページ（提供されている製品のみ）、ブログ（一部の記事のみ翻訳）、規制上の違いなどで一般的です。

パターン C：ローカル型。 各ロケールが、他のロケールとはおおむね独立したコンテンツを持ちます。メディアサイトやコミュニティサイトで一般的です。

ほとんどのマーケティングサイトは A です。大規模サイトのほとんどは、必要に迫られて最終的に B になります。C は、地域ごとの編集方針が強いサイト向けです。

このパターンは次の点に影響します。

• コンテンツモデルの設計（各コンテンツに親子関係や翻訳関係を持たせるか）
• 翻訳の管理（ワークフローはこの構造を前提とします）
• チームの連携方法

レイヤー 3：hreflang と canonical

翻訳版と個別のページを検索エンジンに伝えます。

hreflang は、各バージョンの言語と、任意で地域を指定します。

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/page">
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page">
<link rel="alternate" hreflang="de-DE" href="https://example.com/de-de/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/en-us/page">

ルール：

• 各ページに、翻訳版すべて（そのページ自身を含む）を記載します
• ページ同士で相互に参照する必要があります（ページ A がページ B をドイツ語版として示す場合、ページ B はページ A を英語版として示します）
• x-default は、地域が指定されていないユーザー向けのフォールバックです
• 各ページには、そのページ自身を指す canonical を設定します（デフォルト言語のページを指すものではありません）

hreflang は HTML の head、HTTP ヘッダー、XML サイトマップのいずれにも設定できます。大規模サイトにはサイトマップが最適です。小規模サイトなら HTML の head で問題ありません。

canonical：

• ページごとに自分自身を参照させます
• ドイツ語ページの canonical を英語ページに向けないでください（検索エンジンがドイツ語ページをインデックスしなくなります）

レイヤー 4：翻訳ワークフロー

コンテンツの翻訳、最新状態の維持、品質管理の方法です。

翻訳の担い手：

• 社内翻訳者（フルタイムのスタッフ）
• 翻訳会社（単語単位の有料、プロフェッショナル）
• コミュニティの貢献者（ボランティア、品質にばらつきあり、無料）
• AI 支援と人間によるレビューの併用（低コスト、高速、品質向上中）
• AI のみ（一部のコンテンツには許容可能ですが、ブランド上重要なコンテンツには不向きです）

ワークフローの段階：

1. ソースコンテンツをソース言語で作成します
2. TMS（翻訳管理システム）またはスプレッドシートを通じて翻訳を依頼します
3. 翻訳メモリを使って翻訳します（再利用されるフレーズの再翻訳を避けます）
4. 別の翻訳者または現地スタッフがレビューします
5. 翻訳にとどまらないローカライズを行います（通貨、単位、例、文化的な参照など）
6. 対象ロケールで公開します
7. ソースコンテンツが変更されたときに更新を反映します

コンテンツ全体が約10K単語を超えると、TMS の導入効果が出てきます。それより少なければ、スプレッドシートと一貫した命名規則で十分です。

更新の反映が最も難しい部分です。 ソースコンテンツは変更されます。翻訳は古くなります。プロセスがないと、各ロケールの内容がソースから次第にずれてしまいます。

レイヤー 5：ロケールに応じた UX

翻訳だけでなく、ユーザー体験も適応させる必要があります。

通貨： 該当する場合は、現地通貨で表示します。ヨーロッパのロケールには EUR、日本語には JPY などを使います。フランス語ロケールのページで、フランスのユーザーに USD を表示しないでください。

数値： 千の位の区切りと小数点の表記は異なります。en-US の 1,000.50 は、de-DE では 1.000,50 です。

日付と時刻： 表記形式と順序は異なります。en-US では MM/DD/YYYY、en-GB では DD/MM/YYYY です。YYYY-MM-DD（ISO）は普遍的ですが、多くの人にはなじみがありません。

氏名と住所： フィールドの順序や必須項目は異なります。国に応じた住所フォームを用意してください。

電話番号： 国際的には E.164 形式を使用し、表示形式はロケールに合わせます。

単位： メートル法とヤード・ポンド法があります。世界の大半ではメートル法が使われ、米国ではヤード・ポンド法が使われます。両方に対応する製品もあります。

右から左に記述する（RTL）言語： アラビア語、ヘブライ語、ペルシャ語、ウルドゥー語などです。レイアウトを反転します。ナビゲーションは右側に移動し、テキストは右揃えになり、方向を示すアイコンも反転する場合があります。CSS の論理プロパティ（margin-left ではなく margin-inline-start）を使うと、対応しやすくなります。

言語切り替え： 目立つように配置しますが、邪魔にならないようにします。ロケール名はその言語で表示します（"German" ではなく "Deutsch"）。選択を保持します。ブラウザーの言語に基づいて自動リダイレクトする場合は、元に戻る方法も用意してください。

文化的配慮： 色、画像、例、翻訳できない参照表現に配慮します。製品画像で手のジェスチャーを避けてください。ローカライズされていない場合は、特定の国に固有の参照表現を避けてください。

---

ワークフロー

ステップ 1：対象ロケールを決める

追加できるからという理由だけで言語を追加しないでください。各ロケールには継続的な保守コストがかかります。

• オーディエンス調査：訪問者や見込み顧客はどこにいますか？
• ビジネス上の優先度：どの市場を成長目標としますか？
• コンテンツの準備状況：維持するためのリソースはありますか？
• 法務：規制によりローカライズが必要ですか（GDPR、アクセシビリティ関連法など）？

ステップ 2：URL 構造を選ぶ

ほとんどの場合はサブフォルダーが適しています。選択とその理由を文書化してください。

ステップ 3：コンテンツ構造を選ぶ

ミラー、サブセット、またはローカルのいずれかを選びます。持続可能な範囲を正直に見極めてください。

ステップ 4：hreflang と canonical を設定する

2 つ目のロケールを公開する前に、追加ページが 1 つだけの場合でも実装してください。

ステップ 5：翻訳ワークフローを設定する

TMS またはスプレッドシートのシステムを選びます。ワークフローを文書化します。翻訳者とレビュアーを指名します。

ステップ 6：翻訳にとどまらないローカライズを行う

各ロケールについて、以下を確認します。

• 通貨、数値、日付、単位
• 必要に応じたロケール固有の画像
• 住所フォーム
• カスタマーサービスの営業時間と連絡先

ステップ 7：言語切り替えを実装する

• ヘッダーまたはフッターの目立つ位置に配置します
• 現在のロケールを明確に表示します
• 利用可能なすべてのロケールを、それぞれの言語で一覧表示します
• 選択を保持します（Cookie またはローカルストレージ）
• ブラウザーの言語に基づいて自動リダイレクトせず、代わりに候補を提示します

ステップ 8：テスト

• 各ロケールで正しく表示される
• hreflang リンクが有効である（チェッカーを使用）
• 各ページの canonical がそのページ自身を参照している
• 通貨と日付が正しい
• RTL レイアウトが正しい（RTL ロケールの場合）
• 言語切り替え機能が動作し、設定が保持される
• 検索エンジンの観点：各ロケールがクロール可能かつインデックス可能である

ステップ 9：公開とモニタリング

ロケールごとに確認します。

• インデックス率
• 対象地域からのトラフィック
• ロケール内のエンゲージメント指標
• 翻訳の鮮度（翻訳更新がないまま、ソースコンテンツが変更されたのはいつか）

ステップ 10：維持

• 翻訳の更新頻度（ソースの変更時期と、それに続く翻訳の更新時期）
• ロケールのパフォーマンスを四半期ごとに確認
• 維持が見込めないロケールを終了する（更新されないロケールを質の低い状態で維持するより適切です）

---

よくある失敗パターン

ブラウザーの言語に基づく自動リダイレクト。 ユーザーはドイツにいて、英語を希望しています。サイトがドイツ語に強制的に切り替えます。ユーザーを困らせます。リダイレクトではなく、候補として提示しましょう。

デフォルト言語への単一の canonical。 検索エンジンが翻訳をインデックスできません。ページごとに自分自身を canonical として指定してください。

相互の hreflang がない。 ドイツ語ページでは英語ページを翻訳先として指定しているのに、英語ページではドイツ語ページを指定していません。検索エンジンはこの関係を確認できないものとして扱います。

地域が重要なのに、地域指定のない hreflang を使う。 スペイン語版が1つだけなら、hreflang="es" で問題ありません。es-ES（スペイン）と es-MX（メキシコ）がある場合は、地域指定のある両方を使用してください。

自動翻訳したコンテンツを完成版として扱う。 機械翻訳は許容できる出発点です。ユーザー向けのコンテンツには、すべて人間によるレビューが必要です。

コピーに通貨を埋め込む。 本文中の「月額 $99」は、ヨーロッパのユーザーには適しません。状況に応じて切り替わる通貨表記をテンプレート化してください。

日付形式のハードコード。 コード内の「2024年1月5日」は、状況に応じて変わりません。ロケールに対応した日付フォーマットライブラリを使用してください。

フィールドラベルをソース言語のままにする。 本文は翻訳されているのに、フォームのラベルは翻訳されていません。一貫性がありません。ローカライズの一環として UI 文字列も翻訳してください。

エラーメッセージを翻訳しない。 ユーザーがフォームを送信すると、フランス語のページなのに英語でエラーが表示されます。ユーザーを困らせます。UI の状態を翻訳してください。

メールを翻訳しない。 サイトはフランス語なのに、トランザクションメールは英語です。メールもサイトに合わせて翻訳してください。

CMS のロケールを更新し忘れる。 編集者が1つのロケールの更新を忘れ、内容にずれが生じます。ずれを把握できる TMS またはワークフローを使用してください。

操作の途中で機能しないロケール切り替え。 ユーザーがドイツ語のチェックアウト画面でフランス語に切り替えると、フランス語のホームページに移動します。新しいロケールの同じページに移動できるようにしてください。

RTL レイアウトが実際には反転しない。 マージンとパディングが LTR 用にハードコードされています。CSS の論理プロパティを使用してください。

言語を終了する際にリダイレクトしない。 フランス語の提供を終了すると、古いフランス語 URL が 404 になります。別の対応言語にある最も近いページへリダイレクトしてください。

---

出力形式

国際化計画には以下を含めます。

• ロケール一覧： 優先度と対象ユーザーの根拠を含む
• URL 構造： 選択したパターンとその理由
• コンテンツ構造： ミラー、一部対応、またはローカル向け
• hreflang 計画： 実装方法
• 翻訳ワークフロー： ソース、段階、ツール
• ローカライズチェックリスト： 翻訳以外の項目（通貨、日付など）
• 言語切り替えの設計： 配置、動作、設定の保持
• テスト計画： ロケールごとに検証する項目
• 保守計画： 更新頻度、ずれの検出

---

参考ファイル

• references/locale-checklist.md：カテゴリー（URL、コンテンツ、UX、形式、法務）ごとに整理した、翻訳以外にロケールごとに適応が必要なすべての項目のチェックリスト。