AIクローラーを17日間調べた——名乗りと発信元の照合で分かること（2026年）

資金について：CypherpunkGuideは、関連記事で明示した紹介リンクを通じて条件を満たす購入があった場合、紹介報酬を受け取ることがある。監視型広告、広告ネットワークのスクリプト、トラッキングピクセル、スポンサー記事は載せない。

2026年9月24日訂正：初版では、IPの一致からクローラーの身元や遮断効果について言える範囲を超えて断定していた。また、llms.txtを利用拒否の仕組みとして扱い、14種類のラベルを14社と表現していた。本文と付属の集計資料を訂正し、裏づけのないAmazonbotとDNSの結論を撤回した。観測期間は2026年6月19日〜7月5日のままで、今回の更新に新しい巡回実験は含まない。

サイト運営者が分けて考えるべき問いは三つある。相手は何と名乗ったか。発信元は公表されたクローラーのIP範囲と一致するか。設定した規則によって、実際に取得を防げたか。このログが手がかりを与えるのは最初の二つであり、三つ目の答えは含まれていない。

user-agentは、プログラムが自身を名乗るために送る文字列だ。送り手が自由に選べる。IP一覧との照合は発信元を確かめる材料になるが、一覧の対象や取得時点を確認する必要がある。robots.txtは、対応するクローラーに指定した場所を取得しないよう求める。一方、サーバーやCDNでの遮断はアクセス規則を強制する。llms.txtは、言語モデルに役立つサイト情報を案内する提案であり、前の二つとは役割が違う。

AI時代の脅威モデルでは、CypherpunkGuide自身のクローラー通信を調べる方針を示した。その17日間の記録から、名乗りだけに頼る限界が見える。初版の解釈が見落としていた限界も、その中に含まれていた。

17日間の記録に含まれるもの

#

保存された集計には、AI関連のuser-agentを14種類に分類した、1,635件のリクエストがある。ここでいう分類は、user-agent内の文字列に基づいてまとめたものだ。別々の企業や、重複のない完全なuser-agent文字列を数えた値ではない。CCBotやGoogle-Extendedというラベルも含むため、商用の学習クローラー14社を調べた結果とも呼べない。

訂正版の集計資料には、件数とその限界を残した。集計値と一部のネットワーク範囲を掲載し、完全な発信元IPやリクエスト単位のログは掲載していない。読者は合計の計算を確かめられるが、この資料だけで元のIP照合を独立して再実行することはできない。

残る7分類は計101件だ。割合はリクエスト件数に基づく概数であり、訪問者、ページ、発信元アドレスの重複を除いた割合ではない。

ここでの一致は、観測したIPが7月の分析で使った参照集合に含まれていたことを指す。動いていたソフトウェアや操作者を認証したわけではなく、取得内容の用途も分からない。一致しない理由にも、別の送り手、古い・不完全な一覧、処理の誤りなどがあり得る。不一致だけで、なりすましと断定はできない。

IPの一致率は、遮断の成功率ではない

#

GPTBotとClaudeBotの一致率が示すのは、発信元アドレスとの照合結果だ。遮断前後を比較する対照実験や、学習への使用状況の確認はしていない。 この割合を根拠に「robots.txtが機能した」とした初版の結論には、裏づけがなかった。

OpenAIのクローラー資料は、クローラーの役割と制御方法を分けている。Anthropicの案内はrobots.txtでの指示を説明する一方、IPによる遮断がそのファイルの読取りを妨げる場合にも注意を促している。いずれも事業者による自社システムの説明であり、私たちの実験結果ではない。

Googleの確認手順も、クローラーの種類ごとに対象と方法を区別する。GoogleOtherは汎用クローラーだ。Google-Extendedは別の制御用指定名であり、独立したHTTP user-agentを持たない。ログにこの名前があっても、Googleによるその制御の利用状況を測ったことにはならない。

遮断を試験するなら、規則、適用時刻、クローラーの種類、その後の要求に内容を返したかを記録する必要がある。発信元の照合結果とアクセスの成否は、別の項目にする。この公開集計にはその実験がないため、遮断の成功率も、学習から除外できた割合も算出できない。

四つのネットワークに14種類のラベル、運用者は不明

#

当時のネットワーク別集計には、四つの/24範囲から来た99件に14種類のラベルが記録されている。その14種類すべてが、一つの範囲内でも観測された。/24は256個のIPv4アドレスをまとめた範囲だ。この記事の表示単位であり、最小の割当単位や一人の運用者を表す境界ではない。

14種類には、同じ企業に関係する複数の製品や、利用者の操作をきっかけに取得するものも含まれる。全体の1,635件とは抽出条件が違うため、99件を単純な内数として足し引きすることはできない。

次の表の先頭行は比較用だ。99件の集計対象は、その下の四つの範囲である。

隣接する216.73.217.0/24にはClaudeBotの265件があり、合わせて記録上の一致546件になる。この標本での結果であり、正規の設備は常に一つの名前だけを使うという法則ではない。

登録組織の確認に使ったRDAPは、IPアドレスの登録情報を公開する仕組みだ。通信を実行した利用者までは示さない。同じ貸しサーバー会社に登録された二つの範囲でも、操作者が一人とは限らない。多様な名乗りは詳しく調べる理由になるが、「一人が14社になりすました」「robots.txtを無視した」という証拠にはならない。

Amazonbotでは参照一覧の問題が未解決

#

保存された分析にはAmazonbotを名乗る344件中120件の一致が残る。しかし、35%を検証済みのAmazonbot帰属率として示すことはできない。 研究メモでは、公式一覧の件数を489と記録した一方、分析に使った抽出結果は525個のアドレスだった。ページ内のコードからクローラー以外のアドレスが混入した可能性を記し、その差を未解決としていた。

120件の一致と224件の不一致は、当時の処理結果として訂正版資料に残す。公式一覧との照合結果として確定するには、抽出した参照集合の再検証が必要だ。

初版には「不一致だった18アドレスがすべてAmazonのDNS確認を通らなかった」とも書いた。しかし、保存されたDNS集計は別の14アドレスの標本であり、この断定を裏づけない。別の標本に置き換えて根拠とすることはせず、18件についての結論を撤回する。不一致224件すべてが偽物だとは確認できていない。

新しく調べる場合は、現在のAmazonbot公式資料を使い、参照データそのものと抽出方法を保存する必要がある。クラウド事業者がアドレスを所有しているだけでは、特定のクローラーや利用者を識別できない。

DNS名を取得できなくても、身元は確定しない

#

7月の分析では、meta-externalagentを名乗る179件とBytespiderを名乗る112件の帰属を確かめていない。この分析の限界であり、原理的に検証できない、あるいは現在も確認方法が存在しないという意味ではない。

Metaの名を含む9アドレスでは、保存結果にDNS名がなかった。ただし、確認コードはすべての検索失敗を、名前が存在しないことを表すNXDOMAINとして記録していた。他の原因による失敗も区別していないため、「9件ともDNS名が存在しなかった」とは言えない。名前を取得できなかったことから、巡回規則に従ったかどうかも分からない。

llms.txtは案内であり、利用拒否ではない

#

llms.txtは、言語モデルに役立つサイト内容を案内する提案であり、取得を断るための仕組みではない。 提案の一次資料が示す目的はrobots.txtとは異なる。2024年の当初の目的も情報提供であり、この調査後に登場した新しい拒否機能ではない。

7月の研究メモには、観測期間中にAI関連と分類した通信による/llms.txtへの要求が0件だったとある。ただし、今回使った保存済み集計JSONからは、パスごとの件数を再計算できない。したがって、限界を添えて当時の報告値として残す。またGPTBotの310件はリクエスト数であり、異なる310ページや、成功した310回のダウンロードではない。

0件という報告をそのまま採用しても、分かるのは、このサイトの記録・分類方法で、その期間に該当する要求が見つからなかったことまでだ。ウェブ全体の普及率、AIによる引用、利用拒否の効果を測ってはいない。初版にあった外部の引用頻度調査との比較も、この結論を支えないため削除した。

結論：身元の照合とアクセスの成否を分ける

#

今回の記録から得られる判断材料は、初版の結論より狭い。user-agentの名乗り、IP一覧との一致、アクセスを防げた結果は、それぞれ別の証拠だ。 ログを使って判断する際は、これらを分けて扱う。

1. 目的に合う公式の巡回制御を使う。 学習用、検索用、利用者の操作による取得を区別し、IP一致を規則の遵守試験として扱わない。
2. 参照資料と方法を残す。 取得日、正確なアドレス集合、照合規則、未解決の失敗を記録する。共用設備やアドレスの不一致は注意の理由であり、送り手を自動的に断定する理由ではない。
3. アクセス制御は結果で確かめる。 非公開にすべき内容には認証・権限確認を設け、許可のない要求へ内容を返さないことを試験する。公開された拒否指示ファイルは、アクセスを阻む仕組みではない。
4. 公開記録に何を残すかを選ぶ。 すでに他所へ複製された内容は、自分のサーバーへの今後のアクセスとは別の問題だ。完全には消せない投稿や公開情報の断片からの推測にも、同じ限界が関わる。

よくある質問

#

robots.txtでAIクローラーを遮断できますか？

#

対象の規則を守るクローラーへ指示を出せますが、robots.txt自体はアクセス制御を強制しません。この調査のIP一致率も、指示に従ったかを測るものではありません。事業者の公式な制御方法を確認し、アクセスの成否は別に試験してください。非公開にすべき内容は、取得できる相手を制限する必要があります。

GPTBotやClaudeBotという名乗りは、どう確かめますか？

#

発信元IPを対象事業者の参照一覧と比較し、その版と取得日を残します。クローラーごとに確認方法が文書化されていれば、それに従ってください。一致はその範囲で発信元を判断する材料になりますが、不一致だけではなりすましと断定できません。内容がモデルの学習に使われたかも、IP照合だけでは分かりません。

llms.txtでAIによるコンテンツの利用を拒否できますか？

#

できません。llms.txtは言語モデルに役立つサイト情報を案内する提案であり、巡回拒否や学習利用からの除外を指示する仕組みではありません。7月のメモには17日間でAI関連の要求が0件とありますが、これは拒否の効果を試験した結果ではなく、保存された集計JSONからの再計算もできません。

AIクローラーのなりすましとは何ですか？

#

そのクローラーではない送り手が、クローラーの名前を名乗ることです。user-agentは送り手が選べますが、一覧との不一致や共用ホスティングだけでは、なりすましと確定できません。今回の四つの範囲での観測は注意を促す材料です。誰が実行したか、robots.txtを無視したかまでは示しません。

すべてのクローラーを識別できない場合、何をすべきですか？

#

非公開にすべき内容にはアクセス制御を使い、その動作を試験してください。公開ページでは、文書化された巡回の希望を設定し、結果を観察して、分析に残る不確実性を明示します。自分のサイトへの要求の記録だけで、他所から複製が取得されていないことや、その後利用されていないことまで証明することはできません。

出典

#

外部資料の確認日は2026年9月24日。保存版の日付は観測期間と異なり、当時のIP一覧を再現する資料ではない。

訂正版の集計資料には、当時の件数と撤回した結論を残している。9月24日の更新は保存済み集計と方法の点検であり、90日後の再測定や、条件を制御した遮断実験の結果ではない。

この事例は、開かれたウェブの囲い込みを考える材料になる。ただし、一つのサイトのログから、その広い議論を証明するものではない。自己監査ツールが扱うのは別の問いだ。自分に関する公開情報のうち、何が見つかり、何を確かめられるかを調べる。