AIに読まれているかを測る方法｜robots.txtとサーバー設定の食い違いを見つけて直す手順

執筆: 魚住琢（株式会社SAL代表取締役） / SNS常駐支援の提供会社 / 貝印・霧島酒造・横河電機・oakley・adidas-outdoorなど全国規模で展開する企業への支援実績多数

「AI検索で競合ばかり出てきて、うちが出てこない。記事は書いているのに、何が足りないのか」——当社にご相談いただくWeb担当者やマーケティング責任者の方から、こうした声を聞く機会が増えました。

この記事では、次の順に整理します。

  • AI検索に出てこない原因が、コンテンツより手前にあることがある理由
  • それが日本の主要103サイトでどのくらい起きているか（実測データ）
  • 自社サイトの状態を、その場で測る方法（無料ツール aio.sal.ne.jp を公開しています）
  • 測った結果をどう読み、どこから直すか
  • 直したあと、何を記録し、どう測り続けるか

先に結論です。AI検索に引用されない原因が、コンテンツより手前にあることがあります。robots.txtで禁止していないのに、サーバーやCDNがAIクローラを拒否している状態です。当社が2026年8月7日に日本の主要103サイトを実測したところ、計測が成立した86サイトのうち9サイト（10.5%）でこの食い違いが起きていました。

そして厄介なのは、この状態がrobots.txtを見ているだけでは分からないことです。だからまず、測れるようにするところから始めます。

なぜ「引用されない」の前に確認すべきことがあるのか？

AIクローラが自社のページを取得できていなければ、その経路からの発見・引用は起きにくくなるからです。

AI検索対策の相談は、多くの場合「どう書けば引用されるか」から始まります。構造化データを入れる、FAQを足す、一次情報を厚くする。いずれも有効ですが、それらは「AIクローラがページを取得できている」ことを前提にしています。

（※AIクローラとは、AIの学習や回答生成のために、Web上のページを自動で読みに来るプログラムです。ChatGPTのGPTBot、ClaudeのClaudeBotなどが該当します。）

順番を整理すると、こうなります。

  1. 到達性 — AIクローラがページを取得できるか（この記事の範囲）
  2. 可読性 — 取得したページから、AIが事実を読み取れるか
  3. 引用価値 — 読み取った内容が、回答に使う価値があるか

3から手をつけても、1が壊れていれば、その経路からは届きません。そして1は、測れば数分で分かります。

当社自身も、構造化データやFAQ整備の効果を測る過程で、robots.txt上の宣言とは別に、GPTBotを名乗る外部アクセスに403（アクセス拒否）が返る不整合を見つけました。原因は、レンタルサーバーの管理画面にあった「AIクローラーを制限する」という設定です。誰かが悪意で設定したものではなく、既定で有効になっていました。

ひとつ補足しておきます。この403が、AI検索での引用が伸びなかった原因だと確定したわけではありません。GPTBotは主に学習用で、ChatGPTの検索・引用にはOAI-SearchBotという別のクローラが使われます。原因を特定したというより、インフラ側の設定が意図したbot区分と一致しているかを点検するきっかけになった、という話です。

robots.txtを見るだけでは、なぜ足りないのか？

「許可する」と書く場所と、実際にアクセスを止めている場所が、別々だからです。

AIクローラの許可・不許可は robots.txt に書きます。しかし実際にアクセスを遮断しているのは、サーバー本体、WAF、CDN、レンタルサーバーの管理画面、セキュリティ系プラグインといった、robots.txt とはまったく別の場所です。

（※robots.txtとは、サイトの最上位に置き、クローラに「どこを読んでよいか」を伝えるテキストファイルです。強制力はなく、あくまで意思表示です。）

宣言と実装が別なので、両者は簡単に食い違います。そして robots.txtだけを確認していると、この食い違いには気づけません。開いても「許可」としか書いていないからです。robots.txt の記述だけを読むチェックツールも、同じ理由で「問題なし」と表示します。

つまり、放っておくと気づけない類の問題です。だから「気にする」ではなく「測る」必要があります。

どのくらいの企業で起きているのか？

計測が成立した86サイトのうち9サイト（10.5%）で、robots.txtで禁止していないのにサーバーが拒否していました。

2026年8月7日、日本の主要103サイトへ6種類のクローラのUser-Agentを名乗って接続し、応答を記録しました。

実測した内容結果
計測が成立したサイト（通常のブラウザで到達できた）103サイト中 86サイト
robots.txtで禁止していないのに、外形的に拒否された9サイト（10.5%）
うち、Googlebotは通過するのにAIクローラだけ拒否6サイト
robots.txtにAIクローラを名指しした記述を確認できた10サイト（11.6%）
robots.txtが無い、または空だった24サイト（27.9%）
GPTBotを名乗るとrobots.txt自体が取得できなかった6サイト

この調査は、大手・中堅の著名サイトを中心に選んだ便宜標本です。無作為抽出ではなく、単一時点・単一の接続元から測っています。中小企業やレンタルサーバー上のWordPressサイトでは比率が異なる可能性があります。詳しい方法と限界は調査レポート全文（aio.sal.ne.jp/report/ai-crawler-japan-2026/）に公開しています。

もうひとつ、実務上重い数字があります。AIクローラを名指しした記述を確認できたのは10サイト（11.6%）だけで、残る76サイト（88.4%）では確認できませんでした。

ただし、これを「何も決めていない」と読むのは行き過ぎです。User-agent: * の記述があれば、そのルールはAIクローラにも適用されます。CDNやWAF側で方針を実装している場合もあります。この数字が示しているのは「AIクローラを名指しした意思表示は読み取れなかった」ところまでです。

いずれにせよ、自社がこの9サイト側なのか、そうでないのかは、測らないと分かりません。

自社サイトの状態を、その場で測るには？

ドメインを入力すれば、6種類のクローラを名乗って実際に接続し、応答を並べて表示します。無料で公開しています。

当社は、この記事で説明する確認作業をまとめて実行する検査ツールを公開しています。

AIクローラ到達性チェック（無料・登録不要）

https://aio.sal.ne.jp/

自社サイトのドメインを入力すると、次を自動で行います。

  • 通常のブラウザとして接続し、対照群として応答を取得する
  • robots.txt を、通常UAとGPTBot名義の2通りで取得する
  • 学習用・検索用のAIクローラ5種類と、対照のGooglebotで接続する
  • 拒否と見えたものは、間隔を空けて再検査する

結果は、robots.txtの記述と、実際のサーバー応答を左右に並べて表示します。この2つが食い違っていれば、それが本記事で扱っている状態です。

なぜ対照群にGooglebotを混ぜているかというと、「AIクローラだけが狙って止められているのか」「自動アクセス全般が止められているのか」で、直す場所が変わるからです。Googlebotは通るのにAIクローラだけ弾かれるなら、User-Agentの文字列を見て判定している疑いが強い。両方弾かれるなら、bot全般を止める設定です。

調査に使った103サイトの実測データも、匿名化して同じサイトで公開しています。自社の結果が全体の中でどのあたりなのかを見比べられます。

1回の検査で十数件以内のHTTPリクエストを送り、同一ドメインの結果は5分間再利用します。通常は小さい負荷ですが、閲覧1回とまったく同じではありません。自社サイト、または調査の許可があるサイトでご利用ください。

結果をどう読むか

判定は4通りです。

表示意味次にすること
要確認robots.txtが禁止していないのに、拒否が返っている後述の手順で、どの層が止めているかを探す
方針どおりの遮断robots.txtの記述と実際の挙動が一致している意図どおりなら対応不要。区分の見直しだけ検討
拒否は確認されず今回の接続では拒否応答が出なかったrobots.txtに方針を書けているかを確認
計測できず混雑・無応答などで判定できなかった時間を空けて再検査

「拒否は確認されず」は「問題なし」ではありません。測れた範囲で拒否が出なかったという意味です。この違いは後述の「限界」で説明します。

手で確かめたい場合は、どうすればよいのか？

ツールと同じことを、ブラウザとコマンドで確認できます。仕組みを理解しておくと、結果の意味が分かり、保守会社への説明もしやすくなります。

robots.txtに何が書いてあるかを、どう読むのか？

ブラウザのアドレスバーに、自社サイトのURLの末尾へ /robots.txt を付けてアクセスします（例: https://www.example.co.jp/robots.txt）。

読む順番が決まっています。

  1. User-agent: GPTBot のように、そのクローラを名指ししたグループがあれば、そのグループのルールだけを読む（* のルールは適用されません）
  2. 名指しのグループがなければ、User-agent: * のグループのルールを読む
  3. どちらも無ければ、robots.txt上は制限なし

そのうえで、確認したいURLに対して最も長く一致する Allow / Disallow を見ます。Allow: / が1行あっても、同じグループ内に Disallow: /products/ があれば、/products/ 配下はそちらが優先されます。

「AIクローラの名前が無い＝許可」ではありません。名指しが無くても、User-agent: * に Disallow: / があれば、GPTBotにもサイト全体の拒否が適用されます。

User-agent: *
Disallow: /

robots.txtが取得できなかった場合の扱いも決まっています。

robots.txtの状態仕様上の扱い（RFC 9309）
404 など4xxクローラはアクセスしてよい（MAY）。禁止されていない扱い
5xx やネットワーク障害一時的に全面拒否と仮定される。サーバー不調が続くと、クロール自体が止まり得る

5xxのケースは見落とされがちです。robots.txtを返すサーバーが不安定だと、中身の記述に関係なくクロールが止まります。

実際のサーバー応答を、どう確かめるのか？

Macなら「ターミナル」、Windowsなら「PowerShell」を開き、URL部分を自社サイトに書き換えて実行します。

curl -sS -L -A "Mozilla/5.0 (compatible; GPTBot/1.4; +https://openai.com/gptbot)" -o /dev/null -w "HTTP %{http_code}  %{url_effective}\n" https://www.example.co.jp/

Windowsの PowerShell では、標準の別名と衝突するため curl ではなく curl.exe と書いてください。

このコマンドは、GPTBotを名乗って通常どおりページを取得し（-L でリダイレクトを最後まで追い）、本文は保存せずに最終的なステータスと到達URLだけを表示します。

-I は使わないでください。-I はHEADという別のメソッドになり、当社の調査や検査ツールが使っているGETとは条件が変わります。HEADに対応していないサーバーは、GETなら取得できるのに405を返すことがあり、それを「拒否」と誤読する原因になります。

比較のため、Googlebotと通常のブラウザでも同じことをします。ここが最も重要です。

curl.exe -sS -L -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -o /dev/null -w "HTTP %{http_code}  %{url_effective}\n" https://www.example.co.jp/

通常のブラウザとGooglebotは通るのにAIクローラだけ弾かれ、それが時間を空けても再現するなら、User-Agentを見て判定している疑いが強いと言えます。

なお、User-Agentのバージョン番号は変わります（本稿執筆時点でOpenAIの公式例は GPTBot/1.4）。判定に使われるのは主に GPTBot という名前の部分です。最新の一覧は各社の公式ドキュメントで確認してください。

返ってきた番号を、どう読み分けるのか？

応答読み方次にすること
200HTTP上は成功。ただし本文が目的のページとは限らない後述のソフトブロック確認
401認証が必要。bot名を理由にした拒否とは限らない通常UAとの差、認証・WAF設定を確認
403要求を理解したうえで拒否通常UA・Googlebotとの対照、時間を空けて再検査
405そのメソッドが許可されていないHEADで試したならGETで再確認
429リクエスト過多。拒否ではないRetry-After を見て、間隔を空けて再検査
503一時的に処理できない。429と同義ではない障害・保守情報とWAFログを確認
3xxリダイレクト最終URLまで追う
応答なし・タイムアウト判定不能時間を空けて再検査

429 と 503 を「拒否された」と数えないでください。混んでいる、あるいは一時的に落ちているという意味で、名前を見て弾かれたわけではありません。応答が返らない場合も同じで、「通った」でも「拒否された」でもなく「測れなかった」です。

当社もここを間違えました。最初に公開した集計では429を拒否に数え、応答なしを通過に数えていたため、該当サイト数を10サイトと発表しました。指摘を受けて数え直し、9サイト（10.5%）に修正しています。経緯は調査レポートの変更履歴に残しました。混雑と拒否を分けないと、直す必要のないサイトを直しに行くことになります。

200なのに読めていないことがあるのですか？

あります。ステータスは200でも、中身がCAPTCHA、JavaScriptが必要な確認画面、空のページ、同意バナーだけ、ということがあります。「ソフトブロック」と呼ばれる状態です。

curl.exe -s -L -A "Mozilla/5.0 (compatible; GPTBot/1.4; +https://openai.com/gptbot)" https://www.example.co.jp/ | head -c 500

ここだけ -sS ではなく -s にしています。head が途中で受け取りを打ち切るため、-sS のままだと本文のあとに curl: (56) という表示が出て紛らわしいためです。

通常のブラウザのUser-Agentでも同じことをして、タイトルや本文の書き出しが同じかを見てください。bot側だけ「Just a moment…」「アクセスが制限されています」といった内容なら、200でも実質的に読めていません。

トップページだけ見ていればよいのか？

いいえ。robots.txtはパスごとにルールを書けますし、WAFのルールもURL単位で設定できます。トップページが200でも、製品ページ、導入事例、PDF、ブログ配下だけが拒否されていることがあります。

AIに読ませたい代表的なURLを3〜5本選び、同じ手順で確認してください。加えて、次の違いも見ておきます。

  • www あり / なし
  • http / https
  • 別サブドメイン（blog. など、別サイトとして動いているもの）

これらは別々に設定されていることがあります。

拒否されていたら、どこから調べるのか？

robots.txtを書き換えても直りません。止めているのはrobots.txtではないからです。

これが最も多い遠回りです。「拒否されている」と分かった時、robots.txt に Allow: / を書き足して終わりにしてしまう。しかし止めているのは別の場所なので、状況は変わりません。

当社が支援で確認してきた事例では、次の順に調べると原因に当たることが多くありました。

1. レンタルサーバーの管理画面

エックスサーバー、さくらのレンタルサーバなどの管理画面に、「AIクローラーを制限する」「AIデータスクレイパーを制限する」といった項目があります。既定で有効になっていることがあります。学習用・検索用・アシスタントで別項目に分かれている場合は、後述の区分に照らして個別に判断してください。当社の事例もここが原因でした。

2. WAF・セキュリティ系プラグイン

WordPressのセキュリティプラグインが、既知のボットを一括で拒否している例があります。管理画面のボット対策設定を確認します。

（※WAFとは、不正なアクセスを検知して遮断する仕組みです。サーバー会社が提供している場合と、CDN側にある場合があります。）

3. CDN

CloudflareなどのCDNでは、AI botを検索用・エージェント用・学習用といった区分や、個別のクローラ単位で制御できる場合があります。ただし、以前の設定が残っていたり、広すぎるカスタムルールが入っていたりすると、許可したい区分まで止まります。

4. サーバー設定ファイル

.htaccess や nginx の設定に、User-Agent判定が手で書かれていることがあります。設定ファイル内を SetEnvIf User-Agent（Apache）や $http_user_agent（nginx）といった文字列で検索すると見つかります。これは探すための手がかりであって、そのまま貼り付けて使う設定例ではありません。変更は保守会社かインフラ担当の方に依頼してください。

注意点がひとつあります。CDNで遮断されている場合、オリジンサーバーのアクセスログには何も残りません。ログを見て「何も来ていない」と分かったら、それはCDN/WAFの段階で止まっている可能性を示しています。CDNのイベントログ、ロードバランサ、Webサーバーの順に見てください。

1箇所直すたびに、もう一度測ってください。ひとつ解除しても、別の層がまだ止めていることがあります。ツールなら結果が並ぶので、どのクローラが解除できてどれが残っているかがそのまま見えます。

どのクローラを通すかは、どう決めればよいのか？

区分によって効果が違い、「拒否すれば必ずこうなる」と言い切れるものは多くありません。

「AIに学習されたくない」という理由で一括遮断すると、AI検索に引用される経路まで同時に塞ぐことがあります。判断の材料として、言える範囲を整理します。

区分代表例拒否した場合に言える範囲
学習・データ収集GPTBot ／ ClaudeBot ／ CCBot将来の学習・データ収集への利用を抑える意思表示になる。既存モデルから情報が消える保証はない
検索・索引OAI-SearchBot ／ Claude-SearchBot ／ PerplexityBot検索回答での発見・引用の機会が減る可能性がある。影響の度合いは各社仕様で異なる
ユーザー起点の取得ChatGPT-User ／ Claude-User ／ Perplexity-Userrobots.txtの扱いがサービスごとに異なる。WAF/CDN側で止めれば、利用者がURLを貼っても読めなくなる可能性がある
利用制御トークンGoogle-Extended独立したクローラではない。Googleが取得済みのコンテンツを、Geminiの学習やグラウンディングに使うかどうかを制御するrobots.txt用の名前

CCBotはCommon Crawlのクローラで、特定のAI事業者の学習botではありません。公開アーカイブを作る団体のもので、そのデータが各社に使われることがある、という関係です。

ユーザー起点の取得は、robots.txtで制御できるとは限りません。OpenAIはChatGPT-Userについてrobots.txtが適用されない場合があるとしており、Perplexityも自社のユーザー起点クローラについて一般にrobots.txtに従わない旨を公開しています。この区分を止めたい場合は、WAF/CDN側での制御が必要です。

有料コンテンツを持つメディアが学習用だけを拒否するのは、合理的な判断です。一方、発見されたいBtoB企業が学習用も検索用も一括で塞いでいるなら、それはたいてい意図ではありません。

直したあと、何を残し、どう測り続けるのか？

robots.txtに方針を書き、変更の記録を残し、定期的に測り直してください。

サーバー側で通るようにしただけでは、また同じことが起きます。設定は自分以外の手で変わるからです。制作会社によるサイト改修、プラグインの更新、サーバー移転、CDNの設定変更。一度直しても、また壊れます。

robots.txtに方針を書く

検索・引用の経路を開けておきたい場合の記述例です。

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

学習・データ収集まで許可するかは、広報だけでなく法務・知財・情報セキュリティの判断が絡みます。目的が「AI検索で見つかること」だけなら、学習用（GPTBot、ClaudeBot、CCBot）の許可は必須ではありません。これは目的別の記述例であって、どのサイトにも当てはまる設定ではありません。既存の User-agent: * や、パス別の Disallow と競合しないかを確認してから変更してください。

変更を記録する

  • 変更前の設定のバックアップ
  • 対象のbot、対象のパス、変更の目的
  • 変更者と変更日
  • 戻し方

意図が残っていないと、数年後に別の担当者が「不要なアクセスだ」と判断して、また塞ぎます。

定点で測る

半年に一度、同じ確認をする運用にしておくのが現実的です。AIクローラの名前は増え続けており、数年前の設定は今はもう不完全です。サイト改修やサーバー移転の直後も、測り直すタイミングです。

aio.sal.ne.jp は登録不要で何度でも使えるので、改修後のチェックリストに1行加えておくと、壊れたことに早く気づけます。

なお、クローラはrobots.txtをキャッシュするため、直した直後の外形確認と、実際のbotの挙動が一致するとは限りません。OpenAIは変更の反映に24時間程度かかり得るとしています。

この測り方の限界はどこにあるのか？

外から名乗って接続する方法では、IPアドレスで本物のクローラだけを許可している設定を見分けられません。

ここは正直に書いておきます。本記事の方法も、当社のツールも、User-Agentという「名乗り」を変えて外から接続しているだけです。誰でもGPTBotを名乗れます。

そのため、セキュリティ意識の高いサイトでは、名乗りだけでなく「アクセス元のIPアドレスが公式のものか」を照合していることがあります。この設定があるサイトに外から名乗って接続すると、偽物と判定されて拒否されます。外形確認で「拒否」と出ても、本物のクローラは通っている可能性があるということです。

したがって、この方法で分かるのは次の範囲です。

分かること分からないこと
robots.txtの記述と、外形的な応答が食い違っているか本物のクローラが実際に通れているか
通常ブラウザやGooglebotと比べて、扱いが違うか拒否が意図的か、設定事故か
調べるべき箇所を絞り込めるか「読まれていない」と断定できるか

確定させるには、CDN/WAFのイベントログとオリジンサーバーのログを突き合わせ、各社が公開している公式IPレンジや、CDNの認証済みbot判定と照合します。そこまでやって初めて「読まれていない」と言えます。当社のツールが「読まれていません」と断定せず「要確認」と表示するのも、同じ理由です。

逆に、この照合を前提にすると、WAFで「GPTBotという文字列を含むUser-Agentを許可する」という設定は避けるべきです。User-Agentは誰でも名乗れるため、その許可設定は誰にでも使えてしまいます。許可するなら公式IPレンジや認証済みbot判定と組み合わせてください。

それでも、外形確認には十分な役割があります。「robots.txtは禁止していないのに403が返る」と分かれば、調べる場所は絞れます。そして何より、これまで見えていなかったものが数字になります。

よくある質問

robots.txtが無くても問題ないのですか？

仕様上、robots.txtが404などで取得できなければ、クローラはアクセスしてよいことになっています。ただしそれは「許可した」ではなく「禁止されていない」という状態です。次に誰かがサーバー設定を触った時の判断材料が残りません。当社の調査では86サイト中24サイト（27.9%）が、robots.txtが無いか空でした。

Googlebotが来ているなら大丈夫ではないですか？

そうとは限りません。当社の調査で食い違いが見つかった9サイトのうち6サイトでは、Googlebotは通過するのにAIクローラだけが拒否されていました。検索エンジン用とAI用は別のクローラなので、別々に確認する必要があります。

学習には使われたくないが、AI検索には出たい場合はどうすればよいですか？

robots.txtで学習・データ収集用（GPTBot、ClaudeBot、CCBot）を拒否し、検索・索引用（OAI-SearchBot、Claude-SearchBot、PerplexityBot）を許可する、という書き分けはできます。ただし、サーバーやCDN側で一括ブロックされていると、この細かい制御は機能しません。robots.txtの記述とインフラ側の設定を、セットで見直してください。また、拒否しても既存のモデルから情報が消えるわけではありません。

検査でサイトに負荷はかかりませんか？

curlでの確認は1回につき1リクエストです。当社のツールは1回の検査で十数件以内のリクエストを、間隔を空けて送り、同一ドメインの結果は5分間再利用して再接続しません。いずれも自社サイト、または調査の許可があるサイトでご利用ください。

直したら、いつAI検索に反映されますか？

クローラの再訪問のタイミング次第で、期間は保証できません。robots.txtはキャッシュされるため、変更の反映に時間がかかります（OpenAIは24時間程度かかり得るとしています）。当社としても、修正から引用が変わるまでの期間を実測できていないため、確かなことは申し上げられません。

自社に技術担当がいない場合はどうすればよいですか？

aio.sal.ne.jp にドメインを入れるところまでは、どなたでもできます。結果の画面をそのままサーバーの保守会社に渡してください。「このUser-Agentで403が返っている」と伝われば、調べる側は原因を絞れます。コマンドを打てなくても、話が前に進みます。

関連サービス・関連ナレッジ

お問い合わせ・ご相談

「ツールで要確認と出たが、どこを直せばよいか分からない」「CDNとサーバーのログを照合して確定させたい」「WAFやCDNの設定を、AIクローラの区分に沿って整理したい」といった段階でご相談いただけます。

株式会社SAL（東京都品川区東五反田／設立2008年7月7日／代表取締役 魚住琢）

なお、設定の調査と修正はお引き受けしますが、AI検索での引用や順位を保証するものではありません。到達性は前提条件であって、引用されるかどうかは内容と第三者からの評価によります。

株式会社SAL公式 →SNS常駐支援 →Clipkit導入 →remodooo! 在宅チーム →
タイトルとURLをコピーしました