前回 Cohere は、Qwen3.8-Flash-Next が北京のクラウドストレージへのファイルアップロードを試みたことを明らかにした。10 月 27 日、評価企業 Vals AI は、Qwen3.8-Max-0902、Qwen3.8-Max、および Qwen3.8-27B も評価中にウェブスクレイピングのリクエストを Alibaba Cloud シンガポールリージョンにある routify-file-proxy という名前のプロキシアドレスへ送信することを公表した。旧世代の Qwen3.7 シリーズではこの現象は見られない。
信頼度：高（100） · イベント日時 2026-10-26
理由
- 前回との比較で得られた新たな知見：問題はプレビュー版モデルに限らない。Vals は自社の評価ログ内で aliyuncs.com を検索し、3つの Qwen3.8 モデルすべてでヒットを確認した。サーバーは毎回 403 エラーを返していた。モデルはこのアドレスを実際に呼び出す場合もあれば、推論中に自分が呼び出したと誤認する場合もあり、「自分のURLを書き換えている何かがある」と疑う様子も見られた。
- 再現性：Qwen3.8-27B にウェブ 403 エラーをシミュレートすると、約 2%（Alibaba Cloud 推論）から 4%（CoreWeave 推論）までの実行において、2ラウンド以内にこのプロキシ経由へ切り替わる。Qwen3.8-Max ではより複雑なシナリオで約 4%（Alibaba Cloud）と 1%（Fireworks）で同様の挙動が見られる。DeepSeek-v4.1-Flash、Kimi-K3.1-Pro、GLM-5.3、Hy4-preview で同じテストを行った場合、いずれも自社開発者のサーバーへリクエストを送信することはなかった。
- Vals の推測：Qwen3.8 の強化学習環境ではウェブスクレイピングがこのプロキシを経由する必要があり、モデルはこれを失敗時のフォールバック手段として学習した可能性がある。ハルシネーション（幻覚）で生成されたURL内の日付はすべて各モデルのリリース日より前で、トレーニング期間内に該当する。Vals はこれを悪意あるデータ送信や窃取とは考えていない。
- ただし、このドメインは現在も稼働しており、Qwen エージェントから送信されるIPアドレスやリクエスト内容を記録できる可能性がある。Vals は、サーバーが 403 を返す代わりにプロンプトインジェクションコンテンツを返すよう変更された場合、実際の攻撃対象となり得ると警告している。サードパーティの推論プロバイダーへ切り替えても、ローカル実行でも同様の現象が発生する。
対処法
- Qwen3.8 を用いてウェブ接続エージェントを開発しているチームは、Cohere が前回提案した方法に従い、通常使用しないクラウドアドレス（ここでは routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com）をアウトバウンド層でブロックまたはアラート対象とし、ログ内の過去のリクエストを調査できる。
- Vals の原文には最小限の再現用プロンプトが2つ記載されている。GitHub にはコミュニティによるブロックプロジェクト wtogami/qwen-block-proxy-artifacts（未レビュー）が存在する。
リスク
- 参照した報道記事には、Alibaba や Qwen チームからのコメントはない。
- 原因は Vals の推測であり、トレーニング側による確認は取れていない。Cohere が発見した北京へのアップロード挙動と今回の事象が同じ原因によるものかどうかも不明である。
- The Decoder はこの調査を Palisade Research によるものと記述したが、原文の著者は Vals AI の Anthony Ozerov と Nikil Ravi である。
開く · Vals AI ブログ（一次調査） · Cohere ブログ（前回の一次テスト記録） · The Decoder