🧲

Retrieval Signalsを設計する ─ AIが引用したくなる本文5つの構造

に公開
SEO
geo
ChatGPT
生成 AI
LLMO
tech

「同じ情報なのに、引用されるサイトと無視されるサイトがある」。私がここ半年LLMOを試して一番感じたのはこの不公平さでした。

Google検索1位でも、ChatGPTやPerplexityには無視される。逆に順位の低いサイトが、AI回答の引用元として何度も出てくる。

何が違うのか。突き詰めると 本文の「構造」が違うだけ でした。

本記事では、LLMが引用候補を拾う手がかり = Retrieval Signals を5つの構造に整理し、before/afterのスニペットで具体化します。llmoframework.comの定義と、ChatGPT/Perplexity/Claude/Geminiの2026年の引用挙動データを踏まえます。

Retrieval Signals 5構造の一覧

Retrieval Signalsとは何か

Retrieval Signalsは、AIがコンテンツを発見し引用候補として拾う手がかり。LLMOフレームワーク(llmoframework.com)は、これを4フェーズの1つに置き、Retrieval Signalsページで次の問いを掲げます。

"Can AI systems find your content when they need it?"

ここで挙がるのが、llms.txt、/ai/ディレクトリ、robots.txt、sitemap.xmlといった「発見の器」、つまり 外側のシグナル です。

しかし発見だけでは引用されません。AIが「これは回答に使える」と判断する 内側のシグナル が、本文の構造そのものです。Knowledge Clarityはこちらを問います。

"Is your content clear enough for AI to understand and summarize accurately?"

両輪が揃って初めて引用される。本記事は内側のシグナルを5つの型に落とし込みます。

なぜパッセージ単位の最適化が効くのか

AIの引用判断は、ページ全体ではなくパッセージ単位で行われます。Yextの2026年の分析でも「ページは全文読まれず、クエリに合うパッセージだけが引用される」と整理されています(参考)。

Perplexityは引用元の段落番号まで明示します。ChatGPTも段落単位でリフトを行う。ページ全体のSEO評価が低くても、特定パッセージの構造が良ければ引用される。逆もまた然りです。

ここから具体的な5つの構造へ。

構造1: 質問→即答→根拠(YAMAパターン)

私が YAMAパターン と呼ぶ順序です。Y(question)、A(answer)、M(metric)、A(authority)の4ステップ。

Before(引用されにくい)

<h2>JSON-LDについて</h2>
<p>
  JSON-LDはGoogleが推奨する構造化データの記述形式の一つで、
  HTMLから独立した形でメタデータを記述できる仕組みです。
  さまざまなメリットがあり、AI検索においても活用されています。
</p>

質問なし、回答も曖昧、数値も出典もなし。AIは引用判断材料を見つけられません。

After(引用されやすい)

<h2>JSON-LDとMicrodataの違いは？</h2>
<p>
  <strong>JSON-LD</strong> はHTMLから独立したscriptタグ内に
  メタデータを記述する形式です。Googleは公式にJSON-LDを推奨しており、
  AI検索では <strong>JSON-LD優先で抽出</strong> されます。
  Microdataより実装が容易で、Brave LLM Context APIなど
  AI検索基盤の <strong>標準入力フォーマット</strong> です。
</p>
<p class="source">出典: Google Search Central公式ドキュメント</p>

質問形式の見出し、1文目で明確な回答、太字で要点強調、最後に出典。AIは最初の2文をそのままリフトできます。

私の運用ルール

各H2の直下に必ず1文で結論を置きます。読者もAIも答えを早く知りたい。「導入文を書いてから本題」というブログの定型を捨てるのが第一歩でした。

構造2: 比較表+1行サマリ

LLMがテーブルを偏愛する理由は、行単位で構造化されているから。Brave LLM Context APIは テーブル行レベルでデータを抽出 すると公式に明言しています。

Before(引用されにくい)

ChatGPTはBing、PerplexityはBrave、GeminiはGoogle、ClaudeはMCP経由のBraveを使っています。それぞれ特徴が違うので、最適化の優先度も変わってきます。

文章で並べた瞬間、AIは情報とプラットフォームの紐付けを分解しにくくなります。

After(引用されやすい)

直前に1行サマリを置き、テーブル本体を続けます。

**結論: ChatGPTはBing最適化、PerplexityはBrave最適化が直接効きます。**

| プラットフォーム | 検索基盤 | 主な最適化施策 |
|---|---|---|
| ChatGPT/SearchGPT | Bing + GPTBot | Bing SEO、GPTBot許可 |
| Perplexity | Brave + 独自インデックス | Brave Search対応、Q&A構造 |
| Gemini | Google + YouTube + Scholar | Google SEO、動画連携 |
| Claude | Brave(MCP経由) | JSON-LD、構造化データ |

Perplexityで自分の記事が引用されたパッセージを調べると、テーブル直前のサマリ文がそのまま引用されているケースが何度もありました。サマリは省略可能な装飾ではありません。引用の入口そのものです。

よくある失敗

テーブルを画像で貼ること。これは致命的です。Microsoftの2025年公式ガイドでも「画像のみに重要情報を格納するな」とアンチパターン扱いです(参考)。HTMLテーブルで書きましょう。

構造3: 名前付き定義(Glossary形式)

用語と定義を1対1で並べる Glossary構造 です。

Before(引用されにくい)

LLMOは大規模言語モデル最適化の略で、最近よく聞く言葉になってきました。GEOというのもあって、これも似たような意味で使われていますが、厳密には区別されています。

「最近よく聞く」「似たような意味」のような曖昧表現で、定義として成立しません。

After(引用されやすい)

HTMLなら<dl>/<dt>/<dd>、Markdownなら太字+コロンで明示。

**LLMO (Large Language Model Optimization)**
: 大規模言語モデルに自社コンテンツを引用させるための最適化施策。

**GEO (Generative Engine Optimization)**
: Princeton大の論文で2024年に提唱された学術用語。LLMOとほぼ同義で使われる。

**AEO (Answer Engine Optimization)**
: AI検索エンジンの回答エンジン部分を最適化する考え方。LLMOの一部と見ることが多い。

各エントリが独立して意味を持ち、AIはそのまま「LLMOとは何か」への回答として抜き出せます。私はLLMO関連の記事で必ず冒頭近くに3〜5語のGlossaryブロックを置きます。

補足: schema.org DefinedTerm を併用する

GlossaryブロックにDefinedTermスキーマを追加すると、Brave LLM Context APIなどで構造化抽出されやすくなります。FAQPage級の引用率データはまだ少ないですが、私が試した範囲では効きます。

構造4: 出典明示の数値主張

GEO論文(Aggarwal et al., ACM SIGKDD 2024)が示した最強の施策は、 統計データ追加で引用率+115.1% でした。ただし、数値だけでは意味がありません。出典とセットで初めてシグナルになります。

Before(引用されにくい)

リモートワークは日本で急速に普及しています。多くの企業が導入しており、
今後さらに増えると予想されます。

数値ゼロ、出典ゼロ。AIには引用価値のないパッセージです。

After(引用されやすい)

総務省の調査によると、日本のテレワーク実施率は2024年に **32.2%** に達し、
2019年の **9.8%** から **3倍以上** に増加しました。特にIT業界では
**58.7%** が週3日以上のリモートワークを実施しています。

> 出典: 総務省「令和6年情報通信白書」(2024年7月公表)
> ※ 数値はサンプル説明のための例示です。実数は出典で確認してください。

数値の太字化、出典明示、必要なら検証可能性まで示す。GEO論文では「引用の追加(Adding Citations)」だけで +77.8% とされています。数値+出典の合わせ技は最強です。

私が使っているチェック観点

  • 数値は 太字 にしてAIに見つけやすく
  • 出典は 発行元名+発行年 をセットで書く
  • 「約」「およそ」を避け、確定値を出す
  • 数値が古い場合は更新日を書き、dateModifiedもJSON-LDで一致させる

構造5: TL;DR+Bodyの二段構え

短文の要約(TL;DR)と長文の根拠(Body)を二段で持つ構造です。

なぜ二段構えなのか

AIはTL;DRを引用元として読み、人間はBodyを読みます。役割が違うので、両方ないと両方逃します。

Before(引用されにくい)

## llms.txtの設置方法

llms.txtは2024年9月にJeremy Howardが提唱した規格で、サイトのルートに
配置するMarkdownファイルです。robots.txtのAI版とよく呼ばれますが、
役割は異なります。robots.txtはアクセス制御、llms.txtはコンテンツ案内です。
具体的な書き方を順を追って説明していきます。
...(長い説明が続く)

回答に5秒以上かかります。AIは途中で離脱します。

After(引用されやすい)

## llms.txtの設置方法

**TL;DR**: サイトルートに`/llms.txt`を配置し、Markdown形式で主要ページの
タイトル・URL・1行説明を列挙する。`robots.txt`はアクセス制御、`llms.txt`は
コンテンツ案内で、役割が異なる。

### 詳細な書き方

llms.txtは2024年9月にJeremy Howardが提唱した規格で...
(以下、本文)

TL;DRブロックがあれば、AIは即座に「このセクションの結論」を抜き出せます。Mediumの2026年ガイドでも「short answer + long context」が引用率を高めると報告されています(参考)。

TL;DRブロックの作り方

  • 1ブロックは 2〜3文以内
  • セクションの結論を そのまま 書く(引用されることを前提に)
  • 太字や記号を使いすぎない(プレーンテキストの方がAIに優しい)
  • セクション冒頭ではなく、見出しの直下に置く

Before / After を1枚にまとめると

Before/After比較: 引用されない本文と引用される本文

同じ情報量でも、構造を変えるだけでAIの引用判断は変わります。私が試行錯誤して気づいたのは、 書き直すコストより、書く前に型を選ぶコストの方が小さい ことでした。

各構造をschema.orgでブーストする

5つの構造はそのままでも効きますが、schema.orgのJSON-LDを併用すると引用シグナルが強化されます。

FAQPageは2026年も有効か

「Googleが2026年6月にFAQ rich resultsを廃止する」と報じられ、FAQPageは終わったと誤解されがちです。しかし AI検索の引用シグナルとしては今も有効 です。

2026年のSchema Markup調査では「FAQPageマークアップがあるページはAI Overviewsに 3.2倍 出やすい」と報告されています。装飾は消えても、AIの抽出シグナルは残っています。

構造別の推奨スキーマ

構造 推奨schema.org 補足
1: 質問→即答→根拠 FAQPage / QAPage AI引用シグナルとして引き続き強い
2: 比較表+1行サマリ Table + Article 表自体のスキーマは弱い。本文側で強化
3: 名前付き定義 DefinedTerm / DefinedTermSet Glossaryページ全体に適用可能
4: 出典明示の数値 Article + Citation sameAs/citationフィールドを活用
5: TL;DR+Body Article + about descriptionフィールドにTL;DRを反映

JSON-LDは2026年もAI検索の標準入力フォーマット。Google、Bing、Perplexity、ChatGPTがすべて依存していると2026年の調査も整理しています。

クローラーに届ける外側のシグナルも忘れない

内側のシグナルを整えても、クローラーがブロックされていれば届きません。2026年の主要AIクローラーをおさらいします。

クローラー 用途 公式ドキュメント
GPTBot OpenAIのモデル学習 platform.openai.com/docs/gptbot
OAI-SearchBot ChatGPTのリアルタイム検索 上記と統合管理
ChatGPT-User ChatGPTからのユーザー操作 同上
ClaudeBot Anthropicの学習用クロール Anthropicが2026年2月更新
Claude-User Claudeからのユーザー操作 同上
Claude-SearchBot Claude検索品質向上 同上
Google-Extended Gemini/Vertex AI学習(opt-out専用) Google Search Central
PerplexityBot Perplexity独自インデックス docs.perplexity.ai

Anthropicは2026年2月にClaudeBot関連を3種類に分解し、robots.txtで粒度の高い制御が可能になりました(Search Engine Roundtable)。Google-Extendedは学習opt-out専用で、ブロックしてもGooglebotのインデックスには影響しません。私のrobots.txtは学習系は選別、検索系はフル許可で運用中です。

5つの構造を組み合わせる順番

全部入れる必要はありません。私が試した順番はこうです。

  1. まず 構造1(質問→即答→根拠) を全H2に適用 → 即効性が高い
  2. 次に 構造4(出典明示の数値) を主要セクションに追加 → 引用率が伸びる
  3. 構造2(比較表+サマリ) を要点比較に使う → Perplexity引用が増える
  4. 構造5(TL;DR+Body) を長文記事に追加 → 滞在時間も上がる
  5. 構造3(Glossary) は専門用語が多い記事に限定 → ピンポイントで効く

全部適用すると本文が窮屈になります。記事のテーマと長さに合わせ2〜3個を選ぶのが現実解です。

信長の野望でいう「布石」

私は信長の野望を15年プレイしてきましたが、retrieval signalsの設計は布石の打ち方に似ています。今すぐ効果が出なくても、半年後・1年後にAI引用の累積で差が出る。1記事ずつ構造を整えれば、サイト全体のAI可視性が滑らかに上がります。面白くいきましょう。

まとめ: 引用される本文は「型」で決まる

要点を5つに絞ります。

  1. AIの引用判断は パッセージ単位 で行われます。ページ全体の権威性より、各セクションの構造が直接シグナルになります。

  2. 引用率を上げる5つの構造は 質問→即答→根拠 / 比較表+サマリ / Glossary / 出典明示の数値 / TL;DR+Body 。記事ごとに2〜3個を選びましょう。

  3. 数値+出典はGEO論文で +115.1% という最強の引用シグナル。曖昧な主張を避け、確定値と発行元名を併記しましょう。

  4. FAQPageスキーマはGoogle rich resultsから消えても、 AI Overviewsへの引用は3.2倍 という調査結果があります。schema.orgは2026年も標準入力フォーマットです。

  5. 内側のシグナル(本文構造)と外側のシグナル(robots.txt、llms.txt、sitemap)は両輪です。llmoframework.comのKnowledge ClarityとRetrieval Signalsを行き来して設計しましょう。

参考リンク

Discussion