オープンソースLLMとは？主要モデルやオープンウェイトとの違い、選び方を解説

オープンソースLLMとは、モデルの重みやライセンスが公開され、自社環境にダウンロードして利用・改変・再配布できるLLMの総称として使われる言葉です。
ただし業界で「オープンソースLLM」と呼ばれてきたモデルの大半は、OSI（Open Source Initiative）の定義に照らすと厳密には「オープンウェイト」に分類されるモデルで、学習コード・学習データまでは公開されていません。

本記事では、この定義の違いから、フルオープンソースLLMと実質オープンウェイトの主要モデル、ローカルLLMとの位置関係、ライセンス、日本語対応、選び方、そして「オープンソース＝タダ」という誤解までを、2026年7月時点の最新情報で体系的に解説します。

オープンソースLLMとは？重みやライセンスを公開し自社環境で使えるLLMの総称

オープンソースLLM（Open Source Large Language Model）とは、モデルの重みやライセンスが公開され、自社環境にダウンロードして推論・改変・再配布などが可能なLLMの総称として業界で広く使われています。

対置される概念は、モデル本体がベンダー側に置かれAPI経由でのみ利用できるプロプライエタリモデル（クローズドソースとも呼ばれる）で、GPT-5.5・Claude Opus 5・Gemini 3 Proなどが該当します。

ただし、この呼び名で紹介される主要モデル（Meta Llama・Google Gemma・Alibaba Qwen・DeepSeek・Moonshot Kimi・Z.ai GLM等）の多くは、OSI（Open Source Initiative）が定めるOpen Source AI Definition 1.0の要件を満たしておらず、厳密にはオープンウェイト（重みだけ公開・学習コードやデータは非公開）に分類されます。

---

オープンソースLLM・オープンウェイト・プロプライエタリの3層分類——OSI定義で峻別する

本セクションでは、「オープンソースLLM」の定義のズレを解消するために、OSIが2024年10月に公開したOpen Source AI Definition 1.0を軸に、モデルの公開範囲を3層で整理します。

この3層分類が身につくと、Web上で「オープンソースLLM」と紹介されているモデルが実際にはどこに位置するのかを、自分の目で判定できるようになります。

OSI Open Source AI Definition 1.0の4つの自由と3点セット

OSIのOpen Source AI Definition 1.0は、AIシステムが「オープンソース」を名乗るために満たすべき条件を、以下の4つの自由として定義しています。

自由	内容
使用の自由	用途を問わず、許可を得ずに使える
研究の自由	どのように動作するかを研究し、構成要素を検査できる
改変の自由	任意の目的でシステムを改変できる
共有の自由	改変した派生物を他者に共有・再配布できる

そして、この4つの自由を実質的に保証するために、以下の3点セットを公開することが必須要件とされています。

要素	内容
データ情報（Data information）	学習に使ったデータの出所・特性・入手方法などの十分な情報
コード（Code）	学習と推論に用いた完全なソースコード
パラメータ（Parameters）	モデルの重みと設定値

ここでのポイントは、「重みが公開されている」だけではOSIのオープンソース定義を満たさないという点です。

学習コードとデータ情報まで揃って初めて「派生物を独自に再学習・再構築できる」状態になり、4つの自由が実質的に成立します。

モデル公開範囲の3層分類

以下の表で、モデルの公開範囲を3層で整理しました。各層で「何を公開しているか」がまったく異なります。

層	公開範囲	代表モデル	4つの自由の状態
プロプライエタリ（クローズドソース）	すべて非公開（APIのみ）	GPT-5.5、Claude Opus 5、Gemini 3 Pro	研究・改変・共有はいずれも不可
オープンウェイト	重み＋推論コードを公開。学習コード・データは非公開または部分公開	Llama 4、Qwen 3.6、DeepSeek V4、gpt-oss、Kimi K3、GLM-5.2、Gemma 4 等	使用・部分的な改変は可能。データ由来の再構築は困難
フルオープンソース（OSI準拠）	重み＋学習コード＋データ情報＋（多くは）チェックポイントまで公開	OLMo 2、Pythia、LLM360 K2、Apertus 等	4つの自由をすべて満たす

この表が示すのは、業界慣習の「オープンソースLLM」と、OSIの定義する「フルオープンソース」の間に、オープンウェイトという中間層が実は存在するという構造です。

多くの企業が「オープンソースLLM」として社内提案に上げるモデルは、実際にはオープンウェイトです。

主要モデルが実はオープンウェイトである理由

Meta Llama・Alibaba Qwen・DeepSeek等は、コミュニティで「オープンソースLLM」として紹介されることが多いモデルです。

しかし公開されているのは重み（＋推論コードの一部）だけで、学習に使ったデータセットの詳細や学習コード全体は公開されていません。

OSIは2023年7月にMeta Llama 2について「オープンソースではない」と正式に表明しており、Llama 3.x、Llama 4に至るまで一貫してその姿勢を維持しています。

Llama 4に対しても2025年にOSIが「Llama 4はオープンソースではなく、Europeansは除外されている。Open Source AIと呼ぶのをやめるべきだ」と改めて指摘しました。

Qwen 3系は2025年にライセンスをApache 2.0に移行しており、Llamaよりは自由度が高いですが、それでも学習データ情報が公開されていない点でOSI準拠のフルオープンソースには届いていません。

DeepSeek V3系（MITライセンス）も同様に、ライセンスは寛容ですが学習データ由来の再構築は困難で、OSIの定義では実質オープンウェイトに分類されます。

この違いを踏まえたうえで、次のセクションからは業務投入で意識するべき「運用形態としてのローカルLLM」との峻別、そしてフルオープンソースと実質オープンウェイトの主要モデルを順に見ていきます。

---

ローカルLLMとの違い——公開範囲の話と運用形態の話は別軸

「オープンソースLLM」と「ローカルLLM」は、日常会話ではほぼ同じ意味で使われることが多い言葉ですが、実は指しているレイヤーがまったく違います。

この違いを理解しておくと、「オープンソースLLMだからローカルで動かすもの」「ローカルLLMだから商用利用OK」といった短絡的な判断を避けられます。

定義軸と運用軸の切り分け

以下の表で、両者が扱っているレイヤーの違いを整理しました。

用語	扱っているレイヤー	判断基準
オープンソースLLM	ライセンス・公開範囲（定義軸）	重み・コード・データがどこまで公開されているか
ローカルLLM	推論の実行場所（運用軸）	モデルの推論を自社サーバー・手元PCで行うか、クラウドAPIから呼び出すか

つまり、同じモデルでも運用のしかたでラベルが変わるという関係にあります。

Meta Llama 4をOllamaで手元PCで動かせばローカルLLM運用、Amazon Bedrock経由でAPIコールすればクラウドLLM運用です。

モデル自体はどちらも「オープンウェイト（業界慣習ではオープンソース）LLM」のLlama 4のままです。

組み合わせで見ると4パターン

定義軸と運用軸を掛け合わせると、以下の4パターンに整理できます。

• プロプライエタリ × クラウドAPI運用
  GPT-5.5をOpenAI APIで呼ぶ、Claude Opus 5をAnthropic APIで呼ぶといった標準構成。重みは手に入らないため、原理的にローカル運用はできません
  
  

• オープンウェイト × クラウドAPI運用
  Llama 4をAmazon Bedrock・Google Vertex AI経由で呼ぶ、Qwen 3.6をAlibaba Cloudから呼ぶといった構成。「重みは公開されているが自社で動かさない」選び方
  
  

• オープンウェイト × ローカル運用
  Llama 4・Qwen 3.6・gpt-oss等の重みをダウンロードし、社内サーバーやワークステーションで動かす構成。データ主権とAPI課金脱却の両立を狙う典型パターン
  
  

• フルオープンソース × ローカル運用
  OLMo 2・Pythia等の重みと学習データをダウンロードし、自社で追加学習も含めて完全に制御する構成。研究組織・監査要求の厳しい規制業界で選ばれます

この4パターンで見ると、「オープンソースLLM」で情報を集める側が実際に検討しているのは主にオープンウェイト × ローカル運用、あるいはオープンウェイト × クラウドAPI運用であることが多いです。

そのため本記事の残りは、フルオープンソースの位置づけを整理したうえで、実質オープンウェイトの主要モデルとその選び方を軸に進めます。

ローカルLLMの導入手順・ハードウェア要件・ランタイム比較の詳細は本記事のスコープから外れるため、運用軸の話は概観にとどめます。

【関連記事】
ローカルLLMとは？メリットやおすすめモデル、導入方法を解説
ローカルAIとは？主要ランタイムやモデル選定、日本企業の導入事例を徹底解説

---

フルオープンソースLLMの主要モデル——OLMo 2・Pythia・LLM360

本セクションでは、OSI Open Source AI Definition 1.0を実質的に満たすフルオープンソースLLMの主要モデルを整理します。

重み・学習コード・データ情報の3点セットを公開しているモデルで、商用フロンティアの性能には及ばないものの、学術研究・監査要求の厳しい業界・完全な内製化を求める組織で選ばれています。

Ai2のOLMo 2——最も影響力のあるフルOSS

Allen Institute for AI（Ai2）のOLMo 2は、フルオープンソースLLMの中で最も注目されているモデルシリーズです。

OLMoシリーズを公開するAllen Institute for AI（出典：Allen Institute for AI）

7B・13B・32Bの3サイズがあり、いずれも以下をすべて公開しています。

• モデル重み（Hugging Faceで配布）
• 学習コード（GitHubで公開）
• 学習データセット（olmo-mix-1124：約3.9兆トークン／dolmino-mix-1124：約8,430億トークン）
• 中間チェックポイント（学習の各段階のスナップショット）
• 評価フレームワーク OLMES（20種のベンチマーク）

Ai2は「OLMo 2 7B・13Bは、同規模のオープンウェイトモデルを凌駕する場合が多い最良のフルオープンモデル」と説明しています。

学習過程の再現性が担保されており、研究者や規制対応の厳しい業界で「モデルの中身を証明する必要がある」ケースでは第一候補になります。

EleutherAIのPythia——研究用途の定番

EleutherAIのPythiaは、2023年に公開された16個のモデルからなるファミリーで、フルオープンソースLLMの初期からの定番です。

同じデータを同じ順序で学習させた複数のモデルサイズが公開されており、学習過程への介入実験や再学習の因果検証ができる設計になっています。

実務投入というよりも、モデルの挙動を研究する土台として広く使われており、AI安全性・解釈可能性の研究論文で頻繁に引用されます。

BLOOM——多言語対応の大規模オープンサイエンスモデル

BigScienceが2022年に公開したBLOOMは、176B規模の多言語モデルで、46の自然言語と13のプログラミング言語をカバーします。

学習データ・学習コード・重みを広く公開したオープンサイエンスモデルとして知られていますが、ライセンスはBigScience BLOOM RAIL 1.0で用途制限（許容可能な使用ポリシーへの遵守）が課されており、OSI Open Source AI Definitionの「あらゆる目的での利用」要件は満たしません。厳密にはフルオープンソース（OSI準拠）ではなく、公開範囲は広いが用途制約付きのモデル、という位置づけです。

2026年時点では性能面で最新モデルに追い抜かれていますが、多言語処理・オープンサイエンス系研究の基盤として引き続き参照されるモデルです。

LLM360 K2とApertus

LLM360が公開しているK2（65B）とCrystalは、「360-Open」を掲げて重み・学習コード・データ・中間チェックポイントに加え、学習ログや評価スクリプトまで公開する徹底したフルオープンソース実装です。

またスイス国立AIイニシアチブ（Swiss National AI Initiative）が主導するApertusは、政府主導でフルオープンソースLLMを構築する事例として2025年以降注目を集めています。

非営利団体・政府・研究機関がフルオープンソースLLMの供給者として重要な役割を担っており、商用ベンダー中心のオープンウェイトとは別の生態系が形成されています。

なぜフルオープンソースLLMは業務投入されにくいのか

フルオープンソースLLMはOSI定義に沿った「本物のオープンソース」ですが、業務投入で選ばれるのは限定的です。理由は以下の3点に整理できます。

• 性能で商用フロンティアに届かない
  Llama 4・Qwen 3.6・DeepSeek V4といった実質オープンウェイトのフロンティアクラスと比べると、OLMo 2 32Bでも汎用ベンチマーク・コード生成性能で見劣りするケースが多い
  
  

• 日本語対応が薄い
  学習データの多言語バランスが英語中心で、日本語の実務品質ではLlama 3.1 SwallowやPLaMo 3.0 Prime、Qwen 3.6等の後塵を拝する
  
  

• エコシステムが薄い（ツール・ドキュメント・事例）
  Ollama・LM Studio・vLLM等のランタイム側で、Llama系・Qwen系のような即応の最適化が少ない

そのため、「業務用途で使える現実的なオープンソースLLM」を探す文脈では、実質オープンウェイトの主要モデルに落ち着くのが一般的です。

「フルオープンソース＝理想」「オープンウェイト＝現実」という認識で使い分けると、選定でブレなくなります。

---

実質オープンウェイトの主要オープンソースLLM——2026年7月時点の勢力図

本セクションでは、業界で「オープンソースLLM」と呼ばれることが多い実質オープンウェイトの主要モデルを、2026年7月時点の勢力図で整理します。

米国系・中国系・欧州系・日本系がそれぞれ強みを持ち、モデル選定は「性能」「ライセンス」「日本語対応」「地政学リスク」の複合判断になります。

2026年7月時点の主要オープンソースLLM比較表

以下の表で、業務投入の候補になる主要オープンソースLLM（実質オープンウェイト）を整理しました。

モデル	提供元	総パラメータ／活性化	ライセンス	コンテキスト長	特徴
Llama 4 Maverick	Meta（米）	400B／17B（MoE）	Llama 4 Community License	最大1M	汎用性能とエコシステム、大規模MAU企業は追加合意が必要
Qwen 3.6	Alibaba（中）	4バリアント展開（MoE中心）	Apache 2.0	最大1M	公式ベンチマークで多言語性能に強み
DeepSeek V4 Pro	DeepSeek（中）	総1.6T／活性49B（MoE）	MIT	最大1M	推論・数学・コード生成に強く、公式APIレートが低水準
gpt-oss	OpenAI（米）	120B／5.1B（MoE）と20B	Apache 2.0	128K	OpenAI発の初オープンウェイト、H100単体で動く設計
Kimi K3	Moonshot（中）	2.8T（MoE）	Kimi K3 License（独自）	最大1M	2026年7月16日リリース、Native Vision対応。MaaS事業者は連続12ヶ月売上$20M超で別契約要
GLM-5.2	Z.ai（中）	744B／40B（MoE）	MIT	最大1M	GPQA Diamond 91.2%、コーディング用途に強み
Gemma 4	Google（米）	E2B・E4B・12B・26B A4B・31Bの5構成	Apache 2.0	128K〜256K	エッジ・組込〜中規模まで幅広いラインナップ
Mistral Large 3	Mistral AI（欧）	総675B／活性41B（MoE）	Apache 2.0	256K	欧州発、コーディングと多言語処理で強み
Phi-4	Microsoft（米）	14B	MIT	16K	小規模＋合成データで軽量高性能を狙う

この表から読み取れるのは、2026年時点でオープンソースLLMの主軸は米国系（Llama 4・gpt-oss・Gemma 4・Phi-4）と中国系（Qwen・DeepSeek・Kimi・GLM）に集約されつつあり、欧州系Mistralが追いかける構図になっているという点です。

ライセンス面ではQwen 3.6・DeepSeek V4・gpt-oss・Gemma 4・GLM-5.2・Mistral Large 3・Phi-4がApache 2.0またはMIT系で商用条件が寛容なのに対し、Llama 4・Kimi K3は独自ライセンスで一部制約が残ります。

米国系——Llama 4・gpt-oss・Gemma 4・Phi-4

Meta Llama 4

Meta Llama 4は、Behemoth・Maverick・Scoutといったサイズ違いで展開される主力オープンソースLLMで、Hugging Faceダウンロード数・エコシステムの厚みで市場を先導しています。

Meta Llama 4シリーズ Behemoth・Maverick・Scoutの構成（出典：Meta AI）

公開されているのはLlama 4 Maverick（17B活性化・128エキスパート・総400B・1Mコンテキスト）とLlama 4 Scout（17B活性化・16エキスパート・総109B・10Mコンテキストの大規模ロングコンテキスト構成）の2モデルで、Llama 4 Behemoth（288B活性化・16エキスパート・総2T）は同時発表された教師モデルながらリリース時点では学習中で未公開です。公開済みの2モデルは用途に応じて使い分ける想定になっています。

ただしライセンスは「Llama 4 Community License」で、月間アクティブユーザー7億超（リリース日前月時点で判定）の企業はMetaの追加合意が必要な点、Llama 4のマルチモーダルモデルではEU居住個人・EU主事業所ライセンシーの利用が制限される点（組み込み製品のエンドユーザーは除外）、派生AIモデル名は「Llama」で始める義務がある点で、完全なオープンではありません。

OpenAI gpt-oss

OpenAIのgpt-ossは、2025年8月にOpenAIが「これまでのプロプライエタリ路線」から一歩踏み込んで公開したApache 2.0ライセンスのオープンウェイトモデルで、120B（活性化5.1B）と20Bの2構成があります。

H100単体GPUで動作するように設計されており、社内クローズ環境で「OpenAI系モデルを動かしたい」という要件に応えます。

OpenAI gpt-oss-120bのHugging Face公式リポジトリ（Apache 2.0で公開）（出典：Hugging Face）

Google Gemma 4

Gemma 4は、Google製のApache 2.0ライセンスのオープンウェイトモデル。E2B・E4B・12B・26B A4B・31Bの5構成があり、小型モデルは128K、中型モデルは256Kコンテキストに対応。エッジ・組込用途から中規模サーバーまで幅広いラインナップが強みです。

Microsoft Phi-4

Microsoft Phi-4はMITライセンスで、合成データを活用した学習で「小規模ながらフロンティアに迫る」設計思想を持つモデルです。

中国系——Qwen・DeepSeek・Kimi・GLM

中国系オープンソースLLMは、2025年後半から2026年にかけて性能・コスト・エコシステムのすべてで急速に存在感を高めており、日本企業の採用検討でも避けて通れない選択肢になっています。

• Qwen 3.6（Alibaba）
  Apache 2.0で提供される多言語対応LLM。公式ベンチマークで多言語性能に強みがあり、Qwen3-Coderのようなコーディング特化バリアントも展開
  
  

• DeepSeek V4（DeepSeek）
  MITライセンスで、推論・数学・コード生成が公式ベンチマークで高評価。公式APIレートが低水準でコスト優先の候補になる
  
  

• Kimi K3（Moonshot）
  2026年7月16日リリース。2.8トリリオンパラメータのMoEモデルで、Native Visionと1Mコンテキストに対応。ライセンスはKimi K3 License（独自）で、MaaS事業者が連続12ヶ月売上$20M超なら別契約が必要な点、一定規模以上の派生製品に「Kimi K3」表示義務がある点で商用条件を法務レビューが必要

• GLM-5.2（Z.ai）
  MITライセンスで、GPQA Diamond 91.2%というフロンティアレベルの公式ベンチマーク。1Mコンテキストとコーディング適性が強み

いずれも公式ベンチマークではLlama 4に比肩、あるいは特定タスクで上回るケースが報告されています。ライセンス面ではKimi K3以外は商用条件が寛容ですが、Kimi K3は独自ライセンスで契約前の法務レビューが必要です。

また、後述する地政学リスク（輸出規制・データレジデンシー・調達統制）は自社ポリシーに照らして必ず確認する必要があります。

【関連記事】
中国製AIまとめ｜主要モデル7選・料金・Claude Code代替の全体像【2026年最新】

日本語対応の主要モデル

日本語業務での実用性を重視する場合、以下の日本語特化モデルも主要な選択肢になります。

• Llama 3.1 Swallow
  産業技術総合研究所と東京科学大学が公開する、Llama 3.1をベースに日本語能力を強化したモデル。ライセンスは元のLlamaに準拠
  
  

• PLaMo 3.0 Prime
  Preferred Networksの国産LLM商用フラッグシップ。APIまたはオンプレミスで提供される商用モデルで、Prime本体は無償ライセンス対象ではない。
  
  PLaMo Primeを標準搭載する自治体向けサービス「QommonsAI」経由での自治体導入が広がっている。小規模事業者向けにはPLaMo 2 8B等がPLaMo Community License（年間売上10億円以下は無償）で公開されている
  
  

• NTT tsuzumi 2
  NTTが提供する日本語特化モデル。オンプレミス提供が可能で、金融・製造業のオンプレAI要件にフィット
  
  

• ELYZA 70B
  ELYZAが開発する日本語特化モデル。公式評価で日本語性能の高さが示されている

公開範囲はモデルごとに大きく異なり、商用フラッグシップ（PLaMo 3.0 Prime・NTT tsuzumi 2）は独自ライセンスで提供される一方、小規模版（PLaMo 2）や研究用モデルは独自Community License等で提供されるケースがあります。

日本語業務で「英語圏の主要オープンウェイトでは辞書・敬語・業界用語が足りない」というギャップに直面したとき、これらの日本語特化モデルが有力な補完先になります。

【関連記事】
国産AIとは？主要モデル比較・料金・ガバメントAI源内を2026年6月版で解説

---

ライセンス種別と商用利用の判断軸——「オープンソース」でも商用条件は千差万別

オープンソースLLMを業務に投入するとき、最初につまずくのがライセンスです。同じ「オープンソースLLM」と呼ばれるモデルでも、商用利用の条件は大きく異なります。

本セクションでは、主要ライセンス種別の商用利用条件と、企業が確認すべき論点を整理します。

主要ライセンス種別の商用条件

以下の表で、主要オープンソースLLMのライセンス種別と商用利用条件を整理しました。

ライセンス	商用利用	主な制約	該当モデル
Apache 2.0	自由	特許条項・帰属表示・変更点の明示	Qwen 3.6、gpt-oss、Gemma 4、Mistral Large 3、OLMo 2 等
MIT	自由	帰属表示のみ	DeepSeek V3/V4、GLM-5系、Phi-4 等
Llama 4 Community License	条件付き	MAU 7億超はMetaの追加合意が必要（リリース日前月時点で判定）、マルチモーダルモデルはEU居住個人・EU主事業所ライセンシーに制限、派生AIモデル名は「Llama」で始める義務	Llama 4 全系
Kimi K3 License（独自）	条件付き	MaaS事業者は連続12ヶ月売上$20M超で別契約が必要、一定規模以上の派生製品に「Kimi K3」表示義務	Kimi K3

実務で最も安全なのはApache 2.0とMITで、社内利用・SaaS提供・派生モデル公開まで大きな制約なく実行できます。

一方でLlama系・Kimi系のカスタムライセンスは、後述の落とし穴を意識して契約前に法務レビューを通すのが安全です。

Llama 4 Community Licenseの落とし穴

Metaが提供するLlamaシリーズは、独自のCommunity Licenseで提供されています。Apache 2.0やMITに比べて商用条件が厳しく、以下の3点が特に注意点です。

• 月間アクティブユーザー7億超の制限
  Llamaベースのプロダクトを提供する企業のMAUが7億を超える場合、Metaの追加合意が必要（リリース日前月時点で判定）
  
  

• Llama 4マルチモーダルモデルのEU制限
  Llama 4のマルチモーダルモデルは、EU居住個人・EUに主たる事業所を置くライセンシーの利用を制限。ただし組み込み製品のエンドユーザーは除外される
  
  

• 派生AIモデルの命名規則
  Llamaベースで開発した派生AIモデルの名称は「Llama」で始める義務がある

OSIはこれらの制約を根拠に、Llamaシリーズを「オープンソースとは呼べない」と繰り返し表明しています。

大企業の社内利用や海外展開を視野に入れる場合、Llama系を採用する前に法務レビューを通すのが実務的な必須手順になります。

中国系モデルの地政学リスク

中国系のQwen・DeepSeek・Kimi・GLMは、ライセンスとしてはApache 2.0・MIT・独自ライセンス等ですが、企業採用時には別レイヤーのリスクを検討する必要があります。

• 輸出規制
  米国政府の対中輸出規制で、モデル本体や派生物の米国・第三国展開に条件がつく可能性がある
  
  

• データレジデンシー
  モデル自体は自社環境で動かせても、ファインチューニング・API連携で中国側インフラを経由する構成では、データの国外流出リスクが問われる
  
  

• 調達統制
  公共・防衛・重要インフラ関連の業務では、中国系モデルの調達自体が調達方針で制限されるケースがある

これらは技術論ではなく調達・監査・法務の話です。

ライセンス条件だけを見て「Apache 2.0だから安全」と判断すると、後工程で調達承認が下りない事態が起きます。中国系モデルを候補に入れるときは、社内の調達統制・輸出管理担当と早めに擦り合わせておくのが安全です。

派生条件まで踏み込んで確認する

企業でオープンソースLLMを本格採用するときは、単純な「商用利用OK」の一言では判断材料が足りません。以下の観点まで踏み込んで確認する必要があります。

• 改変後の再配布は可能か
• ファインチューニング済みモデルをSaaSで提供できるか
• 派生モデルの命名にベースモデル名を含める義務があるか
• ライセンス違反が発覚したときの解除条件

Apache 2.0・MITなら大半の項目でクリアですが、Llama系・Kimi系は個別条項の確認が必要です。

「オープンソースLLMだから自由に使える」と一括りにするのではなく、モデルごとにライセンス条項を1本1本読むのが原則です。

---

オープンソースLLMの選び方——3つの判断軸

本セクションでは、オープンソースLLMを業務投入する際の3つの判断軸を提示します。この順で絞ると、候補が2〜3個に自然と収束します。

ライセンスが自社ビジネスに乗るか

最初のフィルターは、自社が想定する使い方が該当モデルのライセンスで許容されるかです。ここで詰まると後工程がすべて手戻りになります。

• 社内ツールとして使うだけなら大半のライセンスがクリア
• 顧客向けSaaSに組み込むなら、Apache 2.0・MITが第一候補
• Llama 4のリリース日時点の前月MAUが7億超だった企業は、Metaとの追加合意要件を確認
• EU所在の個人・EUに主たる事業所を置く企業がLlama 4マルチモーダルモデルを直接利用する場合は対象範囲を確認

この段階で候補が半分程度まで絞れます。

日本語対応が業務品質で足りるか

次のフィルターは日本語対応です。英語ベンチマークが高くても、日本語での実務品質が伴わないケースがあります。

日本語業務ドキュメント・敬語・業界用語の処理を求める場合、以下のような優先順位で候補を絞ります。

• 日本語特化モデルを優先する → PLaMo 3.0 Prime・Llama 3.1 Swallow・NTT tsuzumi 2・ELYZA 70B
• 汎用性能と日本語の両立を求める → Qwen 3.6、DeepSeek V4
• 英語主軸で、日本語性能は自社データで検証 → Llama 4、gpt-oss、Mistral Large 3

日本語対応の実力は、自社の実業務データでベンチマークを1回回してから判断するのが確実です。

Web上のベンチマーク数値だけで決めると、自社の業務ドメイン（金融の与信文書、製造の設計仕様書、医療の診療録等）で期待外れになることがあります。

GPU/インフラを自社で持てるか

3つ目のフィルターは、モデルを実際に動かすインフラです。オープンソースLLMを選んでも、動かせなければ意味がありません。

• フロンティアクラスを自社で動かす
  GLM-5.2・Kimi K3・DeepSeek V4・Llama 4 Maverick等の1Mコンテキスト・大規模MoEクラス。80GB VRAM級のGPU（H100・H200）を複数台束ねるDGXホスト規模の構成が必要で、初期投資は数千万〜億単位
  
  

• 中規模モデルを量子化して動かす
  Qwen 3.6・Llama 4 Scout（Int4）・gpt-oss 120B等。80GB VRAM単体のGPUで動作可能で、投資は数百万〜数千万円規模
  
  

• 小規模モデルで軽量運用
  Phi-4・Gemma 4・gpt-oss 20B等。24〜48GB VRAMのGPUで動作可能で、ワークステーション単体で数十万〜数百万円
  
  

• 自社インフラを持たずクラウド経由で動かす
  Amazon Bedrock・Google Vertex AI・Microsoft Foundry・Alibaba Cloud経由でAPI呼び出し。定価従量課金

「オープンソースLLM＝ローカルで動かす」というイメージが先行しがちですが、実際にはクラウドAPI経由でオープンウェイトを使う構成も一般化しています。

ケース別の推奨——3判断軸を組み合わせた実務パターン

上記3軸を組み合わせて、AI総研の支援現場でよく出るケース別の推奨をまとめます。

• 金融・医療・防衛など機密データを社外に出せない業務
  ライセンス軸でApache 2.0/MITを優先候補にしつつ、独自ライセンスでもオンプレミス提供可能なNTT tsuzumi 2やPLaMo 3.0 Prime等も選択肢に入る。GPU軸を要件次第で判断し、Qwen 3.6・DeepSeek V4・gpt-oss等のオープンウェイトをローカルで動かす構成が典型
  
  

• 社内ナレッジ検索・FAQ・議事録要約など汎用業務
  日本語対応軸を最優先し、Qwen 3.6やPLaMo 3.0 Primeをクラウド経由で軽量に導入
  
  

• コーディング支援・技術ドキュメント処理
  ライセンス軸（Apache 2.0/MIT）＋ 性能でGLM-5.2・DeepSeek V4・Qwen3-Coderが候補
  
  

• 監査・規制対応で「モデルの中身を証明する必要がある」業務
  ライセンス軸でフルオープンソースが要件になる場合、OLMo 2・Pythia等が候補。性能は妥協した上で説明責任を優先

「ライセンス→日本語→GPU」の順で絞れば、モデル候補は自然に2〜3個まで収束します。この段階で自社業務データでのPoC比較に進むのが、最短ルートです。

---

オープンソースLLM検討で詰まる3つの論点——コスト誤解・地政学リスク・長期保守

本セクションでは、オープンソースLLMの導入判断で企業が実際に詰まる論点を3つ取り上げます。単なるモデル選定より一段深い、運用に載せてから問われる論点です。

オープンソースはタダではない

オープンソースLLMを検討する現場で最も多い誤解は、「ライセンス費用がゼロだから安く済む」というものです。

たしかにApache 2.0・MITのモデルはライセンス費用がかかりませんが、実際の運用コストは以下のように積み上がります。

• GPUハードウェア
  80GB VRAM級のGPU（H100等）は1台数百万円、複数台構成なら数千万〜億単位
  
  

• 電気代・冷却コスト
  GPU 1台あたりTDP 350〜700W、24時間365日稼働で年間の電気代が1台あたり数十万円規模
  
  

• 運用人件費
  ランタイム構築・モデル更新・障害対応・ファインチューニングを担当するインフラ・MLエンジニアの人件費
  
  

• セキュリティ・監査コスト
  オンプレAI基盤のセキュリティ設計・監査対応の追加工数

クラウドAPIのトークン単価だけを比較すれば、GPT-5.5やClaude Opus 5より遥かに安く見えるものの、実質コストは規模次第で逆転します。

どこで損益分岐点が来るかは、月間トークン量・同時実行数・GPU台数・稼働率・償却期間・電力単価・運用人件費のすべてに依存し、モデル・リージョン・API単価の変動でも変わります。

クラウドAPIの利用規模が小さいうちはローカル化の初期投資が回収圏に入らず、大規模利用になるほど固定費に切り替えるメリットが出るのが一般的な傾向ですが、具体的な閾値は自社の利用実態に基づく試算が必要です。

「オープンソース＝タダ」ではなく、オープンソース＝コスト構造が変わるという理解が正解です。

中国系モデル採用の意思決定フロー

性能・コスト面で中国系オープンソースLLM（Qwen・DeepSeek・Kimi・GLM）は非常に魅力的ですが、企業採用では技術論とは別レイヤーで判断が求められます。

• 輸出規制
  米国の対中輸出規制で、中国系モデルベースの派生物・製品を米国・第三国へ展開する場合、事前確認が必要になる可能性
  
  

• データレジデンシー
  モデル本体は自社環境で動かせても、ファインチューニング・APIコール経路で中国側のインフラを一部経由する構成なら、データが国外に渡るリスクを検討する
  
  

• 調達統制
  公共・防衛・重要インフラ関連では、中国系モデルの調達自体が調達方針で制限されるケースがある

実務では「Qwen 3.6の性能は魅力だが、社内の調達承認が下りない」という壁にぶつかることがあります。

早い段階で調達・法務・輸出管理担当と擦り合わせておかないと、PoCまで進めても最後で採用不可になる事故が起きます。中国系モデルを候補に入れるなら、キックオフ時点で社内ステークホルダーを揃えるのが安全です。

モデル世代交代と長期保守の設計

オープンソースLLMは配布形態としては「一度公開されれば消えない」ものの、業務に組み込んだ後のモデル更新・セキュリティパッチ・ライセンス変更まで含めて考えると、長期保守は別問題です。

• モデル更新の頻度と互換性
  Qwen・DeepSeek・Llamaは半年〜1年で世代交代し、旧世代のサポート・パッチが徐々に薄くなる
  
  

• ライセンス変更の可能性
  Qwenが2025年にApache 2.0へ移行した例のように、途中でライセンスが変わることがある。逆に厳しくなる可能性もゼロではない
  
  

• 提供元の事業継続リスク
  中小規模のオープンウェイト提供者（Kimi・Z.ai等）は、事業戦略変更でモデル公開を停止するリスクを内包する

プロプライエタリAPIなら「ベンダーが提供を続ける限り安定」という前提が置けますが、オープンソースLLMはモデル選定と同じくらい、乗り換え計画も設計に組み込んでおく必要があります。

実務的には、「特定モデルに全社を依存させない」「ランタイムを差し替え可能な設計にする」「Hugging Faceの重みを社内ミラーに退避しておく」といった構造的な備えが有効です。

---

オープンソースLLMを業務Agentに接続する運用基盤を整えるなら

オープンソースLLMを選定できても、実際の業務価値に変えるには「業務システムに接続するAgent実行層」が別途必要です。多くの企業が、モデル選定は終わったのにSAP・Salesforce・Teams・社内DBへの接続層で詰まって運用に載らないという状況に直面します。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、オープンソースLLM・オープンウェイトモデル・プロプライエタリAPIのいずれもバックエンドに据えられる基盤として、業務Agentの実行・統合管理・ログ監査を1画面で完結させます。

• オープンソースLLMとクラウドAPIをハイブリッド運用
  機密性の高い処理は自社Azure環境内のオープンウェイトモデルへ、汎用処理はプロプライエタリAPIへ、と用途別に振り分ける構成が標準サポート
  
  

• モデル世代交代を吸収する管理層
  Qwen 3.6 → Qwen 3.7、Llama 4 → Llama 5のような短サイクルの世代交代でも、業務Agent側の設計は不変。特定モデル依存のワークフロー陥落を回避
  
  

• Agent単位でセキュリティ統制を1画面で管理
  どのAgentがどのモデルを呼び出したか、誰がどのデータを扱ったかを不変ログで保管し、監査対応をそのまま提出できる形で残す
  
  

• データは100%自社Azureテナント内に保持
  オープンウェイトモデルの推論も自社Azureテナント内で完結し、外部ベンダーへのデータ送信を発生させない設計

AI総合研究所の専任チームが、オープンソースLLM選定から業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、オープンウェイトモデル×業務Agentの実装例をご確認ください。

---

まとめ

本記事では、オープンソースLLMを、OSI Open Source AI Definition 1.0に基づく3層分類（プロプライエタリ／オープンウェイト／フルオープンソース）、フルOSS主要モデル、実質オープンウェイトの主要モデル、ライセンス、選び方、詰まる論点まで、2026年7月時点の最新情報で整理しました。

2026年時点で押さえておくべきポイントは次の3つです。

• 「オープンソースLLM」で検索される大半のモデル（Llama・Qwen・DeepSeek・gpt-oss・Kimi・GLM等）はOSI定義では実質オープンウェイトで、フルオープンソースはOLMo 2・Pythia・Apertus等の研究基盤に限られる
• 業務投入で第一候補になるのはApache 2.0・MITの実質オープンウェイト（Qwen 3.6・DeepSeek V4・gpt-oss・Gemma 4・GLM-5.2・Mistral Large 3・Phi-4）で、Llama 4・Kimi K3等の独自ライセンスは制約を法務レビューで確認する必要がある
• 選定は「ライセンス→日本語→GPU」の3判断軸で絞り、「オープンソース＝タダ」の誤解と中国系モデルの地政学リスクを運用設計に織り込むのが実務的な備え
  
  

オープンソースLLMは「使うか使わないか」の段階を過ぎ、「どれをどう業務に組み込むか」を各社が具体的に判断するフェーズに入っています。

ライセンス・日本語対応・インフラ・地政学リスクを1本1本のモデルで確認し、自社の業務Agent基盤に接続できる形で採用する視点が、2026年時点の実務判断の中心になります。