LLMO対策は英訳だけで十分？海外向けサイトで直す言語・料金・提供条件

英語ページを作ったのに、海外からの問い合わせが増えない。AIに自社サービスを聞くと、英語では説明されるものの、利用できる国や料金が違っている。こうした状態を調べるときは、訳文の上手さだけでなく、誰が、どの条件で申し込めるページなのかを確認します。

LLMO対策は、生成AIの回答で自社の情報がどう紹介されるかを調べ、情報やサイトを整える取り組みです。海外向けでは「英語にした」という作業と、「対象国の顧客が判断できる」という状態を分けて考える必要があります。

この記事では、サービス紹介の日英ページを一組選び、提供条件、URL、AI回答、更新担当を順に点検します。Google検索の技術的な案内は公式資料に基づきますが、すべてのAIに同じ仕組みがあるという説明ではありません。表と質問例は、編集部が作成した架空の業務サービスを使った確認用の例です。

LLMO対策で英訳の前に決める国と読者

英訳の前に、対象国、読み手、申し込み条件を一枚に書き出します。「海外向け」だけでは、料金の通貨や問い合わせ時間を決められません。

たとえば、日本に拠点がある外国企業へ売るサービスと、海外にしか拠点がない企業へ売るサービスでは、必要な説明が違います。英語を読む人が全員、米国に住んでいるわけでもありません。

最初に決める項目	記入例（架空）
読者	日本に拠点がある企業の、英語で業務をする管理担当者
読者が決めたいこと	日本拠点の問い合わせ管理に導入できるか
契約できる対象	日本国内の法人。海外法人からの直接契約は未対応
英語でできること	サービスの理解、問い合わせ、メールでの相談
次の行動	英語の相談フォームで対象拠点と用途を送る

この表を営業やサポートと確認してから、ページに載せる情報を決めます。翻訳担当が提供範囲まで推測して埋めると、自然な英文でも事業の実態と違ってしまいます。

英語対応と海外提供を分ける

「英語で使える」と「どの国でも契約できる」は別の条件です。画面、問い合わせ、契約書、導入支援のどこまで英語に対応しているかも、それぞれ確認します。

架空の例で、管理画面は日本語のみ、営業相談は英語に対応しているなら、「English support」の一言では範囲が伝わりません。「営業への問い合わせは英語で受け付けます。管理画面は日本語です」と書けば、導入後に使う人も判断できます。

AI回答を点検するときも、自社名が出たかだけを見ないでください。「海外のどの企業でも利用できる」と説明されていないか、実際の提供範囲と比べます。誤った条件で候補に入っても、そのまま有効な問い合わせにつながるとは限りません。

国ごとに違う問い合わせを集める

現地向けに必要な情報は、実際の問い合わせや商談から探します。国ごとの性格を決めつけるのではなく、購入判断に関わった質問を記録してください。

営業メモから、顧客名などの個人情報を除いて「請求書はどの通貨か」「自国の営業時間に相談できるか」「日本拠点だけで契約できるか」といった疑問を抜き出します。それぞれに、現在の答えがあるURLを付けます。

まだ海外の顧客がいない場合は、想定質問と実際に聞かれた質問を分けて保存します。想定だけで作ったFAQを「海外のお客様からよくある質問」と呼ぶ必要はありません。商談で確認できたら、質問と答えを更新すれば十分です。

海外向けページでそろえる料金と提供条件

料金、対象地域、対応時間、申し込み後の流れを、日英で同じ対象について確認します。日本語の価格表と英語の紹介文を別々に読むだけでは、条件の抜けを見逃しやすいためです。

次の表は架空のサービスの点検例です。自社の承認済み条件を左に置き、英語ページに同じ意味が残っているかを右で照合します。

承認済みの条件（架空）	英語ページで確かめる内容
月額3,000円、年払い契約	月額表示と年払いの条件が隣にある
日本国内の法人が対象	英語で読めても、契約対象が広がっていない
平日10〜18時、日本時間	時間帯と休業日の基準を読める
相談後に見積もり	フォーム送信だけで利用開始とは書いていない

条件の説明を価格表の脚注だけに押し込めず、申し込みボタン付近にも必要な情報を置きます。ページを読んだ人が、問い合わせ後に初めて対象外だと分かる状態を減らすためです。

通貨・単位・時間帯をそろえる

請求通貨と、分かりやすさのための換算表示は分けます。円で請求するサービスをドル換算で紹介しても、ドル払いに対応したことにはなりません。

架空のサービスなら、価格の中心は「JPY 3,000 per month, billed annually」のように実際の請求条件で示せます。換算額を載せる場合は、換算日とレートを添え、参考額だと分かるようにします。変動する数字を維持できないなら、無理に換算表示を増やす必要はありません。

対応時間も「10:00–18:00」だけでは不十分です。「10:00–18:00 JST（UTC+9）」と時間帯を示し、日本の祝日に休むならその条件を添えます。海外の読み手が、自分の営業時間と比べるための情報になります。

翻訳しても意味が変わらない説明にする

翻訳の確認では、自然な言い方と契約条件の保持を別々に見ます。読みやすく短縮した結果、対象や除外条件が消えていないかを確かめます。

たとえば「日本法人向け。海外拠点の利用は事前相談」という原文を「Available worldwide」と訳すと、意味が広がってしまいます。説明例なら「Available to companies incorporated in Japan. Contact us before use at an overseas office.」のように、対象と相談条件を両方残します。

確認者には「この英語を読んだ顧客が、何をできると思うか」を説明してもらいます。直訳に近いかだけを見るより、期待する行動の食い違いを見つけやすくなります。機能名の表記をそろえる用語集も用意し、販売資料と画面で別の製品に見えないようにします。

多言語サイトのURLとリンクを確認する

言語ごとのページへ直接アクセスでき、読者が対応する言語版へ切り替えられる状態を確認します。Googleは、言語版ごとに別のURLを使う方法と、利用者が選べるリンクを案内しています。[1]

まずCMSから、サービス紹介と料金ページの日英URLを取り出してください。日本語のサービス紹介から英語のトップへしか移動できない場合は、対応するサービス紹介へ進めるリンクを検討します。

ページの役割	日本語URLの例	英語URLの例
サービス紹介	https://example.com/ja/service	https://example.com/en/service
料金	https://example.com/ja/pricing	https://example.com/en/pricing

URLは説明用です。公開前には実在するページに置き換え、ページ名だけでなく中身も対応しているか確認します。

言語ごとのURLと切り替えリンク

新しいブラウザタブへ英語URLを貼り、最初から英語の本文が開くかを確認します。翻訳ボタンを押した後だけ英語になり、同じURLを共有すると日本語へ戻るなら、その違いを開発担当へ伝えます。

Googleは、ブラウザ設定や推定した言語による自動転送では、すべての言語版を見つけられない場合があると説明しています。本文を日本語のまま残してメニューだけ英訳する方法も、本文が英語になった状態とは異なります。[1]

PCとスマートフォンで、言語切り替え、料金ページ、相談フォームまで進んでください。実際に送信する必要はありません。途中で説明が日本語へ戻る、海外の住所形式を入力できないなど、申し込みの判断を妨げる箇所を記録します。

hreflangとcanonicalの役割を分ける

hreflangは対応する言語・地域版を示し、canonicalは重複・類似URLの中で代表にしたいURLを示します。翻訳版をすべて日本語へまとめる指定として扱わないでください。[2][3]

次は、内容を翻訳した日英ページが一つずつある場合の説明用HTMLです。CMSの本文欄ではなく、ページのheadを管理するテンプレートや設定へ反映する内容です。

<!-- 日本語ページ https://example.com/ja/service -->
<link rel="canonical" href="https://example.com/ja/service">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/service">
<link rel="alternate" hreflang="en" href="https://example.com/en/service">

<!-- 英語ページ https://example.com/en/service -->
<link rel="canonical" href="https://example.com/en/service">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/service">
<link rel="alternate" hreflang="en" href="https://example.com/en/service">

二つのコメント以下を同じページへ全部貼らず、各ページに対応する三行を使います。例のURLを自社URLに置き換え、既存設定との重複を開発担当に確認してください。Googleの案内では、各言語版に自分自身と相互の完全なURLを示します。[2]

公開後は両ページのHTMLで指定を確認します。これは公式構文に沿った説明例であり、読者のCMSに実装して動作確認した結果ではありません。地域別の英語ページなどがある場合は、その構成に合わせた確認が必要です。

LLMO対策の結果を言語ごとに確かめる

ページを直したら、AIがどの言語で何を答えたかを記録します。自社名の有無だけでなく、提供国や料金が正しく説明されたかを確認するためです。

作業用の表には、AIサービス名、確認日時、質問文、回答、引用URL、誤っていた条件を残します。ログイン状態や、変更できる地域・言語の設定も記録してください。サービスごとに設定項目は違うため、存在しない設定を無理にそろえる必要はありません。

確認する対象	記録する内容
AIの回答	自社名、提供条件、価格、説明の正誤
出典	どの言語・どのページを引用したか
サイトへの訪問	どのページに来たか、参照元を取得できたか
問い合わせ	契約対象に合う相談か、誤認があったか

この表は観測を整理するための提案です。GoogleのAI機能にも掲載保証はなく、特別な構造化データを追加すれば選ばれるという条件ではありません。[4]

目的が同じ質問の組を作る

日英を比べるなら、単語だけでなく、対象国と利用条件を同じにした質問を用意します。言語と条件を一度に変えると、回答の違いを読み取りにくくなります。

以下は、架空サービスを調べるための質問例です。サービス名を実際の名称に置き換え、同じAIの新しい会話で各質問を試し、結果を保存します。

日本法人が日本拠点で「サンプル窓口」を使う場合、契約条件、請求通貨、英語で相談できる範囲を、根拠となるページと一緒に教えてください。

For a company incorporated in Japan using “Sample Desk” at its Japanese office, what are the eligibility requirements, billing currency, and scope of English-language support? Please include source pages.

この質問は、社名を知っている人への説明を確認するものです。新しい顧客への紹介を調べたい場合は、社名を含まない質問を別に用意します。質問設計の詳しい進め方は、AI計測の質問リストを作る方法で整理しています。

一回の回答を市場全体の結果にしない

一度正しく説明されたことは、その時点のその質問で確認できた結果です。対象国のすべての利用者に同じ回答が出る、という意味ではありません。

同じ質問を継続して確認する場合は、文言と条件を固定し、各回の回答を保存します。問題が見つかったら、AIの誤りと、自社ページに残っていた誤りを分けて記録してください。引用されたページが古い資料だった場合は、現在のサービスページだけを直しても説明が変わらない可能性があります。

また、AIで紹介された回数と、サイトへの訪問、問い合わせは別の指標です。訪問の調査はGA4でAI流入を確認する方法と組み合わせます。参照元を取得できない訪問まで、根拠なくAI経由へ足さないでください。

日本語版と英語版の更新を続ける

英語ページは、公開した後も元の提供条件と一緒に更新します。料金や対応時間が変わったとき、日本語だけ直すと、同じサービスについて違う説明が残ります。

変更管理には、ページ単位の完了印だけでなく、何の条件を直したかを残します。下の表は作業用の書式です。担当者名、日付、確認結果には実際の情報を記入します。

変更項目	日本語版	英語版	次の作業
年払いの価格	URL・反映日	URL・反映日	見積もり資料の価格も確認
英語の相談時間	URL・確認者	URL・確認者	フォームの自動返信も確認
契約対象の地域	URL・反映日	URL・反映日	FAQと申し込み案内を照合

翻訳作業が終わった日と、公開画面を確認した日を分けると、反映漏れを探しやすくなります。記事の日付だけを更新して、条件の確認を済ませたことにはしません。

仕様変更を両言語へ反映する

変更の起点は、翻訳原稿ではなく、社内で確定した料金や提供条件です。営業やサービス責任者が確認した内容を基準に、両言語の差分を作ります。

1. 変更した条件と適用日を、承認済みの資料に記録します。
2. サービス紹介、料金、FAQ、フォームなど、条件が出てくる場所を洗い出します。
3. 日英の説明を更新し、対象や除外条件が一致しているか確認します。
4. 公開画面で、見出し、価格、注記、リンク、画像内の文字を確認します。
5. AI回答を再確認した日時と、残っている相違を別欄に記録します。

更新後すぐにAIの回答が変わらなくても、反映済みのページを何度も同じ内容で書き換える必要はありません。どの出典が使われているかを先に確認します。公開前の全体点検には、AI記事の公開前チェックも使えます。

まずサービス紹介の一組から始める

最初は、問い合わせ前によく読まれるサービス紹介の日英ページを一組選びます。全ページの翻訳を先に増やすより、その一組から料金と相談先まで迷わず進めるかを確かめます。

今日の作業としては、対象読者と提供条件を書き、両言語のURLを並べ、同じ目的の質問でAI回答を確認すれば、直す場所を具体化できます。結果は「英訳完了」だけでなく、「英語ページに年払いの条件を追加」「海外法人が対象外であることを明記」のように残してください。

LLMO対策のために、実際には提供していない国や機能まで説明を広げる必要はありません。対象の顧客が、自分に合うサービスかを正しく判断し、そのまま相談へ進める情報をそろえることから始めましょう。