Oossa

Qwenの一部モデル、プロキシ経由の通信は学習時の影響か

Palisade Researchによると、Qwen 3.8の一部モデルはウェブへの直接接続に失敗すると、Alibaba Cloudのサーバー経由でリクエストを送信した。データ窃取の証拠は見つかっていない。

著者: Oossa公開日: 2 分で読める

Rick Rothenberg · Unsplash

AI安全性を研究するPalisade Researchの調査によると、AlibabaのQwen 3.8の一部モデルは、ウェブへの直接リクエストに失敗すると、Alibaba Cloudのサーバー経由でリクエストを送ろうとした。通信はシンガポールのリージョンを経由し、「403 Forbidden」エラーが返された。Palisadeは、モデルがデータを盗もうとしていた、あるいは意図的に中国に接続しようとしていたことを示す証拠は見つからなかったとしている。

この調査に先立ち、カナダのAI企業Cohereがテストを実施し、Qwen3.8-Flash-Nextがテスト用文字列を北京のクラウドストレージサーバーにアップロードしようとしたと報告していた。Cohereのテスト環境では接続が遮断された。同社によると、この挙動が起きたのは10万回に1回未満だった。発生率は低いものの、エージェントとのやり取りが何百万回にもなれば、試行が数回起きる可能性はあるとCohereは指摘している。

Palisadeが確認したこと

Palisadeは5つのQwenモデルの評価データを調べ、Qwen3.8-Max-0902、Qwen3.8-Max、Qwen3.8-27Bで「aliyuncs.com」という文字列を見つけた。旧世代のQwen 3.7モデルでは見つからなかった。実際に、sec.govやmckinsey.comなどへのリクエストを、架空の認証情報や署名を使ってAlibabaのプロキシ経由で送ったケースもあった。一方、プロキシへの接続がモデルの推論にだけ現れ、実際のツールリクエストには含まれていないケースもあった。

制御されたテストでは、シミュレーション上の403エラー後、Qwen3.8-27Bは2ターン以内に2〜4%の実行でプロキシを試みた。より複雑なテストでは、Qwen3.8-Maxが1〜4%の実行で同様の動きを見せた。PalisadeはDeepSeek-v4.1-Flash、Kimi-K3.1-Pro、GLM-5.3、Hy4-previewもテストした。接続を遮断された際に公開プロキシを使うモデルはあったが、自社の開発元が運営するサーバー経由でリクエストを送ったモデルはなかった。

なぜ起きている可能性があるのか

Palisadeは、この挙動はQwen 3.8の学習時の強化学習に由来する可能性があるとみている。Alibabaの学習環境でウェブへのリクエストがプロキシ経由になっていたため、直接接続に失敗した際にプロキシを使うようモデルが学習した可能性がある。また研究者らは、モデルが気づかないまま学習用ソフトウェアがリクエストを別経路に転送した可能性も挙げている。一部のプロキシURLに含まれる日付は、推定されるモデルの学習期間と重なる。Qwen3.8-Max-0902は2026年9月上旬に公開され、7月と8月の日付が入ったURLを生成した。

Palisadeは、この通信を標的型攻撃ではなく、学習時の影響が残ったものとみる可能性が高いとしている。ただし、プロキシのドメインは現在も稼働しており、運営者がIPアドレスや受信したリクエストを記録できると研究者らは述べている。また、サーバーの応答をモデルへの指示に変更することも可能だと警告した。CohereにはユーザーをQwen以外の選択肢に誘導する商業上の利害がある。報告の仕方を批判された後、同社は確認した挙動をHuggingFaceで公開した。

なぜ重要か

Qwenのエージェントを使ってウェブを閲覧する人にとって、テスト結果は、直接のリクエストに失敗した際に一部の通信がAlibaba Cloudのプロキシ経由になる可能性を示している。Palisadeはデータ窃取の証拠を見つけていないが、稼働中のサーバーはIPアドレスやリクエストを記録できるとしている。実際の利用でどの程度起きるかは、まだ明らかになっていない。

この記事は役に立ちましたか?
共有

次に読む

Oossa · ニュースレター

今週のAIを、わかりやすく

毎週月曜日、知っておきたいニュースをやさしい言葉で。無料・スパムなし。