ChatGPTの検索機能に自社サイトが引用されるために必要なことは、大きく3つです。ひとつはOAI-SearchBotのクロールをrobots.txtで許可すること。ふたつめは、質問に対して単独で答えが完結するページ構造にすること。みっつめは、他サイトからの言及を増やして「その話題ならこのサイト」という参照のされ方を作ることです。逆に、話題になりやすいllms.txtの設置は、現時点ではOpenAIをはじめとする主要AI企業に公式採用されていないため、優先度は高くありません。
先日、BtoBのSaaS企業から「AI検索対策をやりたい」という相談を受けました。話を聞くと、社内で「これからはSEOではなくAI対策だ」という話になったものの、具体的に何をするのかは誰も分かっていない、という状態でした。
とりあえずサイトのrobots.txtを見せてもらったところ、生成AIのクローラーを全部ブロックする設定が入っていました。1年ほど前に「AIに学習されるのは嫌だ」という理由で情報システム部門が入れたものだそうです。つまり、AI検索に載りたいと言いながら、AI検索に載るための入口を自分で閉じていたわけです。
この記事では、対策の中身に入る前に、そもそも何を許可して何を止めているのかを確認するところから整理します。
Google AI OverviewとChatGPT検索は別の話
最初に用語を整理しておきます。「AI検索対策」と一言で言われるものには、性質の違う2つが混ざっています。
ひとつは、Google検索の結果画面の上部に表示されるAIによる要約です。これは検索エンジンの一機能であり、Googleのインデックスが情報源になります。対策の考え方は従来のSEOの延長線上にあり、AIO対策(AI検索最適化)とはで詳しく整理しています。
もうひとつが、ChatGPTやPerplexityのような対話型サービスの中で検索が行われ、回答の中に出典としてサイトが引用されるケースです。この記事で扱うのは後者です。
分けて考える必要があるのは、参照される経路が違うからです。前者はGooglebotがクロールしたインデックスを使いますが、後者はOpenAI自身のクローラーが集めた情報と、回答時に取得する情報を使います。Googlebotを許可していれば自動的に両方に載る、という関係にはなっていません。
まず確認するのはrobots.txtです
OpenAIは用途ごとに別々のクローラーを使い分けており、robots.txtでそれぞれ個別に許可・拒否を指定できます。公式ドキュメントで公開されているのは次の4種類です。
| クローラー名 | 用途 | 拒否したときの影響 |
|---|---|---|
| OAI-SearchBot | ChatGPTの検索機能でサイトを表示するため | 検索結果に出なくなる |
| GPTBot | 生成AIモデルの学習用 | 学習に使われなくなる |
| OAI-AdsBot | 広告の遷移先ページの安全性確認用 | 広告出稿時に影響する |
| ChatGPT-User | ユーザーが指示して取得する場合 | ユーザー起点のためrobots.txtの指定が適用されない場合がある |
ここで実務上いちばん重要なのは、OAI-SearchBotとGPTBotの役割が別だという点です。
冒頭のクライアントのように「学習に使われたくない」という判断をする会社は少なくありません。その場合に止めるべきなのはGPTBotであって、OAI-SearchBotまで一緒に止めてしまうと、学習を拒否したうえに検索機能での露出も失うことになります。
学習は拒否したいが検索には出たい、という方針であれば、robots.txtの書き方は次のようになります。
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /
なお、OpenAIのドキュメントでは、robots.txtの変更が反映されるまでにおよそ24時間かかるとされています。設定を変えた直後に結果を確認しても判断はできません。
もうひとつ注意したいのが、robots.txtだけでなくサーバー側やCDN側でボットを遮断しているケースです。WAFやbot対策の設定で、未知のUser-Agentをまとめて弾いている構成は珍しくありません。robots.txtを直したのにクロールされた形跡がない場合は、アクセスログでOAI-SearchBotのリクエストが到達しているかを確認してみてください。
llms.txtは今どういう位置づけか
AI検索対策の文脈で必ず名前が挙がるのがllms.txtです。サイトのルートにマークダウン形式のファイルを置き、AIが読みやすい形で要約と主要ページへのリンクを提供する、という提案です。
出どころははっきりしていて、Jeremy Howard氏が2024年9月に公開した提案です。背景には、LLMのコンテキストウィンドウにサイト全体を読み込ませるのは現実的ではないという課題があります。
ただ、現時点では公式な標準ではありません。提案元のサイト自身が、コミュニティ主導で仕様を議論している段階であることを明示しており、OpenAIやAnthropic、Googleといった主要なAI企業が採用を表明した事実は確認できません。
そのため、「llms.txtを置けばChatGPTに載る」という説明は、現状に対して過大です。設置コスト自体は小さいので試すこと自体は否定しませんが、これを主要な施策に据えるのは順序が違います。まずrobots.txtの許可設定を直し、コンテンツ側を整えるほうが先です。
新しい仕様や手法が出てきたときは、それが提案なのか、実際にプラットフォーム側が採用したものなのかを分けて見る習慣をつけておくと、こうした過大評価を避けられます。
引用されやすいページには共通点があります
クロールの入口を開けたうえで、次はコンテンツ側の話になります。
対話型AIが回答に出典を添えるとき、参照されているのは「そのページを読めば質問の答えが完結する」ページです。逆に引用されにくいのは、複数ページを行き来しないと結論にたどり着かない構成のページです。
具体的には、次のような作りが有利に働きます。
質問に対する答えを、ページの冒頭で言い切っていること。結論が記事の終盤にしか書かれていない構成は、部分的に読まれたときに答えとして成立しません。
見出しが、実際に人が尋ねる形になっていること。「当社の強み」より「導入にかかる期間はどのくらいか」のほうが、質問と回答の対応が取りやすくなります。
数値や条件に、出典と時点が添えられていること。裏の取れない数値は、そもそも引用の対象になりにくい情報です。
このあたりは、E-E-A-T(経験・専門性・権威性・信頼性)で求められている考え方と大きくは変わりません。AI検索のために別のコンテンツを用意するというより、既存の記事が単独で答えとして成立しているかを点検する作業に近いです。基本的な組み立てはSEO対策の基本やSEO記事の書き方と共通しています。
検索されるより先に「言及される」ことが効きます
対話型AIの回答は、必ずしもその場の検索結果だけで組み立てられているわけではありません。モデルが学習の過程で持っている知識も使われます。
ここで効いてくるのが、自社サイト以外の場所でどれだけ言及されているかです。業界メディアの記事、比較サイト、登壇レポート、他社のブログでの引用。こうした外部からの言及が積み上がっているブランドは、直接クロールされていない場面でも回答に登場しやすくなります。
自社サイトの中だけで完結する施策には限界がある、ということでもあります。オウンドメディアの運用と並行して、外部に一次情報を出していく動き方についてはオウンドメディアの作り方やコンテンツマーケティングとはで触れています。
すぐに着手できるものとしては、自社で持っている実データや調査結果を、他所が引用しやすい形で公開しておく方法があります。引用される単位が明確なコンテンツは、外部からリンクされる確率も上がります。
効果はどう測るか
AI検索対策で困るのが計測です。検索エンジンのように順位を確認する手段が用意されていません。
現時点で現実的なのは、次の2つを併用する方法です。
ひとつは、アクセス解析で参照元を見ることです。ChatGPT経由の遷移は、参照元としてchatgpt.comが記録されます。まずはこの参照元が発生しているか、どのページに着地しているかを確認します。数としては検索流入より小さくなりますが、着地ページの傾向から「どのコンテンツが引用されているか」の当たりがつきます。
もうひとつは、実際に質問してみることです。自社が獲得したい質問文をそのまま投げて、回答に自社が出てくるか、競合が出てくるかを記録します。原始的ですが、現状ではこれがいちばん直接的な確認方法です。毎回まったく同じ回答が返るわけではないため、1回の結果で判断せず、複数回・複数の言い回しで試すのが前提になります。
計測の設計そのものは、KPI設計の考え方で整理している「何を見れば判断できるか」から逆算する流れと同じです。参照元が月に数件しかない段階で細かく分析しても意味は薄いので、まずは発生の有無から追うのが現実的です。
よくある誤解を3つ
相談を受けるなかで繰り返し出てくる誤解を挙げておきます。
ひとつめは、SEOをやめてAI検索対策に切り替える、という考え方です。対話型AIが参照するのは結局のところWeb上の文書であり、検索エンジンに評価されるコンテンツの条件と大きく矛盾しません。既存のSEOを捨てる判断にはつながらない、というのが実務の感覚です。
ふたつめは、GPTBotを許可すれば学習されて有利になる、という期待です。学習に使われることと、検索機能で引用されることは別経路です。学習データに含まれたかどうかを外から確認する方法もありません。
みっつめは、特別な技術対応が必要だという思い込みです。実際に手を入れる場所は、robots.txtの見直しと、既存コンテンツが単独で答えとして成立しているかの点検が中心になります。冒頭のクライアントも、結果としてやったことはrobots.txtの修正と、主要ページの冒頭に結論を置き直す作業でした。
何から着手するか
順番をつけるなら、次のとおりです。
最初にrobots.txtを確認します。OAI-SearchBotが拒否されていないか、CDNやWAFで遮断されていないか。ここが閉じている限り、コンテンツを直しても露出は増えません。
次に、流入を取りたいページの冒頭を点検します。質問に対する答えが最初に書かれているか。見出しが人の問いの形になっているか。数値に出典と時点が添えられているか。
そのうえで、獲得したい質問文を10本ほど決めて、現状の回答を記録します。ここが対策前の基準値になります。
llms.txtのような新しい仕様への対応は、この3つが終わってからで十分間に合います。
自社サイトの現状がどうなっているか分からない、robots.txtを確認したが判断がつかない、という場合は株式会社ティーラへご相談ください。クロールの設定とコンテンツ構造の両面から、どこが詰まっているかをお伝えします。
参考文献
-
OpenAI「Bots」(OAI-SearchBot・GPTBot・OAI-AdsBot・ChatGPT-Userの仕様) https://developers.openai.com/api/docs/bots
-
llms.txt(Jeremy Howard氏による提案・2024年9月3日公開) https://llmstxt.org/