訪日客はAIに聞いて店を決めている｜多言語×AI検索で「答え」に選ばれる情報設計

自分の店の前で、旅行者がスマホを見ながら数十秒立ち止まり、そのまま別の店へ歩いていく。そのとき画面に出ていたのは、ガイドブックでも日本語の検索結果でもありません。自分の言語でAIに投げた質問への回答と、そこに並んだ店名です。

ここで勝負が決まっているのは、翻訳メニューや外国語の料金表の出来ではありません。その候補に自社の名前が入っているかどうかです。どれだけ丁寧に多言語サイトを作っても、候補として挙がらなければ、そのサイトは開かれません。インバウンド対策は、この順序が逆になりやすい領域です。

この記事では、訪日外国人数や消費額といった数値は扱いません。扱うのは「外国語で投げられた問いに対して、自社の事実がWeb上に“答え”として存在しているか」という一点です。Googleの公式ドキュメントとschema.orgの定義で確認できる範囲にもとづき、何を・どの言語で・どこに置くかを、着手順に説明します。翻訳会社への発注や新しいツールの導入を前提にしない、社内で今日から着手できる範囲から順に扱います。

訪日客の意思決定は「候補に入るか」で決着している

訪日客がその場で使う聞き方は、日本語話者の検索とはかなり違います。「渋谷 ランチ 人気」ではなく、「Where can I get a vegetarian dinner near Shibuya station that takes credit cards?」のように、条件を全部まとめて1文で聞く形です。返ってくるのは、リンクの一覧ではなく、絞り込まれた候補と短い説明文であることが多くなります。何件返るか、どう表示されるかは、使うサービスや聞き方によって変わります。

翻訳メニューは「選ばれたあと」の道具

翻訳メニューも、英語のPOPも、指差し会話シートも、来店してくれた人・サイトを開いてくれた人に対しては確実に効きます。ただしそれらはすべて、図1の3段階目より後ろで働く道具です。2段階目の候補に入っていない店では、出番そのものが来ません。

「多言語サイトを作ったのに問い合わせが増えない」という状態は、翻訳の質ではなく、この順序に原因があることがあります。翻訳に予算を使う前に、候補に挙がる条件のほうを先に満たす必要があります。

聞かれているのは「良い店か」ではなく「条件に合うか」

訪日客の質問は、条件を絞り込む形になりがちです。豚肉が入っていないか、クレジットカードが使えるか、予約が要るか、駅から歩けるか——。これらは主観的な評価ではなく、該当するかしないかが決まっている事実です。だからこそ、その事実を書いているかどうかが効いてきます。

なぜ日本語だけのページは、外国語の問いで拾われにくいのか？

ここは、根拠のはっきりしている話だけに絞ります。Google検索セントラルの多地域・多言語サイトのドキュメントには、次のように明記されています[1]。

Google では、ページの表示内容からその言語を判断します。lang 属性のようなコードレベルの言語情報や、URL は使用しません。

この一文は、インバウンド対策の設計をかなり左右します。判断材料は「実際に画面に出ている文字」だということだからです。ページのソースに lang="en" と書いても、表示されているのが日本語であれば、日本語のページとして扱われます。

同じドキュメントは、URLの持たせ方についてもこう述べています[1]。

Google では、ページの各言語のバージョンに異なる URL を使用することをおすすめします。

「翻訳ウィジェット方式」でつまずきやすい点

サイトの右上に言語切替ボタンを置き、クリックするとその場で表示だけが切り替わる——という実装は、導入が手軽です。ただしこの方式は、切り替えてもURLが増えない構成になっていることがあります。その場合、外国語版のページはWeb上に独立した住所を持ちません。上の2つの記載に照らすと、これは望ましい形ではありません。

状態	Web上でどう見えるか
日本語ページ＋表示切替のみ（URLが増えない）	外国語版のページが独立して存在しない。表示内容は日本語として扱われうる
定型文（メニュー名・ボタン）だけ翻訳	本文は日本語のまま。Googleは、定型文のみ翻訳された状態はユーザーにとって不便だと述べている[1]
言語ごとに別URL＋本文も翻訳	各言語版が独立したページとして存在する。推奨されている形

言語版どうしを結び付ける（hreflang）

言語ごとに別URLを用意したら、それらが同じページの別バージョンであることを伝えます。Googleは、この注釈（hreflang）によって「Google 検索はユーザーの言語や地域に応じた最適なページのバージョンを表示できるようになります」と説明しています[2]。同じ言語でも地域別のURLを複数持つ場合については、こう案内されています[2]。

同じ言語でも地域が異なるユーザーをターゲットにする代替 URL が複数ある場合、その言語で地域を特定できないユーザーを対象とする汎用の URL を提供することもおすすめします。

英語を en-us や en-au だけで用意して en を置かない、という設計は避けたほうが無難です。訪日客はどこから来るか分かりません。

自動リダイレクトをかけない

「日本のIPからのアクセスは日本語版へ飛ばす」といった処理は、便利に見えて逆効果になりえます。同ドキュメントは明確です[1]。

サイトのある言語バージョンから別の言語バージョンにユーザーを自動的にリダイレクトすることは避けてください。

日本国内から英語版を見たい人——すでに来日している旅行者、在日外国人、日本在住の家族が代わりに調べているケース——がいます。国で振り分けるのではなく、言語を自分で選べる状態にしておくのが基本です。

「多言語対応」の順序を間違えない

多言語対応と聞くと、サイト全体の翻訳から考えがちです。しかし先に効くのは、文字数の少ない事実の項目のほうです。

機械翻訳をどう扱うか

機械翻訳そのものが禁じられているわけではありません。Googleのスパムに関するポリシーは、大量生成されたコンテンツの不正使用の例のひとつとして、スクレイピングしたフィードや検索結果などのコンテンツから多数のページを生成する行為を挙げており、そこには類義語への置き換え・翻訳・その他の難読化といった自動変換を伴うものが含まれるとしています。ただしその条件として、ユーザーにほとんど価値を提供しないものであることが併記されています[7]。

線引きは「翻訳か手書きか」ではなく「読んだ人の役に立つか」です。実務的には次のように分けられます。

• 機械翻訳を起点にしてよい範囲：誤訳しても実害が小さく、読んだ人にとって内容が伝わっていれば足りるもの（読み物・季節の案内など）。ただし「読んで意味が通るか」は一度は確認します。
• 人の目を通すべき範囲：決済・アレルギー・料金・予約条件・キャンセル規定など、誤訳が実害になる項目。ここは翻訳精度ではなく、事業リスクの話です。

「ベジタリアン対応」を機械翻訳しただけのページが、実際には出汁に鰹が入っているのに vegetarian と読める状態になっていた——という食い違いは、翻訳品質の問題ではなく、元の日本語が曖昧だったことに起因します。翻訳する前に、日本語の側を事実の粒度まで書き直すのが順序です。

自社の情報は、どの面から整えるべきか？

置き場所は、自社で管理できる面から埋めます。他社が管理する面は最後です。

面	やること	自社で管理
自社サイト	言語別URL、事実ページ、hreflang、構造化データ	できる
Googleビジネスプロフィール	属性・営業時間・写真・説明文の整備	できる（オーナー確認が前提）
公式SNS	プロフィール欄の表記統一、固定投稿に事実をまとめる	できる
予約・EC等の外部サービス	掲載情報を自社サイトと一致させる	おおむねできる
口コミ・旅行ポータル・まとめ記事	誤りがあれば運営者へ修正を依頼する。外国語の口コミには返信で事実を補える	できない

自社サイト｜「事実ページ」を1枚だけ先に作る

事実ページとは、決済手段・食事制限・アクセスなど、条件付きの問いに対する答えだけを外国語で並べた1ページのことです。読み物ではなく、見出しを質問の形にし、その直下に短い断定文で答えを置きます。段落の途中に埋め込まず、拾える形にしておくことが要点です。

全ページを翻訳する前に、この1枚だけを先に作ります。「一部分だけ切り出されても意味が通る書き方」は、AI検索全般に共通します。作法はAI検索で引用されるWeb改善チェックリスト10に、全体像はLLMOとは？SEOとの決定的な違いとLLMO対策完全ガイドにまとめています。

Googleビジネスプロフィール｜語学力なしで埋められる項目から潰す

店舗・事業所を持つ場合、Googleビジネスプロフィール（以下GBP）が最も負担の小さい着手点です。理由は、属性が自由記述ではなく、あらかじめ用意された選択肢だからです。Googleビジネスプロフィールヘルプでは、属性として、バリアフリー（入口・トイレ・駐車場・エレベーター等）、電子決済オプション（PayPay、楽天ペイ、au PAY、交通系ICなど）、ビジネスアイデンティティ、リサイクルなどが案内されており、各項目は「はい」「いいえ」を選ぶ形式です[6]。

選択式の項目は、文章の翻訳とは違って自分で外国語を書く必要がありません。予算も語学力も要らない項目ですが、着手されないまま残りやすい部分です。属性の埋め漏れは、多言語サイトの制作より先に潰す価値があります。

GBPそのものの運用はMEO対策の本質で、小売店の地図まわりの考え方は小売店のGoogleマップ×AI検索 集客ガイドで扱っています。

SNS・外部サービス｜「そこだけにしかない情報」を作らない

臨時休業や新メニューをSNSにだけ投稿し、サイトを更新しない——この状態だと、SNSを見ていない人には情報が届きません。事実は必ず自社サイト側に置き、SNSはその告知に使う向きにしておくと、情報の所在が1か所に定まります。

表記ゆれと固有名詞を1つに固定する

日本の店名・地名・駅名は、ローマ字の書き方が複数成立します。地味ですが、インバウンド文脈では影響が大きい部分です。

対象	ばらけやすい例
店名	Sushi Tanaka ／ SUSHI TANAKA ／ Tanaka Sushi ／ 鮨たなか
地名・駅名	Shinbashi ／ Shimbashi、Ohsaka ／ Osaka、Tokyo Sta. ／ Tokyo Station
施設・支店名	Shibuya branch ／ Shibuya store ／ Shibuya-ten
長音・促音	Ryokan Kohyoh ／ Ryokan Koyo、Nikko ／ Nikkō
電話番号	03-1234-5678 ／ +81-3-1234-5678 ／ 81-3-1234-5678

「これが正」と決めた表記を1つ書いた社内メモを作り、サイト・GBP・SNS・予約サービス・名刺・看板に同じものを使うだけです。ばらつきは、表記を決めていないまま担当者がそれぞれ入力したときに起きます。

電話番号は、国内表記に加えて国際表記（+81 から始まる形）も併記します。海外から、あるいは国際ローミング中の端末から、そのまま発信できるようにするためです。

別名と対応言語を、機械が読める形で書いておく

正式名称と通称の両方が使われている場合は、構造化データで両方を明示できます。GoogleのOrganization構造化データのドキュメントは、推奨プロパティ alternateName を「組織の通称として知られている別の名前」と説明しています[3]。schema.org側の定義は「An alias for the item.（そのアイテムの別名）」です[4]。

対応できる言語も、文章で書くだけでなくプロパティで示せます。schema.orgの availableLanguage は「A language someone may use with or at the item, service or place.（そのアイテム・サービス・場所において人が使用しうる言語）」と定義され、IETF BCP 47 の言語コードを使うよう案内されています。ContactPoint のほか LodgingBusiness（宿泊施設）や TouristAttraction（観光施設）でも使えます[5]。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Sushi Tanaka",
  "alternateName": ["鮨たなか", "Tanaka Sushi"],
  "url": "https://example.com/en/",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "reservations",
    "availableLanguage": ["ja", "en"]
  }
}

ただし構造化データは、書けば選ばれるようになる仕掛けではありません。Googleは、Organization構造化データについて「Google は組織の管理情報の詳細を把握して、検索結果で組織を明確化できるようになります」と説明しており[3]、位置づけはあくまで取り違えを減らすための整理です。マークアップの実践はLLMO×構造化データの実践テクニックにまとめています。

訪日客がAIに尋ねる問いに、自社の答えは存在するか？

以下は、条件付きの問いとして挙がりやすいものです。自社について、それぞれの答えが外国語でWeb上に存在するかを確認してください。

問い	必要な答えの粒度	置き場所
支払い カードは使えるか	「キャッシュレス対応」では不足。使えるブランド・電子マネー・QR決済を名前で列挙。現金のみならそう書く	GBP属性／事実ページ
食事制限 ハラル・ベジタリアン・アレルギー	「対応可」ではなく、どの料理が該当し、何が入っていないか。出汁・みりん・調理油・共用フライヤーまで書く	事実ページ／メニューページ
予約 予約は要るか	不要／推奨／必須のどれか。予約手段（Web・電話・アプリ）と、当日枠の有無。電話のみなら対応言語も	事実ページ／GBP
免税 免税で買えるか	自店が免税対応しているか、手続きの場所、必要な持ち物、対象外の商品。制度一般の解説ではなく自店の運用	事実ページ／店頭表示
アクセス どう行けばよいか	最寄駅の英語表記、出口番号、徒歩分数、目印。バス・タクシーで伝えるための住所表記も	事実ページ／GBP
営業時間 いま開いているか	ラストオーダー、定休日、祝日・年末年始の扱い、臨時休業。サイトとGBPで同じ値にする	GBP／事実ページ
言語 英語は通じるか	スタッフが話せる言語、英語メニューの有無、翻訳アプリでのやり取りが可能か。「片言なら可」も有益な情報	事実ページ／構造化データ
設備 Wi-Fi・荷物・子連れ	Wi-Fiの有無と接続方法、大型スーツケースを置けるか、ベビーカー・車椅子で入れるか、喫煙可否	GBP属性／事実ページ

上の8つは業態を問わず共通しますが、求められる答えの粒度は業種で変わります。宿泊施設ならチェックイン・チェックアウトの時刻、門限、荷物の預かり、大浴場のタトゥーの扱い。小売店なら免税手続きの場所、在庫、海外発送の可否、サイズ表記の対応。美容室・サロンなら当日予約の可否、施術にかかる時間、カウンセリングを何語でできるか、使用する薬剤や仕上がりの説明。クリニックなら診療科目、外国人が受診できるか、問診票が外国語で用意されているか、支払い方法。いずれも「良し悪し」ではなく該当するかしないかが決まっている事実であり、条件付きの問いになりやすい項目です。まず自社で繰り返し聞かれている質問を、上の表と同じ形に置き換えてください。

「書いていない」は、選ばれない理由として十分

条件付きの問いで候補を絞るとき、条件を満たすと確認できない店は外れます。実際には対応していても、Web上に記述がなければ同じことです。逆に言えば、すでに店でやっていることを書くだけで、条件を満たすと確認できる状態になります。設備投資も新メニューも要りません。

3つの面で答えが食い違っていないか

すでに誤った説明が出回っている場合の直し方は、「AIが自社を間違って説明する」を直す方法で、原因の切り分けから手順まで扱っています。

よくある失敗

AI検索・MEO対策のご相談をお受けする中で、実際に挙がるものを並べます。心当たりのある項目から潰してください。

明日からの実行手順

順序どおりに進めれば、初期の負担は小さく済みます。1〜3は翻訳会社に依頼しなくても着手できます。

手順	やること
STEP 1 棚卸し	前掲の8つの問いについて、自社の答えを日本語で書き出す。この時点で「決まっていない」項目が見つかることが多い
STEP 2 表記の固定	店名・住所・駅名・支店名のローマ字表記を1つに決め、社内メモに残す
STEP 3 GBPを埋める	属性・営業時間・写真・説明文を整える。選択式の属性は語学力なしで埋められる
STEP 4 事実ページを1枚作る	英語版を1ページ、独立したURLで公開する。問いを見出しにし、直下に答えを短く置く
STEP 5 結び付けと検証	日本語版と英語版をhreflangで結び、構造化データに別名・対応言語を入れる。実際に外国語で問いを投げて、答えが返るかを確認する

言語を増やすのは、英語版が一巡してからで構いません。1言語でも、事実が揃っていて表記が固定されていれば、何も置いていない状態とは扱われ方が変わります。

確かめ方は「同じ問いを投げ直す」だけでよい

効果の確認は、STEP 1で書き出した問いを外国語のまま複数のAIサービスに投げ、返ってきた答えと引用元URLを記録するところから始めます。着手前と着手後で同じ問いを使えば、変化が分かります。検索結果の外側で回答が完結してしまう挙動そのものへの向き合い方は、ゼロクリック対策完全ガイドで扱っています。

よくある質問（FAQ）

まとめ｜次にやること

インバウンド対策は、翻訳の量ではなく事実の整備から始めるほうが早く効きます。順序は次の3つです。

1. 書き出す：条件付きで聞かれる8つの問いに、自社の答えを日本語で確定させる
2. 固定する：店名・住所・駅名のローマ字表記を1つに決め、全ての面で同じものを使う
3. 置く：GBPの属性を埋め、英語の事実ページを独立したURLで公開し、hreflangと構造化データで結び付ける

難しいのは3ではなく1です。「うちは何語で、どこまで対応できるのか」が社内で確定していないまま翻訳を発注すると、曖昧な訳文が出来上がります。ここは外部に頼んでも代わりに決められない部分です。

一方で、外国語で問いを投げたときに自社が実際にどう扱われているか、どの面の情報が食い違っているかは、社内からは見えません。確認すべき面はサイト・GBP・SNS・予約サービス・外部の掲載先と広く、面の数だけ手間がかかります。決めるのは社内で、現状の把握だけ外に出す——という切り分け方もあります。

出典

本文中の引用・参照は、以下の一次情報にもとづいています（最終確認：2026年8月8日）。

1. Google検索セントラル｜多地域、多言語のサイトの管理
2. Google検索セントラル｜ページのローカライズ版について Google に伝える
3. Google検索セントラル｜Organization（組織）の構造化データ
4. schema.org｜alternateName
5. schema.org｜availableLanguage
6. Googleビジネスプロフィールヘルプ｜ビジネスの属性を追加、編集する
7. Google検索セントラル｜Google ウェブ検索のスパムに関するポリシー