PerplexityBot

PerplexityBotとは何か

PerplexityBotは、Perplexityの検索・回答機能に自社ページを「出典として並べる」ための候補を集める検索系クローラーです。公式のフルUA文字列（＝正式な名乗り）は `Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)` で、末尾のURLは説明ページへの案内です。Perplexityは自社ボットの公式IPアドレス一覧を機械可読ファイル（perplexitybot.json）で公開しており、UA名の一致だけでなくアクセス元IPが公式範囲かどうかで本物を確かめられるようにしています。

公式の推奨は明快です。Perplexityの検索結果に自社を表示させたいなら、robots.txtでPerplexityBotを許可し、公開IPレンジからのリクエストを通すこと。逆に載せたくないなら、robots.txtで拒否します。この「載る／載らない」がAI検索での露出に直結するため、PerplexityBotの扱いは方針判断（＝検索露出を取りに行くか、コンテンツ保護を優先するか）そのものになります。

UA文字列の読み方

PerplexityBotのUA文字列は、先頭こそ一般的なブラウザ風の名乗り（`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; …`）で始まりますが、判別の軸は括弧内に含まれる「PerplexityBot」という語です。多くのボットが互換性のために先頭をブラウザ風に偽装しますが、これは「昔ながらのブラウザ判定を通すための慣習」で、正体を隠す意図とは限りません。読むべきは `compatible; PerplexityBot/1.0` の部分と、末尾の説明URL `+https://perplexity.ai/perplexitybot` です。ログ集計では「PerplexityBot」を部分一致で拾い、同時に「Perplexity-User」（＝ユーザー起点の取得系）も別カウントで拾って区別します。両者はUA文字列が似ているため、`PerplexityBot` と `Perplexity-User` を取り違えない集計ルールにしておくのが実務の要点です。

もう一点、UAの先頭がブラウザ風だからといって「隠れて巡回している」と決めつけない冷静さも要ります。互換表記は業界の慣習で、PerplexityBotに限らず多くの正規ボットが採用しています。正体を確かめる本筋は、UA文字列の見た目ではなく、公式IPレンジ（perplexitybot.json）との照合と逆引きDNSの往復一致です。逆に言えば、UAが立派に見えても公式IPから外れていれば疑うべきで、この「見た目でなく出所で判断する」姿勢が、後述するステルス巡回の指摘に対する現実的な備えになります。

なぜ重要か（可視化の文脈）

AI検索の可視化を測るうえで、PerplexityBotは「回答の出典に載るための入口」として、学習系クローラーより成果に近い位置にあります。PerplexityBotに取得・索引化されたページは、ユーザーの質問に対する回答の出典欄に引用される候補になります。つまり、ここへのアクセスがある＝出典露出のチャンスがある、と読めます（ただし取得＝必ず引用、ではありません）。当ラボの引用計測でも、Perplexity系は「回答・検索系」に分類し、学習・収集系（訓練データ集め）とは指標を分けて扱っています。

仕組み（2種類のボットの違い）

具体例・データ

• PerplexityBotの公式UA：`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)`。
• Perplexity-Userの公式UA：`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)`。
• 公式IP一覧：perplexitybot.json（Perplexityが公開する機械可読ファイル）でIPレンジを配布。UA照合に加えてIP照合で本物を確認します。
• 外部からの指摘（2024年）：WIREDは2024年6月19日、robots.txtでPerplexityのクローラーを拒否していたWIRED.comとCondé Nast（＝WIREDを発行する米出版社）の各サイトへ、Perplexityが公開していないIPアドレス（44.221.181.252）からアクセスがあったと報じました。同記事でPerplexityのAravind Srinivas CEOは「WIREDの質問はPerplexityとインターネットの仕組みに対する根深い誤解を反映している」との声明を出しましたが、記事が挙げた個別の事実関係には反論していないとWIREDは記しています。
• 外部からの指摘（2025年）：Cloudflareは2025年8月4日、robots.txtで全自動アクセスを禁止し、WAF（＝Webアプリを守る防御層）でPerplexityの公開クローラーを遮断した検証用ドメインに対して、Perplexityが宣言済みのUAに加え、macOS版Google Chromeを装う未宣言のUA（`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36`）でアクセスしてきたと報告しました。公式IPレンジ外のIPやASN（＝インターネット上のネットワークの管理単位）を切り替える挙動が、数万ドメイン・1日あたり数百万リクエストの規模で観測されたとしています。Cloudflareはこれを受けてPerplexityをVerified Bots（＝正規のボットとして認証する一覧）から外し、この挙動を遮断する検知ルールを追加しました。
• Perplexity側の反論：Perplexityは同じ2025年8月4日に反論記事を公開し、ユーザーの求めに応じてその場で取りに行く「ユーザー起点の取得」は自動巡回とは別物だと主張しました。そのうえで、Cloudflareがステルスと判断した1日300万〜600万リクエストはBrowserBase（＝第三者が提供するクラウド上のブラウザサービス）のトラフィックの取り違えであり、Perplexity自身の利用は1日45,000リクエスト未満だと述べています。両者の主張は対立したままで、当ラボはどちらが正しいかを判定できる一次データを持っていません。
• robots.txtでの拒否例：`User-agent: PerplexityBot` の行に続けて `Disallow: /` を書くと索引用の巡回を全体で拒否できます。一部だけなら `Disallow: /private/` のようにパスを指定します。Perplexity-Userも止めたいなら `User-agent: Perplexity-User` の行を別に足すが、ユーザー起点の取得は必ずしも従わない前提で考えます。
• 逆引きDNSでの本物判定：疑わしいアクセスは、アクセス元IPを逆引きしてPerplexityの正規ホスト名に解決されるか、さらに順引き逆引きが往復一致するか（forward-confirmed reverse DNS）を確かめます。perplexitybot.jsonのIP照合と併用すると、UA詐称やステルス巡回の疑いを切り分けやすいです。

よくある誤解・注意点

実務での扱い方

1. 露出方針を決める：Perplexityの回答出典に載せたいならPerplexityBotを許可、載せたくないなら拒否します。
2. robots.txtを整える：許可なら明示的にAllow相当（一般ルールで通す）、拒否なら `User-agent: PerplexityBot` に `Disallow: /` を書きます。
3. IPで裏を取る：perplexitybot.jsonの公式IPレンジと照合し、UA詐称を排除します。遮断したい場合はIP単位で確実に止めます。
4. PerplexityBotとPerplexity-Userを分けて扱う：出典掲載を狙うのは前者。後者はユーザー起点で、robots.txtだけでは止まらない前提で設計します。
5. 出典露出を計測する：PerplexityBotのアクセス数だけでなく、実際にPerplexityの回答へ出典として載ったかをモニタリングして成果を測ります。

ブロックの是非（トレードオフ）

PerplexityBotの許可・拒否は、他の学習系クローラー（訓練データ集め）とは判断の性質が違います。学習系はブロックしても回答露出に直結しませんが、PerplexityBotは「回答の出典欄に載る候補になるかどうか」に直結します。つまり拒否は、Perplexity経由の可視化・流入（＝AI検索の回答から自社サイトへの訪問）を自ら手放すことを意味します。逆に許可のデメリットは、コンテンツを索引化されること・サーバー負荷が増えることですが、検索系ボットの取得量は学習系ほど突出しにくく、負荷面の懸念は相対的に小さい傾向です。したがって多くのサイトでは「露出を取りに行く＝許可」が基本線になり、拒否は、有料会員向けなど本当に外に出したくない領域に限ってパス単位で行う、という使い分けが現実的です。ここで悩ましいのが、2024年のWIRED報道と2025年8月4日のCloudflareの報告が指摘した「robots.txtやWAFの遮断を回避する未宣言のアクセス」で、拒否したのに取られるリスクが残る点です（Perplexityは同日の反論記事でこれを否定しています）。確実に止めたいなら、robots.txtに加えて公式IPレンジ照合とファイアウォール／WAF（＝Webアプリを守る防御層）側の遮断を併用します。

当ラボのサーバーログ観測での見え方としては、PerplexityBot（索引用の巡回）は比較的落ち着いた頻度で現れ、UA語「PerplexityBot」で素直に拾えます。注意すべきは、同じPerplexity系でもPerplexity-User（ユーザー起点の即時取得）が混在する点で、この二つを一列に合算すると「巡回の実態」と「ユーザー個別の即時アクセス」がぼやけます。集計では両者を別カウントで並べ、さらに「学習・収集系（ClaudeBot・Bytespider等）」とも列を分けて可視化することで、初めて出典露出のチャンスを正しく読み取れます。

よくある質問（FAQ）