LLMO実装ガイド｜AI検索に選ばれるサイト構造の作り方

2026年10月8日に、GoogleのAI機能ガイド、構造化データの一般方針、生成AIコンテンツの指針、役立つ内容の自己点検、Schema.org FAQPageを再読しました。本文を読者に見える形で整え、クロールとindex条件を確認し、構造化データを可視本文と一致させてから、検査と実ページ観測を分けます。ArticleやFAQPageの型を置いても検索表示やAI引用は保証されず、語彙定義とGoogleの機能資格を同一視しません。

LLMOを実装するときは、「このタグを入れればAIに選ばれる」という完成条件を置かないことが重要です。対象の検索製品、読者が知りたいこと、公開・取得の条件、確かめられる結果を分けます。正しいJSONが書けたことと、内容が正しいこと、引用されたことは別です。

本記事は、既存ページを点検するための実装ガイドです。FAQ、見出し、定義文、Articleの教材を使いながら、どの確認を誰が行うかを整理します。説明は2026年10月4日UTCに確認した公開資料に基づきます。非公開のランキングや、全AI製品に共通する引用基準は扱いません。

30秒で要点

• 対象製品とページを選び、公開・索引・表示条件を先に確認する。
• 見出し、定義、FAQは読者の判断を助けるために整え、引用保証にしない。
• 構造化データの著者、日付、質問回答は、実際の表示内容と一致させる。
• 実装の確認、検索機能への表示、参照流入、その後の成果を別々に記録する。

1. 優先順位は、今ある障害から決める

LLMOは、生成AIを使う検索や回答で内容を参照されることも考慮した情報整備の実務上の呼び方です。製品ごとの仕組みや公開条件は同じではありません。まず「Google Searchの生成AI機能で、料金比較ページの情報を正しく届けたい」のように対象を限定します。

Googleの現行ガイドは、索引に入り、スニペット付きで表示できる技術要件に加えて、Search ConsoleでSearchの生成AI機能の対象に含まれることを案内しています。要件を満たしても、クロール、索引登録、表示は保証されません。アカウント内の実際の状態は担当者が確認します。

同じガイドは、Google向けに特別なAI用ファイルや専用schema.orgマークアップを作ることを必須にしていません。見出しがないと一切理解されない、回答を200字にすると引用される、といった共通規則も置きません。文章量は、読者が判断するために必要な内容で決めます。

表が収まらない場合は、横にスクロールできます

HTML/CSSの基礎だけで全て解決するとは限りません。CMSの出力、CDNや認証、JavaScriptでの本文表示、計測、公開権限の担当が必要な場合があります。画面で保存できる設定でも、ページの最終出力が意図どおりかは別に確認します。

2. FAQは、機能の提供状況と読者への回答を分ける

FAQには、料金に何を含むか、対象外の条件、開始前に準備することなど、本文だけでは残る疑問を置きます。質問数を増やすだけでは判断材料は増えません。短い回答でも重要な例外を落とさず、長ければ要点と詳しい説明への導線を分けます。

Googleは2026年5月8日の更新告知で、FAQリッチリザルトが5月7日から表示されなくなることを案内しています。古い「政府・医療の権威あるサイトに限定」という説明を、そのまま現在の提供条件として使わないでください。一方、Schema.orgのFAQPageという語彙の存在と、Googleの検索機能の提供は別の話です。

FAQPageの教材を、表示本文と照合する

次は架空のサービス案内に対応するJSON-LDのデータ例です。GoogleのFAQリッチリザルトを出すための推奨施策ではありません。 既存のマークアップの意味や、表示との一致を点検する教材として使います。

表が収まらない場合は、横にスクロールできます

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "初回相談の前に何を準備しますか？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "目的、対象ページ、現在の計測方法を用意します。未定の項目は未定と伝えてください。"
    }
  }]
}

CMSが出すデータを確認する場合は、JSONの構文、質問と回答の対応、表示本文との一致を見ます。読者に見せない宣伝文を回答へ足したり、終わったキャンペーンの条件だけを残したりしないようにします。例示JSONを本番ページへそのまま貼らず、サイトの既存の生成処理と管理者を確認してください。

ここで構文が正しくても、検索サービスが利用したことやAIが回答へ採用したことは分かりません。FAQの読みやすさ、構造化データの整合、検索結果という三つの確認を混ぜないことが大切です。

3. 見出しは、読者が必要な節へ進むために使う

見出しは、何についてのページか、各節が何に答えるかを示します。現行のGoogleガイドも、段落や節、見出しを読者に分かりやすく整理することを挙げています。完全なHTMLだけを特別なAI引用の要件にしているわけではありません。

次は構成の教材であり、貼り付けて動くコードではありません。ページタイトルの表示をテーマ側が担当しているなら、本文で同じH1を重ねないようにします。

ページタイトル：業務改善の相談を始める前に
  H2：どの仕事を改善したいか
    H3：入口と完成条件をそろえる
    H3：対象に含めない仕事を決める
  H2：比較のために残す数字
    H3：件数と確認・修正の時間
  H2：まだ決められない場合の進め方

「概要」「詳細」「その他」だけでは、その節で何が分かるか伝わりません。一方、全ての見出しへ同じキーワードを足すと読みにくくなります。見出しだけを順に読んで、対象、条件、比較、例外、次の行動が分かるかを確かめます。

表の見出しと単位、リンク先の意味も本文の構造です。「こちら」の反復より、何を確認できる資料かを示します。関連する重要な条件を別ページへ隠したり、長いページを機械的に細切れにしたりしないでください。

4. 定義文は、短さより適用範囲を明確にする

「LLMOはAIに選ばれる技術です」だけでは、何を実装するか、何を保証しないかが残ります。用語の分類だけでなく、そのページで扱う対象と扱わない結果を示します。

【用語】は、【対象】について【何をするか】を指す。
本ページでは【製品・業務・条件】を扱う。
【この説明だけで保証しないこと】は別に確認する。

たとえば「このページのLLMOは、生成AIを使う検索で参照されることも考えて、公開条件と情報の伝わり方を整える実務を指します。Google Searchの公開資料を中心に説明し、全製品の引用や順位を保証するものではありません」と書けば、適用範囲が明確になります。

定義は冒頭や用語が初めて出る場所へ置きます。同じ説明を各節で繰り返すより、必要な条件へリンクします。定義が明瞭になったことは読者の理解を助ける設計上の判断であり、その文章が引用されるという実測結果ではありません。

5. Articleは、実際の著者と日付へ合わせる

GoogleのArticleの説明では、記事の種類、見出し、著者、公開日や更新日などの情報を扱います。編集部という組織が著者ならOrganization、実在する個人が著者ならPersonというように、実態に合わせます。検索対策のために架空の専門家や肩書を作りません。

次も架空のページに対応する独立した教材です。URLは例示用のexample.comで、このサイトの記事metadataを再現したものではありません。

表が収まらない場合は、横にスクロールできます

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "業務改善の記録を始める方法",
  "url": "https://example.com/guides/process-record",
  "author": {
    "@type": "Organization",
    "name": "例示会社 編集部",
    "url": "https://example.com/about"
  },
  "datePublished": "2026-09-01",
  "dateModified": "2026-10-04"
}

記事ページ、著者欄、CMSの出力が食い違っていないか確認します。テーマやプラグインと手書きJSONが別々の著者・日付を出しているなら、管理元を整理します。このサンプルは全ての推奨プロパティを網羅する設定ではなく、日付と著者の一致を学ぶために絞っています。

Googleのpeople-firstコンテンツの説明は、実質変更のない日付更新や偽の著者情報を点検対象にしています。また生成AIコンテンツの説明は、公開前の事実確認を、タイトル、description、構造化データ、画像のaltにも求めています。本文だけ直して周辺情報を放置しないようにします。

6. SEOと一緒に、実装後の観測を設計する

取得できないページ、内容が見つけにくいページ、古い条件が残るページには、従来のSEOと共通する問題があります。だからといって、SEOで確認した項目が全AI製品への対応を保証するわけではありません。製品名、対象のページ、言語、観測日を記録します。

Googleの現行ガイドはSearch ConsoleのGenerative AI performance reportを案内しています。詳細な集計単位や対象製品面は、そのレポートの現行説明を確認します。ここでは管理画面での測定やアカウント設定を実施したとは主張しません。製品別のLLMO測定で、表示、引用、参照流入、成果の違いを整理できます。

表が収まらない場合は、横にスクロールできます

同じ質問を繰り返した結果は、無作為に選んだ独立した利用者の調査とは異なります。参照元が欠ける訪問や、同時期の広告・季節要因もあり得ます。実装前後で数字が変わっても、施策の因果効果と即断しません。

一ページで始める確認の手順

1. 対象製品と読者の問いを一つ決め、現在の本文と出力を保存する。
2. 公開・取得・索引の条件を担当者と確認し、未確認の項目を残す。
3. FAQ、見出し、定義、著者や日付のうち、実際の不整合を直す。
4. 最終HTMLと可視本文を照合し、JSON構文、リンク、表示も別に確認する。
5. 観測する指標、期間、比較条件、再点検の契機を決める。

期間は一律に2〜4週間と約束できません。担当者が調べる作業時間、開発・公開の待ち、検索側の再取得や観測に必要な期間を分けます。実装項目を消化しただけで完了にせず、内容を更新する人と計測を読む人を決めてください。

静的な構文検査で分かるのは、対象の文字列が解析できるか、想定した値があるかまでです。実ブラウザでの表示、支援技術での利用、検索サービスの受入れ、引用結果は別の確認です。この区別を保ったまま、LLMOの失敗パターンとチェックリストの先にある判断へ進むと、実装を成果の保証へ飛躍させずに改善を続けられます。