「LLMO対策」という言葉で、営業や提案を受ける機会が増えていないでしょうか。資料にはrobots.txtの設定、llms.txtの設置、構造化データ、タイトルの見直しと施策の名前が並びますが、どれが重要で、どれが後回しでよいのか。判断の物差しまでは書かれていません。
迷う根本の原因は、施策リストが「AI」をひとくくりに扱っていることです。実際にサイトを読みに来るのは、目的も動き方も違う何種類ものボットで、施策はどのボットに向けたものかで意味が変わります。この記事は、ボットの種類ごとに仕組みを整理し、外部に丸投げせず自社で実装の判断まで下せるようにするための解説です。
いま、日本のWebトラフィックの約3分の1は人間ではありません。Cloudflareの観測によると、日本では、HTMLページへのリクエストの33.5%がボットによるもので（Cloudflare Radar・日本・2026年8月時点の直近7日間）、世界全体では人間のリクエストはすでに半数未満です（Cloudflare公式ブログ・2026年8月）。
しかもこのボットたちの多くは、アクセス解析の定番であるGA4（Googleアナリティクス）には映りません。GA4はページ内のJavaScript（ブラウザ上で動く計測プログラム）で訪問を測る仕組みで、AIボットの多くはそれを動かさず、ページのテキストだけを持ち帰るからです（自動ブラウザなどJavaScriptを実行する一部のボットは例外です）。
このボットたちを名前ごとに観察できる道具がCloudflareです。CloudflareはWebサイトの玄関に置くセキュリティ兼高速化サービスで、AI時代はそこを通るAIボットを見分ける関門になりました。
管理画面の「AI Crawl Control」を開くと、GPTBot・ClaudeBot・ChatGPT-UserといったAIボットの来訪が名前ごとに記録されています。この記録と、OpenAI・Anthropic・Perplexity・Cloudflareの公式資料、当社サイト（gaaaon.jp）で実装した施策の結果をもとに、4つの経路に分けて整理します。
全体図：AIボットは3種類。それに新しい窓口が1つ
サイトに来るAIボットは、Cloudflareの公式分類で3種類に分かれます。学習クローラー・インデックス作成クローラー・ユーザー指示ボットの3種です（Cloudflare公式ドキュメント）。どのボットがどの種類かは名前ごとに定義されているため、自分のサイトに来ているボットを機械的に仕分けられます。この3種に、ボット分類の外に新しく生まれた窓口（MCP）を足した4つが、この記事の対象です。
| # | 経路 | 該当ボット | 何をするか | 対策の優先度 |
|---|---|---|---|---|
| ① | 学習クローラー | GPTBot・ClaudeBot など | 平時に巡回し、LLMモデルの学習材料としてページを集める | 方針決定（順番の話ではない） |
| ② | インデックス作成クローラー | OAI-SearchBot・Claude-SearchBot・PerplexityBot | 平時に巡回して検索用の索引を作る。質問時の検索はAIの中で完結（サイトからは見えない） | 最優先 |
| ③ | ユーザー指示ボット | ChatGPT-User・Claude-User・Perplexity-User | 質問やURL指示をきっかけに、実物のページをその場で読みに来る | 重要（誤読を防ぐ） |
| ④ | 専用接続窓口（MCP） | MCPクライアント・エージェントブラウザ | サイトが用意したデータ提供窓口に直接問い合わせる | 将来への備え |
ユーザーがAIに質問したとき、裏側では次の順で進みます。中心にあるのは②インデックス作成クローラーと③ユーザー指示ボットです。
- （事前・定期的に）②のインデックス作成クローラーが世界中のサイトを巡回し、中身を検索用の索引（インデックス）に保存しておく。
- （ユーザーから質問を受けると）AIが索引を検索する。AIの手元に届くのは、インデックスに保存済みの抜粋データ。
- その抜粋で回答が作れればそのまま回答する。※この場合、AIによるサイトアクセスは発生しない。
- （AIが抜粋で回答が不足していると判断したら）③のユーザー指示ボットがサイトへアクセスし、本文データを取得して回答する。
①の学習クローラーはこの流れの外にいて、④も索引を通らない独立ルートです。
以下、4つの経路を順に説明します。
経路①：学習クローラー（LLMモデルの学習材料を収集）
最初の経路は、AIモデルの学習材料としてページを集めるボットです。GPTBot（OpenAI）とClaudeBot（Anthropic）が代表で、robots.txtで学習利用を制御する名前としては、GoogleのAI学習向けのGoogle-Extendedや、多くのオープンソースAIの上流データになるCCBot（Common Crawl）もここに入ります。
学習クローラーが持ち帰ったデータは、LLMモデル（大規模言語モデル）の「学習」に使われます。学習に取り込まれた内容はモデルの知識の一部になり、原文の形では保存されません。反映は次のモデル更新まで待つため遅く、回答に使われても出典は付きません。一度学習された内容を、後から差し替えることもできません。
ここで重要なのは、同じAI企業が目的の違うボットを分けて走らせていることです。3社の公式資料を並べると、分業がきれいに見えます。
| 提供元 | 学習（①） | 検索の索引づくり（②） | ユーザー起点の取得（③） |
|---|---|---|---|
| OpenAI | GPTBot | OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot | Claude-SearchBot | Claude-User |
| Perplexity | （学習用巡回なし） | PerplexityBot | Perplexity-User |
たとえばOpenAIは、GPTBotを「基盤モデルの学習に使いうるコンテンツを収集するボット」、OAI-SearchBotを「ChatGPTの検索機能で表示するサイトを見つけるためのボット」と説明しています（OpenAI公式Botsページ）。
Perplexityも「PerplexityBotは検索結果にサイトを表示するためのもので、基盤モデルの学習用ではない」と明記しています（Perplexity公式ドキュメント）。
ボットを学習用とインデックス作成用とにわざわざ分けているのには、理由があります。
robots.txt（ボットの入館規定を書いたファイル）は、ボットの名前単位でしか許可・拒否を選べません。学習用と検索用が分かれているからこそ、サイト側は「学習に使われるのはNG。検索結果に表示されるのはOK」という選択ができます。
日本でこの選択を最も強い形で行っているのが新聞各社です。日経・朝日・読売など大手各紙は、いずれもAIボットの名指し拒否をrobots.txtに掲げています（2026年8月15日に各社robots.txtで確認）。
例として日経を見ると、学習用・検索用・ユーザー指示の3分類すべてにわたってAIボットを含む40種類のボットを名指しで拒否し、機械学習に使いたい事業者は有償のデータ提供窓口へ問い合わせるよう明記しています（2026年8月時点のnikkei.com/robots.txt）。
nikkei.com/robots.txtからOpenAI関連の行を抜き出すと、次の3組です（#で始まる分類ラベルは当社による注記で、原文にはありません）。
#学習用BOT
User-agent: GPTBot
Disallow: /
#検索用BOT
User-agent: OAI-SearchBot
Disallow: /
#ユーザー指示
User-agent: ChatGPT-User
Disallow: /
一方で、GooglebotやBingbotといった従来の検索クローラーは許可したままです。AI経由の露出をゼロにしてでもコンテンツの対価を守り、検索流入だけは維持する、という経営判断だと思われます。
ただし、この名指しの拒否には届かない範囲があることも確認できています。
例えばClaudeに経済ニュースを聞くと、拒否しているはずの日経の記事がソースとして使われて紹介されます。これはClaudeが検索インデックスをBraveに外注しており、そのクローラー（Bravebot）は、日経の拒否リストに入っていないために起こる現象です。
企業側から見れば、40種類のボットを名指しで拒否しても、AI検索の裏側にある第三者の索引（ChatGPTやCopilotが使うBing、Claudeが使うBrave）までは手が及ばないということです。遮断を選ぶ場合も、この限界を織り込んだ判断になります。
①への対応は、経営方針の判断そのものとも言えるでしょう。コンテンツそのものが商品である企業ほど遮断と対価回収に傾き、露出が営業資産になる企業ほど許可に傾きます。
経路②：インデックス作成クローラー（AI検索用の情報収集）
AI各社は、自前のAI検索エンジンを作るために専用のボットを巡回させています。OpenAIのOAI-SearchBot、AnthropicのClaude-SearchBot、PerplexityのPerplexityBotがそれで、集めたページは学習ではなく、回答時に引くための索引（インデックス）に保存されます。学習クローラーとは名前が切り分けられているため、robots.txtで「学習は拒否、検索は許可」のように個別に制御できます。
ただし、索引を自前で持つとは限りません。前述の通り、Claudeは自前のClaude-SearchBotを走らせつつ、現在の検索インデックスにはBraveのものを使っています（当社の検証で、Claudeの検索抜粋とBraveの索引の内容が一致することを確認しています。OpenAIも、検索機能にBingを含む外部の検索技術を併用していると公表しています）。どのAIの検索に載るかは、各社がどの索引を使っているかで決まります。
従来の検索エンジンとAI検索エンジンは、同じ「クロールして索引を作り、検索時に引く」仕組みですが、前提がいくつも違います。
| 従来の検索エンジン | AI検索エンジン | |
|---|---|---|
| 代表サービス | Google検索・Bing検索 | ChatGPT検索・Claude・Perplexity |
| 代表的なクローラー | Googlebot・Bingbot | OAI-SearchBot・Claude-SearchBot・PerplexityBot |
| 索引を引くのは | 人間の検索操作 | 回答を作るAI |
| 検索クエリ | 人間が打つ短いキーワード | AIが発行する細かい質問文（かけ合わせや言い換えを大量に投げる） |
| 上位に入った後 | 人間がリンク一覧から選んでクリック | 最終的な取捨選択もAIが行い、回答に合成される |
| サイトへの流入 | クリックで訪問が発生する | 回答内で消費されがちで、クリックは細る |
| サイト側の計測 | Search Consoleで表示回数・順位・クリックが見える | 索引が引かれたかは見えない |
| robots.txtでの制御 | Googlebot・Bingbotの名前で制御 | AI検索用の別の名前で個別に制御できる |
なお、この境界は溶けかけています。Google検索は結果の上にAIによる概要を出すようになり（Googlebotの索引がAIの回答にも使われる）、Bingの索引はCopilotやChatGPT検索に供給されています。従来検索の顔をした索引が、AI検索の材料を兼ねています。①で見た「検索には載せたいがAIには使われたくない」を完全には選べない理由が、ここにあります。
ユーザーがAIに質問すると、画面には「Web検索しています」と表示されますが、この瞬間にボットは動いていません。Googleで検索してもGooglebotが動かないのと同じで、作り置きの索引が引かれるだけです。AIの手元に届くのは索引に保存されたタイトル・説明文・本文の断片で、それだけで答えが組めれば、実物のページは読まれません。なお、この抜粋は索引に保存された時点の内容で、いま公開されている本文と一致するとは限りません。
本文をどれだけ磨いても、抜粋で落選したページは読まれない。
しかもこの検索の瞬間はAIの中で完結するため、サイト側からは観測できません。巡回してきたクローラーの記録はCloudflareに残りますが、その索引がいつ・どの質問で引かれたかは、ログにもCloudflareにも残りません。見えないところでページの当落が決まります。
だからこそ、②の索引にしっかり収まることが、AI検索の結果に反映されるための出発点です。①の学習方針を決めたら、実際に手を動かす施策の中ではここが最重要です。
ちなみに当社でも「生成AIに強いPR会社」という文脈で、AIに取り上げてもらうための実験を行った結果、実際にAI言及率／引用率を増やすことに成功しました（詳しくは以下記事参照）。
なぜAIは第三者の評価を重視するのか｜Claude思考分析で検証
AIは企業の“自社に都合のよい主張”を割り引き、第三者の評価を重んじて会社を推す。Claudeの思考データと自社AI可視性計測AI Pulseの実測で検証し、AIに選ばれるためのSEOとPRの両輪、Brave対策まで具体的に解説します。
株式会社ガーオン
このように②は、従来のSEOの延長線上にあり、ビジネスとして介入できます。ここが重要なポイントです。
ただし、章の冒頭の表の通り、クエリを発行するのも、上位に入った後の最終的な取捨選択をするのもAIです。この2点は、従来のSEOにない前提です。
②への対応は、自社で今日から手を付けられます。
- robots.txtの確認：「自社ドメイン/robots.txt」をブラウザで開き、中身をAIに貼って「AI検索用のボットをブロックしていないか」と聞く。まとめてブロックしていると、AI検索の結果から消えます
- タイトルと説明文の整備：検索されやすい言い方をタイトルに使い、本文から切り離して読んでも内容が伝わる説明文にする。文章の仕事で、技術の仕事ではありません
①と②をまとめると、対策の性質がまったく違います。①は網羅、②は競争です。
| ① 学習データ対策 | ② 検索インデックス対策 | |
|---|---|---|
| 性質 | 網羅。隅々まで読める状態にする | 競争。対象クエリ群で上位に入る |
| やること | クロール許可・機械可読な構造・サイト全体の一貫性 | ターゲットクエリに合うタイトル・説明文・自己完結のコンテンツ |
| 効果の出方 | 遅い（モデル更新待ち）。出典なし・検証不能 | 速い（索引更新ごと）。引用付き・順位で検証できる |
| 従来SEOとの関係 | 別物 | ほぼ延長線 |
経路③：ユーザー指示ボット。実物のページを読みに来る
3つ目の経路は、実物のページをその場で読みに来るボットです。ChatGPT-User・Claude-User・Perplexity-Userが該当し、名前が「-User」で終わるのは、ユーザーの依頼に応じて動くボットだからです。
動くきっかけは2つあります。1つは、②の検索結果の抜粋だけでは足りないとAIが判断して、実物を取りに来る場合。もう1つは、ユーザーがURLを渡して「このページを見て」「要約して」と指示した場合です。サイトのログからは、どちらも同じボット名で来るため区別できません。
来訪数は4経路の中でも最大級です。当社サイトの実測では、ChatGPT-Userを名乗るアクセスだけで直近24時間に192件と、ボット名別の首位でした（Cloudflare AI Crawl Control、2026年8月13日）。件数はアクセス元が自己申告する名前（ユーザーエージェント）にもとづくもので、名乗りは偽装できるため、実数はこれより少ない可能性があります。それでも、実物ページの取得は理屈ではなく、日常的に起きている動きです。
なお、ユーザー起点の取得はrobots.txtで止まらないことがあります。Perplexityは「ユーザーの指示によるフェッチ（Perplexity-User）は原則robots.txtに従わない」と公式に明記しています。人間がブラウザで開くのと同じ扱い、というロジックです。
③でAI対策として効くのは、本文を「機械が誤読しない状態」に保つことです。ここでHTMLの構造が崩れていたり情報が食い違っていたりすると、AIが内容を誤読したまま回答を組み立てます。当社サイトで実際にやったことが3つあります。
1つ目は、メタデータの位置の修正です。当社ブログはかつて、記事の公開日などの情報がHTML内の決められた場所（head内）に出力されておらず、Claudeが記事の日付を取得できない状態でした。ページの作り方を変更してhead内に固定する修正を実施済みです（取得改善の再検証は、AI側の再クロールを待って行う予定です）。人間のブラウザでは何も変わらない、機械だけが困る不具合でした。
2つ目は、Markdown配信です。ページに Accept: text/markdown というリクエストヘッダー（「本文だけの軽い形式でください」という機械からの注文）が付いたとき、HTMLの代わりに、飾りを取り去った本文だけの文書形式（Markdown）で返す仕組みを実装しました。機械にとっては、メニューや装飾の混ざった百数十KBのHTMLを解読するより、数KBの本文だけを受け取るほうが確実です。
3つ目が、記載内容の矛盾の排除です。当社では診断サービスの料金表記がページによって揺れていた時期があり、全ページを1つの表記に統一しました。AIが複数ページを読んだとき、矛盾があるとどちらを答えるかはAI任せになります。どこを読まれても同じ答えになる状態が、AI経由の回答の再現性を作ります。
このほか、構造化データ（会社名・料金・公開日といった基本情報を、機械が読み間違えない決まった書式でページに書き添えておく仕組み）も③に効く施策で、当社サイトでも実装しています。
あわせて、本文の書き方そのものにも効く工夫があります。当社の検証では、Claudeが検索経由で読む抜粋は、ページ本文から逐語コピーされたチャンク（文章の断片）でした。チャンクの境目は質問が変わっても動きません。長さは一定ではなく、当社計測では中央値150〜200字程度（1ページあたり約5個）でした。ページはまるごと評価されるのではなく、この断片単位で読まれ、引用されます。
どこを切り出されても単体で意味が通るように、1つの段落に1つの主張を置き、重要な数字はその1文の中で完結させます。この書き方が、②の抜粋での当落にも、③で読まれた後の引用のされ方にも効く、というのが当社の見立てです。検証の詳細は次の記事にまとめています。
Claudeは何を「読んで」答えている？AIに拾われる文の書き方
生成AI「Claude」は、ページ全文でも要約でもなく、検索エンジンBraveが本文からそのまま切り出した約150字の抜粋を「意味」で選んで読んでいた。当社の実測でClaudeの検索メカニズムを解剖し、キーワード詰め込みに頼らずAIに拾われる文を書く5つのポイントを解説します。
株式会社ガーオン
③への対応も、自社で進められます。
- 記載内容の矛盾を潰す：料金・サービス名・数値・代表者名など、ページによって記述が違う箇所を洗い出して統一する。技術は不要で、社内の情報統治の仕事です
- 技術面を自分で点検する：気になるページのHTML（ブラウザの「ページのソースを表示」で見られます）をAIに貼り、「公開日などのメタ情報はhead内に正しくあるか」「構造化データは入っているか」と聞けば、外注前に自分で現状を把握できます
- 本文を自己完結の段落で書く：どこを切り出されても意味が通る150〜200字程度のまとまりを意識し、重要な数字は1文の中で完結させる
経路④：専用接続窓口（MCP）。AIが直接問い合わせる仕組み
最後の経路は、ボット分類の外にある新しい窓口です。AIがページをブラウジングするのではなく、サイト側が用意したデータ提供窓口（MCPサーバー）に直接問い合わせて情報を取得します。
この領域は2026年に入って動きが速く、SEO業界でも大きな話題になっています。MCPによって検索を経由しない情報取得の経路が増え、「検索順位からの流入」だけを価値とするビジネスモデルが最も影響を受ける、という論考が広く読まれました（あーこ「MCPがSEO業界を変える？―記事量産と検索順位レポートの価値が下がる理由」・note・2026年8月3日）。
MCPよくわかんない！というお声をいただいたので非エンジニアでもどなた様でもわかりやすいように記事を書きました🙋♀️
— あーこ (@aakobuppan) 2026年8月3日
わかりやすかったよ！と思っていただけたらリポストいただけると幸いです🙏
MCPがSEO業界を変える？―記事量産と検索順位レポートの価値が下がる理由｜あーこ…
MCPがSEO業界を変える？―記事量産と検索順位レポートの価値が下がる理由｜あーこ
今話題のMCPについて、非エンジニア・どなた様でも理解できるようにわかりやすく解説したnote記事。
note
その土台にあるのがMCPとWebMCPです。MCP自体は、Anthropic（Claudeの開発元）が2024年11月に公開したAIとツールをつなぐ共通規格で、その後OpenAI・Microsoft・Googleも採用し、事実上の業界標準になっています。
WebMCPは、このMCPをブラウザの標準機能として使えるようにするための規格案です。こちらはGoogleとMicrosoftのエンジニアが提案し、W3C（Webの標準化団体）で策定が進んでいます（2025年8月に統合提案、2026年2月にChrome公式ブログで発表）。MCP本体も2026年7月28日に最新の仕様改定が行われるなど土台が動き続けるなか、同年8月にはCloudflareが「MCPサーバーを持つサイトをスイッチ1つでWebMCP対応にする」開発者プレビューを公開しました（Cloudflare公式ブログ）。
サイトがMCPサーバーを持っていると、Cloudflareが各ページに案内係のプログラムを差し込みます。ページを開いたとき、利用者のブラウザの中で動くAI（ページを一緒に見ながら作業を手伝うタイプのAI）が、その窓口を自動で見つけて使えるようになります。①〜③の続きではなく、独立した経路です。窓口に人は座っておらず、問い合わせも回答も機械同士の自動のやり取りで完結します。
当社サイトでも、記事検索など読み取り専用のツールを持つMCPサーバーを設置し、WebMCPを有効化してみました。claude.aiから実際に接続できることは確認しましたが、この経路を今日使える訪問者はまだごく少数です。対応ブラウザは実験段階で、MCPクライアント側も自分で登録する必要があります。
④への対応は、現時点では「こういう窓口の規格が生まれつつある」と知っておくことです。実装は費用対効果を見て判断する経路で、着手する場合も、当社のようにAIの支援を受けて自社で作る選択肢があります。
どこまで計測できるか。GA4に映るのはクリックの後だけ
4経路の計測可否を1枚にまとめると、冒頭の「GA4では全部は見えない」の正体が見えます。
| 見たいもの | 見える場所 | GA4で見えるか |
|---|---|---|
| ①学習クローラー・②インデックス作成クローラーの巡回 | Cloudflareなどサイト手前の通信記録（ボット名ごと） | 見えない |
| ②の後段（AI内検索でどのページが抜粋されたか） | どこにも記録されない（通信が発生しない） | 見えない |
| ③ユーザー指示ボットの取得 | Cloudflareなどサイト手前の通信記録（ボット名ごと） | 見えない |
| ④MCP窓口への問い合わせ | Cloudflareで通信量まで。ツール単位はサーバー側に記録を作れば計測できる | 見えない |
| AI回答の引用をユーザーがクリックした訪問 | GA4（参照元付き） | 見える |
回答画面に自社サイトの引用が表示された時点では、まだ誰もサイトに来ていません。索引の控えが読み込まれて表示されているだけです。ユーザーがその引用をクリックした瞬間から、人間のブラウザによる普通の訪問になり、初めてGA4に記録されます。AI経由の露出のうち、GA4で見えるのはこの最後の一歩だけです。
明日からできる4つのアクション
いずれも特別な予算は要りません。
- 自社のrobots.txtを開いて見る。ブラウザで「自社ドメイン/robots.txt」にアクセスし、中身をAIに貼って「インデックス作成クローラー（OAI-SearchBot・Claude-SearchBot・PerplexityBot）をブロックしていないか」と聞きます。止めていると、AI検索の結果から消えます。
- 主要ページのタイトルと説明文を「抜粋単体」で読む。本文から切り離して、タイトルと説明文だけで自社の何が伝わるかを確認します。伝わらなければ、そこが②の失点です。
- サイト内の矛盾を1つ潰す。料金・数値・サービス名など、ページによって記述が揺れている箇所を探して統一します。AIは複数ページを突き合わせて読みます。
- 自社サイトへのボットアクセスを一度実測する。GA4では見えないため、Cloudflareのような、サイトの手前で通信を記録するサービスで確認します。導入済みなら、冒頭で触れたAI Crawl Controlの画面がそのまま使えます。導入しているかどうかは外から確認できます。ブラウザで自社サイトを開いてF12キーを押し、「Network」タブを開いた状態でページを再読み込みして、一番上のリクエストのレスポンスヘッダーに
server: cloudflareとcf-rayがあれば導入済みです（cf-rayはCloudflareだけが返す識別子です）。
なお、AI対策としてよく挙がるllms.txtは、主要AIクローラーが取得しに来る保証がなく、Googleも公式ガイドで「Google検索はllms.txtを使わず、無視する」と明言しています（Google検索セントラル AI最適化ガイド）。当社の計測でも取得は観測されていません。当社は費用ゼロの実験として設置していますが、効果を期待して優先する施策ではありません。
まとめ
たった1行で言えば、LLMO対策とは「①学習に載せるかを決め、②索引に収まって抜粋で選ばれ、③実物で誤読されず、④窓口まで備える」ことです。
優先順位は②→③→④です。②で索引に入らなければ抜粋に載らず、検索起点の③も起きません。④は上積みです。①の学習は露出の順番の話ではなく、使わせるかどうかを最初に一度決めておく方針判断です。
施策のリストに迷ったら、それがどのボットに向けた施策かで仕分けてみてください。順番と抜け漏れが一目で見えます。そしてこの範囲の実装は、予算の問題ではなく理解と段取りの問題です。当社サイトが、AIの支援を受けた自社実装だけでここまで到達できることの実例です。
当社では、自社サイトを実験台にした知見をもとに、AI上で自社がどう見えているかを測るスポット診断「AI Pulse」（3万円・税別〜）を提供しています。現状把握から始めたい方は、お気軽にご相談ください。
関連記事：
マシンリレーションズとは｜LLMO対策の先にあるAI広報論
「メディアはAIが最初の読者になり、最初のフィルターになる」。AI引用の82-89%がアーンドメディアから来る時代に、何をすればAIに選ばれるのか。米国Parrott氏提唱のマシンリレーションズ（MR）を5層で解説し、新指標「Share of Citation」まで紹介します。
株式会社ガーオン
LLMO対策とは｜費用相場と頼める会社3タイプ【中小企業向け】
LLMO対策の費用相場と、SEO会社・ツール型・PR会社発の3タイプの選び方を中小企業向けに解説。契約前に確認すべき5つの計測指標つき。
株式会社ガーオン
参考文献・参考リンク
- OpenAI「Overview of OpenAI Crawlers」。OAI-SearchBot／ChatGPT-User／GPTBotの3ボットの役割を公式に説明。 https://developers.openai.com/api/docs/bots
- Anthropic「Does Anthropic crawl data from the web?」。ClaudeBot／Claude-User／Claude-SearchBotの3ボット構成を公式に説明。 support.claude.com/…-block-the-crawler
- Perplexity「Perplexity Crawlers」。PerplexityBotは学習用ではないこと、Perplexity-Userは原則robots.txtに従わないことを明記。 https://docs.perplexity.ai/guides/bots
- Cloudflare「Verified bot categories」。ボットをTraining（学習）・Search（検索）・Agent（ユーザー起点の取得）などの区分で公式に分類。 developers.cloudflare.com/…d-bots/categories/
- 日本経済新聞 robots.txt（2026年8月時点）。AIボットを含む40種のボットの名指し拒否と、機械学習利用の有償データ提供窓口への誘導を記載。 https://www.nikkei.com/robots.txt
- Brave「Brave Search Crawler」。クローラーBravebotのUser-agentとrobots.txt遵守を公式に説明。 search.brave.com/…ave-search-crawler
- あーこ「MCPがSEO業界を変える？―記事量産と検索順位レポートの価値が下がる理由」（note・2026年8月3日）。MCPで検索を経由しない経路が増え、流入依存のビジネスモデルが影響を受けるとの論考。 note記事
- Model Context Protocol「Versioning」。現行仕様が2026-07-28版であることを明記。 modelcontextprotocol.io/specification/versioning
- W3C Web Machine Learningコミュニティグループ「WebMCP」。GoogleとMicrosoftのエンジニアが提案したWeb標準の規格案。 https://github.com/webmachinelearning/webmcp
- Cloudflare「Bringing agents to the browser with WebMCP」（2026年8月）。WebMCP開発者プレビューの発表。 https://blog.cloudflare.com/webmcp/
- llms.txt の仕様。 https://llmstxt.org/
