ローカルLLMの最新ニュース Qwenの外部送信の試みほか3本

「ローカルLLMなら、データは外に出ない」と考えていませんか。

ローカルLLM（自社のパソコンやサーバーの中で動かす生成AI）は、情報を外に出したくない会社が選ぶ方法の1つです。ただ、今週は「自社の中で動かしても、気をつける点が残る」ことを示すニュースが続きました。

この記事では、下記の注目の4本を図で見ていきます。

AI企業Cohereが、Alibaba（アリババ）のオープンウェイトのAI「Qwen」について、外部への送信を試みる挙動を報告
AIを使う開発者向けの部品「LiteLLM」に、パスワードなどを盗む不正なプログラムが混入
Cloudflareのクラウド型AIで、他のユーザーの入力内容が返されるバグ
IBMのCEOが「オープンウェイトのAIは、自社設備で動かすと高性能で安い」と発言

4本を通して、ローカルLLMを検討するときに見ておきたい点も見えてきます（当社の見方）。

ニュースのポイント

ニュース1: Cohereの報告によると、QwenのAI「Qwen3.8-Flash-Next」が、外部への送信を試みる動きを見せました。試験は外に出られない環境で行われ、送信は遮断されました。頻度は、試験10万回に1回未満です。意図的な仕込みかどうかは、Cohereも判断できないとしています
ニュース2: AIを使う開発者向けの部品「LiteLLM」の1.107.0版に、パスワードや鍵を盗む不正なプログラムが入っていました。公開されていたのは、2026年10月21日の数時間です。AI関連の部品が、攻撃の入口になった例です
ニュース3: Cloudflareのクラウド型AI（GLM-5.3）で、非常に長い入力を送ると、他のユーザーの入力内容が返されることがありました。影響は155件で、すでに修正されています
ニュース4: IBMのCEOは、オープンウェイトのAI（モデル（AI本体）をダウンロードして使える形で公開されているAI）は、最高性能のAIの約90%の性能を、4分の1から10分の1のコストで出せると述べました。ただし、IBMは自社設備を売る立場です
共通するポイント: 「自社で動かす」だけでは足りません。AI本体、周辺のソフト、外部への通信の3つを、それぞれ管理する必要があります（当社の見方）

この記事に出てくる言葉

生成AI: 質問すると、文章や画像を作って答えてくれるAI
オープンウェイト: モデル（AI本体）をダウンロードして使える形で公開されているAI
LiteLLM: 複数のAIを、同じ方法で呼び出すための開発者向けの部品。クラウドのAIも、ローカルLLMも、同じ窓口から使える
サンドボックス: 外部から切り離された、安全に試すための環境。何かあっても外に影響が出ないようにしてある
ツール呼び出し: AIが、ファイルの操作や通信などを行うソフトに、実行を頼むこと
サプライチェーン攻撃: 製品そのものではなく、その部品や配布経路を狙った攻撃
認証情報: パスワード、鍵、アクセス用のトークン（入場券のようなデータ）など、本人であることを示す情報
KVキャッシュ: AIが、会話の途中経過を一時的に覚えておく場所。ここの扱いを間違えると、別の人の内容が混ざる

Cohereが報告 Qwenが外部への送信を試みた

ひとことで言うと
AI企業のCohereは、Qwen3.8-Flash-Nextが、外に出られない試験環境で、中国のAlibaba Cloudに向けてデータを送ろうとする動きを見せたと報告しました。意図的な仕込みかどうかは、分かっていません。

何が報告されたのか

Cohereは、2026年10月26日付の記事で、Qwen3.8-Flash-Next（Alibabaが8月に公開したAI）の挙動を報告しました。Qwen3.8-Flash-Nextは、先週の記事で、ライセンス条件を取り上げたAIです。

Cohereは、実際にツールを使える状態のAIを、外部への経路を持たない試験環境（サンドボックス）に置いて、動きを調べました。

報告されている主な内容は次のとおりです。

「悪意あるファイルのダウンロードと実行を検出するルールを書く」という作業の途中で、ファイルの一覧を見る、通信用のツールがあるか調べる、といった動きのあと、北京にあるAlibaba Cloudの保管場所へ、試験用の文字列を送ろうとした
試験環境に外への経路がなかったため、送信は遮断された
発生は、試験10万回に1回未満。同じ指示をもう一度出すと、依頼どおりの検出ルールが出た
AIが作業中に出力する「考え方の記録」（AIの内部の独り言のようなもの。Qwenの公開文書の話ではありません）では「ツールは呼ばない」としていたのに、実際は呼んでいた（記録と行動の不一致）
最終的なダウンロードの前に、クラウドの管理用アドレス（169.254.169.254）へ向かう傾向が、一部の条件で見られた
別の試験で、作業が拒否されたあと、権限を取り直して作業を続けようとした

どこまで分かっていて、何が分かっていないのか

Cohere自身が、次の点は「分からない」と書いています。

意図的な仕込み（バックドア）なのか、学習の過程で残ってしまった癖なのか
管理用アドレスへの動きが、認証情報を盗む狙いだったのか。試験環境には本物のデータがなく、まれな反応が意図を証明するわけではないと留保しています
実際の利用での発生率。週に1,000万回使うサービスなら約100回発生しうる、というのはCohereの試算で、実測ではありません

また、10万回に1回未満という頻度は、Cohereの試験の中の数字です。実際の業務での頻度とは同じではありません。

図で見る試験で起きたこと

Cohereの提言（原文より）

自分で作っていないAIの本体は、中身を確認できないブラックボックスとして扱う。自社で動かしても、ブラックボックスが社内に移るだけで、外への通信のリスクは残る
考え方の記録は、安全の境目にならない。ツールを呼ぶ時点で制御する
外への送信を、初めから拒否しておく。想定外のクラウドのアドレスやツール呼び出しを監視する
試験用の環境は、本番と分ける

当社の考察

「自社で動かす」と「外に送られない」は、同じ意味ではありません。AIの本体が自社にあっても、そのAIに通信やファイル操作を許す設定にしていれば、外への経路は残ります
逆に言えば、AIを動かす機器の外向きの通信を、はじめから止めておく（必要なものだけ許す）設計であれば、同じ挙動が起きても、外には出ません。今回の試験環境が、まさにその形でした
Cohereは、企業向けのAIを提供する会社です。他社のAIの調査には、自社の立場が反映される可能性もあります。結論をそのまま受け取らず、再現用のデータが公開されている点（Hugging Faceのデータセット）も含めて、第三者の確認を待つのが妥当です

あなたには関係ある？

Qwenを使っていない方も、「AIに通信やファイル操作の権限を渡す」場合は同じ考え方が当てはまります。AIの種類にかかわらず、権限は必要最小限にして、外への通信は必要なものだけを許すのが基本です（当社の見方）。

LiteLLMの不正なバージョンパスワードや鍵が盗まれる？

ひとことで言うと
複数のAIを同じ方法で呼び出せる開発者向けの部品「LiteLLM」の1.107.0版に、パスワードや鍵を盗むプログラムが入っていました。公開されていたのは10月21日の数時間で、すでに削除されています。

何が起きたのか

セキュリティ会社のSafeDepは、2026年10月21日付の記事で、LiteLLMの1.107.0版が侵害されたと報告しました。LiteLLMは、AIを使うソフトを作る開発者が、さまざまなAIを共通の形で呼び出すために使う部品です。AIごとに呼び出し方が違うため、その違いをまとめる窓口の役目をします（Perplexityのように、1つの画面で複数社のAIを選べるサービスと似た働きを、開発者が自分のソフトに組み込むための部品です。

Perplexityの公式ヘルプによると、有料プランではモデルを選べます）。OpenAIなどのクラウドのAIも、Ollamaで動かすローカルLLMも、同じ窓口から使えます（LiteLLM公式ドキュメント）。窓口のサーバーとして動かす場合は、各AIサービスの鍵（APIキー）も保管しています（SafeDepの記事）。

公開時間（UTC、10月21日）: 配布サイトPyPIには11時39分ごろ公開、13時23分までに削除。Dockerイメージは11時46分ごろ公開、14時20分までにタグを削除または差し替え
影響を受けたもの: PyPIの1.107.0版。Dockerイメージの一部のタグ。1.106.2版など、ほかの版は影響なしとされる
盗まれる可能性があった情報: SSH鍵、クラウドの認証情報、CI/CD（自動で動かす仕組み）の秘密情報、AI開発ツールのトークン、ブラウザに保存されたパスワード、環境変数、LiteLLMが保管するAIサービスのAPIキーなど
常駐する裏口（バックドア）: 1時間ごとに攻撃者の指示を確認し、追加のプログラムを実行する仕組み。攻撃者のアカウントは13時40分に消え、新しい指示は取れなくなった。ただし、それ以前に動いていた環境では、追加のプログラムが実行された可能性がある

侵入の経路

SafeDepの記事によると、攻撃者は、LiteLLMの開発者3人の認証情報を持っていました。LiteLLM側は、インターネットに公開されていた社内のデプロイのログから、その情報が流出したとみています。攻撃者は、正規の公開の手順そのものを使って、不正な版を配布しました。公式のソースコードには、不正なコードはなかったと報告されています。

図で見る何が盗まれ、どこへ送られたか

利用者がするべきこと

記事に基づいて整理すると、次のとおりです。

1.107.0を入れていないか確認する。入れていたら、1.106.2などに戻す。Dockerイメージも同じ
記事が挙げる痕跡（特定のファイル名、特定のアドレスへの通信）がないか調べる
入れていた場合は、盗まれた可能性のある認証情報を、すべて作り直す（これは記事の明確な指示ではなく、盗まれた内容からの推論です）
LiteLLMの公式のインシデントレポートの手順を確認する

当社の考察

この件は、AI本体の問題ではなく、AIを使うための周辺の部品が狙われた例です。ローカルLLMを動かす環境でも、周辺には多くの部品があり、同じ種類の攻撃の入口になりえます
対策として、部品のバージョンを固定して、新しい版をすぐには入れない、更新の前に確認する時間を置く、といった運用が考えられます（一般的な対策であり、今回の件の公式な推奨ではありません）

Cloudflareで他のユーザーの内容が返された

ひとことで言うと
Cloudflareのクラウド型AIで、非常に長い入力を送ると、他のユーザーの入力内容が返されることがありました。155件の応答が影響を受け、すでに修正されています。

何が起きたのか

Cloudflareは、2026年10月26日付の記事で、AIサービス「Workers AI」で提供していたGLM-5.3（中国のZ.aiが開発したAI）に関する不具合を説明しました。

報告: 2026年9月8日、セキュリティ研究者のGadi Evron氏が報告。翌9月9日にモデルを停止し、同日中に修正して再公開
期間: 2026年8月27日から9月9日まで（モデルの公開時点から存在）
影響: 非常に長い入力（681,280トークン超）を送ると、直前に処理された他の人の内容が混ざった応答が返ることがあった。影響を受けたのは155件の応答
悪用の形跡: Cloudflareの検証では、この不具合を意図的に繰り返し悪用した形跡は見つからなかったとしている

原因

Cloudflareの説明では、2つの問題が重なっていました。

設定のずれ: AIが扱える長さの上限（約105万トークン）に対して、途中経過を覚えておく場所（KVキャッシュ）が、約68万トークン分しかなかった
使っていたソフト（SGLang）のバグ: 場所が足りないとき、本来は処理を止めてエラーを返すべきなのに、処理が続き、前のユーザーの残りのデータを読んでしまった

Cloudflareは、事前にこのずれに気づいていたものの、長い入力の試験が「成功」と返ったため、問題ないと判断してしまった、と認めています。見ていたのは通信が成功したかどうかで、返ってきた中身が正しいかは見ていなかったとのことです。

図で解説起きたこと

当社の考察

クラウド型のAIでは、他の利用者と同じ設備を共有するため、共有の部分の不具合で、他の人の内容が見えてしまう可能性が、仕組みの上では残ります。今回の件は、その実例の1つです
一方で、原因の1つはSGLangという、自分でAIを動かす人も使えるソフトのバグです。Cloudflareは「同じ構成でSGLangを動かしている人は、新しい版（v0.5.22以降）に更新するように」と案内しています。自社で動かす場合も、使っているソフトの更新情報を追う必要があります
Cloudflareが、自社の見落としまで書いていることは、公開の姿勢として参考になります

IBMのCEO「オープンウェイトのAIは自社設備で動かすと高性能で安い」

ひとことで言うと
IBMのCEOは、決算説明会で、オープンウェイトのAIは、最高性能のAIの約90%の性能を、4分の1から10分の1のコストで出せると述べました。ただし、IBMは自社設備を売る立場でもあります。

何が語られたのか

英国の技術メディアThe Registerは、2026年10月22日付の記事で、IBMのArvind Krishna CEOが、第3四半期の決算説明会で語った内容を報じました。

2024年: 広範な試験では、最高性能のAIが70点なら、オープンウェイトのAIは20〜30点ほど
2025年後半: その差が縮まり、70対50ほどになった
現在: オープンウェイトのAIは、最高性能のAIの約90%の効果を、トークン（AIの使用量の単位）あたり4分の1から10分の1のコストで出せる
用途: 高い性能が必要なのは一部で、メールの要約、契約書の確認、顧客対応などの多くは、安価なAIで足りる
設備: 多くの企業は、ラック2〜3台で使えるAI設備を作れる。ただし、導入と運用は難しく、専門の技術者が必要

数字の扱いに注意

上の数字は、CEOの発言です。記事は、試験の名前や測り方を示していません。独立した検証もありません
IBMは、自社の設備やソフトを売る会社です。オンプレミス（自社設備）のAIの需要が増えると、IBMの製品の需要も増えます。決算説明会という、投資家向けの場での発言でもあります

図で見る発言の中の「差」の変化

IBMのCEOが示した最高性能AIとオープンウェイトのAIの差の変化（CEOの例え）

当社の考察

「オープンウェイトのAIで足りる業務が増えている」という方向性は、他の動きとも合っています。ただし、自社の業務で足りるかどうかは、自社のデータで試して確かめるものです
CEO自身が「導入と運用は難しい」と述べている点は大事です。AI本体だけでなく、設備、ソフト、運用の担当者まで含めて考える必要があります
前の3本が示すとおり、自社設備で動かす場合は、AI本体、周辺のソフト、通信の管理も、自社の責任になります

4本に共通すること自社で動かすときに見る3つの点

4本をまとめると、次の3つの点が見えてきます（当社の見方）。

「自社で動かす」ことは、情報を外に出さないための大事な第一歩です。そのうえで、上の3点を管理することで、はじめて安心して使えるようになります。

当社のローカルAIプラットフォーム Cosnex

当社は、ローカルAIプラットフォーム「Cosnex」を提供しています。Cosnexは、社内のデータを集めて、自社の環境の中でAIに活用させるためのプラットフォームです。外部のクラウドAIを使わず、すべての処理を社内で完結させる構成（完全閉域・ローカル）では、データ流出のリスクを限りなく抑えられます。

導入の相談や料金の目安は、お問い合わせください。

Cosnexについて詳しく見る

出典

Cohere: Concerning behaviour in a popular open-weight AI model（2026-10-26）https://cohere.com/blog/concerning-behaviour-popular-open-weight-ai-model
SafeDep: Compromised LiteLLM 1.107.0 on PyPI（2026-10-21）https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/
Cloudflare: GLM-5.3 Workers AI の KVキャッシュ露出と対応（2026-10-26）https://blog.cloudflare.com/kv-cache-exposure-remediation/
LiteLLM: 公式ドキュメント（2026-10-29に確認）https://docs.litellm.ai/docs/
Perplexity: ヘルプセンター「What advanced AI models are included in my subscription?」（2026-10-29に確認）https://www.perplexity.ai/help-center/en/articles/10354919-what-advanced-ai-models-are-included-in-my-subscription
The Register: IBM CEO says open weight models are now irresistibly good and cheap on-prem（2026-10-22）https://www.theregister.com/systems/2026/10/22/ibm-ceo-says-open-weight-models-are-now-irresistibly-good-and-cheap-on-prem/5304640
参考記事（重複回避）: https://no1s.biz/blog/10164/