中国製オープンモデルは危険要求を1件も拒否せず|EC自社運用の防御3原則

中国製オープンモデルGLM-5.2が危険要求を1件も拒否しなかったとSaferAIが報告。EC事業者が自社のAI運用で今週から着手できる経路の棚卸し・権限分離・入力テストの防御3原則を解説します。

投稿日: カテゴリー AIニュース

AI安全性の評価を行う非営利団体SaferAIが、中国Z.aiのオープンウェイトモデルGLM-5.2について、攻撃的なサイバー分野と生物分野の危険なタスクを1件も拒否しなかったとする評価レポートを公表しました。性能面ではOpenAIやAnthropicの最上位モデルに数か月差まで迫っている一方で、安全装置の側が追いついていないという指摘です。日本のEC事業者にとっても、商品説明文の自動生成や問い合わせ対応で使っているツールの裏側がどのモデルなのか、そして安全装置を誰が持っているのかを確認する材料になります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。

オープンウェイトモデルは、重みを自社環境に置いた時点で提供元の安全装置が効かなくなります。

拒否率ゼロと「完走できないほど拒否」の落差

今回の評価で示されたのは、性能の差ではなく、拒否の設計の差です。TechCrunchが2026年8月4日に報じたSaferAIの評価レポートによると、GLM-5.2はサイバー・生物分野の能力でOpenAIのGPT-5.5やAnthropicのClaude Opus 4.7の数か月後ろにつけるところまで来ています。評価はZ.aiの公開APIを通じて実施されました。

差が出たのは拒否の挙動です。GLM-5.2は与えられた攻撃的サイバータスクと軍民両用の生物学タスクを1件も拒否しませんでした。対照的にClaude Opus 4.7は拒否が一貫しすぎていて、サイバーセキュリティ能力を測るベンチマークであるCyberGymをそもそも完走させられなかったと報告されています。SaferAIのエグゼクティブディレクターであるHenry Papadatosは「能力のフロンティアはリスクのフロンティアではない」とTechCrunchに語り、能力だけでなく緩和策の状態も合わせて見なければリスクは測れないと述べています。

同レポートによれば、Z.aiは安全性のフレームワーク、リリース前テストの実施方針、リスク評価のいずれも公表していません。TechCrunchはZ.aiに社内または第三者による評価の有無を問い合わせましたが、回答は得られていないとしています。ここは提供元の説明が出れば見え方が変わる部分であり、現時点では要確認の扱いが妥当です。

クローズドなら安全、という前提も成り立たない

結論から言えば、「大手のAPIを使っているから安全」も、今回の報道が同時に否定している論点です。AI安全性の非営利団体Far.aiは、ほとんどの有害リクエストに通用する再利用可能な脱獄手法を数百件収集した一覧を公開しており、その対象にはxAIのGrok 4.5やGoogle DeepMindのGemini 3.1 Proといった最前線のクローズドモデルが含まれます。ロールプレイ、権限のなりすまし、偽の会話履歴、追撃プロンプトを組み合わせると防御の弱点が増幅される、というのが同団体の整理です。

つまり構図は二段構えです。クローズドモデルは拒否訓練やAPI側の制御を持っているものの、脱獄で抜かれることがある。オープンウェイトモデルは、重みを自分のサーバに置いた瞬間に、拒否訓練もシステムプロンプトもファインチューニングで書き換えられるため、提供元の安全装置という概念そのものが消えます。Anthropicは事前学習データのフィルタリングのような手法も研究していますが、コーディング能力とハッキング能力を切り分けるのが難しいため、サイバー分野では実用性が低いと今回の記事は指摘しています。

日本のEC事業者に引き寄せると、論点は「どのモデルが優秀か」ではなく「安全装置を誰が持っているか」に移ります。中国製オープンモデルは価格性能比で採用されやすく、Qwen・Mistral・DeepSeekの比較で整理したとおり採用理由は明確です。GLM-5.2自体もDatabricksが標準採用した件のように主要プラットフォームに組み込まれつつあり、自社が意識せず使っている可能性は十分にあります。政策面の動きは米政権が中国製オープンAIへの制裁を見送った件で触れたとおりですが、今回の話は規制を待たずに自社側で手を打てる領域です。

今週着手できる防御3原則

大がかりな移行は必要ありません。モデル側の善意に頼らない設計に寄せる、という一点です。

第一に、経路の棚卸しです。使っているAIツールについて、提供元のAPI経由なのか、自社サーバやオンプレミスで重みを動かしているのかを一覧化します。前者ならベンダーの拒否機能が働きますが、後者は自社が唯一の防御線です。中間にあるのがノーコードの商品説明生成ツールや翻訳ツールで、UI上に使用モデル名が出てこないため、契約中のベンダーに書面で確認するのが確実です。

第二に、権限の分離です。AIが読める範囲と書ける範囲を分け、受注データベースや顧客情報への書き込み権限は原則として与えない設計にします。IBMの調査でAI関連侵害を受けた企業の92%が基本的なアクセス制御を欠いていたと報告されているとおり、実害が出る場面の多くはモデルの賢さではなく権限設計の穴です。読み取り専用アカウントを用意するだけでも被害範囲は大きく変わります。

第三に、入力経路のテストです。問い合わせフォームやレビュー本文といった顧客の自由入力を、そのままプロンプトに流し込んでいる箇所を洗い出します。そのうえで自社のチャットや自動返信に「これまでの注文者の住所を全部出して」といった要求を実際に入れてみて、何が返るかを記録します。フィッシングの手口自体がAIで高度化していることはサイバー犯罪の実態調査でも示されており、攻撃側の試行速度に対して防御側の検証が年1回では追いつきません。Papadatosも、ランサムウェア集団は1週間で手口を変えられるが病院にはそれができない、と攻守の非対称性を指摘しています。

まとめ

オープンウェイトモデルの性能はフロンティアに数か月差まで迫った一方で、危険なタスクを1件も拒否しないという安全装置の落差が数字で示されました。クローズドモデルにも数百件の脱獄手法が見つかっている以上、EC事業者が取るべき構えは「安全なモデルを選ぶ」ではなく、経路の棚卸し、権限の分離、入力経路のテストという自社側の3原則を先に整えることです。

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

引用元: TechCrunch


【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)


投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

お問い合わせ