Workers AIで他人のデータ混入、原因と対応【2026年10月】

2026年10月26日、Cloudflare は公式ブログで、AI 推論サービス「Workers AI」の GLM-5.3 モデルで、ある利用者への応答に別の利用者のリクエストのデータが混ざっていたと報告しました。期間は2026年8月27日〜9月9日、影響した応答は155件です。

Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang

原因は Cloudflare 側の設定ミスと、推論エンジン「SGLang」のバグが重なったことでした。問題はすでに修正され、ほかのモデルに影響はなかったとされています。共有の GPU で動く AI API でも、利用者どうしのデータが混ざりうる——そのことを事業者自身が具体的に示した報告、という位置づけです。

Workers AIのGLM-5.3で何が起きた？一言でまとめると

一言でいうと、とても長いプロンプトを送ると、少し前に別の利用者が送ったリクエストの中身が応答に混ざることがあったという問題です。

GLM-5.3 は、Z.ai が開発したエージェント型のコーディング向けモデルです。Workers AI では最大1,048,576トークン（約100万）の長い入力を扱えるのが特徴で、Changelog では2026年8月28日付で提供開始が告知されています。

Workers AI の料金は、入力100万トークンあたり $1.40、出力 $4.40 です。無料の Workers Free プランでは使えず、Workers Paid などの有料の利用が前提のモデルです。

影響を受けた条件と、混ざった可能性のあるデータ

公式ブログによると、影響を受けたのは681,280トークンを超える長いプロンプトを GLM-5.3 に送った場合です。この条件にあたるすべてのリクエストで同じ動きになった、と説明されています。

混ざったのは、同じ GLM-5.3 に少し前に送られた、他の利用者のリクエストのデータです。仕組みの説明の中では、他の利用者のプロンプトや、生成の途中の内容がメモリに残っていたとされています。

ここで整理しておきたいのは、立場が2つあることです。

• データを受け取ってしまった側：681,280トークンを超えるプロンプトを送った利用者
• データが混ざった側：その直前に、同じモデルへリクエストを送っていた利用者

Cloudflare は、自社と研究者のテストを除くと、該当したリクエストは通常の長文利用と同じような時間帯・量で、繰り返し悪用された形跡はないとしています。また、Workers AI で同じく処理を分けて動かしているほかのモデルはプリフィル・デコードの両方でメモリの枠がコンテキスト長より大きく、この状態に入りえなかったため、影響したのは GLM-5.3 だけと確認したとのことです。

なぜ起きた？原因は2つ

前提として、KV キャッシュは、LLM がプロンプトを読んだ結果を GPU のメモリに一時的に置いておく仕組みです。Cloudflare の環境では、このメモリは決まった大きさの「ページ」に分けて多くのリクエストで使い回され、リクエストが終わってもゼロクリアはせず、次のリクエストが上書きする方式でした。性能のために一般的なやり方だ、と説明されています。

① Cloudflare の設定ミス

GLM-5.3 は1,048,576トークンのコンテキストで公開されていましたが、プロンプトを処理する側（プリフィル）の KV キャッシュの枠は681,280トークン分しかありませんでした。

Cloudflare はこのずれをローンチ前から把握していたと認めています。収まらないプロンプトはエンジンがエラーを返すと考えており、長文のテストでも成功の応答が返ったため、問題ないと判断していたとのことです。テストでは HTTP のステータスや性能だけを見て、出力の中身までは確かめていなかった点を、テストの欠落として挙げています。

② SGLang のバグ

Workers AI は GLM-5.3 を、オープンソースの推論エンジン SGLang で動かしています。プロンプトを読む GPU（プリフィル）と、応答を生成する GPU（デコード）を分けた構成です。

枠に収まらないプロンプトは、内部では「拒否」と記録され、1トークンだけの代わりの入力に差し替えられて処理が進んでいました。1台で動かす構成ならそのままエラーが返りますが、分けた構成では次のことが起きていました。

1. デコード側は、元の長いプロンプトの分だけメモリのページを確保する
2. プリフィル側は、1トークン分のデータだけを送って「転送完了」を伝える
3. デコード側は、以前のリクエストのデータが残ったページも含めて読み、応答を生成する

その結果、利用者には本来のエラー（HTTP 400）ではなく成功（HTTP 200）が返り、応答の文章も自然に読める形でした。ただし中身には、他の利用者のデータが混ざっていた、ということです。

Cloudflareの対応と時系列

報告を受けてから、モデルの停止・修正・再開までを1日で終えています。公式ブログの時系列（UTC）に、日本時間を添えると次のとおりです。

なお、Cloudflare のステータスページでは、9月9日の件は「Workers AI のエラー増加（GLM 5.3）」として掲載されていました。データの混入という中身が公式に説明されたのは、10月26日のブログが初めてです。

再発防止とSGLangの修正

Cloudflare は、同じことが起きないように設定とエンジンの両方を直しています。

① メモリの枠をコンテキスト長より大きく

GLM-5.3 の設定を GLM-5.2 と同じ形にそろえ、プリフィルの KV キャッシュの枠を約204万トークン（コンテキスト長の約2倍）に広げました。コンテキストに収まるプロンプトは必ず枠にも収まるので、それだけでこのバグは起きなくなる、としています。

② エンジン側でも拒否を正しく扱う

枠の大きさだけに頼るのは危ういとして、拒否されたリクエストは、データの転送などが始まる前に元のエラーで終わらせるパッチをエンジンに当てました。同じ考え方の修正は SGLang 本体にも取り込まれています。

③ 全モデルへの適用とデプロイ前のチェック

このエンジンの修正と追加の強化は、SGLang で動かしているすべてのモデルに適用済みです。今後の展開でも、KV キャッシュの枠とコンテキスト長を、動いているエンジンから直接確かめるチェックを必須にしたとしています。

SGLang 側では、この件の修正が v0.5.20 で公開され、v0.5.21（10月2日）・v0.5.22（10月19日）で追加の修正が入りました。

利用者がやること：公式が示していること

2026年10月28日時点の公式ブログでは、Workers AI の利用者に向けて「何かをしてください」という指示は書かれていません。問題は9月9日に修正され、ほかのモデルには影響がなかった、という説明です。

また、ブログには、影響を受けた顧客に個別の連絡をしたかどうかについての記述もありません。

公式に示されている行動は、次の2つです。

• SGLang を自分で動かしている事業者：プリフィルとデコードを分けた構成なら、v0.5.22 以降への更新、各ノードで KV キャッシュの枠とコンテキスト長を比べることなどを強く推奨
• Workers AI でセキュリティ上の問題を見つけた人：hackerone.com/cloudflare から報告する

SGLang についての推奨は、SGLang を自分で運用している事業者に向けたものです。自社で GPU サーバーを用意して SGLang でモデルを動かしている場合は、上の推奨が直接あてはまります。

国内の GPU でモデルを動かす選択肢としては、さくらインターネットが専有型の AI 推論サービスを始めています。

あわせて読みたい

さくらのAI Engineに専有型、自社モデルを国内GPUで定額運用【2026年10月】

開発者の反応

Hacker News では、この報告に178ポイント・78件のコメント（2026年10月28日時点）が付きました（出典）。

報告の書き方を評価する声があります。ユーザーの kami23 氏は、テストで見逃した理由まで明確に説明している点や、モデルをすぐ止めた対応の速さを評価しています（出典）。

一方で、ずれを知りながら公開した判断には厳しい意見が目立ちます。ComputerGuru 氏は「エラーを予想していたのに成功が返ったなら、むしろ調べるべきでは」と疑問を投げかけています（出典）。

混ざったデータの中身を心配する声もあります。alxsm 氏は、100万トークンのモデルにはリポジトリや設定ファイルごと貼る使い方も多く、API キーが含まれていた可能性もあると指摘し、データが混ざった側の顧客に通知したかが書かれていない点を挙げています（出典）。

タイトルにモデル名を入れたことには「モデルのせいに見える」との指摘もありました。Cloudflare 側の立場で答えたユーザーの kflansburg 氏は、どのエンドポイントが影響を受けたかを顧客が知る必要があるためだと説明しています（出典）。

IT Picks的な所感

今回の件で重いのは、エラーにならず、自然な文章の応答が返ってきていた点だと思います。利用者の側からは、異常に気づく手がかりがほとんどありません。共有の GPU で動く AI API では、利用者どうしのデータの分離を事業者の実装に頼るしかない——その前提を、改めて意識させる出来事です。

一方で、Cloudflare がずれを把握していたことや、テストの抜けまで含めて詳しく公開したことは評価できます。研究者の報告から約1日で停止・修正・再開し、SGLang の修正にも協力しているので、ほかの推論サービスや自前で SGLang を使う人にも役立つ報告になっています。

ただ、データが混ざった側への連絡については公式ブログからは分かりません。長いプロンプトに機密情報を含めて使っていた利用者にとっては、ここが一番知りたい点のはずで、追加の説明を待ちたいところです。

Cloudflare は10月に Deno のチーム合流も発表しており、開発者向けプラットフォームの動きが続いています。

あわせて読みたい

Deno Deploy終了へ、DenoがCloudflareに合流【2026年10月】

まとめ

Workers AI の GLM-5.3 で起きたデータ混入のポイントをまとめます。

• 発表：2026年10月26日（Cloudflare 公式ブログ、SGLang と協調公表）
• 対象：Workers AI の GLM-5.3（@cf/zai-org/glm-5.3）のみ
• 期間：2026年8月27日〜9月9日（UTC）
• 条件：681,280トークンを超えるプロンプト
• 影響：155件の応答に、直前の他の利用者のリクエストのデータが混入
• 悪用：意図的な悪用の証拠はなし
• 原因：KV キャッシュの枠がコンテキスト長より小さい設定と、SGLang のバグ
• 対応：9月9日に停止・修正・再開。全モデルにエンジン修正を適用
• 利用者向けの指示：公式ブログには記載なし（SGLang の運用者は v0.5.22 以降を推奨）

Workers AI を使っている人は、まず公式ブログの本文で影響の条件を確認し、自分の使い方が当てはまるかを見ておくのがおすすめです。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。