答えに他人の入力が混ざるとき──Cloudflareが公表した事故（影響155件）と、使う側の備え

2026年10月28日 00:05

はじめに

会社でAIサービスを使うとき、入力した資料が、別の利用者への回答に混ざることを想定している人はいないでしょう。ところがCloudflareは2026年10月26日、Workers AIで、ある利用者への応答に別の利用者の入力由来のデータが混ざった事故を公表しました。

この話を「AIは危ない」で終わらせても、次に何を決めればよいかは分かりません。Cloudflareの報告に書かれている範囲と、書かれていない範囲を分けたうえで、外部のAIサービスを使う会社が確かめておきたいことを考えます。

1. Cloudflareの報告で、何が起きたのか

1-1. 155件の応答に、別の利用者の入力由来のデータが混ざった

Cloudflareの報告によると、2026年8月27日〜9月9日、Workers AIで提供していたGLM-5.3の応答155件に、別の利用者の入力由来のデータが含まれました。データが混ざったのは、681,280トークン（AIが文章を数える単位）を超える、非常に長い入力への応答です。混ざったデータの元は、少し前に同じモデルを使った別の利用者の入力です。同社は、Workers AIでホストしていた他のモデルには影響がなかったとしています。

発見のきっかけは、KnosticのGadi Evron氏が9月8日にHackerOne経由で送った報告でした。Cloudflareによると、翌9月9日に再現し、GLM-5.3を停止して設定とAIを動かすソフトを修正し、同日に再開しました。Cloudflareは調査の結果として「意図的な悪用の証拠は見つからなかった」としています。いずれも同社の自己報告として読みます。

図1　事故の時系列。見つかるまで約2週間、修正から公表まで約7週間。影響を受けた利用者への個別の連絡があったかは、報告には書かれていない。 — 図1　事故の時系列
見つかるまで約2週間、修正から公表まで約7週間
影響を受けた利用者への個別の連絡があったかは、報告には書かれていない

出典: Cloudflareの報告／Knosticの研究者側の報告（9月24日、Cloudflareから修正済みと連絡を受けたという記述）。日付は報告の表記による。

2. 設備を分け合うAIサービスで、何が崩れたのか

2-1. 片付けずに書類をさばく窓口

AIの計算機を、書類を次々にさばく窓口にたとえてみます。窓口では速さを優先して、前の人の書類を片付けず、次の人の書類をその上に広げて読みます。ふだんはそれで困りません。Cloudflareも、こうした使い回しは一般的で、速さのために必要だと説明しています。

今回は、机に載りきらないほどの書類が来ました。本来は「無理です」と断るところを、受けてしまいました。机には前の人たちの書類も出たままになり、担当者はそれもこの人の分として読んで、答えを書きました。

さばききれない量の書類を断らずに受けたことが混ざった原因だと、Cloudflareの説明からうかがえます。

2-2. 設定の食い違いと、見えていなかった不具合が重なった

Cloudflareは原因を二つの重なりとして説明しています。一つは設定の食い違いです。モデルが受け付ける長さが、一度に置いておける量より大きくなっていました。同社はこの食い違いを提供開始前から把握していましたが、入りきらない入力にはエラーが返ると考えていました。長い入力のテストでも、応答が返るか、性能が出るかは見ていましたが、出力の中身は確認していなかったとしています。

もう一つは、オープンソースのAIを動かすソフトSGLangの不具合です。Cloudflareによると、この不具合そのものは2026年7月6日に別の利用者が開発元へ報告済みで、同社は今回の調査の途中でその報告に気づきました。同社は修正案を開発元へ提案し、関連する修正の大半はSGLang本体のv0.5.22までに取り込まれたと説明しています。同じ部品を使う事業者には、v0.5.22以降への更新を勧めています。

3. 事故報告は「書いてあること」と「書いていないこと」を分けて読む

3-1. 範囲、原因、対応、時系列は報告に書かれている

今回の報告には、影響した期間、155件という応答数、長い入力という条件、原因の説明、停止から再開までの時系列、修正の内容が書かれています。サービス提供者がここまでをどう調べ、どう対応したと説明しているかは、使う側が次の判断をする材料になります。

Cloudflareの時系列では、9月8日の報告から10月26日の公表までに時間がありました。同社は、研究者とSGLangの開発元との公表時期をそろえたと説明しています。

3-2. 個別連絡・混ざった中身・影響利用者数は書かれていない

Cloudflareの報告には、影響を受けた利用者への個別連絡の有無は書かれていません。影響を受けた利用者については「少数」とだけ書かれ、人数は示されていません。他の利用者の入力や生成途中の文章が混ざったという種類は説明されていますが、具体的な中身も書かれていません。これは「個別連絡がなかった」ことを意味しません。

事故のニュースに触れたときは、件数だけを見て結論を急がないほうがよいでしょう。誰の報告なのか、対象は何か、何を調べたと書かれているか。そして、利用者に関わる情報のうち何が書かれていないか。この順で読むと、自社が提供元へ確認すべき点も見えやすくなります。

4. AIを使う会社が、いま確かめる二つの問い

使う側から見れば、今回の事故は、自社が入力した情報が別の利用者への答えとして外に出る、情報漏えいの一つの形です。自社の情報が出た側は、手元の記録からは気づきにくく、提供元の報告や連絡で知ることになりそうです。Cloudflareの報告には、データが出た側・受け取った側のどちらへの個別の連絡も書かれていません。入力に個人情報や取引先から預かった秘密が含まれていれば、その相手への説明や対応が必要になることもありえます。

今回は、長い入力を送った側が、他人の情報が混ざった答えを受け取りました。受け取った側には、その答えを社内資料や顧客への回答にそのまま使ってしまうおそれもあります。一方、自社の情報が他人への答えに出るほうは、自社の入力を短くするだけでは防げません。だからこそ、入れる情報と、提供元との約束を確かめておく必要があります。

4-1. 何を入力してよいことにしているか

最初の問いは、「このサービスに、どの種類の情報まで入れてよいか」です。個人情報、未公表の資料、取引先から預かった情報など、入力する情報の種類を分けます。そのうえで、契約上の約束や社内のルールを踏まえ、それぞれを入力してよいか判断します。

AI事業者ガイドライン第1.2版は、AI利用者にとって、個人情報や機密情報を不適切に入力しないよう注意を払うこと、提供者から受け取った文書を保管・活用し、サービス規約を守ることを重要な事項として挙げています。個人情報保護委員会も2023年の注意喚起で、一般の利用者は利用規約やプライバシーポリシーを確認し、入力する情報を踏まえて利用を判断するよう示しています。

4-2. 事故が起きたとき、提供元は何を知らせる約束か

次は、「事故が起きたとき、自社の契約では何を、いつ知らせてもらえるのか」です。これは一般論ではなく、実際に結んでいる契約、利用規約、管理画面の通知設定で確かめる問いです。

CloudflareのData usageページは、2026年10月27日時点で、保存を伴う機能を使わない通常の推論では、入力と出力を保持せず、学習にも他の顧客への提供にも使わないと説明しています。ただし、同社のデータ処理契約（DPA）にある事故通知の約束は、個人データの侵害が対象です。今回の155件に個人データが含まれたか、どの利用者にどの契約が適用されるかは、Cloudflareの報告には書かれていません。

利用中のAI、用途、入力する情報の種類、契約した人を並べて確認することから始めましょう。AIに仕事を任せる前の権限管理と監査ログについては、以前の記事『AIに仕事を任せる前に──これから必須になる「権限管理」と監査ログ』でも取り上げました。

5. 分け合う仕組みの正しさが、サービスの信頼になる

ここからは私の見立てです。AIを速く、利用しやすい価格で提供するには、計算機やソフトウェアを多くの利用者で分け合う場面が増えます。利用者ごとの入力や処理を正しく分ける技術は、使う側にとっては、サービスを選び続けられるかどうかに関わる商品の一部です。

ですから、サービスを選ぶときは、性能や料金だけでなく、事故が起きたときに何を公表し、どう直す提供者なのかを見ておきたいところです。

おわりに

今回の報告を見たら、まず自社が対象のサービスとモデルを使っていたか、影響を受けた可能性があるかを提供元に確かめます。入力してよい情報と、提供元から受ける連絡を前もって確かめておけば、事故の知らせを自社の運用を見直すきっかけにできます。

参考リンク

※本記事は、2026年10月27日時点で公開されている情報をもとにしています。