WEBサイトCloudflareのWorkers AIで、ほかの利用者の入力の一部が応答に混ざった。HTTP 200は返っていた ── 外部のAI機能の棚卸しと、応答の検品を確かめる13項目（2026年10月時点）
CloudflareのWorkers AIで、ほかの利用者の入力の一部が応答に混ざった。HTTP 200は返っていた ── 外部のAI機能の棚卸しと、応答の検品を確かめる13項目（2026年10月時点）
目次
- 01 何が起きたか — 2026年8月27日から9月9日に、155件の応答に、ほかの利用者の入力の内容が混ざった
- 02 なぜ・背景 — 外部のAI機能では、入力が事業者の設備に渡り、事故は担当サイトの記録に出ない
- 03 用語 — 今回の報告に出てくる言葉を、先にそろえる
- 04 型別 — 外部のAI機能につないでいるサイトが対象で、棚卸しの手順は5つある
- 05 明日、自社のサイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 事故を完全には防げないので、送る中身と、気づく仕組みの両方を考える
- 07 当サイトで確かめたこと — 外から見える範囲では、外部のAIサービスへ送るコードは見つからなかった
- 08 このテーマは、ここまで
- 09 この記事のまとめ
01 何が起きたか — 2026年8月27日から9月9日に、155件の応答に、ほかの利用者の入力の内容が混ざった
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflareのブログ、Cloudflareのステータスページ、SGLangの開発チームのブログからの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月28日に開き、本文を取り直して、引用した文が原文にあることを確かめた。日本語で書いた説明は、原文の要旨であり、引用ではない。また、これはCloudflareの利用者に起きた出来事で、当サイトの出来事ではない。
2026年10月26日に、Cloudflareのブログに、Workers AIで起きた事故の報告が出た。AIのモデルに長い入力を送った利用者の一部に、ほかの利用者が少し前に送った入力の内容が、応答に混ざって返っていた、という内容である。この記事は、事故の細かい仕組みよりも、外部のAI機能につないでいるサイトの担当者が、自分の側で確かめられることに絞る。事故が起きたのは、Cloudflareの利用者の一部だけである。ただ、棚卸しと確認は、どの事業者のAI機能にも使える。
起きたことは、1つのモデルで、2週間ほどの間の出来事だった
原文によると、対象は、Workers AIのGLM-5.3というモデル（@cf/zai-org/glm-5.3）で、期間は2026年8月27日から9月9日である。同じ期間に、少数の利用者が、同じモデルに少し前に出された、ほかの利用者の要求の内容を含む応答を受け取った。原文は、数字をこう書いている。
"In total, 155 responses were affected, all to prompts longer than 681,280 tokens."
（訳: 合計で155件の応答が影響を受けた。すべて、681,280トークンより長い入力に対する応答だった。）
原文は、Workers AIで提供している他のモデルは影響を受けなかったことを確かめた、とも書いている。トークンは、AIが文章を数える単位で、681,280という数字は、非常に長い入力であることを示す。
見つかったのは外部の研究者の報告で、報告の翌日に非公開にして、その日のうちに戻した
原文のタイムラインでは、9月8日（UTC）の23時11分に、研究者からの報告がバグ報奨金の窓口（HackerOne）に届いた。9月9日の13時22分に事故として宣言し、14時にモデルを非公開にして、要求にはHTTP 400を返すようにした。19時40分に、直した設定とエンジンのパッチを入れて、公開に戻した。公表は10月26日で、報告から数えて、およそ7週間後である。
悪用の形跡は、見つかっていないと書かれている
原文は、Cloudflare自身の試験と研究者の試験を除いた要求を調べ、その時刻と件数は、ふつうの長い入力の使い方と合っていて、繰り返し悪用された形ではなかった、と書いている。結論の1文は次のとおりである。
"We found no evidence of deliberate exploitation."
（訳: わざと悪用された証拠は見つからなかった。）
この記事では、「見つかっていない」を「なかった」と言い換えない。原文が書いているのは、調べた範囲では証拠が無かった、ということまでである。
原因は、設定の食い違いと、エンジンの処理の誤りの2つの重なり
原文は、原因を2つに分けている。1つ目は、設定の食い違いである。モデルの入力の最大の長さは1,048,576トークンだったが、前半の処理を受け持つ機器のメモリの作業場には、681,280トークン分しか入らなかった。2つ目は、AIの実行に使われているオープンソースのエンジン（SGLang）が、入りきらない要求を扱うときの誤りで、本来はエラーで終わるはずの要求が、途中までの処理で次へ渡された。同じ種類の不具合は、2026年7月6日に別の利用者がSGLangの不具合報告に出していて、Cloudflareは今回の調査の中でそれに気づいた、と原文は書いている。仕組みの細部は、原文とSGLangの開発チームの記事に詳しいので、ここでは触れない。
応答は200で返っていた。Cloudflareは、確かめたのが応答コードと性能だけだったと書いた
利用者の側から見ると、いちばん大事な点は、応答のステータスが正常を示していたことである。原文は、事故の経路の最後を、こう書いている。
"The client got HTTP 200 instead of HTTP 400."
（訳: クライアントは、HTTP 400ではなく、HTTP 200を受け取った。）
さらに、Cloudflareは、自分たちの試験の穴を、次のように書いている。
"This was one critical gap in our testing: we only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence."
（訳: これは試験の重大な穴の1つだった。長い入力での、HTTPの応答コードとエンジンの性能だけを確かめ、モデルの出力とそのつじつまは確かめていなかった。）
事業者が自分の試験で、応答コードと性能だけを見て気づけなかった。利用者の側がステータスだけを見ていても、同じ見落としが起きる。05章の確認の10番目が、この点に当たる。
02 なぜ・背景 — 外部のAI機能では、入力が事業者の設備に渡り、事故は担当サイトの記録に出ない
外部のAI機能を載せると、入力は事業者の設備で処理される
担当サイトの画面や裏の処理から、外部のAI機能（チャット・要約・検索・翻訳・画像の説明など）を呼ぶと、そのとき送った入力は、事業者の設備に渡って処理される。入力には、画面の入力欄に利用者が書いた文のほかに、裏で足している指示文や、これまでのやりとりも入りうる。どれが事業者へ渡っているかは、担当者が一覧にしないと、すぐには言えない。
事業者の設備は、複数の利用者で共有されている
原文は、この件を、利用者どうしを分ける仕組み（テナント分離）の問題として扱っている。同じモデルは、多くの利用者の要求を、同じ設備で処理する。ある利用者の入力が、別の利用者の応答に出ない、という前提は、事業者の側が守る。今回は、その前提が、特定の条件で守られなかった。
事業者側の事故は、担当サイトのログには出ない
事故が起きたのは、事業者の設備の中である。担当サイトの記録に残るのは、送った入力と、返ってきたステータスと、本文だけである。今回のように、ステータスが200で返り、本文が自然な文章に見えると、担当サイトの記録だけでは、異常に気づく手がかりがほとんど無い。原文は、その応答について、入力の長さの表示は長い入力のままで、返事は筋の通った文章で、長い入力の処理にしては速く返った、と書いている（要旨）。担当サイトの側の記録では、速さのほかに目立つ手がかりは無いだろう、と筆者は考える（筆者の読み）。
事業者の知らせに、原因まで書かれるとは限らない
Cloudflareのステータスページには、この件が、「Cloudflare Workers AI increased errors」（訳: Cloudflare Workers AIでエラーが増えている）という題で載っている。開始は9月9日14時25分（UTC）で、本文は次の1文である。
"Cloudflare is aware of, and investigating, increased Workers AI errors when attempting to use GLM 5.3."
（訳: Cloudflareは、GLM 5.3を使おうとしたときにWorkers AIでエラーが増えていることを承知していて、調べている。）
この知らせには、ほかの利用者の内容が混ざった、という説明は無い。原因が書かれた報告が出たのは、10月26日である。知らせが届く、という確認だけでは、自分のサイトに関係するかを決められない場合がある。
03 用語 — 今回の報告に出てくる言葉を、先にそろえる
プロンプトと、トークン
プロンプトは、AIに送る入力のことである。画面で利用者が書いた文のほか、裏で足す指示文などもまとめて指す。トークンは、AIが文章を数える単位で、1トークンは、文字数と一致しない。この記事は、原文の「681,280トークン」を、文字数には直さない。
コンテキストの長さ
コンテキストの長さは、AIが1回に受け取れる入力の最大の長さである。原文では、GLM-5.3の設定が1,048,576トークンだった。入力の最大の長さと、機器のメモリが実際に抱えられる長さが、食い違っていたことが、1つ目の原因である。
用語
KVキャッシュは、AIが長い入力を処理する間、途中の計算結果を機器のメモリに置いておく場所である。原文は、要求が終わっても、この場所の中身はいちいち消されず、次の要求が上書きする作りだと書いている。性能のために一般的な作りで、そのぶん、どの要求がどの場所を使っているかをエンジンが正しく管理する必要がある。
テナント分離と、責任ある開示
テナント分離は、同じ設備を使う利用者どうしの内容が、互いに見えないようにする仕組みである。責任ある開示は、研究者が見つけた弱点を、事業者と関係する開発元に先に知らせ、直す時間を取ってから、時期をそろえて公表するやり方である。今回は、Cloudflare・研究者・エンジンの開発チームが、10月26日に同時に公表した。
用語
SGLangは、AIのモデルを動かすためのオープンソースのエンジンである。Cloudflareが使っていて、今回の2つ目の原因は、このエンジンの処理の誤りだった。原文は、この構成を前に書いた記事として、特大の言語モデルを動かす土台の記事と、KimiとGLMを大規模に動かす記事を挙げている。開発チームは、Cloudflareから9月9日に知らされたと書き、修正を入れた版を公開している。
04 型別 — 外部のAI機能につないでいるサイトが対象で、棚卸しの手順は5つある
🅰 適用範囲 — 誰に関係するか
今回の事故そのものは、Workers AIのGLM-5.3に、長い入力を送った利用者だけに関係する。Workers AIを使っていないサイトや、別のモデルを使っているサイトには、当てはまらない。一方、外部のAI機能につないでいる担当サイトの棚卸しと、事故の知らせが来たときの見直しは、事業者を問わず使える。サイトに載せたチャットボット、問い合わせの要約、翻訳、画像の説明文、サイト内検索、管理画面の補助などが、対象になる。
🅱 原文が書いていないこと
原文を読んだ範囲で、次のことは書かれていない。確かめられなかったので、この記事も書かない。
- 影響を受けた利用者の数や、業種
- 影響を受けた利用者への連絡の有無と、利用者に求める対応
- 混ざった内容の中身
- Workers AI以外の事業者で、同じ種類の事故があったかどうか
利用者への対応について、原文の本文を取り直して「customers」の語を探すと、影響を受けた範囲を書いた1文にしか出てこない。SGLangの記事は、その点を次の1文で、Cloudflareの報告に委ねている。
"For details on the incident’s scope and customer impact, see Cloudflare’s incident report."
（訳: 事故の範囲と、利用者への影響の詳細は、Cloudflareの事故報告を見てほしい。）
つまり、利用者が何をするべきかは、どちらの記事にも書かれていない。05章の確認は、原文の指示ではなく、筆者が整理したものである。
🅲 手順 — 5つの手順で、外部のAI機能を棚卸しする
棚卸しは、1行が1つの機能の表にする。列は、機能・事業者とモデル・送る入力・個人情報の有無・実際に送る長さ・事業者の上限・知らせの届け先・応答の検品の8つである。表のひな形を次の図に示す。
手順1: 外部のAI機能が動く所を、画面ごとに書き出す
公開ページ、会員の画面、問い合わせのフォーム、管理画面、メールの自動返信を、1つずつ開き、AIが働いていそうな所を書き出す。チャットの吹き出し、要約ボタン、翻訳ボタン、おすすめ表示が目印になる。裏の処理は画面からは見えにくいので、開発や運用の担当者にも聞く。
手順2: 機能ごとに、事業者の名前とモデルの名前を書く
分かる範囲で、事業者の名前と、使っているモデルの名前を書く。モデルの名前は、事業者の資料に書かれていることが多い。今回の事故でも、モデルの名前（GLM-5.3）が、影響を受けるかどうかの決め手だった。Workers AIのモデルの一覧にも、このモデルの項目がある。
手順3: 事業者へ送る入力を、2つに分けて書き出す
画面の入力欄に書かれた文と、裏で足している指示文を、別々に書き出す。個人情報保護委員会は、個人情報を含む入力を生成AIのサービスに送るとき、その利用目的の範囲内かを確かめることを求めている。この確認は、送る入力の中身を知らないとできない。
手順4: 入力の長さの上限と、事業者の知らせの届け先を書く
実際に送る入力の長さと、事業者が決めている上限の両方を書く。あわせて、入力の長さに、担当サイトの側で上限があるかを書く。今回の事故は、非常に長い入力でだけ起きた。さらに、事業者の障害や事故の知らせが、誰のどの連絡先に届くかを書く。ステータスページの購読、メール、セキュリティの窓口が候補になる。
手順5: 応答を、ステータスだけでなく本文まで読む
機能ごとに、最近の応答を数件開き、入力に無かった名前・数字・文章が混ざっていないかを目で見る。事故の知らせが来ていない普段から、定期的に読んでおくと、異常の見分けがつきやすい。
表に書いた内容の読み方を、次の表にまとめた。
| 列 | 書くこと | 書けないとき |
|---|---|---|
| 機能 | 画面の名前と、AIが働く内容 | 担当者に、画面を見ながら聞く |
| 事業者・モデル | 事業者の名前と、モデルの名前 | 事業者の資料か、管理画面で確かめる |
| 送る入力 | 入力欄の文と、裏で足す指示文 | 開発の担当者に、送る前の中身を見せてもらう |
| 個人情報 | 入る・入らない・分からないの3つ | 分からないは、聞く相手の名前を書く |
| 実際に送る長さ | 実際に送る文字数や画像の枚数 | 担当サイトの側に上限が無いなら、決める人を書く |
| 事業者の上限 | 事業者の文書で確かめた値 | 文書で見つからなければ、事業者に聞く |
| 知らせの届け先 | 購読の有無と、届いた最後の日付 | 購読していなければ、手順4でする |
| 応答の検品 | 本文を読む頻度と、読む人 | 頻度が決まっていなければ、まず月に1回とする |
注意
棚卸しの表には、入力や応答の実例（利用者の名前や、問い合わせの本文）を貼らない。表に書くのは、種類と件数、場所の名前までにする。表そのものが、個人情報の置き場になってしまうからである。
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトの外部のAI機能について、棚卸しと、事故の知らせが来たときの見直しの準備を進める13項目である。1〜6番目は機能・事業者・入力の洗い出し、7〜9番目は知らせの届け先と、今回の報告との突き合わせ、10〜13番目は応答の検品・記録・見直しの順番・見直しの日である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトの公開ページ・会員の画面・問い合わせのフォーム・管理画面を1つずつ開き、外部のAI機能が動く所を5つまで書き出す
- 書き出した機能ごとに、事業者の名前と、使っているモデルの名前を、棚卸し表の2列目に書く
- 各機能について、画面の入力欄の文と、裏で足している指示文を、別々の列に書き出す
- 送る入力に、氏名・メールアドレス・電話番号・社外秘の資料が入るかを調べ、各機能に「入る」「入らない」「分からない」のどれかの印を付ける
- 「分からない」の機能ごとに、聞く相手の名前と、聞くことを1行で書く
- 各機能について、実際に送る入力の長さと、事業者が決めている上限の両方を確かめて、数字を表に写す。担当サイトの側に上限が無いなら「無し」と書いて、決める人の名前を付ける
- 事業者ごとに、障害や事故の知らせの届け先（ステータスページの購読・メール・セキュリティ窓口）を1つずつ表に書く
- 事業者のステータスページを1つ開き、購読の宛先が、自分の連絡先になっているかを確かめる
- 今回のCloudflareの報告を読み、棚卸し表の機能のうち、GLM-5.3を使うものがあるかを、「ある」「無い」「分からない」で印を付ける
- 各機能の最近の応答を3件ずつ開き、入力に無かった名前・数字・文章が混ざっていないかを、本文まで読んで確かめる
- 入力と応答の本文を記録に残しているか、残すなら保存期間は何日かを、機能ごとに表へ書く
- 事故の知らせが来たときの見直しの順番（機能を止める・入力の中身を見直す・記録を保存する・利用者に伝えるか決める）を4行で書き、各行に担当者の名前を付ける
- 棚卸し表を見直す日を毎月1回の決まった日に決めて、カレンダーに入れる
06 代替・他の選択肢 — 事故を完全には防げないので、送る中身と、気づく仕組みの両方を考える
実務のヒント
機能が多いサイトは、入力に個人情報が入る機能から先に表を埋める。表は1回で完成させなくてよい。「分からない」の行が残っていても、残っていると分かること自体が、最初の成果である。
対策を、効くことと効かないことで比べる
次の表は、外部のAI機能を載せるときの対策を、筆者が整理したものである。原文が勧めているのは、エンジンを自分で動かす運用者向けの確認で、この表の内容ではない。一般的な考え方として書く。
| 選択肢 | 効くこと | 効かないこと・注意 |
|---|---|---|
| 入力から個人情報を外して送る | 事業者側の事故があっても、漏れる中身が減る | 応答の誤りは防げない。外し方の確認が要る |
| 入力の長さに上限を付ける | 今回のように、長い入力でだけ起きる事故の条件を避けられる | 別の事故には別の条件がある。上限は機能ごとに決める |
| 応答の本文を検品する | ステータスが正常でも、中身の異常に気づく機会ができる | 他人の内容が自然な文に見える場合は、気づけないことがある |
| 機能を止める切り替えを用意する | 知らせが来た日に、すぐ止められる | 止めた間の代わりの画面と、再開の条件を決めておく |
| 自分でエンジンを動かす | 入力が事業者の外へ出ない | 同じ種類の、メモリの扱いの誤りを、自分で見張る必要がある |
外部のAI機能の使い方を、3つの形で比べる
次の表は、外部のAI機能を使う形を、筆者が整理したものである。数字や優劣は、原文にも出典にも無いので、書かない。
| 使い方 | 向く場面 | 注意 |
|---|---|---|
| 事業者のAPIをそのまま使う | 入力に個人情報や社外秘が入らない機能。早く始めたいとき | 入力は事業者の設備で処理される。事業者側の事故は、担当サイトの記録にエラーとしては出ない。棚卸し表の知らせの届け先を先に決める |
| 送る前に個人情報を外す | 入力に氏名や連絡先が入りうる機能（問い合わせの要約など） | 外し漏れが無いかを、事前に実例で確かめる。応答の誤りは防げない |
| 自前で動かす | 入力を事業者の外へ出したくない機能 | エンジンの更新と、メモリの扱いの誤りの見張りを、自分で受け持つ。今回のような事故の原因も、自分の側に来る |
事業者の資料で、確かめる場所
事業者は、利用者の内容の扱いを、資料に書いていることが多い。たとえばCloudflareのWorkers AIのデータの扱いのページ（最終更新2026年10月16日）は、入力と出力の保存や学習への使用について書いている。このページは保存するかどうかの話で、今回のように処理の途中で内容が混ざる事故とは別の話である。事業者の資料を読むときは、保存の扱いと、利用者どうしの分離の説明を、別々に探す。
送る中身を決める基準は、個人情報の扱いにある
個人情報保護委員会は、2023年6月2日の注意喚起で、個人情報を扱う側に、個人情報を含む入力を生成AIのサービスへ送るときは、その利用目的の範囲内かを確かめることと、本人の同意なしに個人データを入力する場合は、サービスの事業者がそのデータを機械学習に使わないことなどを確かめることを求めた（要旨）。送る入力の中身が決まっていないと、この確認ができない。
応答を検品する考え方は、OWASPの整理にもある
OWASPの生成AIの危険の一覧には、「機密情報の開示」という項目がある。大規模言語モデルは、出力を通して、個人情報や機密の業務情報を明かすおそれがある、という整理である。対策として、データの無害化、アクセスの制限、利用者への説明などが挙がっている。今回の事故は、応答に別の利用者の内容が混ざる形だったので、この項目に近い。ただし、OWASPの項目は、今回の事故の原因を説明するものではない。
07 当サイトで確かめたこと — 外から見える範囲では、外部のAIサービスへ送るコードは見つからなかった
当サイトはCloudflareを使っていないので、事故そのものは当てはまらない。外部のAI機能を使っているかは、外から見える範囲だけ調べた。2026年10月28日に、公開ページと、それが読み込むスクリプトの中身に、外部のAIサービスへ入力を送るコードがあるかを調べた。
調べた範囲と、探したもの
調べたのは、トップページ1本・AI Ronのブログ（一覧1本・記事2本）・運営者ブログの一覧1本・解説記事（一覧1本・記事2本）・無料ツールの画面4本の、公開ページ12本と、そこから読み込まれる同じサイトのスクリプト26本である。探したのは、主なAI事業者の接続先の名前や、呼び出しの形の18種（OpenAI・Anthropic・Google・Cloudflareのモデル呼び出し・Hugging Face・Cohere・Mistral・Perplexity・Groq・DeepSeekなど）である。
結果は、どれも0件だった
12本のページ本体と、26本のスクリプトのどちらにも、18種のどれも見つからなかった。確認のために、同じ方法でGoogleのタグ（gtag.js）の読み込みを探すと、トップページで見つかったので、探し方そのものは動いている。
この確認で、分からないこと
- サーバーの中から、外部のAIサービスへつなぐ処理があるか（外からは見えない）
- ほかの会社のドメインから読み込まれるスクリプトの中身（読んでいない）
- ログインしないと開けない画面の中身
サーバーの中から外へつなぐ先の一覧は、外からは作れない。別に、サーバーの中で確かめて台帳にする。認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録で、外へつなぐ先の一覧を作る課題を書いた。この確認は、その一覧のAI機能の欄を作る前の、外側の確認にあたる。
08 このテーマは、ここまで
外部のサービスの事故や変更を、自分の側で確かめる記事は、これまでにも書いてきた。
外へつなぐ先の一覧を作った記録
認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録は、知らせを読んで終わりにせず、自分のサーバーから外へつなぐ先を測り直した記録である。05章の1〜3番目は、この「つなぐ先を書き出す」確認の、AI機能版にあたる。
重大な更新の後に、ブラウザで中身まで確かめた記録
PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録は、更新のあとに、応答のステータスだけでなく、ページの中身を確かめる手順を書いた。05章の10番目の応答の検品と、同じ考え方である。
AIに関する設定を、決めて確かめた記録
Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つは、AIの学習のための取得を、通すか止めるかを決めた記録である。Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直したは、名乗りと実際の出どころの突き合わせである。
外から取った画面は、目当てのものとは限らない
外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、取った応答の中身を確かめずに結論を出しかけた記録である。応答が返っても、目当ての中身かは別に確かめる、という点が、今回の事故と重なる。
AI機能と、外部のツールの棚卸し
Cloudflare AI Searchが一般提供になり、11月1日から従量課金が始まる ── サイト内検索をAIに任せる前に、載せる範囲と誤りの直し場所を決める14項目（2026年10月時点）は、サイト内検索をAIに任せる前に決めることを、サイトにつながる外部ツールと権限は、サービスごとに別々の画面で管理されている ── 計測・CMS・広告の連携を棚卸しする14項目（2026年9月時点）は、外部ツールと権限の棚卸しを書いた。この記事の棚卸しは、その続きとして使える。
2026年10月28日 — この記事の確認日
この記事の内容は、2026年10月28日に、公式のページ11本と、当サイトの公開ページ12本を開いて確かめた時点のものである。Cloudflareの報告や、SGLangの記事に追記や訂正が出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
