AI の応答に、ほかの客のデータが混ざった：Workers AI の KV キャッシュの事故

Cloudflare は 10 月 26 日、Workers AI で動かしていた GLM-5.3（@cf/zai-org/glm-5.3）の一部の応答に、ほかの顧客のリクエストのデータが混ざっていたと公表しました。

何が起きたか

• 期間：2026 年 8 月 27 日から 9 月 9 日
• 影響：155 の応答、「少数の顧客」。プロンプトが 68 万 1,280 トークンを超えた場合だけ
• 混ざった物：ほかの顧客のプロンプトと、生成の途中の一部
• わざと悪用された形跡はなく、Workers AI のほかのモデルには影響がない

原因

GLM-5.3 は、入力を読む段階（プリフィル）と、文字を書き出す段階（デコード）を別の機械に分ける作りで、SGLang（LLM を動かすオープンソースの仕組み）の上で動いていました。

1. 文脈の長さは 104 万 8,576 トークンなのに、プリフィルの KV キャッシュ（読んだ文脈の計算の結果）の置き場は 68 万 1,280 トークンしかなく、2 つの値を照らし合わせていなかった。
2. SGLang の不具合で、長すぎる要求は 1 トークンの仮の値を付けて「拒否」とされたが、キューは「完了」かどうかだけを見ていたため、KV の転送が続いた。デコードの側は、前の要求の古いページを読み、HTTP 200 で答えを返した。

Cloudflare は「ページは要求の間で消されていない。次の要求がページを上書きするだけだ」と説明しています。

対応の速さ（UTC）

SGLang は、v0.5.21（10 月 2 日）と v0.5.22（10 月 19 日）で修正を入れています。

直し方

• プリフィルの置き場を、文脈の長さの 2 倍（約 204 万トークン）に広げる。
• 長すぎる要求は、受け付けの時点で拒否する。
• 転送の大きさを確かめ、転送ごとにチェックサムを付ける。
• KV のページを手放す時期を遅らせ、転送の束の大きさに上限を付ける。

作り手にとっての意味

いちばん重いのは、Cloudflare 自身のこの反省です。「長い文脈では、HTTP の応答の番号とエンジンの性能だけを確かめ、モデルの出力と筋の通り方を確かめていなかった（we only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence.）」。

AI を動かす仕組みは、壊れてもエラーを返さず、もっともらしい文章を返すことがあります。設定の値は動いている仕組みから測ること、迷ったら止める（fail closed）こと、そして出力の中身を試験すること。自分でモデルを動かす人も、API を使う人も、同じ教訓が当てはまります。