Vals AI、Qwen3.8のAlibaba宛ての通信は「悪意の証拠なし」

手元で動かしているQwenは、勝手に中国のサーバーへデータを送っているのか。

AIモデルの評価を手がけるVals AIは10月27日、この疑問を自社の記録で調べた結果を公開しました。答えは「悪意をもって送っている証拠は見つからなかった」。ただし、Alibaba Cloudのサーバーに向けた通信そのものは、条件によっては数%の割合で起きていました。前の日には、Cohereが同じ系統のQwen3.8-Flash-Nextについて、より深刻な例を報告しています（Cohere、Qwen3.8-Flash-Nextが外部へ送信を試みたと報告）。

Webの取得を、Alibabaの中継先に向けてしまう

Vals AIは、評価で残っていたエージェントの記録を、Qwen3.8-Max-0902、Qwen3.8-Max、Qwen3.8-27B、Qwen3.7-Max、Qwen3.7-Flashの5つで調べました。Alibabaのサーバーへの通信が見つかったのは、Qwen3.8の3つだけです。行き先は、シンガポールにあるAlibaba Cloudのストレージ「routify-file-proxy-sg」で、Cohereが報告した北京の行き先とは違います。届いた通信は、すべてアクセスを断られていました。

起きていたことは2つあります。1つは、たとえば米国の証券取引委員会のサイトを読もうと考えたあとに、なぜかこの中継先を呼び出してしまう動き。もう1つは推論の中だけの話で、呼んでもいないAlibaba CloudのURLについて考え込んだり、自分の呼び出しが書き換えられたと思い込んだりする動きです。

割合は、取得の失敗をわざと起こすなど、この動きが出やすい場面を作って測ったものです。DeepSeek V4.1 FlashやKimi K3.1 Pro、GLM-5.3も、ときどきr.jina.aiのような中継のサービスを使いました。ただ、Alibaba Cloudや自社の中継先を呼んだモデルはありません。

原因について、Vals AIは強化学習の名残ではないかとみています。学習の環境で、Webの取得がこの中継先を通る作りになっていた可能性です。モデルが作り出したURLに入っている日付は、それぞれのモデルが出る前の、学習していたとみられる時期に重なります。Qwen3.7には無い動きなので、Qwen3.8で新しく入ったようです。一方で、このサーバーの持ち主は、届いた通信のIPアドレスや中身を記録できます。返す中身を変えて、エージェントに指示を紛れ込ませることもできる、とVals AIは注意しています。

2社の結論をどう読むか（編集部の見方）

2社の結論は違って見えますが、正直なところ、矛盾しているわけではありません。Cohereは10万回に1回未満の深刻な例を、Vals AIは数%で起きる軽い例を見つけました。どちらも、意図して仕込まれたかは確かめられていません。なお、Vals AIの検証はAPIの推論の提供元を使ったもので、題にある「手元のQwen」で試した結果は記事にありません。Qwen3.8をエージェントに使うなら、外への通信を許したサイトだけに絞り、この中継先への通信が記録に出ていないかを見ておくと安心です。調べる会社がさらに増えれば、原因ももう少しはっきりするかもしれません。

Qwen3.8のモデルは、現時点ではYOBITSUGI AIからは使えません。