GEO / LLMO 入門：AI が答えるとき、自社サイトに引用してもらう技術

「ググる」が「ChatGPT に聞く」「Perplexity に聞く」に置き換わる時代 が、すでに来ています。Google も検索結果の上部に AI Overviews (AI Overviews) を表示するようになりました。これらに共通するのは 検索結果ページを経由せずに、AI が回答そのものを返す という構造です。

ここで起きる変化は決定的です: AI の回答に 自社サイトが引用されなければ、流入そのものが発生しない。従来の SEO（Search Engine Optimization） で「2 ページ目に表示される」と「全く表示されない」が同じ意味だったのと同じ構造が、AI 検索でも起きています。

この記事では、新しい最適化領域である LLMO（Large Language Model Optimization） (LLM Optimization) / GEO（Generative Engine Optimization） (Generative Engine Optimization) について、①概要 → ②利点と欠点 → ③対策方法 → ④検証方法 の 4 部構成でまとめます。

1. LLMO / GEO とは何か

用語の整理

LLMO と GEO はほぼ同義語 です。本記事では包括的な「LLMO / GEO」表記を使います。実務的な対策内容は同じです。

なぜ今やるべきか

• Google が AI Overviews を主要市場に展開: 検索結果の上部を AI 回答が占有するようになり、青いリンクのクリック率が低下傾向
• ChatGPT に検索機能が統合: ChatGPT search / Perplexity が「ググる」の代替として定着しつつある
• Z世代・若年層は AI で情報収集: 「Google で調べる」より先に「ChatGPT に聞く」が主流化しつつある
• 競合がまだ手をつけていない: SEO は競争激化しているが、LLMO は まだ「やっている人が少ない」フェーズ。先行者利益が大きい
• コストが SEO より低い: SEO は外部リンク獲得・コンテンツ大量生産の競争だが、LLMO は 構造化データと信頼性シグナル で差がつく

LLM が情報を引用する 2 つの経路

対策を考える前に、生成 AI がどうやって自社サイトを引用するかを理解しておく必要があります。経路は大きく 2 つです。

2. LLMO / GEO の利点と欠点

利点（やる価値）

1. 1新しい流入経路の確保: ChatGPT / Perplexity 経由の流入は今後数年で大きく増える見通し。引用元として表示される価値は大きい
2. 2ブランド権威性の向上: 「AI に聞いたら御社の名前が出てきました」は強力な信頼シグナル。営業の場面でも効く
3. 3SEO との相乗効果: 構造化データ / 著者情報 / 引用しやすい構造は、Google 検索の順位にも好影響
4. 4競合がまだ少ない: 多くの企業が手を付けていないので、先行投資の効率が良い
5. 5改修コストが低い: ゼロからの再設計ではなく、既存サイトに 追加施策 として実装できる
6. 6測定可能: 「どの AI が、どのクエリで、自社を引用したか」を一定の方法で測定できる

欠点・リスク（やる前に認識すべきこと）

1. 1直接コンバージョンが測りにくい: AI が回答に引用 → ユーザーが企業名を覚えて後日検索、のような 間接経路 が多い。ROI 算定が難しい
2. 2「クリックが減る」可能性: AI が要約で回答してくれると、ユーザーが元サイトに来ない (= ゼロクリック)。ブランド認知は上がるが PV は減ることも
3. 3模倣されやすい: 構造化データ・llms.txt 等は公開情報なので、競合に模倣される速度も速い
4. 4LLM の挙動はブラックボックス: 「なぜ引用されたか / されなかったか」の理由が分からない。仮説検証ベースの試行錯誤になる
5. 5情報の信頼性リスク: AI が要約する際に、文脈を切り取って 誤った形で引用 することがある。ブランド毀損リスクの認識が必要
6. 6標準が流動的: llms.txt は事実上の標準だが正式仕様ではない、Schema.org も AI 利用は確立していない、など仕様変更の可能性

3. 対策方法 — 4 つの軸

対策は大きく 4 つの軸に分けられます。優先度順に並べました。

A. 技術シグナル — 3〜5 日で実装できる

A-1. robots.txt で AI クローラを明示的に allow

Web クローラ (Googlebot / Bingbot 等) のためのファイルが robots.txt ですが、現代は AI クローラを 個別の User-Agent 名 で明示することが推奨されます。

User-agent: *Allow: /Disallow: /api/
# OpenAIUser-agent: GPTBotAllow: /User-agent: OAI-SearchBotAllow: /User-agent: ChatGPT-UserAllow: /
# AnthropicUser-agent: ClaudeBotAllow: /User-agent: Claude-WebAllow: /
# PerplexityUser-agent: PerplexityBotAllow: /User-agent: Perplexity-UserAllow: /
# Google Gemini (※ Googlebot とは別 UA)User-agent: Google-ExtendedAllow: /
# Common Crawl (LLM の主要学習データ源)User-agent: CCBotAllow: /
# Apple IntelligenceUser-agent: Applebot-ExtendedAllow: /
Sitemap: https://example.com/sitemap.xml

A-2. llms.txt — LLM 向けの「サイトマップ」

llms.txt は 2024 年に Jeremy Howard が提案した、LLM 向けに自サイトの構造と要約を Markdown で提供する 規約です。robots.txt の LLM 版。サイトルートに `/llms.txt` を置きます。

# 会社名
> 1〜3 行の要約。何をやっている会社か、誰向けか、何が強みか。
会社の説明や背景を任意で 1 段落。
## 主要ページ
- [サービス](https://example.com/services): 提供サービスの一覧- [事例](https://example.com/works): 過去の実装事例- [About](https://example.com/about): 会社情報・代表略歴
## ブログ・ナレッジ
- [シリーズ A](https://example.com/blog/a): A についての連載- [シリーズ B](https://example.com/blog/b): B についての連載
## Optional
- [プライバシー](https://example.com/privacy)- [問い合わせ](https://example.com/contact)

A-3. 構造化データ (Schema.org + JSON-LD（JSON for Linked Data）)

Schema.org の語彙を JSON-LD 形式で HTML に埋め込む と、検索エンジン・LLM がページの種別・著者・日付・関連エンティティを正確に理解できます。これは SEO（Search Engine Optimization） でも基本ですが、LLMO でも有効です。

• Article: 記事ページに必須。`headline` / `datePublished` / `dateModified` / `author` / `publisher` / `keywords` 等
• Person: 著者情報。`name` / `jobTitle` / `description` / `url` / `sameAs` (SNS リンク) 等
• Organization: 会社情報。`name` / `legalName` / `url` / `logo` / `founder` / `knowsAbout` / `areaServed` 等
• FAQPage: Q&A コンテンツに有効。LLM がそのまま回答に使える形式なので、引用率が上がる
• HowTo: 手順記事に有効。ステップごとに分割された構造が AI に理解されやすい
• BreadcrumbList: パンくずリスト。サイト構造の把握を助ける

<script type="application/ld+json">{  "@context": "https://schema.org",  "@type": "Article",  "headline": "記事タイトル",  "description": "記事の要約",  "datePublished": "2026-05-09",  "dateModified": "2026-05-09",  "author": {    "@type": "Person",    "name": "著者名",    "url": "https://example.com/about",    "jobTitle": "代表"  },  "publisher": {    "@type": "Organization",    "name": "会社名",    "logo": {      "@type": "ImageObject",      "url": "https://example.com/logo.png"    }  }}</script>

A-4. sitemap.xml と canonical URL

• sitemap.xml: 全公開 URL を一覧化。`lastmod` を 記事の更新日 に揃えると、AI クローラが更新を検知しやすい
• canonical URL: 同じ内容が複数 URL で公開されている場合、`<link rel="canonical">` で正規 URL を指定。重複コンテンツの混乱を防ぐ
• HTTPS / モバイル対応: HTTPS は必須、モバイル表示は Google Search Console でエラーが出ないよう確認

B. コンテンツ構造 — 「引用しやすい書き方」

LLM が回答生成時にサイトを参照する際、抽出しやすい構造で書かれているコンテンツが優先的に引用 されます。

1. 1結論を最初に書く: AI は冒頭の数百文字を要約候補として強く重視する。「結論 → 理由 → 詳細」の構造で書く
2. 2見出しを階層化: h1 → h2 → h3 を論理的に。LLM は見出し階層を解析して情報を構造化する
3. 3箇条書き・番号付きリスト: 機械的に抽出しやすい。「対策は 5 つあります: 1. ... 2. ...」のような明示的リスト
4. 4表 (table): 比較情報は表で書く。LLM は表を構造化データとして扱える
5. 5Q&A 形式の活用: 「Q. ○○とは何ですか A. ...」の形式は AI 検索エンジンが直接回答に使える
6. 6具体的な数値を明記: 「効果が大きい」より「3 ヶ月で 30% 改善」。数値は LLM の引用基準として強く効く
7. 7用語の定義を最初に: 「LLMO（Large Language Model Optimization） とは ... のことです」のような冒頭定義。AI が「○○とは何か」を聞かれたときの引用候補になる
8. 8情報の出典を明記: 「Princeton 大学の 2023 年論文によると」のような明確な出典は、LLM が「信頼できるソース」と判定する一因

B-1. FAQPage 構造化データの活用

Q&A セクションがある記事は、必ず FAQPage 構造化データ を JSON-LD で埋め込みます。AI 検索エンジンはこれを直接回答候補として使います。

<script type="application/ld+json">{  "@context": "https://schema.org",  "@type": "FAQPage",  "mainEntity": [    {      "@type": "Question",      "name": "LLMO とは何ですか?",      "acceptedAnswer": {        "@type": "Answer",        "text": "Large Language Model Optimization の略で、生成 AI に自社サイトを引用してもらいやすくするための施策の総称です。"      }    },    {      "@type": "Question",      "name": "SEO と LLMO の違いは?",      "acceptedAnswer": {        "@type": "Answer",        "text": "SEO は Google 検索結果の順位を狙うのに対し、LLMO は ChatGPT や Perplexity 等の生成 AI が回答するときの引用元になることを狙います。"      }    }  ]}</script>

C. 著者シグナル — E-E-A-T（Experience, Expertise, Authoritativeness, Trust） を満たす

Google が品質評価ガイドラインで定めた E-E-A-T（Experience, Expertise, Authoritativeness, Trust） (Experience / Expertise / Authoritativeness / Trust) は、SEO（Search Engine Optimization） だけでなく LLMO でも引用元選定の基準として効きます。AI は「この情報は誰が書いたのか」を強く評価します。

• 著者ページ (Person) を作る: 経歴・実績・専門分野・資格・SNS リンクを集約。Schema.org Person で構造化
• 実体験を書く: 「○○を実際に運用して分かった ...」のような一次情報は、AI から見て価値が高い
• 専門分野を絞る: あらゆる分野に手を出すより、特定領域で 深い コンテンツを揃える方が権威性が出る
• 最終更新日を明記: 古い情報は AI から信頼度が低く扱われる。古い記事は更新・改訂日付を明示
• 矛盾しない情報発信: SNS と Web サイトと外部寄稿で言うことが食い違うと、AI が信頼できないと判定する材料になる

D. 外部シグナル — 「他から言及される」状態を作る

AI は 「他のサイトでもこのドメインが言及されているか」 を信頼性指標の 1 つとして使います。これは SEO（Search Engine Optimization） の被リンク評価に近いですが、リンクである必要はなく、ブランド名のメンション だけでも一定の効果があります。

• Wikipedia への記載 (該当領域で著名な企業・人物の場合): AI が信頼性ソースとして強く参照する
• 業界メディア・著名ブログでの言及: 自社のメディア露出を増やす、寄稿する、インタビューを受ける
• SNS でのブランドメンション: 単に投稿数が多いだけでなく、「他の人が自社を語っている」状態を作る
• Qiita / Zenn / note 等への投稿: 同じ内容を複数の信頼性の高いプラットフォームに置くと、AI が「複数のソースで一致する情報」と判定する
• 学会発表・論文・登壇: 公的な裏付けは AI から見て強いシグナル

4. 検証方法 — 効果をどう測るか

LLMO は「やったら何が起きたか」が見えにくい領域なので、測定の仕組みを最初に作っておく のが重要です。

4-1. AI クローラのアクセスログを取る

サーバーログ (Vercel / Cloudflare / Nginx) を分析し、AI クローラの User-Agent ごとの訪問回数・ページを集計します。

# よく見る AI クローラ UA を grep で集計zcat /var/log/nginx/access.log.*.gz | grep -oE 'GPTBot|ClaudeBot|PerplexityBot|Google-Extended|CCBot|Bytespider|Applebot-Extended' | sort | uniq -c | sort -rn
# 結果例:#  3421 GPTBot#  1840 ClaudeBot#  1203 PerplexityBot#   890 Google-Extended#   542 CCBot

4-2. AI 検索エンジンに直接聞く

自社が引用される対象クエリで実際に AI に質問 し、引用元として表示されるかを定期的にチェックします。

1. 1ターゲットクエリの一覧を作る: 「○○ サービス おすすめ」「○○ 比較」「○○ とは」など、自社が引用されたいクエリを 20〜50 件
2. 2各 AI で実際に検索: ChatGPT search / Perplexity / Claude / Google AI Overview / Bing Copilot で同じクエリを試す
3. 3引用元 URL を記録: 自社が引用されているか、競合が引用されているかを月次で記録
4. 4引用順位を追う: 「引用 5 件中、自社は何番目に出てくるか」

4-3. リファラ流入の測定

AI 検索経由の流入は通常のアクセス解析でも一部測定可能です。GA4 / Plausible 等で リファラ にこれらのドメインが含まれるかを見ます。

4-4. ブランド名の指名検索の推移を見る

「会社名 + 何か」での検索数の推移 は、AI 検索の間接的な効果指標として使えます。「AI で見て知った → 後で会社名で検索した」という経路が増えていれば、LLMO が効いている証拠です。

• Google Search Console: 「クエリ」フィルタで自社ブランド名を含むクエリの推移を見る
• Google Trends: 自社ブランド名の検索トレンドの推移
• 月次レポート化: 経営層に「ブランド指名検索 +XX% / AI 経由流入 ○件」のような形で報告できる

5. ふくふく推奨：実装ロードマップ

1. 1Week 1: アクセスログから現状の AI クローラ訪問数を計測 → 現在地を把握
2. 2Week 1-2: robots.txt に AI クローラの allow を明示、llms.txt を作成、Article schema (JSON-LD) を全記事に追加
3. 3Week 3-4: ターゲットクエリ 20-50 件を定義 → 各 AI で実際に試してベースライン記録
4. 4Month 2: コンテンツ改修 (結論先出し / Q&A 形式 / 数値明記)。FAQPage schema を Q&A 記事に追加
5. 5Month 3: 著者ページ強化 (Person schema、経歴、実績、SNS 連携)、E-E-A-T を満たす記述に改修
6. 6Month 3-6: 外部シグナル獲得 (寄稿、登壇、Wikipedia 記載検討)、月次でターゲットクエリの引用率を測定
7. 7継続: ターゲットクエリの拡張、ツール導入 (Profound / Otterly.ai 等)、業界別の対策強化

6. 関連記事と次の話

• AI for Business シリーズ — 非エンジニア向け AI 活用全般
• Engineering Dashboards シリーズ — 開発組織のメトリクス可視化
• データの宝石箱 — 公的オープンデータの活用

本シリーズでは、続編として 「llms.txt の実装パターン詳細」、「FAQPage / HowTo schema の使い分け」、「業界別 LLMO 対策 (B2B SaaS / EC / メディア)」、「Profound / Otterly.ai 等の LLMO ツール比較」 などを、読者リアクションに応じて随時追加していきます。

ふくふくでは LLMO / GEO の導入を 3 ヶ月並走 で支援する形を取っています。技術実装 (robots.txt / llms.txt / 構造化データ) を最初の 2 週間で固め、その後はコンテンツ改修と効果測定の運用に伴走します。お問い合わせは Contact より。