2026年7月24日、NVIDIA・Microsoft・Meta・Dell・IBM・Palantir・Hugging Face・Mistralなどが名を連ねた「Open Weights and American AI Leadership」という共同書簡が公開された。当初は不参加だったOpenAIも同日中に署名に加わり、賛同企業は最終的に50社規模まで広がった一方、AnthropicとGoogleは署名していない。オープンウェイトモデルへの規制強化に反対し、「重みをダウンロード・検査・改変し、自社インフラで動かせるモデルはAI経済へのアクセスを広げ、競争を強化し、セキュリティ研究を後押しする」という主張が骨子だ。この規制論争の分析は、姉妹メディアのUravationメディアで調達リスクの角度から公開済みなので、政策論はそちらに譲る。
この記事で扱いたいのは、もっと地味で、もっと実務的な話だ。実際にオープンウェイトモデルを業務システムに組み込もうとすると、規制論争より先に「このモデルのライセンス、うちのサービスで使って本当に大丈夫なのか」という素朴な疑問にぶつかる。Hugging Faceのリポジトリ直下に置かれたLICENSEファイルだけを見て「MITだから自由」と判断し、モデルカードの本文を読んでいなかった、という光景は検証の現場で何度も見かける。
この記事では、Llama・Gemma・Qwen・DeepSeek・Mistralという主要なオープンウェイトモデルについて、公式のライセンス原文・利用規約・Hugging Face上のライセンスファイルとモデルカードを直接確認したうえで、(1) ライセンス比較表、(2) 「蒸留」が技術と契約のどちらの境界で扱われているか、(3) 重みを差し替えるときの評価スイートによる回帰検知、(4) セルフホスト運用でのセキュリティ実務、の4点を整理する。個別モデルの性能や「どれを選ぶべきか」という選定軸は中国オープンウェイト勢の比較記事など他記事に譲り、本記事はライセンスと運用実務に絞る。原文を確認できなかった条項は「要原文確認」と明記し、読めていないものを読めたことにはしない。
まず結論:主要オープンウェイトモデルのライセンス早見表
2026年7月28日時点で、公式のライセンス原文・利用規約・Hugging Face上のLICENSEファイルおよびモデルカードを直接確認した結果を表にまとめた。同じ「Llama」「Qwen」「DeepSeek」というブランド名でも、モデルやバリアントによってライセンスが変わる点に注意してほしい。
| モデル | ライセンス | 商用利用の条件 | 蒸留・出力学習の扱い | 再配布時の義務 |
|---|---|---|---|---|
| Llama 4(Scout/Maverick等) | Llama 4 Community License Agreement | 前月の月間アクティブユーザーが7億人超なら要Meta許可 | 出力を使った他モデルの学習・改善は許可。ただし配布するモデル名の先頭に「Llama」を付ける義務あり | 「Built with Llama」表示+Noticeファイルの保持 |
| Gemma 3 | Gemma Terms of Use | MAU等の数値上限はなし。Prohibited Use Policyの遵守が条件 | 中間表現や合成出力を使う蒸留は「Model Derivatives」と定義され、元のTerms of Useを継承。出力そのものはModel Derivativesではない | 利用制限条項の転記+契約書写しの提供+Noticeファイル必須 |
| Qwen3系(235B-A22B等の主要オープン版) | Apache License 2.0 | 制限なし | 制限なし(蒸留・出力学習を含め自由) | 著作権表示の保持のみ |
| Qwen2.5-72B-Instruct等の一部モデル | Qwen License Agreement(通称Tongyi Qianwen License) | 月間アクティブユーザー1億人超で別途ライセンス申請が必要 | 出力を使った他モデルの学習は許可。Qwen運営元の回答では「Built with Qwen」等の表示義務があり、派生モデルにはベースのApache条件も併存し得る | 表示義務+両ライセンスの遵守 |
| DeepSeek-R1 / V3(オリジナル配布) | MIT License | 制限なし | 制限なし(蒸留・商用利用ともに自由) | 著作権表示の保持のみ |
| DeepSeek-R1-Distill-Llama-70B等 | リポジトリ表記はMIT。ただし公式モデルカードで「Llama3.3をベースに派生し、元はllama3.3ライセンスの下でライセンスされている」と明記 | 実質的にLlama側の条件(MAU7億人超で別途許可等)も適用対象になり得る | このモデル自体が蒸留の産物。MITとLlamaライセンスの二重構造 | Llama側の帰属表示義務が上乗せされ得る |
| Mistral(Mistral Large 3・Ministral 3系等の主要オープン版) | Apache License 2.0が中心。一部モデルはModified MIT License(月間売上2,000万ドル超で商用契約が必要) | モデルにより異なる。公式ヘルプでも一覧化されておらず個別モデルカードでの確認が必須 | 要原文確認(モデルごとに個別確認が必要) | 著作権表示の保持 |
表の中で最も見落とされやすいのは、DeepSeek-R1-Distill-Llama-70Bの行だ。「MIT」という文字だけを見て安心すると、ベースにしたLlamaの条件を見落とす。この構造については後述する。
ライセンスを読むときに見る3つの論点
オープンウェイトモデルのライセンスは長文で読みにくいが、業務導入の判断に直結するのは実質的に次の3点に絞られる。
- 商用利用の条件:無条件で商用利用できるのか、それとも一定規模(MAUや売上)を超えると別途契約が必要になるのか。Llama 4は「前月MAU7億人超」、Qwen License Agreement版は「MAU1億人超」、Mistralの一部モデルは「月間売上2,000万ドル超」が閾値になっている。
- 再配布・帰属表示の義務:モデルやその派生物を外部に配布する場合、著作権表示だけで済むのか、「Built with Llama」のような表示や、モデル名の命名規則まで求められるのか。
- 蒸留・出力を使った学習の扱い:モデルの出力を使って別のモデルを学習させる(蒸留する)ことが許可されているか、許可されている場合はどんな条件が付くか。ここが最も解釈の揺れが大きい。
「蒸留」は技術と契約の境界で揺れる
「蒸留」という言葉は技術的には「大きなモデルの出力や中間表現を使って小さなモデルを学習させる手法」を指すが、ライセンスの世界では「どこからが蒸留で、どこまでが許可されるか」の線引きがモデルごとに違う。
Llama 4 Community License Agreementでは、「Llama Materialsまたはその出力・結果を使ってAIモデルを作成・ファインチューニング・改善し、それを配布または提供する場合」という条項があり、条件付きで許可されている。ただし配布するモデルの名前の先頭に「Llama」を付ける義務が課される。過去のLlama 3世代では他社の大規模言語モデルの改善に出力を使うことをより強く制限する条項があったとされ、世代によって扱いが変わってきた経緯がある点は覚えておきたい。
Gemma Terms of Useでは、「Model Derivatives」という概念が定義されており、「重み・パラメータ・演算、またはGemmaの出力のパターンを転写して作られた機械学習モデル」に加え、「中間データ表現を使う蒸留手法、またはGemmaが生成した合成出力を使う手法」も含まれるとされている。一方で「出力そのものはModel Derivativesとみなさない(Outputs are not deemed Model Derivatives)」とも明記されている。つまりGemmaの出力を単に生成するだけならGemma Terms of Useの派生物扱いにはならないが、その出力を学習データとして別モデルを訓練すればModel Derivativesとなり、元の利用規約を引き継ぐ、という2段構えの設計になっている。
Qwenについては、Qwen2.5-72B-Instructのライセンスを巡るHugging Face上の質問に対して、Qwen運営元のメンテナーが「出力の利用は許可される。ただしファインチューニングしたモデルはQwen側の表示義務(Built with QwenまたはImproved using Qwen)とベースモデルのライセンス(Apache 2.0など)の両方を満たす必要がある」という趣旨の回答をしている。つまりQwenも「禁止」ではなく「条件付き許可+表示義務」という設計だ。
そしてDeepSeek-R1-Distill-Llama-70Bが、この論点の一番わかりやすい実例になっている。DeepSeek自身が公開しているモデルカードには「DeepSeek-R1-Distill-Llama-70B is derived from Llama3.3-70B-Instruct and is originally licensed under [llama3.3 license]」という一文がある。リポジトリ直下のLICENSEファイルはMITだが、これはDeepSeekが自社のコードと配布条件に付けたライセンスであって、蒸留元であるLlama 3.3の重みに紐づく条件(MAU7億人超での許可要件や帰属表示義務)は別レイヤーとして残る。「蒸留してMITで再配布すれば、元のライセンスから自由になる」わけではない、という良い実例だ。
ここまでの内容を機械的にスクリーニングするための最小スクリプトを載せておく。ただし、これはあくまで一次スクリーニング用であり、最終判断はモデルカードの本文を人間の目で読むことを前提にしてほしい。
# 動作環境: Python 3.11+, huggingface_hub>=0.30
# 必要パッケージ: pip install huggingface_hub
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from huggingface_hub import HfApi
api = HfApi()
targets = [
"meta-llama/Llama-4-Scout-17B-16E",
"google/gemma-3-27b-it",
"Qwen/Qwen3-235B-A22B",
"Qwen/Qwen2.5-72B-Instruct",
"deepseek-ai/DeepSeek-R1",
"deepseek-ai/DeepSeek-R1-Distill-Llama-70B",
"mistralai/Mistral-Large-Instruct-2411",
]
for repo_id in targets:
info = api.model_info(repo_id)
license_tag = next(
(t.split(":", 1)[1] for t in info.tags if t.startswith("license:")),
"unknown",
)
print(f"{repo_id:45s} -> license tag: {license_tag}")
# license タグだけでは「蒸留元モデルのライセンスが別途適用される」
# ようなケースを検知できない。必ずモデルカードのREADME本文も読むこと。
実装ユースケース別の判断
同じモデルでも、何をするかによって効いてくる条項が変わる。実務でよくある3パターンに分けて整理する。
- 社内システムへの組み込み(推論のみ、配布なし):多くのケースでライセンス上の摩擦は小さいが、自社サービスの月間アクティブユーザーがMAU閾値(Llama 4なら7億人、Qwen License Agreement版なら1億人)に近づいている場合や、Prohibited Use Policy(Gemma)に抵触する用途(医療診断の断定的判断など)がないかは確認が必要になる。
- ファインチューニングして外部に配布・公開する:帰属表示(Built with Llama / Built with Qwen等)、モデル名の命名規則、再配布時の契約書写しの提供義務(Gemma)といった手続き的な義務が発生する。これを見落とすと「技術的には問題ないが規約違反」という状態になる。
- モデルの出力を使って別モデルを学習させる(蒸留):Llama・Qwenは条件付き許可(帰属表示義務あり)、Gemmaは出力そのものは制限しないが学習に使うと派生物として扱われる、DeepSeek-R1オリジナルは制限なし。ただし蒸留元がLlama/Qwenベースなら、その時点で元のライセンスが上乗せされる。
【要注意】よくある失敗パターンと回避策
失敗1:リポジトリ直下のLICENSEファイルだけ見て安心する
NG例: DeepSeek-R1-Distill-Llama-70BのLICENSEがMITだったので、Llamaの条件は一切関係ないと判断した。
OK例: モデルカードのREADME本文まで読み、「どのベースモデルから派生したか」を確認する。派生元のライセンスが別レイヤーで残っていないかをチェックする。
なぜ重要か:蒸留・ファインチューニング済みモデルは「配布者自身のライセンス」と「ベースモデルのライセンス」が二重に存在し得る。LICENSEファイルは前者しか表していないことが多い。
失敗2:「Qwen」や「Llama」というブランド名だけでライセンスを一括りにする
NG例: 「Qwenは全部Apache 2.0だから自由に使える」と決め打ちした。
OK例: 使う予定の具体的なモデルID(例:Qwen3-235B-A22B vs Qwen2.5-72B-Instruct)ごとにLICENSEファイルを確認する。
なぜ重要か:同じQwenブランドでも、モデルの規模や世代によってApache 2.0とQwen License Agreement(MAU1億人条項付き)が混在している。ブランド名で判断すると条件付きライセンスのモデルを見落とす。
失敗3:規制論争のニュースを見て「オープンウェイトなら何でも自由」と誤解する
NG例: 「業界団体がオープンウェイトモデルの規制強化に反対している」という報道を見て、ライセンス面でも制約が少ないと思い込んだ。
OK例: 業界の政策論争(重みを公開すべきか)と、個別モデルのライセンス条項(公開された重みをどう使ってよいか)は別の話として、それぞれ別に確認する。
なぜ重要か:「オープンウェイト」は重みが入手可能であることを意味するだけで、利用条件が自由であることを保証しない。むしろLlamaやQwenのように商用利用に閾値があるモデルの方が主流に近い。
重みを差し替えるときの運用:評価スイートで回帰を検知する
ライセンスをクリアして業務に組み込んだ後も、運用は終わらない。オープンウェイトモデルは提供元がリビジョンを更新したり、量子化版・修正版が同じリポジトリのmainブランチに上書きされたりする。ID固定の問題については無日付Claude IDの落とし穴を扱った記事で触れたが、オープンウェイトモデルでは「リビジョン(コミットハッシュ)を固定していないと、いつの間にか重みが変わっている」という同種の事故が起きやすい。
最低限の対策は、重みを固定リビジョンで取得し、差し替え候補に対して固定の評価スイートを走らせ、スコアの劣化がないかを確認してからデプロイすることだ。評価ハーネスの設計そのものはAIエージェント評価への組み込み方を扱った記事で詳しく扱っているので、ここでは重みの差し替え判断に絞った最小パターンを示す。
# 動作環境: Python 3.11+, huggingface_hub>=0.30
# 目的: 固定リビジョンでスナップショットを取得し、
# 自作の評価スイートで新旧の重みを比較してから本番反映する最小パターン。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from huggingface_hub import snapshot_download
CURRENT_REV = "a1b2c3d" # 本番で使っている固定コミットハッシュ
CANDIDATE_REV = "e4f5g6h" # 差し替え候補のコミットハッシュ
REGRESSION_THRESHOLD = 0.03 # 3ポイント以上の劣化でブロック
def load_pinned(repo_id: str, revision: str) -> str:
# revisionを明示しない場合、既定でmainブランチの最新に引きずられ、
# 気づかないうちに重みが変わる事故につながる。
return snapshot_download(repo_id=repo_id, revision=revision)
def run_eval_suite(model_path: str) -> dict:
# ここは自社ユースケースに合わせた固定タスク×正解ペアを回す部分。
# 既存の評価ハーネスに接続する場合はこの関数だけ差し替えればよい。
raise NotImplementedError
repo_id = "meta-llama/Llama-4-Scout-17B-16E"
current_scores = run_eval_suite(load_pinned(repo_id, CURRENT_REV))
candidate_scores = run_eval_suite(load_pinned(repo_id, CANDIDATE_REV))
for task, base_score in current_scores.items():
delta = candidate_scores[task] - base_score
if delta < -REGRESSION_THRESHOLD:
raise SystemExit(f"回帰検知: {task} が {delta:.3f} 悪化。デプロイを中止します。")
print("回帰なし。差し替え候補のリビジョンを本番に反映してよい。")
セルフホストのセキュリティ実務:供給元検証と改ざん対策
ライセンスと運用の次に見落とされがちなのが、重みファイル自体の安全性だ。従来のPyTorch形式(.bin/.pt)はPython標準のpickleを使ったシリアライズ形式で、読み込み時に任意コードが実行され得るという構造的なリスクを抱えている。Hugging Face上で悪意あるpickleペイロードを仕込んだモデルが繰り返し確認されてきたほか、pickleファイルの悪性判定に使われる主要オープンソースツール「PickleScan」自体にも、2025年12月にCVSS 9.3相当の複数のゼロデイ脆弱性(CVE-2025-10155/10156/10157)が見つかっている。
Hugging Faceが開発したsafetensors形式は、ヘッダーと生バッファだけで構成され、読み込み時に実行コードパスを持たない設計になっており、この種のリスクを構造的に回避できる。セルフホストでオープンウェイトモデルを運用する場合の最低限の実務は次の3つだ。
- pickle系フォーマットを本番パイプラインで受け付けない:
.bin/.pt/.pklは変換してから使うか、そもそも読み込みを禁止する。 - 固定リビジョンからのみ取得する:前章の評価スイートの話と同じ理由で、
mainブランチの最新を無条件に信頼しない。 - ダウンロード後にチェックサムを突き合わせる:ローカルのファイルハッシュと、取得元リポジトリの該当リビジョンの情報を突き合わせ、改ざんや取り違えがないかを確認する。
# 動作環境: Python 3.11+, huggingface_hub>=0.30
# 目的: pickle系フォーマットの読み込みを止め、safetensors形式のみを許可する最小チェック。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 注: HfApi().model_info()のsiblings配下の詳細な属性(sha/lfs情報等)は
# huggingface_hubのバージョンで変わるため、実装前に公式ドキュメント
# (https://huggingface.co/docs/huggingface_hub)で最新のAPIを確認すること。
import hashlib
import pathlib
UNSAFE_SUFFIXES = {".bin", ".pt", ".pkl", ".ckpt"}
def reject_pickle_formats(local_dir: str) -> None:
for path in pathlib.Path(local_dir).rglob("*"):
if path.suffix in UNSAFE_SUFFIXES:
raise ValueError(
f"pickle系フォーマットを検出: {path}。"
"safetensors形式のみ許可してください。"
)
def local_sha256(path: pathlib.Path) -> str:
h = hashlib.sha256()
with open(path, "rb") as f:
for chunk in iter(lambda: f.read(1 << 20), b""):
h.update(chunk)
return h.hexdigest()
# 使い方: ダウンロード直後にreject_pickle_formats()を通し、
# local_sha256()で算出したハッシュを、事前に別チャネル(社内台帳等)で
# 記録しておいた「正規リビジョンのハッシュ一覧」と突き合わせる。
ツール面での対策(サプライチェーン検査、権限最小化等)はAIエージェントを守るセキュリティツールの比較記事も参考になる。モデル配布経路そのものの検証は、AIエージェントのツール呼び出しのセキュリティとは別レイヤーの話として、混同せずに設計しておきたい。
よくある質問
Q. オープンウェイトモデルの出力を使って別のモデルを学習させる「蒸留」は、どのライセンスなら禁止されていますか?
本記事で原文を確認できた範囲では、Llama 4・Gemma 3・Qwen(Apache版・Qwen License Agreement版いずれも)・DeepSeek-R1オリジナルは、出力を使った学習(蒸留)自体を明確に禁止してはいません。ただし「配布するモデル名にLlama/Qwenを接頭辞として付ける」「Built with Llama/Built with Qwenを表示する」といった帰属表示義務や、Gemmaのように学習に使うとModel Derivativesとして元のTerms of Useを継承する仕組みが課される点には注意が必要です。過去のLlama 3世代では他モデルの改善への利用をより強く制限する条項があったとされ、モデル世代ごとに条件が変わる前提で、使う直前に必ず原文を確認してください。
Q. DeepSeek-R1-Distill-Llama-70Bのように「MIT License」と表示されているのに、Llamaのライセンスにも従う必要があるのはなぜですか?
DeepSeek-R1-Distill-Llama-70Bのリポジトリ直下のLICENSEファイルはMITですが、モデルカードのREADMEには「Llama3.3-70B-Instructから派生し、元はllama3.3ライセンスの下でライセンスされている」と明記されています。DeepSeek自身のコードと配布条件はMITでも、ベースにしたLlamaの重みに紐づく条件(MAU7億人超で別途許可が必要、帰属表示義務など)は別レイヤーで残るということです。LICENSEファイルの表記だけで判断せず、モデルカード本文まで読むことが必須です。
Q. 重みを差し替えるとき、何を根拠に「安全に更新できた」と判断すればいいですか?
公式のバージョン番号やリリースノートの記載だけでなく、固定した評価スイートを新旧の重みそれぞれに対して実行し、タスクごとのスコア差分を確認することが実務上の最低ラインです。評価タスクの設計自体は、自社ユースケースの精度・レイテンシ・コストに応じて自作するか、既存の評価ハーネスに組み込む形で運用します。
参考・出典
- NVIDIA, Microsoft, Meta Lead 25-Company Push Against Restrictions on Open-Weight AI Models — Compsmag(参照日: 2026-07-28)
- Llama 4 Community License Agreement(LICENSEファイル) — Meta / Hugging Face(参照日: 2026-07-28)
- Gemma Terms of Use — Google AI for Developers(参照日: 2026-07-28)
- Clarification on Qwen License Agreement Regarding Output Usage — Hugging Face / Qwen運営元回答(参照日: 2026-07-28)
- DeepSeek-R1 LICENSE(MIT License) — Hugging Face(参照日: 2026-07-28)
- DeepSeek-R1-Distill-Llama-70B モデルカード — Hugging Face(参照日: 2026-07-28)
- Under which license are Mistral's open models available? — Mistral AI 公式ヘルプ(参照日: 2026-07-28)
- PyTorch Users at Risk: Unveiling 3 Zero-Day PickleScan Vulnerabilities — JFrog(参照日: 2026-07-28)
- Remote Code Execution With Modern AI/ML Formats and Libraries — Unit 42, Palo Alto Networks(参照日: 2026-07-28)
まとめ:今日から始める3つのアクション
- 今日やること:自社が使っている(使おうとしている)オープンウェイトモデルのリポジトリで、LICENSEファイルだけでなくモデルカードのREADME本文まで読み、「ベースモデルから派生していないか」を確認する。
- 今週中:重みの取得を固定リビジョン(コミットハッシュ)に切り替え、
mainブランチの最新に無条件で追従しない構成にする。 - 今月中:重み差し替え前に走らせる固定評価スイートと、pickle系フォーマットを排除するチェックを、デプロイパイプラインに組み込む。
この記事を読んでライセンス・運用の論点が整理できてきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
著者:佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。100社以上の企業向けAI研修・導入支援に携わる。
