Claudeで海外向けLPをローカライズする — 通貨・日付・必須表示を国別に差し替える

海外向けLPの翻訳で事故になりやすいのは、文章の硬さよりも数字と表示のずれです。価格の通貨記号、日付の並び、税の書き方、問い合わせ窓口の言語が、日本のLPのまま英語になっているケースです。

Claudeには、この「差し替え」を国別に一気に出させられます。ただし、何を差し替えるかの表と、差し替えてはいけない条件は人が先に決めます。この記事では、Projectsに用語集とトーンを固定し、国別の版を作り、別チャットで逆翻訳して検算するところまでを順に扱います。

直訳のLPは「数字と表示」から崩れる

日本語LPを英語に直訳しても、訳文が不自然になるとは限りません。崩れるのは次のような箇所です。

日付は特に事故になりやすい項目です。W3Cの国際化ガイドによると、MM/DD/YYという並びは米国に固有で、欧州の多くはDD/MM/YY、日本はYY/MM/DDを使います。同じ「03/04/02」でも、読む国によって3月4日にも4月3日にもなります。

差し替える項目を入力表にして先に決める

Claudeに「この国向けに直して」と頼むと、どこまで変えるかを毎回自分で判断します。判断を人側に戻すため、国ごとの差し替え条件を入力表にして渡します。

表の「国別に決める内容」は、マーケティング担当や現地の代理店が埋めます。Claudeが埋めると、為替換算や法令の記述を推測で書くことになります。価格は換算させず、確定値を表に書いて渡すのが安全です。

用語集とブランドトーンをProjectsに固定する

国別の版を何本も作るなら、毎回の指示を同じにしておく必要があります。Projectsには、知識として資料を置く場所と、プロジェクト指示を書く場所があります。指示はそのプロジェクト内のすべてのチャットに効きます。

置くものは次の3つです。

• 用語集: 製品名・機能名・プラン名の固定表記と、使わない表記
• ブランドトーンの説明: 「親しみやすいが砕けすぎない」など、LPの声を数行で
• 国別の入力表: 前節の表を国の数だけ並べたもの

プロジェクト指示は、例えば次のように書きます。

あなたは当社の海外向けLPのローカライズ担当です。
入力は日本語LPと、国別の入力表です。次を守ってください。
1. 用語集の「固定表記」だけを使い、「使わない表記」は出さない。
2. 価格・税・日付・単位は入力表の値をそのまま書く。換算しない。
3. 必須表示の欄が空の国は、本文に書かず「要確認」と一覧に出す。
4. 直訳できない訴求は、意味を保った言い回しに変え、変えた箇所を表にする。
5. 出力は国ごとに「LPの訳文」と「変更点一覧」の2つに分ける。

用語集を作る手順はClaudeで英文プレスリリースを翻訳するで詳しく扱っています。LPでは製品名と機能名が中心なので、列は「固定表記」「使わない表記」の2つで足ります。

Projectsは無料アカウントでも使えますが、作れるのは最大5つまでです。有料プランでは、プロジェクトの知識が増えて上限に近づくとRAGモードが自動で有効になり、容量が最大10倍に広がります。国の数が多いときは、国ごとにプロジェクトを分けるより、1つのプロジェクトに入力表を並べるほうが枠を節約できます。

国別の版を一度に出させて、変更点を表で受け取る

日本語LPのテキストを貼り、対象の国を指定します。

添付の日本語LPを、入力表の「米国」「ドイツ」「シンガポール」向けに
ローカライズしてください。国ごとに、訳文と変更点一覧を出してください。

出力は、例えば次のような形に揃えます(形式の例です)。

見るべきは訳文より「変えた理由」の列です。理由が書かれていない変更は、Claudeが自分で足した可能性があります。変更点一覧に載っていない差異を見つけたら、入力表か指示に書き足して、同じチャットで再出力させます。

ページのコードに戻すときは、言語の宣言も国別に分けます。W3Cのガイドは、html要素のlang属性でページの既定の言語を宣言し、別の言語の文章は囲む要素にlang属性を付けるよう勧めています。言語タグはIANAの言語サブタグレジストリから選びます。LPの納品物にlang属性の値を含めるよう、指示の末尾に1行足しておくと抜けを防げます。

訴求の言い回しは「何を安心材料にするか」から変える

見出しやボタンの文言は、単語を置き換えるだけでは国の読者に響きません。日本のLPで定番の「選ばれて累計○万人」「まずは無料でお試し」が、別の国でも同じ重みで読まれるとは限らないからです。

そこで、訳す前に「この国の読者は何を見て申し込みを決めるか」を、入力表に1行で書きます。例えば次のような欄です。

Claudeは、この欄を読んで見出しとボタンの案を複数出せます。案を選ぶのは人です。根拠のない人数や実績は、案の中に紛れていないか変更点一覧で確認します。事実として確認できていない数字は、どの国の版にも入れません。

本文以外の文字も差し替え漏れの定番

LPの翻訳では、本文を直しても次の箇所が日本語のまま残る事故が起きます。納品前に、Claudeへ「日本語が残っている箇所を一覧にして」と頼み、機械的に拾わせます。

• 画像の中に埋め込まれた文字(バナー・図・スクリーンショット)
• titleタグとmeta descriptionの文言
• フォームのプレースホルダー、エラーメッセージ、完了画面の文言
• 決済や確認メールなど、LPの外にある導線の文言

画像内の文字は、Claudeに画像を渡して文字を書き出させれば拾えます。ただし画像そのものの差し替えはデザイン側の作業なので、一覧は「要差し替え」としてデザイン担当に渡します。

必須表示はClaudeに決めさせず、確認済みの条件を渡す

「必須表示を国別に差し替える」は、LPのローカライズで最も慎重に扱う部分です。ここは訳文の品質ではなく、販売先の規則の問題だからです。

EUの事業者向け案内には、参考になる整理があります。消費者向けの契約条項には公正さと透明性の要件があり、条項は平易で分かりやすい言葉で書く必要があります。曖昧さは消費者に有利に解釈されます。この規則は消費者との取引が対象で、事業者向けの販売には当てはまりません。さらに、EUの規則は最低基準で、各国の法律で強化・拡張されることがあり、案内は各国のEnterprise Europe Networkへの相談を勧めています。

LPの運用に引き直すと、次のようになります。

• 消費者向けか事業者向けかで、要る表示が変わる可能性がある。入力表に「販売先の相手」の欄を作る
• 国の規則は上位の枠組みの上に各国の法律が乗ることがある。EU域内でも国別に確認する
• Claudeには「規則を調べて書く」より、確認済みの文言を渡して「訳す・整える」を任せる

必須表示の文言は、現地の担当や専門家が確認したものを入力表に書き、Claudeはその文言の訳と、LP内の置き場所の整合だけを見ます。規則の要否そのものをClaudeの回答で判断しない、という線引きです。

逆翻訳は別チャットで取る

翻訳後の意味のずれは、日本語に戻して見ると気づきやすくなります。このとき、同じチャットで「日本語に戻して」と頼むのは避けます。直前の訳の経緯が文脈に残っていて、原文の意図に引きずられて戻してしまうためです。

Projectsのチャットは、知識に追加した情報を除いて、互いの文脈を共有しません。この性質を利用して、同じプロジェクトの新しいチャットで逆翻訳を取ります。

次の英語のLP文を、日本語に逆翻訳してください。
意訳せず、英語に書かれている内容だけを日本語にしてください。
原文の日本語は渡しません。

戻ってきた日本語を、元のLPと並べて比べます。見る点は次の3つです。

1. 数字(価格・日付・割引率・期間)が一致しているか
2. 「必ず」「最大」「業界初」のような強い言い切りが増えていないか
3. 元にない保証や効果の表現が加わっていないか

3つ目は、直訳しない言い換えで特に起きやすい点です。広告表現の可否は国ごとに違うため、強くなっていたら変更点一覧に戻って理由を確認します。

同じ流れで問い合わせ対応まで海外向けにするなら、英語の問い合わせに返信する手順がそのまま使えます。訳の下書きを専用の翻訳ツールに任せ、Claudeを整える役に回す方法はClaudeとDeepLの連携にあります。

よくあるつまずき

用語の揃え方は、手順書向けに書いた作業手順書の多言語化の用語集の作り方がそのまま応用できます。翻訳の精度を確かめてから確定する一般的な流れはClaude翻訳ワークフローにまとめています。

まとめ

LPのローカライズは、訳す作業より、差し替える項目と確認済みの条件を先に表にする作業です。その表をProjectsに固定すれば、国が増えても同じ指示で回せます。

最後の検算は、別チャットでの逆翻訳です。数字と言い切りの強さだけを見れば、見る時間は短く済みます。必須表示は、確認済みの文言を渡して訳させる範囲にとどめ、要否の判断は現地の担当に残します。