Cloudflare、GLM-5.3の情報露出と修正を報告

特定モデルでの情報露出を報告

Cloudflareは2026年10月26日、Workers AIで提供するGLM-5.3に、別の利用者のリクエスト内容が応答へ混入する問題があったと公表しました。対象期間は8月27日から9月9日で、同社は9月9日に修正してサービスを再開したと説明しています。他のWorkers AIモデルは影響を受けていないと確認したうえで、原因と再発防止策を公開しています。

対象範囲と調査結果を読む

報告では、設定上のキャッシュ容量と長い入力の処理に関する推論エンジンの不具合が重なったとされています。68万1,280トークンを超える入力への155件の応答が対象で、意図的な悪用の証拠は見つからなかったとしています。これは提供元の調査結果であり、悪用が絶対になかったという保証とは区別が必要です。修正済みの事案を、現在も全モデルに続く問題と広げて読むべきではありません。

自社の利用範囲と照合

実務での見方として、この報告は「AIサービスを使ったか」だけでなく、どの提供元の、どのモデルを、いつ利用したかを追える状態にしておく必要性を示します。まず該当期間の利用記録とモデル名を照合し、対象外ならその根拠を残す、対象なら入力した情報の分類と提供元からの通知を確認する、という順序が考えられます。個別の影響を調べずに、一律に安全または危険と結論づけないことが大切です。

応答内容と上限付近を検証する

AIを自社サービスへ組み込むチームは、通信が成功したことと、返答の内容が正しいことを別々に確かめたいところです。検証では、長い入力、処理上限に近い入力、中断や失敗を伴う入力などを用意し、期待した内容が返るかを見ます。ただし実利用者の秘密情報を試験データとして流し込むのではなく、管理されたテスト用の識別文字列などで境界を確かめる設計が適しています。

利用台帳と対応手順を整える

利用部門側でも、入力してよい情報、保存するログ、保存期間、事故時の連絡先を一覧にしておくと対応を始めやすくなります。モデルの更新や切り替えを行うときは、品質だけでなくデータの扱いに関する確認項目も引き継ぎます。今回の報告をきっかけに行うべきなのは、すべてのAI利用を同じリスクと見ることではなく、自社の利用範囲を確認できる台帳と、問題が起きた際に動ける手順を整えることです。社内の窓口がモデル名や利用期間をすぐ確認できるか、机上で一度たどるだけでも、台帳に足りない項目を見つける手がかりになります。