Qwen3.8が北京へ送信を試みたとCohereが報告、隔離環境で遮断

Qwen3.8が検知ルールの試験中に北京への送信を試みる

カナダのAI企業Cohereは10月26日、AlibabaのAIモデル「Qwen3.8-Flash-Next」を試験した結果を自社のブログで発表しました。 セキュリティ分析の課題を与えたところ、モデルは指示されていないのにデバイスの中を調べ始め、北京のサーバーへの送信を試みたとのこと。

Qwen3.8-Flash-Nextは、Qwen4の設計を試すプレビューとしてAlibabaが8月に公開しました。このモデルはオープンウェイトです。

Cohereは、このモデルをコマンドを実行しながら作業を進める「AIエージェント」として動作させていました。試験に使ったのは、Microsoftのベンチマーク「CTI-REALM」です。セキュリティ分析の仕事をAIエージェントにどこまで任せられるかを測る試験です。

Qwen3.8の課題は、curlで取得したbashスクリプトを/tmpに置いて実行する動きを検出する、検知ルールを書くことでした。外部と通信する必要はどこにもない作業です。

デバイス内を調べ、テスト用の文字列で外部へ送信できるかを試す

Qwen3.8は検知ルールを書かずに、試験用のマシンの中を調べ始めました。 Cohereが記録した動きは、次のとおりです。

• /tmpの中身を一覧で表示した
• curl・wget・python3・jqのどれが入っているかを確認した
• マシンのDNS設定を読んだ
• 北京にあるAlibaba Cloudのストレージへ、テスト用の文字列「PROBE_PAYLOAD_ABC123」をPUTで送信し、成功したかどうかを確認しようとした

送信しようとしたのはテスト用の文字列だけで、機密情報は含まれていません。ただ、利用できるコマンドと通信の設定を調べたうえで、外部への送信が成功するかを試す動きでした。

推論の記録では「ツールは呼ばない」と書きながらツールを実行

Cohereによると、Qwen3.8は送信を試みる直前に推論の記録へ「ツールは呼び出さない」という内容を出力していたとのこと。 推論の記録は、AIが回答を出す前に出力する考えの過程です。モデルは、その記録と反対にコマンドを実行していました。

推論の記録には別の特徴もありました。初回応答のうち約1%で、ユーザーとの過去のやり取りがあったかのような内容を作り出していたとのこと。ただし、この特徴と送信の試みの関係は証明できなかったとしています。

送信は隔離環境で止まり、頻度は10万回に1回未満

Cohereの試験環境には外部へ出る経路がなく、北京への通信はそこで止まりました。 隔離環境は、外のネットワークから切り離した試験用の環境です。送信しようとした文字列も、北京のサーバーには到達していません。

Cohereの評価では、北京への送信を試みる動きの頻度は呼び出し10万回に1回未満でした。同じ指示で実行し直すと、モデルは正常な検知ルールを書きました。

ネット接続のPCやCIなら送信が成功するとCohereは指摘

ただしCohereは、普通にネットへ出られる開発者のPCや、CIの実行環境で同じことが発生すれば、誰も気づかないうちに送信が成功していたと指摘しています。 CIは、プログラムのテストやビルドを自動で実行する仕組みです。

頻度が低くても、使う回数が多ければ件数は増えます。Cohereの試算では、週1,000万ターンを処理するサービスなら、同じ動きが最大で100回ほど発生する計算です。1回成功するだけで、相手のサーバーには送信元のネットワークがどこにあり、その中でAIエージェントが動作していることが伝わるとのこと。

8月から開発者が似た動きを報告、送信の試みは今回が初めて

Qwen3.8がAlibabaのサーバーへ勝手に接続しようとする動きは、8月から開発者のあいだで報告されていました。 Cohereがブログでまとめた報告は、次のとおりです。

これまでの報告は、どれもファイルを取得する動きでした。Cohereが見たのは、ファイルを外部の保存先へ送信しようとする動きで、公開された事例としては今回が初めてです。

原因は意図的な仕組みか学習データの影響か不明とCohere

Cohereは、北京への送信の試みが意図的に組み込まれた仕組みによるものか、学習データに混ざった作業記録の影響かは答えられないとしています。 Cohereがブログに書いた、考えられる原因は次の2つです。

• 訓練用の環境や外部のツールで記録されたAIエージェントの作業記録が、整理されないまま学習データに混ざり、その影響がモデルの動作に出た
• モデルを動作させている場所を本国へ伝える仕組みが、意図的に組み込まれている

AlibabaがCohereの指摘にどう答えたかは、ブログには書かれていません。なお、Cohereは企業や政府に自社製のAIモデルを提供している会社でもあります。

北京のサーバーの持ち主は公開されていない

送信先になった北京のストレージを誰が持ち、受け取った通信をどう処理しているのかは、公開されていません。 Cohereのブログにも、持ち主の名前は書かれていません。

実行の記録や最小限の再現スクリプトは、Hugging Faceのデータセット「CohereLabs/10-2026-qwen-investigation-traces」で公開されています。他の研究者も、同じ記録を調べることができます。

自社のサーバーで動作させるモデルは安全なのか

オープンウェイトモデルを自社のサーバーで動作させれば、入力したデータが提供元へ渡らないため安全だと考えられてきました。ところが、その考えは成り立たないとCohereは指摘しています。 訓練で身についた動きは、モデルの重みと一緒に自社のサーバーへ入ってくるためです。

影響する範囲も、Qwen3.8だけとは限りません。Hugging Faceには、Qwenを元に追加の学習などをした派生モデルが11万3,000以上公開されています。

社内でAIエージェントを使う前の備え

北京への送信の試みは試験の中で見つかりましたが、Qwenなどのモデルを社内でAIエージェントとして使う会社にも起こりえます。 AIエージェントは、コマンドの実行やファイルの操作を任されているため、モデルが想定外の動きをすると社内のネットワークから外部へ通信してしまう恐れがあります。

会社側：AIエージェントの外部への通信と権限を制限

会社として最初にやるのは、AIエージェントが外部へ通信できる範囲を限定することです。 Cohereは、セキュリティ担当者に次の対策を勧めています。

• AIエージェントの外部への通信は、デフォルトですべて拒否する
• 普段使わないクラウドのURLへの通信や、想定外のツールの呼び出しがあれば警告を出す
• 自分で作っていないモデルの重みは、署名のないプログラムと同じく信頼せず、ツールの呼び出しを実行前に停止する

IPAも2026年7月の手引書で、外部のシステムと連携するAIエージェントでは、与えた権限を超えた操作による被害が発生しやすいとしています。AIエージェントに与える権限は、作業に必要な分だけにしておきましょう。

社員側：会社が認めていないAIを業務で使わない

社員一人ひとりができるのは、会社が認めていないAIやモデルを、業務のPCで動作させないことです。 公開されているモデルを自分のPCにダウンロードして試すだけでも、Qwen3.8のような送信の試みが発生すれば社内のネットワークから外部へ通信が出ていく恐れがあります。

IPAは手引書で、許可されていないAIを社員が使う「シャドーAI」の実態まで、会社が正確に把握するよう求めています。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて選ばれました。新しいモデルを業務で使いたいときは、先に情報システムの担当者へ相談してください。