WEBサイトYandexの通信が大きく落ちた週、悪質な自動アクセスは止まらず別の業者へ移った、とCloudflareは書いた ── 総量の増減ではなく、名乗り・発信元・ふるまいで分けて数える13項目（2026年10月時点）
Yandexの通信が大きく落ちた週、悪質な自動アクセスは止まらず別の業者へ移った、とCloudflareは書いた ── 総量の増減ではなく、名乗り・発信元・ふるまいで分けて数える13項目（2026年10月時点）
目次
01 何が起きたか — Yandexの通信が大きく落ちた週、悪質な自動アクセスは止まらず別の業者へ移った、とCloudflareは書いた
Cloudflareが10月14日に出した分析
Cloudflareのブログに、Yandexの障害の週の通信を分析した記事が出た。題は「Yandex outage: Data shows that instead of going dark, malicious bots went on the move」（訳: Yandexの障害 — データによれば、悪質なボットは消えたのではなく、移動した）で、日付は2026年10月14日と書かれている。2026年10月15日に開いて読んだ。
記事の出発点は、Yandexのデータセンターへの攻撃が報じられたあと、ロシアのボット運営や世論工作の拠点が止まったという主張が広まり、HTTPの通信量のグラフが急に落ちていたことである。ブログは、総量のグラフは誤解させやすいと書いて、中身を分けて見ている。
先に断っておく。このあとに出てくる割合や増減は、すべてCloudflareが自社のネットワークで見た数字である。Cloudflareを通ったお客様のサイトの通信の集計であり、読者のサイトの数字ではない。この記事は、その数字を自社に当てはめるためではなく、自動アクセスを数えるときの分け方を取り出すために読んだ。
Yandexの2つのネットワークは、役目が違った
ブログは、Yandexに関係するネットワークの番号（ASN）を2つに分けて見ている。1つは検索エンジンが使うAS13238、もう1つはクラウドのサービスが使うAS200350である。どちらも通信は落ちたが、落ちたものの中身が違った。
- 検索用（AS13238） — 落ちた分は、ほとんどが検証済みの検索クローラーによる、ページや画像の巡回だった。リクエストの99.5%が自動で、自動のうち93.6%は、Cloudflareが「検証済み（Verified）」と分類したものと書かれている。
- クラウド用（AS200350） — 脆弱性を探るような悪質な動きは減ったが、大量の自動の送信は消えなかった。リクエストの約95.0%がボットで、そのうち検証済みは0だった。ボットのリクエストの3分の2近くは、サイトへデータを送るものだったと書かれている。
世界全体に占める割合も書かれている。検索用は0.05%、クラウド用は0.01%である（ブログの書き方のままで、何に対する割合かは、本文に明示されていない）。どちらも小さい。この記事は、この小ささも、「Yandexが止まったから世界の悪質なボットが止まった」とは言えない理由の1つだと読んだ。
ブログの結論は、2つある
ブログのまとめは、検索の巡回が減ったことと、悪質な自動化が止まらず移動したことの2つである。移動のしやすさについて、ブログはこう書いている。
"Cloud workloads are portable, so when a data center goes dark or an IP prefix gets blocked, operators can migrate their scripts to another provider in hours."
（訳: クラウドの仕事は持ち運べる。だから、データセンターが止まったり、IPアドレスの範囲が遮断されたりしても、運営者は数時間で、自分のスクリプトを別の業者へ移せる。）
この記事が読んだもの、読めなかったもの
読んだのは、Cloudflareのブログ本文、Yandexの公式ヘルプ、Googleの確認方法の文書、JA4の公開資料、Cloudflareの文書2つ、OWASPとIPAの資料である。すべて2026年10月15日に開いた。
確かめていないものもある。Cloudflareの集計のもとのデータは見られない。Radarの画面は開いていない。Yandexのヘルプは、更新日を画面で見つけられなかった。当サイトのログでYandexの動きを数えることも、していない。この記事の主題は、攻撃の評価ではなく、自動アクセスを名乗り・発信元・ふるまいの3つで分けて数える手順である。
02 なぜ・背景 — 通信の総量では、悪質な自動アクセスの量は読めない
総量が落ちたのは、ネットワークが落ちたから
ブログは、HTTPの通信量が急に落ちたことは、ネットワークが止まったことしか示さない、と書いている。
"A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted."
（訳: HTTPの通信量の全体が落ちたことが確かめるのは、そのネットワークが止まったことだけである。悪質な、または追跡をかわすボットが妨げられたかどうかは、分からない。）
読む側に必要なのは、グラフの落ち方ではなく、落ちた分の中身である。検索用の落ちた分は、検索クローラーの巡回だった。クラウド用は、探るような動きは減っても、別の業者に移った。同じ「Yandexの通信が落ちた」でも、中身を分けると意味が逆になる。
世界全体の自動アクセスの割合は、ほとんど動かなかった
ブログには、日別の表がある。世界全体のHTTPリクエストに占める自動アクセスの割合と、ロシア発のHTTPリクエストに占めるロシア発の自動アクセスの割合を、10月1日から6日の基準と並べたものである。括弧の中は、ブログの表にある基準との差で、書き方も表のままにした。
| 期間 | 世界の自動アクセスの割合（全HTTPリクエストに占める） | ロシア発の自動アクセスの割合（ロシア発のHTTPリクエストに占める） |
|---|---|---|
| 10月1日〜6日（基準） | 39.4% | 50.4% |
| 10月7日〜8日 | 39.2%（-0.2%） | 48%（-2.4%） |
| 10月9日 | 39.4%（+0%） | 42.5%（-7.9%） |
| 10月11日 | 39.5%（+0.1%） | 42.2%（-8.2%） |
| 10月12日 | 39.6%（+0.2%） | 43.6%（-6.8%） |
| 10月13日 | 39.5%（+0.1%） | 42.1%（-8.3%） |
世界全体の割合は、基準との差が最大でも0.2しか動いていない。ロシア発は、10月9日以降、基準より6.8から8.3低い状態が続いた。ブログは、ロシア発の自動アクセスが減ったのは、Yandex自身の通信のほとんどが自動だったので、Yandexの通信が消えた分とほぼ釣り合ったからだと書いている。
この表だけを見ると、「ロシア発のボットが減った」と読む人が出る。実際に減ったのは、Yandex自身の自動アクセスである。表を読むときは、どの発信元が消えて下がったのかを、先に分ける必要がある。
ブログの数字を読んでいて、引っかかった所が2つある
1つ目は、基準の割合が2組あることである。本文は、事件の前の自動アクセスが、世界のHTTP通信の36.1%、ロシアのIPアドレスからの通信の35.8%を占めたと書く。上の表の基準は39.4%と50.4%である。違いの理由は、読んだ範囲では、書かれていなかった。
2つ目は、括弧書きの「10月14日18:00 UTC時点で、通信は平常の85%」である。直前の文は、通信が基準より86〜90%低い状態にとどまったと書いている。並べると読み方が合わず、どちらの意味かは、本文から決められなかった。
これは、分析が誤りだという指摘ではない。何を数えたかが書かれていない他人の数字は、同じ記事の中でも食い違って見える、という例として書く。この点は、当サイトの記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」で、自社のログに当てはめるときの3つの問いにまとめた。
止まったもの、動いたもの
クラウド用のネットワークでは、ボットのリクエストが約40%減った。WordPressのプラグインを探る動きは90%、スキャナーと自ら名乗るリクエストは93%減り、Cloudflareのお客様が設けた遮断の件数も70%減った。
動いたものの例が、賭博関連の1つのお客様のアカウントである。Yandex.Cloudから来たボットのリクエストのほとんどが、このアカウントに向いていた。10月8日の障害の直後に、Yandex.Cloudからこのアカウントへのリクエストはゼロになり、同時に、Radistや Selectelなど、ロシアの別のホスティング業者から、同じリクエストが現れ始めた。業者が変わっても、同じだったものが3つあった。
- TLSクライアントの指紋（JA4）が同じだった。
- 珍しいリクエストの経路とHTTPのヘッダーが同じだった。
- 独自の名乗り（User-Agent）の文字列が同じだった。
ロシア発のボットが賭博関連のアカウントに向けたリクエストの合計は、1週間で1億6,770万から1億7,010万へ、+1.4%とほぼ横ばいだった。ブログは、自動化は一度も止まらず、運営者が仕事を別のクラウドの業者へ移しただけだと書いている。
Cloudflareも言い切っていない点
ブログは、ソーシャルメディアへの自動投稿が止まったかも調べている。投稿・返信・いいねに当たる入口へのボットの通信は、ロシア発が5.7%減、世界全体が1.1%増だった。ブログは、この数字は「止まった」という主張を支えていないと書く。ただし、Cloudflareの外のデータなしには、関係が無いとも言い切れない、とも書いている。
賭博関連の話も、1つのお客様のアカウントの観察で、Cloudflareの全部のお客様に起きたことではない。ブログ自身も、発信元の業者と責任者を分けて書いている。
"While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic."
（訳: 悪質な通信が特定の業者から出ていても、それが、その通信の責任者が誰かを必ずしも教えてくれるわけではない。）
業者が分かっても、動かしている人は分からない。この記事が扱うのも、「誰か」ではなく、どう分けて数えるかである。
03 用語 — 読み違えやすい言葉を先にそろえる
ASN（エーエスエヌ）
用語
ASN：インターネットの中で、1つの運営者が経路を管理しているネットワークの単位に付く番号である（自律システム番号）。通信事業者、クラウドの業者、大学などが持つ。IPアドレスから、どのASNに属するかを引ける。Yandexのヘルプも、自社のロボットが使うネットワークを、AS13238などの番号で挙げている。
JA4（TLSクライアントの指紋）
用語
JA4：暗号化通信（TLS）を始めるときの、クライアントの振る舞いから作る識別用の文字列である。JA4の公開資料は「TLS Client Fingerprinting（TLSクライアントの指紋）」と呼ぶ。Cloudflareの文書は、同じ種類のクライアントは似た始め方をするので、接続先が変わっても識別に使える、と説明している。名乗りと違い、ログの1項目として最初から入っているとは限らない。
逆引きDNSと順引きDNS
用語
逆引きDNS：IPアドレスから、ホスト名（機器の名前）を引く検索である。順引きDNS：ホスト名から、IPアドレスを引く検索である。GoogleもYandexも、ロボットが本物かどうかを、逆引きで出た名前の末尾を見て、その名前を順引きして元のIPアドレスに戻るかを確かめる方法で案内している。
検証済み（Verified）のボット
用語
検証済みのボット：Cloudflareが、自分が何者で何をするかを隠さないと確認したボットやエージェントである。条件は2つで、名乗りが正直であること（署名、公開されたIPアドレスの一覧と固定した名乗り、逆引きDNSのいずれか）と、悪用しないこと（robots.txtを守る、リクエストの頻度が妥当、など）である。
名乗り（User-Agent）
用語
名乗り（User-Agent）：アクセスしてきたソフトが、HTTPのヘッダーで自分で申告する名前の文字列である。ログに1行ごとに残る。申告なので、誰でも好きな名前を書ける。「Yandexを名乗る」ことと「Yandexである」ことは、別の確認になる。
04 型別 — 自社がどれに当たり、何を、どの順で確かめるか
3つの見方を並べる
ブログが示した分け方を、読者のサイトで使う形に直すと、3つの見方になる。それぞれ、分かることと、分からないことが違う。
| 見方 | 分かること | 分からないこと | 偽られやすさ |
|---|---|---|---|
| 名乗り | 自分で何者だと申告しているか | 申告が本物か | 書き換えは自由で、偽りやすい |
| 発信元 | どの業者のネットワークから来たか | その業者の中で誰が動かしているか | 名乗りよりは偽りにくいが、業者を移れる（ブログの例） |
| ふるまい | 何を、どの順で、何回求めるか | 人かソフトか、善意か悪意か | 業者が変わっても残りやすい。ただし指紋は変わる |
3つの見方は、どれか1つで足りるものではない。名乗りだけで数えると、偽りに引っかかる。発信元だけで止めると、移られる。ふるまいだけで判断すると、材料が足りない日がある。重ねて読むのが、この記事の手順である。
🅰 型A — ログインや会員登録の画面を持つサイト
この型は、ふるまいを先に見る。ブログによると、Yandex.Cloudのボットは、リクエストの3分の2近くがサイトへデータを送るものだった。ログイン、登録、パスワードの再設定、問い合わせの入口に、どの発信元から、1日に何回送信が来ているかを数える。表示の件数だけを見ていると、入口への送信は見えない。
入口の異常を、アカウント単位で調べる画面については、当サイトの記事「Cloudflareは、ログインと会員登録の異常をアカウント単位で調べる画面を先行利用の顧客に出した ── 同じ問いを自社の記録に当てて確認する13項目（2026年10月時点）」が、Cloudflareの先行利用の画面を例に、同じ問いを自社で確かめる方法を書いている。
🅱 型B — 記事や紹介のページが中心のサイト
この型は、名乗りと発信元を先に見る。検索エンジンの名乗りが本物かを、逆引きで確かめる。ブログによると、Yandexの検索用ネットワークからニュースのサイトへの通信の約90%は、YandexBotによる記事の巡回だった。名乗りの数え方は、当サイトの記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」にある。
🅲 型C — Cloudflareなど、前段の事業者を使っているサイト
この型は、事業者の画面にボットの数字がある。画面の「ボット」の定義は、事業者のものである。JA4については、Cloudflareの文書に次の記述がある。
"JA3 and JA4 fingerprints are only available to Enterprise customers who have purchased Bot Management."
（訳: JA3とJA4の指紋は、Bot Managementを購入したEnterpriseのお客様だけが使える。）
この文書の最終更新は2026年5月6日である。プランによっては、指紋の値が出ない。出ないなら、名乗りと発信元と経路の並びで見る。事業者の画面と自社のログの、両方を見る。
🅳 型D — 自分のアクセスログだけがあるサイト（当サイトもこの型）
この型は、ログと、無料の道具で3つの見方をそろえる。名乗りは、ログの文字列を数えるだけでよい。発信元は、IPアドレスの逆引きと、ASNの検索で引く。ふるまいは、同じ発信元が求めたURLの並びを見る。指紋の値は、ログの項目に入っていなければ、使えない。
手順1 — 名乗りで分ける
ログの名乗りの欄を数えて、上位10件を並べる。「Googlebot」「bingbot」「YandexBot」のような検索エンジンの名前、「python」「curl」「Go」のようなプログラムの名前、ふつうのブラウザの名前に分ける。分けるだけで、本物かどうかは、まだ決めない。
手順2 — 発信元で分ける
名乗りの行から、IPアドレスを5つ選び、逆引きで出たホスト名の末尾を書く。Yandexのヘルプによれば、Yandexのロボットのホスト名は、yandex.ru、yandex.net、yandex.comのどれかで終わる。ほかの末尾なら、Yandexのロボットではない。次に、そのホスト名を順引きして、元のIPアドレスに戻るかを確かめる。戻らなければ、ホスト名は偽物である。
名乗りが無くても、IPアドレスからASNを引くと、どの業者のネットワークかが分かる。ヘルプが挙げるロボットのネットワーク（AS13238、AS208722、AS212066）に、ブログが取り上げたクラウド用のAS200350は含まれていない。Yandexのクラウドから来ていても、検索のロボットとは限らず、そのクラウドを借りた誰かの可能性がある。
手順3 — ふるまいで分ける
同じ発信元について、求めているURLの順番と、1日あたりの回数と、入口（ログイン、登録、問い合わせ）への送信の有無を書く。決まった珍しいURLだけを求める、同じ順序を繰り返す、入口へだけ送信する、というのは、ふるまいの偏りである。
手順4 — 3つを重ねて、移動を探す
同じ名乗り、同じURLの並びが、日を追って別のASNに出ていないかを、3日分の表で見る。ブログの例は、業者が変わっても、名乗りと経路と指紋が同じだった。名乗りと経路の組が同じで、発信元だけが変わるなら、発信元ごとに止める方法は追いつかない。
手順5 — 結果を3つに分けて書く
最後に、結果を3つの見方に分けて書く。確かめていないものは、確かめていないと書く。数字の隣には、期間とログの本数を書く。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- アクセスログを直近7日分、HTTPSのものを含めて手に入れ、ファイルの数と行の数を書く
- 名乗り（User-Agent）の欄を数えて、上位10件を、件数つきで書く
- 名乗りに「Googlebot」「bingbot」「YandexBot」のどれかを含む行から、IPアドレスを5つ選んで書く
- 項目3の5つのIPアドレスに逆引きを行い（hostコマンドなど）、出たホスト名の末尾を書く
- 項目4のホスト名を順引きして、元のIPアドレスに戻るかを、5つそれぞれ「戻る」「戻らない」で書く
- ログのIPアドレスの上位10個を、ASNの検索で引き、ASNの番号と事業者の名前を書く
- 項目6の10個のASNについて、1日あたりの行数を日別に並べ、全体に占める割合を書く
- 日別の表で、突然増えて数日で消えたASNと、新しく現れたASNがあるかを、3日分見て「ある」「ない」で書く
- ログイン・登録・パスワード再設定・問い合わせの入口への送信を、日別に数え、多い発信元の上位5つを書く（画面が無ければ「無し」と書く）
- 項目9で多かった発信元を1つ選び、求めたURLを時刻順に20件並べて、人が辿れる順かどうかを書く
- 同じ名乗りと同じURLの組が、別のASNにも出ているかを、3日分の表で数えて書く
- IPアドレスで止めているものがあれば、止めた日の前後3日の、同じ名乗りの行数を並べて書く（止めていなければ「止めていない」と書く）
- 項目1から12の結果を「名乗り」「発信元」「ふるまい」の3列の表にまとめ、各列に「確かめた」「確かめていない」を付けて、日付つきで保存する
時間が限られているときは、項目1・2・3・4・5・6の6つだけでも、名乗りが本物か、どの業者から来ているかの見当は付く。
06 代替・他の選択肢 — IPアドレスで止める以外の方法
IPアドレスで止める — 効くときと、効かなくなるとき
IPアドレスやASNで止める方法は、その発信元から来続けるものには効く。ただし、運営者が数時間で別の業者へ移れるなら、次の発信元には効かない。止めた数が増えても、自動アクセスが減ったとは限らない。止める前と後で、同じ名乗りと経路の組が別の発信元に出ていないかを並べて見る。
ふるまいで見る — ブログが挙げた3つ
ブログは、対策の軸を、発信元ではなく、リクエストの中身に置いている。
"Defending against automated threats requires inspecting request behavior, such as identifying shared JA4 fingerprints, monitoring anomalous request rates, and applying WAF rules to sensitive endpoints, regardless of which network the request originates from."
（訳: 自動化された脅威から守るには、リクエストのふるまいを調べる必要がある。たとえば、共通するJA4の指紋を見つける、異常なリクエストの頻度を監視する、重要な入口にWAFの規則を当てる、といったことで、リクエストがどのネットワークから来ているかは問わない。）
指紋には注意が要る。JA4の公開資料は、指紋が変わることをはっきり書いている。
"So I want to make this clear: JA4 fingerprints will change as application TLS libraries are updated, about once a year."
（訳: だから、はっきり言っておきたい。JA4の指紋は、アプリのTLSライブラリが更新されるにつれて、約1年に1回は変わる。）
指紋で見つけた共通点は、「今日、同じ運営者だと見分ける手がかり」であって、「永久に変わらない印」ではない。頻度と入口の見方と組み合わせる。
公式の確認方法で、名乗りの本物を確かめる
名乗りが本物かの確かめ方は、各社が公式に書いている。Yandexのヘルプは、こう始まる。
"Some robots can disguise themselves as Yandex robots by indicating the relevant User Agent. You can check the authenticity of a robot using a reverse DNS lookup."
（訳: ロボットの中には、該当するUser Agentを書くことで、Yandexのロボットのふりをするものがある。ロボットが本物かどうかは、逆引きDNSで確かめられる。）
順引きで元のIPアドレスに戻らなければ、ホスト名は偽物だとも書いている。Googleの文書も、同じ確認方法を、Googleを名乗る迷惑なアクセスを心配するときに使うものとして案内している。Googleは、逆引きのほかに、公開しているIPアドレスの範囲の一覧に照らす方法も書いている。Yandexは、IPアドレスが頻繁に変わるため、ロボットのIPアドレスの一覧を公開していないと書いている。会社によって、使える確認方法が違う。Googleの範囲の一覧の置き場が移った件は、当サイトの記事「GoogleクローラーのIPレンジJSONファイルが新しい場所へ ── 自社の設定で確認する13項目（2026年9月時点）」にある。
入口を守る — ログインや登録の画面
ブログの対策の3つ目は、重要な入口に規則を当てることだった。OWASPの資料は、ウェブアプリが望まれない自動の利用に毎日さらされていて、その多くは脆弱性の悪用ではなく、正しい機能の悪用だと書いている。外から、自社の入口に何が見えているかを確かめたいときは、当サイトの無料ツール🔧 WEBサイトの外からできるセキュリティ対策監査ツール（要ログイン）がある。URLを入れると、外から取れる情報を使って状況を確かめる。自分で管理しているサイトに使うものである。入口の保護そのものを設定するものではない。
ログを読みやすい形にする
ログの量が多くて手では見切れないときは、IPAの攻撃兆候検出ツールが使える。IPAのページは、iLogScannerを「ウェブサーバのアクセスログから攻撃と思われる痕跡を検出するためのツール」と説明している。当サイトの無料ツール🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール（要ログイン）は、ログを入れると結果をExcelでダウンロードできる。これは攻撃の痕跡を探すもので、自動アクセスの内訳を数えるものではない。内訳は、手順1と2の作業になる。
数字を報告に載せるとき
注意
Cloudflareの割合や増減は、Cloudflareのお客様の通信の集計で、読者のサイトの数字ではない。報告に書くときは、「Cloudflareが2026年10月14日に書いた数字」であること、何を数えた割合か（全HTTPリクエストか、ロシア発のHTTPリクエストか）を、数字の隣に書く。賭博関連の1アカウントの観察を、「悪質なボットは必ず業者を移る」と一般化して書かない。
注意
名乗りが偽物だったことと、悪質だったことは、別の確認である。逆引きが合わなければ「そのロボットではない」とは書ける。悪質かどうかは、ふるまい（入口への送信の偏り、頻度、経路）を見て決める。
07 当サイトで確かめたこと
当サイトは、Cloudflareを使っていない型である
当サイト（WEBサイトサポート）は、Cloudflareを使っていない。だからブログの数字は、当サイトのアクセスの記録には入っていない。この記事の手順は、当サイトでも、自分のアクセスの記録で確かめられる形になっている。
名乗りだけで数えた記録がある
当サイトの記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」では、2026年10月5日から12日までのHTTPSのアクセスログ46,929行を、名乗りで6つに分けて数えた。名乗りから自動と分かるものは36.2%、残りの63.8%はブラウザを名乗るもので、人とは限らなかった。名乗りは自己申告で、公式のIPアドレスの一覧と照らす作業はしていない、とも書いてある。
この記事の言葉でいえば、当サイトが数えたのは名乗りだけである。発信元とふるまいは、まだ数えていない。発信元の見方が要る理由は、当サイトの記事「「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった」で見つけた。AIクローラーの名前で大量に拒否されたように見えた数字の正体は、日ごとに1台の貸しサーバーが、数十の名前を使い分けて送ったものだった。
確かめていないこと
公式のIPアドレスの一覧と、当サイトのログを照らして数え直す作業は、まだ終わっていない。ふるまいの見方（入口への送信、経路の並び）も、手順としてはまだ当サイトのログに当てていない。当サイトのログでYandexの動きを数えることも、していない。終わったら、この記事の末尾に、日付つきで書き足す。
数字の「0件」や「差」には、見た範囲を書かないと、見ていないことと区別が付かない。この点は、当サイトの記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」で書いた。
08 このテーマの、これまで
| 日付 | できごと |
|---|---|
| 2026年10月7日〜11日 | Yandexの3つの設備への攻撃が報じられたと、ブログが書いた期間 |
| 2026年10月8日 | Yandex.Cloudから賭博関連の1アカウントへのリクエストがゼロになり、別のホスティング業者から同じリクエストが現れた（ブログ） |
| 2026年10月8日 | Cloudflareの「検証済みのボット」の文書の最終更新 |
| 2026年10月11日 | Radar上で、検索用が基準より99%、クラウド用が90%低い水準まで落ちた（ブログ） |
| 2026年10月14日 | Cloudflareがこの分析を公開した |
| 2026年10月15日 | この記事の確認の日 |
この表で、攻撃の日付と場所は、ブログの記述を要約したもので、この記事では確かめていない。
当サイトの、関連する過去の記事
- AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける（2026年9月時点）
- Googleの広告用クローラーには、robots.txtの「*」の指定が効かない ── 止めたつもりのページと広告タグのあるページを突き合わせる13項目（2026年10月時点）
- 外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった
- 「守る」から「見分ける」へ ── Cloudflare Precursor GAが変えるbot対策と、WEBディレクターが今週確認すべき3点
現在の貴方のIPアドレス
このサイトで書いている人
