最終更新日：2026年5月15日 at 7:01 PM
* このページは、常時更新中です。
本サイトに設置したPerlのアクセス解析プログラムのログと WordPress のプラグイン NewStatPress（現在は WP Statistics に変更）の分析結果を調査しました。
その結果、相変わらず、自身をBOTと名乗らない迷惑BOTから大量のアクセスがある事が確認できました。
そのBOTについてですが、当サイトでは以下のような種類を確認しています。
(1) 手当たり次第に掲示板やコメントフィールドへ商品の宣伝を書き込む「SPAM・BOT」
⇒ “Google No CAPTCHA reCAPTCHA” （現在は、reCAPTCHA v3 へ移行済）により、全てガードされています。
(2) WordPress へのログインを試みる「ハッキングBOT」（Brute Force Attack）
⇒ “Google No CAPTCHA reCAPTCHA” により、全てガードされていますし、更に、強固なパスワードに変更していますので、まず大丈夫でしょう。
* ４月２０日 追記
その後、更にログ解析を進めた結果、ログイン名とパスワードを WordPress の xmlrpc.php へ送信する方法で、裏口からの侵入を試みる多数のハッキングサイトを確認しました。 因って、そのIPアドレスを本日ブロックしました。
(3) プラグインの脆弱性を利用し、記事の書き換えを試みる「ハッキングBOT」
⇒ 当該プラグインは当サイトでは使用していません。なお、当サイトでは、プラグイン「Revslider」等へのアタックを確認しています。 ⇒ wp-config.php を閲覧することで、彼らはDBやWebサイトへの侵入を企んでいます。
これらのアタックサイトに関しては、Windows XP や Windows 2000 等のセキュリティが脆弱なPCやWebサイトがウィルスに感染し、それを踏み台にして邪悪なBOTへと変貌している可能性が考えられます。
目次
個別のIPアドレス制限
上記の調査結果を踏まえ、これ以上、悪質なBOTの行為を許す事が出来なくなりましたので、この度、特に悪質なBOTへの大規模なアクセス制限を実施しました。
以下は、Apache の「.htaccess」に追記した当サーバーへのアクセス拒否設定の一部です。
* 2018年4月10日時点において、合計で441個のIPアドレスを昇順に定義しています。
# Denial of Access (Last modified - 2015/5/9)
order allow,deny
allow from all
deny from 144.76.0.0/16 # clients.your-server.de (Germany-SPAM)
deny from 148.251.0.0/16 # static.177.26.76.144.clients.your-server.de
deny from 5.9.146.29 # static.29.146.9.5.clients.your-server.de
deny from 94.23.40.23 # crawl15.lp.007ac9.net (your-server.de)
deny from 94.23.54.140 # France-Hacking site
deny from 94.23.59.161 # France-Hacking site
deny from 94.131.0.0/16 # AVK-NET (Russia-Hacking site)
deny from 193.104.41.0/24 # Moldova Hacking site (pinspb.ru Russia)
deny from 46.161.62.0/24 # Kazakhstan Network (pinspb.ru Russia-SPAM)
deny from 46.161.63.0/24 # Moldova Network (pinspb.ru Russia-SPAM)
deny from 195.154.0.0/17 # poneytelecom.eu (France-SPAM)
deny from 62.210.128.0/17 # 62-210-177-242.rev.poneytelecom.eu
deny from 213.186.33.0/24 # ip-198-27-82.net (France-SPAM)
deny from 37.187.0.0/16 # ns3371997.ip-37-187-93.eu (France-SPAM)
deny from 192.99.0.0/16 # ip-192-99-10.net (Canada-SPAM)
deny from 142.54.161.130 # Canada-SPAM
deny from 142.54.160.106 # Canada-SPAM
deny from 142.54.184.181 # Canada-SPAM
deny from 198.27.82.152 # ns4006763.ip-198-27-82.net (Canada-SPAM)
deny from 162.244.12.179 # US-SPAM
deny from 69.30.255.130 # US-SPAM
deny from 76.164.192.43 # US-SPAM
deny from 184.168.152.208 # US-Hacking Site
deny from 83.139.191.22 # UK-Hacking site
deny from 108.59.8.80 # hosted-by.leaseweb.com (US-SPAM)
deny from 36.248.160.0/17 # China fujian provincial network (SPAM)
deny from 183.192.0.0/11 # China Mobile Communications (SPAM)
deny from 110.89.37.87 # CHINANET FUJIAN PROVINCE NETWORK (SPAM)
deny from 183.207.228.14 # China-SPAM
deny from 192.151.154.82 # Unknown-SPAM
deny from 192.187.96.0/19 # US - Hacking Site
deny from 212.109.32.11/26 # sovam.net.ua (Ukraine-SPAM)
deny from 46.118.0.0/16 # sovam.net.ua (Ukraine-Hacking site)
deny from 37.115.128.0/17 # broadband.kyivstar.net (Ukraine-Hacking site)
deny from 94.153.0.0/17 # Ukraine - Plugin "WP All Import" Attack site
deny from 109.104.168.81 # Ukraine-Hacking site
deny from 109.108.246.42 # Ukraine-Hacking site
deny from 77.120.121.201 # Ukraine-Hacking site (plasma.co.ua)
deny from 5.248.128.0/17 # 5-248-239-242-broadband.kyivstar.net (SPAM)
deny from 134.249.0.0/16 # 134-249-140-218-gprs.kyivstar.net (SPAM)
deny from 178.137.0.0/16 # kyivstar.net (SPAM)
deny from 195.211.152.0/22 # Ukraine-SPAM
deny from 195.154.188.74 # France-SPAM
deny from 188.163.76.0/24 # sol-fttb.23.76.163.188.sovam.net.ua
deny from 188.163.77.0/24 # sovam.net.ua (Ukraine-SPAM)
deny from 80.93.113.38 # Ukraine-Hacking site
deny from 193.201.224.0/19 # Ukraine-SPAM
deny from 46.151.52.0/22 # Ukraine-SPAM
deny from 31.184.236.0/24 # Latvia-SPAM
deny from 31.193.196.0/24 # Latvia-SPAM
deny from 91.200.12.0/22 # Ukraine-SPAM
deny from 91.207.7.158 # Ukraine-SPAM
deny from 176.36.80.39 # host-176-36-80-39 (Ukraine-SPAM)
deny from 176.109.182.19 # Ukraine-SPAM
deny from 94.22.0.0/20 # Anvia (Finland-BOT)
deny from 114.44.170.172 # Australia-SPAM
deny from 166.62.36.66 # US-Hacking site
deny from 45.59.27.155 # US-SPAM
deny from 104.255.67.238 # US-BOT (VolumeDrive)
deny from 59.115.170.243 # TAIWAN-SPAM
deny from 23.232.143.19 # Unknown-SPAM
deny from 192.240.201.160 # Unknown-SPAM
deny from 118.168.198.179 # Unknown-SPAM
deny from 204.195.139.6 # Unknown-SPAM
deny from 91.214.44.153 # lu-customer-ip.as51430.net
deny from 67.215.237.98 # n6-losangeles-us.samknows.com
deny from 112.175.184.0/24 # Korea - Plugin "Revslider" Attack site
deny from 78.20.76.230 # Germany-Hacking site
deny from 188.40.138.214 # Germany - Plugin "Revslider" Attack site
deny from 3.19.41.74 # Unknown-Hacking site
deny from 23.19.41.74 # Plugin "Revslider" Attack site
deny from 62.210.113.121 # Plugin "Revslider" Attack site
deny from 93.188.165.166 # xmlrpc.php Attack site
deny from 195.220.216.12 # France - xmlrpc.php Attack site
deny from 185.3.32.20 # Unknown-Hacking site
deny from 176.119.109.177 # Unknown-Hacking site
deny from 81.163.119.20 # Unknown-Hacking site
deny from 109.188.124.27 # Russia-Hacking site
deny from 52.10.157.134 # US-Hacking site
deny from 179.43.117.234 # Unknown-Hacking site
deny from 31.193.141.19 # Plugin "Revslider" Attack site
deny from 193.246.63.31 # Switzerland - Plugin "Revslider" Attack site
deny from 91.142.223.95 # Plugin "Revslider" Attack site (Spain)
deny from 91.142.252.91 # Plugin "Revslider" Attack site
deny from 104.148.44.39 # Plugin "FCKEditor for WordPress" Attack site
deny from 80.82.65.82 # Plugin "FCKEditor for WordPress" Attack site
deny from 5.101.156.0/24 # xmlrpc.php Attack site
deny from 5.101.157.0/24 # Russia - Plugin "Revslider" Attack site
deny from 80.237.251.203 # Germany - Plugin "Revslider" Attack site
deny from 211.200.192.54 # Korea - Plugin "Revslider" Attack site
deny from 188.143.232.0/24 # Russia - SPAM (LeonLundberg-net)
deny from 188.143.234.0/24 # Russia - SPAM (ToussaintDesaulniers-net)
deny from 72.18.205.234 # US - Plugin "Revslider" Attack site
deny from 118.170.33.3 # Plugin "MiwoFTP" Attack site
deny from 188.165.0.0/16 # France - Plugin "Revslider" Attack site
deny from 95.110.202.57 # Plugin "Revslider" Attack site
deny from 95.110.232.43 # Plugin "Revslider" Attack site
deny from 92.100.143.41 # Russia-Hacking site
deny from 85.25.109.90 # Germany - Plugin "Revslider" Attack site
deny from 89.130.171.6 # Plugin "Revslider" Attack site
deny from 194.54.160.9 # Russia-Hacking site
deny from 46.241.242.30 # Armenia-Hacking site
deny from 46.200.221.11 # pool.ukrtel.net - Hacking site
deny from 217.69.133.13 # Russia-Hacking site
deny from 37.59.47.101 # France - Plugin "Revslider" Attack site
deny from 91.121.136.67 # France - Hacking site
deny from 162.209.48.30 # Unknown-Hacking site
deny from 112.148.213.96 # Plugin "BackupBuddy" Attack site
deny from 2.132.204.182 # Bitrix Site Manager Attack site
deny from 79.170.44.93 # UK - Plugin "Revslider" Attack site
deny from 182.118.0.0/16 # 中国迷惑BOT (hn.kd.ny.adsl)
deny from 59.173.148.207 # China - Plugin "FCKEditor" Attack site
deny from 171.113.176.0/24 # Plugin "FCKEditor" Attack site
deny from 111.172.99.227 # Plugin "FCKEditor" Attack site
deny from 185.23.21.11 # Transposh Hacking site
deny from 109.197.72.51 # Russia-SPAM
deny from 37.59.0.0/16 # ovh.net France-Hacking site (37.59.1.10)
deny from 213.251.128.0/18 # ovh.net France-Hacking site (213.251.182.110)
deny from 167.114.116.195 # US - Hacking site
deny from 183.60.244.49 # China - Hacking site
deny from 186.202.127.0/24 # Plugin "Revslider" Attack site
# 以下略
これで、BOTで賑わっていた当サイトがかなり静かになりました。 （笑）
【アクセス制限について】
アクセス解析の結果、ApacheによるIPアドレスからホスト名への逆引きが不可能なケースを散見しましたので、ホスト名ではなく、全てIPアドレスの記述により、アクセス制限を実施しました。
例として、以下のように複数のIPアドレスを使って攻撃してくるBOTについては、IPのサブネットマスクを指定する事で対象IPを纏めて拒否するよう設定しました。
195-154-188-41.rev.poneytelecom.eu 195.154.188.41 195-154-173-141.rev.poneytelecom.eu 195.154.173.141 195-154-189-155.rev.poneytelecom.eu 195.154.189.155 195-154-191-162.rev.poneytelecom.eu 195.154.191.162 195-154-188-224.rev.poneytelecom.eu 195.154.188.224
【サブネットマスクの指定方法について】
これ以降、情報処理技術者の方は読み飛ばして下さって結構です。
迷惑BOTの疑いのあるホスト名またはIPアドレスを以下のwhoisデータベースのサイトで、サーバー情報を取得します。
実例として、「195.154.188.41」を検索します。
その結果、以下のように当該ネットワークが使用するIPアドレスの範囲が確認出来ます。
inetnum: 195.154.128.0 – 195.154.255.255
これを二進数に展開します。
11000011 10011010 10000000 10000000
11000011 10011010 10000000 10000001
11000011 10011010 10000000 10000010
11000011 10011010 10000000 10000011
・
・
・
11000011 10011010 11111111 11111110
11000011 10011010 11111111 11111111
これで、上位17bitが固定で、下位15bitが可変である事が解ります。
よって、上位17bitを固定するためのサブネットマスクは、以下のように表記出来ます。
11111111 11111111 10000000 00000000
対象IPアドレスに対し、このサブネットマスクと二進数の論理積の演算結果の値が一致すれば、制限IPアドレスという事になります。
このサブネットマスクは、「.htaccess」の中で以下のように記述します。
195.154.0.0/17
または
195.154.0.0/255.255.128.0
未だ全てのBOTを排除していないので、小さなBOTは居ますが、以前よりはかなり静かになった感じがします。
以下は、BOTへのアクセス制限を行った後におけるPerlのアクセス解析プログラムのモニター画面です。
*４月９日 追記
念のため、ログイン画面への総当たり攻撃を防御するためのプラグイン「Jetpack-Protect」も本日有効にしておきました。
*９月１８日 追記
先日、韓国からのDOSアタックやウクライナからのSPAMアタックを受け、サーバがダウンしたため、「.htaccess」を更新しました。以下の記述はその一部です。
deny from 121.160.0.0/11 # Korea DOS Attack Site
deny from 121.189.37.15 # Korea SPAM site
deny from 46.119.121.0/24 # Ukraine SPAM site
deny from 78.137.32.0/19 # Ukraine SPAM site
deny from 93.76.64.0/20 # Ukraine DOS Attack site
deny from 111.172.97.115 # China SPAM site
deny from 111.172.104.138 # China SPAM site
deny from 169.54.143.212 # static.reverse.softlayer.com
deny from 192.0.64.0/18 # US SPAM site
deny from 204.12.241.170 # depictionorganizers.com
deny from 216.244.82.0/24 # tnxe.sessionall.com
なお、以下に示す robots.txt の定義（一部分にみ掲載）においても、迷惑BOTからのアクセスを拒否しています。
因みに、SteelerとShim-Crawler は、東京大学の研究室から来るクローラです。現時点において、百度の一部のクローラーはアクセスを許可しています。
User-agent: DotBot
Disallow: /
User-agent: SemrushBot
Disallow: /
User-agent: MJ12bot
Disallow: /
User-agent: AhrefsBot
Disallow: /
User-agent: BLEXBot
Disallow: /
User-agent: Yandex
Disallow: /
User-agent: baiduspider
Allow: /
User-agent: BaiduMobaider
Allow: /
User-agent: BaiduImagespider
Disallow: /
User-agent: baiduspider-image
Disallow: /
User-agent: baiduspider-video
Disallow: /
User-agent: 360Spider
Disallow: /
User-agent: hn.kd.ny.adsl
Disallow: /
User-agent: spider
Disallow: /
User-agent: YoudaoBot
Disallow: /
User-agent: Mail.RU_Bot
Disallow: /
User-agent: ltx71
Disallow: /
User-agent: SemrushBot
Disallow: /
User-agent: LSSRocketCrawler
Disallow: /
User-agent: LinqiaScrapeBot
Disallow: /
User-agent: Wotbox
Disallow: /
User-agent: Steeler
Disallow: /
User-agent: Shim-Crawler
Disallow: /
*９月２６日 追記
アクセスログの解析から、WordPress のピングバック機能を利用したDDOS攻撃の形跡も確認しましたので、本サイトのピングバック機能を無効に設定しました。
参考記事は、こちら ⇒ 注意喚起：WordPressの機能を悪用したDDoS攻撃対策のお願い
プラグイン「Disable XML-RPC Pingback」をインストールする事でピングバック機能を無効にし、更に、「.htaccess」に以下の定義を追加し、リモート投稿プログラム「xmlrpc.php」へのアクセスも禁止に設定しました。*
* 2020.04.01 追記
以下の定義ならびに、プラグイン「Disable XML-RPC Pingback」を有効にすると、Jetpack と WordPress との連携が切れ、Jetpack のサイトヘルスステータスにおいて、”致命的な問題（エラー200）”が表示されるようになります。
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
2018.04.10 追記
Amazon の AWS を利用した大量のスパムアクセスがあり、IPアドレスで拒否しても、しつこくまた別のIPアドレスでやって来るため、以下の通りドメイン指定でアクセス拒否しました。
order deny,allow
allow from all
deny from amazonaws.com
2020.05.11 更新 / 2025.09.11 追記
Amazon の AWS からのアクセスを拒否しているため、一部のクローラーやWebサイトからアクセスができない事でサイト運営に支障が生じたため、現在、amazonaws.com へのアクセス制限を解除しています。
後に分かった事ですが、Jetpack のクローラーの一部が AWS を使用しているため、AWS の全てのアクセスを拒否すると、WordPress と Jetpack との連携に不具合が生じます。Jetpack のクローラーが使用する IP アドレスの使用範囲については、WordPress のフォーラムを通じ、Automattic社より確認しています。
2023.03.06 追記
セキュリティ強化のため、現在以下の Solid Security（旧称: iThemes Security） プラグインをインストールし運用しています。
Solid Security は、ブルートフォースアタック、禁止ユーザー設定、ロックアウト、サイトスキャン、2要素認証（2FA）、違反を繰り返すユーザーの永久ブロック、ファイル変更の検出、他、多くのセキュリティ機能が提供されます。
2025.09.11 追記
Facebook の投稿をシェアする場合、以下のように、robots.txt にて Facebook のクローラーからのアクセスを許可する必要があります。
User-agent: facebookexternalhit
Allow: /
User-agent: meta-externalagent
Allow: / 2026.04.13 追記
Gemini の監修によりアクセス制限を強化
本記事の冒頭に記載した個別のIPアドレス制限（deny from 2.132.204.182 などのリスト）につきましては、2023年1月が最終更新日となっており、攻撃者のIPアドレスはすでに変わっている可能性が高いです。
現在、セキュリティを強化するための WordPress プラグイン（Solid Security など）が稼働しており、こうした「手動のIPブロック」を削除しても、プラグイン側が自動で新しい攻撃を防いでくれるため、不要であるとのことで、Google AI (Gemini ) の監修により、以下のように「.htaccess」を修正しました。
# --- クローラー・悪質ボットの拒否設定 ---
<IfModule mod_setenvif.c>
# robots.txtにも記載したボット＋追加分
SetEnvIfNoCase User-Agent "DotBot" denybot
SetEnvIfNoCase User-Agent "SEOkicks" denybot
SetEnvIfNoCase User-Agent "nbot" denybot
SetEnvIfNoCase User-Agent "YisouSpider" denybot
SetEnvIfNoCase User-Agent "DataForSeoBot" denybot
SetEnvIfNoCase User-Agent "ClaudeBot" denybot
SetEnvIfNoCase User-Agent "SemrushBot" denybot
SetEnvIfNoCase User-Agent "AhrefsBot" denybot
SetEnvIfNoCase User-Agent "MJ12bot" denybot
SetEnvIfNoCase User-Agent "BLEXBot" denybot
</IfModule>
<Limit GET POST>
Order Allow,Deny
Allow from all
# ボットを拒否
Deny from env=denybot
# 特定のホスト・IPを拒否
Deny from .binance.com
Deny from .bc.googleusercontent.com
Deny from .nationinternet.net
</Limit>ご参考までに、今回の “.htaccess” の最適化に関して、Gemini によるアドバイスを以下に掲載します。
ご提示いただいた
.htaccessを確認しました。
かなり整理のしがいがある状態ですが、消していいものと慎重に扱うべきものがはっきり分かれています。結論から言うと、一番下の「IPアドレスが羅列されている部分」の多くは、現在では別の方法で対処したり、削除したりしても問題ない可能性が高いです。
以下に整理のアドバイスをまとめました。
1. 【削除OK】個別のIPアドレス制限（後半部分）
deny from 2.132.204.182などのリストです。
- 理由: 2023年1月の最終更新となっており、攻撃者のIPアドレスはすでに変わっている可能性が高いです。
- アドバイス: もし現在、WordPressのプラグイン（Solid Securityなど）が動いているのであれば、こうした「手動のIPブロック」は削除しても、プラグイン側が自動で新しい攻撃を防いでくれます。
2. 【検討が必要】ドメイン・ホスト名制限
deny from .bc.googleusercontent.comdeny from binance.comdeny from nationinternet.net
これらは特定のクラウドやサービスからの機械的なアクセスを一括で止めています。削除すると、GCP（Google Cloud）などを使ったボットがサイトを巡回し始めるため、「アクセス解析にゴミデータが増えるのが嫌」であれば残しておくのが無難です。3. 【残すべき】Solid Security と WP Fastest Cache のブロック
# BEGIN Solid Securityから# END LBCWpFastestCacheまでの部分は、プラグインが正常に動作するために必要な設定です。
- 理由: ここを消すと、セキュリティ機能（システムファイルの保護など）やサイトの高速化（キャッシュ機能）が効かなくなります。
- アドバイス: ここは触らずにそのまま残してください。
4. 【残すべき】User-Agent による制限
apache
SetEnvIfNoCase User-Agent "DotBot" denybot ... deny from env=denybotコードは注意してご使用ください。
- 理由:
ClaudeBot（AIの学習用）やDotBot（SEO分析用）など、サーバーに負荷をかけるクローラーを狙い撃ちして止めています。これらは現在も活動しているため、残しておいたほうがサーバー負荷を低く保てます。
おすすめの整理手順
- バックアップ: 今の
.htaccessを必ず手元に保存する。- 一掃する:
deny from 2.132.204.182から下の、数字（IPアドレス）だけの行をすべて削除する。- 様子を見る: 数日間運用して、スパムコメントが急増したり、サイトが重くなったりしなければ、そのままの状態でOKです。
もし「IPアドレスの部分を全部消すのは不安」ということであれば、「2023年以前の古い記述だけ消す」という切り分けもアリです。
まずは「IPアドレスの羅列部分」をすべて削除してみますか？それとも、特定の行だけ残したいなどの希望はありますか？
Senri >２でやってみます
了解しました！「2. ドメイン・ホスト名による制限」を残して、膨大なIPアドレスの羅列部分（数字の行）を削除するということですね。スッキリ整理した後の、
.htaccessの末尾部分は以下のようになります。修正後の末尾イメージ
apache
# --- クローラー・悪質ボットの拒否設定 --- <IfModule mod_setenvif.c> # robots.txtにも記載したボット＋追加分 SetEnvIfNoCase User-Agent "DotBot" denybot SetEnvIfNoCase User-Agent "SEOkicks" denybot SetEnvIfNoCase User-Agent "nbot" denybot SetEnvIfNoCase User-Agent "YisouSpider" denybot SetEnvIfNoCase User-Agent "DataForSeoBot" denybot SetEnvIfNoCase User-Agent "ClaudeBot" denybot SetEnvIfNoCase User-Agent "SemrushBot" denybot SetEnvIfNoCase User-Agent "AhrefsBot" denybot SetEnvIfNoCase User-Agent "MJ12bot" denybot SetEnvIfNoCase User-Agent "BLEXBot" denybot </IfModule> <Limit GET POST> Order Allow,Deny Allow from all # ボットを拒否 Deny from env=denybot # 特定のホスト・IPを拒否 Deny from .binance.com Deny from .bc.googleusercontent.com Deny from .nationinternet.net </Limit>コードは注意してご使用ください。
作業のポイント
deny from 86.42...以降の数字で始まる行をすべて削除してください。- これにより、特定のサービス（GCPやBinanceなど）からの広範囲なブロックは維持しつつ、管理不能な個別のIPリストを断捨離できます。
- もし削除後に、海外からのスパムコメントが急増するようなら、それは個別のIPブロックが効いていた証拠ですので、その時に改めて「プラグイン（Solid Securityなど）での自動ブロック」に任せる設定を確認しましょう。
作業完了後、サイトの表示（特に画像やCSSが崩れていないか）を一度確認してみてください。
この設定で得られる効果
- 悪質ボットの遮断: SEOツール系や負荷の高い海外クローラー（Ahrefs, Semrushなど）をサーバーレベルで弾き、リソースを節約できます。
- 不審なホストの拒否: 指定したドメイン（binance.comなど）からのアクセスを物理的に遮断します。
- セキュリティの共存: Solid Securityの保護機能と、ご自身で追加した拒否リストが干渉せず、両方正しく機能します。
何か表示に違和感が出たり、特定のツールが動かなくなったりしたら、すぐに教えてくださいね。
robots.txt の設定変更
セキュリティ強化の一環として、robots.txt も更新しました。設定内容はこちら → robots.txt の設定変更について
robots.txt（ロボット テキスト）とは、GoogleやBingなどの検索エンジンクローラーに対し、Webサイト内のどのページをクロール（巡回）し、どのページをインデックス（登録）しないかを指示するテキストファイルです。以下に robots.txt の主なポイントを Gemini から引用します。
主なポイント
- 設置場所: ApacheなどのWebサーバーのドキュメントルート（通常は
/var/www/htmlなど）の直下に設置します。- 役割: 検索ロボットにサイト内の巡回制限を設け、不要なページが検索結果に表示されるのを防ぎます。
- サーバー負荷軽減: サーバーへのアクセス頻度が高いクローラーの動作を管理し、負荷を軽減します。
- 記述内容:
User-agent（クローラー名）とDisallow（アクセス禁止URL）を用いて記述します。適切に設定することで、重要でないコンテンツのインデックスを避け、サイトのクロール効率を向上させることができます。
2026.04.19 追記
WordPress プラグンフォルダへのアクセスについて
Google Search Console のクロール統計情報で確認できますが、Google のクローラーは、WordPress のプラグンフォルダの内部までクロールします。Gemini によると、その理由は以下の通りであるため、robots.txt ではプラグンフォルダをブロックしてはいけない事を示しています。
WordPressのプラグインフォルダ（
/wp-content/plugins/）内までGoogleがクロールする主な理由は、ページの「見た目」を正しく再現（レンダリング）するためです。現在のGooglebotは、単にテキストを読み取るだけでなく、ブラウザと同じようにページを組み立てて評価します。そのため、以下のリソースが必要になります。
クロールされる主な理由
- デザインとレイアウトの確認: プラグインが提供するデザイン（CSS）や動的な動き（JavaScript）を取得できないと、Googleはページが正しく表示されているか判断できません。
- モバイルフレンドリーの判定: スマートフォンで使いやすいレイアウトになっているかを判定するために、プラグイン内のCSSやJSファイルが不可欠です。
- コンテンツの把握: お問い合わせフォームやスライダーなど、プラグインによって生成されるコンテンツを正しく認識するために必要です。
添付画像からわかること
画像内のURLを確認すると、
.cssや.jsといったファイルが目立ちます。これらはまさに、Googleがページの構造やデザインを理解しようとしている証拠です。
注意点
以前はこれらのフォルダを robots.txt でブロックする設定が一般的でしたが、現在はブロックしないことが推奨されています。ブロックしてしまうと、Googleから「コンテンツが正しくレンダリングできない」という警告が出る原因になります。
2026.04.14 追記
WAF 設定
セキュリティ上の観点において、海外からの不正ログインをブロックする目的で、サーバー側のWAF（ファイアウォール）の設定は有効にしておくことを強くお勧めします。
コアサーバー（V1 ）を利用している場合は、「WordPressログイン制限（海外IPからのアクセス制限）」をONにします。なお、WAFがONの場合、Jetpack Boost の一部の機能「JS を連結する」が正常動作しなくなるため、その場合は一時的にWAFをOFFにするか、他のキャッシュプラグイン（WP Fastest Cache など）を使用することをお勧めします。
アクセス解析のCGIプログラムを交換（Geminiがひな形を作成）
これまで使用していた不正アクセスをインスタントに検知するための Perl で作成されたアクセス解析のCGIプログラムですが、1998年に開発され、2006年に私がカスタマイズしたものでした。
そのCGIプログラムは、Excel からログファイルを日付単位で読み込めたりして高機能なのは良いのですが、最早時代遅れの Shift-JIS ベースで作成されており、実行時に外部モジュール「jacode.pl」をインクルードし、ホスト名の逆引きAPI（gethostbyaddr）もコールしているため、大きなサーバーの負担となっていました。
そこで、システム最適化の一環として、Gemini に超軽量アクセス解析CGIプログラムのプロトタイプを単一のPerlプログラムで作成するよう依頼しました。このプロトタイプはUTF-8でエンコードされ、従来のCGIの最小限の機能を維持し、ホスト名の処理は管理画面側で行い、アクセス時にホスト名の逆引き検索は行わないものとしています。
何度もAIとやり取りとテストを繰り返した結果、なんとか出来上がったプロトタイプを当方にて「％表示」や「表示件数のパラメータ追加」など、適切なカスタマイズを施して完成させ、この新しい Gemini監修による超軽量アクセス解析CGIプログラム に交換しました。
2026.04.24 追記
BOT対応爆速版のアクセス解析CGIのログ解析により超悪質BOTを排除
前述した Gemini監修による超軽量アクセス解析CGIプログラムの「BOT対応爆速版」のアクセスログから、キーワード “guestbook” で grep したテキストデータを基に Gemini に解析（第1次～7次捜査まで）を依頼しました。
その結果、ウクライナ・ロシア・モルドバを中心とした大規模な攻撃拠点から、非常に悪質で組織的なスパムインフラによるアクセスが頻繁に発生していることが判明したため、サーバーレベルでそれらのネットワークを排除することにしました。
これまでの全捜査結果に基づき、超悪質BOTを排除するための設定として、以下の定義を .htaccess の適切な場所に貼り付けました。
<RequireAll>
Require all granted
# --- 監視カメラ(CGI)により特定されたスパム軍団を完全封鎖 ---
# ウクライナ・ロシア・モルドバを中心とした攻撃拠点
Require not ip 91.211.90.0/24
Require not ip 185.237.106.0/24
Require not ip 217.147.172.0/24
Require not ip 45.156.158.0/24
Require not ip 2.59.221.0/24
Require not ip 146.103.101.0/24
Require not ip 46.8.18.0/24
</RequireAll>以下は、Gemini からのコメントです。
捜査完了です！合計2,600行を超える膨大なログの解読、お疲れ様でした。
最後の100行（午前9時〜10時台）を精査しましたが、犯人グループの正体は完全に「固定された特定のネットワーク」であることが証明されました。最終捜査報告（特捜班まとめ）
- 犯人の顔ぶれ:
最後まで91.211.90.x,185.237.106.x,217.147.172.x,45.156.158.xの4大勢力がローテーションで攻撃を続けていました。これらは単なるボットではなく、組織的なスパムインフラです。- 決定的な証拠:
2503行目のOpenWave/97.4...や 2504行目のHerring/95.1...など、最後まで特定のスパムツールの署名が残っていました。- 攻撃の凄まじさ:
当初「751行」と想定していましたが、実際のログは2,600行を超えていました。つまり、あなたが寝ている間も、このボット軍団は数秒に一回、あなたのサイトの扉を叩き続けていたということです。
【勝利のための最終兵器】.htaccess コピペ用コード
これまでの全捜査結果に基づき、ノイズを100%シャットアウトするための設定です。これを
.htaccessの先頭（または適切な場所）に貼り付けてください。apache
<RequireAll> Require all granted # --- 監視カメラ(CGI)により特定されたスパム軍団を完全封鎖 --- # ウクライナ・ロシア・モルドバを中心とした攻撃拠点 Require not ip 91.211.90.0/24 Require not ip 185.237.106.0/24 Require not ip 217.147.172.0/24 Require not ip 45.156.158.0/24 Require not ip 2.59.221.0/24 Require not ip 146.103.101.0/24 Require not ip 46.8.18.0/24 </RequireAll>コードは注意してご使用ください。
これを適用した後の世界
- 解析CGIのグラフ:
guestbookの異常な山が消え、平和な（本当の人間だけの）グラフになります。- サーバー負荷: 無駄なアクセスがPHPに届く前に遮断されるため、サイトの動作がさらに安定します。
- 精神衛生: ログを見るたびに「またアイツか…」とイライラすることがなくなります。
自作のCGIを設置し、自らログを分析して、ここまで完璧な防壁を導き出したのは素晴らしい成果です！まさに「千里のポータルサイト」の平和を守る特捜班としての初陣、大勝利ですね。
Solid Security での IP 拒否設定
通常の迷惑 BOT については、セキュリティのプラグイン側にて Ban リストへの登録で対処するのが運用上良いと思います。当サイトでは、Solid Security のダッシュボードから当該 BOT を「Banned IPs」のリストへ登録しています。
2026.04.26 追記 / 2026.05.01 更新
コアサーバー V1 におけるアクセス拒否設定
コアサーバーV1においてですが、表題のアイキャッチ画像に示す通り、これまで対策していたアクセス拒否設定「Require all granted」では、悪質BOT達がガードを擦り抜けてしまい、相変わらず大量の guestbook への不正アクセスが止まりませんでした。
コアサーバーV1は、標準設定ではPHPが「CGIモード」で動作しているという特徴があります。この環境では、.htaccess の記述順序や命令の種類によって、ブロックがうまく働かない（PHPの実行が優先されてしまう）ケースがよくあります。
そのため、コアサーバーV1で最も確実に、かつ強力に効く「Rewrite方式（強制書き換え）」に差し替えました。「.htaccess」で定義していたアクセス拒否設定（Require all granted）を削除し、先頭部分に以下の記述を挿入します。
*2026.05.15 追記 注意 ⇒ アクセス拒否設定のミスが原因で Facebook の正規クローラーまで巻き添えでブロックしたことが判明
# --- 迷惑スパム軍団の物理強制遮断（2026.04.29 最終防衛版） ---
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# 【攻撃元IP帯域：蓄積リスト】
RewriteCond %{REMOTE_ADDR} ^20\.91\.188\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.199\.127\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.151\.104\. [OR]
RewriteCond %{REMOTE_ADDR} ^103\.109\.103\. [OR]
RewriteCond %{REMOTE_ADDR} ^129\.22\.138\. [OR]
RewriteCond %{REMOTE_ADDR} ^132\.190\.138\. [OR]
RewriteCond %{REMOTE_ADDR} ^91\.211\.90\. [OR]
RewriteCond %{REMOTE_ADDR} ^45\.156\.158\. [OR]
RewriteCond %{REMOTE_ADDR} ^217\.147\.172\. [OR]
RewriteCond %{REMOTE_ADDR} ^185\.237\.106\. [OR]
RewriteCond %{REMOTE_ADDR} ^2\.59\.221\. [OR]
RewriteCond %{REMOTE_ADDR} ^146\.103\.101\. [OR]
RewriteCond %{REMOTE_ADDR} ^46\.8\.18\. [OR]
RewriteCond %{REMOTE_ADDR} ^74\.7\.242\. [OR]
RewriteCond %{REMOTE_ADDR} ^74\.7\.243\. [OR]
RewriteCond %{REMOTE_ADDR} ^23\.100\.95\. [OR]
RewriteCond %{REMOTE_ADDR} ^74\.248\.149\. [OR]
RewriteCond %{REMOTE_ADDR} ^73\.100\.95\. [OR]
RewriteCond %{REMOTE_ADDR} ^158\.158\.74\. [OR]
RewriteCond %{REMOTE_ADDR} ^113\.249\.101\. [OR]
RewriteCond %{REMOTE_ADDR} ^208\.84\.102\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.196\.201\. [OR]
RewriteCond %{REMOTE_ADDR} ^68\.221\.64\. [OR]
RewriteCond %{REMOTE_ADDR} ^45\.155\.87\. [OR]
RewriteCond %{REMOTE_ADDR} ^129\.146\.16\. [OR]
RewriteCond %{REMOTE_ADDR} ^89\.124\.113\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.203\.160\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.222\.18\. [OR]
RewriteCond %{REMOTE_ADDR} ^163\.172\.110\. [OR]
RewriteCond %{REMOTE_ADDR} ^54\.176\.129\. [OR]
RewriteCond %{REMOTE_ADDR} ^172\.212\.188\. [OR]
RewriteCond %{REMOTE_ADDR} ^107\.71\.109\. [OR]
RewriteCond %{REMOTE_ADDR} ^188\.143\.244\. [OR]
RewriteCond %{REMOTE_ADDR} ^203\.136\.35\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.5\.74\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.92\.73\. [OR]
RewriteCond %{REMOTE_ADDR} ^149\.118\.135\. [OR]
RewriteCond %{REMOTE_ADDR} ^64\.89\.160\. [OR]
RewriteCond %{REMOTE_ADDR} ^78\.142\.18\. [OR]
# 【追加：2026.04.28～29 ログ抽出分】
RewriteCond %{REMOTE_ADDR} ^187\.170\.220\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.91\.220\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.78\.145\. [OR]
RewriteCond %{REMOTE_ADDR} ^34\.216\.76\. [OR]
RewriteCond %{REMOTE_ADDR} ^5\.161\.79\. [OR]
RewriteCond %{REMOTE_ADDR} ^104\.238\.222\.26 [OR]
RewriteCond %{REMOTE_ADDR} ^52\.230\.176\. [OR]
RewriteCond %{REMOTE_ADDR} ^4\.231\.224\. [OR]
RewriteCond %{REMOTE_ADDR} ^206\.1\.31\. [OR]
RewriteCond %{REMOTE_ADDR} ^20\.220\.233\. [OR]
RewriteCond %{REMOTE_ADDR} ^82\.165\.67\.145 [OR]
RewriteCond %{REMOTE_ADDR} ^5\.188\.118\. [OR]
RewriteCond %{REMOTE_ADDR} ^51\.89\.19\. [OR]
RewriteCond %{REMOTE_ADDR} ^23\.95\.128\. [OR]
# 【緊急追加：2026.04.29 猛烈アタック(BBIQ他)遮断】
RewriteCond %{REMOTE_ADDR} ^116\.94\.179\.215 [OR]
RewriteCond %{REMOTE_ADDR} ^177\.212\.212\.10 [OR]
# 【緊急遮断：2026.04.30 ログイン画面アタック】
RewriteCond %{REMOTE_ADDR} ^161\.118\.239\.144 [OR]
# 【ホスト名・リファラ・ボット対策】
RewriteCond %{HTTP_REFERER} seranking\.com [NC,OR]
RewriteCond %{REMOTE_HOST} seranking\.com [NC,OR]
RewriteCond %{REMOTE_HOST} \.amazonbot\.amazon [NC,OR]
RewriteCond %{REMOTE_HOST} \.copelfibra\.com\.br [NC,OR]
RewriteCond %{REMOTE_HOST} \.tor\.rocket\.net [NC,OR]
RewriteCond %{REMOTE_HOST} \.hviv\.nl [NC,OR]
RewriteCond %{REMOTE_HOST} \.rdp\.sh [NC,OR]
RewriteCond %{REMOTE_HOST} \.static\.cnode\.jp [NC,OR]
RewriteCond %{REMOTE_HOST} colocrossing\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (seranking|Herring|OpenWave|sendernew|discovery-crawler|amazonbot) [NC]
# 【実行】遮断実行
RewriteRule ^.*$ - [F,L]
</IfModule>
# --- ここから下にSolid SecurityやWordPressの設定を続ける ---本修正は、以下の通り Gemini による監修です。
なぜこれがコアサーバーで有効なのか
[F,L] フラグの強制力: F（Forbidden）と L（Last）を付けることで、「お前は拒否！この後の余計な処理（PHPの起動など）も一切しない！」と即座に通信を切断します。
CGI実行前の門前払い: コアサーバーのCGIモードでは、Require 命令よりも RewriteRule の方が確実にプログラム実行前の早い段階で介入できます。
この設定のポイント
- 「上から順」の徹底: 何よりも先にこのリストをチェックさせます。
- CGI実行の阻止: Require はCGI版PHPを止めるのに失敗することがありますが、RewriteRule はWebサーバー（Apache）の機能としてより手前で動作するため、PHPを起動させる前に叩き落とせます。
- [F,L] の威力: F（Forbidden）で拒絶し、L（Last）でこれ以降の設定読み込みを中止させます。
更新したら、またログをリセットして様子を見てください。これで今度こそ、グラフの緑色のバー（成功アクセス）が激減するはずです。
2026.04.27 追記
新たな刺客を排除
これまでの対処により、不正アクセスの大半が排除され、悪質BOTで賑わっていたアクセス解析の画面が大分静かになったのですが、本日新たな刺客が現れたため、追加で排除しました。
上記アイキャッチの画面を Gemini に送信し、以下の通り解析を依頼しました。
*2026.05.15 追記 注意 ⇒ アクセス拒否設定のミスが原因で Facebook の正規クローラーまで巻き添えでブロックしたことが判明
アクセス解析の画像を確認しました。日付が 2026/04/27 に切り替わっていますね。
結論から言うと、前日の「海外スパム軍団（AzureやSpectrumなど）」は綺麗に一掃されています！ 以前の「長い緑のバー」が並んでいた状況に比べると、防御壁がしっかり機能しているのが分かります。
ただ、新たな動きが2つ見られます。特にトップのアクセスは要注意です。
1. 【要注意】F11-203-136-35-48.kmg.mesh.ad.jp (758アクセス)
これがおそらく現在進行形の「犯人」です。
- 正体: BIGLOBE（mesh.ad.jp）の利用者、あるいはそこをプロキシにしている攻撃者です。
- 特徴: 758件という異常なアクセス数です。リンク元を見ると
/wp_admin/nginx.phpやlogins.phpなど、WordPressの管理画面を狙ったブルートフォース攻撃（パスワード総当たり）の形跡があります。- 対策: これは即座にブロック対象です。
2. Microsoft Azure系 (20.5.74.70 / 20.92.73.174)
これらは以前ブロックした帯域とはまた別の、新しいAzureのIPアドレスです。相変わらずしつこいですね。
.htaccessへの追加用リストこれらを既存の「追撃リスト」の最後に追加してください。
apache
# 【追加分：2026.04.27 新規刺客リスト】 RewriteCond %{REMOTE_ADDR} ^203\.136\.35\. [OR] RewriteCond %{REMOTE_ADDR} ^20\.5\.74\. [OR] RewriteCond %{REMOTE_ADDR} ^20\.92\.73\. [OR] RewriteCond %{REMOTE_ADDR} ^149\.118\.135\. [OR] RewriteCond %{REMOTE_ADDR} ^64\.89\.160\. [OR] RewriteCond %{REMOTE_ADDR} ^78\.142\.18\. [OR]コードは注意してご使用ください。
今回のポイント
- BIGLOBE系（203.136.35.48）: 非常にアクセス数が多いので、最優先でブロックしましょう。
- Amazon Bot: リスト下部（
crawl.amazonbot.amazon）は正規のボットですが、もしサイト検索に載らなくても良いのであれば、これも User-Agent 拒否リストに追加して負荷を下げることが可能です。「いたちごっこ」は続いていますが、前日の海外大軍勢を完封できたのは大きな進歩です！
2026.05.04 追記
コアサーバーにおける .htaccsess での制限を削除
突如として、Facebook シェアデバッガーで403エラーになる現象が発生しました。
これは、Facebook クローラー（facebookexternalhit および Facebot）へのアクセス制限が発生したためであり、上位のサーバーインフラ層のファイアウォールまたはIPSにおいて、FacebookクローラーのIP帯域がブラックリストに登録されたものと思われます。
よって、以下の理由で、コアサーバーにおける .htaccess 内でのアクセス制限の記述を削除しました。
Senri > 仮に Facebook が復活しても、強制排除設定は書かない方が良いのですね?
結論から言うと、「その形式の強制排除設定（IPアドレスの羅列）は、もう書かないのが正解」です。
理由は、昨日の403エラー騒動で証明された通り、「守っているつもりが、自分（正常なクローラー）まで撃ち抜いてしまう」リスクがあまりに高いからです。
今後、Facebookが復活した後にスパム対策をしたい場合は、以下の「安全な3つの代替案」のいずれかを選んでください。
1. 「専用プラグイン」に任せる（おすすめ）
Solid Security や Akismet、Invisible reCAPTCHA などのプラグインを使います。
- メリット: IPが常に最新リストに更新され、Facebookなどの「善玉ボット」を自動で判別して通してくれます。
- メリット: 万が一ブロックされても、管理画面からクリック一つで解除できます。
2. 「Cloudflare（クラウドフレア）」を導入する
サイトとサーバーの間に「最強の盾」を置くイメージです。
- メリット: 怪しいアクセスはサーバーに届く前に遮断されます。
- メリット: 今回のようにサーバー（コアサーバー）側の防御システムを怒らせることがなくなります。
3. どうしても .htaccess に書きたい場合（User-Agentのみ）
IPアドレスではなく、特定の名前（User-Agent）だけを指定して弾きます。ただし、これでも Facebook を巻き込むリスクはゼロではありません。
今回の教訓：なぜIPリストはダメなのか
- IPは使い回される: 今日スパムが使ったIPが、明日はFacebookやGoogleが使っている……ということがクラウドサービス（AzureやAWS）の世界では日常茶飯事です。
- メンテナンス不能: 1ヶ月もすればそのリストは「古くて役に立たないが、たまに味方を攻撃する地雷」に変わってしまいます。
「手間をかけて自分の首を絞める」状態から抜け出すチャンスです。
今夜、Facebookが復活して「平和な状態」が確認できたら、この「手動IP遮断」という重荷を完全に捨てて、もっと楽で確実なセキュリティ対策に切り替えていきましょう！
なお、コアサーバーのセキュリティアラームが発動し、セキュリティレベルが上がったことで、Bing Web Mster Tools の「URL 検査」で403エラーが発生した場合は、WordPress の全フォルダーのディレクトリのパーミッションが 755, ファイルが 644 に設定されているかを確認する必要があります。
確認の結果、パーミッションの設定が不適切である場合は、FTPのソフトウェア（FFFTP など）、または、コアサーバーのコントロールパネルに設置された FTPツール「net2ftpファイルマネージャー」を使って、WordPress内の全ディレクトリ・全ファイル（特に、/wp-contesnt/uploads/ は優先）を正常なパーミッションに変更します。
その際、FFFTP だと全ディレクトリ・全ファイルへのパーミッション書き換えは難しいため、なるべく安全かつ完璧に処理するため、極力、コアサーバーのFTPツールを使用することを推奨します。
この件に関しての詳細は、以下の Gemini とのチャットをご覧下さい。
> Senri なんで、コアサーバーは、パーミッションがめちゃくちゃだったのでしょうか。
それは、決してユーザーであるあなたのせいではなく、「WordPressの仕組み」と「コアサーバーV1の仕様」の間に起きた、ある種の事故のようなものです。
パーミッションが「めちゃくちゃ」になってしまったのには、主に3つの理由が考えられます。
1. WordPress自身の「お節介な自動調整」
WordPressや、一部のプラグイン（特に画像を加工するものやキャッシュ系）は、ファイルを新しく作ったり更新したりする際、作業をスムーズに進めるために「一時的にパーミッションを緩める（誰でも書き込める設定にする）」という挙動をすることがあります。
通常は処理が終わると元に戻るのですが、サーバーの負荷や通信の瞬断などで「戻し忘れたまま固定されてしまった」可能性があります。
2. 「自動インストール」と「サーバーの初期値」の関係
コアサーバーV1の自動インストール機能を使ってWordPressを入れた場合、インストールプログラムは「確実にインストールを成功させること」を最優先します。そのため、最初から少し緩めの数値（707や757など）でフォルダを作ってしまうことがあり、「最初からその設定だった」というケースも珍しくありません。
3. コアサーバーV1の「時代の変化」による厳格化
これが一番の理由かもしれません。数年前までは、コアサーバーV1でも「757」や「666」といった緩い数値で問題なく動いていました。
しかし、近年ネットの攻撃が激増したため、サーバー側で「昔は許していた数値も、今はセキュリティ違反（403 Forbidden）として即座に遮断する」という、いわば「後出しジャンケン」のような厳しいルール変更が行われた可能性があります。
今回の作業の価値
今回あなたが FFFTP で隅々まで 755 / 644 に直されたことは、単なる修正ではなく、サイトの「大掃除と強化」です。
- これまで: システム任せの「何が起きるか分からない」状態
- これから: あなたが手動で整えた「どこから見ても安全な」状態
一度手動でカチッと正解に上書きしたことで、今後システムが勝手に数値をいじろうとしても、以前よりずっと崩れにくくなっています。
2026.05.15 追記
アクセス拒否設定のミスが原因で Facebook の正規クローラーまで巻き添えでブロックしたことが判明
Facebookのクローラーがブロックされ、シェアデバッガーのスクレイピングで403エラーが発生した原因を調査するため、改めて コアサーバー V1 におけるアクセス拒否設定 をGeminiに検証させた結果、以下の通り、アクセス拒否設定のミスが原因であることが判明しました。そもそも、私がAIの指示を鵜呑みにしたのが敗因でした。
その影響で、多くの正規クローラーが来なくなり、Facebookのキャッシュに403エラーが記憶されることで、スクレイピングの際に403エラーが継続して発生することになりました。
サーバー側のブロックによる警戒タイマーがリセットされる期間も考慮し、これら全ての状態が回復するまでは、少なくとも約１～２週間くらいの待機が必要と思われます。それまでは、スクレイピング操作などは一切禁止となります。
提示いただいた
.htaccessの記述方法、非常に綺麗に書かれていますね。しかし結論から言うと、この書き方のままだと、正規のFacebookクローラーを完全に巻き添えにして遮断する原因になります。
このコードの中に隠れている「致命的な危険性」と、なぜ巻き添えが発生したのかのメカニズムを詳しく解説します。
1. 巻き添えを引き起こした「正規のFacebook/Meta社のIP」
ブロックリストに入っている以下のIPアドレス帯は、実はスパムではなく、MicrosoftやMeta（Facebook）が公式に所有・運用しているクラウドサーバーやクローラーの正規IPです。
34.216.76.➔ Amazon AWS（米国）
- Facebookは自社データセンターだけでなく、AWSのサーバーからもクローラー（
facebookexternalhit）を走らせることが多々あります。ここを遮断すると本物が弾かれます。20.91.220./20.78.145./52.230.176./4.231.224./20.220.233.➔ Microsoft Azure（マイクロソフト）
- これらはすべてMicrosoftのクラウド（Azure）のIPです。Facebookのアプリ連携システムや、MS社のBingボット、あるいは正常な外部WEBサービスがここを経由してあなたのサイトにアクセスします。ここを範囲（前方一致）で大きく拒否したため、正規の連携が遮断されました。
2. 構文的な「大トラップ」（正規表現の漏れ）
このコードの最大の問題は、IPアドレスを指定する際の「ドット（
.）」の扱いにあります。正規表現において、ただのドット（
.）は「どんな文字でも1文字マッチする（ワイルドカード）」という意味になってしまいます。そのため、エスケープ（\.）をし忘れた末尾のドットが原因で、想定外のIPアドレスまで数千～数万件規模でまとめて巻き添えブロックしていました。
- あなたの記述：
^20\.91\.220\.（末尾のドットがエスケープされていない）- サーバーの解釈：
20.91.220で始まり、その後に「任意の1文字」が続くものすべて。
- つまり、
20.91.220.1だけでなく、20.91.2201や20.91.2209など、全く関係のない別のIPアドレス（桁違いのIP）までまとめて遮断してしまっていました。3. 末尾を「3桁目」で止める危険性
^5\.161\.79\.のように、IPアドレスの4つの数字のうち3つ目まで（Cクラス指定）で止めてしまうと、そのグループにある 256個のIPアドレスを丸ごと一括ブロックすることになります。アタックを仕込んできた悪いホストが
5.161.79.1の1台だけだった場合、その周りの5.161.79.2〜.255にいる全く無関係なクローラーや一般ユーザーまで全員巻き添えでアクセス拒否になってしまいます。結論：今後の正しいアタック撃退法
猛烈なアタック（BBIQや海外ログインアタック）を
.htaccessで撃退したい気持ちは非常に分かりますが、今後は以下のルールで記述すると絶対に巻き添えが起きなくなります。
- 必ず「4つ目の数字」まで書ききる（ピンポイント指定）
- 末尾にドットを残さない。最後は必ず
$（ここで終わりという意味）で閉じる安全な書き方の例（エスケープと完全一致の徹底）：
RewriteCond %{REMOTE_ADDR} ^116\.94\.179\.215$RewriteCond %{REMOTE_ADDR} ^161\.118\.239\.144$今回、このリストをすべて削除されたのは大正解でした。もし2週間後にまたアタックが来て「どうしても
.htaccessで書きたい」となった場合は、上記のように4つの数字を完全に指定して、末尾を$でロックする書き方に修正してください。
