# オープンウェイトLLMの商用ライセンス選定：Apache 2.0 / Llama / Qwen / Gemma を『設計判断』として扱う

> Llama・Qwen・GemmaなどオープンウェイトLLMを業務で使うとき、商用利用は本当に自由か。『オープンウェイト ≠ オープンソース ≠ 自由に使える』という落とし穴と、商用可否・MAU上限・帰属表示・派生物の命名・利用制限という選定軸を、実際に量子化オープンモデルを商用プロダクトで運用した経験から、機械可読なライセンス対照表とともに解説します（法的助言ではありません）。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: 生成AI, LLM, Llama, オープンウェイト, 発注, コスト最適化
- URL: https://tomodahinata.com/blog/open-weight-llm-commercial-license-guide-apache-llama-qwen-gemma

## 要点

- 『オープンウェイト ≠ オープンソース ≠ 自由に使える』。重みが公開されていても、商用利用の条件はライセンスごとに大きく異なる
- Apache 2.0（多くのQwen3など）は最も自由——商用可・MAU上限なし・帰属表示のみ。ロックインを避けたい商用案件の第一候補
- Llama Community Licenseは商用可だが『月間7億MAU超は別途許諾』『Built with Llama表示』『派生物の命名規則』『利用ポリシー』の条件付き
- Gemma等は商用可でも利用制限ポリシーを下流へ引き継ぐ義務がある。OSI承認のオープンソースではない点に注意
- ライセンスは後付けの確認事項ではなく、最初に決める設計判断（license-as-architecture）。要件に対し過剰な制約を負わないモデルを選ぶ

---

最初に結論を述べます。**「オープンウェイト」のLLMでも、商用利用が無条件に自由とは限りません。「オープンウェイト ≠ オープンソース ≠ 自由に使える」——この3つは別物です。** 重み（weights）が公開されていても、その使用条件はライセンスごとに大きく異なり、「月間アクティブユーザー数の上限」「帰属表示の義務」「派生モデルの命名規則」「利用制限ポリシーの下流への引き継ぎ」といった条件が付くものがあります。これを「あとで確認すればいい」と後回しにすると、本番投入の直前や事業拡大のタイミングで、ライセンス違反や予期せぬ制約に直面します。**ライセンスは、モデルを選ぶ最初の段階で決める『設計判断』**として扱うべきです。

本記事は、私が**量子化したオープンモデル（vLLM上のQwen3、4bit量子化Llama など）を商用プロダクト（クラウドワークス契約ランキング1位のAI動画基盤）で運用**した経験をもとに、オープンウェイトLLMの商用ライセンスの選定軸を、発注者・意思決定者の視点で整理します。

> **重要な免責**: 本記事は法的助言ではありません。ライセンスの正確な条件は改定されます。実際の採用前に、各モデルの**最新のライセンス正文**を確認し、必要に応じて法務・弁護士に相談してください。本記事は「何を確認すべきか」の地図を提供するものです。

---

## 1. 「オープンウェイト」という言葉の罠

まず用語を正確にします。混同されがちな3つは、まったく別の概念です。

| 概念 | 意味 |
|---|---|
| **オープンウェイト** | モデルの重みがダウンロード可能。ただし使用条件はライセンス次第 |
| **オープンソース（OSI準拠）** | OSI承認のライセンスで、利用・改変・再配布の自由が保証される |
| **自由に使える** | 商用・改変・再配布に実質的な制約がない（上の2つと必ずしも一致しない） |

多くの「オープンウェイトLLM」は、**重みは公開しているが、OSI承認のオープンソースではない**独自ライセンスを採用しています。これらは「コミュニティライセンス」「利用規約」などと呼ばれ、商用利用を許しつつも、**特定の条件**を課します。「オープン」という言葉の響きで「自由に使える」と早合点しないことが、最初の落とし穴を避ける鍵です。

---

## 2. 商用ライセンスを分ける5つの軸

オープンウェイトLLMのライセンスは、次の5軸で評価できます。発注者・採用者が確認すべきチェックリストです。

1. **商用利用の可否**——商用が許可されているか、研究用途限定か。
2. **規模の上限（MAU等）**——一定のユーザー規模を超えると別途許諾が必要か。
3. **帰属表示の義務**——「Built with X」のような表示、ライセンス・通知の保持が必要か。
4. **派生物の扱い**——ファインチューニングした派生モデルの命名規則・再配布条件。
5. **利用制限ポリシー**——禁止用途（許容利用ポリシー）があり、それを下流に引き継ぐ義務があるか。

これらを機械可読な形で整理すると、選定が明快になります。型で表現することで、抜け漏れなく比較できます。

```ts
/** ライセンスの義務を機械可読に表す。採用判断を構造化し、確認漏れを防ぐ。
 *  ※ 値は記事執筆時点の一般的な理解。採用前に必ず最新の正文を確認すること（法的助言ではない）。 */
interface LicenseProfile {
  readonly family: string;
  readonly license: string;
  readonly osiOpenSource: boolean;          // OSI承認のオープンソースか
  readonly commercialUse: "permitted" | "permitted-with-conditions" | "research-only";
  readonly scaleCap?: string;               // 例: 月間アクティブユーザー数の上限
  readonly attributionRequired: boolean;    // 帰属表示の義務
  readonly derivativeNaming?: string;       // 派生物の命名規則
  readonly acceptableUsePolicy: boolean;    // 利用制限ポリシーの引き継ぎ義務
}

// 代表例（執筆時点の一般的理解。正確性は各正文で要確認）
const PROFILES: readonly LicenseProfile[] = [
  {
    family: "Qwen3（多くの dense モデル）",
    license: "Apache 2.0",
    osiOpenSource: true,
    commercialUse: "permitted",
    attributionRequired: true,              // ライセンス・通知の保持
    acceptableUsePolicy: false,
  },
  {
    family: "Llama（Meta）",
    license: "Llama Community License",
    osiOpenSource: false,
    commercialUse: "permitted-with-conditions",
    scaleCap: "月間アクティブユーザー7億超は別途許諾が必要",
    attributionRequired: true,              // "Built with Llama" 等
    derivativeNaming: "派生モデル名に 'Llama' を冠する規則",
    acceptableUsePolicy: true,
  },
  {
    family: "Gemma（Google）",
    license: "Gemma Terms of Use",
    osiOpenSource: false,
    commercialUse: "permitted-with-conditions",
    attributionRequired: true,
    acceptableUsePolicy: true,              // 禁止用途を下流へ引き継ぐ義務
  },
] as const;
```

---

## 3. 主要ライセンスの実務的な読み解き

### Apache 2.0 / MIT 系（最も自由）

**多くのQwen3（dense）モデルや、Mistralの一部公開モデルなどがApache 2.0**を採用しています。これは**OSI承認のオープンソース**で、商用利用・改変・再配布が広く許され、**ユーザー規模の上限もありません**。義務は主に「ライセンスと著作権表示の保持」程度です。

**ロックインを避けたい商用案件では、Apache 2.0 / MIT 系が第一候補**になります。私がAI動画ローカライズ基盤で翻訳にQwen3系を採用した理由の一つも、許諾の制約が軽く、商用プロダクトに組み込みやすかったことです。「将来の制約リスクを最小化する」という意味で、ライセンスの自由度は立派な技術選定軸です。

### Llama Community License（商用可・条件付き）

**Llama（Meta）は商用利用を許可**しますが、いくつかの条件が付きます。代表的なのは、

- **規模の上限**——製品の月間アクティブユーザーが一定規模（7億）を超える場合、Metaから別途ライセンスを得る必要がある。（多くの企業には実質的に無関係だが、超大規模サービスには効く）
- **帰属表示**——「Built with Llama」の表示や、ライセンス条項の保持。
- **派生物の命名**——Llamaを使ってファインチューニングした派生モデルの名前に、規定の冠を付ける。
- **許容利用ポリシー**——禁止される用途が定められている。

これらは多くの実務では満たせる条件ですが、**「OSI承認のオープンソースではない」**点は認識しておくべきです。「Llamaは自由に使える」ではなく「Llamaは条件付きで商用利用できる」が正確です。

### Gemma 等（商用可・利用制限の引き継ぎ）

**Gemma（Google）も商用利用を許可**しますが、**利用制限ポリシー（禁止用途）を下流に引き継ぐ義務**があり、出力の扱いにも規約が及びます。これもOSI承認のオープンソースではありません。再配布や、自社プロダクトに組み込んで第三者へ提供する場合は、この引き継ぎ義務に注意が必要です。

---

## 4. ライセンスを「設計判断」として扱う（license-as-architecture）

最も重要な実務的教訓は、**ライセンスを後付けの確認事項ではなく、最初に決める設計判断として扱う**ことです。理由は3つあります。

1. **後から変えるのは高コスト**——本番投入後にライセンス問題が発覚し、別モデルへ載せ替えるのは、再評価・再検証・再デプロイの大仕事です。
2. **事業拡大で効いてくる**——MAU上限のようなスケール条件は、事業が成功したまさにその時に問題化します。
3. **データ主権・出力の権利と絡む**——ライセンスは、生成された出力の権利や、データの扱いとも関わります。

実装面では、[プロバイダ抽象](/blog/tts-self-hosting-vs-elevenlabs-cost-data-sovereignty-guide)でモデルを差し替え可能にしておくことで、「ライセンス条件が変わったら別モデルへ移る」という選択肢を残せます。これは[API vs 自前ホスティングの意思決定](/blog/generative-ai-cost-api-vs-self-hosting-decision-guide)とも地続きの、ロックイン回避の設計です。

> **発注者への含意**: AIを業務に組み込むベンダーに、「採用するオープンウェイトモデルのライセンスは何か」「商用利用・規模・帰属・派生・利用制限の条件をどう満たすか」を確認してください。これに即答できないベンダーは、ライセンスリスクを見落としている可能性があります。

---

## よくある質問（FAQ）

### Q. オープンウェイトのLLMは、商用利用が自由ですか？

ライセンス次第です。「オープンウェイト（重みが公開）」と「商用利用が自由」は別物です。Apache 2.0（多くのQwen3など）は商用も含めて広く自由ですが、Llama Community LicenseやGemma Terms of Useは商用利用を許しつつ、規模上限・帰属表示・利用制限の引き継ぎといった条件を課します。採用前に各ライセンスの正文を確認してください。

### Q. Llamaは商用利用できますか？

できますが、条件付きです。Llama Community Licenseは商用利用を許可する一方、製品の月間アクティブユーザーが一定規模（7億）を超える場合はMetaから別途許諾が必要、「Built with Llama」の帰属表示、派生モデルの命名規則、許容利用ポリシーの遵守、といった条件があります。多くの企業には満たせる条件ですが、OSI承認のオープンソースではない点に注意してください。

### Q. ロックインや制約を避けたい場合、どのライセンスを選ぶべきですか？

Apache 2.0 / MIT 系が第一候補です。これらはOSI承認のオープンソースで、商用利用・改変・再配布が広く許され、ユーザー規模の上限もありません。義務はライセンス・著作権表示の保持程度です。多くのQwen3（dense）モデルやMistralの一部公開モデルがApache 2.0を採用しています。将来の制約リスクを最小化したい商用案件に向きます。

### Q. ファインチューニングした派生モデルにも、ライセンスは及びますか？

及びます。元モデルのライセンスは派生物にも継承され、ライセンスによっては派生モデルの命名規則（例: 名前に元モデル名を冠する）や、利用制限ポリシーの引き継ぎ義務があります。Apache 2.0系は派生物の扱いも比較的自由ですが、コミュニティライセンス系は条件を確認する必要があります。

### Q. ライセンスはいつ確認すべきですか？

モデルを選ぶ最初の段階です。ライセンスは後付けの確認事項ではなく設計判断（license-as-architecture）として扱ってください。本番投入後にライセンス問題が発覚すると、別モデルへの載せ替えという大きな手戻りが発生します。MAU上限のようなスケール条件は事業が成功した時に問題化するため、最初に評価しておくことが重要です。

---

## まとめ：ライセンスは最初に決める設計判断

オープンウェイトLLMの商用利用で損をしないために、押さえるべきは次の通りです。

1. **「オープンウェイト ≠ オープンソース ≠ 自由に使える」**——重み公開と商用自由は別物。
2. **5軸で評価する**——商用可否・規模上限・帰属表示・派生物の命名・利用制限ポリシー。
3. **Apache 2.0 / MIT 系は最も自由**——ロックインを避けたい商用案件の第一候補。
4. **Llama・Gemma等は商用可だが条件付き**——MAU上限・帰属・利用制限の引き継ぎに注意。
5. **ライセンスは最初に決める設計判断**——プロバイダ抽象で差し替え可能にし、リスクを局所化する。

「どのオープンモデルを商用で使ってよいか」「ライセンス条件を満たせるか不安」——その判断は、事業の拡大可能性とロックインリスクを左右します。モデル選定・ライセンス評価・差し替え可能な実装まで、本番運用品質でお引き受けします（具体的なライセンス適合の最終判断は、必要に応じて法務と連携します）。