WEBサイトCloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）
CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）
目次
01 何が起きたか — CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった
用語
Logpush（ログプッシュ）：Cloudflareが、自社を通ったアクセスの記録（ログ）を、お客様が指定した保存先へ届けてくれる機能。公式文書は、記録を「保存サービス、SIEM、ログ管理の提供元」へ送る機能と説明している。（公式の説明にもとづく）
公式ブログが書いたこと
2026年10月2日、Cloudflareの公式ブログに、Enterprise（企業向けの契約）だけだった機能を、ほかのお客様にも広げる更新の記事（アドレスの名前は「enterprise-for-all-update」）が載った。その中に、アクセスの記録を外へ送るLogpushについて、次の一文がある。
"Previously available only to Enterprise customers, Logpush is now available to Free, Pro, and Business customers through self-service, pay-as-you-go pricing."
（訳: これまでEnterpriseのお客様だけが使えたLogpushは、Free・Pro・Businessのお客様も、自分で申し込む従量課金の料金で使えるようになりました。）
つまり、これまでEnterprise（企業向けの契約）でなければ使えなかった「アクセスの記録を丸ごと手元に送る機能」が、無料や安いプランでも、使った分だけ払う形で使えるようになった。同じブログには、送れるデータの種類も増えているという趣旨の記述がある。
"Datasets available to Logpush have been expanding as well. We've recently added account-scoped firewall events, WebSocket analytics and per-zone post-quantum visibility."
（訳: Logpushで使えるデータの種類も広がっています。最近、アカウント単位のファイアウォールのイベント、WebSocketの分析、ゾーンごとのポスト量子暗号の可視化が加わりました。）
一次情報
素材にした公式ブログ：enterprise-for-all-update（Cloudflare公式ブログ・2026年10月2日）。英文の引用は、2026年10月3日に開いたページから写した。使うときは原文のページで確かめてほしい。
この記事が書いていないことを先に決めておく
取得した範囲では、ブログに「提供の開始日」や「Free・Pro・Businessで使えるデータの範囲」の詳しい説明は無かった。料金の細かい数字は公式の料金ページにあり、データの項目は開発者向けの文書にある。この記事は、その2つのページを開いて、書かれていたことだけを後の章に並べる。書かれていないことは、書かれていなかったと書く。
そもそも、何を確かめる記事なのか
この記事の軸は、Cloudflareの機能の紹介ではない。自社のサイトの「アクセスの記録」が、どこに、何日分、どんな中身で残っているかを、読んだ人が自分で確かめる手順である。Cloudflareを使っているサイトも、使っていないサイトも対象にしている。使っていないサイトでは、サーバーのアクセスログが同じ役目を持つ。05章に13項目のチェックリストを置いた。
02 なぜ・背景 — ログは、取り始めた日からしか残らない
公式文書が書いている、Logpushの性質
Logpushの概要ページには、仕組みの性質を示す文が2つある。1つは、記録を届ける速さについての文である。
"Logpush delivers logs in batches as quickly as possible, with no minimum batch size, potentially delivering files more than once per minute."
（訳: Logpushは、記録をできるだけ早くまとめて届けます。最小のまとまりの大きさは決まっておらず、1分に1回を超えて、ファイルを届けることもあります。）
もう1つは、さかのぼれないことについての文である。
"only pushes logs once as they become available and cannot backfill historical data."
（訳: 記録は、使える状態になった時に1回だけ届けられ、過去のデータをさかのぼって補うことはできません。）
後者が、実務で大事な点である。Logpushを設定した日より前の記録は、後から取り寄せられない。使えるようになったと知った日に設定しないと、その日までの記録は、手元に残らない。
「後で見よう」は、見る材料が無い状態を作る
サーバーのアクセスログでも、事情は似ている。ログの置き場所と、ファイルを入れ替える（回転させる）設定によって、何日分が残るかが決まる。古いものから消える設定なら、見たいと思った日には、もう無い。
当サイトでも、これで困ったことがある。AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていたでは、記録を数える範囲で結果が大きく変わった。『0件には三つの顔がある』と書いた記事が、三つ目の顔を踏んでいた ── サイトへのアクセスの94%を、52日間 見ていなかったも、数える範囲の話である。どちらも、記録が残っていたから、後から数え直せた。残っていなければ、数え直す材料がなかった。
今回の変更が、Cloudflareを使うサイトに意味すること
Cloudflareを使っているサイトは、これまで、自分のサイトのアクセスの記録を、Cloudflareの外へ丸ごと持ち出す手段に制限があった。使えるのはEnterpriseの契約だけだったためである。契約を変えずに、記録を持ち出す道が1本増えた、というのが今回の変更の意味である。ただし、使うかどうかは別の話で、使うなら、送り先と量と費用を決める必要がある（04章）。
03 この記事で出てくる用語
アクセスログ
Webサーバーが、受けたリクエストを1行ずつ書き残した記録である。Apacheの公式文書は、こう説明している。
"The server access log records all requests processed by the server."
（訳: サーバーのアクセスログは、サーバーが処理したすべてのリクエストを記録します。）
名乗り（User-Agent）
アクセスしてきたものが、自分は何だと名乗る文字列である。Apacheの公式文書は、これを「クライアントのブラウザが自分について報告する識別の情報」と説明している。ボットの名前も、ここに入る。名乗りは自己申告なので、本物かどうかは別に確かめる必要がある（04章で扱う）。
CDN
サイトの手前に置いて、画像などを近くから配る仕組みである。Cloudflareは、その代表の1つ。CDNを置くと、来訪者のリクエストは、まずCDNに届く。CDNが処理して返したリクエストは、サーバーのログに残らないことがある。サーバーまで届かないからである。
04 型別 — 適用範囲・この記事が確認していないこと・手順
適用範囲 — 使えるプランと、使えない人
Logpushの概要ページの表では、Free・Pro・Business・Enterpriseの4つのプランすべてに「Yes」と書かれていた。2026年10月2日のブログの一文と、向きが合っている。
ただし、使えるのは、サイトの手前にCloudflareを置いている場合だけである。置いていないサイトは、対象外になる。また、Enterpriseの既存の契約については、料金のページに次の注意がある。
"Existing Enterprise contracts retain their current Logpush pricing through renewal"
（訳: 既存のEnterpriseの契約は、更新まで、現在のLogpushの料金を保ちます。）
料金は「含まれる量」と「超えた分」の2段
料金のページに書かれていた数字を、表にまとめた。いずれも、Cloudflareの1アカウントごとの、毎月の量である。
| 対象 | 毎月、含まれる量 | 超えたときの料金 |
|---|---|---|
| 外部の送り先 | 25 GB | 1GBあたり0.10ドル |
| 内部の送り先 | 25 GB | 1GBあたり0.03ドル |
| ログの変換（Transformers） | 1 GB | 1GBあたり0.04ドル |
| Workers向けのLogpush | 1,000万リクエスト | 100万リクエストあたり0.05ドル（Workers Paidプランが必要） |
料金のページは、内部と外部の区別も書いている。「R2 and Pipelines are internal destinations. All other destinations are external.」（訳: R2とPipelinesは内部の送り先です。ほかの送り先はすべて外部です。）である。送り先を外部のサービスにするか、Cloudflare内部にするかで、超えたときの1GBあたりの料金が約3倍違う。
送り先の保存サービスの料金は別
もう1つ、見落としやすい一文がある。
"does not include charges from destination services."
（訳: 送り先のサービスの料金は含まれません。）
Logpushの料金は、記録を届ける分である。届けた先で記録を置いておく料金（保存の料金）は、別に、送り先のサービスに払う。「Logpushが安い」と「記録を持てる全体が安い」は別の話である。
送り先として挙げられていたもの
送り先の文書には、Cloudflare R2、Amazon S3、Datadog、Elastic、Google Cloud Storage、Google BigQuery、Microsoft Azure、Splunkなど、十数種類が並び、最後に「Other providers」（訳: そのほかの提供元）もあった。自社で保存サービスを持っていないなら、まず「どこに置くか」を決めるのが先である。この文書のページには、送り先ごとのプランの制限は書かれていなかった。
量の見積もりは、公式の目安から出せる
HTTPのリクエストの記録について、公式文書は量の目安を書いている。
"~100–250 bytes per request (compressed)"
（訳: 1リクエストあたり、圧縮後でおよそ100〜250バイト。）
ただし、この目安は「圧縮後」の大きさである。料金のページ（最終更新2026年10月2日）は、課金の数え方を次のように書いている。
"Cloudflare measures export usage from uncompressed bytes successfully delivered."
（訳: Cloudflareは、正常に届けられた、圧縮前のバイト数で、送り先への出力の使用量を数えます。）
つまり、含まれる25GBは、圧縮前の大きさで数えられる。圧縮後の100〜250バイトで25GBを割ると、実際より多い量が含まれているように見えてしまう。同じ概要のページ（最終更新2026年9月30日）には、「1M req/day → ~250–500 MB/day」（訳: 1日100万リクエストで、1日あたりおよそ250〜500MB）という、別の表もある。この表の数字が圧縮前か圧縮後かは、ページには書かれていない。圧縮前の1リクエストあたりのバイト数を、公式が数字で書いている箇所は、この記事では見つけられなかった。
そこで、この記事では、表の「1日100万リクエストで250〜500MB」を、1リクエストあたり250〜500バイトとして使う（筆者の割り戻し）。25GBを30日で割ると、1日あたり約830MBである。1リクエスト250〜500バイトなら、1日におよそ170万〜330万リクエストになる（1GBを1,000MBとした場合の筆者の計算）。圧縮後の100〜250バイトで計算すると330万〜830万リクエストになるので、圧縮前で数える課金に合わせると、含まれる25GBに相当するリクエストの数は、およそ半分から5分の2になる。実際の量は、記録に入れる項目の数で変わる。公式は、正確な見積もりが要るなら、Logpullで1時間分を取って測れると書いている。
1つのゾーンに作れるジョブの上限
ジョブとは、「どのデータを、どこへ送るか」という1つの設定のことである。概要ページには、その上限も書かれている。「There is currently a max limit of 4 Logpush jobs per zone.」（訳: 現在、1ゾーンあたり、Logpushのジョブは最大4つまでです。）である。1つのドメインに対して、送り先を最大4つまで分けられる。
記録に入る項目は、HTTPのリクエストなら多い
HTTPのリクエストのデータセットの文書には、項目の一覧がある。次の表は、このうち、サイト運営で使いやすいものを抜き出した。
| 項目名 | 公式の説明（訳） |
|---|---|
| ClientIP | クライアントのIPアドレス |
| ClientRequestUserAgent | クライアントが報告したUser-Agent（名乗り） |
| ClientRequestURI | クライアントが要求したURI。パスと、?以降のクエリを含む |
| ClientRequestPath | クライアントが要求したURIのパスの部分だけ |
| EdgeStartTimestamp | エッジ（CloudflareのCDN側）がリクエストを受けた日時 |
| EdgeResponseStatus | Cloudflareがクライアントに返したHTTPの応答の番号 |
| ClientCountry | クライアントのIPアドレスの国（2文字のコード） |
| VerifiedBotCategory | 確認済みのボットの種類 |
| BotScore | Cloudflareのボットのスコア。30未満は、自動のアクセスと結びつくことが多い。Bot Managementの契約者だけが使える |
最後の行のとおり、項目によっては、別の契約（Bot Management）が必要だと書かれている。Free・Pro・Businessで、どの項目が実際に出るかは、取得した範囲では書かれていなかった。送る前に、自分の画面で確かめる項目になる。
この記事が確認していないこと
- Logpushのジョブを、実際に設定して、記録が届くところまでは試していない。2026年10月3日に開いた当サイトの応答に、Cloudflareの印が無かったため（07章）。
- 設定画面の操作の順番は、取得できた文書に書かれていなかった。画面の名前や手順は、公式のページで確かめる必要がある。
- Free・Pro・Businessで、HTTPのリクエストの記録のどの項目が出るかは、確かめていない。
手順 — 名乗りで数えるときの確かめ方
記録が手に入ると、名乗りの名前ごとに数えたくなる。OpenAIの公式文書（Overview of OpenAI Crawlers）は、名乗りを4つ挙げている。OAI-SearchBot・OAI-AdsBot・GPTBot・ChatGPT-Userである。OAI-AdsBotは、ChatGPTの広告として出された、リンク先のページの安全を確かめるためのものと書かれている。ここでは、サイトの運営者が通常 数える対象として、検索・学習・利用者の依頼の3つを取り上げる。
"OAI-SearchBot is used to surface websites in search results in ChatGPT's search features."
（訳: OAI-SearchBotは、ChatGPTの検索機能の結果にサイトを表示するために使われます。）
"GPTBot is used to make our generative AI foundation models more useful and safe."
（訳: GPTBotは、生成AIの基盤モデルをより有用で安全にするために使われます。）
"When users ask ChatGPT or a CustomGPT a question, it may visit a web page with a ChatGPT-User agent."
（訳: ユーザーがChatGPTやカスタムGPTに質問したとき、ChatGPT-Userという名乗りでウェブページを訪れることがあります。）
名乗りは役目が違うので、名乗りごとに別々に数えると、意味のある内訳になる。この3つの名前の通し方は、当サイトのAIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける（2026年9月時点）で整理した。
名乗りは自己申告 — 本物かどうかは、送信元で確かめる
名乗りは、アクセスしてきた側が自分で書く文字列である。Googleの公式文書は、確認の手順を書いている背景を、次のように述べている。
"This is useful if you're concerned that spammers or other troublemakers are accessing your site while claiming to be from Google."
（訳: これは、スパム業者などが、Googleを名乗ってサイトにアクセスしていないかが心配な場合に役立ちます。）
確認の方法は2つ書かれている。1つは、記録に残ったIPアドレスの逆引きをして、名前が正しいドメインかを確かめる方法。もう1つは、Googleが公開しているIPアドレスの範囲の一覧と照らす方法である。つまり、名乗りの件数は「その名前を名乗った件数」であり、「本物が来た件数」ではない。件数を報告に書くときは、どちらを数えたかを書く。
IPアドレスなどを、どう扱うか
Logpushで送れる記録には、ClientIPの項目がある。Apacheの標準的なログの形式でも、先頭にアクセス元のアドレスが入る。記録をCDNの外へ持ち出すと、アクセス元のアドレスを含むデータが、もう1か所に増える。送り先の保存サービスが海外か国内か、誰が見られるか、何日で消えるかを、決める必要がある。
Cloudflareの同じブログは、記録を送る前に加工する機能Transformersも、全員が使えるようになると書いている。
"customers can use SQL to filter unnecessary records, redact sensitive information, enrich events, and reformat logs before delivery"
（訳: SQLで不要な記録を除き、機微な情報を伏せ、イベントに情報を足し、届ける前にログの形を整えられます。）
伏せる機能が使えるということである。ただし、これも「ログの変換」の料金の対象で、含まれる量は1GBである。自社のプライバシーポリシーに、アクセスの記録を取ることと、その保存期間が書かれているかを、05章の項目13で確かめる。
05 明日、自社サイトで確認できることチェックリスト
まず13項目を通して見る
以下は、明日、自社の契約の画面と、サーバーのログだけで、アクセスの記録が手元に残る形になっているかを確かめるための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜4番目がCDNとLogpushを確かめる作業、5〜8番目が費用と量を見積もる作業、9〜13番目がサーバーの記録と扱いを確かめる作業である。CDNを使っていない場合は、1〜8番目を「該当なし」として飛ばし、9番目から始めてよい。
実務のヒント
サーバーのログの解析は、当サイトの🔧 iLogScannerを使ったログ分析ツールが使える（会員登録とログインが要る）。ログの形が分からないときの、最初の1回に向いている。
- 契約書か管理画面で、サイトの手前にCDN（Cloudflareなど）を置いているかを確認して、置いている場合は名前を書き留める
- Cloudflareを使っている場合は、管理画面で、契約しているプラン名（Free・Pro・Businessなど）を1つ書き留める
- 管理画面のログに関する項目を開き、Logpushのジョブがすでにあるかを確認して、あれば件数と送り先を書き留める
- Logpushのジョブがなければ、「いま、CDNを通ったアクセスの記録を、サイトの運営側では持っていない」と1行書く
- 公式の料金ページを開き、毎月含まれる量（25GB・1GB）と、超えたときの1GBあたりの料金を、メモに書き写す
- 直近7日のうち1日分で、サイトの1日のリクエスト数を、サーバーのログの行数か管理画面の数字で数えて書く
- 6番目の数に、1リクエストあたり250〜500バイト（公式の概要ページの表「1日100万リクエストで250〜500MB」から割り戻した目安）を掛けて、1日と1か月（30日）の量を、MBかGBで書く
- 7番目の1か月の量を、毎月含まれる25GB（課金は圧縮前のバイトで数える）と比べて、「超える」「超えない」のどちらかを書く。ぎりぎりの場合は、Logpullで1時間分を取って測り直す
- サーバーのアクセスログが置かれている場所を、サーバーの管理画面か担当者に聞いて、1か所書き留める
- ログのファイルを開き、いちばん古い日付と最新の日付を書いて、何日分残っているかを数える
- ログの1行を開き、日時・要求したURL・応答の番号・名乗りの4つが入っているかを、1つずつ確認する
- 直近1日分のログで、GPTBot・OAI-SearchBot・ChatGPT-Userの3つの名前が入る行を、名前ごとに数える
- プライバシーポリシーのページを開き、アクセスの記録を取ることと保存期間が書かれているかを、1ページ分読んで確認する
かかる時間の目安
すべてに目を通す時間は、あわせて1時間（60分）ほどである（筆者の見積もりで、権限や記録の大きさによって変わる）。内訳は、1〜4番目が15分、5〜8番目が20分、9〜10番目が10分、11〜12番目が10分、13番目が5分である。CDNを使っていないサイトは、9〜13番目だけで、25分ほどになる。
5分で終わらない項目があったとき
ログのファイルが大きくて、開けない場合は、ファイルの名前と更新日時を見るだけで、項目10は足りる。名前に日付が入っている形なら、並べるだけで残っている日数が分かる。項目12も、大きなファイルは、1日分だけで十分である。
06 代替・他の選択肢（表で）
アクセスの記録を手元に持つ手段は、Logpushだけではない
Logpushは、記録を丸ごと外へ送る手段である。それ以外にも、Cloudflareの文書は、見る方法を何種類か挙げている。サーバー側のアクセスログや、Googleの統計も合わせて、見られることと、見られないことを表にまとめた。特定の製品の優劣ではなく、種類ごとの整理である。
それぞれの手段が「見られないこと」も知っておく
| 手段 | 見られること | 見られないこと |
|---|---|---|
| Logpush | リクエストの記録を、保存先へまとめて届ける。送り先は、保存サービス・SIEM・ログ管理の提供元など | 設定する前の記録（さかのぼれない）。保存先の料金は含まれない |
| Instant Logs | HTTPのリクエストの記録を、管理画面かコマンドですぐ見られる | 保存の期間は、取得した範囲では書かれていなかった |
| Logpull（旧式） | HTTPの通信で、記録を取り出すためのAPI。文書には「legacy」（訳: 旧式）と書かれている | 新しく使い始めるかどうかは、文書の位置づけを確かめてから決める |
| Log Explorer | Cloudflareの記録を、管理画面かAPIの中で保存して調べられる | 使える契約と料金は、この記事では確かめていない |
| サーバーのアクセスログ | サーバーが処理したすべてのリクエスト。名乗り・URL・応答の番号など | CDNが処理して、サーバーまで届かなかった分。名乗りが本物かどうか |
| Search Consoleのクロール統計 | Googleのクロールの履歴（回数・応答・利用できなかった問題） | Google以外のボットの動き。ルートレベルのプロパティでしか使えない |
いちばん確実なのは、サーバーのログを、自分の手元で期限なく残る形にしたうえで、CDNの記録を足す順番である。CDNだけを残しても、CDNに届かなかった直接のアクセスは入らない。サーバーのログだけを残しても、CDNが返した分は入らない。
Search Consoleのクロール統計は、ログの代わりにならない
Googleの公式のヘルプは、クロール統計を「statistics about Google's crawling history on your website」（訳: サイトに対するGoogleのクロールの履歴の統計）と説明している。同じページには、使える条件も書かれている。
"This report is available only for root-level properties."
（訳: このレポートは、ルートレベルのプロパティでのみ使えます。）
Googleのクロールの全体像を、自分のログで確かめたいときの、突き合わせの相手として使うのがよい。見方は、当サイトのSearch Console クロールの統計情報レポート ── 90日分のGooglebotの動きから読める8指標を確認する14項目（2026年9月時点）で整理した。
Clarityなどの解析ツールは、CDNのログを元にしている
ボットの動きを画面で見られる解析ツールの中には、元データがCDNのログの機能から来るものがある。当サイトのClarityのBot Activityに「ページ分類」が入ったが、元データはCDNのログで接続が要る ── 自社のURLを種類分けして、ボットの多い種類を確認する13項目（2026年10月時点）で書いた。
Microsoftの費用の文書は、Cloudflareについて、次のように書いている。日付欄は2026年5月11日付だった。
"LogPush is typically available on paid plans and might have usage-based pricing."
（訳: Logpushは通常、有料プランで使え、使った量に応じた料金になることがあります。）
2026年10月2日のCloudflareのブログは、Free・Pro・Businessでも従量課金で使えると書いている。2つの文書の食い違いは、文書の日付が違うためかもしれないが、理由は確かめていない。料金やプランの条件は、使う日に、提供元の最新のページで確かめるのが確実である。
07 当サイトで数えてみた結果
数えた範囲と方法
当サイト（WEBサイトサポート）で、2026年10月3日に、2つを確かめた。1つ目は、サイトの手前にCloudflareを置いているか。公開のページの応答のヘッダーを開いて、Cloudflareの印があるかを見た。2つ目は、サーバーのアクセスログが、何日分、何行残っているか。ファイルの数と行数を数えた。
Cloudflareの印は、見つからなかった
応答のヘッダーには、Cloudflareを通ったことを示す印は無かった。サーバーの種類を示す項目はApacheだった。つまり、今日の応答を見る限り、当サイトは今回のLogpushの変更の、対象になる使い方をしていない。05章の1〜8番目は、当サイトでは「該当なし」になる。ヘッダーだけで言えるのは「今日、そのページの応答にCloudflareの印は無かった」までである。
なお、当サイトの過去の記事には、Verified AI Agent 37体を個別allowした実装ログ ── 警告した側の次の責任を、当サイトで完結させた日（2026年6月30日公開）がある。その記事は、当サイトのCloudflareの設定に、AIの名乗りを個別に許可するルールを入れる手順を書いている。つまり、当サイトは、少なくとも過去に、Cloudflareの設定を持つ時期があった。今日の応答に印が無いことと、この記事は両方とも事実として書いている。いつ・なぜ外れたかは、この記事では確かめていない。
サーバーのログは、52日分が残っていた
暗号化通信（https）のアクセスの記録の控えは、1日につき1ファイルで、全部で52ファイルあった。ファイル名の日付は、2026年8月13日から10月3日までである。52ファイルの行数の合計は231,739行で、1ファイルあたり約4,460行だった。
1行に、名乗りまで入っていた
ログの最新の1行を開いて、項目を確かめた。送信元のIPアドレス、日時、要求したURL、応答の番号、参照元、名乗りの6つが入っていた。Apacheの文書の、Combined Log Format（訳: 複合ログ形式）に近い形である。名乗りが入っているので、05章の項目12の、3つの名前ごとに数える作業はできる形になっている。
もし、Logpushで送るなら、量はどのくらいか
仮にの話として、当サイトの1日あたり約4,460行を、割り戻した目安（1リクエストあたり250〜500バイト）に当てはめると、1日に約1.1〜2.2MBになる。30日で、約33〜67MBである。毎月含まれる25GBに、大きく余裕がある。圧縮後の目安（100〜250バイト）で出した最初の概算（約13〜33MB）より増えたが、25GBに対して余裕があるという結論は変わらない。ただし、これはサーバーのログの行数を、CDNのリクエストの数の代わりに使った、筆者の概算である。実際にCloudflareを通すと、画像などの配信の分も数えられるので、数は増える。
この数え方の限界
数えたのは、サーバーに残っているログのファイルの数と行数である。サーバーの外に控えがあるかどうかは、この数え方では分からない。また、保存の期間を定めているかどうかや、プライバシーポリシーの記載との照合（項目13）は、この記事では数えていない。いちばん古い日付が8月13日だったことは、それより前の記録が、いまのサーバーには残っていないという意味である。
08 このテーマの、これまで
Cloudflareのログの機能が、公式文書でどう書かれているか
Cloudflareのログの文書は、3つの機能を並べている。Logpush（記録を保存先へ届ける）、Instant Logs（HTTPのリクエストの記録を管理画面やコマンドで即座に見る）、Logpull（旧式のAPI）である。別に、Log Explorer（記録を管理画面やAPIの中で保存して調べる）にも触れている。
当サイトの過去の記事 — ログを読む話
当サイトには、アクセスログを読んだ記事がいくつかある。AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていたは、数える対象を取り違えた話である。「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直したは、探した数を書く話である。「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提も、記録を開いて前提を確かめた話だった。
CloudflareのAIボットの設定については、Cloudflareが「検証」の定義を変えた日 — Search/Agent/Training 三分類の刷新と、37体allowの次の一手と、「守る」から「見分ける」へ ── Cloudflare Precursor GAが変えるbot対策と、WEBディレクターが今週確認すべき3点がある。設定を決める前に、来訪の記録を持つという順番は、これらの記事とも合う。
注意
この記事の料金の数字は、公式の料金ページを2026年10月3日に開いて写したものである。ドル建てで、為替によって円の額は変わる。また、Logpushを有効にする前に、送り先の保存サービスの料金と、保存期間を決めておく。決めずに有効にすると、記録が増え続けて、請求が想定より大きくなることがある。
現在の貴方のIPアドレス
このサイトで書いている人
