Qwen3.8の商用利用、契約を分けて確認

APIを契約したのに、自社サーバーへQwen3.8のウェイトを配置する段階で公開が止まった。

最短の解決策は、APIのサービス契約、公開ウェイトのLICENSE、推論コードのライセンスを別々に確認することです。正式なウェイトLICENSEを確認できるまでは、APIの隔離検証と切り替え可能な構成だけを進め、自社運用ウェイトの本番投入、顧客納品、再配布は凍結してください。

このページは、Qwen3.8を商用製品、AIエージェント、顧客向け案件に接続する開発責任者向けです。法務・コンプライアンス担当者は適用文書を特定し、技術購買担当者は契約主体と地域条件を確認できます。

※最終更新：2026年8月15日。公式ブログ、公式モデル組織ページ、Qwen Cloudの契約文書を確認しています。正式なLICENSE、NOTICE、モデルカード、地域付録が追加または変更された場合は、結論を再確認してください。

同じモデル名でも、許可される行為は同じではありません

典型的な失敗は、チームがQwen3.8-MaxをAPIで呼び出せたことを根拠に、同じモデルのウェイトをダウンロードして顧客環境へ納品するケースです。APIで許可されるのは、まず契約されたサービスへのアクセスです。そこからウェイトの複製、改変、再配布まで自動的に許可されるわけではありません。

Qwen CloudのCustomer Agreementは、利用者と地域に応じた契約主体、サービス規則、地域別提供条件を定めています。契約の発効日は2026年4月2日で、重要な変更は原則として掲載後15日で効力を持つとされています。ただし、新サービスや法令対応などの例外もあるため、契約ページの保存日時まで記録してください。
Qwen CloudのCustomer Agreementと地域別契約主体

過去のQwen3では、公式発表が複数の公開ウェイトをApache 2.0として説明していました。しかし、その事実をQwen3.8の結論へ流用することはできません。モデル名が似ていても、対象バージョンに紐づくLICENSEが別に存在するためです。
過去のQwen3公式発表における公開ウェイトの説明

API契約と公開ウェイトを混同すると、どこで止まるのか

Qwen3.8 APIを商用製品で利用できるかは、APIの契約主体、提供地域、アカウント種別、サービス規則、入力・出力の扱いを確認して判断します。Qwenの利用ポリシーは商用利用を含むプラットフォーム、API、公開モデルに適用されると説明していますが、個別サービスの契約条件や禁止用途を置き換える文書ではありません。
Qwenの利用ポリシーにおける商用利用の記載

Qwen3.8 APIは商用製品へそのまま組み込めるのですか。

APIのサービス契約と利用ポリシーが、予定する用途、契約主体、利用地域に適用されるなら、API接続を商用検証の候補にできます。ただし、これはオンラインAPIの利用判断です。APIの応答を利用した製品機能と、モデルウェイトを自社へ持ち込む行為は、同じ許可として扱わないでください。

APIを使った後に、自社サーバーへ公開ウェイトを置けますか。

API契約に明示的な権利がない限り、置けるとは判断できません。公開ウェイト側のLICENSE、NOTICE、モデルカードが、対象モデルの取得、改変、内部利用、顧客への提供、再配布をどこまで認めるかを確認する必要があります。

Qwen Cloudの契約文書では、地域別提供や第三者サービスについて、別の条件や契約が適用される可能性が示されています。会社の登記地、利用者の所在地、実際に処理する地域、契約アカウントの請求先は、同じ場所とは限りません。
地域別提供と第三者契約の扱いを含むQwen Cloudの契約本文

正式LICENSEが見つからないときは、伝聞を放行条件へ変換する

2026年8月15日時点で、Qwen3.8の公開ウェイトに直接紐づく正式なLICENSEを、確認可能なQwen公式ブログおよび公式モデル組織ページから特定できない場合、商用可否を推測で埋めてはいけません。

地理制限やrevenue-shareについては、現時点では報道または関係者情報として扱います。正式なLICENSEや公式契約で、対象となる主体、行為、売上の定義、発動条件が示されるまでは、確定した支払義務や地域制限として記載しないでください。
Qwen3.8の公開ウェイトと条件に関する報道

Qwen3.8のrevenue-shareはAPI契約向けですか、それとも公開ウェイト向けですか。

報道だけでは確定できません。見出しにrevenue-shareと書かれていても、対象がAPI利用者なのか、公開ウェイトを商用利用する大規模事業者なのか、特定地域の契約者なのかは、正式文書の定義で確認する必要があります。発表前は「調査中のリスク」として予算・法務レビューに残し、義務として確定させないのが安全です。

注意：過去のQwenモデルに付属したApache 2.0のLICENSEは、Qwen3.8の正式な権利証拠ではありません。対象モデルのリポジトリ、コミット、LICENSE本文を保存できないなら、公開ウェイトの本番放行記録は完了扱いにしないでください。

コード、量子化、微調整を重ねるほど、確認対象は増えます

モデルウェイトだけを確認しても、実際の製品には推論コード、デプロイフレームワーク、量子化ファイル、微調整アダプター、評価データ、外部プラグインが含まれます。それぞれの配布元、バージョン、NOTICE、改変条件を対応づけてください。

Qwen3公式資料でも、モデル利用には対応ライブラリや推論環境が関係します。つまり「モデルが商用利用可能」でも、採用した周辺コードやデータの条件まで一括で緩和されるわけではありません。
Qwen3公式モデルページの利用ライブラリと推論方法

微調整モデルを顧客へ渡す場合は、元ウェイトだけでなく、アダプター、設定ファイル、推論スクリプト、学習データの権利も確認します。顧客へAPI経由の機能だけを提供する場合と、微調整済みウェイトを納品する場合では、確認すべき行為が異なります。

どの提供形態なら進められるかを条件で分ける

「商用利用できるか」を一つのYes・Noで処理すると、APIの検証まで不必要に止めるか、反対に自社運用ウェイトまで誤って本番投入します。次の条件で切り分けてください。

• API契約、利用地域、用途、アカウント主体を確認できるなら、API接続の隔離検証を進めます。
• 正式なウェイトLICENSE、NOTICE、モデルカードを対象バージョンとともに保存できるなら、自社運用の法務確認へ進みます。
• LICENSEはあるが、再配布、顧客納品、地域、revenue-shareの適用範囲が不明なら、公開・納品は保留します。
• APIと自社運用を同じインターフェースで切り替えられるなら、二系統の検証を続けます。
• 契約主体や地域付録を確認できないなら、購買担当者が契約先へ照会するまで本番放行しません。
• 正式文書が更新され、保存した版と差分があるなら、以前の承認を自動継続しません。

この条件分岐で、最終結論は4種類にします。

1. APIのみ本番可：API契約の範囲に限定する。
2. 隔離検証のみ：ログ、顧客データ、外部公開を制限する。
3. 正式LICENSE待ち：自社運用、納品、再配布を止める。
4. 代替モデルへ切り替え：AIエージェントのバックエンドを変更する。

第1段階：4担当で同じ放行記録を作る

1. 開発担当が交付形態を固定する

API呼び出しなのか、ウェイト配布なのか、推論サーバーのホスティングなのかを記載します。モデル名だけでなく、取得URL、コミット、ハッシュ、量子化形式、アダプターの有無を保存します。

2. 法務担当が適用文書を分離する

APIにはCustomer Agreementとサービス規則、ウェイトにはLICENSEとNOTICE、コードにはコードLICENSEを割り当てます。発見できない文書は「確認済み」ではなく「未確認」と記録します。

3. 購買担当が地域と契約主体を確認する

会社の登記地、請求先、利用者の所在地、推論処理地域、顧客の所在地を分けます。Qwen Cloudの契約主体が登録時の所在地や請求先により変わる点も、契約記録へ残してください。

4. リリース担当が停止条件を設定する

LICENSEの追加、地域付録の変更、revenue-shareの正式化、モデル版の更新を再審査トリガーにします。更新時に承認者と承認日時が残る仕組みにします。

5. AIエージェントに切り替え口を残す

モデル呼び出し部分を自社コードから分離し、API、自社運用、代替モデルを同じ抽象インターフェースへ接続します。障害時だけでなく、契約条件が変わった場合にもロールバックできる構成が必要です。

実際の検証用ホストを準備する場合は、クラウドMacの検証環境を選ぶ手順と、Macの管理コンソールで接続状態を確認する方法を先に確認してください。重要なのは、API検証と自社運用検証を同じ成果物として扱わず、別々のログと承認記録にすることです。

今の構成とMacHTMLの検証環境を比較する

既存の共有クラウドや開発者の手元だけで確認すると、環境差分、権限の所在、バージョン固定の難しさが残ります。特に自社サーバーへ直接載せる前に、推論コードの互換性、ログ保存、APIへの切り替え、顧客データを使わない隔離運用を一つの環境で試す必要があります。

その点、MacHTMLのレンタル環境なら、契約条件が確定するまでの一時的な検証場所として使い分けやすくなります。レンタルは長期の固定負荷や物理アクセサリが必要な運用の代替ではありませんが、正式LICENSE待ちの期間に、バージョン留保、接続試験、切り替え演習を進める用途には適しています。

本番投入の可否は、Qwen3.8の名称や報道見出しではなく、対象モデルに紐づく正式文書で決めてください。まず隔離したMac環境でAPIと自社運用を分けて検証し、LICENSEのURL、版、確認日、承認者を揃えたうえで、自社運用を続けるかAPI路線へ戻すかを選ぶのが安全です。レンタルによる検証を始める場合は、MacHTMLの利用プランと期間を確認し、顧客データを持ち込まない検証計画から着手してください。

これは法的判断そのものではありません。顧客納品、地域制限、収益分配、再配布が関係する場合は、正式文書を提示して専門の法律専門家へ確認してください。