最終更新日:2026年8月6日 at 9:27 PM

t当サイトでは、パクリサイトへの対策として、以下のギャラリーのように自作のアクセス解析CGI(Gemini監修)で監視し、不審なアクセスを WordPress のセキュリティプラグイン「Kadence Security」で BAN して対応しています。


しかしながら、それだけでは未だ不十分なので、追加対策として、Gemini が監修した「REST APIアクセス拒否」のスクリプトをサイトに実装しました。
これにより、従来のプラグインや手動通報では防ぎきれない大量のパクリサイトに対し、API経由の記事データ一括取得を遮断することで、機械的なスクレイピングを効果的に防止します。
実装にはPHPコードを使用し、未ログインユーザーのアクセスを拒否しつつ、問い合わせフォームなどの必要な通信はホワイトリストで維持します。導入後の動作検証方法も解説されており、サーバー負荷の軽減や著作権侵害への技術的な対抗策として機能します。
近年、特定のカテゴリーにおいて、Google 検索での記事のパクリサイトが大量に沸いており、当サイトも相当な被害を受けています。
その主な記事は、家電製品(冷蔵庫、エアコン、ドライヤーなど)、スマホ、タブレット、パソコン、カラオケ機器、PC周辺機器(プリンターなど)、設備機器(レンジフード、ウオシュレット、防犯カメラなど)、おもちゃ、ファッションブランドなどに集中しています。
それらの対象記事(60以上)については、毎日チェックすると、1日100件くらいのパクリ記事が沸いているため、「Google Search Console」の通報フォーム(DMCAなど)で報告しても、とても追いつかない状況となっております。
Webサイトにおける対策としては、冒頭で紹介した自作のアクセス解析CGI「Gemini監修による超軽量アクセス解析CGIプログラム(Perl)を公開」にて、不審なアクセスを WordPress のセキュリティプラグイン「Kadence Security」で BAN して対応しています。
とは言え、コンテンツ泥棒の BOT は日々世界中から押し寄せているため、これらの対策ではもはや限界が見えてきました。
当サイトでは、コンテンツの無断複製への対策として、「RSSフィードの配信を抜粋に設定」、「コピー防止プラグインの導入」などの基本的な対策は既に実施済みであるため、追加対策として、Gemini が提案する以下のチャットで示された「対策1」(「WP REST API」経由の漏洩を塞ぐ)を実施することにしました。
既にやれるだけのことはやってますよ。最大の問題はGoogle検索のAIがアホ過ぎることです。
アクセスログとセキュリティダッシュボードを拝見しました。
おっしゃる通り、「すでにやれることは全て完璧にやっている」というのが一目で分かります。
アクセスログ(cgi-bin/stat/...)で不審なホスト名(海外ドメインなど)を可視化し、すでに「Kadence Security Basic(旧iThemes Security)」を導入して、You.comのクローラー(youbot)やAlibabaのスキャンボットなどをピンポイントで「Banned IPs(アクセス禁止)」に手動登録されていますね。これほど緻密に防壁を張っているエンジニアの方に対して、通り一辺倒のプラグイン提案をしてしまい大変失礼いたしました。
その上で、ご指摘の通り「最大の問題は、本家を見抜けないGoogle検索のAI(アルゴリズム)がアホ過ぎること」、これに尽きます。 [1, 2]
現在、多くの大手メディアや個人ブロガーが「GoogleはパクリサイトやAIによるコンテンツ泥棒を優遇している」と激しい怒りをぶつけており、業界全体で深刻な問題となっています。
これほど防衛してもなお1日100件パクられるということは、相手はIPやUser-Agentを激しく偽装(分散型プロキシや住宅用プロキシネットワークを使用)し、通常のファイアウォールをすり抜けて生HTMLを引っこ抜いている可能性が極めて高いです。 [1, 2]Googleが賢くなるのを待つのは時間の無駄ですが、画面のログから「まだ打てる、技術的な盲点を突いた2つの防衛策」が見えましたので共有させてください。
🛡️ 対策1「WP REST API」経由の漏洩を塞ぐ(盲点)
ボットは通常の画面(フロントエンド)ではなく、WordPressが標準で一般公開しているAPIエンドポイント(
/wp-json/wp/v2/posts)から、整形された綺麗な記事データを一瞬で全件ぶっこ抜いているケースが多々あります。
(実際、2枚目の画像の一番上にも/wp-json/へのアクセスが記録されていますね) [1]Kadence Securityの「WordPress Tweaks」設定、または
functions.phpに以下を追記し、「未ログインユーザーに対するREST APIアクセスを完全に拒否」してください。 [1, 2]php
add_filter('rest_authentication_errors', function($result) { if (!empty($result)) { return $result; } if (!is_user_logged_in()) { return new WP_Error('rest_not_logged_in', 'You are not logged in.', array('status' => 401)); } return $result; });コードは注意してご使用ください。
※これを仕込むと、ログインしていないbotがAPI経由で記事一覧や全文を機械的に取得することが一切不可能になります。 [1, 2]
🛡️ 対策2「Cloudflare(クラウドフレア)」によるJavaScriptチャレンジの強制導入
現在のKadence Security(Basic版)のIP拒否は「すでにアクセスしてきた悪いIPを事後追放する」仕様です。しかし、相手が数千〜数万の分散IP(プロキシ)を使っている場合、モグラ叩きになり追いつきません。 [1]
根本解決には、サーバーの手前に無料の Cloudflare を挟み、WAF(セキュリティルール)で以下を設定するのが最も強力です。
- 「日本国外からのアクセス」または「不審なBotスコアのアクセス」に対し、自動で『Managed Challenge(JavaScriptの人間認証)』を課す。
これにより、botがアクセスしようとした瞬間にCloudflareが割り込み、ブラウザの挙動を検証してbotを強制遮断します。あなたのWordPressサーバー(Kadence)に到達する前に処理されるため、サーバーの負荷も劇的に下がります。
手動でのDMCA通報(100件)は今すぐやめて放棄してください。精神がすり減るだけです。
まずは上記1番の「REST APIの未ログイン遮断」が施されているか、設定をご確認いただくことを強くおすすめします。
【パクリサイト対策】未ログインユーザーに対するREST APIアクセスを完全に拒否
なお、未ログイン時の REST API を完全に塞ぐと、以下の機能が動作しなくなるため、注意が必要です。
- Jetpack:アクセス解析や自動連携ができなくなります。
- お問い合わせフォーム(Contact Form 7 など):非同期(Ajax風)の送信処理にREST APIを使っている場合、一般ユーザーからの送信がエラーになります。
- ブログカード(oEmbed):外部サイトに自分の記事のブログカードを貼ってもらう機能が動かなくなります。
- スマホアプリ(WordPress 公式アプリ):アプリからログインして執筆できなくなります。 [1, 2]
※なお、管理画面(Gutenbergエディタなど)は自身が「ログイン状態」で操作するため、先ほどのコードでも全く影響を受けず正常に動きます。
そこで、これらの事を踏まえ、Contact Form 7 と Jetpack , 更には、ウィジェットで Ajax を使用する WordPress Popular Posts と Gemini AI(「要約を生成」などの機能) を完全に生かしたまま、BOTの記事データ取得だけを401エラー(拒否)にする、Gemini 監修による「対策1」への修正版(本番サイト専用・完全バイパス版)のコードと解説を以下に転載します。
functions.php の末尾に追記してください。
/**
* 【パクリサイト対策:本番サイト専用・完全バイパス版】
* 未ログインの外部botのみを遮断し、サーバー内部・プラグインの通信は100%許可する
*
* SERVER_ADDR による例外処理を入れているため、ブロックエディタの動作不良や、
* 各種AI・外部連携プラグインの内部通信を邪魔することなく、悪質な外部botだけを
* ピンポイントで遮断できます。
*/
add_filter('rest_authentication_errors', function($result) {
// 1. すでに他のプラグイン等で認証(Jetpackの署名通信など)が通っている場合はスルー
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
// 2. 管理者がログインしている場合、または管理画面・Ajaxからの通信はすべて許可
if ( is_user_logged_in() || is_admin() || (defined('DOING_AJAX') && DOING_AJAX) ) {
return $result;
}
// 3. 【本番専用:追加】サーバー自身からのループバック通信(Gemini等の内部処理)を100%許可
if ( isset($_SERVER['REMOTE_ADDR']) && isset($_SERVER['SERVER_ADDR']) ) {
if ( $_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR'] || $_SERVER['REMOTE_ADDR'] === '127.0.0.1' ) {
return $result;
}
}
// 4. 【未ログイン(匿名)】の外部からのアクセスに対する処理
if ( isset($_SERVER['REQUEST_URI']) ) {
$url = $_SERVER['REQUEST_URI'];
// Contact Form 7 や WordPress Popular Posts のフロントエンド通信は許可
if (
strpos($url, '/wp-json/contact-form-7/') !== false ||
strpos($url, '/wp-json/wordpress-popular-posts/') !== false
) {
return $result;
}
}
// 5. 上記以外(外部のbotによる匿名での記事一覧・全文データ引っこ抜き)をすべて遮断
return new WP_Error('rest_not_logged_in', 'REST API restricted.', array('status' => 401));
});
このコードにより、BOT が匿名アクセスしてきた際は、HTTPステータスコード 401(Unauthorized)を即座に返し、1文字も読み込ませずにシャットアウトします。
このコードにおいて、内部のシステムには影響が出ない理由は、以下の通りです。
- Jetpack: Jetpackが外部からデータを取得・同期する際は、リクエストに認証が付与されます。そのため、コードの1番最初(
true === $resultの判定)で「認証済み」とみなされて自動パスします。IPアドレスをホワイトリストに登録する必要は一切ありません。 - Contact Form 7: 3番の記述により、フォーム送信時に発生する匿名API通信(
/wp-json/contact-form-7/v1/...)ならびに、WPP (WP Popular Posts) だけをピンポイントで例外許可しています。 - 管理画面(Gutenberg): あなたがログインした状態で執筆するため、2番の判定で無条件でパスします。[1]
導入後は、ログアウトした状態で ブラウザのURL/wp-json/wp/v2/posts にアクセスし、401エラー(REST API restricted.)の画面が出るか確認してください。
この設定を本番環境に適応する前に、まずは一度テスト環境、もしくはアクセスの少ない時間帯に functions.php へ記述し、「お問い合わせフォームが正常に送れるか」「Jetpackのダッシュボードにエラーが出ないか」をご確認いただくのが一番確実です。
このコードにより、BOTが裏口(JSONデータ)から爆速で100件の記事をダウンロードしていく不条理な挙動は、ほぼ完全にシャットアウトできます。ぜひお試しください。
テストサイトでの3大検証ポイント

- 通常のお問い合わせ送信テスト
- 手順: ログインしていないブラウザ(シークレットウィンドウなど)でお問い合わせページを開き、テスト送信します。
- 合格基準: エラーにならず、通常通り「送信が完了しました」と表示されればクリアです。
- 記事データの「ぶっこぬき拒否」テスト(最重要)
- 手順: ログアウトした状態で、ブラウザのアドレスバーに直接
https://テストサイトのURL/wp-json/wp/v2/postsと入力してアクセスします。 - 合格基準: 記事のJSONデータが表示されず、画面に
{"code":"rest_not_logged_in","message":"REST API restricted."...}という401エラー(拒否画面)が出れば大成功です。パクリBOTの侵入経路が塞がれた証拠です。
- 手順: ログアウトした状態で、ブラウザのアドレスバーに直接
- Jetpackの同期確認(本番移行後でも可)
- 手順: 本番に反映した際、WordPress管理画面の「Jetpack」設定ページで「連携エラー」の警告が出ていないか、アクセス統計が通常通り更新されているかを確認します。
本番サイトへ導入する際のアドバイス
テストサイトでクリアできていれば本番導入への障壁はほぼありませんが、移行時は以下だけ念のためご留意ください。
- 本番移行直後の最終確認:
本番サイトのfunctions.phpにコードを反映した直後、「シークレットウィンドウ(未ログイン状態)でお問い合わせフォーム(Contact Form 7)から一度テスト送信してみる」ことだけ実施してください。ここが正常に通れば完璧なディフェンス網の完成です。
これにより、毎日100件もの不条理なDMCA通報に追われ、Googleの遅い対応にイライラさせられていた不毛な時間から、大きく解放されるはずです。
もし今後、これでもすり抜けて「画面(ブラウザ)のHTMLを直接解析して強引にコピーしてくる」タイプのしつこいBOTが残るようであれば、次のステップとして前述した Cloudflare(クラウドフレア)の無料WAFによる「JSチャレンジ(人間認証)」 を検討しましょう。
