トレンドまとめ
AI検索に引用されないのは、SEO不足ではなく「回答単位」の欠如だ
AIが自社ページを引用しないのは、たいていSEOが足りないからではない。前後の文脈なしに一段落だけ切り出しても意味が壊れない「回答単位」に、本文がなっていないからだ。
自社ページがAI検索に参照されないと気づいたとき、多くの企業はまずllms.txtやAI向けのschemaを疑う。しかし本文が回答単位になっていなければ、案内板をどれだけ整えても、案内する中身がない。この記事は、AI検索対策を「本文→構造化データ→llms.txt」という整える順番の問題として扱う。なお、市場シェアやCTRのような変動の大きい数値速報は扱わない。対象は、参照されやすい情報設計とその運用手順だけだ。
私がこの順番にこだわる理由
私は、AI検索最適化の大半は新しい略語を追いかける作業ではなく、「本文を回答単位に直す作業」だと考えている。多くの企業はllms.txtやAI向けschemaから着手するが、それは順番が逆だ。
nexaflow.io自身、このブログの実装は本文→schema→llms.txtの順で整えている。記事ごとのArticle構造化データ(著者名・公開日・更新日)はページテンプレート側で全記事に自動付与し、llms.txtはサイト概要と主要ページの案内、引用ポリシーを載せた案内板として最後に薄く置いてある。補助ファイルを厚くする前に、本文を回答単位にする方を先にやっている、という立場からこの記事を書いている。
ただし、境界は明確にしておきたい。「この順番で整えれば引用が増える」とまでは言い切らない。引用の因果は私の手元でもまだ検証中で、確実に言えるのは、引用率より先にcoverage(後で定義する)が崩れている、というnexaflow.io自身での適用範囲までだ。それが覆るデータが出れば、この記事も朝令暮改する。
使う前に定義しておきたい二つの言葉
この記事は「回答単位」と「coverage」という2つの言葉を軸に進む。使う前に定義を置く。
回答単位
見出し直下で結論が完結し、1つの見出しに1つの質問と1つの答えが対応していて、前後の文脈なしにその段落だけを切り出しても意味が壊れないブロックを指す。次の形になっているかで、機械的に判定できる。
- 見出し直下で結論を先に書いている
- 定義・手順・比較・留意点を1つの塊に混ぜていない
- 長い導入がなく、最初の2〜3文で言いたいことが分かる
- 表・箇条書き・FAQ形式で、単位が視覚的にも分かれている
この定義がないと、「本文を直す」は精神論で終わる。回答単位になっているかどうかは、段落ごとにチェックできる話にしておきたい。
coverage(網羅度)
自社が答えるべき重要な質問のうち、結論・手順・FAQ・著者・更新日が揃ったページが存在する割合を指す。以後は単にcoverageと書く。
coverageを先に定義しておくと、「引用されたかどうか」より先に見るべき指標が何かが決まる。coverageが低い状態で引用率だけ追っても、何を直せば改善するのか分からない。
全体像:「見つけられる」と「回答として取り出される」は別レイヤーだ
AI検索最適化の全体像
「SEOは終わったのか」という問いは雑だ。実務では次の2段階に分けたほうが正確になる。
- 見つけられること: 検索エンジンやクローラーがページを発見し、理解できること
- 回答として取り出されること: AIがそのページから回答単位を取り出せること
前者は従来SEOの守備範囲で、後者がGEO・AEO・LLMOと呼ばれている領域だ。GEOは生成型の検索結果で参照されやすくすること、AEOは質問への直接回答として採用されやすくすること、LLMOはLLM全般が理解・再利用しやすい状態を作ることを指すが、実務でやる作業は「定義・手順・比較・FAQを回答単位で置く」でほぼ共通する。呼び方を細かく分けて覚えるより、SEOの上に回答単位を積み増す一つの作業として運用したほうが迷いが少ない。
| 観点 | SEOの土台 | AI検索向けに追加で意識すること |
|---|---|---|
| 発見 | URL、内部リンク、サイトマップ、canonical | 公開範囲とクロール方針を意図して決める |
| 理解 | 見出し、本文、title、meta description | 定義・手順・FAQを回答単位で分ける |
| 信頼 | 著者、組織、更新日、引用元 | どの主張が自社知見で、どれが一次情報かを明示する |
| 再利用 | 段落構造、画像alt、schema | 箇条書き、比較表、FAQ、要点サマリーを置く |
SEOを捨ててAI検索最適化に乗り換えるのではない。SEOで整えてきた土台の上に、回答単位を増やす順番の話だ。
本文 → 構造化 → llms.txtという順番でしか、労力は積み上がらない
ここが中核の主張だ。優先順位を逆にする、つまりllms.txtやschemaから着手すると、なぜ労力が空回りするのか。理由は単純で、補助ファイルは本文を案内する道具でしかなく、案内する中身——回答単位になった本文——がなければ、案内板をどれだけ整えても指し示す先が空だからだ。
schemaは著者・公開日・更新日というページの責任範囲を機械可読な形で示すが、本文自体が結論を先送りにした長い導入文のままなら、示した責任範囲に中身が伴わない。llms.txtは主要ページへの案内板として機能するが、案内された先のページが定義・手順・比較・留意点を1つの段落に混ぜたままなら、AIはそこから回答単位を取り出せない。
だから作業の順番は次のようになる。
- まず本文を回答単位の形に直す。定義を1段落で説明する、手順を番号付きリストで並べる、比較軸を表で分ける、FAQを独立見出しにする、留意点を本文中に明示する。
- 次にschemaとメタ情報で、誰が書き、いつ公開し、いつ見直したかを機械可読にする。
- 最後に
llms.txtやサイトマップで、優先的に見てほしい公開URLを案内板として示す。
なお、この順番に着手する前に、そもそもどのページをAIに読ませたいかは決めておく必要がある。公開ページだけを対象にするのか、価格やFAQ、資料請求導線をどう扱うのか、robots.txtや認証設定が意図せず遮断していないかは、本文を直す前に確認しておくべき前提だ。
各層をどう置くか.io自身の実装から
この順番を、nexaflow.io自身のブログでどう実装しているかを書く。
schemaとメタ情報については、記事ごとに著者名・公開日・更新日を持つArticle構造化データと、パンくずの構造化データを、ページテンプレート側で全記事に自動付与している。個々の記事で手作業を増やさずに、著者・公開日・更新日という責任範囲を機械可読にする、という設計だ。サイトマップも、各記事の公開日・更新日をもとに自動生成している。
llms.txtは、サイト概要、主要ページの案内(トップ、サービス一覧とサービス別ページ、価格、ブログ、事例、会社概要など)、そして「要約や短い引用は可、参照元URLを併記してほしい」という引用ポリシーを合わせて784バイトに収めている。全ページの要約を詰め込むのではなく、公開導線を短く保つ、という判断だ。
実際の実装ログを振り返っても、この順番は後付けの理屈ではない。記事のauthorNameを必須化しJSON-LD構造化データを整えたのが先で、llms.txtを追加したのはそのおよそ2週間後だ。本文とschemaの土台をひと通り固めてから、案内板を最後に薄く足すという順番は、狙って決めたというより、実装ログを見返してもそうなっていた、というのが正直なところだ。
日本企業が最初にやるなら、この順番が現実的
大規模リニューアルから始める必要はない。優先順位は次の順番が現実的だ。
- 売上や商談に近いページを特定する
- そのページで答えるべき質問を3〜5個に絞る
- 見出し直下で回答する構造に直す
- 著者、更新日、組織、FAQ、schemaを揃える
llms.txtやサイトマップで主要導線を整理する
対象ページとして優先しやすいのは次のようなものだ。
| ページ種別 | 向いている理由 |
|---|---|
| サービス紹介 | 用語定義、対象顧客、導入条件を明確にしやすい |
| 価格ページ | 比較や判断条件がまとまっており、意思決定質問に強い |
| FAQ | 回答単位の構造を作りやすい |
| 導入ガイド | 手順・前提・留意点が整理しやすい |
| 事例記事 | 結果だけでなく条件や再現手順を載せやすい |
逆に、時事統計の寄せ集めや他社比較の速報だけで構成された記事は古くなりやすく、最初の対象には向かない。
優先順位の1番目、「売上や商談に近いページ」をどう特定するかは、購買シグナルを起点にしたGTM戦略の話でもある(関連: GTM戦略ガイド)。また、価格ページが「意思決定質問に強い」理由は、請求単位・上限・値上げの説明といった回答単位の設計そのものにある(関連: AIサービスの価格戦略)。
この記事は「整える順番」に責務を絞っている。同じ主題を扱う姉妹記事「GEO/AEOとは何か」は、AI検索まわりの記事がなぜ古くなりやすいか——snapshot依存でどう陳腐化するか——に責務を絞っている。1ページ1責務は、AI検索向けの助言としてだけでなく、この2本の記事自体がその実例になっている。
分けている理由は単純だ。「整える順番」と「なぜ古くなりやすいか」では、更新すべきタイミングも参照する一次情報もまったく違う。順番の話は一度整理すれば長く使えるが、陳腐化の話は市場動向のスナップショットに依存するため、更新サイクルがずっと速い。1本にまとめると、どちらの理由で更新したのかが記事の中で混ざってしまう。責務を分けておけば、直すべき記事がどちらかは常に一つに決まる。
効果測定は「引用率」の前にcoverageを見る
AI検索最適化を始めると、すぐに「どれだけ引用されたか」を追いたくなる。しかし初期段階でそれだけを見ると、運に左右されすぎる。
先に見るべきなのはcoverageだ。
- 自社が答えるべき重要な質問に対して、対応ページが存在するか
- そのページに結論、手順、FAQ、更新日、著者が揃っているか
- サービス、価格、事例、導入条件への導線が一貫しているか
- 更新時に古くなった主張や過去の断面情報を消せる運用になっているか
そのうえで、取れるなら次を補助指標として見る。
- Search Console上の指名検索・一般検索の変化
- リファラやアシスタント経由流入の傾向
- 商談や問い合わせで参照されたページの偏り
- 重要な質問を手動で投げたときの回答網羅状況
coverageが弱い状態で引用率だけ追っても、何を直せば改善するのか分からない。
coverageを手で確認する作業でありがちな抜け方には、共通のパターンがある。単価や機能の説明はどのページにもあるのに、「途中でプランを変えたらどうなるか」「解約時に何が起きるか」といった、意思決定の後工程にあたる質問への回答が抜けていることが多い。前工程の説明を厚くする一方で、後工程の質問には答えていない、というのが典型的な漏れ方だ。
おわりに:「引用されるため」から「答えの正本を守るため」へ
ここまでの話を、優先順位リストとしてもう一度並べ直すことはしない。代わりに、軸を一つ入れ替えておきたい。
この記事は表向き「AIに引用されるため」の話として書いてきたが、私が実際に運用しているのは「答えの正本を1つ保守するため」という軸だ。引用されるかどうかはAI側の挙動に依存し、こちらでは完全にコントロールできない。一方で、正本を1つ持ち、それを本文→schema→llms.txtの順で整え続けることは、自分たちの手の中にある。
私が次にやる一手は、coverageを実際に測って、抜けている重要質問を潰すことだ。引用率が動くかどうかは、その後で確認する。順番を守れば必ず引用が増える、とは今の時点では言わない。そこは検証中で、覆るデータが出れば書き直す。
