はじめに——日本語で質問したのに、根拠が英語圏ソースになっている
ChatGPTやPerplexityに日本語で質問してみてください。返ってくる回答は自然な日本語です。しかし引用元のリンクを開くと、英語圏のメディア、英語のドキュメント、英語の研究ブログが並んでいる——こうしたケースが2026年、目に見えて増えています。
本サイトではこれまで多数のAEO（Answer Engine Optimization）記事で、シェア・オブ・モデルの継続計測、引用劣化（Citation Decay）の監視、AIクローラーログ解析、競合ギャップ分析といった「AIの回答に自社が引用されるための施策」を扱ってきました。それらの記事で想定していた競合は、基本的に国内の同業サイトでした。
しかし日本語サイトの運営者にとって、いま最大の引用競合は国内他社ではありません。英語圏のソースです。日本語のクエリに対する回答面ですら、AIは英語圏の情報を根拠として選び、それを日本語に翻訳して返す——この「言語間引用ギャップ」は、既存の競合ギャップ分析や多言語AEOガイドでは扱われてこなかった構造的な盲点です。
既存の多言語AEO記事の多くは「外国語ページを作ってインバウンド需要を取りに行く」という攻めの方向を扱っています。本記事は逆です。日本語クエリの回答面を、英語圏ソースから守り、奪還する——いわば防衛戦の設計を扱います。想定読者は、日本語で一次情報を発信しているのにAI回答面で引用されない企業サイト・メディア・専門家サイトの運営者、そしてAEOを担当するマーケティング・広報部門の方々です。
前提——「言語間引用ギャップ」はなぜ起きるのか
対策の前に、なぜ日本語で質問しているのに英語ソースが引用されるのか、その仕組みを3つの要因に分けて理解します。ここを押さえないと、対策が「日本語ページの品質改善」という従来のAEO施策の繰り返しになり、的を外します。
要因1：LLMの知識そのものが英語に偏っている
大規模言語モデルの事前学習データは、圧倒的に英語が多数を占めます。Common Crawlをはじめとする学習コーパスにおいて日本語が占める割合は数％程度に過ぎず、モデルが「知識」として内在化している情報の大半は英語の文書に由来します。
この結果、検索を伴わない回答（モデルの内部知識だけで答えるケース）でも、その知識の出どころは英語圏の情報空間です。日本語の一次情報がどれだけ充実していても、モデルの「頭の中」に入っていなければ、回答の土台になりません。
要因2：言語横断RAG——日本語クエリは「日本語だけ」で検索されていない
ChatGPTの検索機能やPerplexityは、回答生成の前にウェブ検索を行い、取得したソースを根拠に回答を組み立てます（RAG：検索拡張生成）。ここで重要なのは、この検索が言語横断（クロスリンガル）で動くという点です。
日本語のクエリが入力されると、システムは内部で英語のクエリを併走させたり、多言語対応の埋め込みモデルで「言語をまたいで意味が近い文書」を取得したりします。つまり、日本語で質問しても、検索対象には最初から英語圏の文書が含まれています。そして英語圏の文書は量・更新頻度・被リンクのすべてで日本語文書を上回ることが多いため、検索結果の上位を英語ソースが占めやすくなります。
LLMは取得した英語ソースを読んで理解し、日本語で回答を書けます。翻訳コストがゼロになった世界では、「日本語の質問には日本語の文書で答える」という前提そのものが崩れているのです。
要因3：評価シグナルの非対称——「翻訳された英語情報」が日本語一次情報に勝つ構造
検索・引用の候補に日本語文書と英語文書が並んだとき、AIがどちらを根拠に選ぶかは、被リンク・被言及・出典としての実績といったシグナルに左右されます。ここに非対称があります。
- 英語文書は世界中から被リンク・被言及を集めるのに対し、日本語文書のシグナルは日本語圏に閉じる。
- 英語圏の主要ドキュメント・研究・統計は他のAIシステムでも繰り返し引用され、「引用される実績」自体が引用されやすさを強化する。
- 日本固有のテーマ（国内制度・国内市場・日本語の商習慣）ですら、英語で書かれた二次情報・三次情報——つまり翻訳・要約された英語記事——のほうが引用シグナルで勝ってしまうことがある。
結果として、「日本の一次情報を持っているのは自社なのに、それを英語で要約した海外メディアの記事が引用される」という逆転現象が起きます。これが言語間引用ギャップの最も深刻な形です。
従来の競合分析と本記事の分析対象の違いを整理します。
| 観点 | 従来の競合ギャップ分析 | 言語間引用ギャップ分析 |
|---|---|---|
| 競合の単位 | 国内の同業サイト | 英語圏ソース（言語そのもの） |
| 戦場 | 日本語の回答面での順位・引用枠 | 日本語の回答面に入り込む英語ソースとの競争 |
| 主な敗因 | コンテンツの網羅性・構造化の不足 | 言語圏をまたぐシグナルの不足 |
| 主な対策 | コンテンツ改善・構造化データ | 日英併記・国際Schema・英語圏被引用の獲得 |
現状診断——「言語別Share of Model」で、どの言語のソースに負けているかを測る
これまでのAEO記事で扱ってきたシェア・オブ・モデル（自社がAI回答に引用される割合）の計測に、引用ソースの言語という軸を追加します。これが言語間引用ギャップ対策の起点です。
計測の手順
- クエリセットの準備：自社領域の主要な日本語クエリ（クエリマップがあればそこから抽出）を20〜50件用意する。
- 定点観測：ChatGPT（検索あり）・Perplexity・Google AIモードなど主要エンジンに同じクエリを投げ、回答と引用元を記録する。
- 引用元の言語判定：引用された各ソースについて、言語（日本語／英語／その他）、ドメイン、一次情報か二次情報かを分類する。
- ギャップの特定：「自社が一次情報を持っているのに英語ソースが引用されたクエリ」を最優先の奪還対象としてリスト化する。
記録項目の例を示します。スプレッドシートで十分に運用できます。
| 記録項目 | 内容 | 見るべきポイント |
|---|---|---|
| クエリ | 日本語の質問文 | クエリマップとの対応 |
| エンジン | ChatGPT／Perplexity／AIモード等 | エンジン別の言語偏向の差 |
| 引用ソースの言語比率 | 日：英：その他 | 英語比率が高いクエリ群の特定 |
| 英語ソースの正体 | 一次情報か、日本情報の翻訳・要約か | 「翻訳二次情報に負けている」ケースの抽出 |
| 自社の引用有無 | 引用された／されない | 言語別Share of Modelの母数 |
この診断で見えてくる典型的なパターンは3つです。(a) 英語一次情報に負けている（グローバルな一般論のクエリ）、(b) 日本情報の英語翻訳・英語要約に負けている（日本固有のテーマなのに英語記事が引用される）、(c) そもそも検索されず、モデルの内部知識（＝英語由来）だけで回答されている。それぞれ対策の力点が変わります。(a)には英語圏での被引用獲得、(b)には日英併記と国際Schema、(c)には英語圏の情報空間へ自社情報を「学習される形で」届ける施策が対応します。
対策1——日英併記設計：日本語一次情報に「英語の入口」を付ける
最初の対策は、日本語の一次情報コンテンツに英語の入口を付けることです。ポイントは「英語サイトを別に作る」ことではなく、言語横断RAGの検索に日本語ページ自体が引っかかるようにすることです。
英語アブストラクトの併記
日本語記事の冒頭または末尾に、その記事の要点をまとめた英語アブストラクト（150〜300語程度）を併記します。学術論文の英文抄録と同じ発想です。これには2つの効果があります。
- 検索一致の入口になる：英語クエリ・英語埋め込みでの検索に対して、ページ内の英語テキストが一致点を作る。ページ全体が日本語のみの場合と比べ、言語横断検索で拾われる確率が上がる。
- 引用時の要約素材になる：AIが回答を組み立てる際、要点が凝縮された英語パラグラフは「引用しやすい形」そのもの。数字・固有名詞・結論を含めておくと引用の核になりやすい。
英語アブストラクトには、記事の結論・独自データ・一次情報であることの明示（”based on our original survey of …” など）を必ず含めます。「この日本語ページが一次情報である」と英語で宣言することが、翻訳二次情報との差別化になります。
対訳ページとhreflangの整備
引用奪還の優先度が高いコンテンツ（診断で特定した奪還対象クエリに対応する記事）については、フルの英語版ページを用意し、hreflangで日英ページを相互に関連付けます。ここで重要なのは順序です。全ページの英訳は不要で、言語別Share of Model診断で「英語ソースに負けている」と特定されたクエリに対応するページから着手します。
- 日英ページに相互のhreflangアノテーション（
ja/en）を設定し、同一コンテンツの言語違いであることを検索エンジン・AIクローラーに明示する。 - 英語版ページはURLも英語圏から参照しやすい構造（英語スラッグ）にする。
- 機械翻訳をベースにする場合も、固有名詞・数字・結論部分は人手でレビューする。引用の核になる箇所の誤訳は、引用されたときの誤情報拡散に直結する。
対策2——国際Schema設計：sameAs・inLanguageで「言語をまたいだ同一性」を宣言する
日英のコンテンツを用意しても、AIやクローラーから見て「別々のページ」に見えていては、シグナルが言語ごとに分散するだけです。構造化データで言語をまたいだ同一性と対応関係を宣言します。
使う語彙はSchema.orgの標準プロパティです。
inLanguage：各ページの言語を明示する（"ja"/"en"）。translationOfWork/workTranslation：英語版が日本語原文の翻訳であること（およびその逆の対応関係）を宣言する。「日本語が原文＝一次情報」という向きを機械可読にできるのがポイント。sameAs：組織・人物・製品のエンティティについて、英語圏の権威あるプロフィール（Wikipedia英語版、Wikidata、LinkedIn、GitHub、Crunchbaseなど）と結びつける。日本語サイトのエンティティを英語圏の知識グラフに接続する橋になる。citation/isBasedOn：独自調査・独自データに基づく記事であれば、調査レポート自体への参照を構造化し、一次情報であることを補強する。
日本語原文記事のJSON-LDの例を示します。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "（日本語記事のタイトル）",
"inLanguage": "ja",
"workTranslation": {
"@type": "Article",
"@id": "https://example.com/en/article-slug/",
"inLanguage": "en"
},
"author": {
"@type": "Organization",
"name": "（組織名）",
"sameAs": [
"https://www.wikidata.org/wiki/QXXXXXXX",
"https://en.wikipedia.org/wiki/Example_Corp",
"https://github.com/example-corp"
]
},
"isBasedOn": "https://example.com/reports/original-survey-2026/"
}英語版ページ側には逆向きのtranslationOfWorkを設定し、"@id"で日本語原文を指します。これにより「英語版はあくまで翻訳であり、原典は日本語ページ」という一次情報の所在が機械可読になります。
対策3——英語圏被引用の獲得：日本語一次情報を英語の情報空間に届ける
日英併記と国際Schemaは「見つけてもらう・正しく理解してもらう」ための施策です。しかし要因3で見たとおり、最終的に引用の当落を分けるのは英語圏での被引用・被言及シグナルです。日本語一次情報を、英語の情報空間に能動的に届けます。
- 独自データの英語プレスリリース化：調査・統計・事例など、自社にしかない一次データを英語のサマリーとして発信する。英語圏メディア・業界ニュースレターが引用すれば、そのシグナルは自社ドメインに向かう。
- 英語圏のコミュニティ・プラットフォームへの寄稿：GitHub（技術情報）、業界団体の英語資料、英語圏の専門メディアへの寄稿など、ドメイン外でも「出典として自社名・自社URLが刻まれる」場所に一次情報を置く。
- Wikidata・Wikipedia英語版のエンティティ整備：自社・自社製品のエンティティが英語圏の知識グラフに存在しなければ、sameAsで繋ぐ先もない。中立的な記述で登録・更新できる状態を整える（自作自演的な編集はガイドライン違反になるため、出典に基づく事実の整備に徹する）。
- 「日本市場の一次情報源」ポジションの確立：英語圏から見ると、日本市場・日本の制度・日本語圏の動向は情報が乏しい領域。この非対称を逆手に取り、「日本のことならこのサイトが一次情報」という被引用パターンを英語圏に作る。これは防衛戦であると同時に、英語圏クエリでの引用獲得（攻め）にも転化する。
この対策は即効性こそありませんが、要因3の構造そのものに働きかける唯一の施策です。日英併記・国際Schema（即効性のある技術施策）と並行して、四半期単位で積み上げます。
実装チェックリスト——診断から奪還までの優先順位
| フェーズ | 施策 | 対応する要因 | 目安 |
|---|---|---|---|
| 診断 | 言語別Share of Modelの定点計測（引用ソースの言語判定） | 全要因の可視化 | 初月〜継続 |
| 診断 | 奪還対象クエリのリスト化（一次情報を持つのに英語ソースに負けているもの） | 要因3 | 初月 |
| 技術 | 主要記事への英語アブストラクト併記 | 要因2 | 1〜2か月 |
| 技術 | inLanguage・sameAs・translationOfWorkの構造化データ実装 | 要因2・3 | 1〜2か月 |
| 技術 | 奪還対象ページの英語版作成＋hreflang | 要因2 | 2〜3か月 |
| 継続 | 独自データの英語発信・英語圏被引用の獲得 | 要因1・3 | 四半期単位 |
| 継続 | Wikidata・英語圏知識グラフのエンティティ整備 | 要因1・3 | 四半期単位 |
よくある質問（Q&A）
Q1. 全ページを英訳しないと効果はありませんか？
不要です。むしろ全ページ英訳は投資対効果が最も悪い選択です。まず言語別Share of Model診断で「自社が一次情報を持っているのに英語ソースが引用されているクエリ」を特定し、そのページから英語アブストラクト併記→フル英語版の順で優先度をつけて着手してください。
Q2. 英語アブストラクトを付けるだけで本当に引用されますか？
単体で引用を保証するものではありません。英語アブストラクトは言語横断検索に「引っかかる入口」を作る施策で、引用の当落は被引用シグナルや一次情報性との合わせ技で決まります。ただし、ページ全体が日本語のみの状態と比べて検索一致の機会が増えること、引用しやすい凝縮された英語パラグラフを提供できることから、費用対効果の高い最初の一手です。
Q3. 機械翻訳で英語版を量産しても大丈夫ですか？
品質管理なしの量産は推奨しません。引用の核になる数字・固有名詞・結論部分の誤訳は、AIに引用されたときに誤情報として拡散するリスクを伴います。また低品質な翻訳ページの量産は検索エンジンの品質評価も毀損します。機械翻訳をベースにする場合も、要点部分の人手レビューを必須にしてください。
Q4. 日本固有のテーマなのに海外メディアの英語記事が引用されます。なぜですか？
典型的な「翻訳二次情報への敗北」パターンです。日本語の一次情報は日本語圏にしかシグナルを持たない一方、それを要約した英語記事は英語圏全体から被リンク・被言及を集めるため、言語横断検索での評価で逆転が起きます。対策は、原典が自社であることをtranslationOfWork・isBasedOnなどで機械可読にすること、英語アブストラクトで一次情報性を英語で宣言すること、そして英語圏での被引用を自社ドメインに向けて獲得することの3点セットです。
Q5. インバウンド向けの多言語サイトはすでにあります。それとは何が違うのですか？
目的と設計が異なります。インバウンド向け多言語サイトは「外国語話者の検索・閲覧」を取りに行く攻めの施策で、英語圏クエリの回答面が戦場です。本記事の対策は「日本語クエリの回答面に入り込んでくる英語ソース」から引用を取り返す防衛戦で、日本語ページ自体の言語横断検索対応（英語アブストラクト・国際Schema）と、日本語一次情報の英語圏でのシグナル獲得が主眼です。既存の多言語サイトがあるなら、hreflang・translationOfWorkの整備でそのまま資産として活かせます。
まとめ——戦う相手は「国内競合」ではなく「英語圏ソース」
言語間引用ギャップ対策の要点は3つです。
1. 日本語クエリの回答面は、もう日本語サイトだけの戦場ではない。LLMの知識の英語偏重と言語横断RAGにより、英語圏ソースが日本語回答面の引用競合になっています。国内競合とのギャップ分析だけでは、この構造は見えません。
2. 計測に「引用ソースの言語」の軸を足す。言語別Share of Modelで、どのクエリで・どの言語のソースに・どう負けているか（英語一次情報か、翻訳二次情報か、内部知識か）を特定することが、すべての対策の起点です。
3. 技術施策と被引用獲得を並行させる。英語アブストラクト・hreflang・sameAs／translationOfWorkによる国際Schemaは数か月で実装できる即効施策、英語圏被引用の獲得とエンティティ整備は四半期単位の積み上げ施策です。両輪で、日本語一次情報が「翻訳された英語情報」に負けない状態を作ります。
翻訳コストがゼロになった世界では、情報の国境は消えますが、シグナルの国境は残ります。この非対称を放置すれば日本語の一次情報は埋没し、逆に設計すれば「日本のことならこのサイト」という英語圏でのポジションにも転化します。防衛戦から始めて、攻めに転じてください。
参考リンク
- Google検索セントラル「ページのローカライズ版について Google に知らせる（hreflang）」
- Schema.org「sameAs」
- Schema.org「inLanguage」
- Schema.org「workTranslation」
免責事項：本記事は2026年7月時点の公開情報に基づく一般的な情報提供であり、特定のAI検索エンジンにおける引用・表示を保証するものではありません。各AIサービスの検索・引用の仕組みは公開されていない部分が多く、また頻繁に変更されます。実際の施策は自社サイトの状況・計測データに照らして検討し、最新情報は各公式ドキュメントでご確認ください。
コメント