Perplexityに学習させない設定と拒否方法！著作権やSEOも解説

最近、急速に利用者を増やしているAI検索エンジン「Perplexity（パープレキシティ）」。その便利さの一方で、「自分のブログ記事やウェブサイトのコンテンツを勝手に学習されたくない」「入力した検索データがAIの知識として再利用されるのは気持ち悪い」という不安を感じている方も非常に多いのではないでしょうか。特に、丹精込めて書いた記事がAIによって勝手に要約され、検索結果だけで完結してしまう「ゼロクリック検索」は、サイト運営者にとって死活問題となりかねません。

サイト運営者にとっては、著作権を無視したスクレイピングやクローリングの拒否設定が急務ですし、一般ユーザーとしても、業務上の機密情報やプライベートな検索履歴の取り扱いについては正しい知識を持っておきたいところです。この記事では、サーバー設定やrobots.txtによる技術的な遮断方法から、iPhoneやAndroidなどの端末側で行うべきプライバシー設定、さらには最新の著作権法解釈や訴訟の動向まで、Perplexityに「学習させない」ための包括的な対策を徹底解説します。

Perplexityに学習させないためのサイト管理者向け技術的対策

ウェブサイトやブログを運営している私たちが、自分のコンテンツを無断でAIの学習データとして利用されたくない、あるいは検索結果での安易な要約による「ただ乗り」を防ぎたいと考えた場合、サーバーサイドで適切な拒否設定を行う必要があります。しかし、相手は高度な技術を持つAI企業です。生半可な対策ではすり抜けられてしまうのが実情です。ここでは、Perplexityからのアクセスを正確に識別し、ブロックするための技術的な手法を、初心者にもわかりやすく、かつ専門的な深さまで掘り下げて解説します。

PerplexityBotとUserの違いを見分ける識別方法

Perplexityからのアクセスを技術的に遮断しようとする際、最初に絶対に理解しておくべきなのは、Perplexityが使用しているボット（User-Agent）には、役割や挙動が全く異なる2つの種類が存在するという点です。これを混同してしまうと、「ブロック設定をしたはずなのに、なぜかアクセスログに記録が残っている」「記事が勝手に要約されている」という事態に陥ります。

まず1つ目は「PerplexityBot」です。これは、Googleの「Googlebot」やBingの「Bingbot」と同じように、ウェブ全体を定期的に巡回（クロール）して情報を収集し、検索インデックスを作成するためのボットです。PerplexityBotは、主に記事のコンテンツを読み取ってAIの基盤モデル（LLM）に学習させたり、RAG（検索拡張生成）のベースとなる知識データベースを構築したりするために稼働しています。基本的には、ウェブサイト側が提示するルール（robots.txt）に従う「行儀の良いボット」として設計されています。

2つ目は「Perplexity-User」です。こちらは少し特殊で、より厄介な存在です。これは、ユーザーがPerplexityのチャット画面で「このURLの記事を読んで要約して」といった具体的な指示を出した際や、「Copilot」機能を使用した際に、そのユーザーの代わりに（Agentとして）リアルタイムで特定のページを見に来るボットです。Perplexity側の主張としては、「これはAIが勝手に巡回しているのではなく、あくまでユーザーがブラウザで閲覧する行為を代行しているだけ」という位置付けになります。そのため、後述するように一部のアクセス制限を無視したり、より人間に近い挙動をとったりする傾向があります。

サーバーのアクセスログ解析を行う際は、User-Agent（ユーザーエージェント）という文字列を確認します。ここにMozilla/5.0 ... PerplexityBot/1.0やPerplexity-User/1.0といった記述が含まれているかを確認することで、どちらの目的でアクセスされているかを明確に識別できます。まずは現状、どのくらいの頻度でアクセスされているかを確認することから始めましょう。

robots.txtでPerplexityのクローラーを拒否する

最も基本的で、かつ法的な文脈においても「拒否の意思」を対外的に示す標準的な方法は、ウェブサイトのルートディレクトリにあるrobots.txtファイルに記述を追加することです。これは「Robots Exclusion Protocol」と呼ばれる国際的な慣習に基づくもので、多くの正規の検索エンジンボットはこれに従います。技術的な強制力はありませんが、玄関先に「立ち入り禁止」の札を掲げるようなもので、AI企業に対する意思表示として非常に重要です。

Perplexityに学習させないためには、以下の記述をrobots.txtに追加します。WordPressなどのCMSを使っている場合は、プラグインで編集するか、FTPソフトで直接アップロードしてください。

推奨される記述コード

# Block Perplexity AI crawlers specifically
User-agent: PerplexityBot
Disallow: /

User-agent: Perplexity-User
Disallow: /

# Block other major AI crawlers (Optional but recommended)
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: ClaudeBot
Disallow: /

上記の記述において、User-agent: PerplexityBotはボットの名前を指定し、Disallow: /はそのボットに対してサイト内のすべてのページへのアクセスを禁止するという意味になります。「Perplexity-User」に対しても同様に記述することで、リアルタイム検索の代行も拒否する意思を示します。もし、特定の画像フォルダや管理画面など、一部のディレクトリだけをブロックしたい場合は、Disallow: /wp-admin/のようにパスを指定することも可能です。

PerplexityのIPアドレスを特定してブロックする手順

robots.txtによる「お願い」ベースの拒否では不安な場合、アクセス元のIPアドレス自体をファイアウォールで遮断するという、より物理的で強硬な手段があります。特定の住所からの訪問を門前払いするイメージです。しかし、PerplexityのようなAI企業のクローラーをIPアドレスでブロックするには、いくつかの大きな技術的課題とリスクが存在します。

Perplexityのクローラーは、自社の専用サーバーではなく、主にAmazon Web Services (AWS) という巨大なクラウドインフラを利用して稼働しています。具体的には、AWSの「US-East-1 (N. Virginia)」や「US-West-2 (Oregon)」といったリージョンのデータセンターからアクセスしてくることが観測されています。

問題は、クラウドサービスの特性上、IPアドレスが固定されていないことです。彼らが使うIPアドレスは頻繁に変更されたり、アクセスのたびに動的に割り当てられたりします。Perplexity側も公式にperplexitybot.jsonといった形式でIPリストを公開している場合がありますが、このリストは日々更新されるため、手動で追いかけるのは事実上不可能です。

「巻き添えブロック」のリスク

さらに深刻なのが、誤遮断（False Positive）のリスクです。もし「PerplexityがAWSを使っているから」といって、AWSの特定のIPレンジ（CIDRブロック）をまるごとファイアウォールでブロックしてしまうとどうなるでしょうか？

AWSは世界中の数え切れないほどの企業やサービスが利用しています。その中には、あなたのサイトの正常な監視ツール、提携しているAPIサービス、あるいはAWSのVPN経由でアクセスしている一般ユーザーなどが含まれている可能性があります。IPレンジでのブロックは、これら全ての無関係な「善意のアクセス」まで巻き添えにして遮断してしまうリスクが非常に高いのです。

勝手に学習されるのを防ぐhtaccessとWAF設定

robots.txtを無視して強引にアクセスしてくるボットに対しては、ウェブサーバーのレベルで強制的にエラー（403 Forbidden）を返して追い返す設定が有効です。これは、サーバーの入り口に警備員を立たせて、名札（User-Agent）を見て入場を断るようなものです。

Apacheサーバーを利用している一般的なレンタルサーバーなどでは、.htaccessという設定ファイルを編集することで対策が可能です。以下のコードをファイルの先頭付近に追加してください。

Apache (.htaccess) の設定例

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} (PerplexityBot|Perplexity-User) [NC]
    RewriteRule .* - [F,L]
</IfModule>

このコードの意味を解説します。RewriteCondは条件を指定しており、アクセスしてきたUser-Agentの中に「PerplexityBot」または「Perplexity-User」という文字列が含まれているか（[NC]は大文字小文字を区別しない設定）をチェックします。もし条件に合致した場合、RewriteRuleが発動し、[F]つまりForbidden（立ち入り禁止）のステータスコードを返して接続を切断します。

Nginx の設定例

最近増えているNginxサーバーの場合は、設定ファイル（nginx.confなど）に以下のように記述します。

if ($http_user_agent ~* "PerplexityBot|Perplexity-User") {
    return 403;
}

Cloudflare WAFでの対策（推奨）

WordPressなどのCMSを使っている場合、サーバーに負荷をかけないためにも、プラグインや.htaccessではなく、CloudflareなどのCDN（コンテンツデリバリネットワーク）側でWAF設定を行うことを強くおすすめします。サーバーにリクエストが到達する前に、インターネットのエッジ（最前線）で弾くことができるため、DDoS攻撃のような大量のボットアクセスがあってもサイトが重くなりません。

Cloudflareの管理画面から「WAF」→「カスタムルール」を作成し、以下のように設定します。
フィールド: User Agent
演算子: contains（含む）
値: Perplexity
アクション: Block（ブロック）
これで、「Perplexity」と名乗るすべてのアクセスを水際で阻止できます。

ブロック回避を行うステルスクローリングへの対処法

ここまで解説した対策を行えば、通常のクローラーは防げます。しかし、「学習させない」を実現する上で最大の障壁となっているのが、いわゆる「ステルスクローリング」の問題です。これは、セキュリティ企業のCloudflareなどがレポートで告発している通り、Perplexityの一部のクローラーが、サイト側のブロック設定を検知すると、身元を隠蔽してアクセスを継続する行為を指します。

具体的には、本来なら「PerplexityBot」と名乗るべきところを、一般的なWebブラウザである「Google Chrome」や「Safari」のUser-Agent（例: Mozilla/5.0 ... Chrome/120.0...）に偽装して再アクセスを試みる挙動が確認されています。また、データセンターのIPアドレスではなく、一般家庭用のIPアドレス（住宅用プロキシ）を経由することで、IPブロックをすり抜けるケースもあります。

こうなってくると、単純な文字列マッチングやIPリストでは防げません。正規のユーザー（人間）と偽装ボットを見分けることができないからです。

高度な防御策：Bot Fight Modeの活用

この「なりすまし」に対抗するには、ブラウザの挙動そのものを検証する高度な対策が必要です。

• Cloudflareの「Bot Fight Mode」: 無料プランでも利用可能です。JavaScriptチャレンジ（ブラウザに簡単な計算をさせるなど）を実行し、それに答えられない単純なボットをブロックします。
• 「Super Bot Fight Mode」（Proプラン以上）: より強力な機能で、「Definitely Automated（明らかに自動化されている）」と判定されたアクセスを自動的に遮断したり、Headless Browser（画面のないブラウザ）特有の指紋（フィンガープリント）を検知したりできます。

Perplexity側は「ユーザーの代理（Agent）としてアクセスしているのだから、ブロックされる筋合いはない」という論理（Agent論）を展開していますが、サイト管理者としては、サーバーリソースを無断で使用され、コンテンツをタダで利用されることに変わりはありません。徹底抗戦するなら、こうした振る舞い検知型のWAF導入を検討する価値があります。

ユーザーや権利者がPerplexityに学習させない方法と影響

ここまではサイト管理者としての防御策を見てきましたが、ここからは視点を変えて、「Perplexityというサービスを利用するユーザー」の立場、そしてコンテンツの権利者としての立場から、データ保護と法的な権利関係、ビジネスへの影響について深掘りしていきます。自分のデータは自分で守る意識が大切です。

アカウント設定で自分のデータを学習から除外する

「仕事のリサーチでPerplexityを使っているけれど、検索窓に入力した社外秘のプロジェクト名や、アップロードした内部資料の内容をAIに学習されたくない」──ビジネスパーソンなら当然の懸念です。実際、初期設定のままでは、ユーザーとの対話データはAIモデル（PerplexityのSonarモデルなど）の精度向上のために利用される可能性があります。

しかし、幸いなことにPerplexityにはユーザーがデータの利用を拒否できる「オプトアウト」機能が用意されています。以下の手順で設定を見直しましょう。

設定変更の具体的な手順

1. Perplexityにログインし、画面左下のアイコンから「Settings（設定）」メニューを開きます。
2. 上部のタブから「Account（アカウント）」を選択します。
3. 「AI Data Retention（AIデータの保持）」という項目を探します。
4. このトグルスイッチをオフ（グレーの状態）にします。初期状態ではオン（青色）になっていることが多いです。

この設定をオフにすることで、あなたの検索クエリ、プロンプト、対話履歴は、Perplexityの将来のモデルトレーニングセットから除外されます。ただし、これは「今後」のデータに対する設定であり、過去に収集されたデータが遡って削除されるとは限らないため、アカウント作成直後に設定することをお勧めします。

企業向けプランの安全性

もし会社全体で導入しているなら、個人版ではなく「Enterprise Pro」プランの利用が推奨されます。このプランには「Zero Data Retention」ポリシーが適用されており、デフォルトで学習利用が禁止されているほか、API経由でのデータ送信も学習対象外となり、一定期間（例：30日）でサーバーから完全に削除される仕様になっています。機密情報を扱う場合は、無料版や個人Pro版ではなく、この企業向け環境を利用するのが鉄則です。

著作権侵害の懸念と日本国内での法的訴訟の動向

「勝手に学習される」ことに対して、法的にはどのような扱いになるのでしょうか。クリエイターやメディア関係者にとっては最も気になる部分です。実は、日本は世界的に見ても「AI学習天国」と呼ばれるほど、著作権法がAI開発側に有利な構造になっています。

その根拠となるのが、著作権法第30条の4です。この条文では、著作物に表現された思想や感情を「自ら享受し、または他人に享受させることを目的としない場合」（＝単なる情報解析や学習用データとしての利用）には、原則として著作権者の許諾なく利用（複製・翻案）できると定められています。つまり、「AIに勉強させるために記事を読ませるだけなら、違法ではない」というのが現在の日本の法律の基本スタンスです。

しかし、これには重要な例外規定（ただし書き）があります。「当該著作物の種類及び用途並びに当該利用の態様に照らし著作権者の利益を不当に害することとなる場合」は、この限りではない（＝違法となる可能性がある）とされています。

メディアによる反撃と訴訟

現在、日本経済新聞社、朝日新聞社、読売新聞グループなどの大手メディアは、この「不当に害する場合」に該当するとして、Perplexityに対して強く抗議し、法的措置も辞さない構えを見せています。彼らの主張は、「Perplexityは記事を学習するだけでなく、検索結果として記事の詳細な要約を表示しており、これによってユーザーが元のニュースサイトを訪問しなくなっている。これは単なる情報解析を超えた『著作物の利用（享受）』であり、フリーライド（ただ乗り）によって新聞社の有料事業や広告収益を侵害している」というものです。

米国でもThe New York Timesなどが同様の訴訟を起こしており、国際的にも「学習」と「盗用」の境界線が争われています。文化庁もAIと著作権に関するガイドラインを策定し、議論を進めています。

（出典：文化庁「AIと著作権について」）

学習させないことによるSEOとトラフィックへの影響

感情的には「勝手に使われたくない！」と思うものですが、冷静にWebマーケティングやSEO（検索エンジン最適化）の観点で考えると、ブロックすることが常に正解とは限りません。ここにはメリットとデメリットのトレードオフが存在します。

Perplexityは現在、月間で数億回のアクセスがある巨大なプラットフォームに成長しており、Google検索の代替として使うユーザーも急増しています。もしあなたがPerplexityを完全にブロックすれば、当然ながらその検索結果において、あなたのサイトが回答のソース（出典）として引用されることは一切なくなります。

これは、「Perplexity経由での新しい読者（Referral Traffic）」を自ら遮断することを意味します。現状、Google検索からの流入数に比べれば、Perplexityからの流入はまだ微々たるもの（ウェブ全体の1%未満とも言われる）ですが、AI検索を利用するユーザーは情報の感度が高く、記事を深く読み込む傾向があるため、質の良いリード（見込み客）になる可能性があります。

ゼロクリックの脅威

一方で、パブリッシャーが最も恐れているのが「ゼロクリック検索」です。AIが優秀すぎて、検索結果画面だけでユーザーの疑問を完璧に解決してしまい、出典元のリンクがクリックされない現象です。ある調査では、AI検索は従来の検索に比べてサイトへの送客数が大幅に減少するというデータもあります。「利用されるだけで、こちらには一銭の得にもならない」という状況です。

ゼロクリックを防ぐための戦略的なブロック判断

これらを踏まえると、一律に「ブロック推奨」とするのではなく、運営しているサイトのビジネスモデルや目的によって「学習させるか、させないか」の判断を使い分けるのが、現時点での最も賢い戦略と言えます。

Perplexityに学習させないための包括的なまとめ

Perplexityに「学習させない」という選択は、単なるサーバー設定の作業ではなく、AI時代の情報のあり方に対する意思表示でもあります。

サイト管理者としては、まずrobots.txtへの記述とCloudflare WAFなどの導入を行い、明確な拒否の姿勢を示すことが第一歩です。しかし、ステルス挙動への対策には限界があり、完全に防ぐには常に監視が必要であることを理解しておく必要があります。

また、一般ユーザーとしては、アカウント設定の「AI Data Retention」をオフにするだけで、プライバシーリスクを大幅に低減できます。これは今すぐできる最も効果的な自衛策です。

AI検索の進化は止まりませんが、私たちもただ指をくわえて見ているだけでなく、自分のデータやコンテンツをどのように扱わせたいのか、その価値を理解し、主体的にコントロールしていく姿勢が何よりも大切です。