WEBサイトCloudflareは、ログインと会員登録の異常をアカウント単位で調べる画面を先行利用の顧客に出した ── 同じ問いを自社の記録に当てて確認する13項目（2026年10月時点）
Cloudflareは、ログインと会員登録の異常をアカウント単位で調べる画面を先行利用の顧客に出した ── 同じ問いを自社の記録に当てて確認する13項目（2026年10月時点）
目次
01 何が起きたか — Cloudflareは、ログインと会員登録をアカウント単位で調べる画面を出した。ただし、まず使えるのは先行利用の顧客だけである
2026年10月2日の発表の中身
Cloudflareの公式ブログに、2026年10月2日付で「Follow the thread: a new dashboard to investigate account abuse」（訳: 糸をたどる。アカウントの不正利用を調べる新しい画面）が載った。2026年10月13日に本文を開いて確かめた範囲では、中心はAccount Abuse Protection（AAP）という機能に、不正を調べる新しい画面が加わったという話である。ブログはAAPを、次のように説明している。
"Cloudflare’s Account Abuse Protection (AAP) creates stateful account overviews to help website owners detect and investigate abuse across login and signup activity."
（訳: CloudflareのAccount Abuse Protection（AAP）は、ログインと登録の活動にまたがる不正を、サイトの持ち主が見つけて調べられるように、状態を持ったアカウントの概要を作る。）
「状態を持った」というのは、1回のログインだけで通すか止めるかを決めるのではなく、そのアカウントのこれまでの履歴と照らして見るという意味である。ブログは、確認の通過だけでは足りない理由を、「identity checks are no longer sufficient as they capture a moment in time」（訳: 本人確認は、ある瞬間を捉えるだけなので、もはや十分ではない）と書いている。
画面が使えるのは、先行利用の顧客から
"The new dashboard is available first to Account Abuse Protection Early Access customers."
（訳: 新しい画面は、まずAccount Abuse Protectionの先行利用（Early Access）の顧客が使える。）
ブログは続けて、Bot ManagementのEnterpriseの顧客が先行利用に申し込めることを書いている。つまり、この画面は、誰でも今日から開けるものではない。Cloudflareを使っていないサイトの運営者には、そもそも縁のない画面である。
それでも、この記事が取り上げる理由
この記事が取り上げるのは、画面そのものではなく、画面が前提にしている調べ方である。不正ログインや偽の会員登録を気にするサイトなら、調べ方はCloudflareを使っていなくても自社の記録に当てられる。以降の章で、発表の調べ方を4段に分け、自社の記録で同じ問いを立てる手順に置き換える。
発表が示した調べ方は4段
ブログは、資格情報の使い回しによる攻撃を調べる場面を例にして、調べ方を4つの段に分けている。
| 段 | 発表での内容 | 自社の記録に置き換えると |
|---|---|---|
| 1 異常を見つける | ログインの失敗が増えたとき、漏えい済みの資格情報に当たった件数を見る | 日ごとのログインの件数と失敗の割合を並べる |
| 2 絞り込む | 失敗3回以上、漏えい資格情報の一致3回以上、5つ以上の別のIPアドレスから、のように条件を重ねる | 同じアカウントへの失敗と、別のIPアドレスの数を重ねて数える |
| 3 1つのアカウントを調べる | ログインの試行、新しい端末や場所、時系列を1つずつ見る | そのアカウントのログインの記録を、日時順に並べて読む |
| 4 対応を決める | 回復の手順に進む。識別子を使った規則で、以後の要求を確認または遮断する | パスワードの再設定、利用の制限、利用者への連絡の順を決めておく |
例の数字は、「手がかり」と書かれている
ブログの例では、漏えいした資格情報の判定が出たイベントが約2.4K（約2,400件）、問題なしと判定されたイベントが11.7K（約11,700件）と書かれている。この数字について、ブログは次の注意を付けている。
"This pattern is an investigative lead, not confirmation that every affected account was compromised."
（訳: この傾向は調べるための手がかりであって、影響を受けたアカウントがすべて乗っ取られたという確認ではない。）
自社の記録でも同じで、数えて出た件数は、乗っ取りの件数ではなく、見に行く先の目印である。
02 なぜ・背景 — 本人確認を通ったあとも、そのアカウントが「いつもの動き」かを見る必要が出てきた
通った瞬間の確認だけでは足りない、という考え方
ブログの冒頭は、これまでの不正防止が「正しいパスワードを入れる」「生体認証を通る」といった、その場の証明に頼っていたことから始まる。AIが広く使えるようになり、漏れた資格情報に、本人らしく見せる合成の素材を組み合わせて、確認をすり抜けようとする動きが現実的になった、というのがブログの見立てである。この見立ては、Cloudflareの主張であり、この記事は数字で確かめていない。
確かめる側が使える部分は単純で、1回の振る舞いは作れても、長く続くいつもの振る舞いは作りにくいという点である。確認を通ったアカウントでも、履歴と食い違う動きがないかを見る。この考え方は、Cloudflareを使わなくても採れる。
資格情報の使い回しは、「別のサイトの漏えい」を使う攻撃
OWASP（ウェブアプリケーションの安全を扱う非営利の団体）は、攻撃の自動化を整理した資料の中で、資格情報の使い回し（クレデンシャルスタッフィング）をOAT-008として定義している。
"Mass log in attempts used to verify the validity of stolen username/password pairs."
（訳: 盗まれたユーザー名とパスワードの組が有効かを確かめるための、大量のログインの試み。）
同じページは、推測や総当たりはせず、他のサイトで使われた資格情報をそのまま試すと書いている。だから、パスワードの強さだけでは防げない。利用者が複数のサイトで同じメールアドレスとパスワードを使っていれば、別のサイトの漏えいが、そのまま自社への入口になる。
偽のアカウントを作る攻撃も、同じ画面を使う
もう1つはOAT-019の「Account Creation」で、自動のプログラム（ボット）が会員登録の画面から偽のアカウントを作る場面である。OWASPは次のように定義している。
"Bulk account creation, and sometimes profile population, by using the application’s account sign-up processes."
（訳: アプリケーションの会員登録の手順を使った、アカウントの大量作成。ときにはプロフィールの記入も含む。）
作られたアカウントの使い道として、OWASPのページは、迷惑な投稿の生成、現金や商品の洗浄、マルウェアの拡散、検索順位やレビューやアンケートの歪みなどを挙げている。ログインの画面と会員登録の画面は、別々の入口でありながら、同じ記録の見方で調べられる。
注意
本記事は、Cloudflareの画面の使い方を説明する記事ではない。操作の手順と料金は、公式のブログには書かれていない。対象は、Bot ManagementのEnterpriseの顧客と読める。契約を考えるときは、Cloudflareの窓口で確かめる。
03 用語 — 攻撃の名前と、画面に出てくる言葉を先にそろえる
3つの攻撃の違い
OWASPの「Credential Stuffing Prevention Cheat Sheet」（訳: 資格情報の使い回し対策の早見表）は、よく混同される3つの攻撃を、次の表で区別している。表の英文は、2026年10月13日にそのページの本文で確かめた。
| 名前 | 公式の説明（英文） | 訳 |
|---|---|---|
| 総当たり | Testing multiple passwords from dictionary or other source against a single account. | 辞書などから取った複数のパスワードを、1つのアカウントに試す。 |
| 資格情報の使い回し（クレデンシャルスタッフィング） | Testing username/password pairs obtained from the breach of another site. | 別のサイトの漏えいで手に入れた、ユーザー名とパスワードの組を試す。 |
| パスワードスプレー | Testing a single weak password against a large number of different accounts. | 1つの弱いパスワードを、多数の別のアカウントに試す。 |
記録の見え方が違う。総当たりは1つのアカウントに失敗が集中し、パスワードスプレーは1つのIPアドレスに多数のアカウントへの失敗が並ぶ。資格情報の使い回しは、アカウントごとの失敗が少なく、成功が混じることがある。以上の見え方は、この記事の整理であって、OWASPの表がそう書いているわけではない。
ハッシュ化したユーザーID
用語
Hashed User ID（ハッシュ化したユーザーID）は、ブログによると、顧客がログインや登録の流れから選んだ識別子（メールアドレス、ユーザー名、電話番号など）を、Cloudflareが暗号の方式で変換し、ドメインごとに作る識別子である。元の値をそのまま持たずに、1つのアカウントの活動を結びつけられる。
自社の記録に置き換えるなら、記録に残す識別子を、メールアドレスそのものではなく、内部の会員番号か変換した値にするのが同じ発想である。記録を見る人が増えても、個人情報が広がりにくい。
Ray IDと、漏えい資格情報の照合
用語
Ray IDは、ブログによると、Cloudflareを通る要求のすべてに付く識別子で、関連する情報をSecurity Eventsで調べるのに使える。自社の記録でも、要求ごとの番号を残せば、同じ使い方ができる。
もう1つの言葉は、漏えい資格情報の照合である。Cloudflareの公式の説明書（WAF）は、受け取ったリクエストの中のユーザー名とパスワードを、過去に漏えいしたデータと照らす機能を説明している。同じ説明書は、「Leaked credentials can appear in your traffic for different reasons.」（訳: 漏えいした資格情報は、さまざまな理由で通信の中に現れうる）と書き、攻撃のこともあれば、利用者が漏えい済みのパスワードを使い回しているだけのこともある、という趣旨を続けている。照合で当たった件数は、攻撃の件数とイコールではない。
04 型別 — 画面が無くても、同じ問いを自社の記録で立てる
🅰 この記事が扱う範囲
この記事が扱うのは、自社が運営するログインと会員登録の画面を持つサイトである。会員制のサイト、通販、予約、社内向けの管理画面などが当てはまる。ログインも会員登録も持たない、情報を公開するだけのサイトは、06章の表のうち、入口を持たない場合の注意だけが当てはまる。
範囲の外は、Cloudflareの画面の操作の手順、実際に起きた乗っ取りの調査と法的な通知の判断、個人情報の扱いの規程の3つである。どれも、自社の担当者や専門家と進める。
🅱 発表が測っていないこと、書かれていないこと
ブログに書かれていない点を、先に並べておく。ここは、この記事が確かめられなかった範囲である。
- 検知の正しさ（見つけた件数のうち、本当に不正だった割合、見逃した件数）は、ブログに書かれていない
- 料金と、先行利用の細かい条件は、ブログに書かれていない（対象は、Bot ManagementのEnterpriseの顧客と読める）
- Cloudflareを使わないサイトで、同じ精度の調べ方ができるかは、書かれていない。04章の手順は、この記事の整理である
🅲 手順1: ログインと登録の入口を、すべて書き出す
最初に、入口の数を数える。ログインの画面だけでなく、会員登録、パスワードの再設定、メールアドレスの変更の画面も、攻撃の入口になりうる。管理画面、取引先向けの画面、アプリ用の窓口も、同じ要領で拾う。数え漏れた入口は、記録の対象からも漏れるので、ここが土台になる。
🅲 手順2: 件数と失敗の割合を、日ごとに並べる
サーバーのアクセスログから、ログインの画面への送信（POST）の件数を、日ごとに数える。同じ日の失敗の応答の件数も数え、失敗の割合を出す。1日だけでなく、7日分を横に並べるのがコツで、いつもの日の形が分かると、増えた日が目に入る。ログに成功と失敗の区別が残らない作りなら、そのこと自体が、直す課題になる。記録が暗号化ありとなしの通信で別のファイルに分かれているサイトは、両方を数える。片方だけを開いて「0件」と読むと、数え方の間違いを、攻撃のなさと取り違えかねない。
🅲 手順3: 同じIPアドレスと、複数のアカウント
パスワードスプレーは、1つのIPアドレスから多数のアカウントに試す形で現れる。7日分の失敗の記録から、IPアドレスごとの送信回数と、そのIPアドレスが試したアカウントの数を数える。回数が多い上位のIPアドレスから順に見る。OWASPは、IPアドレスの遮断について次のように書いている。
"Blocking IP addresses may be sufficient to stop less sophisticated attacks, but should not be used as the sole or primary defense due to the ease in circumvention."
（訳: IPアドレスの遮断は、巧妙でない攻撃を止めるには十分なことがあるが、回避が容易なので、唯一または主要な防御として使うべきではない。）
遮断は補助であって、見つける手順の目的ではない。
🅲 手順4: 同じアカウントと、複数のIPアドレス
資格情報の使い回しは、IPアドレスを次々に変えながら行われることが多い。そこで見るのは、1つのアカウントに対する失敗が、いくつの別のIPアドレスから届いたかである。ブログの例は、失敗3回以上、漏えい資格情報の一致3回以上、5つ以上の別のIPアドレス、という条件で絞り込めると書いている。
"For example, filters can be set to look at accounts with at least three failed logins, at least three leaked credential matches, and observed from at least five unique IP addresses."
（訳: たとえば、失敗が3回以上、漏えい資格情報の一致が3回以上、5つ以上の別のIPアドレスから観測された、というアカウントに絞り込める。）
OWASPの記録の早見表も、同じ見方を勧めている。
"Monitoring repeated failures for the same account, failures from multiple IP addresses, or rapid bursts of login attempts helps detect account takeover attempts before they succeed."
（訳: 同じアカウントへの繰り返しの失敗、複数のIPアドレスからの失敗、短い間に集中するログインの試みを見ていれば、アカウントの乗っ取りの試みが成功する前に見つけやすくなる。）
漏えい資格情報の照合がない自社の記録では、後半の条件は使えない。それでも、「失敗3回以上、5つ以上の別のIPアドレス」まで絞るだけで、見に行くアカウントの数は大きく減る。OWASPは、失敗を数える単位についても注意を書いている。
"The counter of failed logins should be associated with the account itself, rather than the source IP address, in order to prevent an attacker from making login attempts from a large number of different IP addresses."
（訳: ログインの失敗の回数は、攻撃者が多数の別のIPアドレスからログインを試みるのを防ぐため、接続元のIPアドレスではなく、アカウントそのものに結びつけるべきである。）
🅲 手順5: 会員登録の急な増え方を見る
偽のアカウントの大量作成は、登録の件数の増え方に出る。直近30日分を日ごとに数え、最も多い日と最も少ない日を並べる。さらに、直近の登録10件を開き、登録からはじめてログインするまでの時間と、メールアドレスの@の後ろのドメインを見る。登録の直後に同じ形の動きが並ぶときは、1件ずつ調べる。メールアドレスそのものは写さず、@の後ろだけを書く。
🅲 手順6: 失敗したときの応答が、同じかを見る
攻撃側は、ログインや再設定の応答の違いを手がかりに、存在するアカウントを探す。OWASPの「Authentication Cheat Sheet」（訳: 認証の早見表）は、次のように書いている。
"An application should respond (both HTTP and HTML) in a generic manner."
（訳: アプリケーションは、HTTPでもHTMLでも、一般的な形で応答すべきである。）
この早見表は、ユーザーIDやパスワードの誤り、アカウントが存在しない場合、停止中の場合のどれでも、同じ文言を返すことを求めている。自分の確認用アカウントで、存在しないメールアドレスと、存在するメールアドレスで誤ったパスワードを、1回ずつ試し、画面の文言とステータスコードを見比べる。再設定の画面と、会員登録の画面でも同じ見比べをする。
🅲 手順7: 漏えい済みのパスワードを断る仕組みと、記録を見る人
最後の手順は2つある。1つ目は、新しいパスワードを決めるときに、漏えい済みのパスワードを断る仕組みがあるかの確認である。米国のNIST（国立標準技術研究所）の「SP 800-63B-4」は、次のように求めている。
"verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords."
（訳: 検証する側は、これから設定される秘密の値を、よく使われる、予想されやすい、または漏えいしたと分かっているパスワードを含む拒否リストと照らさなければならない。）
2つ目は、記録を見る人を決めることである。OWASPの早見表は、ログインなどの認証機能の記録について、"Ensure that all failures are logged and reviewed"（訳: すべての失敗が記録され、見直されることを確かめる）と書く。記録は残すだけでは、見る人がいないのと同じである。なお、同じ記録の早見表は、認証のパスワードなどを、記録にそのまま残さず、取り除く、隠す、変換する対象に挙げている。ログインの失敗の記録に、入力されたパスワードが写っていないかも、このとき一緒に見る。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業で、04章の手順1〜7に順に対応している。項目10と11は、自分の確認用アカウントでの試行を含む。他人のアカウントや、許可のないサイトには試さない。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- ログインを受け付ける画面（会員向け、管理向け、取引先向けなど）を全部書き出し、画面ごとに1行でURLを書く
- 会員登録、パスワードの再設定、メールアドレスの変更の入口を、画面ごとに1行ずつ、項目1の一覧に書き足す
- 直近7日分のアクセスログを開き、ログイン画面への送信の件数を、日ごとに7つ書く（暗号化ありとなしで記録が分かれていれば、両方を数える）
- 同じ7日の失敗の応答の件数を日ごとに数え、失敗の割合を7つ書く（失敗がログに残らないなら「残らない」と書く）
- 7日分の失敗の記録から、IPアドレスごとの送信回数を数え、上位3つのIPアドレスと回数を書く
- 項目5の上位3つのIPアドレスが、それぞれ何件の別のアカウントを試したかを、「分かる」なら数を書き、「記録から分からない」ならそう書く
- 1つのアカウントへの失敗が、5つ以上の別のIPアドレスから届いた日があるかを、「ある」「ない」「記録から分からない」のどれかで書く
- 直近30日の会員登録の件数を日ごとに数え、最も多い日と最も少ない日の件数を並べて書く
- 直近の登録10件を開き、登録からはじめてのログインまでの時間と、メールアドレスの@の後ろのドメインを、1件ずつ書く
- 自分の確認用アカウントで、存在しないメールアドレスと、存在するメールアドレスで誤ったパスワードを1回ずつ試し、画面の文言とステータスコードが同じかを書く
- パスワードの再設定の画面で、存在しないメールアドレスと存在するメールアドレスを1回ずつ試し、画面の文言とメールの届き方が同じかを書く
- 新しいパスワードを決める画面で、漏えい済みのパスワードを断る仕組みがあるかを、仕様書か設定で調べ、「ある」「ない」「不明」のどれかで書く
- ログインの失敗の記録を、誰がいつ見るかを1行で書き、記録の中に入力されたパスワードが写っていないかを、1件開いて「写っていない」か「写っている」で書く
06 代替・他の選択肢 — 画面を持つか、記録を数えるか、入口で止めるか
選択肢を並べる
Cloudflareの画面は、選択肢の1つである。ほかの選択肢と並べると、次の表になる。表の最後の列は、各選択肢の前提や、確かめられていない点である。
| 選択肢 | できること | 前提と注意 |
|---|---|---|
| アカウント単位の調査画面（Cloudflare AAP） | ログインと登録の活動を、アカウントごとに見て絞り込む | 先行利用の顧客向け。検知の正しさは公式の発表に数字がない |
| 漏えい資格情報の検知（Cloudflare WAF） | リクエストの中のユーザー名とパスワードを、漏えい済みのデータと照らす | プランごとの提供内容は、公式の説明書の「Availability」で確かめる |
| 自社の記録を数える | 件数、失敗の割合、IPアドレス、アカウントを手元で数える | 記録に何が残るかで決まる。残っていない項目は、数えられない |
| 多要素認証 | パスワードが漏れていても、ログインを止める | OWASPは「by far the best defense」と書く。利用者に求められるかは、サイトの事情による |
| 漏えい済みのパスワードの拒否 | 新しいパスワードを決める時点で、使い回しを断る | すでにあるパスワードには効かない。変えてもらう手順が別に要る |
| CAPTCHA | 自動の試行を遅くする | OWASPは、破る道具やサービスがあると書く。補助として使う |
| IPアドレスの遮断 | 巧妙でない攻撃を止める | 回避が容易で、唯一の防御にしない |
多要素認証は、いちばん強いが、全員には求めにくい
OWASPの資格情報の使い回し対策の早見表は、多要素認証について次のように書いている。
"Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises."
（訳: 多要素認証（MFA）は、資格情報の使い回しやパスワードスプレーを含む、パスワードに関わる攻撃の大半に対して、飛び抜けて優れた防御である。マイクロソフトの分析は、アカウントの侵害の99.9%を止められただろうと示唆している。）
早見表は、続けて、かつては利用者によっては多要素認証を求めるのが現実的でなかったかもしれないが、最近のブラウザや携帯端末がFIDO2のパスキーなどに対応したので、"it is attainable for most use cases"（訳: ほとんどの用途で実現できる）と書いている。見出しの「全員には求めにくい」は、全員に一律に求める場面の話で、多要素認証そのものが実現しにくいという意味ではない。
同じ早見表は、全員に求めるのが難しいときの方法として、新しい端末や普段と違う国からのログインのときだけ2つ目の確認を求めること、高額の取引や管理者の設定変更のような危険の高い操作のときだけ、追加の確認を求めることを挙げている。
CAPTCHAとIPアドレスの遮断は、補助に置く
OWASPの早見表は、CAPTCHAについて、"However, CAPTCHAs are not perfect, and in many cases tools or services exist that can be used to break them with a reasonably high success rate."（訳: しかしCAPTCHAは完全ではなく、多くの場合、かなり高い成功率でそれを破る道具やサービスが存在する）と書く。どれか1つに頼らず、重ねるのが、この早見表の一貫した考え方である。各防御は、検知した件数と止めた件数も出すべきだとも書かれており、記録を数える手順は、防御の効き具合を測ることにもつながる。
漏えい資格情報の照合を、自分で持たない場合
Cloudflareの説明書によると、漏えい資格情報の照合には、Have I Been Pwned（HIBP）のパスワードのデータと、Cloudflareが集めたユーザー名のデータなどが使われる。Cloudflareを使わない場合でも、HIBPのPwned Passwordsは、パスワードのハッシュの先頭5文字だけを送って照合する方式（k-anonymity）のAPIを公開しており、新しく決めるパスワードを、その場で漏えい済みのものと照らす用途に使える。利用規約は公式の説明で確かめる。
実務のヒント
パスワードの使い回しを減らすには、利用者に長くて固有のパスワードを案内するのが近道である。当サイトの🔧 パスワード・ジェネレーターのような、ブラウザの中で作れる道具を案内に添えると、利用者が自分で決めやすい。
07 当サイトで確かめたこと
入口の数を、外から数えた
手順1に沿って、当サイトの入口を、公開されているページをたどって数えた。2026年10月13日に外から開いた範囲では、ログイン、会員登録、パスワードの再設定の3つの入口があり、会員向けのページを直接開くと、ログインの画面に案内された。送信はしていない。外から読めたのは、入口の種類だけである。
手順2を、アクセスの記録で当てた
2026年10月13日に、直近7日分のアクセスの記録で、手順2のログイン画面への送信の件数を数えた。結果の数字は書かない。書くのは、数え方の落とし穴である。最初に開いた記録には、会員向けの画面の記録が1件も無く、最初の「0件」は、開く記録の選び間違いだった。画面を開く操作が記録に出ることを先に確かめてから送信を数えると、数え方が合っているかを確認できる。
記録の中身と防御の設定は、この記事では扱わない
当サイトの記録に何が残っているか、どんな制限をかけているかは、外からは見えず、この記事にも書かない。記録の中身や制限の設定を書くと、攻撃の手がかりになりうるからである。この記事の手順1と2は、当サイトの記録にも当てた。手順3以降は、この記事の公開時点では当てていない。
08 このテーマの、これまで
公式の、日付つきの記録
- 2026年10月2日: Cloudflareのブログ「Follow the thread: a new dashboard to investigate account abuse」（訳: 糸をたどる。アカウントの不正利用を調べる新しい画面）。Account Abuse Protectionに新しい画面が加わり、まず先行利用の顧客が使えると書かれた
- 2026年9月8日: Cloudflareの説明書「Leaked credentials detection」（訳: 漏えい資格情報の検知）の最終更新（ページ上の表記は Sep 8, 2026）
- OWASPの早見表と攻撃の自動化の資料、NISTのSP 800-63B-4。取り上げたページには、公開日の表記がない
当サイトの、関連する過去の記事
- ボットが世界の57%を占めた日 — AIクローラー時代のアクセスログ、WEBディレクターが今知るべき数字 — 自動の通信が多い時代の、記録の読み方の話。
- 「守る」から「見分ける」へ ── Cloudflare Precursor GAが変えるbot対策と、WEBディレクターが今週確認すべき3点 — 「守る」だけでなく「見分ける」考え方の話。
- 「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった — 日別に割って、正体を見分けた話。
- Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つ — Cloudflareの設定の範囲を、自分の側で確かめた話。
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 確認項目を、公開した日に自分のサイトへ当てた話。
実務のヒント
当サイトの記事「CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）」は、アクセスの記録が手元に残る形かどうかを確かめる記事である。この記事の手順2〜4は、その記録が残っていることを前提にしている。
現在の貴方のIPアドレス
このサイトで書いている人
