WEBサイトCloudflareのLogpushでは、ログを書き出す前にSQLで行を落とし、項目を伏せられるようになった。ただし費用は落とす割合しだい ── 自社のアクセスログに残る個人情報と容量を点検する13項目（2026年10月時点）
CloudflareのLogpushでは、ログを書き出す前にSQLで行を落とし、項目を伏せられるようになった。ただし費用は落とす割合しだい ── 自社のアクセスログに残る個人情報と容量を点検する13項目（2026年10月時点）
目次
- 01 何が起きたか — CloudflareのLogpushで、ログを書き出す前に、SQLで行を落とし、項目を伏せられるようになった
- 02 なぜ・背景 — 個人に当たる項目は、残してから消すより、残す前に決めるほうがやさしい
- 03 用語 — 読み違えやすい言葉を先にそろえる
- 04 型別 — 自社がどれに当たり、何を、どの順で確かめるか
- 🅰 型A — Cloudflareを使い、Logpushでログを書き出している（または始める）サイト
- 🅱 型B — Cloudflareを使っていない（Apache・nginxの）サイト
- 🅲 型C — ログイン・会員登録の画面を持つサイト
- 🅳 型D — 制作会社・運用担当で、顧客のログの設定を引き継ぐ担当
- 公式が書いていることと、書いていないこと
- 手順1 — ログの出口を、全部書き出す
- 手順2 — 実際の1行を10本取り、項目を4つに分ける
- 手順3 — URLのクエリの項目の名前を、数える
- 手順4 — 落としてよい行を数え、割合を出す
- 手順5 — 費用を、公式の単価で試算する
- 手順6 — 試験でSQLを書き、試し実行で1件を確かめる
- 手順7 — 失敗したときの動きと、ログの保存期間を、先に決める
- 05 自分のサイトで確認するチェックリスト
- 06 代替・他の選択肢 — Transformersを使わずに、同じ点検をする
- 07 当サイトで確かめたこと
- 08 このテーマの、これまで
- 09 この記事のまとめ
01 何が起きたか — CloudflareのLogpushで、ログを書き出す前に、SQLで行を落とし、項目を伏せられるようになった
10月2日に提供が始まり、10月12日に仕組みの記事が出た
Cloudflareの公式ブログに、2026年10月2日付の記事「8 major updates to Cloudflare Observability」（訳: Cloudflare Observabilityの8つの大きな更新）がある。8つ目の更新は、Logpushが、これまでEnterpriseだけだったところから、すべてのセルフサービスのプランで使えるようになった、という内容である。同じ項目に、次の文がある。
"Transformers is now generally available, letting you apply any SQL transformation without operating a separate ETL pipeline."
（訳: Transformersは一般提供になった。別のETL（データを取り込み・変換する）の仕組みを運用せずに、どんなSQLの変換でも掛けられる。）
その10日後、2026年10月12日付の記事「Filter, reshape, and redact logs before export with Transformers」（訳: Transformersで、書き出す前にログを絞り、形を変え、伏せる）が出た。この記事は、Transformersが何をするかを、次のように書いている。
"Teams define a SQL query to filter records, redact sensitive data, and reshape the output by adding, renaming, removing, or nesting fields."
（訳: チームは、記録を絞り、機密のデータを伏せ、項目を足す・名前を変える・取り除く・入れ子にするなどして出力の形を変える、SQLの問い合わせを定義する。）
Logpush本体の提供の変更（Free・Pro・Businessでも従量課金で使える）は、当サイトの記事「CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）」で扱った。この記事は、その続きで、書き出す前に、何を落とし、何を伏せるかを、自社のアクセスログの側から考える。
Transformerは、データセットごとに書くSQLの文1本
ドキュメント（Transformersのページ・2026年10月12日更新）によると、Transformerは、Logpushのデータセットに対して書くSQLの文である。文の中の「FROM」が、どのデータセットかを示し、条件に合わない行は「WHERE」で落とされ、残った行は「SELECT」の結果が、書き出される記録になる。結果は、NDJSON（1行に1つのJSONを書く形式）で出る。作成・試し実行・管理は、ダッシュボードの「Transformer Studio」か、APIでできる。保存するたびに新しい版ができ、古い版も見られる。保存の前に、用意された見本の記録で、試し実行もできる。
公式ブログの例は、アドレスの末尾2つを伏せ、ヘルスチェックを落とす
10月12日のブログには、HTTPのリクエストのログ（データセットはhttp_requests）に掛ける例がある。例のSQLは、時刻を整数に直し、メソッドを大文字にし、「provider」という固定の項目を足し、ホストとパスを入れ子にし、5xxの応答かどうかの印を付ける。そのうえで、アドレスについては、regexp_replace(ClientIP, '\.\d+\.\d+$', '.XXX.XXX')で、末尾の2つの数字を伏せる。入力の「203.0.113.42」は、出力で「203.0.XXX.XXX」になる。また、内部のホスト2つと、パスが「/healthz」「/metrics」で始まる行は、WHEREで落とされる。
この伏せ方の式は、ドットで区切られた数字2つで終わる文字列に当たる。コロンで区切るIPv6のアドレスに当たるかは、この記事では試していない。式の形から読んだだけで、自社のアドレスの形に当てて試す必要がある。
できることと、できないこと
| 項目 | ドキュメントの記述の要旨 | 点検での意味 |
|---|---|---|
| 使えるプラン | Free・Pro・Business・Enterprise | 無料のプランでも試せる |
| フィルターとの関係 | 1つのジョブに、フィルターかTransformerのどちらか。両方は付けられない | 今のフィルターは、SQLの条件に書き直す |
| 使えるSQL | 項目の選択と改名、WHERE、WITH、UNNEST、JSONの取り出し、入れ子と配列の出力、UPPER・LOWER・COALESCE・CAST・to_timestampなど | 落とす・伏せる・名前を変えるは、これで足りる |
| 使えないSQL | 結合、副問い合わせ、集計、ウィンドウ関数、ORDER BY、複数の文 | 「同じ人の回数を数えて伏せる」などはできない |
02 なぜ・背景 — 個人に当たる項目は、残してから消すより、残す前に決めるほうがやさしい
アクセスログの1行には、アドレスとURLと参照元が入る
Cloudflareのドキュメントのhttp_requestsデータセットは、項目を次のように説明している。パスの項目（ClientRequestPath）は、次のとおりである。
"URI path requested by the client, which includes only the path portion of the requested URL, without the query string."
（訳: クライアントが要求したURIのパスで、要求されたURLのパスの部分だけを含み、クエリ文字列を含まない。）
一方、URIの項目（ClientRequestURI）は、クエリ文字列まで含む。
"URI requested by the client, which includes the full path and query string of the requested URL."
（訳: クライアントが要求したURIで、要求されたURLの、パスの全体とクエリ文字列を含む。）
つまり、同じ要求でも、どの項目を残すかで、「?」より後ろが、ログに残るかどうかが変わる。ほかに、訪問者のアドレス（ClientIP）、参照元（ClientRequestReferer）、端末の名乗り（ClientRequestUserAgent）がある。ヘッダーは、設定した項目だけが入る。
"String key-value pairs for request headers. This field is populated based on Logpush Custom fields, which need to be configured."
（訳: リクエストのヘッダーの、文字列の組。この項目は、設定が必要なLogpushのカスタム項目に基づいて入る。）
参照元の中にも、前のページのURLが、クエリつきで入りうる。参照元の数字を読むときの落とし穴は、当サイトの記事「外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった」に書いた。
Cloudflareを使っていなくても、同じ項目はサーバーのログにある
Apache（mod_log_config）は、%Uを「クエリ文字列を含まないURLのパス」、%qを「クエリ文字列」、%rを「リクエストの最初の行」と説明している。%rには、クエリ文字列が含まれる。%Cは、Cookieの値を出せる。nginxでは、$request_uriが「引数を含む、元のURI全体」、$requestが「元のリクエストの行全体」で、既定の書式は、リクエストの行と参照元と端末の名乗りを含む。
どの出口にも、同じ種類の項目がある。名前は違う。
ログイン・会員登録の画面は、URLに個人の情報が載る作りがありうる
パスワードの再設定やメールアドレスの確認では、メールのリンクのURLに、確認用の符号やメールアドレスを載せる作りがある。ログに「?」より後ろが残ると、その符号やアドレスも残る。自社の画面がそうかは、この記事からは分からない。開発者に、再設定と確認のURLに何を載せているかを聞く。
OWASPは、ログに直接残さないものを挙げている
ウェブの安全についての団体OWASPのログの手引き（Logging Cheat Sheet）は、記録する対象の前提を、最初に書いている。
"Never log data unless it is legally sanctioned."
（訳: 法的に認められていないデータは、決して記録しないこと。）
そのうえで、「通常は、ログに直接記録せず、取り除く・マスクする・無害化する・ハッシュにする・暗号化するもの」として、アプリのソースコード、セッションの識別値、アクセストークン、機微な個人データ、パスワードなどを挙げている。メールアドレスや電話番号などの、機微でない個人データは、「特別な扱いが要るかもしれないもの」の側にある。ログイン・会員登録の画面を持つサイトでは、セッションの識別値とアクセストークンが、特に当てはまる。
同じ手引きは、反対向きの注意も書いている。
"Never exclude any events from "known" users such as other internal systems, "trusted" third parties, search engine robots, uptime/process and other remote monitoring systems, pen testers, auditors."
（訳: 他の社内のシステム、「信頼できる」第三者、検索エンジンのロボット、稼働やプロセスなどの遠隔の監視システム、侵入テストの担当者、監査人などの、「既知の」利用者の記録を、決して除外しないこと。）
手引きは、そうした利用者の記録に、分類の印を付けて残す選択も挙げている。Cloudflareの例は、ヘルスチェックの行をWHEREで落とす。前提が違う。手引きは安全のための記録を想定し、Cloudflareの例は書き出す量を減らす目的である。どちらに従うかは、そのログを何に使うかで決まる。
容量と費用も、書き出す前に絞るほうが小さくなりうる
10月12日のブログは、捨てる記録にも費用が掛かることを書いている。
"Teams also pay to export, ingest, and store records they discard as soon as they arrive, so filtering them before delivery can reduce downstream data volume and cost."
（訳: チームは、届いた直後に捨てる記録にも、書き出し・取り込み・保管の費用を払っている。そのため、届ける前に絞れば、受け取る側のデータ量と費用を減らせる。）
ただし、Transformers自体にも費用が掛かる。手順5で、公式の単価を使って試算する。
03 用語 — 読み違えやすい言葉を先にそろえる
Transformerと、NDJSON
用語
Transformer：Logpushで書き出す前に、ログに掛けるSQLの文である。行を落とす、項目を選ぶ・伏せる・名前を変える、新しい項目を足す、ができる。NDJSON：1行に1つのJSONを書く形式である。TransformersはNDJSONで書き出すジョブだけが対象になる。
伏せる・マスクする・ハッシュにする
用語
伏せる（redact）・マスクする：値の一部または全部を、「XXX」などの印に置き換える。ハッシュにする：元に戻しにくい別の文字列に変える。同じ値は同じ文字列になるので、「同じ人のアクセスか」は分かる。ただし、アドレスのように取りうる値が少ないものは、元の値を割り出されることがある（公式の文書の記述ではなく、一般的な注意である）。
クエリ文字列と、データセット
用語
クエリ文字列：URLの「?」より後ろの部分で、「名前=値」を「&」でつなぐ。「/reset?token=XXXX」の「token=XXXX」がそれに当たる。データセット：Logpushで書き出せる、ログの種類ごとの一覧である。この記事で扱うのは、HTTPのリクエストを1行ずつ記録する、http_requestsである。
失敗したときの、2つの言葉
10月12日のブログは、Transformersの失敗時の設計を、次のように説明している。
"Transformers are designed to fail closed."
（訳: Transformersは、失敗したら閉じる（安全な側に倒れる）ように作られている。）
変換が実行できなければ、配信の位置を進めず、変換していないバッチも送らず、再試行する。伏せ字のつもりが、伏せていないログを送ってしまう事故を避ける設計である。理由は、変換していないデータが、下流の仕組みが前提にしている形や、伏せ字の前提を破りうるためと、ブログは書いている。
04 型別 — 自社がどれに当たり、何を、どの順で確かめるか
🅰 型A — Cloudflareを使い、Logpushでログを書き出している（または始める）サイト
Transformersを使える立場である。使う前に、何を残すかを決める。決めずにSQLを書くと、落としすぎ・伏せ忘れが起きる。手順2から進める。
🅱 型B — Cloudflareを使っていない（Apache・nginxの）サイト
Transformersは使えない。ただし、同じ点検は、サーバーのログの設定でできる（06章）。まず、手順1〜4で、いま何が残っているかを数える。
🅲 型C — ログイン・会員登録の画面を持つサイト
個人や秘密に当たる項目が、最も入りやすい型である。再設定・確認のURLの作りを開発者に聞き、手順3で、クエリ文字列の項目の名前を一覧にする。トークンやメールアドレスの項目の名前があれば、残さない設計が先で、ログの絞り込みは、その次の対策である。
🅳 型D — 制作会社・運用担当で、顧客のログの設定を引き継ぐ担当
引き継いだ設定に、Transformerが付いているかを確かめる。付いていれば、SQLを読んで、何が落ち、何が伏せられているかを、顧客と共有する。失敗が続くと記録が落ちるので、ジョブの状態を見る担当も決める。
公式が書いていることと、書いていないこと
ドキュメントは、失敗したときの扱いについて、変換していない元のログに自動で切り替える仕組みはない、と書いている。続けて、次のように書いている。
"If failures continue, records in the affected batches are eventually dropped and cannot be recovered."
（訳: 失敗が続くと、影響を受けたバッチの記録は、やがて落とされ、取り戻せない。）
ブログの「失敗したら閉じる」と合わせると、伏せ字は守られるが、SQLの間違いが続くと、記録そのものが無くなる、と読める。ログの状態は、ダッシュボードの「Transformer Health」で、変換の成功と失敗、変換前後のデータ量、変換にかかった時間を見られる、とブログは書いている。
一方、2つのページには、IPアドレスの伏せ方が各国の法令や自社の決まりに足りるかの判断と、IPv6のアドレスを伏せる式の例が、見つからなかった。見つからなかったことは、「無い」ことの証明ではない。確かめた範囲は、読んだ本文までである。ドキュメントのエラーの一覧には、「このアカウントではTransformerの機能が使えない」という応答（403）が載っているが、対象のアカウントは書かれていない。
手順1 — ログの出口を、全部書き出す
Cloudflareのログ、サーバーのアクセスログ、アプリが出すログなど、出口をすべて書き出し、「誰が見るか」「何日残るか」を1行ずつ書く。ログが2種類あるのに、片方だけを見ていた失敗は、当サイトの記事「『0件には三つの顔がある』と書いた記事が、三つ目の顔を踏んでいた ── サイトへのアクセスの94%を、52日間 見ていなかった」に書いた。
手順2 — 実際の1行を10本取り、項目を4つに分ける
各出口から、実際のログを10行ずつ取り（個人の値は、画面に貼らず、手元で見る）、項目を4つに分ける。個人や秘密に当たるもの、調査に要るもの、どちらでもないもの、分からないもの。分からないものは、開発者に聞く。
手順3 — URLのクエリの項目の名前を、数える
クエリ文字列がある要求を数え、「?」の後ろの項目の名前だけを、多い順に並べる。値は開かない。「token」「email」のような名前があるかが分かる。数え方の例は、07章に書いた。
手順4 — 落としてよい行を数え、割合を出す
ヘルスチェックや稼働の監視など、読む人がいない行を数え、全体に対する割合を出す。割合は、手順5の試算に使う。OWASPの手引きは、既知の利用者の記録を除外しないよう求めているので、落とさずに、印を付けて残す選択肢も並べる。
手順5 — 費用を、公式の単価で試算する
料金のページ（2026年10月14日に開いた）は、Free・Pro・Businessの単価を、次のように書いている。Cloudflare内部の宛先への書き出しは、月25GBまで無料で、超えた分は1GBあたり0.03ドル。外部の宛先は、25GBまで無料で、超えた分は0.10ドル。変換は、1GBまで無料で、超えた分は0.04ドル。変換の使用量は、Transformerに入る前の量で数える。
"Transformation usage includes the uncompressed input bytes processed by Transformers."
（訳: 変換の使用量には、Transformersが処理した、圧縮前の入力のバイト数が含まれる。）
この単価を使い、月100GBのログを、1か所に書き出し、全量にTransformerを掛ける場合を、自分で試算した。外部の宛先では、Transformerなしの月額は、(100−25)×0.10で7.50ドル。ありの月額は、変換の(100−1)×0.04＝3.96ドルに、書き出しの費用を足した額になる。何も落とさなければ、書き出しが7.50ドルで、合計は11.46ドルである。落とした割合が4割なら7.46ドル、6割なら5.46ドル、75%以上なら書き出しが無料枠に収まり、3.96ドルになる。落とした割合が約4割（39.6%）を超えると、なしの場合より安くなる。Cloudflareの内部の宛先（0.03ドル）では、同じ前提で、なしが(100−25)×0.03＝2.25ドルに対し、ありは0%で6.21ドル、75%以上で3.96ドルで、どの割合でも、ありのほうが高い。
この試算の前提は、全量にTransformerを掛けること、書き出しの量が落とした割合に比例して減ること、受け取る側（監視や分析の仕組み）の取り込み・保管の費用を含まないことである。10月12日のブログが書くように、受け取る側の費用が大きければ、結果は変わる。単価と無料枠は変わりうるので、実際の計算は、その時点の料金のページで行う。
手順6 — 試験でSQLを書き、試し実行で1件を確かめる
本番のジョブに付ける前に、試し実行の画面で、見本の記録に対して、アドレスを伏せる式、クエリを残さない項目の選び方、落とす条件を確かめる。ドキュメントは、本番で見える問題は、たいてい試し実行でも再現する、と書いている（要旨）。
手順7 — 失敗したときの動きと、ログの保存期間を、先に決める
失敗が続くと記録が落ちる（前掲）ので、ジョブの状態を誰が、どの間隔で見るかを決める。保存期間も決める。OWASPの手引きは、次のように書いている。
"Log data, temporary debug logs, and backups/copies/extractions, must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time."
（訳: ログのデータ、一時的なデバッグのログ、バックアップ・複製・抜き出したものは、必要な保存期間が終わる前に破棄してはならず、その期間を超えて保管してもならない。）
自社のプライバシーポリシーに、ログについての記述があれば、書いてある期間と、実際の保存期間が合っているかを、見比べる。
| 項目 | 残す理由 | 落とす・伏せる案 | 注意 |
|---|---|---|---|
| 訪問者のアドレス | 不正なアクセスの調査に使う | 末尾を伏せる、ハッシュにする | IPv6にも掛かるかを試す |
| クエリつきのURL | どの画面かは、パスだけで分かる | パスの項目だけ残し、クエリつきの項目は残さない | 項目名だけ要るなら、別に残す |
| 参照元 | 流入元の分析に使う | ドメインだけ残す、またはクエリを除く | 外部のURLのクエリが入りうる |
| ヘルスチェックの行 | 調査には使わないことが多い | 落とす、または印を付けて残す | OWASPは、既知の利用者の記録を除外しないよう求める |
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 自社のログの出口（Cloudflare・サーバーのアクセスログ・アプリのログ）を、すべて書き出し、各出口の見る担当と保存日数を、1行ずつ書く
- Cloudflareを使っているかを確かめ、使っている場合は、Logpushのジョブの数と、各ジョブの書き出し形式（NDJSONかCSVか）を書く
- 各出口から、ログを10行ずつ取り、個人や秘密に当たる項目の名前を、書き出す（値は書かない）
- クエリ文字列のある要求の数と、全体の要求の数を数え、割合を書く
- クエリ文字列の項目の名前を、多い順に10個書き、token・email・passなど、個人や秘密を思わせる名前があるかを「ある」「ない」で書く
- ログイン・会員登録・パスワード再設定の画面のURLを3つ書き、各URLに載る項目の名前を、開発者に聞いて書く
- 参照元の項目に「?」が付く行の数を数え、割合を書く
- ヘルスチェックや監視の行の数を数え、全体に対する割合を書く
- 訪問者のアドレスを、どの出口が残しているか、各出口で「残す」「伏せる」「残さない」のどれかを書く
- 書き出す量（月ごとのGB）を1つの数字で書き、公式の単価で、Transformerなしとありの月額を計算して並べる
- 自社のプライバシーポリシーを開き、ログ・アクセス記録・IPアドレスについての記述を、すべて書き写す
- 項目11の記述と、項目1の保存日数を並べ、合っているかを「合う」「違う」「書いていない」で書く
- 落とす条件と、伏せる項目を、試験の環境で試し実行し、見本の1件で、結果を書き写す日を、カレンダーに1つ登録する
時間が限られているときは、項目1・4・5・6の4つだけでも、状況が分かる。
06 代替・他の選択肢 — Transformersを使わずに、同じ点検をする
行を落とすだけなら、Logpushのフィルターで足りる
ドキュメントの関連ページには、「Filters - simpler filtering without SQL」（訳: フィルター：SQLを使わない、より簡単な絞り込み）がある。行を落とすだけで、項目を伏せない場合は、フィルターの条件で済む可能性がある。1つのジョブには、フィルターかTransformerのどちらか1つだけである。
Apache・nginxでは、書式と条件で、同じことができる
Apacheは、記録の設定（CustomLog）に、環境変数や式の条件を付けて、条件に合う要求だけを記録できる。nginxは、記録の設定（access_log）の「if」の指定で、条件つきの記録ができる。
"A request will not be logged if the condition evaluates to "0" or an empty string."
（訳: 条件が「0」または空の文字列と評価されたリクエストは、記録されない。）
項目のほうは、書式で選ぶ。Apacheなら、リクエストの行（%r）の代わりに、パスだけの%Uを使う。nginxなら、$request_uriや$requestの代わりに、$uriを使う（公式は、$uriを「正規化された現在のURI」と説明している。クエリを含まない形かは、自社の設定で確かめる）。サーバーの設定は、本番の前に試験の環境で試す。
アプリの側で、URLに秘密を載せない
最も強いのは、そもそもURLに載せない作りにすることである。再設定や確認の符号を、URLの「?」より後ろではなく別の形で渡せるかを、開発者に聞く。ログの絞り込みは、載ってしまったものを後から守る手段で、載せない設計の代わりにはならない。
いまは使わない、という選択
手順5の試算で、書き出し先がCloudflareの内部（R2など）の場合は、この前提では、Transformerなしのほうが安い。費用だけが目的なら、使わない判断もある。ただし、個人に当たる項目を残さない目的は、費用とは別に評価する。
注意
IPアドレスやクエリの項目を、法令の上でどう扱うか、どこまで伏せれば足りるかは、この記事では判断していない。自社の決まりと、法務や個人情報の担当者の判断に従う。この記事の試算も、公式の単価から自分で計算したもので、請求額を保証するものではない。
外から見える対策の点検には、当サイトの無料ツール🔧 WEBサイトの 外からできるセキュリティ対策監査ツールがある。サーバーのログの分析には、🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツールが使える。どちらも、会員のログインが要るツールで、ログの個人情報を判定するものではない。
07 当サイトで確かめたこと
当サイトはCloudflareを使っていない
当サイトは、Cloudflareを通していないので、Transformersそのものは試せない。代わりに、この記事の手順1〜4を、当サイトのサーバーのアクセスログで行った。
8本のログ、38,836行を、件数だけで数えた
2026年10月14日14時39分に、当サイトのサーバーのアクセスログのうち、日ごとにまとめた直近の7本と、いま書いている1本の、あわせて8本を数えた。ログの行は、画面に出していない。出したのは、件数と、項目の名前だけである。結果は、次のとおりである。
- 行の数は、38,836行。全行に、訪問者のIPv4アドレスが入っていた（IPv6の行は0）。
- 「?」で始まるクエリ文字列のある要求は7,672行で、全体の19.8%。参照元に「?」が付く行は490行（1.3%）。
- クエリ文字列の項目の名前で最も多いのは「tag」の6,135回（クエリのある要求の数の80.0%に当たる）。次が「ct」の581回、「q」の384回、「page」の322回。
- 「token」という名前の項目は、1回あった。名前に、mail・token・pass・pwd・tel・phone・session・sid・user・accountのどれかを含む項目が付いた要求は、11件あった。中身は開いていない。
- パスに、login・regist・signup・mypage・memberのどれかを含む要求は97件で、そのうちクエリ文字列のあるものは0件。
「q」は、名前から推測すると、サイト内の検索欄の項目である。検索語は自由に打てるので、何が入るかは、こちらで決められない。これも、中身は開いていない。この数え方は、当サイトの記事「「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だった ── ログを行全体で探すと、正反対の2つが混ざる」に書いた、行全体ではなく欄ごとに数える形にした。名前に当たる語が、別の欄の文字を拾わないようにするためである。
確かめていないこと
項目の値の中身、「token」の1回がどの画面のものか、11件が個人や秘密に当たるかは、確かめていない。ログの保存期間と、プライバシーポリシーの記述が合っているかも、確かめていない。当サイトも、この記事の13項目の順で確かめる。確かめた結果は、日付をつけて、この記事に書き足す。
08 このテーマの、これまで
日付つきの記録
- 2026年10月2日：Cloudflareが、Observabilityの8つの更新を発表した。Logpushがセルフサービスのプランで使えるようになり、Transformersが一般提供になり、Logpushとあわせて、従量課金が導入された。
- 2026年10月12日：Transformersの仕組みの記事が出た。Transformersと、料金のページのドキュメントも、同じ日に更新されている。
当サイトの関連する過去の記事は、下の「関連記事」に並べた。
現在の貴方のIPアドレス
このサイトで書いている人
