クラウド・インフラ

エラーもログも出ない破損——推論エンジンの内部を、マルチテナント境界として扱ってよいか

イーランサー・ジャパン株式会社
この記事の要点

Cloudflareは、生成AIサービスWorkers AIのGLM-5.3が、他の顧客のリクエスト内容を含む応答を155件返していたと公表しました。2026年8月27日から9月9日の13日間で、影響はすべて681,280トークンを超える長い入力でした。入力の上限設定は1,048,576トークンなのに、処理の途中経過を置く領域は681,280トークン分しかなかったことが原因です。この破損はエラーもログも出さず正常な応答として返るため、起きたかどうかを運用側で判別できません。

用語の説明
  • トークン/AIが文章を処理するときの細かい単位です。日本語ではおおむね1文字から数文字にあたります。
  • リクエスト/利用者がAIに送る、1回分の問いかけや処理の依頼のことです。
  • ログ/いつ何が起きたかを、システムが自動で書き残していく記録のことです。

「155件の情報漏洩」という見出しだけが流通すると、PD分離を使っている現場が自分の構成を点検する動機が残りません。この件でいちばん重いのは件数ではなく検知性です。この破損はエラーもログ行も出さず、HTTP 200のまま他人の内容を返します。発生したかどうかを運用側で判別できない、という性質の問題です。

要点

何が起きたか

報告者はKnosticのGadi Evron氏。2026年9月8日23時11分(UTC)にCloudflareのHackerOne経由で届きました。

他のWorkers AIモデルに影響はなく、意図的な悪用の形跡も確認されていないとされています。

構成はこうです。Workers AIはGLM-5.3をSGLangで動かし、プレフィルとデコードを別GPUプールに分け、両者間のKV転送をRDMAで行う。

ここに落とし穴がありました。SGLangのプール容量は、重みをロードした後に残ったGPUメモリから決まり、設定したコンテキスト長とは独立です。宣言値とプール容量が自動で揃うことはありません。

Cloudflareはこの不一致を提供開始前から把握しており、テストでHTTP成功応答が返ったためエンジン側が安全に処理すると判断した、と書いています。事後にプールは約204万トークンへ拡張されました。設定コンテキスト長を上回る値です。

KVキャッシュのページはゼロクリアされない

ここが構造の核です。

KVキャッシュのページは、リクエスト間で初期化されません。エンジンは、ページの所有権追跡が正しいことを前提に動いています。

メモリアロケータと同じ構造です。所有権の記録が1か所ずれれば、前の住人のデータがそのまま読める。

そこから立つ問いは1つです。推論エンジンの内部を、マルチテナント境界として扱ってよいか。

失敗経路の形

素の形は、容量超過のケースで理解できます。

  1. プロンプトが受け入れ上限を超えると、プレフィル側は中断する
  2. ところがリクエストはそのままプレフィルキューを通過する
  3. 転送されるKVは1トークン分だけ
  4. デコード側は全長分の領域を確保済みで、初期化されていないキャッシュから生成を始める

ただし、より一般的な説明はこうです。中断の原因は容量超過に限りません。クライアント切断、入口での拒否、転送障害でも起きます。

  1. 転送の途中でリクエストが中断される
  2. デコード側はスロットを即座に解放する
  3. しかしリモートの書き込み側はまだそこへ書ける
  4. アロケータがそのスロットを別リクエストへ割り当てる
  5. 遅れて届いた書き込みが、そのリクエストのKVキャッシュに着地する

根にあるのはRDMAの性質です。いったん投入した作業はキャンセルできず、片側書き込みは受信側に完了通知を出さない。

そしてコンテキストが長いほど飛行中の書き込みが増え、窓が広がります。影響がすべて681,280トークン超に出たのは、このためです。

対策は「解放の遅延」に集約される

修正の方向は一貫しています。中断したリクエストのスロットを、全ランクから中断確認が返るかタイムアウトするまで保持する。即座に解放しないことで、着弾の窓を閉じます。

入口側の対策も入りました。受付時点で、割り当てや転送が始まる前に大きすぎるリクエストを拒否する。中断そのものを発生させない方向です。

さらに整合性検査として、KV転送のチェックサムがオプションで追加されています。

本記事では、具体的なフラグ名・環境変数名・メトリクス名・PR番号までは独立に確認できていません。チェックサムやKVカナリアを有効化する際は、SGLangのリリースノートで自分が使うバージョンのオプション名を必ずご確認ください。誤ったフラグ名は無効になるだけで、有効化されたと誤認する危険があります。

検知できないことが、いちばん重い

改めて強調します。この破損はエラーを出しません。

つまり発生したかどうかを運用側で判別できない。今回も、外部の研究者が報告するまで13日間気づかれていません。

監視設計への含意は明確です。「エラーが出ていないこと」は、テナント分離が効いている証拠にならない。別経路の検証——チェックサム、カナリア、出力内容の統計的な監視——が要ります。

日本語で流通している部分と、していない部分

事実関係は日本語でも報じられています(GIGAZINE、2026年10月28日)。

流通していないのは、「設定ミス1件」なのか「エンジンの構造的な競合」なのかという判別です。

一次ソースが2本に割れているためです。事業者側は自社の設定不一致とインシデント対応を、エンジン側は競合の構造とPR十数本を書いており、両方を読まないと判断できません。

「155件」だけが流通すると、PD分離を使っている現場が自分の構成を点検する動機が残りません。実際にはデフォルトのPD構成を使っていた範囲が広く影響対象です。

エンジニアにとって何が変わるか

①設計

PD分離でSGLangを回しているなら、今日の作業です。

  1. 推奨ベースラインのバージョンへ上げる(Cloudflareはv0.5.22を挙げている)
  2. 宣言したコンテキスト長が、プレフィルのKVプールに収まるかを起動時に機械で照合する。Cloudflareは事後にこの事前チェックを入れた
  3. 中断時のKVスロット解放遅延を有効にする
  4. KV転送のチェックサムを検討する(整合性検査としてオプション提供されている)

2番目が最も汎用的です。設定値とリソース実体が自動で揃わない箇所は、起動時に突き合わせる。これはPD分離に限らない原則で、今回の根本原因はまさにここでした。

②調達

テナント分離は、自分で検証できない相手側の性質です。しかもこの破損はエラーを出さない。質問項目が増えます。

「SGLangやvLLMを使っているか」ではなく、「どのバージョンで、どの既定値か」が判断材料になりました。

③キャリア

推論エンジン内部、RDMA転送のセマンティクス、マルチテナント境界の設計。この3つが並ぶ職能は、推論基盤を自前で持つ組織で希少性が上がります。

モデルを使える人ではなく、ページアロケータと中断確認の経路を読める側です。

確認できなかった点

出典

本記事は2026年10月27日時点で公開された情報に基づき、主要な事実関係は2026年10月29日に第三者報道で照合しています。運用手順にあたる部分(フラグ名、環境変数、メトリクス名)は独立確認ができていないため具体名を避けています。適用にあたっては、お使いのバージョンの公式リリースノートを必ずご確認ください。

CONSULTATION

案件をお探しの方へ

イーランサーでは、専任担当がご経歴と希望条件を整理したうえで案件をご提案し、条件面の調整もお手伝いしています。すぐに稼働できる状態でなくても、情報収集としてご相談いただけます。

ご登録いただいた情報が企業に公開されることはありません。氏名・連絡先を伏せたスキルシートを使用します。登録から案件のご紹介、契約手続きまで費用は一切かかりません。

案件を見る
案件をお探しの方 人材をお探しの方