Perplexityが禁止サイトに偽装アクセスして情報収集

AI検索エンジン「Perplexity」が、アクセスを拒否しているWebサイトからも密かにデータを取得していた。Cloudflareの調査により、ステルス技術を使ったスクレイピングの実態が明らかになりました。
AIの進化と引き換えに、ウェブの信頼はどう守られるべきなのか。本記事ではその手口、業界の反応、日本への影響までをわかりやすく解説します。
Perplexityが引き起こした“ステルスクローラー”問題とは
AI検索エンジンを開発するスタートアップ「Perplexity」が、Webサイト運営者の意思を無視してデータを取得していたとして問題になっています。
インターネットインフラ大手のCloudflareが2025年8月に公開した調査報告では、Perplexityがアクセス制限をかけたWebサイトに対しても、技術的な手段を用いて情報を取得していたとされています。
これにより、AIがWeb上のコンテンツを活用する際のモラルやルールが、あらためて問われる事態となっています。では、実際に何が問題だったのか、どのような手口が使われていたのかを見ていきましょう。
Cloudflareが指摘した「2種類のクローラー」
Perplexityは、公式に「Perplexity-User」や「PerplexityBot」といったユーザーエージェント(Webにアクセスする際の識別情報)を公開しています。通常、こうした正規のボットはrobots.txtというファイルを参照し、アクセスの可否を判断します。
しかし、Cloudflareの調査によれば、Perplexityは正規のボットがブロックされた場合に、Chromeブラウザを装った「ステルスボット」を使用していたといいます。


このステルスボットは、Google Chrome on macOSと同様のユーザーエージェントを使用し、サイト側に自動化されたアクセスであることを隠していました。
さらに問題なのは、この偽装ボットがPerplexityの公式IPアドレス帯とは異なるIPを使用していた点です。つまり、Webサイト側でPerplexityをブロックしていても、完全には防げない状況が生まれていたのです。
robots.txtを無視?AI企業が直面するコンテンツ取得の壁
robots.txtは、Webサイトの運営者が「このページはクロールしないでください」と明示するための業界標準の仕組みです。通常、検索エンジンやクローラーはこれを尊重し、指定されたページにはアクセスしません。
ところがPerplexityは、このrobots.txtの指示を無視、あるいはそもそも読み込まない形でアクセスしていたケースがあったとされます。
Cloudflareは、顧客からの通報を受けて調査を開始。複数のWebサイトで、Perplexityが禁止されているはずの領域にもアクセスしていたことを確認しました。
これは、単なる技術的問題ではありません。インターネットは「相手の意思を尊重する」という暗黙のルールの上に成り立っており、それを破る行為は業界の信頼を損なう可能性があります。
Cloudflareの検証と技術的な発見:どう見破ったのか?
Perplexityの行動が表面化した背景には、Cloudflareの高度な検証手法とネットワーク監視のノウハウがあります。
単なるアクセスログの解析だけではなく、AIやネットワーク指標を用いた「見えないボット」の特定に成功した点は、今回の問題を明るみに出す大きな要因となりました。
非公開ドメインを用いた検証とPerplexityの回答内容
Cloudflareは、Perplexityの挙動を検証するために、誰にも公開していない複数のテスト用ドメイン(例:testexample.com、secretexample.com)を新たに作成しました。
これらのドメインは、検索エンジンにも登録されておらず、外部から発見される可能性がないように設定されていました。
さらに、robots.txtファイルには「すべてのボットのアクセスを拒否する」設定を記述し、WAF(Web Application Firewall)でもPerplexityの既知のボットをブロック。つまり、正規のクローラーではアクセスできない状態を意図的に作り出したのです。
その状態でPerplexityに対してこれらのドメインに関する質問を投げかけたところ、驚くべきことに、Perplexityは非公開ドメインに実際に掲載されていたコンテンツの詳細を返答として生成。これは明らかに、通常のアクセス制限を回避して情報を取得していた証拠となりました。
ユーザーエージェント偽装/ASNローテーションの手口
Cloudflareが最も注目したのは、Perplexityが使っていた「ステルス技術」です。Perplexityのボットは、ブロックを受けると以下のような手口で偽装アクセスを試みていたといいます。
- ユーザーエージェントをGoogle Chrome on macOSに偽装(例:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...) - 自社IPレンジ外のアドレスを使用してアクセス
- 異なるASN(インターネット上の自律システム番号)を切り替えながらリクエストを送信
以下の表は、Cloudflareが観測したPerplexityの2種類のクローラーの特徴を整理したものです。
| 種別 | ユーザーエージェント | 1日のリクエスト数 | IPの特性 |
|---|---|---|---|
| 正規クローラー | Perplexity-User / PerplexityBot | 約2,000万〜2,500万 | 公式IPレンジ |
| ステルスクローラー | Chrome on macOSを装ったUA | 約300万〜600万 | 非公開IP・ASNローテーション |
Cloudflareは、機械学習とネットワーク上の信号を組み合わせた「フィンガープリンティング」により、このステルスボットを特定。こうした技術がなければ、Perplexityの行動は見逃されていた可能性もあります。
Perplexityはなぜ“倫理的批判”を受けているのか
Perplexityの行動に対して批判が高まっているのは、単なる技術的な手口の問題ではなく、インターネットにおける信頼関係や倫理の側面が関わっているからです。
AIが急速に進化する一方で、その裏側で「データは勝手に使ってもいいのか?」という根本的な問いが突きつけられています。
AI開発と「無断学習」問題:何が許されて、何がNGか
AIモデルの精度向上には、大量のテキストや画像、動画などの学習データが必要です。そのため、多くのAI企業がインターネット上の情報を収集・活用してきました。
しかし近年では、著作権や利用許諾の問題が取り沙汰されるようになり、無断でのスクレイピングやコンテンツ使用に対する社会的な目が厳しくなっています。
Perplexityも過去に、米Wiredなど複数のメディアから「記事の内容を盗用している」と指摘を受けたことがあります。
実際に、Disrupt 2024というイベントでPerplexityのCEOが「盗用と学習の違い」について問われた際、明確な答えを出せなかったことも、企業姿勢への不信を高める結果となりました。
今回のステルスクローラー問題は、こうした流れの中で「意図的なルール無視」が表面化した例として、特に批判を集めています。技術的に可能だからといって、それが許されるわけではないという基本的な価値観が問われているのです。
OpenAIはなぜ模範とされたのか?
同じAI企業でも、Cloudflareが高く評価したのがOpenAIの姿勢です。OpenAIは自社のクローラー(例:ChatGPT-User)を明確に定義し、ユーザーエージェントやIP情報も公開。
さらに、robots.txtでのブロック指示を正しく読み取り、アクセスを停止する動作を確認済みだとCloudflareは報告しています。
Cloudflareは、OpenAIが提案した「Web Bot Auth」という新たな認証方式を紹介し、これが将来的な業界標準になり得るとしています。
実際に、OpenAIはこの方式を使ってHTTPリクエストに正しい署名を付与し、サイト運営者が「誰がアクセスしているか」を識別しやすくする取り組みを進めています。
以下に、PerplexityとOpenAIの対応姿勢の違いを簡潔に整理します。
| 企業名 | ユーザーエージェントの公開 | robots.txtの遵守 | IPの透明性 | 追加偽装の有無 |
|---|---|---|---|---|
| Perplexity | 一部公開 | 多くのケースで無視 | 一部不明確 | あり(ステルスボット) |
| OpenAI | 完全公開 | 遵守 | 明示されている | なし |
この比較からも明らかなように、同じAI開発でも企業によって倫理やルールに対する姿勢には大きな差があります。今後、どのようなルールが標準になるかを考える上でも、OpenAIの取り組みは重要な指標となるでしょう。
この問題が示す今後の課題と日本への影響
Perplexityのステルスクローラー問題は、AIとウェブの関係性におけるグローバルな課題を浮き彫りにしました。今後、同様の問題はさらに複雑化・拡大していく可能性があります。
では、この事例から私たちは何を学び、日本のWeb運営者やコンテンツホルダーはどう備えるべきなのでしょうか。
AI時代におけるコンテンツ保護:運営者が取るべき3つの対策
Webサイトのコンテンツが無断でAIの学習に利用されるリスクは、今後さらに高まっていきます。とくに日本の中小メディアや個人ブログは、対策が不十分なまま標的になるケースも考えられます。そこで重要となるのが、以下のような技術的な防衛策です。
- robots.txtの適切な設定:AIクローラーを明示的に拒否する記述(例:User-agent: GPTBot / Disallow: /)を導入
- WAFによるIP制限・ボットブロック:主要なボットのIPレンジをブロックする設定を強化
- AIクローラー対策サービスの導入:Cloudflareなどが提供するAIスクレイピングブロック機能を活用
とくにCloudflareは、無料プランでも「AIクローラーのブロック機能」を提供しており、手軽に導入できるのが魅力です。自サイトがAI学習に使われるリスクを自覚し、あらかじめ防御策を講じておくことが今後は不可欠になるでしょう。
今後求められるグローバルなルールと標準化の動き
今回のような問題を防ぐには、企業単位の努力だけでは限界があります。より本質的には、「AIによるデータ収集は何を許可とし、何を禁止とするか」という国際的な合意や標準化が求められています。
Cloudflareは、IETF(Internet Engineering Task Force)と連携し、robots.txtの拡張仕様やWeb Bot Authの標準化に取り組んでいます。
これにより、将来的にはAIクローラーが正確に識別され、サイト側が明確なポリシーで許可・拒否を設定できる時代が来るかもしれません。
また、Cloudflareは「Content Independence Day」と題した取り組みの中で、AIによる学習拒否を明示する機能を強化。すでに250万以上のWebサイトがAIトレーニングを明示的に拒否していると発表されています。
こうした動きは日本国内のサイト運営者にも大きな示唆を与えます。自社コンテンツの保護やAI活用との付き合い方を見直すうえで、今後のルール形成動向に注目することが重要です。
AIが日常に溶け込む時代だからこそ、技術だけでなく「ルールと信頼」に基づいたインターネットのあり方が、あらためて問われています。








