WEBサイトCloudflareは、HTTP/3で利用者が途中でやめた通信を499として記録するようにした。499が増えても失敗が増えたとは限らない ── エラー率と稼働率の分母と内訳を点検する13項目（2026年10月時点）
Cloudflareは、HTTP/3で利用者が途中でやめた通信を499として記録するようにした。499が増えても失敗が増えたとは限らない ── エラー率と稼働率の分母と内訳を点検する13項目（2026年10月時点）
目次
01 何が起きたか — Cloudflareが、利用者が途中でやめたHTTP/3の通信を499として記録するようになった
更新履歴に、取り消された通信の扱いの変更が載った
Cloudflareの更新履歴（Changelog）に、2026年10月9日の日付で「Improved HTTP/3 client cancellation reporting」（訳: HTTP/3で利用者の側が取り消した通信の扱いと記録の改善）という項目が出た。製品の区分は「Cloudflare Fundamentals」と付いている。2026年10月15日に、ページの本文を取り直して読んだ。最初の文は、次のとおりである。
"Cloudflare has improved how it handles and reports client-cancelled HTTP/3 requests across Free, Pro, Business, and Enterprise plans."
（訳: Cloudflareは、利用者の側が取り消したHTTP/3の要求の扱いと記録を、Free、Pro、Business、Enterpriseの各プランで改善した。）
取り扱いと記録の変更の対象として、Free・Pro・Business・Enterpriseの4つのプランすべてが挙げられている。これは変更の範囲の話で、499が見える画面がどのプランにもある、という意味ではない（01章の終わりで書く）。
変更の前は2通り、変更の後は1通りになった
何が変わったのかは、次の2つの文に書かれている。変更の前の状態は、こうである。
"Previously, Cloudflare did not always stop an HTTP/3 request when the client cancelled its request stream. Some cancellations were already recorded as 499, while others continued to the origin and showed the eventual upstream status."
（訳: これまでCloudflareは、利用者の側が要求のストリームを取り消しても、HTTP/3の要求を必ずしも止めていなかった。取り消しの一部はすでに499として記録されていたが、ほかのものはオリジンまで進み、最終的に上流が返したステータスで記録されていた。）
変更の後の状態は、次の1文である。
"Cloudflare now stops affected requests sooner, reducing unnecessary origin work, and records them as 499."
（訳: Cloudflareは今は、影響を受ける要求をより早く止め、オリジンの無駄な作業を減らし、それらを499として記録する。）
つまり、利用者が途中でやめた同じ通信が、変更の前には499にも、オリジンが最後に返したステータスにもなりえた。変更の後は、499にそろう。この記事の主題は、ここである。エラー率や稼働率の計算に、取り消された通信が、どのステータスで入っていたかが、ある日を境に変わる。
利用者に向けた2つの注意書き
更新履歴は、利用者が気づくことを、次のように書いている。
"Customers may notice more 499 status codes for HTTP/3 traffic. This reflects more consistent reporting of existing cancellations, not an increase in failed requests."
（訳: 利用者は、HTTP/3の通信で499のステータスが増えたことに気づくかもしれない。これは、すでにあった取り消しがより一貫して報告されるようになったことを表すもので、失敗した要求が増えたのではない。）
さらに、稼働率の計算についての一文がある。
"Customers who use 499 status codes in availability calculations should consider excluding them from server-side error rates because they represent requests cancelled by clients."
（訳: 稼働率の計算に499のステータスを使っている利用者は、499が利用者の側で取り消された要求を表すので、サーバー側のエラー率から除くことを考えるとよい。）
この文は「should consider」（考えるとよい）と書いている。除くかどうかは、利用者が決めるという書き方である。除くなら、どの計算から除くかも決める必要がある。それが04章以降の話である。
この記事が読んだもの、読めなかったもの
更新履歴は、利用者が見やすくなる場所を、Cloudflareの分析と、利用できる場合はログ、と書いている。一方、Cloudflareの499の説明ページ（2026年6月16日更新）は、499がログとステータスの分析に出るのは、Enterpriseの顧客の場合と書いている。変更の後に、ほかのプランで499が見えるのかは、どちらにも書かれていない。
更新履歴の短い文章からは、499が何割増えるのか、いつから全体に行き渡ったのかも読み取れない。書かれていないからである。また、この記事を書いた側はCloudflareを使っていないので、管理画面で数字が動くところは見ていない。画面の見え方は、書かない。
02 なぜ・背景 — 499は標準に登録されたステータスではなく、エラー率は割り算である
499は、HTTPの標準のステータスの登録簿に載っていない
HTTPのステータスコードの登録簿は、IANAが管理している。2026年10月15日に開いたページには、「Last Updated 2025-09-15」（最終更新 2025年9月15日）と出ていて、400番台の最後の行は「452-499」で、状態は「Unassigned」（未割り当て）である。499という番号は、登録簿では割り当てられていない。
Cloudflareの499の説明ページは、この番号の出どころを、次のように書いている。
"The 499 Client Closed Request status code is specific to nginx and indicates that the client closed the connection while the server was still processing the request, preventing the server from sending a status code in response."
（訳: 499 Client Closed Requestのステータスコードはnginxに特有のもので、サーバーがまだ要求を処理している間に利用者の側が接続を閉じたことを示し、サーバーが応答でステータスコードを返せなくなる。）
大事なのは、最後の部分である。利用者はもう居ないので、ステータスは利用者には返らない。499は、記録をつけるソフトが付けた目印である。このページの最終更新は、2026年6月16日と書かれている。
HTTP/3では、取り消しは通信の仕組みの中にある
HTTP/3の規格（RFC 9114、2022年6月）の4.1.1節は、要求の取り消しを、次のように説明している。
"Clients cancel requests if the response is no longer of interest; servers cancel requests if they are unable to or choose not to respond."
（訳: 利用者の側は、応答がもう必要でなくなったとき、要求を取り消す。サーバーの側は、応答できないか、応答しないと選んだとき、要求を取り消す。）
同じ節は、利用者の側が取り消すときに、H3_REQUEST_CANCELLEDというエラーコードを使うことを勧めている。これは通信の部品のエラーコードで、HTTPのステータスとは別のものである。たとえば、ページを閉じたときや、読み込みを中止したときに、取り消しが起きうる。取り消しは、障害ではなく、普通に起きる動作である。
エラー率は割り算で、分母が動けば数字が動く
Googleのサービス運営の本（Site Reliability Engineering）は、サービスの状態を表す数字として、エラー率を、次のように説明している。
"Other common SLIs include the error rate, often expressed as a fraction of all requests received, and system throughput, typically measured in requests per second."
（訳: ほかのよくある指標には、受けた全要求に対する割合で表すことが多いエラー率や、1秒あたりの要求数で測ることが多い処理量がある。）
「受けた全要求に対する割合」とある。分子（何をエラーと数えるか）と分母（何を全体と数えるか）の両方が、数字を決める。同じ書の実践の手引きは、指標を「良い出来事の数 ÷ 出来事の総数」の割り算にすることを勧めている。
"While many numbers can function as an SLI, we generally recommend treating the SLI as the ratio of two numbers: the number of good events divided by the total number of events."
（訳: 指標になりうる数字は多いが、私たちは一般に、指標を2つの数の比として扱うことを勧める。良い出来事の数を、出来事の総数で割った値である。）
変更の前は、取り消しの行き先が割れていた
変更の前は、同じ「利用者が途中でやめた通信」が、499になるものと、オリジンの最後のステータスになるものに割れていた。「500番台の割合」を見ていた報告では、オリジンが500番台を返して終わった取り消しが、エラーに入っていた。「200の割合」を見ていた報告では、200で終わった取り消しが、成功に入っていた。
変更の後は、これらがすべて499にそろう。計算式が同じでも、数字が動く。動いたのは、サイトの状態ではなく、記録の付け方である。数字の動きを見る前に、式の分子と分母を確かめる。
03 用語 — 数え方の言葉を先にそろえる
499（Client Closed Request）
用語
499：利用者の側が、サーバーの処理が終わる前に接続を閉じたとき、ログに付く番号である。Cloudflareの説明ページは「The HTTP 499 response code typically occurs when a client terminates the connection before the server is able to respond.」（訳: HTTPの499の応答コードは、サーバーが応答できる前に利用者の側が接続を終えたときに、よく起きる）と書いている。HTTPの標準の登録簿には載っていない。
取り消しと、待ちきれずに閉じた場合
499には、2種類の事情が入りうる。1つは、利用者が自分で画面を閉じたり移ったりした場合である。もう1つは、利用者の側のソフトが、待つ時間の上限を超えて接続を切った場合である。Cloudflareの499の説明ページは、後者の例として、利用者の側が待つ時間の設定が短く、サーバーの処理が終わる前に閉じるときを挙げている。499の中身は、利用者の気持ちが変わった場合と、サーバーが遅かった場合の、両方がありうる。
エラー率と、分母に入れるもの
用語
エラー率：全体の要求のうち、エラーと数えたものの割合である。式は「エラーの数 ÷ 全体の数」になる。何をエラーと数えるか（500番台だけか、400番台も含めるか）と、何を全体と数えるか（取り消された通信を含めるか）の2つを決めないと、数字は出ない。
稼働率と、サービスの目標
用語
稼働率（可用性）：サービスが使えた割合である。Googleのサービス運営の本は「It is often defined in terms of the fraction of well-formed requests that succeed, sometimes called yield.」（訳: 正しい形の要求のうち、成功したものの割合で定義されることが多く、yieldと呼ばれることもある）と書いている。サービスの目標（SLO）は、その指標について決める、目標の値や範囲である。「正しい形の要求」とあるので、どの要求を数えるかも定義の一部である。
オリジンと上流
用語
オリジン（origin）と上流（upstream）：CDNやロードバランサーの後ろにある、実際にページを作って返すサーバーのことである。Cloudflareのログの項目の説明は、オリジンが返した値を「Status returned by the upstream server.」（訳: 上流のサーバーが返したステータス）と書く。利用者に返したステータスは、別の項目「HTTP status code returned by Cloudflare to the client.」（訳: Cloudflareが利用者に返したHTTPステータスコード）である。
04 型別 — 自社がどれに当たり、何を、どの順で数え直すか
🅰 型A — ログイン・会員登録・予約・購入の画面を持つサイト
この型は、ステータスの数字よりも、画面の完了数を先に見る。ログインや登録の完了数が、変更の前後で変わっていなければ、499が増えても、利用者の仕事が失敗したとは言いにくい。反対に、完了数が下がっているなら、499は原因の手がかりになる。取り消された通信の中に、送信（POST）が含まれているかも、ログのメソッドの欄で数える。
🅱 型B — 記事や紹介のページが中心で、検索から来る割合が高いサイト
この型は、検索エンジンの巡回に影響するステータスを、499とは別に数える。Googleの巡回の技術文書「How HTTP status codes affect Google's crawlers」（訳: HTTPステータスコードは、Googleの巡回にどう影響するか）は、500番台について、次のように書いている。
"5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling."
（訳: 5xxと429のサーバーエラーは、Googleの巡回の動きを、一時的に遅くさせる。）
この文書の本文に、499という番号は出てこない（2026年10月15日に、ページの本文を確かめた）。巡回に関わる500番台と、利用者が切った通信は、別の行にして数える。
🅲 型C — すでにCloudflareを使っているサイト
この型は、変更の日の前後で、499が増えたかを、自分の数字で確かめる。499が自分のプランの分析やログに出るかは、先に画面で確かめる。増えていたなら、更新履歴の言うとおり「すでにあった取り消しが、499にそろっただけ」と読めるかを、500番台や200の件数の動きと並べて確かめる。分析データを手元に残す手順は、当サイトの記事「Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）」に書いた。
🅳 型D — Cloudflareを使っていないサイト（当サイトもこの型）
この型は、今回の変更は自社の記録に入らない。ただ、利用者が途中で切った通信は、どの構成にもある。記録にどんな番号で残るかは、使っているソフトで違う。AWSのロードバランサーの文書は、似た場合に460という番号を使っている。
"The load balancer received a request from a client, but the client closed the connection with the load balancer before the idle timeout period elapsed."
（訳: ロードバランサーは利用者から要求を受けたが、利用者は、アイドルタイムアウトの時間が過ぎる前に、ロードバランサーとの接続を閉じた。）
この文は、AWSの「Troubleshoot your Application Load Balancers」（訳: Application Load Balancerのトラブルシューティング）の、HTTP 460の項目にある。番号もソフトで違うので、自社の記録に「利用者が切った」通信がどう出るかを、先に確かめる。
手順1 — エラー率と稼働率の定義を、書き出す
最初にするのは、式を変えることではなく、いまの式を書き出すことである。月次の報告や監視の画面で、エラー率と稼働率について、分子に入るステータスの範囲、分母に入れるもの、集計の期間と単位（日・週・月）の3つを書く。式が読めないなら、「式が読めない」と書く。それも結果の1つである。
手順2 — 変更の前後を、同じ長さで並べる
更新履歴の日付は2026年10月9日だが、いつから全体に行き渡ったかは書かれていない。そこで、10月9日の前の7日と、後の7日を、同じ長さで並べる。7日にするのは、曜日で件数が違うことが多いからである。499、500番台、全体の件数を、日ごとの表にする。Cloudflareを使っていないサイトも、同じ表を作ると、普段の揺れが分かる。
手順3 — 499を別の行にして、定義を変えて計算する
499を別の行にして、定義を変えながら、同じ数字から計算し直す。次の表は、仮の数字で作った例である。実際のサイトの数字ではない。全体は変更の前後とも100万件、利用者の取り消しは3,000件とする。取り消しの記録先は、変更の前は「499が1,000件、オリジンの200が1,800件、オリジンの500番台が200件」で、変更の後は「3,000件すべてが499」になった、という想定である。
| 数え方 | 変更の前 | 変更の後 | 動いた向き |
|---|---|---|---|
| 5xxだけをエラー、分母は全体 | 1,000 ÷ 1,000,000 = 0.100% | 800 ÷ 1,000,000 = 0.080% | 下がる（稼働率は99.900%から99.920%へ） |
| 400番台以上をすべてエラー、分母は全体 | (9,000 + 1,000 + 1,000) ÷ 1,000,000 = 1.100% | (9,000 + 3,000 + 800) ÷ 1,000,000 = 1.280% | 上がる |
| 499を分子と分母の両方から除く | (9,000 + 1,000) ÷ 999,000 = 1.001% | (9,000 + 800) ÷ 997,000 = 0.983% | わずかに下がる |
表の読み方は、こうである。同じ取り消しなのに、1行目は下がり、2行目は上がる。数え方によって、動く向きが逆になる。2行目で数字が上がったのは、500番台のエラーが増えたからではなく、499が400番台に入っていて、499の増え方が、500番台の減り方より大きかったからである。この行だけを月次の報告に載せていると、変更の日から「エラー率が悪化した」と読まれる。
実務のヒント
月次の報告の表に、499の行を足し、エラー率の式の隣に、分子と分母の説明を1行で書いておく。数字だけを毎月並べると、定義を変えた月に、前の月と比べられなくなる。定義を変えた日付も、表の下に書く。
手順4 — 499の中身を、URLと応答時間で割る
499を丸ごと「サイトの失敗ではない」と除くと、見えなくなるものがある。Cloudflareの説明ページは、499の調べ方を、次のように書いている。
"Use Origin Analytics to check whether slow origin response times are causing clients to close connections prematurely."
（訳: オリジンの分析を使い、オリジンの応答が遅いことが、利用者の側に接続を早く閉じさせていないかを確かめる。）
499のなかに、サーバーが遅くて、利用者が待ちきれずに離れた分が混ざっているかもしれない、ということである。それを見分けるには、499の件数が多いURLの上位を並べ、その応答時間を見る。画像のような軽い要求が多いのか、検索やログインのような重い処理が多いのかで、読み方が変わる。
注意
499を、エラー率から除くのは、利用者が自分で離れた分だけでよい。待ちきれずに離れた分まで除くと、遅さが原因の離脱が、数字から消える。除いた499は、別の行で件数と応答時間を見続ける。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。Cloudflareを使っていないサイトも、項目1から4と7、13は、そのまま使える。
- 月次の報告か監視の画面で「エラー率」の計算式を探して書き写し、分子に入るステータスの範囲と、分母に入れるものを、1行ずつ書く
- 「稼働率」の計算式も同じように書き写し、利用者が途中で切った通信が、成功と失敗のどちらに入るか、分母から外れるかを、「入る」「外れる」「書いていない」から選んで書く
- 契約書や社内の目標（SLAやSLO）にある稼働率の定義の文を開き、利用者が途中で切った通信に触れた文があるかを、「ある」「ない」で書く
- ステータス別の件数を、直近30日分、日ごとに、100番台から500番台の5つに分けた表にして書く
- 499を別に記録しているなら、2026年10月9日の前の7日と後の7日について、499の日別の件数と、全体に占める割合を書く（記録していなければ「記録なし」と書く）
- 500番台の件数を、項目5と同じ前の7日と後の7日で並べ、増えたか減ったかを書く
- 400番台以上をすべてエラーと数えているなら、499を含めた割合と、499を除いた割合の2つを計算して書く
- 499が多いURLの上位10件を並べ、ログインや送信のように結果が大事な画面か、画像のように軽い要求かを分けて書く
- 項目8の10件について、オリジンの応答時間を（取れる範囲で）書き、遅いものに印を付ける
- 取り消された通信のうち、送信（POST）が何件あるかを、メソッドの欄で数えて書く
- ログインや会員登録、問い合わせの完了数を、項目5と同じ前の7日と後の7日で並べて書く（画面が無ければ「画面なし」と書く）
- 通信の種類（HTTP/3、HTTP/2など）の欄があれば、種類ごとの499の件数を書く（欄が無ければ「欄なし」と書く）
- 項目1から12の結果から、「失敗が増えた」「数え方が変わっただけ」「判断できない」のどれかを選び、日付を付けて1枚にまとめて保存する
時間が限られているときは、項目1・2・5・7・13の5つだけでも、理由が数え方の側にあるかの見当は付く。
06 代替・他の選択肢 — エラー率の数え方を選ぶ
数え方は、5つの選び方がある
数え方は、目的に合わせて選ぶ。次の表は、この記事の整理である。
| 数え方 | 向いている場面 | 向かない場面 |
|---|---|---|
| 5xxだけをエラー、分母は全体 | サーバーの失敗を見る。Googleの運営の手引きの例も、この形である | 利用者の不満（遅さ、拒否）が見えない |
| 5xxだけをエラー、分母から499を除く | 利用者が離れた分を、全体から外して見る | 分母の動きで、数字が毎月少し揺れる |
| 400番台以上をすべてエラー | 利用者の側の失敗も含めて、全体の荒れ具合を見る | 自動のアクセスや、499の増減で大きく動く |
| 成功した要求の割合（200番台） | 「使えた」要求の割合を、そのまま見る | 転送（300番台）や、取り消しが、失敗に入る |
| 画面の完了数 | ログインや購入が、実際にできたかを見る | 画面のない要求（APIなど）は見えない |
Googleのサービス運営の手引きは、サーバー側の例について「5XX responses count against SLO, while all other requests are considered successful.」（訳: 5XXの応答は目標に対してマイナスと数え、ほかの要求はすべて成功と見なす）と書いている。この例の数え方では、499は成功の側に入る。ただし、これはその手引きの例の数え方であって、すべてのサービスにこの数え方を求める文ではない。どの数え方を選んだかを、報告に書いておくことが、あとから読み返す人を助ける。
499を別の指標として持つ
エラー率から外した499は、別の指標にして、時間の動きを見る。499の件数と、全体に占める割合と、応答時間の遅いURLの上位を、月次の表に並べる。変更の後は499が増えうるので、別の行を持っておくことが、定義を変える日の準備になる。
利用者の側から、外から開いて確かめる
サイトの外から主なページを開き、表示できるかを定期的に記録する方法もある。当サイトの無料ツール🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールは、ページを撮影して、画面の見え方を残すのに使える。ただし、撮った時点の画面の記録で、サーバーの監視ではない。
表示の遅さを、先に測っておく
499の一部が、サーバーが遅くて利用者が離れた分だとすると、表示の速さそのものも、手がかりになる。当サイトの無料ツール🔧 Lighthouse監査・チェックツール — 最大3ページまとめて表示の速さを測る（利用には無料の会員登録が必要です）は、主なページ3つの表示の速さを測る。サーバーの応答時間とは別の数字である。
自社のログを、手元で読む
ログの中身を、実際に開いて確かめたいときは、当サイトの無料ツール🔧 IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール — サーバーのアクセスログを、手元で読む手がかりにする（要ログイン）が使える。ただし、攻撃の兆候を探すためのツールで、499の集計のためのものではない。ログの形を知る入口にする。
07 当サイトで確かめたこと
当サイトは、Cloudflareを使っていない
当サイト（WEBサイトサポート）は、Cloudflareを使っていない。2026年10月15日に、トップページの応答のヘッダーを確かめたところ、CloudflareのCDNを通ると付く「cf-ray」のヘッダーは付いていなかった。今回の変更は、当サイトの記録には入らない。この記事の型でいうと、🅳 型Dである。
同じ1週間のログを、3通りの定義で数えた
ただ、定義で数字が動くことは、当サイトの記録でも確かめられる。当サイトのHTTPSのアクセスの記録の、2026年10月8日から14日の34,607行を、ステータスの最初の数字で分けて数えた。内訳は、200番台が25,318行、300番台が64行、400番台が9,217行、500番台が8行である。
| 数え方 | 式 | 結果 |
|---|---|---|
| 500番台だけをエラー | 8 ÷ 34,607 | 0.023% |
| 400番台以上をすべてエラー | (9,217 + 8) ÷ 34,607 | 26.7% |
| 200番台以外をすべて失敗 | (34,607 − 25,318) ÷ 34,607 | 26.8% |
同じ記録、同じ7日間でも、エラー率は、0.023%から26.8%まで動く。400番台のうち、404は237行で、ほかの400番台が8,980行である。内訳の詳しい説明は、ここでは書かない。この記録には、自動のアクセスも含まれる。この数字は当サイトの例であって、他のサイトの目安ではない。数えたのはHTTPSの記録で、10月15日の途中までの記録は入れていない。
08 このテーマの、これまで
日付つきの記録
- 2022年6月: HTTP/3の規格（RFC 9114）が出た。
- 2025年9月15日: IANAのHTTPステータスコードの登録簿の最終更新。452から499は未割り当てである。
- 2026年6月16日: Cloudflareの499の説明ページの最終更新。
- 2026年9月14日: Cloudflareのログの項目（HTTP requests）の説明の最終更新。
- 2026年10月9日: Cloudflareが、HTTP/3で利用者が取り消した通信の扱いと記録の改善を、更新履歴に載せた。
- 2026年10月15日: この記事の確認の日。
変更がいつから全体に行き渡ったかは、更新履歴が書いていないので、確かめていない。499の説明ページは、変更より前の日付で、変更に触れていない。
当サイトの、関連する過去の記事
記録の数え方を、これまでも当サイトで取り上げてきた。当サイトの記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」は、見ている記録の範囲で、数字が33倍違った例である。当サイトの記事「同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったこと」は、数字を並べる前に条件をそろえる話である。当サイトの記事「「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提」は、数字の前提を確かめる話である。
自動のアクセスの割合を、自社のログで数え直した話は、当サイトの記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」に書いた。参照元の数え方は、当サイトの記事「外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった」に書いた。
現在の貴方のIPアドレス
このサイトで書いている人
