LLM-jp-4とは?国産オープンLLMの2モデル構成・性能・使い方を解説
LLM-jp-4は、国立情報学研究所(NII)の大規模言語モデル研究開発センター(LLMC)が2026年4月3日に公開した国産オープンソースLLMです。約86億パラメータの「8Bモデル」と、MoEを採用した「32B-A3Bモデル」の2種類を同時公開し、日本語MT-BenchではGPT-4oの7.29点を上回る7.82点を記録しました。学習コーパス・スクリプトまで公開する透明性の高さと、Apache License 2.0による商用利用のしやすさが特徴です。この記事では、モデル構成の違い、性能の実態、Hugging Faceでの使い方、商用利用の条件までを、NII公式発表とモデルカードの一次情報にもとづいて整理します。
目次
まとめ:LLM-jp-4の要点
LLM-jp-4の押さえどころは次の5点です。(1) NIIが主宰する2,600名超のコミュニティが開発した国産オープンLLMで、2026年4月3日に8Bと32B-A3Bを公開。(2) 8BはLlama 2、32B-A3BはQwen3 MoEアーキテクチャ(総約320億・推論時アクティブ約38億)で、単体GPUから本番用途まで用途で選べる。(3) 日本語MT-Benchで32B-A3BがGPT-4oを上回る性能を記録した(詳細は後述の比較表)。(4) base・instruct・thinkingの3系統があり、thinkingモデルはSystem 2推論で複雑な指示に強い。(5) Apache License 2.0で商用利用・改変・再配布が可能。より大規模な32Bと332B-A31Bも2026年度中に公開予定です。以降で、構成・性能・使い方の根拠を順に見ていきます。
LLM-jp-4とは|NII主導の国産オープンLLM
LLM-jp-4は、単独企業ではなく学術機関を核とした産学官連携で開発された点が、海外の商用LLMと最も異なります。まず、誰がどんな体制で作り、前世代から何が変わったのかを押さえます。
NII・LLMCと2,600名超コミュニティによる産学官連携体制
開発母体は、NIIが設立した大規模言語モデル研究開発センター(LLMC)が主宰する研究開発コミュニティ「LLM-jp」です。2026年3月31日時点で大学・企業から2,600名以上が参加し、自然言語処理と計算機システムの研究者を中心にSlackやオンライン会議で共同研究を進めています。計算資源には産業技術総合研究所のAI橋渡しクラウド「ABCI 3.0」を、資金には文部科学省補助金事業を活用しており、大量のGPUを長期間専有する国産LLM開発の障壁を、公的資金と学術ネットワークの共有で越えている点が特徴です。資金規模で海外ビッグテックに及ばなくても、日本語処理という一点で世界最高水準に到達できることを示した体制といえます。
LLM-jp-3から学習データ約6倍・コーパスまで公開する透明性
LLM-jp-4は前世代のLLM-jp-3.1シリーズと比べ、学習コーパスを約6倍に拡大しました。さらに構造面でも、13Bや172BといったDenseモデル中心だったLLM-jp-3に対し、MoE(Mixture of Experts)を採用した32B-A3Bを新たに加えています。もう一つの核が透明性で、オープンソースAIの定義(OSAID)に配慮し、第三者も入手可能な公開データ・政府文書・合成データのみを使用し、学習コーパス自体やコーパス構築スクリプトも公開しています。「どのデータで学習したか」が検証できるため、出力のバイアスや著作権リスクを企業が独自に評価でき、監査対応が求められる分野での採用判断がしやすくなります。関連するオープンモデルの潮流はQwen3とは?アリババのオープンLLMの特徴・モデル一覧・日本語性能・商用利用を解説でも整理しています。
8B・32B-A3B・thinkingモデルのラインアップと選び方
LLM-jp-4は「サイズ2種類 × 用途3系統」で提供され、この組み合わせを理解すると選定を誤りません。まず全体像を表で示し、設計差と選び方を解説します。
| モデル | 総パラメータ | アクティブ | アーキテクチャ | 目安VRAM | 主な用途 |
|---|---|---|---|---|---|
| LLM-jp-4 8B | 約86億 | 約86億 | Llama 2 | 16GB〜(推奨24GB) | 検証・エッジ・軽量運用 |
| LLM-jp-4 32B-A3B | 約320億 | 約38億 | Qwen3 MoE | 数十GB級 | 本番・高精度日本語処理 |
8Bモデルと32B-A3Bモデルの設計差
8Bモデルは約86億パラメータのLlama 2系Denseモデルで、VRAM 24GB程度のコンシューマ向けGPU単体でも動作が見込めます。対する32B-A3BはQwen3 MoEアーキテクチャを採用し、128個のエキスパートのうち推論時に8個だけを活性化する構造です。総パラメータ約320億の表現力を持ちながら、実際に計算されるのはアクティブ約38億パラメータ分で済むため、32Bクラスの精度を32層のMoEで効率的に引き出せます。つまり8Bは「軽さ優先」、32B-A3Bは「精度と推論効率の両立」という設計思想の違いです。
base・instruct・thinkingの3系統と使い分け
各サイズには、事前学習のみのbase、指示応答を学習させたinstruct、そして推論過程を明示的にたどるthinkingの3系統が用意されています。baseは追加学習の土台向けで、そのまま対話に使うものではありません。一般的なチャットや要約はinstructが基本です。thinkingモデルはSystem 2推論(じっくり考える段階的推論)を備え、多段の指示や論理を要するタスクで精度が上がります。thinkingモデルを目的に探すユーザーも多く、まず用途に合う系統を選ぶことが重要です。
用途別の選定基準と失敗しやすい選び方
選定の軸は「必要な日本語精度」と「使えるGPU」の2つに絞れます。社内チャットボットの初期検証や研究用途なら8Bで十分で、単体GPUに載るため試行コストが低く済みます。カスタマーサポートの自動応答や大量文書の要約・分類など精度がKPIに直結する本番用途では32B-A3Bが適します。ありがちな失敗は、単純タスクにいきなり32B-A3Bを選んで運用コストを膨らませるケースと、逆に高精度が要る業務に8Bを充てて後述の日本語MT-Benchでの性能差を軽視するケースです。まず8Bで要件を満たせるか検証し、足りなければ32B-A3Bへ上げる順序が堅実です。
約12兆トークンのコーパスとMoEアーキテクチャ
性能を支えるのは、データの量ではなく「質を絞り込んだ量」です。コーパスの作り方とMoE・トークナイザの技術要素を押さえます。
19.5兆トークンから選別した「LLM-jp Corpus v4.1」
学習コーパスは、約19.5兆トークンのソースプールから品質基準を満たす約12兆トークンを選別して構築され、「LLM-jp Corpus v4.1」として公開されています。ソースプールの内訳は日本語約7,000億、英語約17.8兆、中国語・韓国語約8,500億、コード約2,000億トークンです。実際の学習には事前学習で約10.5兆、中間学習で約1.2兆、合計約11.7兆トークンが使われました。政府文書や国会議事録が敬語・制度用語の学習に効き、合成データが不足ドメインの補完に使われています。パラメータを際限なく増やすのではなく、高品質データで効率的に学習させる「データ最適化スケーリング」の考え方に沿った構築です。
128エキスパートから8選択するMoEとllm-jp-tokenizer v4.0
32B-A3BのMoEは、32層の各層で128個のエキスパートのうち8個を動的に選ぶルーティングを行い、計算量を抑えます。トークナイザは独自の「llm-jp-tokenizer v4.0」で、Hugging Face tokenizersのUnigram byte-fallbackモデルとして構成されています。日本語を効率よくトークン化できるため、同じ文脈長でも扱える日本語量が増え、推論コストの低減にもつながります。カスタムトークナイザのため、後述のとおりロード時に専用の設定が必要になる点は運用上の注意点です。
日本語MT-BenchでGPT-4oを上回った性能と評価の注意点
LLM-jp-4の話題性の中心が、この日本語ベンチマークの結果です。数値の内訳と、鵜呑みにしないための注意点を整理します。
| MT-Bench | 8B | 32B-A3B | GPT-4o | Qwen3-8B |
|---|---|---|---|---|
| 日本語 | 7.54 | 7.82 | 7.29 | 7.14 |
| 英語 | 7.79 | 7.86 | 7.69 | 7.67 |
日本語・英語MT-Benchのスコア内訳
日本語MT-Benchでは32B-A3Bが7.82点、8Bが7.54点を記録し、いずれもGPT-4o(7.29点)とQwen3-8B(7.14点)を上回りました。英語MT-Benchでも32B-A3Bが7.86点、8Bが7.79点で、GPT-4o(7.69点)と同等以上です。8Bと32B-A3Bの日本語スコア差は0.28点で、モデルサイズの差ほどには開いていません。小規模でも実用水準の日本語品質に届いていることが、8Bを軽視できない根拠になります。
llm-jp-evalの横断評価とスコア比較の落とし穴
MT-Benchに加え、42タスクを横断する「llm-jp-eval」でもQwen3-8Bと並ぶ日本語総合力が確認されています。ただしMT-BenchはLLM-as-a-Judge(別のLLMが採点する方式)で測るため、採点者モデルが変わると過去スコアと単純比較できません。日本語MT-Benchでのわずかな優位をもって「あらゆる面でGPT-4o超え」と読むのは誤りで、コーディングや長文生成では差が出る可能性があります。導入前には自社の実タスクで検証することを前提に、ベンチマークは相対比較の目安として扱うのが妥当です。ベンチマークの読み方はgpt-oss-120bの性能とは?20bとの違い・ベンチマーク・必要GPUを徹底比較【OpenAI公式】も参考になります。
SFT・DPOによる事後学習とthinking機能
ベンチマークの高さは、事前学習だけでなく事後学習(アライメント)の設計に支えられています。学習手法とthinkingモデルの仕組みを見ます。
SFT+DPOによるアライメントと安全性
LLM-jp-4の事後学習は、22種類の日英インストラクションデータによる教師ありファインチューニング(SFT)と、人間の選好を反映する直接選好最適化(DPO)で構成され、強化学習(RLHF)は使っていません。SFTで指示追従の基礎を、DPOで応答の望ましさを整えるという役割分担です。DPOは安全性ベンチマーク「AnswerCarefully」に効くよう設計されており、危険な要求への慎重な応答を学ばせています。RLを避けてSFTとDPOだけで整合性を確保した点は、学習の再現性と安定性を重視した判断といえます。
thinkingモデルのSystem 2推論・65,536トークン文脈・Harmony形式
thinkingモデルは、回答前に推論過程を展開するSystem 2推論を備え、複雑な指示や多段の論理を要するタスクで精度が高まります。文脈長は最大65,536トークン(約6万5千トークン)に対応し、長文の要約や複数文書の横断処理に活きます。加えてthinkingモデルのchat templateはOpenAIの「Harmony応答形式」と互換になるよう設計されており、Harmony対応のツールチェーンに載せやすいのが実務上の利点です。ただしトークナイザはopenai-harmonyライブラリの前提と異なるため、統合時は公式のテンプレート指定に従う必要があります。
Hugging Faceでの使い方と必要GPUスペック
LLM-jp-4はHugging Faceで公開されており、transformersから数行で呼び出せます。ロード手順と、8B・32B-A3Bそれぞれの実行環境を押さえます。
transformersでのロード手順と必須設定
基本はモデルIDを指定してロードするだけですが、独自トークナイザを使うためtrust_remote_code=Trueの指定が要ります。推論はbfloat16精度が推奨で、安易な低ビット量子化は日本語品質を落とすことがあるため、品質要件と相談して選びます。初回セットアップは、各モデルカードに記載された実装例をなぞると迷いません。
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model_id = "llm-jp/llm-jp-4-8b-instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
model_id,
torch_dtype=torch.bfloat16,
device_map="auto",
trust_remote_code=True,
)
用途に応じてモデルIDの末尾を-8b-thinkingや-32b-a3b-thinkingに差し替えれば、System 2推論版を同じ手順で試せます。
8B・32B-A3Bの必要VRAMとローカル実行の注意
bfloat16で動かす場合、8Bはおおむねパラメータ数の2倍にあたるVRAM(16GB前後+推論オーバーヘッド)が目安で、24GB級のGPUなら余裕を持って載ります。32B-A3BはMoEのためアクティブは約38億ですが、全エキスパートをメモリに保持する必要があり、総パラメータ約320億分のVRAMを見込む必要があります。手元のGPUが小さい場合はGGUF形式への量子化やOllama等での実行が選択肢になりますが、量子化は精度低下を伴うため本番前に日本語品質を必ず検証してください。ローカル実行環境の組み方はOllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法が参考になります。
Apache License 2.0での商用利用と導入判断
企業導入で最初に確認すべきがライセンスです。LLM-jp-4はApache License 2.0で提供され、商用のハードルは低いものの、確認しておくべき点があります。
Apache 2.0で許される範囲と透明性の実務メリット
Apache License 2.0は、商用利用・改変・再配布を広く許容し、特許条項と免責条項を備えた実務で扱いやすいライセンスです。自社サービスへの組み込みや派生モデルの公開も原則可能で、追加の商用契約は不要です。加えてLLM-jp-4は学習コーパスとスクリプトが公開されているため、「AIが何を学んでいるか」を説明する監査対応がしやすく、規制業界での採用理由になります。派生モデルを配布する際はライセンス表示と改変告知の要件を満たすよう、公開前に条項を確認しておくと安全です。
金融・医療・官公庁でのデータ主権とオンプレ判断
データを外部APIに送れない金融・医療・官公庁では、モデルを自社環境に置けること自体が採用の前提になります。LLM-jp-4はオープンモデルのためオンプレミスや自社クラウドで完結でき、機密データを外部に出さずに日本語処理を実装できます。データ主権と説明責任の両方を満たせる点が、海外の商用APIに対する明確な優位です。オンプレ運用ではGPU調達と運用体制がコスト要因になるため、まず8Bで要件検証してから規模を決めると、過剰投資を避けられます。
332B-A31B公開を控えた2026年度の活用戦略
LLM-jp-4は現時点の2モデルで完結せず、より大規模なモデルが続きます。今後の展開を踏まえた導入の進め方を示します。
2026年度公開予定の32B・332B-A31Bと段階導入
NIIは、より大規模なDenseモデル「LLM-jp-4 32Bモデル」と、超大規模MoEモデル「LLM-jp-4 332B-A31Bモデル」を2026年度中に順次公開する予定です。332B-A31Bが出れば、国産オープンLLMの精度は一段上がる見込みです。現時点の実装は、将来の大規模モデルへ差し替えられる前提で設計しておくのが得策で、まず8Bでユースケースを固め、精度が足りなければ32B-A3B、さらに大規模モデルへと段階的に引き上げる進め方が無駄になりません。
API依存脱却・データ主権の選択肢としての評価とコミュニティ参加
LLM-jp-4は、海外の商用APIへの依存を減らし、コストとデータ主権を自社でコントロールする現実的な選択肢です。日本語精度がGPT-4oに並ぶ水準に達したことで、「国産オープンモデルだから精度を妥協する」という前提は崩れました。さらにLLM-jpコミュニティへ参加すれば、最新の開発動向や評価手法に触れられ、自社のAI人材育成にもつながります。ローカルLLM運用のUI整備にはOpen WebUIとは|機能・インストール・APIキー発行までを実コマンドで解説もあわせて検討するとよいでしょう。
よくある質問
LLM-jp-4は商用利用できますか?
できます。LLM-jp-4はApache License 2.0で公開されており、商用利用・改変・再配布が原則可能です。追加の商用契約は不要ですが、派生モデルを配布する際はライセンス表示と改変告知の要件を満たす必要があります。
8Bモデルと32B-A3Bモデルはどちらを選ぶべきですか?
検証・エッジ用途や単体GPU環境なら約86億パラメータの8B、本番の高精度な日本語処理なら32B-A3Bが適します。日本語MT-Benchのスコア差は0.28点と小さいため、まず8Bで要件を満たせるか試し、足りなければ32B-A3Bへ上げる順序が堅実です。
LLM-jp-4の使い方は?
Hugging Faceで公開されており、transformersからtrust_remote_code=Trueを指定してロードします。推論はbfloat16が推奨です。GPUが小さい場合はGGUF量子化やOllamaでのローカル実行も選べますが、量子化は日本語品質の低下を伴うため事前検証が必要です。
LLM-jp-4はGPT-4oより優れていますか?
日本語MT-Benchでは32B-A3Bが7.82点でGPT-4o(7.29点)を上回りました。ただしLLM-as-a-Judge方式の指標であり、コーディングや長文生成など他タスクで差が出る可能性があるため、全面的に優れているとは言えません。自社の実タスクでの検証が前提です。
LLM-jp-4のthinkingモデルとは何ですか?
回答前に推論過程を展開するSystem 2推論を備えたモデルで、8Bと32B-A3Bの両方に用意されています。多段の指示や論理を要するタスクで精度が上がり、chat templateはOpenAIのHarmony応答形式と互換になるよう設計されています。