「ローカルでそれっぽく動くLLMを見つけたけど、あとからライセンスで詰んだ」──そんな経験、ありませんか？
最近の Qwen 3.5 ファミリーのアップデートとライセンス変更は、まさにその「あとから詰む」パターンを内包した動きだと感じています。技術的にはめちゃくちゃ魅力的なのに、商用利用を考えた瞬間に空気が一変する。この記事では、そのギャップについてあえて意見多めで整理してみます。
結論（忙しい方向け）
- 技術的には魅力：Qwen 3.5（特に 9B/27B）はローカル環境で実用ラインに入り、PoC/R&D の“頭脳”として試す価値は高い。
- 商用は要注意：3.5系は利用条件がタイトになりやすく、「とりあえず組み込む」は法務/コンプラで止まるリスクが現実的。
- 採用するなら逃げ道を用意：抽象化レイヤを挟み、ライセンス条件のスナップショット保存＋代替モデルへの切替計画を先に作る。
想定読者：ローカルLLMを業務/プロダクトに組み込みたい開発者・PM・情シス（「性能」だけでなく「継続運用・法務」を含めて判断したい人）。
関連リンク：
- Claudeを巡る政策・ガバナンスの揺れ（ベンダー要因の見方）
- Gemini 3.1 Flash‑Lite：thinking levelsでコスト/品質を調整する設計
- DeepSeek V4リーク：実行基盤まで含めたロックインの論点
一言でいうと：「ローカル GPT の MySQL が、気づいたら Oracle っぽくなってきた」
Qwen 3.5 を一言で説明するなら、
「ローカル LLM 界の MySQL（便利でどこでも動くやつ）が、気づいたら Oracle 的なライセンスをまとい始めた」
という感じです。
- 技術面：
- 9B は Mac mini や 24GB クラス GPU で普通に実用レベル
- 27B も 4bit ならプロシューマー GPU 1枚でなんとかなる
- Ollama 経由で
ollama pull qwen:3.5-9b的に簡単に取れて、エージェント用途にも十分 - しかしライセンス：
- 以前の「わりとオープンっぽい Qwen」から一転
- 3.5 系は商用利用にかなり制約が入り、「実質プロプライエタリ」に近づいた
正直、「ローカルでいい感じに動くから」という理由だけで飛びつくと、数ヶ月後に法務レビューで止まる未来がけっこうリアルに見えます。
何がそんなに「うまい話」に見えるのか：Qwen 3.5 は技術的にはかなり魅力的
まず、技術的にどれくらい「刺さるか」を整理します。ここが強いからこそ、ライセンスの話がやっかいになるわけです。
Mac mini で Qwen3.5-9B が「普通にエージェントの頭脳になる」
記事Aのように、Apple Silicon の Mac mini + Ollama で Qwen3.5-9B をエージェントの基盤モデルとして使う構成は、エンジニアからするとかなり現実的です。
- 9B + 量子化であれば、Mシリーズ Mac でも
- 対話はインタラクティブなレイテンシ
- 軽めのツールコール・ReAct ループくらいなら十分回る
- ollama 側は
pullして HTTP で叩くだけなので、既存のローカル LLM 用コードとほぼ差し替え可能 - Qwen 系はエージェント用途（ツール呼び出し・指示追従）での挙動が素直、という評判もある
「クラウドに投げなくても、机の上の Mac が立派なエージェントになる」という体験は、開発者としてはかなりテンションが上がります。
27B が「頑張れば 1GPU で回る」というインパクト
記事Bのベンチマークが示しているのは、
- 27B という中〜大規模モデルが
- 4bit 量子化なら 24GB VRAM でも動く
- 48GB や 2枚構成なら、より精度を落とさずに余裕を持って回せる
- 対話・軽いバッチ用途なら、プロシューマー環境でも現実的に使える
という「27B が手の届くところまで降りてきた」という事実です。
ぶっちゃけ、LLaMA 3 70B を自前ホスティングする気力があるチームはそこまで多くないはずです。一方で 27B なら、頑張ればオンプレで…というラインに入ってくる。ここで Qwen 3.5-27B が「なかなか強い」というのは、インフラ設計的にはかなり刺さります。
なぜこれが「MySQL → Oracle化」に見えるのか：ライセンスの方向転換
では問題のライセンスです。記事Cの論点を噛み砕くと、
- Qwen 2 / 2.5 までは
- 「オープンソースっぽい」「商用も割といけそう」という印象が強かった
- 実際、ローカル LLM の選択肢として「Qwen 使っておけばコスパいいよね」という空気があった
- Qwen 3.5 からは
- 商用利用に明確な制約が入り、
- 条件によっては個別の合意や契約が必要
- 「とりあえずダウンロードして勝手に SaaS に組み込む」はアウトになりうる
正直、これは「OSS っぽい空気」を吸っていた開発者からすると、ギャップがかなり大きいです。
歴史的アナロジー：Elasticsearch, Redis, MySQL で見たパターン
この動き、過去に何度も見たパターンです。
- Elasticsearch：Apache 2.0 → ライセンス変更でクラウド事業者がざわつく
- Redis：OSS 本体 + 商用ライセンスのモジュールで線引き
- MySQL：小規模利用はフリーだが、大規模エンタープライズは Oracle 契約が現実解に
Qwen も同じ匂いがしています。
- 初期：コミュニティに広く使ってもらうために「オープン寄り」の印象で普及
- 3.5：品質と知名度が上がったタイミングで「ビジネスとして回収するフェーズ」に入りつつある
ビジネスとしては当然の流れですし、責めるべき話ではありません。ただ、「最初からそう言ってほしかった」と感じる開発者は多いと思います。
競合との比較で見える「使いどころ」と「やめておいたほうがいいところ」
ここからが本題で、「じゃあ実務でどう判断するの？」という話です。Qwen 3.5 を他の選択肢と比べてみます。
Qwen 3.5 vs LLaMA 3 / Mistral / Phi-3：技術編
ざっくりの印象はこんな感じです（あくまで印象＋公開情報ベース）。
- Qwen3.5-9B
- 8B〜10B クラスとしてはかなり強い
- 多言語（特に中国語）やコード生成、エージェント挙動で高評価
- Qwen3.5-27B
- ローカル運用可能なサイズとしては「質の良い中型モデル」
- LLaMA 3 70B ほどの重さはないが、かなり高い実力帯
- LLaMA 3 8B / 70B
- 英語圏・一般的なベンチマークでは SOTA クラス
- ただし 70B のインフラコストがえぐい
- ライセンスは独自だが、世界中の法務部門が一通り目を通している安心感がある
- Mistral / Phi-3
- Apache 2.0 系が多く、ライセンスはわかりやすい
- モデルサイズはやや小さめだが、「そこそこ賢くて、完全に自由に使える」系
技術的に「1台の GPU / 1台の Mac で限界まで賢いモデルを回したい」という観点だけなら、Qwen 3.5 の 9B / 27B はかなり魅力的です。
Qwen 3.5 vs LLaMA 3 / Mistral / Phi-3：ビジネス編
ところがビジネス視点になると、話がひっくり返ります。
- ライセンスの分かりやすさ・長期安定性で見れば
- Apache 2.0（Mistral open 系 / Phi-3）は圧勝
- LLaMA 3 も「制約はあるが世界中で散々レビュー済み」の安心感
- Qwen 3.5 は
- 商用条件がタイトになり、「とりあえず使っておく」はできない
- 将来のバージョンアップ（Qwen 4, 5…）でさらに条件が厳しくなるリスクもある
正直、「これから数年育てる自社プロダクトの中核モデル」としては、かなり慎重にならざるを得ません。
「ただ、懸念点もあります…」と思うポイント
技術的によく出来ているからこそ見落としがちな「罠」をいくつか挙げておきます。
「ollama pull できる = 自由に商用利用できる」ではない
ぶっちゃけ、ここが一番危険です。
- 開発者の心理として
- Hugging Face や Ollama から
pullできるモデル - → なんとなく「OSS っぽい」「商用もいけそう」と錯覚しがち
- 実際には
- 配布チャネルとライセンスは別問題
- 「簡単にダウンロードできるけど、商用利用は制限あり」というケースは普通にある
CI で勝手に最新版の Qwen 3.5 を引っ張ってきて、そのまま社内ツールに組み込んでいるようなパターンは、気づいたらコンプライアンス違反になっていてもおかしくありません。
ベンダーロックインが「ローカル LLM」という皮をかぶって忍び寄る
ローカル LLM を選ぶ一番の理由のひとつは、
- クラウドベンダーにロックインされにくい
- 自社インフラで完結できる
という点のはずです。
ところがライセンスがコロコロ変わる前提のモデルに依存すると、
- 技術的にはローカルでも
- ビジネス的には特定ベンダー（今回は Alibaba/Qwen）の方針にがっつり縛られる
という、本末転倒な状態になります。
正直、「これなら最初から OpenAI / Anthropic の API を使っていた方が、まだロックイン構造が分かりやすいのでは？」という気持ちすらあります。
モデル切り替えコストは想像以上に高い
「ダメなら LLaMA に差し替えればいいじゃん」という声も聞こえてきそうですが、現場の感覚としてはそんなに簡単ではありません。
- システムメッセージ・プロンプトフォーマット
- Few-shot の例示
- エージェントのツールコールプロトコル
- それに合わせた評価・テストコード
こういったものは、けっこうモデルごとに最適化されてしまいます。
途中で「やっぱりライセンス的に Qwen は厳しそうだから LLaMA に替えます」と決めた瞬間、
- プロンプト調整
- 挙動の差異検証
- 品質劣化に対するチューニング
といった「見えないコスト」が一気に噴き出します。
じゃあ、Qwen 3.5 をプロダクションで使うのか？
ここまでいろいろ書いてきましたが、最終的な自分の結論はかなりシンプルです。
結論：プロダクションの中核には「正直まだ様子見」です
- R&D・技術検証・個人利用：
- Qwen3.5-9B / 27B はかなり魅力的です。
- ローカルエージェントや、プロトタイピング用の「頭脳」としては積極的に試す価値があります。
- 本番プロダクトの中核モデル：
- ここに据えるのは、今のライセンス方針を見る限り、正直まだ様子見です。
- 数年単位での運用を考えると、
- Apache 2.0 系（Mistral open, Phi-3）
- あるいはライセンス条件がすでに世界中で解釈されている LLaMA 3
の方が、総コスト（技術＋法務＋将来のリスク）では有利だと感じます。
もし Qwen 3.5 を採用するなら、これだけはやっておきたい
どうしても Qwen 3.5 を使いたい、あるいは既に使っている場合に、エンジニアとして最低限やっておきたいのはこのあたりです。
- モデルを抽象化するレイヤーを必ず挟む
- 「/generate」や「/chat」のような自前 API を設計し、Qwen 依存の部分をそこに閉じ込める
- アプリ側コードは Qwen 固有のプロンプトフォーマット・ツール仕様に直接触れないようにする
- ライセンスのスナップショットを残す
- いつ・どのバージョンのモデルを・どのライセンス条件で使い始めたかを記録する
- 将来の監査・契約交渉の際に「当時の条件」を説明できるようにしておく
- 法務・コンプライアンスと早めに相談する
- 「OSS っぽいから大丈夫そう」ではなく、
- ちゃんと条文を読み、必要なら Alibaba/Qwen 側に確認を取る
最後に：開発者として「何を大事にするか」を決めるタイミング
Qwen 3.5 の一連の動きは、「性能の良いモデルをローカルで簡単に動かしたい」という開発者の願望と、「モデル提供側のビジネス戦略」のせめぎ合いが、いよいよ顕在化してきた象徴だと思います。
- 目先 3 ヶ月の性能と体験を優先するなら、Qwen 3.5 は確かに魅力的です。
- 3 年スパンでのプロダクトとインフラの健全性を優先するなら、ライセンスがシンプルで将来の読みやすいモデルを選ぶ、という判断も十分ありです。
正直、どちらが正しいという話ではありません。ただ、
「技術的に動くかどうか」だけでなく、「ビジネス的に持続可能かどうか」を、ローカル LLM でもちゃんと考えるフェーズに来た
という認識だけは、そろそろ全員で共有した方がいいと感じています。
Qwen 3.5 は、そのことを強制的に考えさせてくれる、かなり象徴的なケースです。
FAQ：Qwen 3.5 のライセンスと採用判断
Q. Ollama / Hugging Face から入手できる＝商用利用も自由？
A. いいえ。配布チャネルとライセンス条件は別物です。入手しやすさだけで判断せず、条文・制限（用途/規模/再配布/派生物など）を必ず確認してください。
Q. 本番プロダクトの中核に置いていい？
A. 現時点では「様子見」寄りが無難です。中核に据えるなら、法務レビューの前提＋契約/合意が必要になるケースを想定し、代替への切替計画（exit）を先に作るのが安全です。
Q. 先にやっておくべき技術的な保険は？
A. モデルを直接呼ばず、/chat などの自前API・抽象化レイヤを挟んで依存を局所化します。さらにプロンプト/ツールコール仕様・評価セットを“モデル差し替え前提”で管理すると、移行コストが下がります。
Q. ライセンス面で最低限残すべき証跡は？
A. 「いつ・どのバージョンを・どの条件で使い始めたか」を説明できるように、利用開始時点のライセンス文面（URL/スクショ/テキスト）と社内判断メモを保管するのがおすすめです。
コメント