Google の AI Overviews や AI Mode、ChatGPT 検索など、生成 AI が検索結果をまとめて回答する機能が広がっています。
自社の記事が回答の出典として表示される機会を増やしたい。そう考えて、「GEO」や「AEO」と呼ばれる対策を調べている方もいるのではないでしょうか。
ただ、先にお伝えしておきたいのは、この方法を使えば AI に引用される、と保証できる施策はないということです。
Google は、AI Overviews や AI Mode に表示されるための追加要件や特別な最適化は必要なく、従来からある SEO の基本が引き続き有効だと説明しています。また、必要な条件を満たしても、クロール、インデックス登録、表示は保証されません。
だからといって、何もできないわけではありません。
僕は、AI への引用だけを狙った書き方を探すよりも、次の3つを順番に確認することが大切だと考えています。
- 情報そのものに、引用する価値があるか
- ページ内で、質問への回答を見つけやすいか
- 検索サービスや AI が、ページを取得できるか
この記事では、AI に引用されるための裏技ではなく、人にも検索サービスにも役立つ記事へ改善するために、本当に確認したいことを整理します。
この記事でいう「AI に引用される」とは
「AI に引用される」という言葉は、少し幅広く使われています。
たとえば、検索時の回答に出典リンクとして表示されることと、公開した文章が AI モデルの学習に使われることは、同じではありません。
この記事では、Google の AI 検索機能や ChatGPT 検索などが回答を生成するときに、記事が参照元や出典リンクとして表示されることを「AI に引用される」と表現します。
この違いは、クローラーを考えるときにも重要です。
OpenAI の公式情報では、ChatGPT の検索結果にウェブサイトを表示するための OAI-SearchBot、生成 AI の基盤モデルの学習に使われる可能性がある内容を取得する GPTBot、利用者の操作に応じてページへアクセスする ChatGPT-User が区別されています。
つまり、「AI のクローラーを許可するか」という一問だけでは、判断できません。検索結果への掲載、学習、利用者の操作によるアクセスのどれを許可したいのか、目的ごとに考える必要があります。
AI への引用を保証できる施策はない
AI 検索の回答は、利用者の質問、検索時点で見つかった情報、サービス側の仕組み、地域や言語など、複数の条件によって変わります。同じ質問をしても、毎回まったく同じ出典が表示されるとは限りません。
そのため、次のような説明は慎重に扱いたいところです。
- 構造化データを入れれば AI に引用される
- FAQ 形式にすれば AI Overviews に採用される
llms.txtを置けば ChatGPT に評価される- GEO 対策をすれば引用数が増える
- 更新日を新しくすれば、最新情報として選ばれる
Google は、AI Overviews や AI Mode に表示されるために、新しい機械可読ファイル、AI 向けのテキストファイル、特別な構造化データは必要ないと明記しています。一方で、クロールを許可すること、内部リンクから記事を見つけられること、重要な内容をテキストで示すことなど、従来からの基本事項は引き続き推奨しています。
ここで分けておきたいのが、「引用を保証すること」と「情報を取得・理解しやすくすること」です。
引用されるかどうかを直接操作することはできません。しかし、引用候補になり得る情報を用意し、その情報を見つけて取得できる状態にすることはできます。
最初に必要なのは、引用する価値のある情報
見出し、構造化データ、クローラーの設定を整えても、記事の中身が一般論のまとめだけであれば、あえてそのページを参照する理由は弱くなります。
最初に考えたいのは、「ほかの記事ではなく、このページを参照する理由は何か」です。
Google は、人の役に立つ信頼できるコンテンツを自己評価する項目として、独自の情報、調査、分析があるか、他者の情報を言い換えただけでなく追加の価値を提供しているか、実際の経験や深い知識が示されているかなどを挙げています。
これは Google 検索向けの案内ですが、AI 検索で参照される情報を考えるうえでも、無理のない判断材料になります。
独自の経験や一次情報を含める
独自情報というと、大規模な調査や難しい研究が必要だと思うかもしれません。しかし、実務の中ですでに持っている情報もあります。
たとえば、次のようなものです。
- 実際に行った作業と、その手順
- 比較や検証を行った条件
- 作業前後の数値や変化
- 起きた問題と、確認した項目
- うまくいかなかった方法
- 判断に迷った点と、最終的に選んだ理由
- 利用者から繰り返し寄せられる質問
- 公式情報を実務へ当てはめるときの注意点
成功事例だけが独自情報ではありません。「試したものの、効果との因果関係は確認できなかった」という結果も、条件と確認方法を示せるなら価値があります。
反対に、生成 AI に一般的な説明を作らせ、同じような情報を大量に公開しても、引用する理由は作りにくいでしょう。
質問に対して、具体的に答える
記事のテーマが広すぎると、読者も AI も、どこに答えがあるのか判断しにくくなります。
「AI 時代のコンテンツ制作について」のような大きなテーマよりも、次のように質問を具体化すると、記事で扱う範囲が明確になります。
- 構造化データを追加すると、AI からの引用が増えるのか
llms.txtは ChatGPT 検索への掲載に必要なのか- WordPress の記事を検索クローラーが取得できるか、何を確認すればよいか
各見出しの直後には、まず短い回答を書き、そのあとに理由、条件、具体例、例外を続けます。
これは AI 専用の書き方ではありません。知りたいことの答えを先に確認できるため、人にとっても読みやすい構成です。
公式情報と、自分の判断を分ける
AI や検索サービスの仕様は変わります。公式に発表されていることと、検証から考えられること、筆者の判断を混ぜないことが大切です。
たとえば、WAF や CDN の取得制限を調べたという想定なら、次のように書き分けます。
- 公式情報: Google は、AI 検索機能への掲載に特別な構造化データは必要ないと説明している
- 確認結果: 指定した条件でアクセスすると、HTTP ステータス403が返された
- 解釈: WAF や CDN の設定が取得を妨げている可能性がある
- 判断: まずアクセスログと制限設定を確認した方がよい
確認できていないことは、無理に結論へ変えず、「現時点では確認できない」と残します。分からないことを明記することも、情報の信頼性を支える要素です。
情報を見つけやすくするページ構造
引用する価値のある情報を用意したら、ページ内で見つけやすい形に整えます。
ここで大切なのは、文章を細かく分解して「AI が好みそうな文」を量産することではありません。見出しと本文の関係を分かりやすくし、1つの節で1つの論点を扱うことです。
見出しだけでも記事の流れが分かるようにする
「はじめに」「重要なこと」「確認しましょう」のような抽象的な見出しだけでは、その節で何が分かるのかを判断できません。
見出しには、質問や結論の対象を含めます。
- AI への引用を保証できる施策はない
- 独自の経験や一次情報を含める
- 構造化データは内容を伝える補助になる
- クローラーがページを取得できるか確認する
見出しの階層も、文字を大きくするためではなく、記事の構造を示すために使います。h1 の下に h2、必要に応じて h3 を置き、見た目の都合だけで階層を飛ばさないようにします。
1つの節で1つの論点を扱う
1つの見出しの中に、構造化データ、内部リンク、著者情報、クローラー設定まで詰め込むと、どの説明が何への回答なのか分かりにくくなります。
節ごとに、次の順序で整理すると読みやすくなります。
- 質問または論点を見出しにする
- 見出しの直後に回答を書く
- その理由を説明する
- 具体例を示す
- 条件や例外を書く
- 必要な場合は根拠へリンクする
表や箇条書きは、条件の比較や確認手順には向いています。ただし、本文をすべて箇条書きに置き換える必要はありません。文章で説明した方が関係を理解しやすい部分は、文章のまま残します。
内部リンクで関連情報をつなぐ
内部リンクには、関連する記事を読者や検索クローラーが見つける手助けをする役割があります。
単に「こちら」や「詳しく見る」と書くのではなく、「AI 時代にもホームページは必要なのか」「llms.txt は本当に必要なのか」のように、リンク先の内容が分かる言葉を使います。
また、関連する記事を増やすときは、それぞれの記事が同じ説明を繰り返さないようにします。
この記事では全体の判断基準を扱い、構造化データの記事ではその役割と限界を掘り下げる。llms.txt の記事では、提案の内容と各サービスの対応状況を検証する。このように役割を分けると、記事同士をつなぎやすくなります。
著者情報と更新日を示す
読者が記事を信頼できるか判断するためには、誰が、どのような立場から書いているのかが分かることも大切です。
肩書きや経歴を長く並べる必要はありません。記事のテーマに関係する経験、確認方法、詳しいプロフィールへのリンクがあれば、主張の背景を判断しやすくなります。
公開日と更新日も、情報の新しさを確認する材料になります。ただし、内容を見直していないのに更新日だけを書き換える方法は避けます。Google も、内容が実質的に変わっていないページの日付を新しく見せる行為を、検索エンジン優先のコンテンツを見直すための確認項目として挙げています。
仕様を検証した記事では、「2026年8月6日時点で確認」のように、確認日と対象サービスを本文にも残しておくとよいでしょう。
構造化データとセマンティックな HTML にできること
構造化データやセマンティックな HTML は、無意味なものではありません。ただし、記事の内容に引用する価値がなければ、それだけで補えるものでもありません。
構造化データは、ページの属性を伝える補助
構造化データを使うと、記事のタイトル、著者、公開日、更新日、組織、パンくずリストなどを、決められた形式で検索エンジンへ伝えられます。
Google は、AI Overviews や AI Mode に表示されるための特別な schema.org の構造化データはないと説明しています。また、構造化データを実装しても検索機能への表示は保証されず、マークアップする内容はページ上で読者に見える内容と一致させる必要があります。
つまり、構造化データは、すでにページにある情報を機械が理解するための補助であり、本文にない価値を追加する仕組みではありません。
セマンティックな HTML は、文書構造を伝える基盤
article、header、nav、見出し、段落、リストといった要素を内容に合わせて使うと、どこが本文で、どこが見出しやナビゲーションなのかを機械や支援技術が判断しやすくなります。
重要な本文が最初から HTML に含まれていれば、JavaScript の実行に問題がある取得環境でも内容を確認しやすくなります。
ただし、article や section を使えば AI に引用される、という意味ではありません。適切な HTML は、内容の構造を正しく伝えるための基盤です。
構造化データと AI 検索の関係については、別の記事で詳しく整理する予定です。
内容以前に、ページを取得できる状態か確認する
内容がどれだけ良くても、検索サービスがページを取得できなければ、検索時の引用候補にはなりにくくなります。
Google の AI 検索機能で補助リンクとして表示されるには、ページがインデックスに登録され、Google 検索でスニペットを表示できる状態であることが技術要件とされています。OpenAI も、ChatGPT の検索結果への掲載を望む場合は、OAI-SearchBot と公開されている IP アドレスからのアクセスを許可するよう案内しています。
少なくとも、次の項目を確認します。
robots.txtで、必要なクローラーを拒否していないかnoindexが付いていないか- ページが HTTP ステータス200を返しているか
- canonical URL が意図した URL になっているか
- ログインしなくても主要な本文を読めるか
- JavaScript を実行しなくても、重要な本文が HTML に含まれているか
- CDN や WAF がクローラーを拒否していないか
- XML サイトマップや内部リンクから URL を発見できるか
- モバイル表示でも主要な内容を確認できるか
WordPress を使っているから、自動的にすべて整うわけではありません。公開状態、SEO プラグインの設定、キャッシュやセキュリティサービス、サーバー側の制限によって、取得できる内容は変わります。
また、すべての AI 関連クローラーを一括で許可する必要もありません。検索結果への掲載、モデル学習、利用者の操作による取得を分け、自社の方針に合わせて設定します。
GEO・AEO をどう考えるか
GEO は「Generative Engine Optimization」、AEO は「Answer Engine Optimization」の略として使われています。ただし、具体的にどこまでを含めるかは、説明する事業者や資料によって異なります。
GEO という言葉が広がる背景の1つに、2023年に公開され、KDD 2024 に採択された研究論文があります。この研究では、出典、引用文、統計情報などを文章へ加える方法を含む複数の施策を、独自の評価環境で検証し、生成エンジン上の可視性が最大40%向上したと報告しています。一方で、効果は分野によって異なるとも説明されています。GEO: Generative Engine Optimization｜arXiv
この研究から得られる示唆はあります。ただし、すべての商用 AI 検索サービス、日本語の記事、あらゆる質問で、同じ結果を保証した研究ではありません。サービスの仕組みも変化していきます。
ですので、GEO や AEO を全面的に否定する必要はないものの、新しい名称が付いた施策だけを切り離して考えない方がよいでしょう。
独自情報を用意し、質問へ具体的に答え、根拠を示し、取得できるページとして公開する。まずは、この基本を整えることが先です。
既存記事を改善するための確認項目
新しい記事を増やす前に、すでに公開している記事を見直してみましょう。
内容
- この記事が答える質問を1文で説明できるか
- 冒頭や各見出しの直後で、質問に答えているか
- 一般論をまとめ直しただけで終わっていないか
- 自社の経験、検証、数値、判断基準のいずれかが含まれているか
- 数値や条件に根拠があるか
- 公式情報、確認結果、自分の解釈を分けているか
- 例外や、分からないことを明記しているか
- ほかの記事にはない情報が1つ以上あるか
構造と信頼性
- 見出しだけで記事の流れを理解できるか
h1、h2、h3の順序が適切か- 1つの節で1つの論点を扱っているか
- 関連記事から内部リンクされているか
- 著者名と、記事に関係する経験を確認できるか
- 公開日と更新日が正しいか
- 出典へのリンクが、実際の主張を裏付けているか
- 古くなった手順、画像、説明が残っていないか
技術
- ページがインデックス可能か
robots.txtやnoindexで意図せず拒否していないか- HTTP ステータスと canonical URL が正しいか
- 主要な本文が HTML に含まれているか
- CDN や WAF が必要なクローラーを拒否していないか
- XML サイトマップに URL が含まれているか
- 構造化データが画面に表示される内容と一致しているか
すべてを一度に直すのが難しい場合は、検索や問い合わせにつながっている記事、古くなりやすい記事、自社の経験を追加できる記事から優先します。
自分で確認できることと、相談した方がよい状態
まずは、次の項目を自分たちで確認できます。
- どの質問に答える記事なのか
- 見出しの直後に回答があるか
- 出典、著者、公開日、更新日が表示されているか
- 関連記事からリンクされているか
- Search Console でページがインデックスされているか
robots.txtとページのnoindex設定が意図どおりか
一方で、次のような状態では、制作会社やサイトの保守担当者へ相談した方が確認しやすくなります。
- CDN や WAF がクローラーを拒否しているか判断できない
- サーバーのアクセスログを確認できない
- JavaScript を無効にすると主要な本文を取得できない
- canonical URL や構造化データにエラーがある
- WordPress のテーマやプラグインの、どこを修正すべきか分からない
- 記事を更新しているのに、検索サービスが古い内容を参照している
相談するときは、対象記事の URL、確認した AI・検索サービス、質問文、表示された回答と出典、確認日時、Search Console の状況を用意しておくと、問題を整理しやすくなります。
オレインデザインでは、AI 向けの施策だけを追加するのではなく、記事の内容、サイト内の情報構造、WordPress の公開設定や取得状況を分けて確認し、改善の優先順位を整理しています。自社だけでは原因を切り分けにくい場合は、お問い合わせからご相談ください。
まとめ
AI に引用される記事を作るために、特別な書き方や設定だけを探す必要はありません。
まず、ほかでは得られない経験、検証、数値、判断基準など、引用する価値のある情報を用意します。次に、質問への答えが見つかる見出しと本文へ整え、著者や更新日、根拠を示します。そして、検索サービスがページを取得できる状態か確認します。
構造化データやセマンティックな HTML は、この土台を機械へ伝える助けになります。ただし、内容の不足を補ったり、引用を保証したりするものではありません。
AI への引用を直接操作することはできなくても、人が読み、確認し、参照したくなる情報を、機械も取得しやすい形で公開することはできます。
これは AI 検索だけに向けた対策ではなく、従来の検索や、記事を読む人にとっても意味のある改善です。既存記事を見直す際の参考になれば嬉しいです。
