第74回ブログ|【2026年7月版】ローカルLLM続報 ─ 超巨大MoEの衝撃と日本語モデル最前線、そして現場は何を選ぶべきか
前回(2026年5月版)から2ヶ月。ローカルLLMの世界では「2.8兆パラメータのオープンウェイト」という前回時点では想像しにくかった規模のモデルが登場し、日本語領域ではSwallowプロジェクトの新シリーズとデジタル庁「源内」の国産LLM実証が動き出した。この続編では、前回からの差分に絞って最新動向を整理し、「結局、手元・自社サーバーで何を動かすべきか」を2026年7月時点で再定義する。
前回のおさらいと、この2ヶ月で何が変わったか
前回記事(第71回)では、以下を結論とした。
- - メインモデルは Qwen3シリーズ(日本語汎用の本命)
- - 速度・マルチモーダルは Gemma 3 / 4
- - 特化用途は ELYZA / Swallow / ABEJA系
- - 推論ツールは 本番=Ollama、検証=LM Studio、最大化=llama.cpp
この骨格は今も崩れていない。ただし2026年5月〜7月にかけて、3つの大きな地殻変動があった。
- 1. 超巨大オープンウェイトMoEの連続公開 ─ Kimi K3(2.8T)、Inkling(975B)、GLM-5.2(753B)、MiniMax M3(428B)など、「フロンティア級の知能がオープンウェイトで手に入る」時代が本格化した
- 2. 日本語モデルの世代交代 ─ Swallowプロジェクトが「Qwen3 Swallow」「GPT-OSS Swallow」を公開し、前回推薦したQwen3系を日本語面でさらに強化する選択肢が確立した
- 3. 国産LLMの政府実証開始 ─ デジタル庁のガバメントAI基盤「源内(GENAI)」で国産7モデルの大規模実証が始まり、「オンプレ・データ主権」の議論が国家レベルで実装フェーズに入った
以下、順に見ていく。
超巨大MoEの衝撃 ─ 「オープンウェイト」の意味が変わった
用語の再確認
- - MoE(Mixture of Experts / 混合専門家): モデル内部を多数の「専門家(Expert)」に分割し、トークンごとに一部の専門家だけを起動する設計。総パラメータは巨大でも、推論時に実際に計算されるアクティブパラメータは小さく抑えられる
- - オープンウェイト(Open Weight): 学習済みモデルの重み(パラメータ)ファイルが配布され、ダウンロードして自前環境で実行・改変できる形態。学習コードやデータまで公開する「フルオープンソース」とは区別される
2026年6月〜7月の主要リリース
| モデル | 開発元 | 規模(総/アクティブ) | コンテキスト | ライセンス | 備考 |
| Kimi K3 | Moonshot AI(中国) | 2.8T / 約50B | 100万トークン | Modified MIT(予定) | 7/16発表、重みは7/27までに公開予定 |
| Inkling | Thinking Machines | 975B | ─ | 公開済み | 重みが既にダウンロード可能 |
| GLM-5.2 | Zhipu AI(中国) | 753B / 40B | 100万トークン | オープン | コーディング性能でOSS首位との評価 |
| MiniMax M3 | MiniMax(中国) | 428B | 100万トークン | オープン | SWE-Bench Pro 59%の報告 |
| Kimi K2.6 / K2.7-Coder | Moonshot AI | 1T MoE | ─ | Modified MIT | コーディング・エージェント特化 |
| Nemotron 3 (Nano/Super/Ultra) | NVIDIA(米国) | Nanoは30B/3B、Ultraは550B | 100万トークン(Nano) | NVIDIA OML(独自・商用要確認) | Hybrid Mamba-Transformer MoE |
| DeepSeek V4 | DeepSeek(中国) | 1T規模と報告 | ─ | ─ | 実行に142GB超のVRAM、Ollama/llama.cpp安定版では未対応 |
Kimi K3 ─ 「世界初のオープン3T級」の中身
2026年7月16日にMoonshot AIが発表したKimi K3は、この波の象徴だ。
- - 総パラメータ2.8兆のスパースMoE。896個のエキスパートのうち16個だけをトークンごとに起動する設計(Stable LatentMoEと呼称)
- - 100万トークンのコンテキストウィンドウと、画像・動画を扱えるネイティブマルチモーダル
- - 重みはMXFP4という低精度フォーマットで扱われ、デコード高速化技術(KDA)により最大6.3倍の高速化を謳う
- - フロントエンドコード生成のArena評価で1位を獲得したとの報告
そして重要なのが公開スケジュール。発表日からAPI・アプリでは利用可能だが、モデル重みの公開は「2026年7月27日までに」とアナウンスされている。つまり本記事執筆時点がちょうどその期日にあたる。公開されれば、オープンウェイトとしては史上最大級となる。
冷静な現実: これらは「手元で動くローカルLLM」ではない
ここで実務者として釘を刺しておきたい。
Kimi K3のセルフホストには推定650GB〜1TBのメモリが必要とされ、Kimi K2系(1T MoE)ですらフル実行に約340GBのVRAMが要る。GLM-5.2やNemotron 3 Ultraもサーバー級GPU構成が前提だ。DeepSeek V4に至っては、そもそもOllamaやllama.cppの安定版がアーキテクチャを読み込めない段階にある。
つまり、この超巨大MoE群の実務的な意味は「RTX 5090で動く」ではなく、次の2点にある。
- 1. 自社占有型フロンティアの選択肢が生まれた: H100/H200クラスタを持つ(または借りられる)組織なら、GPT-5.5級の知能を完全に自社統制下で運用できる。前回記事で述べた「データ主権」の議論が、フロンティア級性能と両立するようになった
- 2. 蒸留・派生モデルの母体になる: 巨大オープンウェイトは、そこから小型モデルへ知識蒸留(大きいモデルの出力を教師データとして小さいモデルを訓練する手法)する起点になる。コンシューマGPU帯のモデル品質は、今後この経路で底上げされていくと見られる
個人・中小規模の現場が今日やるべきことは変わらない。16〜24GB VRAM帯で動く実用モデルを軸に据え、巨大モデルはAPI経由で使い分ける。この構図は次章以降で更新する。
中国製モデルを業務で扱う際の注意
Kimi、GLM、MiniMax、DeepSeek、そしてQwenも、主力オープンウェイトの多くは中国企業製だ。オープンウェイトをローカル実行する限り、データが開発元に送信されることは構造上ない(ここがAPI利用との決定的な違い)。ただし業務導入では以下を先に整理しておくべきだ。
- - API利用とローカル実行の峻別: 同じ「Kimi K3を使う」でも、API経由なら中国事業者へのデータ送信を意味する。社内ルール上どちらの話をしているのか常に明示する
- - ライセンスの実質確認: Modified MIT、NVIDIA OMLなど「オープンだが条件付き」のライセンスが増えた。Apache 2.0(Qwen3、Gemma系、Swallow系)との違いを法務観点で確認する
- - モデルの出力傾向・安全性評価: 政治的トピックや規制関連の応答傾向は開発国の影響を受けうる。業務ドメインでの評価タスクを自社で持つこと(後述)
日本語モデル最前線(1): Qwen3 Swallow / GPT-OSS Swallow
前回記事で「Qwen3が日本語ローカルの第一推薦」と書いたが、その推薦を日本語面でさらに強化する形で、Swallowプロジェクト(東京科学大学 岡崎研究室・横田研究室+産業技術総合研究所)が2026年2月20日に新シリーズを公開している。前回記事では旧世代Swallowのみ触れていたため、ここで正面から扱う。
何が新しいのか
従来のSwallowシリーズは「日本語は強いが、最新の思考型(Reasoning)モデルのパラダイムに追随できていない」という課題があった。新シリーズは継続事前学習(CPT)+教師ありファインチューニング(SFT)+強化学習(RL)のレシピを全面刷新し、以下を達成したとされる。
- - ベースモデル(Qwen3 / GPT-OSS)の数学・コード能力を損なわずに日本語知識・日本語対話力を強化
- - 深く考えてから回答するTest Time Scaling型の思考(Thinking)に対応した推論型モデルとして構築
- - Apache 2.0ライセンスで商用利用も自由
ラインナップ
| モデル | サイズ | ベース | 想定VRAM帯(Q4量子化目安) |
| Qwen3 Swallow 8B | 8B | Qwen3-8B | 8GB帯 |
| Qwen3 Swallow 30B-A3B | 30B総/3B active (MoE) | Qwen3-30B-A3B | 12〜16GB帯 |
| Qwen3 Swallow 32B | 32B | Qwen3-32B | 24GB帯 |
| GPT-OSS Swallow 20B | 20B | OpenAI gpt-oss-20b | 16GB帯 |
| GPT-OSS Swallow 120B | 120B | OpenAI gpt-oss-120b | サーバー級(MoEのため単体GPU実行の報告もあり要検証) |
※VRAM目安は量子化レベル・コンテキスト長設定で大きく変動する。導入前に必ず実測を。
性能面のポイント
- - GPT-OSS Swallow 120Bは日本語タスク平均スコア0.642を記録し、総パラメータ120B以下のオープンモデルとして日本語最高性能を達成したと報告されている。特に日本の知識量を問うベンチマーク(JamC-QA)で元モデルからの顕著な向上が確認された
- - 学習データの約半分に日本語大規模コーパス(Swallowコーパス)を使用しており、「日本の固有知識」「日本語の自然さ」という汎用中国製・米国製モデルの弱点を直接補う設計
実務的な位置づけ
前回の推薦を次のように更新する。
- - 16GB VRAM帯の日本語業務: これまでの「Qwen3-14B」に加えて、Qwen3 Swallow 30B-A3B(MoE) が最有力候補に浮上。MoEのため実効VRAMを抑えつつ、日本語知識はSwallowコーパスで強化済み
- - 日本の制度・固有名詞・敬語表現が重要な業務(行政文書、社内規程、医療・介護記録など): Swallow系を第一候補として比較評価する価値が高い
- - 注意点: Ollamaの公式ライブラリに常に最新のSwallow系があるとは限らない。Hugging FaceからGGUF版を取得して
Modelfileで登録する運用を想定しておく(コミュニティ変換版を使う場合は変換品質・チャットテンプレートの正しさを必ず確認)
日本語モデル最前線(2): デジタル庁「源内」と国産LLM 7モデル
もうひとつの大きな動きが政府側だ。デジタル庁は2026年3月6日、政府の生成AI共通基盤「源内(GENAI)」で試用する国産LLMとして、15件の応募から7モデルを選定した。
選定7モデル
| 提供元 | モデル | 特徴 |
| NTTデータ(NTTグループ) | tsuzumi 2 | 約300億パラメータでGPU 1基で動作する軽量設計。金融・医療・公共の知識を事前強化 |
| KDDI・ELYZA | Llama-3.1-ELYZA-JP-70B | Llama 3.1ベースの日本語強化70B。128Kトークンの長文処理 |
| ソフトバンク(SB Intuitions)系 | Sarashina2 mini | 4,600億パラメータ級基盤モデル「Sarashina」の知見を軽量版に凝縮 |
| NEC | cotomi v3 | 長文処理(30万字対応)とMCP対応のエージェント処理が特徴 |
| 富士通系 | Takane 32B | 行政実証で12万字を10分・精度80%超の処理実績 |
| Preferred Networks | PLaMo 2.0 Prime | 既存OSSに依存しないフルスクラッチ国産。日本語性能世界トップクラスを標榜 |
| 日立 | CC Gov-LLM | 外部クラウド非依存の完全ローカル・セキュリティ特化 |
スケジュール(公表情報ベース)
- - 2026年5月〜: 源内を全府省庁39機関・職員約18万人規模に展開する大規模実証
- - 2026年8月頃: 源内内で国産LLMの試用開始
- - 2027年1月: 評価・検証結果の一部公表
- - 2027年4月以降: 優れたモデルの有償調達開始予定
なぜ技術者がこれを追うべきか
「政府の話は自分に関係ない」と思うかもしれないが、実務的な含意が3つある。
- 1. オンプレ・国産要件の調達仕様が標準化される: 2027年の評価公表以降、自治体・公共系案件のRFP(提案依頼書)に「源内実証で評価されたモデル」への言及が入る可能性が高い。公共系の受託開発をやるなら、7モデルの得意分野は頭に入れておくべきだ
- 2. 18万人規模の実運用データが出てくる: ベンチマークではわからない「行政文書の読解」「公文書生成」の実務評価が公表される予定。日本語LLMの実力を測る一級資料になる
- 3. 国産モデルのAPI・オンプレ提供が加速する: 政府調達を睨んで、各社が民間向け提供(PLaMoのOpenAI互換API、tsuzumi 2のAzure対応など)を拡充している。オンプレ案件の選択肢が実際に増えている
コンシューマ〜ワークステーション帯の現在地(2026年7月)
超巨大モデルの話題が先行するが、手元GPUで動く帯の勢力図も更新しておく。2026年7月時点の各種ランキング・比較では、総合性能でQwen3.6 27B、推論(Reasoning)でGemma 4 26B-A4Bを上位とする評価が多い。
前回からの主な変化:
- - Qwenは3.5 → 3.6 → 3.7へ世代交代。ただし最新のQwen3.7-Plus / Maxは非公開(API専用)で、ローカルで使えるオープンウェイトは一世代前のQwen3.6系までという「オープン版は一歩遅れ」の構図が明確になった。この「フラッグシップはクローズド、一世代前をオープン化」というリリース戦略は各社に共通しつつある
- - Gemma 4のMoE版(26B-A4B) が推論系ベンチマークで存在感を増し、約15GBのメモリで動く「16GB帯の推論番長」の地位を確立しつつある
- - CPU専用・超軽量帯ではPhi-4-miniやGemma 4 E2Bが定番化。GPU非搭載の業務端末でのオフライン処理という新しいニッチが生まれている
VRAM帯別・2026年7月版のおすすめ(前回からの更新)
| VRAM帯 | 前回(5月)の推薦 | 今回(7月)の推薦 |
| 8〜12GB | Qwen3-8B + Gemma 3 4B | Qwen3-8B系に加え Qwen3 Swallow 8B(日本語重視)、Gemma 4 E2B(速度) |
| 16GB | Qwen3-14B 本命、30B-A3B挑戦 | Qwen3 Swallow 30B-A3B または Gemma 4 26B-A4B を本命候補に。GPT-OSS Swallow 20Bも比較対象 |
| 24GB | Qwen3-32B / Gemma 3 27B | Qwen3.6 27B / Qwen3 Swallow 32B / Gemma 4 31B |
| 32GB超〜サーバー | 70B級、Llama 4 Scout | 上記に加えGPT-OSS Swallow 120B(MoE)、さらに上はGLM-5.2等の巨大MoE(H100級前提) |
共通の指針も更新する: 前回は「タスクごとにモデルを使い分ける」と書いたが、今回はさらに一歩進めて、「日本語知識が問われるタスクか、論理・コードが問われるタスクか」で系統を分けることを勧めたい。前者はSwallow系・国産系、後者はQwen/Gemma素の系統が安定する、というのが現時点の見立てだ(もちろん自社タスクでの実測が最終判断)。
運用レイヤーの更新: Ollama / vLLM / LM Studio
Ollama: v0.32.0とセキュリティ対応は必須確認
- - v0.32.0(2026年7月13日リリース) で、引数なしで
ollamaを実行すると対話型コーディングエージェントが起動するという大きなUX変更が入った。ollama run / pull / serveなどサブコマンド明示の挙動は変わらないため、スクリプト・CI/CDへの影響は限定的だが、引数なしollamaをヘルプ表示目的で呼んでいる自動化があれば要修正
- - セキュリティ: CVE-2026-7482という深刻な脆弱性が公表されており、最新版へのアップデートとポート11434を外部公開しないことが強く推奨されている。前回記事のDocker Compose例では
11434:11434を素直に公開していたが、本番・共有ネットワーク環境では127.0.0.1:11434:11434にバインドを絞る、あるいはリバースプロキシ経由のみに限定する構成へ見直してほしい
- - Flash Attentionはバックエンドでのデフォルト有効化が進み、以前ほど環境変数での明示指定に神経質になる必要は減ってきた(それでも
OLLAMA_CONTEXT_LENGTHの明示は引き続き推奨)
# 見直し版: ollamaのポートバインドをローカルに限定する例
services:
ollama:
image: ollama/ollama:latest
ports:
- "127.0.0.1:11434:11434" # ← 0.0.0.0公開をやめる
# (以下は前回記事と同様)
vLLM: 「複数人で使う」なら本命
- - 2026年5月にv0.21.0が安定版リリース、v0.22系がRC段階。1台のGPUで数十人規模の同時リクエストを捌く用途では、OllamaではなくvLLMが決定版という評価が定着した
- - 使い分けの目安: 1人〜数人の開発・検証はOllama、部門・全社の同時アクセスはvLLM。前回記事の「スケーリング」節で触れた移行パスが、そのまま現在も有効
LM Studio: リモート接続とMCP対応
- - v0.4.12(2026年4月)でリモート接続機能(LM Link)やMCP(Model Context Protocol: AIアプリと外部ツールを接続する標準プロトコル) 連携が入り、単なるGUIモデルランチャーから「検証用ハブ」へ進化している。モデル比較フェーズの標準ツールという位置づけは変わらず
実務指針: 2026年後半に向けた3層アーキテクチャ
ここまでを踏まえ、当社が現時点で推す構成を「3層」で整理する。
第1層: 手元・エッジ(〜24GB VRAM)
- - 日本語業務: Qwen3 Swallow系(8B / 30B-A3B / 32B)
- - コード・論理: Qwen3.6系、Gemma 4系
- - 役割: 機密データの一次処理、オフライン業務、定型文書処理
- - ランタイム: Ollama(最新版必須・ポート非公開)
第2層: 自社サーバー・オンプレ(48GB〜数百GB)
- - GPT-OSS Swallow 120B、GLM-5.2などの大型オープンウェイト
- - 役割: 全社RAG、部門横断の同時アクセス、ファインチューニング母体
- - ランタイム: vLLM(同時リクエスト最適化)
- - 公共・規制業種は源内実証の評価公表(2027年1月)を追いつつ国産モデルも比較軸に
第3層: クラウドAPI(フロンティア)
- - Claude、GPT系、そして(データ要件が許すなら)Kimi K3等のAPI
- - 役割: 最高難度の推論・エージェントタスク
- - 原則: 機密データは第1〜2層で処理し、抽象化・匿名化した問題だけを第3層へ
そして層をまたぐ共通原則をひとつ。公開ベンチマークではなく、自社の実タスクで評価セットを持つこと。社内ライブラリ、日本語コメント、独自の文書様式──公開スコアが高いモデルが自社タスクで最良とは限らない、という指摘は複数の実務系レポートで共通している。モデル選定を「ランキングを見る作業」から「自社評価タスクを回す作業」に変えることが、この変化の速い時期を乗り切る唯一の安定戦略だと考えている。
まとめ: 前回結論のどこが変わり、どこが変わらないか
変わらないこと
- - 16〜24GB VRAM帯が個人・小規模の主戦場であること
- - Ollama(開発)/ vLLM(本番多人数)/ LM Studio(検証)の役割分担
- - 「クラウドとローカルのハイブリッド」が現実解であること
変わったこと
- - 日本語第一推薦は「素のQwen3」から「Qwen3 Swallow / GPT-OSS Swallowを含めた比較」へ
- - オープンウェイトの上限が「70B級」から「兆(T)級」へ。自社占有フロンティアが技術的選択肢になった
- - 国産LLMが「研究的存在」から「政府実証中の調達候補」へ。公共系案件の前提知識になった
- - Ollamaはセキュリティアップデートが必須のフェーズに入った(CVE-2026-7482)
半年前には「ローカルLLMはクラウドの劣化版ではなくなった」と書けば十分だった。いまは「どの層に、どの系統のモデルを、どんな評価で置くか」という設計論のフェーズに入っている。次回続編では、実際にQwen3 SwallowとGemma 4を同一の日本語業務タスクで実測比較したベンチマーク結果を報告したい。
参考情報源(2026年7月27日時点で確認)
- - Swallow LLM Project: Qwen3 Swallow 公式ページ (swallow-llm.github.io/qwen3-swallow.ja.html)
- - gihyo.jp: GPT-OSS Swallow / Qwen3 Swallow リリース報道 (2026年2月)
- - GIGAZINE: GPT-OSS Swallow 120Bの日本語ベンチマーク解説 (2026年2月)
- - ITmedia: デジタル庁「源内」国産LLM 7モデル選定 (2026年3月6日)
- - Qiita: 源内 7モデル比較・選定背景の考察記事 (2026年3月〜6月)
- - 各社技術ブログ: Kimi K3発表・セルフホスト要件の分析 (2026年7月16日以降)
- - 株式会社オブライト: ローカルLLM 2026年4月版/6月版 全体像、Kimi K3スペック解説
- - note (Temora): 2026年6月時点オープンウェイトLLMまとめ
- - OpenBridge: ローカルコーディングAIモデル比較 (2026年6月)
- - PromptQuorum: 2026年7月ローカルLLMランキング
- - フィデックス株式会社 / 源勝AI実験室: Ollama v0.32.0 アップデート解説 (2026年7月13日リリース)
- - AI革命株式会社: Ollama解説(CVE-2026-7482への言及)
- - わろかいのLLMブログ: vLLM v0.21.0 / LM Studio v0.4.12 情報
*本記事は2026年7月27日時点の情報に基づきます。特にKimi K3の重み公開は本記事執筆時点で「7月27日までに公開予定」の段階であり、公開後の実測情報は各自最新情報をご確認ください。*