localization-strategy

ローカライズ戦略

ローカライズの意思決定から提供までのライフサイクルを、一貫して管理します。ローカライズを、すべてのソースページを翻訳したり、コンテンツの準備が整う前にロケール別のルートを作成したりする依頼として扱わないでください。

範囲

• このスキルでは、市場とロケールの選定、対象範囲、技術アーキテクチャ、展開、移行、リリース判定基準、測定を管理します。
• translation では、翻訳済みコピー、用語、スタイル、レビュー、ソース変更への更新を管理します。
• keyword-research では、対象市場の検索クエリ調査を管理します。ソースのキーワードリストを翻訳しないでください。
• page-metadata、canonical-tag、url-structure では、それぞれの専門的な実装詳細を管理します。ここでは、詳細なルールを重複させずに連携してください。
• プロジェクト固有の製品情報、ルート一覧、用語は、プロジェクトのコンテキストまたは実装リポジトリに保持してください。それらを普遍的なルールにしないでください。

現状の把握

ルートに contextus.md がある場合は読み込みます。本番サイト、ルートまたは CMS の一覧、ナビゲーションと内部リンク、サイトマップ、ソースリポジトリ、分析データ、検索データから、利用可能な範囲で証拠を集めます。サイトマップだけでは、ページ一覧として不十分です。

以下を確認します。

• 対象市場、言語、実際のロケールの違い
• 現在および提案中の公開 URL パターン
• デフォルトロケールと、URL に接頭辞を付けるかどうか
• ローカライズするページタイプ、ソース言語のみのページ、特定市場向けのページ
• コンテンツの責任者、用語集、レビュー対応能力、更新頻度
• 現在のルート、canonical、hreflang、サイトマップ、言語切り替え、フォールバックの動作
• リダイレクトや互換性対応が必要な、すでにインデックス登録されている URL

同じテンプレートを使うページが数千ある場合は、すべての URL を列挙するのではなく、ページタイプと代表例を一覧にします。

ロケールを公開するかどうかの判断

既存の需要、検索機会、コンバージョンや収益の可能性、競争の度合い、決済とサポートの準備状況、コンプライアンス、コンテンツを最新に保つチームの能力などの根拠に基づき、ロケールの優先順位を決めます。

以下の判断を分けて行います。

1. 言語サポート：インターフェースまたはコンテンツを特定の言語で利用できます。
2. ロケールサポート：綴り、形式、通貨、用語、または製品の動作が異なります。
3. 市場参入：特定の地域で、価格設定、決済、チャネル、実績、サポート、コンプライアンスの準備が整っています。

国によって違いがあるというだけで、国別のコピーを作成しないでください。新しいロケールを作成するには、ユーザーまたは市場に関する、維持する価値のある違いが必要です。

対応範囲のモデルを定義する

ロケールごとの状態を示すページタイプまたはルートファミリーのマトリクスを作成します。

状態	意味	公開時の動作
source-current	ソース言語のページが最新です	ソース URL を公開します
translation-draft	作業中ですが、承認されていません	プレビューまたは noindex のみとします
localized-ready	コンテンツ、用語、事実、メタデータがレビューに合格しました	ロケール URL をインデックス登録できます
outdated	ローカライズの承認後にソースが変更されました	リスクに応じてページを維持し、内部向けに警告し、レビュー待ちにします
not-applicable	製品またはコンテンツが市場に該当しません	代替ページを無理に作成しません

中核的な製品、価格設定、チェックアウト、法務、購入意欲の高いページには、リスクの低いサポートコンテンツやユーザー生成コンテンツより厳格なリリース判定基準を適用します。ロケールの URL を公開する際、その言語向けの外枠によって本文のソース言語が隠される状態にしないでください。

URL とルーティングのアーキテクチャを選択する

公開するローカライズ済みページには、安定したクロール可能な URL を使用します。サブディレクトリは運用上シンプルな場合が多いですが、ホスティング、所有権、規制、市場運営上の理由があれば、サブドメインや ccTLD も有効です。特定の構造があらゆる場合に優れているとは主張しないでください。

主な不変条件：

• インデックス登録可能な各ロケールページには、安定した公開 URL が 1 つあります。
• URL、レンダリングされる言語、<html lang>、ナビゲーション、メタデータ、構造化データは、同じロケールを示します。
• 言語切り替えには見つけやすいリンクを使用し、対応するページが存在する場合は現在のページのコンテキストを維持します。
• ユーザー設定は再訪問時の利便性を高める場合がありますが、公開ロケール URL の代わりにはなりません。
• 翻訳がない場合、ローカライズ済み URL で原文の言語のコンテンツをひそかに表示しません。
• canonical、hreflang、サイトマップ、内部リンク、リダイレクトは、公開 URL の形式に一貫して従います。

実際の違いに適した BCP 47 の言語またはロケール識別子を使用します。SEO のためだけに地域別のバリエーションを作らないでください。

コンテンツ制作を調整する

承認済みの各ロケールについて：

1. 原文のバージョンを確定し、ページの種類、対象読者、意図、主張、制約、担当者を記録します。
2. 原文のクエリを翻訳するのではなく、対象市場向けにキーワード調査を使用します。
3. 翻訳を使用して文章を作成し、用語集の判断、スタイルガイダンス、レビューの証跡を用意します。
4. 例、根拠、価格、支払い方法、日付、単位、画像、コンプライアンス要件は、その市場で確認できた場合にのみ適応します。
5. 機能の提供状況と法的な記述は、実際のロケールまたは市場に関連付けたままにします。
6. コンテンツと実装の各ゲートを通過した後にのみ、ロケールを localized-ready とします。

法律や規制の対象となるコンテンツには、専門分野のレビューが必要です。翻訳では、権限を持つ弁護士が変更を加える場合を除き、当事者、数値、義務、権利、管轄区域、バージョンの優先順位、セクションの対応関係を維持する必要があります。

既存のロケール URL を移行する

クエリパラメーター、Cookie、古いプレフィックス、ドメイン、ルーティングシステムを置き換える場合：

1. インデックス登録済みの形式や外部リンクがある形式を含め、現在の URL と動作を洗い出します。
2. 移行先の公開 URL ポリシーとロケールのマッピングを確定します。
3. 古い URL を、最も同等な新しいロケール URL に対応付けます。
4. 古い公開 URL を置き換える場合は恒久的なリダイレクトを追加し、安全であれば関連するパスとクエリの状態を維持します。
5. 内部リンク、言語切り替え、canonical、hreflang、サイトマップ、構造化データ、分析のセグメント分けを更新します。
6. ログや検索データから不要になったと判断できるまで互換性のためのリダイレクトを維持します。一律の保持期間を恣意的に設定しないでください。
7. ロールバックのトリガーを定義し、ロールバックによって競合するインデックスシグナルが復元されないことを確認します。

フレームワークの例は参考になりますが、公開 URL とコンテンツ状態の不変条件は、特定の Next.js や i18n ライブラリの設定よりも優先されます。

リリースの検証

設定ファイルだけでなく、本番環境で観測できる動作を検証します。

• 各ページタイプとロケールの代表的な URL が、意図したステータスを返すこと。
• 初期 HTML に正しい言語、タイトル、説明、canonical、ロケールに対応する構造化データが含まれていること。
• hreflang が、実際に同等で公開済みのページ間でのみ相互に設定されていること。
• 言語切り替えで対応するページに移動するか、同等のページがないことを明確に説明すること。
• ロケール URL で、複数言語が混在したコンテンツや原文言語のフォールバックを、ローカライズ済みであるかのように表示しないこと。
• サイトマップに、canonical でインデックス登録可能な公開済みロケール URL のみが含まれていること。
• リダイレクトが無限に続かず、意図した遷移先を維持し、重複した公開形式を露出させないこと。
• 同等のリンク先がある場合、内部リンクが現在のロケール内にとどまること。
• ビルド、lint、ルート生成、プロジェクト固有のテストが成功すること。

非常に大規模なルート集合では代表的なサンプルを使用し、ルート群に対する自動チェックを追加します。

モニタリングと拡大

グローバルの合計だけでなく、ロケールと市場ごとに測定します。クロール／インデックス登録の網羅率、インプレッション、クリック、コンバージョン、アクティベーション、収益、サポート負荷、コンテンツの陳腐化率を確認します。カニバリゼーション、誤ったロケールでのランキング、インデックス登録の競合を報告します。許可なくページ構成を自動的に変更しないでください。

最初のロケールで、継続的に運用できる公開体制と、ソースの変更を同期する仕組みが確立されてから拡大します。量だけでは成功とは言えません。

成果物

リクエストに必要な成果物のみを提供します。たとえば、次のとおりです。

• ロケールと市場の決定
• 現状の調査結果
• 対応範囲のマトリクスと担当者
• URL または移行マップ
• 段階的な実施計画
• リリースおよび本番環境での検証結果
• 未解決の製品、法務、市場に関する決定事項

既存のプロジェクト SSOT または実装 Skill を更新できる場合、新たな計画書を作成しないでください。

関連する Skills

• translation：公開用コピー、用語集、スタイル、言語レビュー、更新ワークフロー
• keyword-research：対象市場の検索言語と検索意図
• page-metadata、canonical-tag、url-structure：SEO と URL 実装の専門分野
• pricing-strategy、gtm-strategy：市場の経済性と参入計画
• navigation-menu-generator：言語切り替えと見つけやすいナビゲーション