Cloudflare D1 の無料枠が本日から強制適用 — 告知と発効が同日なので、読んだ時点でもう効いている

要約

2026-09-01、Cloudflare の changelog に 「D1 enforces free tier daily query limits」 が掲載されました。

内容は単純です。本日から、Workers Free プランの D1 クエリは、1日あたりの行読み取り / 行書き込み上限を超えた時点で失敗します。

これまでは、上限を超えても動作していました。 上限は定義されていましたが、超過が実際にクエリを止めることはなかった。 今日から、それが変わりました。

対象は Workers Binding API と REST API の両方です。 どちらの経路から叩いても止まります。

上限に達すると、次のいずれかのエラーが返ります。

• Your account has exceeded D1's free tier daily row read limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.
• Your account has exceeded D1's free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.

エラーメッセージが読み取りと書き込みで分かれているのは親切な設計です。 どちらの上限に達したかが、メッセージだけでわかります。

リセットは UTC 深夜0時。日本時間では朝9時です。

保存済みのデータは影響を受けません。 読み書きが止まるだけで、データが消えるわけではない。 ここは安心してよい部分です。

上限到達時にはメールアラートが送られます。

公式が推奨する対処は2段階です。 まず強制適用の前にクエリ活動を点検し、上限を超えうるクエリを特定する。 行読み取りを減らすには、テーブルへのインデックス追加と、フルテーブルスキャンを行うクエリの見直し。 最適化しても足りない場合は Workers Paid プランへ移行する。

ただし、ここに構造的な問題があります。

この告知は 2026-09-01 付で、適用開始も 2026-09-01 です。

「強制適用の前に点検してください」と書かれていますが、告知を読んだ時点ですでに適用されています。 事前点検を促す文面と、告知のタイミングが噛み合っていません。

したがって、無料枠で D1 を使っている環境は、いま現在すでに止まりうる状態にあります。

何が変わったか

• 2026-09-01 から、Workers Free プランの D1 クエリが日次の行読み取り / 行書き込み上限超過で失敗するようになった
• 対象は Workers Binding API と REST API の両方
• 上限到達時のエラーは読み取り用と書き込み用で分かれている（どちらに達したか判別可能）
• リセットは UTC 深夜0時（日本時間 09:00）
• 保存済みデータは無影響。 読み書きが止まるだけ
• 上限到達時にメールアラートが送られる
• 公式推奨の対処: インデックス追加とフルテーブルスキャンを行うクエリの見直し。それでも足りなければ Workers Paid へ
• 告知日と発効日が同じ 2026-09-01。 事前点検を促す文面だが、読んだ時点で適用済み
• Workers Paid プランは対象外

業務インパクト（一般企業向け）

まず、対象を確認してください。Workers Free プランで D1 を使っている環境です。

「うちは本番は Paid だから関係ない」で終わらせないでください。 実務で無料枠が使われているのは、たいてい次のような場所です。

検証環境。プロトタイプ。社内ツール。個人の実験用アカウントで動いている、いつの間にか業務で使われているもの。 ——この最後のパターンが、いちばん厄介です。

**「誰かが試しに作ったものが、気づいたら業務で使われている」**という状況は、多くの組織にあります。そういう環境は、たいてい無料枠で動いていて、監視もされていません。 止まって初めて存在が認識される。

次に、失敗の現れ方を理解してください。

保存データは無事で、読み書きだけが止まります。 これは「壊れた」のではなく「一時的に使えない」状態です。そして UTC 0時（日本時間 朝9時）にリセットされます。

つまり、症状はこうなります。夕方から夜にかけて動かなくなり、翌朝9時に勝手に直る。

この挙動は、原因の切り分けを難しくします。 「夜になると動かないが朝には直る」という現象を、上限超過だと最初から疑える人は多くありません。 ネットワーク、キャッシュ、時間帯による負荷——いろいろな仮説が先に出ます。

だからこそ、エラーメッセージを読むことが重要です。 D1 のエラーメッセージには 「exceeded D1’s free tier daily row read limit」 とはっきり書かれています。メッセージを見れば一発でわかる。 問題は、アプリケーションがエラーメッセージを握り潰していると見えないことです。

やるべきことを3つ挙げます。

1つ目、無料枠で D1 を使っている環境の棚卸し。 どこで、誰が、何のために使っているか。これは今日やる価値があります。すでに適用されているからです。

2つ目、エラーメッセージのログ出力の確認。 D1 のクエリエラーが、メッセージ本文まで含めてログに残っているか。 「DB エラー」とだけ記録する実装では、原因にたどり着けません。

3つ目、メールアラートの宛先確認。 上限到達時にメールが来ますが、それが届く先が退職者のアドレスや、誰も見ていない共有メールボックスでは意味がありません。 無料枠のアカウントは、この種の管理が緩くなりがちです。

そして、この告知の出し方自体が教訓です。

告知と発効が同日というのは、準備期間が実質ゼロということです。「事前に点検してください」という推奨と、告知タイミングが矛盾している。

依存しているサービスの changelog を、誰も見ていない組織は多い。 そして見ていなくても、変更は適用されます。 Cloudflare のような広範なプラットフォームを使っているなら、changelog の購読は運用業務の一部として扱うべきです。 RSS があります。

最適化の実務としては、公式の推奨がそのまま正しい。 インデックスの追加と、フルテーブルスキャンの排除。 行読み取り数は「取得した行数」ではなく「読んだ行数」でカウントされるため、インデックスのないテーブルへのクエリは、返す行が1件でも大量の行読み取りを発生させます。 ここを直すのが、最も効果の大きい対処です。

副業・個人活用視点

個人開発で D1 を使っているなら、これは直接効きます。

無料枠は、個人プロジェクトの基盤としてよく使われます。 副業のツール、ポートフォリオ用のアプリ、クライアントに見せるプロトタイプ——これらが今日から、上限超過で止まりうる状態になりました。

特に注意すべきは、クライアントに見せるデモ環境です。

「デモの最中に落ちる」というのは、最悪のタイミングです。 そして、夜に動かなくなって朝に直るという挙動なので、自分がテストした時間帯には再現しないかもしれません。

やることは3つです。

1つ目、いま動かしているものの棚卸し。 どのプロジェクトが無料枠の D1 を使っているか。放置していて存在を忘れているものが、たいてい1つ2つあります。

2つ目、クエリの見直し。 インデックスがないテーブルへの検索が、行読み取りをいちばん食います。返ってくる行が1件でも、テーブル全体を読んでいれば、その行数がカウントされます。 ここは知っていれば避けられる話で、知らないと気づかない。

WHERE 句で使っている列にインデックスがあるか——これを確認するだけで、消費が桁で変わることがあります。

3つ目、重要なものは Paid へ。 クライアントに見せるもの、収入に関わるものを無料枠で動かし続けるのは、リスクに見合いません。 Workers Paid の費用は、案件1本の価値と比べれば小さい。「無料で動いているから」という理由だけで無料枠に置いているなら、それは判断ではなく惰性です。

そして、この件から学べる一般的な教訓があります。

無料枠は、条件が変わる前提で使うべきです。

今回は「定義されていた上限が、実際に効くようになった」という変更でした。 上限そのものは以前からあった。変わったのは、それを強制するかどうかという運用判断です。

この種の変更は予告なく起きます。 無料枠は事業者の裁量で提供されているもので、利用者に約束された権利ではありません。

したがって、無料枠を使うときの判断基準は「いま無料か」ではなく「止まったときに困るか」です。 困らないなら使えばいい。困るなら、最初から払うべきです。 この線引きを最初にしておけば、こういう変更が来たときに慌てずに済みます。