WEBサイトCloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）
Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）
目次
01 何が起きたか — Cloudflareの分析データが、すべてのプランで最低30日分になった
2026年10月2日に公開された変更履歴
Cloudflareの開発者向けの変更履歴に、「30 days of analytics data on every plan」（訳: すべてのプランで30日分の分析データ）という投稿が、2026年10月2日の日付で載っている。2026年10月5日に、この投稿と、そこからリンクされている公式ページを開いて読んだ。投稿の最初の1文は、次のとおりである。
"Every plan now gets at least 30 days of analytics data."
（訳: すべてのプランで、少なくとも30日分の分析データが得られるようになった。）
続く文には、対象のデータと日数が、もう少し細かく書かれている。
"Adaptive analytics datasets, such as HTTP requests, security events, and DNS analytics, retain at least 31 days of data for Free and Pro domains, and you can query up to 30 days in a single request."
（訳: HTTPリクエスト、セキュリティイベント、DNSの分析のような適応型の分析データセットは、FreeとProのドメインで少なくとも31日分のデータを保持し、1回のリクエストで最大30日分を問い合わせられる。）
変更の前は、24時間から8日だった
変更の前の状態も、同じ投稿に書かれている。
"Previously, Free and Pro domains could see between 24 hours and 8 days of history depending on the dataset."
（訳: 以前は、FreeとProのドメインで見られる履歴は、データセットによって24時間から8日の間だった。）
つまり、無料や低価格のプランでは、先週の同じ曜日すら見られないデータセットがあったことになる。1週間は7日なので、8日分の履歴があっても、今日と「ちょうど1週間前」を並べるのがぎりぎりで、2週間前とは比べられない。それが、最低30日分になった。
数字が2つある — 保持は31日、1回の問い合わせは30日
投稿を読むときに、見落としやすい点がある。データが残る日数は「少なくとも31日」で、1回の問い合わせで取れる幅は「最大30日」と、別々の数字で書かれている。見出しの「30 days」は、問い合わせの幅のほうに近い。31日分のすべてを1回で取ることはできず、問い合わせを2回に分ける必要がある。この記事の手順では、「31日より前は、画面からは遡れない」と考えて、残す数字を決める。
変わったことと、変わらないこと
変更履歴に書かれた内容を、変わったことと、変わらないことに分けると、次のようになる。
- 対象：すべてのプラン。FreeとProの適応型のデータセットは、少なくとも31日分を保持し、1回の問い合わせは最大30日分である。
- 反映される場所：ダッシュボード、Custom Dashboards、GraphQL Analytics API。
- 変わらないこと：プランごとに使えるデータセットとフィールドは、変わらない。
- 従来のままのもの：httpRequests1hGroupsのような集計型のデータセットは、プランごとの上限のままである。
02 なぜ・背景 — 公式が挙げている使い道は、「後から調べる」「同じ曜日と比べる」「山の形を見る」
公式が挙げている3つの使い道
変更履歴は、30日分の履歴で何ができるようになるかを、次のように書いている。
"A full month of history lets you investigate an issue after it happens, compare today with the same day in previous weeks, and tell a one-time spike from a longer trend."
（訳: 丸1か月分の履歴があると、問題が起きたあとに調べることができ、今日を前の週の同じ日と比べることができ、一度きりの急増と、長く続く傾向を見分けられる。）
3つの使い道を、サイトの運営の場面に置き換えると、次のようになる。
- 後から調べる：障害や表示の不具合に気づいたのが、起きた翌日以降でも、その日の通信の数や状態を見られる。
- 同じ曜日と比べる：月曜日の数字は、前の月曜日と比べて初めて、多いのか普通なのかが分かる。曜日によって訪問の量が違うサイトでは、昨日との比較より役に立つ。
- 山の形を見る：1日だけ高い数字なのか、数日かけて上がっているのかは、30日分を1つのグラフにすると見分けやすい。
分析の画面が、ドメインごとに1か所になった
同じ投稿は、画面の構成の変更にも触れている。ダッシュボードでドメインを選んで「Analytics」を開くと、Traffic・Performance・Security・Cache・Origin・DNS・Visitorsの7つがタブとして並び、1つの期間と1組のフィルターを共有すると書かれている。アカウント全体の分析は、「Observability」の下の「Analytics」にある、とのことである。
タブごとに期間を指定し直さなくてよいので、「障害の日の前後30日」を決めてから、Trafficでリクエスト数を見て、Securityで増えたものを見て、Originでサーバー側の状態を見る、という順に調べやすくなる。ただし、7つのタブがすべて30日分を出すのかは、確かめた範囲の文書には書かれていない。手順2で、自分の画面で数える。
「30日」は、画面やデータセットによって違う
ここで注意したいのは、公式文書の中の数字が、画面ごとに少しずつ違うことである。たとえば、DNSの分析のページは、ゾーン（ドメイン）単位の1回の問い合わせの幅を、Freeで30日、ProとBusinessで31日、Enterpriseで62日と書いている。同じページに、アカウント単位の履歴は、FreeからBusinessまでが8日と書かれている。見出しの「すべてのプランで最低30日」だけを覚えると、アカウント単位の画面で、8日しか遡れないことに驚く場面が出てくる。画面ごとの数字は、04章の表にまとめた。
保持の外側にあるデータは、取り戻せない
公式の文書が、別の面から同じ注意を書いている。ログを外部に送る仕組みのLogpushのページには、次の文がある。
"Logpush only pushes logs once as they become available and cannot backfill historical data."
（訳: Logpushは、ログが利用できるようになった時点で1回だけ送り、過去のデータをさかのぼって送ることはできない。）
このページは、さらに、ジョブが止まっていた間のログは完全に失われる、とも書いている。分析の画面の履歴も、考え方は同じで、画面から消えたあとの数字を、あとから取り出す方法は、確かめた範囲の文書には書かれていない。「あとで見られる」ことは、記録を始めた日からしか成り立たない。この記事の軸は、そこにある。
03 用語 — 「保持」と「問い合わせの幅」を分けて読む
保持期間と、問い合わせの幅
用語
保持期間：データが画面やAPIから取り出せる状態で残っている日数である。問い合わせの幅：1回の問い合わせで指定できる、期間の長さである。公式のページは、この2つを別の行に分けて書いている（たとえばSecurity Analyticsのページには「Historical time (data retention)」と「Max query window」の2行がある）。保持が31日でも、1回で取れる幅が30日なら、31日分を見るには、問い合わせを分ける必要がある。
適応型と、集計型のデータセット
用語
適応型のデータセット：名前にAdaptiveが付くデータセットである（httpRequestsAdaptiveGroupsやfirewallEventsAdaptiveなど）。公式のSamplingのページは、これらは、データの量に応じて、抜き出す割合が変わる方式（adaptive sampling）で作られていて、件数が少なければ抜き出さず、増えるほど低い割合で抜き出すと書いている。集計型のデータセット：変更履歴が、適応型と並べて、httpRequests1hGroupsを例に挙げているものである。今回の30日は適応型の話で、集計型は従来のプランごとの上限のままと書かれている。
GraphQL Analytics API
用語
GraphQL Analytics API：Cloudflareの分析データを、プログラムから取り出すための窓口である。公式のページは、1つの宛先に、取りたいデータセットと指標を指定した問い合わせを送る形だと書いている。ダッシュボードの分析も、このAPIが支えていると書かれている。
Custom Dashboards
用語
Custom Dashboards：自分で選んだ指標を並べた、自分用のダッシュボードである。公式のページは、すべてのCloudflareの利用者が使えて、1つのアカウントで最大100枚まで作れると書いている。今回の変更は、この画面にも反映されると、変更履歴に書かれている。
サンプリング（一部だけを数える）
Security Eventsのページの表には、Freeの「ダッシュボードの機能」の欄に「Sampled logs only」（訳: サンプリングされたログのみ）と書かれている。サンプリングは、全部ではなく一部を抜き出して数える方法を指す一般的な言葉である。FreeのSecurity Eventsは、保持の日数が31日でも、見えているのは一部のログという読み方になる。日数と、中身の量は、別の話である。
04 型別 — 自分のサイトがどれに当たり、何を、どの順で確かめるか
🅰 適用範囲 — Cloudflareにドメインを載せているサイトが対象になる
この変更の対象は、Cloudflareにドメインを載せて、その分析画面を使っているサイトである。変更履歴は「すべてのプラン」と書いている。FreeとProの履歴が延びたことは明記されているが、BusinessとEnterpriseで、この投稿のために保持が変わったのかは、書かれていない。各プランの現在の数字は、画面ごとの公式のページに、次のように載っている（いずれも2026年10月2日更新のページ）。
| 画面・データ | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Security Analyticsの保持 | 最長31日 | 最長31日 | 最長31日 | 最長90日 |
| Security Analyticsの問い合わせの幅 | 30日 | 30日 | 31日 | 31日 |
| Security Eventsの保持 | 最長31日 | 最長31日 | 最長31日 | 最長31日 |
| Security Eventsの問い合わせの幅 | 30日 | 30日 | 30日 | 31日 |
| DNSの履歴（ゾーン単位） | 31日 | 31日 | 31日 | 62日 |
| DNSの問い合わせの幅（ゾーン単位） | 30日 | 31日 | 31日 | 62日 |
| DNSの履歴（アカウント単位） | 8日 | 8日 | 8日 | 62日 |
この表から言えるのは、Freeでも、ゾーン単位の画面なら31日前までが見えることと、アカウント単位のDNSの履歴は、FreeからBusinessまでが8日であることである。Security Analyticsのアカウント単位の画面は、公式のページによれば、BusinessとEnterpriseの利用者だけが使える。
Cloudflareにドメインを載せていないサイトには、この変更は関係しない。ただし、考え方は、ほかの分析ツールにもそのまま使える。「どの数字が、何日前まで見られるか」を知らないまま、数字を見ていることは、どの環境でも起こりうる。
🅱 公式文書が書いていないこと
次のことは、確かめた範囲の公式文書には書かれていない。この記事も、断定しない。
- 変更の前に溜まっていたデータが、すぐに30日分さかのぼれるのか、それとも2026年10月2日から30日かけて溜まっていくのか。
- BusinessとEnterpriseの保持の日数が、この変更で延びたのかどうか。
- Web Analytics（ページの表示の分析）の保持の日数。
- 31日より前の数字を、画面やAPIから取り出す方法。Logpushのページは、ログのさかのぼりの送信はできないと書いている。
この記事が確かめていないこと
筆者はCloudflareのアカウントの分析画面を、この記事のために開いていない。当サイトのドメインを、Cloudflareに載せていないためである。画面のボタンの位置や、各タブに実際に何日分が出るかは、読者が自分の画面で確かめる必要がある。GraphQLの問い合わせの例も、公式のページから引いたもので、この記事のために実行してはいない。
🅲 手順1 — 画面の期間を最大に広げて、いちばん古い日付を見る
最初に、自分のドメインの分析の画面（ダッシュボードでドメインを選んで「Analytics」を開く）で、期間を長いほうに広げる。グラフの左端の日付が、今日から何日前なのかを数えて、メモに書く。画面が実際に見せる日数を、自分の目で確かめる作業である。公式の文書の数字と、画面の数字がずれていたら、そのずれ自体を、記録しておく。
🅲 手順2 — 7つのタブで、30日分が出るかを順に見る
同じ期間のまま、Traffic・Performance・Security・Cache・Origin・DNS・Visitorsの7つのタブを順に開く。各タブで、グラフの左端が手順1と同じ日付まで届いているかを見て、届いているタブの数を数える。7つのうち、短いタブがあれば、そのタブの名前と、見えた日数を書く。
🅲 手順3 — 同じ曜日で比べる
Trafficのタブで、今日と同じ曜日の数字を、4週間前までさかのぼって並べる。たとえば今日が月曜日なら、1週間前、2週間前、3週間前、4週間前の月曜日の、リクエストの数である。今日の数字を、この4日の平均で割って、今日が普通の何倍かを書く。数字が大きく外れていれば、その日付に何があったかを、社内の作業の記録と照らして確かめる。
🅲 手順4 — GraphQLのsettingsで、データセットごとの日数を読む
公式のページは、データセットごとの上限を知る方法として、GraphQLの「settings」を挙げている。ゾーンやアカウントの下のsettingsに、データセットがフィールドとして並び、それぞれに、使えるかどうかを示すenabled、どれだけ前まで読めるかを秒で示すnotOlderThan、1回に指定できる期間の長さを秒で示すmaxDurationなどがある、と説明している。公式のページの例は、次の問い合わせである。
query SampleQuery($zoneTag: string) {
viewer {
zones(filter: { zoneTag: $zoneTag }) {
settings {
firewallEventsAdaptive {
enabled
maxDuration
maxNumberOfFields
maxPageSize
notOlderThan
}
}
}
}
}返ってくる数字は秒なので、86,400で割ると日数になる。公式のページのサンプルの出力には、notOlderThanが2678400（31日）、maxDurationが259200（3日）と書かれている。ただし、このページの最終更新は2026年4月23日で、10月2日の変更を反映した値とは限らない。自分のゾーンで、実際に返る値を見るのが確実である。変更履歴も、正確な保持と問い合わせの幅を知るには、データセットごとのsettingsを問い合わせるよう書いている。
🅲 手順5 — 残す数字と、記録の頻度を決める
保持が31日なら、31日が過ぎる前に、数字を自分の側に写す必要がある。写す数字を、7つのタブから1つずつ選ぶ。たとえば、Trafficならリクエストの数、Cacheなら配信の状態、Originならサーバーの応答の遅さである。1つのタブにつき1つで足りる。数字が多いと、続かない。
記録の頻度は、週に1回にする。保持が31日あれば、週に1回の記録なら、抜けても次の週に補える。曜日を決めておくと、先月の同じ曜日の記録が、必ず手元にある状態を作れる。記録の置き場所は、担当者が替わっても見つかる場所にする。
🅲 手順6 — 障害や急増の日の扱いを決める
障害や急増に気づいた日は、記録を週1回に任せず、その日のうちに、その日付の数字を書き写すことにしておく。31日が過ぎると、画面からは調べられなくなるためである。誰が、どの画面の、どの数字を写すかを、あらかじめ1人に決めておく。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜3が手順1と2、項目4と5が手順3、項目6と7が手順4、項目8〜11が手順5と6、項目12と13が自社のサーバーの記録に対応している。Cloudflareを使っていないサイトの人は、項目12と13から始めればよい。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- Cloudflareのダッシュボードでドメインを選んでAnalyticsを開き、期間を最大に広げて、グラフの左端の日付と、今日から何日前かを書く
- Traffic・Performance・Security・Cache・Origin・DNS・Visitorsの7つのタブを順に開き、左端が項目1と同じ日付まで届いたタブの数を数えて書く
- 7つのタブのうち、届かなかったタブの名前と、そのタブで見えた日数を書き、届かなかったタブがなければ「なし」と書く
- Trafficのタブで、今日と同じ曜日の、1週間前から4週間前までの4日分のリクエストの数を、日付つきで書き並べる
- 項目4の5つの数字で、今日の数字を、4日分の平均で割った倍率を、小数第1位まで書く
- GraphQL Analytics APIを使える担当者に頼んで、firewallEventsAdaptiveのsettingsからnotOlderThanとmaxDurationを取り出し、86,400で割った日数を書く
- 同じ方法で、httpRequestsAdaptiveGroupsとhttpRequests1hGroupsのnotOlderThanを取り出し、2つの日数の差を書く
- 7つのタブから1つずつ、残す数字を選び、数字の名前と、見る画面の名前を、表に7行で書く
- 残す数字を写す曜日を1つ決め、毎週その曜日に、日付つきで7つの数字を1行ずつ記録する作業を、カレンダーに登録する
- 記録の置き場所になるファイルの名前と場所を決め、開ける人の名前を、すべて書き出す
- 障害や急増の日に、その日の数字を写す担当者を1人決めて、名前を書く
- 自社のサーバーのアクセスログが何日分残っているかを、サーバーの担当者に聞き、日数を書く
- Cloudflareの画面の保持（31日）と、項目12の日数を並べて、短いほうの日数の半分を、記録を見直す間隔の上限として、日付つきで書く
チェックリストの使い方
時間が限られているときは、項目1・4・8・9の4つだけでも、「画面は何日分見えるのか」「同じ曜日と比べるとどうか」「何を残すか」「いつ残すか」が決まる。Cloudflareのアカウントに触れない立場の人は、項目12だけでも、自社で調べられる範囲の日数が分かる。日数を知らないまま数字を見ることが、いちばん避けたい状態である。
06 代替・他の選択肢 — 記録を残す方法は、画面の数字を写すだけではない
記録を残す方法を、5つに分けて比べる
31日より前の数字を残す方法は、いくつかある。この記事の手順は、いちばん手軽な「手で写す」方法を中心にしたが、ほかの方法と並べて、自社に合うものを選べる。
| 方法 | 何が残るか | 向く場面 | 注意する点 |
|---|---|---|---|
| 画面の数字を写す | 選んだ数字だけ | 担当者が少なく、まず始めたいとき | 写し忘れた週は、抜ける |
| APIで取り出す | データセットごとの数字 | 決まった数字を、毎週同じ形で残したいとき | GraphQLを扱える担当者が要る |
| Custom Dashboards | 見たい指標を並べた画面 | 見る人が複数いるとき | 見せ方を作る機能で、保持を延ばすとは、確かめた範囲の文書に書かれていない |
| Logpush | ログそのもの | 通信の1件ずつを、あとから調べたいとき | 始める前の分は、さかのぼって送られない |
| 自社のサーバーのログ | 自社のサーバーに届いた通信の記録 | Cloudflareを使っていないとき | 保持の日数は、サーバーの設定による |
Logpushと、画面の履歴は、別の話
当サイトの記事「CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）」は、ログを自分の側に送って残す話である。この記事は、画面で見られる履歴の長さの話で、保存のしくみは別になる。Logpushは、始めた日からしか残せないと、公式のページが書いている。画面の履歴が30日になったことは、Logpushを始める理由を弱めるものではなく、始めるまでのつなぎを少し長くしたものと読める。
実務のヒント
始めやすい順に、画面の数字を週1回写す、APIで取り出す、Logpushでログを残すの3段で考える。最初の段で、毎週続くかを確かめてから、次の段に進む。続かない作業の自動化は、自動化しても続かない。
GraphQLの数字は、請求の根拠ではない
APIの数字を使うときの注意も、公式のページに書かれている。
"These datasets should not be used as a measure for usage that Cloudflare uses for billing purposes."
（訳: これらのデータセットを、Cloudflareが請求のために使う利用量の目安として使ってはならない。）
同じページは、請求の対象になる通信にはDDoSの通信などが含まれないが、GraphQLはすべての測れる通信の利用量を示す、と説明している。画面や記録の数字と、請求書の数字が合わなくても、それだけでは異常ではない。
注意
分析の数字は、一部を抜き出した記録（Freeのセキュリティイベントなど）や、抜き出した値から推定した数字（適応型）であることがある。公式のSamplingのページは、サンプルから推定した値を報告する場合があると書いている。記録に残した数字は、「画面の数字」であって、通信の全件ではないと、記録の見出しに書いておく。あとから読む人が、全件の数字と取り違えるためである。
自社のサイトの状態を残すツール
障害の日の、サイトの状態そのものを残したいときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールが使える。公開ページの基本情報を一覧にして、日付とともに保存しておけば、あとから「あの日はこうだった」と見比べる材料になる。サーバーのアクセスログを手元にお持ちなら、🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツールが、ログから攻撃の兆候を探す手がかりになる（ログインが必要なツールである）。どちらも、Cloudflareの分析の代わりではない。
外部のサービスのログと計測の関係は、ClarityのBot Activityに「ページ分類」が入ったが、元データはCDNのログで接続が要る ── 自社のURLを種類分けして、ボットの多い種類を確認する13項目（2026年10月時点）で扱い、Search Consoleの90日分の動きの読み方は、Search Console クロールの統計情報レポート ── 90日分のGooglebotの動きから読める8指標を確認する14項目（2026年9月時点）で扱った。この記事は、それらの内容を繰り返さない。
07 当サイトで確かめたこと
当サイトは、Cloudflareの背後にない
2026年10月5日に、当サイトのホームページの応答ヘッダーを取得した。Cloudflare経由の応答に付くはずの識別の見出し（CF-RAY）は、付いていなかった。ドメインのネームサーバーも、Cloudflareのものではなかった。つまり、今回の変更の対象になる分析画面は、当サイトには無く、この記事の05章の項目1〜11は、当サイトでは実施できない。
そこで、当サイトで確かめられる範囲に絞って、自社のサーバーに、何日分の通信の記録が残っているかを数えた。
当サイトのアクセスの記録は、53日分の日付がある
当サイトのサーバーには、HTTPSの通信の記録が、日ごとに分けて保存されている。2026年10月5日にファイルを数えると、日ごとのファイルが52本と、書き込み中のファイルが1本あり、記録に含まれる日付は、2026年8月14日から10月5日までの53日分だった（10月5日は、確かめた時点で1日が終わっていない）。Cloudflareの画面の保持（31日）より長く、画面の履歴が31日でも、当サイトのサーバーでは、さらに22日前まで遡れる状態にある。ただし、この日数は、サーバーの設定で決まる値で、いつまでも残るものではない。
同じ曜日で比べると、9月30日だけが突き出ていた
この記録で、手順3の「同じ曜日で比べる」を、当サイトにも当てはめてみた。1件の通信につき1行の記録を、日付ごとに数えた。ボットの通信や、当サイト自身の確認作業も含む数字である。水曜日の5日分は、次のとおりだった。
- 9月2日（水）：3,649行
- 9月9日（水）：3,378行
- 9月16日（水）：4,428行
- 9月23日（水）：4,567行
- 9月30日（水）：9,748行
9月2日から23日までの4日の平均は約4,006行で、9月30日はその約2.4倍だった。53日分の中でも、この日の数字が最大である。日付ごとの数字だけを眺めていても、「9月30日は多い」ことは分かる。しかし、同じ曜日の4日分と並べると、「普通の水曜日の2倍を超えている」と言い切れる。曜日ごとの傾向が違うサイトでは、並べ方で、見え方が変わる。
この結果から言えることと、言えないこと
言えるのは、自社のサーバーの記録に、同じ曜日の比較で目立つ日が、実際に1日あったことと、その日が5日前のため、Cloudflareの画面の保持（31日）の範囲なら、今はまだ見られる位置にあることである。言えないのは、9月30日の数字が増えた理由である。ボットの通信か、人の訪問か、自社の作業かは、この記事では調べていない。理由を調べる材料が、まだ手元に残っているうちに、調べるかどうかを決める。それが、保持の日数を知っておく意味である。
08 このテーマの、これまで
分析データの保持をめぐる、日付つきの記録
| 日付 | 出来事 |
|---|---|
| 2026年4月23日 | GraphQL Analytics APIの概要とsettingsのページが、この日付で最終更新（以後、2026年10月5日の確認時点まで同じ日付） |
| 2026年9月30日 | Logpushのページが、この日付で最終更新 |
| 2026年10月2日 | Cloudflareが、すべてのプランで分析データを最低30日分にする変更を、変更履歴に掲載した。同日、Security Analytics・Security Events・DNS・Custom Dashboardsなどのページが更新された |
| 2026年10月5日 | この記事のために、変更履歴と公式ページを開き、当サイトのホームページとサーバーの記録を確かめた |
表の1行目は、公式のsettingsのページのサンプルの値が、変更の前の状態の値である可能性がある理由でもある。ページの更新日が、変更より前のままだからである。
当サイトの、関連する過去の記事
- 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — ログの52日分を、宣言から15日後に初めて開いた記録。
- AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた — HTTPのログだけを見ていて、数字を取り違えた話。
- 外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった — 参照元の数字を、内訳に分けて読み直した記録。
- 「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった — 合計の数字を日別に割って、読み違いを避けた話。
- 「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提 — 数字が0に見えたとき、仕組みが正常かを確かめた記録。
現在の貴方のIPアドレス
このサイトで書いている人
