インサイト
ロケール同等性：AI AgentはWebサイトをどう翻訳すべきか
Locale parity（ロケール同等性）は、Webサイトが単に翻訳されたのか、本当にローカライズされたのかを分ける基準です。AIコーディングAgentが多言語対応を担うなら、必要なのはこの基準であり、「サイトをスペイン語に翻訳して」というプロンプトではありません。
一文でのテストはこうです。意図して公開するすべてのロケールで、人間とクローラーがソースの一貫した双子を体験できること。つまり、同じJobs-to-be-doneページ、正しい言語信号、適応された検索言語、壊れていない構造、そして何もずれていない証拠があることです。
多くのチームは文字列で止まります。Agentはその失敗を速くします。この記事ではロケール同等性を端から端まで定義し、SEOを壊さずにAgentがWebサイトを翻訳する方法を示します。
「翻訳済み」サイトがそれでも失敗する理由
en.json の隣に ja.json を出荷すると、完了したように感じます。ユーザーとGoogleはそう見ません。
よくある失敗パターン：
- 兄弟ページがない。 英語には
/pricingがあるのに、日本語は404。Hreflangが存在しないページを指します。 - 「ローカライズ済み」ページに英語のUIが残る。 Heroは日本語なのに、ナビ、Cookie、CTAがまだ Book a call のままです。
- ドキュメント言語が間違っている。 すべてのロケールで
<html lang="en">。og:localeはen_USに固定。 - クロール上のアイデンティティが壊れる。 sitemapの入口が2つ、相対hreflang、またはnoindexのプレースホルダーにhreflang。
- 直訳キーワード。 フランス系カナダ市場向けのタイトルが英語の直訳で、実際の検索語から外れます。
- 構造のずれ。 ドイツ語で
{name}プレースホルダーが落ちる。アラビア語なのにdir="rtl"がない。schemaのinLanguageがURLと矛盾する。
翻訳カバレッジは緑に見えても、ロケール同等性は赤のままになり得ます。キーのカウンターは、テンプレートのずれ、SERP言語、相互対応するalternateを検出しません。
この一部に対する狭い「parity」ツールはすでにあります。カタログキーのdiffや、通貨・電話schemaの国際化信号チェックなどです。有用ですが、不完全です。ロケール同等性こそが、Agent主導のWebサイトローカライズに必要な完全な基準です。
標準がないとAI Agentが問題を悪化させる理由
コーディングAgentは、大きなdiffをすばやく作るのが得意です。まさにそこがリスクです。
プレイブックがないと、Agentは次のように振る舞いがちです。
- すべての文字列を一度に機械翻訳する。
- 辞書を使って英語タイトルを他ロケールへコピーする。
- 「親切」のつもりで
Accept-Languagemiddlewareを追加する。 /404や下書きを含むすべてのパスにhreflangを出力する。- TypeScriptのビルドが通ったという理由で検証を省く。
完了定義のないスピードは、進捗に見える多言語負債を作ります。ロケール同等性がその完了定義です。
このプレイブックをパッケージ化したもの（チェックリスト、翻訳ガイド、オフラインHTMLチェッカー）が必要なら、無料のMIT i18n Agent GitHub package を入手し、CursorまたはClaude Codeへクローンしてください。
ロケール同等性の5つの層
| 層 | 答える問い | 失敗した状態 |
|---|---|---|
| ルートとコンテンツ | 意図したページが双子として存在するか？ | ソフト404、孤立したENリンク、不完全な収益ページ群 |
| ドキュメントとクロール | クローラーが言語クラスタを信頼できるか？ | 間違った lang、壊れたhreflang、二重sitemap |
| 意味 | その市場の言語と検索でコピーが機能するか？ | 直訳、トーン不一致、使われない現地クエリ |
| 構造 | 双子ページはまだ動くか？ | 落ちたプレースホルダー、欠けた複数形、LTRのアラビア語、誤ったschema URL |
| 検証 | 回帰でビルドを失敗させられるか？ | 次のAgent PR後の静かなずれ |
1. ルートとコンテンツの同等性
ロケールごとに、どのページを意図して存在させるかを決めます。収益ページ、insights、法務、ツールなどです。デフォルトロケールをプレフィックスなしにするか、すべてを常にプレフィックス付きにするか、どちらかを選び、一貫させます。
Agentが従うべきルール：
- ロケールごとに同じ意図されたルートツリーを作る。ページが本当に存在しない場合は、hreflangから除外する。
- 内部リンクは同じロケール内に保つ（日本語ページなら
/ja/about、/aboutではない）。 - 双子ページに同じnoindexポリシーを適用する（
/coffee、プレースホルダー、Agent markdownミラー）。 - alternateをきれいに対応付けられるよう、ロケール間で安定したslugを優先する。
コンテンツコレクション（MDX/Markdown）、部門データファイル、UI chromeは別々の翻訳レイヤーです。Agentは messages/*.json だけでなく、3つすべてを棚卸ししなければなりません。
2. ドキュメントとクロールの同等性
これは多言語SEOの衛生管理です。ここを間違えると、Googleはクラスタを信頼しません。
インデックス可能な各ロケールURLに必要な最低限の信号：
- 自己参照の絶対 canonical
- 一致する
og:url - ローカライズされたtitleとdescription
- ロケールレジストリに基づく
<html lang>とdir（必要に応じてBCP47） - BCP47コード（
fr-CA、zh-CN）を使った相互対応のhreflangセットと、デフォルトロケールURLを指すx-default - noindexページにはhreflang（または
og:locale:alternate）を出さない <head>と一致するxhtml alternateを持つ、ひとつの公開 sitemap 入口- 正しい
inLanguageとロケールに合ったエンティティURLを持つ構造化データ
アンチパターン：Geo-IPによる強制リダイレクト、二重のsitemapアイデンティティ、相対hreflang、レジストリにないロケールコードの発明。
3. 意味の同等性
意味の同等性は、ローカライズが文字列置換ではなくなる地点です。
Agentがすべきこと：
- 用語集を維持する（製品名、ロックされたURL、翻訳してはいけない用語）。
- 市場ごとのスタイルガイドに従う（カナダフランス語 ≠ フランス本国のフランス語、中立的なラテンアメリカスペイン語 ≠ スペイン限定の慣用句）。
- 英語のキーワードマップを文字通り翻訳するのではなく、現地SERPに合わせてキーワードを適応する。URLごとに主意図はひとつ。
- 現地での明確さとCTRに合わせてH1、title、metaを書き直す。ブランドエンティティは一貫させる。
- Search Consoleでソフト404になり得る薄い機械翻訳を拒否する。
意味の同等性は、AI検索のような面が評価するものでもあります。スペイン語URLの下に英語段落を置くのではなく、ユーザーの言語で明確なエンティティと回答を示すことです。
4. 構造の同等性
壊れた表示をする双子ページは、双子ではありません。
確認すること：
- 補間 / ICUプレースホルダーがソースと一致する（
{count}、<0>…</0>タグ）。 - 複数形とselect分岐は、英語形式のコピーではなく、対象言語が必要とする形（CLDR）に合っている。
- RTLロケールには
dir="rtl"と読みやすいフォントを与える。CJKには適切なタイポグラフィを使う。 - 日付、数字、通貨を表示する場合は、ロケール対応のフォーマットを使う。
- JSON-LDで、すべてのページに英語専用パスや
en言語をハードコードしない。
カタログだけを見る同等性スクリプトはここで役立ちます。必要ではありますが十分ではありません。dist/ 全体のHTMLとschemaチェックと組み合わせてください。
5. 検証の同等性
Agentが証拠なしにマージできるなら、ずれは必ず起きます。
検証の同等性とは：
- 生成されたHTMLに対するビルド時ゲート：title、description、H1、canonical、
og:url、lang、hreflangの完全性、noindexルール。 - ロケール棚卸しテスト：意図して存在するすべての収益ページが、すべての公開ロケールに存在する（または明示的に除外されている）。
- デプロイ後の本番スポットチェック：ライブのheadタグ、sitemapアイデンティティ、analytics
page_locale、RTLサンプル。 - Agentが読めるレポート：次の実行が盲目的に再翻訳するのではなく、発見事項を修正できるようにする。
Rank & Beyondは、自社の多言語サイトでこの種のチェックを実行しています。再利用可能なスキルパックは、同じ規律を他のリポジトリ向けにコード化したものです。
Agentのアンチパターン（出荷しない）
| アンチパターン | なぜ有害か |
|---|---|
Geo-IPまたは Accept-Language の強制リダイレクト |
キャッシュ分断、クローラー混乱、ユーザーの閉じ込め |
| noindex / 404 / 下書きへのhreflang | 言語クラスタを汚染する |
| 二重のsitemap入口 | クロール上のアイデンティティを分割する |
| 英語キーワードの直訳を「ローカライズ」と呼ぶ | 現地の需要言語を逃す |
| 用語集なしの一括MTダンプ | トーンと製品用語がずれる |
| ロックされたブランド名や予約URLを翻訳する | コンバージョンと信頼を壊す |
| ルートの双子なしにロケールをliveと宣言する | hreflangが404を指す |
Agentが「便利だから」とこれらを提案したら、その変更は拒否してください。
AI AgentはWebサイトをどう翻訳すべきか
ローカライズを単一のプロンプトではなく、段階的なエンジニアリングワークフローとして扱います。
フェーズA — 発見
- フレームワーク、ルーティング、i18nライブラリ、コンテンツソースを検出する。
- 現在のロケール、デフォルトロケール、URL戦略を棚卸しする。
- 収益ページ、insights/blog、法務、noindexユーティリティを分ける。
- 予約リンクやanalytics IDなど、発明してはいけないロック済み外部IDを記録する。
フェーズB — 計画
- ロケールレジストリを書く、または更新する（codes、labels、
htmlLang、dir、OG locale、BCP47）。 - 市場の優先順位を決める（すべてのspoke × すべてのロケールに広げる前に、主要市場を深める）。
- 英語の直訳ではなく、ロケールごとに適応したクエリでキーワードマップを作る。
- リスクをフラグする：RTL、CJK、法務コピー、薄いページ。
フェーズC — テクニカルSEOを実装
- helperを接続する：
localizePath、alternatePath、locale-from-pathname。 - canonical、OG、hreflang、sitemap i18n、schema URLを出力する。
- UI内に言語選択を残す。強制リダイレクトはしない。
robots.txt、sitemap URL、Agentインデックス（llms.txt、agent.json）を揃える。
フェーズD — 翻訳とトランスクリエーション
- UI chrome、構造化データのコピー、長文コンテンツを別々のパスでローカライズする。
- 用語集とスタイルガイドを適用する。title/metaをSERP言語に合わせる。
- コード、プレースホルダー、ロックされた文字列を保持する。
- 優先市場では、H1、title、meta、FAQに人間のレビューを入れる。
フェーズE — 検証
dist/またはURLリストに対してHTML auditorを実行する。- hreflang欠落、lang不一致、og/canonicalのずれ、noindex alternateでCIを失敗させる。
- デプロイ後に本番をスポットチェックする。
- 残っているものが意図した負債なのか、ブロッカーなのかを記録する。
これが運用ループとしてのロケール同等性です。フェーズDだけを行うAgentは翻訳者です。A-Eを完了するAgentがローカライザーです。
PRに貼れる実用チェックリスト
多言語PRの完了定義として使ってください。
- ロケールレジストリがcodesと
dirの唯一の信頼できる情報源である - 各liveロケールに意図されたルートが存在する（またはalternateが欠けたページを省いている）
- 内部リンクは同ロケール内に留まる。非英語ページに意図しないEN漏れがない
- すべてのインデックス可能な双子ページでcanonical ===
og:url - インデックス可能なページのみに、完全な相互BCP47 hreflang +
x-default - title/descriptionがローカライズされ、固有である。キーワードは直訳ではなく適応されている
- プレースホルダー/複数形/RTL/schema構造が壊れていない
- sitemap入口はひとつ。noindexルートは除外されている
- 回帰時にビルドゲートが失敗する
- 少なくとも1つの非英語収益ページで本番スポットチェックが完了している
i18n Agent GitHub packageを入手する
Agentにこのプレイブックを標準で従わせたいなら、毎スプリントでチェックリストを作り直すのではなく、スキルをインストールしてください。
無料のMIT i18n Agent packageを入手 — 公開GitHubリポジトリを開き、CursorまたはClaude Codeにクローンして、AGENTS.md / CLAUDE.md が SKILL.md を参照するようにします。
中身は、段階的なAgentワークフロー、多言語SEOチェックリスト、翻訳プレイブック、hreflang、canonical/og:url、lang不一致、noindex alternateのミスを検出するオフラインPythonチェッカーです。
ローカライズだけでなく、より広い収益システムが必要な創業者は、BeyondOS™と、Website、SEO、Contentの各部門がひとつの計画の下でどのように記憶を共有するかをご覧ください。
ロケール同等性FAQ
ロケール同等性はSEOだけのものですか？
いいえ。SEOはクロール層です。ロケール同等性は、UXの完全性、構造の完全性、CIによる証明も含みます。サイトが翻訳されたクエリで順位を取っていても、RTL、CTA、プレースホルダーが間違っていればユーザーには失敗します。
初日からすべてのinsightを全言語で用意する必要がありますか？
いいえ。需要が不明なときは、まず英語のspokeを出荷します。勝ち筋が見えたものについて、優先市場（たとえばカナダフランス語、その後スペイン語）をローカライズします。その他のロケールは、明確な勝者や既存の同等性のために維持します。意図されたページがない状態で、hreflang上のliveロケールとして宣言してはいけません。
ひとつのAgentプロンプトでTMSを置き換えられますか？
多くのプロダクトマーケティングサイトでは、厳格なプレイブック、用語集、CIゲートを持つAgentで十分です。特に翻訳がリポジトリ内にある場合はそうです。多数の人間翻訳者が関わる大規模な継続プログラムでは、TMSは今も役立ちます。どちらの場合でも、ロケール同等性が品質基準です。
最速で始める方法は？
ロケールと収益ページを棚卸しし、ドキュメント/クロール信号を修正し、その後、SERPに適応したコピーでUI chromeと上位URLを翻訳します。次回のAgent実行が書き直しの前に監査できるよう、i18n Agent packageをインストールしてください。