Qwen 3.8 27Bという公開モデルが、市販アプリのライセンス認証を30分で解析し、回避コードまで組み立てた。試したのは筆者本人で、機材はNvidia GB10 Grace Blackwellチップを積んだ小型ワークステーション1台だけだった。今日はこの実測と、それを取り巻く「解析コストの低下」というテーマを掘り下げる。数字が示す範囲と、示していない範囲を分けて見ていきたい。
Qwen 3.8 27Bが1台のマシンでライセンス認証を解いた
XDA Developersのライターが試したのは、Qwen 3.8 27Bという公開重み（オープンウェイト）モデルです。かみ砕いて言えば、企業が非公開で運用する大規模モデルとは違い、誰でもダウンロードして自分のパソコンで動かせるタイプのAIモデルです。筆者はこれを、Nvidiaの「GB10 Grace Blackwell」チップを積んだLenovo ThinkStation PGXという小型のワークステーション1台の上で動かしました。メモリは128GB、データの転送速度は毎秒273GBです。
素の状態では1秒あたり15〜30語（トークン）程度の出力速度でしたが、SGLang、NVFP4、DFlash2による投機的デコーディングを組み合わせる、この機材向けの標準的なセットアップに変更すると、コードや推論のタスクで毎秒約50語まで上がったといいます。速度そのものよりも重要なのは、この構成でどこまでの作業がこなせたかです。
筆者が与えたのは、自分が実際に購入して使っている市販アプリのライセンス認証チェックを解析するという課題でした。この種の作業はモデルの訓練データには含まれていない可能性が高く、しかも技術的な難度は高い。加えて、この手のモデルのセキュリティ面での懸念も指摘されていたため、あえて選んだ検証だったと筆者は説明しています。結果として、モデルは自分の間違いを修正しながら作業を進め、筆者いわく「これまで見た中で最も印象的なデモの一つ」になりました。使用したツールはPiというハーネス（AIエージェントを動かす実行環境）で、モデルが呼び出したのは標準的なBashコマンドだけだったといいます。
興味深いのは、最初の段階でモデルが一度作業を拒否したことです。筆者は自分がそのアプリの開発者だと偽り、よく使われる「ジェイルブレイク」の言い回し（AIの制限を回避するための定型的な指示文）を使って依頼しました。Qwenはこの手口を認識し、まず断りました。そのうえで署名証明書を確認し、筆者が実際の開発者ではないこと、そして本当の開発者が誰かを言い当てたといいます。筆者自身、「見破られた」と書いています。
このやり取りのあと、モデルは一度拒否したものの、自ら回避策を作る方向へ話を進め、最終的に解析と回避コードの作成に取りかかりました。
比較の物差しとして、Artificial Analysisという評価機関の指標も紹介されています。Qwen 3.8 27Bは、パラメータ数40億〜400億という規模のオープンウェイトモデル135種の中で首位、知能指数は52点だったといいます。またSWE-bench Pro（ソフトウェア開発タスクの実力を測るベンチマーク）でも、はるかに運用コストの高いモデルを上回る数値を出したとされています。ここでの「上回った」は同機関が算出した数値上の比較であり、実運用でのコスト差そのものを裏付ける数値ではありません。
個人の実測と、業界側で進む解析・難読化の競争
筆者が最も強調しているのは、消費者向けグラフィックカードに収まる規模のモデルが、30分で商用アプリの認証システムを解析し、動く回避策を作った、という一点です。「かつてフロンティアモデル（各社の最上位・最大級のモデル）でなければ無理だと思っていた作業を、今は隣にある機材に任せられる」と筆者は述べています。この記述はあくまで1人の検証者による1回の実測であり、他のアプリや別の認証方式でも同じ結果になるとは記事は述べていません。
この個人の実測とは別に、解析コストの低下という現象そのものを扱った記事もあります。Simon Willison氏は、コーディングエージェント(自動でコードを書き実行するAIツール)を使って自宅の機器を解析し、自動化したという逸話を繰り返し耳にしていると述べています。氏の見立てでは、エージェント登場以前から機器の解析自体は可能でしたが、問題は費用対効果でした。ドキュメント化されていない不安定なAPI（機器同士がやり取りする仕組み）は将来変更される恐れがあり、その保守の手間まで考えると、最初から手を出す価値があるか迷うケースが多かったといいます。コーディングエージェントはこの計算式を変え、うまくいく作業を得るまでの試行錯誤にかかる手間そのものを下げたため、コードが将来使えなくなっても書き直せばいい、という心理的なハードルの低さにつながっている、というのが氏の観察です。
もう一つ、Elastic Security Labsが2026年4月の社内研究週間で行った検証も、この流れに関わります。同社はClaude Opus 4.6というモデルを使い、Tigressという学術用の難読化ツールで加工したプログラムをどこまで解析できるか調べました。結果、難読化はLLMによって完全に無力化されたわけではないものの、従来型の変換手法は「今日では容易に破られる」水準にあると結論づけています。
同時に同社は、LLM駆動の解析を防ぐための難読化手法を、開発・テスト・改善のAIパイプラインを使って自ら組み上げる実験も行いました。静的解析(プログラムを実行せずにコードを読んで分析する手法)への対策に絞った検証ですが、こちらも「効果的で低コストな難読化手法を、意欲のある担当者なら長い週末1回分の作業で用意できる水準にある」としています。同社はこれを解析側と防御側の「いたちごっこ」と表現し、どちらの側も今後さらに手法を磨いていく前提で研究を続けるとしています。
Qwenの個人検証と、Elasticの組織的な検証は、対象のモデルも手法も別物です。ただし両方とも、AIモデルによる解析作業がこれまでより手の届く範囲に入ってきているという点では方向が一致しています。一方で、難読化の側もAIを使って対抗手段を作れることをElasticの検証は示しており、解析する側だけが有利になり続けると断定できる材料は、今回のソースには含まれていません。
用語補足：オープンウェイトモデルとフロンティアモデル
オープンウェイトモデルとは、AIモデルの中身（重みデータ)が公開されていて、誰でもダウンロードして自分の機材で動かせるモデルを指します。対してフロンティアモデルは、筆者が以前この作業には必要だと考えていた種類のモデルを指す言葉として記事内で使われています。Qwen 3.8 27Bがオープンウェイトモデルの中で高い評価を得たという事実は、非公開の最上位モデル群と直接性能を比較したものではありません。この記事の数字は、あくまで同規模帯のオープンウェイトモデル同士の比較として読む必要があります。
注目ニュース
Vercelが Next.js の未認証RCEを招く脆弱性2件を修正
Vercelは、WebフレームワークのNext.jsに存在する深刻度「重大」の脆弱性2件に対する修正パッチを公開しました。いずれも認証なしでリモートからコードを実行される(RCE)恐れがあるもので、一つは特殊に細工されたAVIF画像ファイルを通じて、もう一つはWindowsのファイルシステムを使うサーバーを狙ったパストラバーサル(本来アクセスできないはずのファイル領域に到達する手口)の欠陥です。Windows側の脆弱性にはCVE-2026-75604という識別番号が割り当てられています。具体的な悪用状況や影響範囲の規模については、今回確認できた記事からは判断材料が不足しています。
PaperCutがNG・MFの脆弱性をゼロデイ攻撃で悪用されていると警告
印刷管理ソフトを手がけるPaperCutは、自社製品「PaperCut NG」および「PaperCut MF」の全バージョンに存在する脆弱性が、ゼロデイ攻撃(修正が公開される前の段階での攻撃)で悪用されていると発表しました。同社は顧客での被害を確認済みとし、インターネットに公開されているアプリケーションサーバーについて、Web管理画面へのアクセスを信頼できるIPアドレスのみに制限するよう緊急で呼びかけています。攻撃の詳細な手口や、攻撃者が侵入後に何を行っているか、データが窃取されているかどうかについては、同社はまだ公表していません。PaperCutは過去にも脆弱性がClopやLockBitなどのランサムウェア攻撃の侵入口として使われた経緯があり、緊急パッチもすでに配布されています。
編集後記：モデルが「見破った」理由は記事に書かれていない
今回の検証で個人的に引っかかったのは、Qwenが最初にジェイルブレイクを拒否し、署名証明書から本当の開発者を言い当てた場面です。ここだけ見ると「賢い」という印象を持ちますが、なぜそのあとに方針を変えて解析作業に入ったのか、出典記事はその経緯を詳しく説明していません。拒否から実行への切り替わりが、モデルの挙動として一般的なものなのか、この1回の対話に特有の流れだったのかは、今回のソースだけでは判断がつきません。1台のマシンでの1回の実測という条件も含めて、この結果をどこまで一般化できるかは、読み手が自分の用途に照らして確かめる必要がありそうです。