Google の AI 検索に特別なファイルや schema は必要ありません。llms.txt の採用や FAQPage の追加による引用率向上を保証する説明を訂正しました。Google の AI 最適化ガイド を基準にし、他サービスの挙動にはこの説明をそのまま当てはめません。
経営層 / マーケ / Web 担当 / SEO 担当 / コーポレートサイトを持つ全ての事業者向け。技術的な実装手順も含むが、判断は経営・マーケ視点で書いています。
「ググる」が「ChatGPT に聞く」「Perplexity に聞く」に置き換わる時代 が、すでに来ています。Google も検索結果の上部に (AI Overviews) を表示するようになりました。これらに共通するのは 検索結果ページを経由せずに、AI が回答そのものを返す という構造です。
AI の回答に参照リンクが表示されることは、サイトを知ってもらう入口の一つです。ただし、引用されないことは検索流入全体の消失を意味せず、表示されても訪問につながるとは限りません。表示・訪問・訪問後の行動を分けて確認します。
この記事では、新しい最適化領域である (LLM Optimization) / (Generative Engine Optimization) について、①概要 → ②利点と欠点 → ③対策方法 → ④検証方法 の 4 部構成でまとめます。
1. LLMO / GEO とは何か
用語の整理
| 用語 | 対象 | 起源 |
|---|---|---|
| SEO | Google / Bing 等の検索結果ページでの順位 | 1990 年代後半〜 |
| LLMO | ChatGPT / Claude / Gemini 等の生成 AI が回答するときの引用源 | 2023〜2024 年に登場 |
| GEO | Perplexity / ChatGPT search / AI Overviews 等の生成 AI 検索エンジン | Princeton 大学 2023 年論文で提唱 |
| AEO | Answer Engine Optimization (Alexa / Siri 等の音声回答も含む広義) | 2017 年頃〜 |
LLMO と GEO はほぼ同義語 です。本記事では包括的な「LLMO / GEO」表記を使います。実務的な対策内容は同じです。
なぜ今やるべきか
- Google が AI Overviews を主要市場に展開: 検索結果の上部を AI 回答が占有するようになり、青いリンクのクリック率が低下傾向
- ChatGPT に検索機能が統合: ChatGPT search / Perplexity が「ググる」の代替として定着しつつある
- Z世代・若年層は AI で情報収集: 「Google で調べる」より先に「ChatGPT に聞く」が主流化しつつある
- 競合がまだ手をつけていない: SEO は競争激化しているが、LLMO は まだ「やっている人が少ない」フェーズ。先行者利益が大きい
- 既存 SEO の点検から始める: Google は通常の検索の仕組みを AI 機能でも利用します。専用の追加施策が通常の SEO より安く効くとは限りません
LLM が情報を引用する 2 つの経路
対策を考える前に、生成 AI がどうやって自社サイトを引用するかを理解しておく必要があります。経路は大きく 2 つです。
| 経路 | 仕組み | 対策の効き方 |
|---|---|---|
| A. 学習時に取り込まれる | Common Crawl / 各社の Web クロールで収集された情報がモデルパラメータに焼き込まれる | 数年スパンで効く。継続的な情報発信と権威性が必要 |
| B. 推論時に検索して取り込まれる | ChatGPT search / Perplexity / AI Overview 等が回答生成時にリアルタイムで Web 検索 → 結果を要約 | 数日〜数週間で効く。SEO と直結 |
経路 A (学習データ取り込み) は予測も検証もしにくく、コスト対効果が読めません。一方、経路 B (推論時検索) は SEO の延長線上 で対策でき、効果も比較的早く見えます。本記事の対策は経路 B 中心です。
2. LLMO / GEO の利点と欠点
利点（やる価値）
- 1新しい流入経路の確保: ChatGPT / Perplexity 経由の流入は今後数年で大きく増える見通し。引用元として表示される価値は大きい
- 2ブランド権威性の向上: 「AI に聞いたら御社の名前が出てきました」は強力な信頼シグナル。営業の場面でも効く
- 3既存 SEO と共通する作業: クロール可能なページ、内部リンク、役立つ本文、正確な著者情報を整備する。各要素を追加しただけで順位が上がるとは限らない
- 4競合がまだ少ない: 多くの企業が手を付けていないので、先行投資の効率が良い
- 5改修コストが低い: ゼロからの再設計ではなく、既存サイトに 追加施策 として実装できる
- 6測定可能: 「どの AI が、どのクエリで、自社を引用したか」を一定の方法で測定できる
欠点・リスク（やる前に認識すべきこと）
- 1直接コンバージョンが測りにくい: AI が回答に引用 → ユーザーが企業名を覚えて後日検索、のような 間接経路 が多い。ROI 算定が難しい
- 2「クリックが減る」可能性: AI が要約で回答してくれると、ユーザーが元サイトに来ない (= ゼロクリック)。ブランド認知は上がるが PV は減ることも
- 3模倣されやすい: 構造化データ・llms.txt 等は公開情報なので、競合に模倣される速度も速い
- 4LLM の挙動はブラックボックス: 「なぜ引用されたか / されなかったか」の理由が分からない。仮説検証ベースの試行錯誤になる
- 5情報の信頼性リスク: AI が要約する際に、文脈を切り取って 誤った形で引用 することがある。ブランド毀損リスクの認識が必要
- 6サービスごとに仕様が違う: llms.txt は提案であり、採用状況と検索結果への効果は別問題。Google は検索で使用しないと明示している
検索流入の重要度、現在の課題、利用できる工数を見て優先順位を決めます。Google の AI 検索で必要なのは通常の SEO の基礎です。有料情報などへのアクセス制御と、検索掲載・学習への利用設定も区別して判断します。
3. 対策方法 — 4 つの軸
対策は大きく 4 つの軸に分けられます。優先度順に並べました。
| 軸 | 点検するもの | 作業の進め方 | 確認する結果 |
|---|---|---|---|
| A. 技術面 | robots.txt / 内部リンク / sitemap / 本文と一致する構造化データ | クロール状況を点検 | 取得・インデックス状況 |
| B. 本文 | 検索意図への回答 / 見出し / 出典 / 限界の説明 | 不足する説明を改稿 | 記事別の表示と訪問後の行動 |
| C. 著者情報 | 著者 / 経歴 / 確認できる実績 | 実態と照合 | 読者が確認できる情報 |
| D. 外部での紹介 | 他サイトの参照リンクや紹介内容 | 実在する紹介を把握 | 参照元別の訪問 |
A. 技術面 — 取得できるページを整える
A-1. robots.txt の設定を用途別に確認する
はクローラに取得ルールを伝えます。Google の AI 検索は Googlebot の制御対象です。Google-Extended は別用途の制御トークンで、独立した HTTP User-Agent はなく、Google 検索の掲載や順位に影響しません。Google のクローラ仕様 を確認してください。
User-agent: *Allow: /Disallow: /api/
Sitemap: https://example.com/sitemap.xmlNext.js App Router なら src/app/robots.ts で生成できます。公開後は実際の robots.txt とホスティング側の制限を確認します。取得を許可することは掲載や引用の保証ではありません。非公開情報は認証などで保護します。
A-2. llms.txt — LLM 向けの「サイトマップ」
は概要と参照先を Markdown で案内するllms.txt の提案です。robots.txt の取得ルールとは役割が異なります。Google Search は使用しないと明記しているため、Google 向けの順位施策には位置づけません。利用する他サービスやエージェントがある場合に、任意の索引として検討します。
# 会社名
> 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)全文を結合したファイルも、利用先と更新方法が決まっている場合の選択肢です。Google の AI 検索には必要ありません。取得ログがあっても、回答への採用や流入が増えたことの証明にはなりません。
A-3. 構造化データ ( + )
Schema.org の語彙を JSON-LD 形式で HTML に埋め込む と、記事・著者・日付などを機械可読な形で記述できます。Google の AI 検索に必須の schema はありません。本文と一致させ、対応する検索機能の要件を満たすために使います。Google の構造化データ方針
- Article: 記事の情報を記述。
headline/datePublished/dateModified/author等。検索掲載や AI 引用の必須条件ではない - Person: 著者情報。
name/jobTitle/description/url/sameAs(SNS リンク) 等 - Organization: 会社情報。
name/legalName/url/logo/founder/knowsAbout/areaServed等 - FAQPage: 本文に表示する質問と回答を記述。Google の FAQ リッチリザルトは終了しており、引用率向上も保証しない
- HowTo: 手順を記述する語彙。Google の HowTo リッチリザルトは終了している
- 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. コンテンツ構造 — 「引用しやすい書き方」
見出しや表は、読者が必要な情報を見つけるために使います。Google は AI 向けに特別な書き方や細かな分割を行う必要はないと説明しています。以下は読みやすさの工夫であり、引用の優先条件ではありません。
- 1結論を最初に書く: 読者が答えを見つけやすいように、必要に応じて「結論 → 理由 → 詳細」の順にする
- 2見出しを階層化: h1 → h2 → h3 を論理的に。LLM は見出し階層を解析して情報を構造化する
- 3箇条書き・番号付きリスト: 機械的に抽出しやすい。「対策は 5 つあります: 1. ... 2. ...」のような明示的リスト
- 4表 (table): 比較情報は表で書く。LLM は表を構造化データとして扱える
- 5Q&A 形式の活用: 「Q. ○○とは何ですか A. ...」の形式は AI 検索エンジンが直接回答に使える
- 6数値には条件と出典を添える: 実測値・計算例・仮定を分け、引用されることを目的に数字を作らない
- 7用語の定義を最初に: 「LLMO とは ... のことです」のような冒頭定義。AI が「○○とは何か」を聞かれたときの引用候補になる
- 8情報の出典を明記: 「Princeton 大学の 2023 年論文によると」のような明確な出典は、LLM が「信頼できるソース」と判定する一因
B-1. FAQPage 構造化データの活用
FAQPage を使う場合は、同じ質問と回答を本文にも表示します。Google の FAQ リッチリザルトは終了しており、公式更新履歴で案内されています。次の例は語彙の記述方法で、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) の観点で、誰が書き、何に基づく情報なのかを読者が確認できるようにします。Person を追加すれば AI が優先的に引用するという意味ではありません。
- 著者ページ (Person) を作る: 経歴・実績・専門分野・資格・SNS リンクを集約。Schema.org Person で構造化
- 実体験を書く: 「○○を実際に運用して分かった ...」のような一次情報は、AI から見て価値が高い
- 専門分野を絞る: あらゆる分野に手を出すより、特定領域で 深い コンテンツを揃える方が権威性が出る
- 最終更新日を明記: 古い情報は AI から信頼度が低く扱われる。古い記事は更新・改訂日付を明示
- 矛盾しない情報発信: SNS と Web サイトと外部寄稿で言うことが食い違うと、AI が信頼できないと判定する材料になる
D. 外部シグナル — 「他から言及される」状態を作る
外部で紹介された内容や参照リンクは、読者に届く経路として確認します。Google は AI 向けに不自然な言及を増やす手法を推奨していません。言及の数だけで引用率が上がるとは扱いません。
- Wikipedia への記載 (該当領域で著名な企業・人物の場合): AI が信頼性ソースとして強く参照する
- 業界メディア・著名ブログでの言及: 自社のメディア露出を増やす、寄稿する、インタビューを受ける
- SNS でのブランドメンション: 単に投稿数が多いだけでなく、「他の人が自社を語っている」状態を作る
- Qiita / Zenn / note 等への投稿: 媒体の読者に合わせた説明と元記事への導線を用意する。同じ文章の複製を独立した裏付けとは扱わない
- 学会発表・論文・登壇: 公的な裏付けは AI から見て強いシグナル
4. 検証方法 — 効果をどう測るか
LLMO は「やったら何が起きたか」が見えにくい領域なので、測定の仕組みを最初に作っておく のが重要です。
4-1. AI クローラのアクセスログを取る
サーバーログで、実際の HTTP User-Agent ごとの取得回数とページを確認します。これはクロールの観測であり、AI 回答での引用数ではありません。Google-Extended は HTTP User-Agent ではないため、この方法で独立したアクセス数を数えることはできません。
# よく見る AI クローラ UA を grep で集計zcat /var/log/nginx/access.log.*.gz | grep -oE 'GPTBot|ClaudeBot|PerplexityBot|CCBot|Bytespider' | sort | uniq -c | sort -rn
# 結果例:# 3421 GPTBot# 1840 ClaudeBot# 1203 PerplexityBot# 542 CCBotCloudflare は Analytics → Bots → 「AI Bots」セクションで GPTBot / ClaudeBot / PerplexityBot 等の訪問回数をグラフで表示できます。Vercel は Logs から User-Agent でフィルタ。クラウド側で測定機能が増えてきています。
4-2. AI 検索エンジンに直接聞く
自社が引用される対象クエリで実際に AI に質問 し、引用元として表示されるかを定期的にチェックします。
- 1ターゲットクエリの一覧を作る: 「○○ サービス おすすめ」「○○ 比較」「○○ とは」など、自社が引用されたいクエリを 20〜50 件
- 2各 AI で実際に検索: ChatGPT search / Perplexity / Claude / Google AI Overview / Bing Copilot で同じクエリを試す
- 3引用元 URL を記録: 自社が引用されているか、競合が引用されているかを月次で記録
- 4引用順位を追う: 「引用 5 件中、自社は何番目に出てくるか」
Profound / Otterly.ai / Peec AI のような LLMO 専用の SaaS が登場しており、複数の AI に対するクエリ実行と引用追跡を自動化できます。手動で月次運用するか、ツールに頼るかは、対象クエリ数と予算次第。
4-3. リファラ流入の測定
AI 検索経由の流入は通常のアクセス解析でも一部測定可能です。GA4 / Plausible 等で リファラ にこれらのドメインが含まれるかを見ます。
| AI 検索エンジン | リファラに現れるドメイン例 |
|---|---|
| ChatGPT | chat.openai.com / chatgpt.com |
| Perplexity | perplexity.ai |
| Bing Copilot | bing.com (Copilot 経由か通常検索かは判別困難) |
| Google AI Overview | google.com (AI Overview からのクリックか通常検索かはほぼ判別不可) |
| Claude | 通常はリファラなし (Claude.ai 内ブラウザで開く場合のみ) |
4-4. ブランド名の指名検索の推移を見る
「会社名 + 何か」での検索数の推移 も確認できます。ただし広告・紹介・広報などの影響が混ざるため、増加だけで AI 検索施策の効果とは判断しません。Google の AI 検索での表示は Generative AI performance report で確認し、Web 検索全体に重ねて加算しないようにします。
- Google Search Console: 「クエリ」フィルタで自社ブランド名を含むクエリの推移を見る
- Google Trends: 自社ブランド名の検索トレンドの推移
- 月次レポート化: 経営層に「ブランド指名検索 +XX% / AI 経由流入 ○件」のような形で報告できる
5. ふくふく推奨：実装ロードマップ
- 1Week 1: アクセスログから現状の AI クローラ訪問数を計測 → 現在地を把握
- 2Week 1-2: robots.txt・内部リンク・sitemap・本文の取得を点検。構造化データを本文と照合し、llms.txt は利用先がある場合だけ検討
- 3Week 3-4: ターゲットクエリ 20-50 件を定義 → 各 AI で実際に試してベースライン記録
- 4Month 2: コンテンツ改修 (疑問への回答 / 出典 / 説明の不足)。FAQ は読者に役立つ場合に本文へ追加し、schema だけに情報を置かない
- 5Month 3: 著者ページ強化 (Person schema、経歴、実績、SNS 連携)、E-E-A-T を満たす記述に改修
- 6Month 3-6: 外部シグナル獲得 (寄稿、登壇、Wikipedia 記載検討)、月次でターゲットクエリの引用率を測定
- 7継続: ターゲットクエリの拡張、ツール導入 (Profound / Otterly.ai 等)、業界別の対策強化
6. 関連記事と次の話
- AI for Business シリーズ — 非エンジニア向け AI 活用全般
- Engineering Dashboards シリーズ — 開発組織のメトリクス可視化
- データの宝石箱 — 公的オープンデータの活用
続く記事では、llms.txt の実装、構造化データの使い方、業界別のLLMO対策、LLMOツールの比較を詳しく扱っています。まずは、サイトに配置するファイルを整えるところから進めます。
ふくふくでは LLMO / GEO の導入を 3 ヶ月並走 で支援する形を取っています。クロール・記事の構成・計測を確認し、コンテンツ改修と効果測定の運用に伴走します。お問い合わせは Contact より。