EP.15 で「モデルはバージョンではなく選び方で持つ」と書きました。この記事はその宿題です。オープンウェイトの流れを年表で押さえ、ファミリーごとの性格とライセンスを並べ、そして「開発元がどこか」をどう評価するかまで扱います。
執筆時点（2026 年 9 月）の情報です。特に 2026 年の最新世代はバージョン番号が数ヶ月で入れ替わるため、個別の版番号は断定せず、ファミリー単位の性格と選び方を軸に書いています。導入時は必ず各モデルの で最新仕様とライセンスを確認してください。
1. なぜ「今の最強」を覚えても無駄なのか
ローカル LLM の相談で最もよく聞かれるのが「結局どれが一番いいか」です。気持ちは分かるのですが、この問いの答えは半年もちません。オープンウェイトの世界は複数の開発元が数ヶ月おきに世代を更新していて、順位表の上位は入れ替わり続けます。
しかも、順位表の上位が自分にとっての最適とは限りません。公開ベンチマークは自社ドメインの文体や専門用語での性能を測っていないし、そもそも問題文が学習データに混入している可能性が常につきまといます。順位で選ぶと「評判はいいのに、うちの資料だと使えない」という結末になりがちです。
そこでこの記事では、変わらないものを扱います。すなわち、流れの読み方（年表）、ファミリーごとの性格、ライセンスの読み方、開発元リスクの評価軸、そして選定手順。これらは世代が変わっても使い回せます。
2. 年表：オープンウェイトの転換点
細かい版番号を追う必要はありません。「何ができるようになった瞬間か」という転換点だけ押さえておけば、いま自分がどのあたりに立っているか分かります。
| 時期 | 出来事 | 何が変わったか |
|---|---|---|
| 2023 年 | Llama 1 / 2 の公開 | 重みが手に入る時代が始まった。ただし実務では玩具の域を出ず、本番は商用 API という共通認識だった |
| 2023 年 12 月 | Mixtral 8x7B | がオープンウェイトに到達。「サイズの割に速い」構成が現実的な選択肢になった |
| 2024 年 | Llama 3 / 3.1（405B）、Gemma 参入 | 初めて商用フロンティアと同じ土俵で語られるようになった。Google の参入で選択肢も増えた |
| 2024 年 9 月 | Pixtral 12B / Llama 3.2 Vision | 画像入力がオープン側にも来た。書類やスクショを扱う用途が現実的に |
| 2025 年 1 月 | DeepSeek R1 | 低コストで推論特化。技術面だけでなく地政学的な話題にもなった転換点 |
| 2025 年 8 月 | OpenAI が Apache 2.0 で重みを公開。GPT-2 以来の open-weight 復帰で、ローカル運用の起点が変わった | |
| 2026 年 | 多極化 | 単独の勝者がいない状態。複数ファミリーが並走し、上位が短い周期で入れ替わる |
この流れから読み取るべきことは 1 つです。「乗り換え前提で組む」。特定モデルに深く依存した作りにせず、インタフェースを EP.14 で触れた OpenAI 互換に寄せておけば、世代交代のたびに作り直す羽目にはなりません。
3. ファミリー別の性格
個別の版ではなくファミリー（系統）で覚えると、世代が変わっても知識が腐りません。主要な系統と、その性格・開発元の所在を並べます。
| ファミリー | 開発元 / 所在 | ライセンスの傾向 | 性格 |
|---|---|---|---|
| gpt-oss | OpenAI（米国） | ツール呼び出し前提。推論の深さを 3 段階で切替。20b が 16GB で動く | |
| Llama | Meta（米国） | 独自のコミュニティライセンス | 周辺ツールと派生モデルが最も厚い。情報量で困らない |
| Gemma | Google（米国） | 独自の利用規約 | 小型でも扱いやすく、端末寄りの用途に向く |
| Mistral | Mistral AI（フランス） | Apache 2.0 中心（一部は独自） | 欧州系。軽量・高効率の設計が得意 |
| Qwen | Alibaba（中国） | Apache 2.0 中心 | サイズ展開が非常に広く、多言語（日本語含む）に強い |
| DeepSeek | DeepSeek（中国） | 寛容なライセンス採用例が多い | 推論・コード方面の評価が高い |
| GLM / Kimi | Z.ai / Moonshot AI（中国） | モデルにより異なる | 近年の伸びが大きく、長文やエージェント用途で名前が挙がる |
この表のどれも、公開されているのは基本的に重みだけです。学習データや学習コードまで公開しているものは少数派。つまり を外部から検証することは基本的にできません。これは中国製かどうかとは無関係に、オープンウェイト全体に共通する性質です。「オープン」という語感で安心しないこと。
4. ライセンスの読み方
実務でつまずくのはここです。性能で選んだ後にライセンスで止まる、が典型的な失敗です。最低限、次の 4 点だけは導入前に確認してください。
- 商用利用が許されているか: 多くは許されるが、条件付きのものもある
- 派生物（ 後のモデル）の扱い: 再配布できるか、命名規則の指定はあるか
- 出力の扱い: 生成した出力を他モデルの学習に使うことを禁じている場合がある（ 制限）
- 利用者数などの閾値条項: 一定規模を超えると別途許諾が必要になる形のライセンスが存在する
傾向として、 や MIT なら判断は速い（寛容で条件が読みやすい）。一方で独自ライセンスは必ず本文を読む必要があります。ここで意外なのは、独自ライセンスは米国の大手が採用している例が目立つという点です。「西側だから安心、中国製だから制限が厳しい」という直感は、ライセンスに関しては当たりません。
5. 「チャイナリスク」を分解する
ご相談でよく出るテーマなので、正面から扱います。結論から言うと、この議論は「API を叩く」のか「重みを落として自前で動かす」のかを分けないと、まったく噛み合いません。リスクの性質が根本的に違うからです。
| 使い方 | データはどこへ行くか | 主なリスク | 対処 |
|---|---|---|---|
| ① 相手国ホストの API を叩く | 相手国の法域へ出る | 規制業種では最も明確なリスク。契約・監査・開示の要件を満たせないことがある | 規制対象データでは使わない。使うなら法務判断を通す |
| ② 重みを落として自前で動かす | どこにも出ない | データ流出の経路自体が無い。残るのは重みそのものへの信頼 | ネットワーク遮断で検証可能。①とは別問題として扱う |
| ③ 重みそのものの信頼性 | — | を検証できない。出力の偏り。改ざんの検知が難しい | 自ドメインで出力を実測。配布元のハッシュを確認 |
②を①と同一視した議論が非常に多い、というのが実務での感想です。手元の Mac にダウンロードした重みを、ネットワークを切った状態で動かしているなら、そのモデルの開発元がどこであろうとデータは 1 バイトも出ていきません。これは検証可能な事実で、実際に通信を遮断して動作確認すれば済みます。
では②なら何も気にしなくてよいかというと、そうではありません。残るのが③です。ただし③は中国製に固有の問題ではないという点は公平に押さえるべきです。前述のとおり、米国製モデルも学習データは公開されていないので、来歴を検証できない点は同じです。
実際に差が出るのは、技術ではなく組織側の要件です。次の観点で判断してください。
- 調達方針・契約条項: 顧客との契約や自社規程に、利用技術の国籍・供給元に関する条項があるか。あるなら技術論より先にそこで決まる
- 業種規制: 金融・医療・公共など、使用するソフトウェアの出所に要件が課される領域か
- 出力の偏り: 特定の話題で回答を避ける・偏る挙動は、自社の用途で実際に試して測る。政治的話題を扱わない業務なら実害が無いこともある
- 供給の継続性: そのファミリーが止まっても代替に移れるか。重みを手元に持っている限り、突然使えなくなることはないという点はオープンウェイトの強み
- 周辺環境の変化: 輸出管理などの規制は AI 分野で頻繁に更新されている。長期の前提に置かない
「それは API か、手元の重みか」。この 1 問で議論の 9 割が片付きます。API なら法域と契約の話、手元の重みなら来歴と出力品質の話。混ぜて議論すると、結論の出ない不安の話になります。
6. 選定の実務フロー
ここまでを踏まえた実際の手順です。上から順に絞り込むのが早い。逆順（性能から入る）にすると、最後にライセンスで振り出しに戻ります。
- 1載るサイズに絞る: 手持ちのメモリで動く規模だけを候補にする。見積り式は EP.14 参照。ここで候補は数分の 1 になる
- 2ライセンスと組織要件で削る: 商用可否・派生物・国籍条項。性能を見る前にやる
- 32 つに絞って実データで比べる: 自社の実データ 30〜50 件で同じ入力を流し、並べて比較する。ここで初めて性能の話をする
- 4評価セットを保存する: 次の世代が出たときに同じセットを流せば、乗り換え判断が 1 日で済む
4 番目が本当の資産です。モデルは半年で変わりますが、評価セットは残ります。これがあるかないかで、世代交代のたびのコストが桁で変わります。
7. 実データで比べる：最小の評価セット
6 章の 3 番目「実データで比べる」を、実際の手順に落とします。大掛かりな評価基盤は要りません。自社の実データ 30〜50 件と、同じ入力を両モデルに流して並べるスクリプトがあれば十分です。
その前に、候補モデルの素性を確認しておきます。ライセンスは配布物に同梱されているので、わざわざ Web を探さなくても手元で読めます。
# モデルの基本情報（パラメータ数・量子化・コンテキスト長など）ollama show gpt-oss:20b
# ライセンス本文を手元で読むollama show gpt-oss:20b --license | head -40
# 比較するときは量子化を揃える。同じモデル名でも量子化が違えば別物ollama list次に比較スクリプトです。採点は人がやります。ここを自動化しようとすると評価用のモデルの癖が混ざるので、最初は素直に並べて目で見るのが確実です。
import jsonfrom pathlib import Path
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
# 自社の実データから作った評価セット（30〜50件）# eval.jsonl は 1行1件: {"input": "...", "note": "期待する観点"}CASES = [ json.loads(line) for line in Path("eval.jsonl").read_text(encoding="utf-8").splitlines() if line.strip()]
MODELS = ["gpt-oss:20b", "<比較したいモデル>:<タグ>"]
def run(model: str, text: str) -> str: resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": text}], ) return resp.choices[0].message.content or ""
rows = []for case in CASES: row = {"input": case["input"], "note": case.get("note", "")} for model in MODELS: row[model] = run(model, case["input"]) rows.append(row)
Path("compare.json").write_text( json.dumps(rows, ensure_ascii=False, indent=2), encoding="utf-8")print(f"{len(rows)} 件を compare.json に出力しました")きれいな成功例ばかり集めても差がつきません。過去に人が間違えた案件・判断に迷った案件・例外的な書式を優先して入れると、モデル間の差がはっきり出ます。30 件で足りない場合も、まず 30 件作って回してみる方が、100 件を設計している間に世代が変わるより早い。
この評価セットは、モデルを乗り換えるたびに再利用できます。 の順位表が更新されても、判断はこの 30 件で下せる。これがモデル選定を「調べもの」から「作業」に変える転換点です。
8. 落とし穴
- 順位表で決めてしまう: 自社ドメインでの性能は測られていない。方向性の把握までに留める
- 性能から入ってライセンスで詰む: 順序を逆にする。ライセンス確認は無料で早い
- API と重みを混同する: リスク評価が丸ごと的外れになる。5 章のとおり分けて考える
- 「オープン」を過信する: 公開されているのは重みだけ。 は検証できない
- 特定モデルに密結合する: プロンプトも含めて 1 つのモデル前提で作り込むと、乗り換えが作り直しになる
- 違いを無視して比較する: 同じモデル名でも量子化が違えば別物。条件を揃えて比べる
- 評価セットを作らない: 毎回「なんとなく良さそう」で判断することになり、判断が積み上がらない
9. ふくふくの進め方
「モデルが多すぎて選べない」「中国製を使ってよいのか社内で結論が出ない」というご相談を受けています。前者には評価セットの設計から、後者には技術リスクと組織要件の切り分けから入るのが有効です。判断材料が揃っていないだけで、揃えれば決まる論点であることがほとんどです。
10. ここまでのまとめ
- 「今の最強」は半年もたない。年表・性格・選び方という腐りにくい知識で持つ
- 転換点は 2023 Llama → 2023-12 Mixtral(MoE) → 2024 Llama 3 / Gemma → 2024-09 画像入力 → 2025-01 DeepSeek R1 → 2025-08 gpt-oss → 2026 多極化
- オープンウェイト ≠ オープンソース。公開されているのは基本的に重みだけで、来歴は検証できない
- ライセンスは性能より先に見る。独自ライセンスは米国大手にも多い
- 「チャイナリスク」は API か重みかで分ける。手元で動かすならデータは出ない。残るのは来歴と出力の偏り、そして組織側の要件
- 選定は 載るサイズ → ライセンス → 実データ比較 の順。評価セットが本当の資産
モデル選びは、技術の目利きというより調達の作法に近い作業です。腐らない判断軸を持っておけば、次の世代が来ても慌てずに済みます。続編では、評価セットの具体的な作り方、量子化違いを揃えて比較する手順、そして量子化違いを揃えて比較する手順などを、読者リアクションに応じて随時追加していきます。なお、1 台に載らないモデルを複数台で動かす話は EP.17 で扱っています。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。