第74回ブログ|【2026年7月版】ローカルLLM続報 ─ 超巨大MoEの衝撃と日本語モデル最前線、そして現場は何を選ぶべきか

ローカルLLM続報 2026年7月版

前回(2026年5月版)から2ヶ月。ローカルLLMの世界では「2.8兆パラメータのオープンウェイト」という前回時点では想像しにくかった規模のモデルが登場し、日本語領域ではSwallowプロジェクトの新シリーズとデジタル庁「源内」の国産LLM実証が動き出した。この続編では、前回からの差分に絞って最新動向を整理し、「結局、手元・自社サーバーで何を動かすべきか」を2026年7月時点で再定義する。


前回のおさらいと、この2ヶ月で何が変わったか

前回記事(第71回)では、以下を結論とした。

この骨格は今も崩れていない。ただし2026年5月〜7月にかけて、3つの大きな地殻変動があった。

  1. 1. 超巨大オープンウェイトMoEの連続公開 ─ Kimi K3(2.8T)、Inkling(975B)、GLM-5.2(753B)、MiniMax M3(428B)など、「フロンティア級の知能がオープンウェイトで手に入る」時代が本格化した
  2. 2. 日本語モデルの世代交代 ─ Swallowプロジェクトが「Qwen3 Swallow」「GPT-OSS Swallow」を公開し、前回推薦したQwen3系を日本語面でさらに強化する選択肢が確立した
  3. 3. 国産LLMの政府実証開始 ─ デジタル庁のガバメントAI基盤「源内(GENAI)」で国産7モデルの大規模実証が始まり、「オンプレ・データ主権」の議論が国家レベルで実装フェーズに入った

以下、順に見ていく。


超巨大MoEの衝撃 ─ 「オープンウェイト」の意味が変わった

用語の再確認

2026年6月〜7月の主要リリース

モデル開発元規模(総/アクティブ)コンテキストライセンス備考
Kimi K3Moonshot AI(中国)2.8T / 約50B100万トークンModified MIT(予定)7/16発表、重みは7/27までに公開予定
InklingThinking Machines975B公開済み重みが既にダウンロード可能
GLM-5.2Zhipu AI(中国)753B / 40B100万トークンオープンコーディング性能でOSS首位との評価
MiniMax M3MiniMax(中国)428B100万トークンオープンSWE-Bench Pro 59%の報告
Kimi K2.6 / K2.7-CoderMoonshot AI1T MoEModified MITコーディング・エージェント特化
Nemotron 3 (Nano/Super/Ultra)NVIDIA(米国)Nanoは30B/3B、Ultraは550B100万トークン(Nano)NVIDIA OML(独自・商用要確認)Hybrid Mamba-Transformer MoE
DeepSeek V4DeepSeek(中国)1T規模と報告実行に142GB超のVRAM、Ollama/llama.cpp安定版では未対応

Kimi K3 ─ 「世界初のオープン3T級」の中身

2026年7月16日にMoonshot AIが発表したKimi K3は、この波の象徴だ。

そして重要なのが公開スケジュール。発表日から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. 1. 自社占有型フロンティアの選択肢が生まれた: H100/H200クラスタを持つ(または借りられる)組織なら、GPT-5.5級の知能を完全に自社統制下で運用できる。前回記事で述べた「データ主権」の議論が、フロンティア級性能と両立するようになった
  2. 2. 蒸留・派生モデルの母体になる: 巨大オープンウェイトは、そこから小型モデルへ知識蒸留(大きいモデルの出力を教師データとして小さいモデルを訓練する手法)する起点になる。コンシューマGPU帯のモデル品質は、今後この経路で底上げされていくと見られる

個人・中小規模の現場が今日やるべきことは変わらない。16〜24GB VRAM帯で動く実用モデルを軸に据え、巨大モデルはAPI経由で使い分ける。この構図は次章以降で更新する。

中国製モデルを業務で扱う際の注意

Kimi、GLM、MiniMax、DeepSeek、そしてQwenも、主力オープンウェイトの多くは中国企業製だ。オープンウェイトをローカル実行する限り、データが開発元に送信されることは構造上ない(ここがAPI利用との決定的な違い)。ただし業務導入では以下を先に整理しておくべきだ。


日本語モデル最前線(1): Qwen3 Swallow / GPT-OSS Swallow

前回記事で「Qwen3が日本語ローカルの第一推薦」と書いたが、その推薦を日本語面でさらに強化する形で、Swallowプロジェクト(東京科学大学 岡崎研究室・横田研究室+産業技術総合研究所)が2026年2月20日に新シリーズを公開している。前回記事では旧世代Swallowのみ触れていたため、ここで正面から扱う。

何が新しいのか

従来のSwallowシリーズは「日本語は強いが、最新の思考型(Reasoning)モデルのパラダイムに追随できていない」という課題があった。新シリーズは継続事前学習(CPT)+教師ありファインチューニング(SFT)+強化学習(RL)のレシピを全面刷新し、以下を達成したとされる。

ラインナップ

モデルサイズベース想定VRAM帯(Q4量子化目安)
Qwen3 Swallow 8B8BQwen3-8B8GB帯
Qwen3 Swallow 30B-A3B30B総/3B active (MoE)Qwen3-30B-A3B12〜16GB帯
Qwen3 Swallow 32B32BQwen3-32B24GB帯
GPT-OSS Swallow 20B20BOpenAI gpt-oss-20b16GB帯
GPT-OSS Swallow 120B120BOpenAI gpt-oss-120bサーバー級(MoEのため単体GPU実行の報告もあり要検証)

※VRAM目安は量子化レベル・コンテキスト長設定で大きく変動する。導入前に必ず実測を。

性能面のポイント

実務的な位置づけ

前回の推薦を次のように更新する。


日本語モデル最前線(2): デジタル庁「源内」と国産LLM 7モデル

もうひとつの大きな動きが政府側だ。デジタル庁は2026年3月6日、政府の生成AI共通基盤「源内(GENAI)」で試用する国産LLMとして、15件の応募から7モデルを選定した。

選定7モデル

提供元モデル特徴
NTTデータ(NTTグループ)tsuzumi 2約300億パラメータでGPU 1基で動作する軽量設計。金融・医療・公共の知識を事前強化
KDDI・ELYZALlama-3.1-ELYZA-JP-70BLlama 3.1ベースの日本語強化70B。128Kトークンの長文処理
ソフトバンク(SB Intuitions)系Sarashina2 mini4,600億パラメータ級基盤モデル「Sarashina」の知見を軽量版に凝縮
NECcotomi v3長文処理(30万字対応)とMCP対応のエージェント処理が特徴
富士通系Takane 32B行政実証で12万字を10分・精度80%超の処理実績
Preferred NetworksPLaMo 2.0 Prime既存OSSに依存しないフルスクラッチ国産。日本語性能世界トップクラスを標榜
日立CC Gov-LLM外部クラウド非依存の完全ローカル・セキュリティ特化

スケジュール(公表情報ベース)

なぜ技術者がこれを追うべきか

「政府の話は自分に関係ない」と思うかもしれないが、実務的な含意が3つある。

  1. 1. オンプレ・国産要件の調達仕様が標準化される: 2027年の評価公表以降、自治体・公共系案件のRFP(提案依頼書)に「源内実証で評価されたモデル」への言及が入る可能性が高い。公共系の受託開発をやるなら、7モデルの得意分野は頭に入れておくべきだ
  2. 2. 18万人規模の実運用データが出てくる: ベンチマークではわからない「行政文書の読解」「公文書生成」の実務評価が公表される予定。日本語LLMの実力を測る一級資料になる
  3. 3. 国産モデルのAPI・オンプレ提供が加速する: 政府調達を睨んで、各社が民間向け提供(PLaMoのOpenAI互換API、tsuzumi 2のAzure対応など)を拡充している。オンプレ案件の選択肢が実際に増えている

コンシューマ〜ワークステーション帯の現在地(2026年7月)

超巨大モデルの話題が先行するが、手元GPUで動く帯の勢力図も更新しておく。2026年7月時点の各種ランキング・比較では、総合性能でQwen3.6 27B、推論(Reasoning)でGemma 4 26B-A4Bを上位とする評価が多い。

前回からの主な変化:

VRAM帯別・2026年7月版のおすすめ(前回からの更新)

VRAM帯前回(5月)の推薦今回(7月)の推薦
8〜12GBQwen3-8B + Gemma 3 4BQwen3-8B系に加え Qwen3 Swallow 8B(日本語重視)、Gemma 4 E2B(速度)
16GBQwen3-14B 本命、30B-A3B挑戦Qwen3 Swallow 30B-A3B または Gemma 4 26B-A4B を本命候補に。GPT-OSS Swallow 20Bも比較対象
24GBQwen3-32B / Gemma 3 27BQwen3.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とセキュリティ対応は必須確認

# 見直し版: ollamaのポートバインドをローカルに限定する例
services:
  ollama:
    image: ollama/ollama:latest
    ports:
      - "127.0.0.1:11434:11434"   # ← 0.0.0.0公開をやめる
    # (以下は前回記事と同様)

vLLM: 「複数人で使う」なら本命

LM Studio: リモート接続とMCP対応


実務指針: 2026年後半に向けた3層アーキテクチャ

ここまでを踏まえ、当社が現時点で推す構成を「3層」で整理する。

第1層: 手元・エッジ(〜24GB VRAM)

第2層: 自社サーバー・オンプレ(48GB〜数百GB)

第3層: クラウドAPI(フロンティア)

そして層をまたぐ共通原則をひとつ。公開ベンチマークではなく、自社の実タスクで評価セットを持つこと。社内ライブラリ、日本語コメント、独自の文書様式──公開スコアが高いモデルが自社タスクで最良とは限らない、という指摘は複数の実務系レポートで共通している。モデル選定を「ランキングを見る作業」から「自社評価タスクを回す作業」に変えることが、この変化の速い時期を乗り切る唯一の安定戦略だと考えている。


まとめ: 前回結論のどこが変わり、どこが変わらないか

変わらないこと

変わったこと

半年前には「ローカルLLMはクラウドの劣化版ではなくなった」と書けば十分だった。いまは「どの層に、どの系統のモデルを、どんな評価で置くか」という設計論のフェーズに入っている。次回続編では、実際にQwen3 SwallowとGemma 4を同一の日本語業務タスクで実測比較したベンチマーク結果を報告したい。


参考情報源(2026年7月27日時点で確認)


*本記事は2026年7月27日時点の情報に基づきます。特にKimi K3の重み公開は本記事執筆時点で「7月27日までに公開予定」の段階であり、公開後の実測情報は各自最新情報をご確認ください。*