WEBサイトCloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点）
CloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点）
目次
- 01 何が起きたか — Cloudflareが2026年9月28日、大手1万サイトの実ユーザー計測を匿名化した「BEACON」をBigQueryで公開した
- 02 なぜ・背景 — 「他社より遅い」と言われた場面では、比べる相手の数字がどの母集団かを先に確かめる
- 03 この記事に出てくる用語
- 04 型別 — 適用範囲・この発表が測っていないこと・比べる相手を確かめる手順
- 05 明日、自社のサイトで確認できること — チェックリスト
- 06 代替・他の選択肢 — 数字を取る道具ごとに、誰の数字かが違う
- 07 当サイトの確認 — 当サイトはCloudflareの背後にないため、BEACONの数字には入らない
- 08 このテーマは、これまで
- 09 この記事のまとめ
01 何が起きたか — Cloudflareが2026年9月28日、大手1万サイトの実ユーザー計測を匿名化した「BEACON」をBigQueryで公開した
引用について
この記事の「" "」で囲んだ英語の文は、公式の資料からの引用で、日本語訳は記事の筆者が付けたものである。原文は各出典のページで確認できる。
公式ブログに書かれたこと
Cloudflareは2026年9月28日、公式ブログで「BEACON（Browser Experience Across Cloudflare's Observed Network）」という公開データを発表した。ブログはBEACONを次のように説明している。
"BEACON is an anonymized dataset built from billions of real-world performance measurements across 10,000 of the largest websites on our network."
（訳: BEACONは、Cloudflareのネットワーク上にある最大級の1万サイトで集めた、数十億件の実際の表示速度の測定から作った、匿名化されたデータセットである。）
ブログによると、データはすべての主要なブラウザエンジンを含み、Google BigQueryで毎日更新される。形式は、コミュニティが進めている公開データベース「RUM Archive」の標準に合わせてある。RUMはReal User Monitoringの略で、実際の利用者の画面で測った数字のことである。
出てくる指標は3つで、平均ではなく分布で公開されている
BEACONが報告する指標は、Core Web Vitalsの3つである。ページの読み込みの速さを表すLCP、画面のずれにくさを表すCLS、操作への反応の速さを表すINPが入っている。ブログは、数字の出し方を次のように書いている。
"Because we’re publishing these as full histograms rather than single averages, you can derive any percentile you like."
（訳: これらを1つの平均値ではなく、分布の全体（ヒストグラム）として公開しているので、好きなパーセンタイルを自分で計算できる。）
Googleの公式の基準は75パーセンタイル（P75）で判定する形だが、BEACONはP90やP95のような、遅い側の数字も計算できる。一部の業種では、いちばん遅い体験が、とくに画面のずれにくさ（CLS）で大きく悪くなると、ブログは書いている。
発表で示された数字の一例 — 切り替えの遷移と、読み直す遷移
ブログは、ページを読み直さずに中身を切り替える「ソフトナビゲーション」と、ページを読み直す「ハードナビゲーション」のLCPを、パーセンタイルごとに並べている。あわせて、最初に着地するページ（ランディングページ）の数字も出している。次の表は、ブログのLCPのパーセンタイルの2つの表（ハードとソフトの表と、ランディングページの表）を、1つにまとめ直したものである。
| 遷移の種類（数字はミリ秒） | P50（ミリ秒） | P75（ミリ秒） | P90（ミリ秒） | P95（ミリ秒） |
|---|---|---|---|---|
| ハードナビゲーション | 791 | 1,421 | 2,636 | 4,122 |
| ソフトナビゲーション | 274 | 582 | 1,169 | 1,816 |
| ランディングページ | 1,370 | 2,681 | 5,397 | 8,940 |
ブログは、この結果を次のようにまとめている。
"Soft navigations render two to three times faster than hard navigations at every percentile."
（訳: ソフトナビゲーションは、どのパーセンタイルでも、ハードナビゲーションより2〜3倍速く表示される。）
注意
表の数字は、ブログの表の値をそのまま写したものである。ブログは、この表の問い合わせの保存名を「Blink - Hard vs Soft Navigations」としている。名前に「Blink」と付いているため、ChromeなどBlink系ブラウザの数字と読めるが、表の対象が何かは、ブログの本文には明記されていない。自社の数字と並べる前に、元の問い合わせで確かめる必要がある。
02 なぜ・背景 — 「他社より遅い」と言われた場面では、比べる相手の数字がどの母集団かを先に確かめる
数字の出どころが分からないと、「遅い」かどうかを判断できない
「同業のサイトより遅い」と言われると、まず自社の数字を見直したくなる。しかし、比べる相手の数字が、誰の・何を・どう集計した数字かが分からないと、差があっても、それが本当の差なのかを判断できない。公開データが増えるほど、「平均」「業界」という言葉だけが先に回りやすくなる。
同じ「LCP」でも、集計のしかたで別の数字になる
LCPの値は、測る人・集める範囲・まとめ方で変わる。自社のページを実際に訪れた人のLCPと、世界の大手1万サイトを混ぜたLCPは、同じ「LCP」という名前でも、別のものの数字である。PageSpeed Insightsの公式の説明は、75パーセンタイルを使う理由を、次のように書いている。
"Our goal is to make sure that pages work well for the majority of users."
（訳: 私たちの目標は、ページが大多数の利用者にとって問題なく動くようにすることである。）
この考え方は、ページを訪れる利用者に向けた基準である。公式の基準は、1つのページやサイトを判定するためのものとして書かれており、大手1万サイトを混ぜた分布に、自社を当てはめるためのものとは書かれていない。
大手1万サイトを「1万番目の規模」にそろえる理由
BEACONの主な表は、最も大きなサイトに数字が引っ張られないように、規模をそろえて作られている。ブログは、全サイトをそのまま集めると、最大級のサイトがトラフィックの量でデータを支配して、数字がそのサイトの作りや訪問者の特徴に偏ると説明している。反対に、いちばん小さなサイトの量にそろえると、記録の数が大きく減ってしまう。この2つの両極端について、ブログは次のように書いている。
"These two extremes made it necessary to scope the dataset to the greatest number of the largest websites on our network to provide maximum diversity across architectures, technologies, geography, and more, all while retaining the total beacon count after normalizing."
（訳: この2つの両極端があるため、サイトの作り・技術・地域などの多様さを最大にしながら、正規化したあとも測定の総数を保てるように、Cloudflareのネットワーク上の大きなサイトをできるだけ多く含める形に、データセットの範囲を絞る必要があった。）
そこでCloudflareは、1万番目のサイトの規模に、ほかのサイトのデータ量をそろえるという方法を選んだ。1万サイトを選んだ理由も、ブログに書かれている。
"We found 10,000 to be a good balance: a globally representative sample with enough volume in the 10,000th that when we normalize the data down to their level, the overall dataset still represents billions of daily records collectively."
（訳: 1万サイトが、ちょうどよい釣り合いだと分かった。世界を代表する標本であり、1万番目のサイトにも十分な量があるため、その規模にデータをそろえても、全体として毎日数十億件の記録を表せる。）
つまり、BEACONの数字は、大きなサイトも中くらいのサイトも、同じ重さで混ぜた結果である。小さなサイトの数字ではない。
全体の傾向と、自社の目標値は別のもの
ブログは、業種別の結果も示している。政府・政治、健康、子ども向けの分類が速く、広告、宗教、天気が遅い傾向だと書いている。また、WebKitが交通量の10%を超える46の国では、LCPとINPの少なくとも一方が、ChromeやEdgeなどBlink系より10%以上悪かった。これらは全体の傾向であり、自社のサイトの目標値ではない。業種ごとの数字を読むときは、その分類が自社と同じ業種を指しているのか、自社と同じ規模のサイトの数字なのかを、読む前に確かめる必要がある。
03 この記事に出てくる用語
BEACONとRUM Archive
用語
BEACON—Cloudflareが公開した、大手1万サイトの実ユーザー計測を匿名化したデータセットである。RUM Archiveは、実際の利用者の画面で測った数字（RUM）を匿名化して集めた、無料で公開されているデータベースで、BigQueryで調べられる。
RUM Archiveのトップページは、データの提供元として「mPulse」と「Cloudflare RUM」の2つを挙げている。BEACONは、このRUM Archiveの標準に合わせて公開されたCloudflareのデータである。ブログは、この公開によって、RUM Archiveの範囲を100倍に広げると書いている。
パーセンタイルとヒストグラム
用語
パーセンタイルとヒストグラム—パーセンタイル（P75など）は、数字を小さい順に並べて、全体のどこに当たるかを表す値で、P75は「4人に3人はこの値以下」を表す。ヒストグラムは、数字を一定の幅の区間に分けて、各区間の件数を数えた分布である。
ヒストグラムの形で公開されたデータからは、好きなパーセンタイルを計算できる。ただし、区間の幅が決まっているため、計算結果は近似になる。RUM Archiveの説明によると、各ヒストグラムは152の区間で、ページ読み込み時間の場合は0〜10,000ミリ秒を100ミリ秒ごとに分けている。
ソフトナビゲーションとハードナビゲーション
用語
ソフトナビゲーション—ページ全体を読み直さず、JavaScriptで中身を差し替えて、別のページに移ったように見せる画面の切り替えである。ハードナビゲーションは、ページ全体を新しく読み込む、通常の移動である。
web.devの公式の解説は、Chromeがこの切り替えを測るために加えた仕組みの1つを、次のように説明している。
"PerformanceSoftNavigation which measures when a user interaction leads to both a paint and a URL change."
（訳: PerformanceSoftNavigationは、利用者の操作が、画面の描画とURLの変更の両方につながったときを測る。）
この解説の更新日は2026年8月11日で、冒頭に「Chrome 151がSPAのサイトでCore Web Vitalsを測れる新しいAPIを出した」という趣旨の更新の注記がある。
オリジンと正規化
オリジンは、「https://www.example.com」のように、サイト全体をまとめて表す単位である。CrUXの公式の説明は、これを次のように定義している。
"An origin represents an entire website, addressable by a URL like https://www.example.com."
（訳: オリジンは、https://www.example.com のようなURLで指せる、サイト全体を表す。）
04 型別 — 適用範囲・この発表が測っていないこと・比べる相手を確かめる手順
🅰 適用範囲 — 自社の比べる相手になるデータと、ならないデータ
BEACONの対象は、Cloudflareのネットワーク上の大手1万サイトである。Cloudflareを使っていないサイトの数字は入っていない。入っているサイトでも、サイト名は外してある。ブログは匿名化の方法を、次のように書いている。
"…we also strip out any potential customer website identifiers such as the domain name and URL paths."
（訳: ドメイン名やURLのパスなど、顧客のウェブサイトを特定できそうな情報も、すべて取り除いている。）
さらに、集計のしかたについて、ブログは次のように書いている。
"…we aggregate records together where they share dimensions such as country, operating system, browser, and connection protocol, and discard any records with fewer than five data points to further guarantee no individual or specific site can be identified."
（訳: 国・OS・ブラウザ・接続のプロトコルなどの区分が同じ記録をまとめ、さらに、個人や特定のサイトを特定できないことを確かにするため、データが5件に満たない記録は捨てる。）
この2点から、BEACONは、自社のサイトの数字を探す道具ではなく、全体の傾向を見るための公開データだと分かる。自社の数字は、別の道具で取る必要がある。自社の数字と全体の傾向の切り分けは、CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）で、CrUXのINPを例に整理している。
CrUXのほうは、サイトごとの数字を確かめられるが、すべてのサイトが入るわけではない。公式の説明は、次のように書いている。
"Not all origins or pages are represented in the dataset."
（訳: すべてのオリジンやページが、データセットに含まれているわけではない。）
🅱 この発表が測っていないこと
BEACONの発表から、自社の遅さの原因や、比べる相手との差の意味は読み取れない。測っていないことは、次の5つである。
- 自社のサイト単体の数字。サイト名は外してあり、特定のサイトの数字は引けない。
- Cloudflareのネットワーク上にないサイトの数字。Cloudflareを使っていないサイトは、対象に入らない。
- 1万番目より小さな規模での姿。規模をそろえた混ぜ方なので、小さなサイト単体の傾向は読み取れない。
- 5件に満たない組み合わせ。珍しい端末や国の組み合わせは、捨てられている。
- 数字の差の原因。ブログは、アフリカの転送サイズが小さい理由について、原因は確かめられないと書き、仮説を挙げるにとどめている。
RUM Archiveの説明は、5件に満たない記録を捨てることの影響にも触れている。別の提供元であるmPulseのデータについての見積もりだが、5件に満たない記録を捨てると、中央値の計算が約2.9%、95パーセンタイルの計算が約7%動きうると書いている。足切りは、遅い側の数字ほど大きく影響する可能性がある。
🅲 手順 — 比べる相手の数字を確かめる5段
手順は5段ある。図の順番に、上から確かめる。各段で、確かめた内容を1行ずつ書き留めておくと、最後に差の読み方を決められる。
手順1 — 数字の出どころを書き留める
「他社より遅い」と言われた数字が、どの資料に書かれていたかを、ページのURLと日付つきで書き留める。ブログ記事やSNSの投稿には、元の発表を要約したものがある。元の発表のページを開いて、数字と文面を確かめる。数字の期間が変わると、同じ指標でも別の数字になる点は、その数字、本当に"今日"の数字か — WEB運営で見落とされる"期間"の罠が参考になる。
手順2 — 母集団を確かめる
その数字が、どのサイトの集まりの数字かを確かめる。BEACONなら「Cloudflareのネットワーク上の大手1万サイト」である。自社と同じ業種・同じ規模のサイトの集まりかを、1行で書く。他人が出した数字を自社に当てはめる前に確かめる点は、「+28%」と「+9%」は、同じ調査の、同じプラットフォームの数字だった ── 他人が測った数字を自分のサイトに当てはめる前に確かめる3点に3つにまとめている。比べる相手を置かないと効果が読めなかった当サイトの例は、猫のファイルが「効いている証拠」を無効化した日 ── llms.txtに足りなかったのは比べる相手だったにある。
手順3 — 集計のしかたを確かめる
集計のしかたが違うと、同じ名前の数字でも並べられない。確かめることは3つある。パーセンタイルか平均か、端末（モバイル・デスクトップ）や国で分けてあるか、足切りや規模の正規化があるか、である。PageSpeed Insightsの公式の説明によると、実際のユーザーの欄は、直近28日の数字で、75パーセンタイルが表示される。BEACONは分布ごと公開されているため、P75を自分で計算して合わせられる。
手順4 — 自社の数字を同じ形で取る
比べる数字と同じ指標・同じパーセンタイル・同じ端末で、自社の数字を取る。自社のトップページのURLを入れると、実際のユーザーの数字が出る場合がある。🔧 Lighthouse監査・チェックツールは、最大3ページまでまとめて測れる（利用には無料の会員登録が必要である）。ただし、Lighthouseは決まった条件の機械で測るラボの数字で、実際の利用者の数字とは別のものである。
実務のヒント
数字が出ないときは、訪問者が少なくてCrUXに入っていない可能性がある。そのときは、自社の画面に計測の仕組みを入れて、自社で数字を集める方法がある。公式のweb-vitalsライブラリは、実際の利用者のWeb Vitalsを、Chromeが測る方法に合わせて測るために作られている。
手順5 — 差の読み方を1行で書く
最後に、条件がそろった差だけを「遅い」と書き、条件がそろわない差は「参考」と書く。たとえば、比べる相手が大手1万サイトの混ぜた数字で、自社が小さな業種限定のサイトなら、その差は「全体の傾向」としてだけ使う。この書き方を決めておくと、報告の文面が毎回そろう。報告された数字と、測り直した数字の食い違いを分けた例は、警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったにある。
05 明日、自社のサイトで確認できること — チェックリスト
以下は、「他社より遅い」と言われたときに、比べる相手の数字と、自社の数字を確かめるための項目である。1〜5番目は数字の出どころ、6〜8番目は自社の数字、9〜10番目は画面の切り替え、11〜13番目は並べて比べることである。チェックの状態はブラウザに保存され、サーバーには送られない。
- 「他社より遅い」と言われた資料を1つ選び、数字・出どころのページのURL・測った期間を3行で書き留める
- その数字が、サイト名のわかる数字か、サイト名を外した集計かを、発表の原文で確かめて1行で書く
- その数字の対象が「大手1万サイト」のような範囲か、自社と同じ業種・同じ規模のサイトかを、原文で確かめて1行で書く
- その数字が75パーセンタイル・平均・中央値のどれかを、原文で確かめて書き留める
- その数字が、モバイルとデスクトップ、国で分けてあるかを確かめ、自社の主な端末と国と同じ分け方か照らす
- PageSpeed Insightsに自社トップページのURLを入れ、「実際のユーザー」欄のLCP・INP・CLSの75パーセンタイルを、モバイルとデスクトップで書き留める
- その欄が「このURL」と「オリジン全体」のどちらの数字かを書き留める
- 比べる数字と同じ指標・同じパーセンタイルで、自社の数字を並べた表を1枚作る
- 自社の画面が、ページを読み直さず中身を切り替える作りかを、ブラウザで3画面たどって確かめる
- 切り替える作りの場合は、使っている計測の道具が切り替えを数えるかを、公式の文書で確かめて書き留める
- 自社と同じ業種・同じ規模のサイトを2〜3つ決め、PageSpeed Insightsの「実際のユーザー」欄を同じ日に書き留めて、自社の数字と並べる
- 並べた差のうち、指標・パーセンタイル・端末がそろっているものだけに印を付け、そろわない差には「参考」と書く
- 差の読み方を1行で書き、比べた日付と並べて、4週間後に同じ数字を取り直す予定をカレンダーに入れる
06 代替・他の選択肢 — 数字を取る道具ごとに、誰の数字かが違う
道具ごとに、見える数字が違う
自社の遅さを確かめる道具は、複数ある。それぞれ、誰の数字を、どう集計して見せるかが違う。次の表は、この記事で原文を確かめた道具を並べたものである。
| 道具 | 誰の数字か | 集計・更新 | 使いどころ |
|---|---|---|---|
| PageSpeed Insights | 自社のURLまたはオリジンの実際の利用者（CrUX） | 直近28日・75パーセンタイル | 自社の数字を確かめる |
| CrUX API | 同じCrUXの数字をプログラムで取る | 28日の移動平均・毎日UTC 4時ごろ更新 | 自社の数字を毎週記録する |
| CrUX BigQuery | CrUXのオリジン単位の数字 | 月ごとの表（2017年10月分から） | 過去の月や、ほかのオリジンと並べる |
| BEACON | Cloudflare上の大手1万サイトの実際の利用者（サイト名なし） | 毎日更新・規模をそろえる・5件未満は捨てる | 全体の傾向を知る |
| Search Console | 自社サイトのURLグループごとの状態 | 過去の利用者のデータにもとづく | どのURLに問題があるかを探す |
| web-vitalsライブラリ | 自社の利用者 | 自社で決める | 自社の原因を探す |
CrUXのAPIとBigQueryは、同じCrUXの数字を、別の形で出す。CrUX APIの説明は、データの性質を次のように書いている。
"The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics."
（訳: Chrome UX Reportのデータは、集計した指標の、28日間の移動平均である。）
このため、CrUXで見る数字には、直近4週間の訪問が混ざっている。改修した日の翌日に数字が変わらなくても、すぐには反映されない点に注意が要る。
BEACONを使うなら、BigQueryで日付を絞って問い合わせる
BEACONを実際に調べたい場合は、BigQueryを使う。ブログは、入手方法を次のように書いている。
"BEACON is publicly available on Google BigQuery."
（訳: BEACONは、Google BigQueryで公開されている。）
BigQueryを使うには、Google Cloudのプロジェクトと、SQLの基本の知識が必要である。RUM Archiveの説明は、問い合わせの費用を抑える方法を、次のように書いている。
"We suggest you limit all queries to a specific date (or date range) to limit your BigQuery query costs."
（訳: BigQueryの問い合わせ費用を抑えるため、すべての問い合わせを、特定の日付（または日付の範囲）に限ることを勧める。）
自社の数字が出ないとき
PageSpeed Insightsの公式の説明は、数字が出ない場合を、次のように書いている。
"PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website."
（訳: PageSpeed Insightsは、オリジン単位の粒度に切り替える。これはサイトのすべてのページでの、すべての利用者の体験を含む。）
URL単位の数字が出ないときは、オリジン全体の数字を見る。オリジンにも十分なデータがなければ、実際のユーザーの数字は表示されない。そのときは、Search Consoleの画面で自社の状態を確かめたり、自社で数字を集めたりする。Search Consoleの見方に迷ったときは、🔧 Search Console解説ツールが参考になる。
注意
自社の数字が出ないことは、自社が遅い・速いを意味しない。訪問者の数や、公開の条件を満たしているかによる。CrUXの公式の説明は、ページが検索エンジンと同じ基準で公開されていること（HTTPステータスが200で、noindexが付いていないこと）と、十分な訪問者がいることを、条件に挙げている。
07 当サイトの確認 — 当サイトはCloudflareの背後にないため、BEACONの数字には入らない
2026年10月6日に、応答ヘッダーを確かめた
BEACONの対象は、Cloudflareのネットワーク上のサイトである。そこで、当サイトのトップページの応答ヘッダーを、2026年10月6日に確かめた。結果は、サーバーの名前が「Apache」で、Cloudflareを通った応答に付く識別子の行（cf-ray）は見当たらなかった。
この結果から、当サイトの数字は、BEACONの対象に入っていないと考えられる。入っていても、サイト名は外されるため、当サイトの数字は引けない。BEACONは、当サイトにとっては、自社を測る道具ではなく、全体の傾向を知るための参考資料である。
当サイトが、報告された数字を測り直した例
当サイトでは、点検ツールが報告した数字を、測り直して分けた経験がある。当サイトの記事「警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった」は、1,440件の警告の中から、本物の問題を2件だけ見つけた記録である。報告された数字をそのまま使わず、出どころと数え方を確かめる点は、この記事の手順1〜3と同じ考え方である。
この記事では、当サイトの表示速度の数字を載せていない
この記事には、当サイトの表示速度の数字は載せていない。BEACONの数字と並べられる、同じ条件の数字を、確認した時点で取れていないためである。
08 このテーマは、これまで
2017年10月から、CrUXの月ごとの表がある
CrUXのBigQueryの説明は、各データセットに、2017年10月分（201710）以降の月ごとの表があると書いている。実際の利用者の数字を公開データとして見る仕組みは、BEACONの発表より前から、サイト単位の形であった。BEACONは、サイト名を外して大手1万サイトを混ぜた形で、公開している。
2024年3月12日、INPがFIDに代わった
web.devのブログは、2024年1月31日の更新で、次のように予告した。
"Interaction to Next Paint will officially become a Core Web Vital and will replace First Input Delay on March 12."
（訳: Interaction to Next Paintは、3月12日に正式にCore Web Vitalsの1つになり、First Input Delayに代わる。）
これにより、操作への反応の速さを表す指標は、INPに入れ替わった。BEACONも、INPを指標に含めている。
2026年8月、ChromeがソフトナビゲーションのCore Web Vitalsを測るAPIを出した
web.devの解説は、2026年8月11日の更新で、Chrome 151が、SPAのサイトでCore Web Vitalsを測れる新しいAPIを出したと書いている。一方、CrUXの方法論のページ（最終更新2024年6月20日）には、切り替えの遷移が、最初の読み込みの数字にまとめられるという趣旨の説明が、まだ残っている。
この2つは、ページごとの更新日が違うために食い違って見える。数字を読むときは、各資料の更新日を見て、どの時点の説明なのかを確かめる必要がある。競合サイトの数字を推定値として読む注意は、競合サイトの数値をどう読むか ── Similarwebなど分析ツールの「推定値」と、実際に測った数字との違い（2026年8月時点）にも書いてある。
2026年9月28日、BEACONが公開された
Cloudflareは2026年9月28日に、BEACONを公開した。ブログは、LCPとINPの内訳の指標を、Cloudflareの自社の計測ダッシュボードにも、数週間のうちに加えると書いている。
この記事の確認日
この記事に書いた内容は、2026年10月6日に、各資料の原文のページを開いて確認した。各資料の更新日が変わったら、最新のページを優先する。BEACONは毎日更新されるため、数字は読む日によって変わる。
現在の貴方のIPアドレス
このサイトで書いている人
