2026年4月3日、国立情報学研究所（NII）が国産LLM「LLM-jp-4」を公開しました。日本語MT-Benchで GPT-4o のスコアを上回ったという発表は、国内外で大きな注目を集めています。
この記事では、LLM-jp-4 の技術的な中身を掘り下げながら、「なぜ日本語特化モデルが汎用モデルに勝てたのか」「実務で使えるのか」を検証します。
LLM-jp-4 の発表概要
NIIが公開したモデルは2種類です。
| 項目 | LLM-jp-4 8B | LLM-jp-4 32B-A3B |
|---|---|---|
| パラメータ数 | 約85.9億 | 約320億（MoE、アクティブ38億） |
| アーキテクチャ | Llama 2ベース | Qwen3 MoEベース |
| レイヤー数 / 隠れサイズ | 32層 / 4,096 | ― |
| MoE構成 | ― | 128エキスパート、8アクティブ |
| 訓練データ | 約11.7兆トークン | 約11.7兆トークン |
| コンテキスト長 | 最大65,536トークン | 最大65,536トークン |
| トークナイザー | llm-jp-tokenizer v4.0（Unigram byte-fallback） | 同左 |
| ライセンス | Apache License 2.0 | Apache License 2.0 |
訓練には、NIIが運用するスーパーコンピュータ ABCI 3.0（NVIDIA H200 GPU × 6,128基）が使われています。
注目すべきは32B-A3Bモデルの設計です。総パラメータ数は320億ですが、MoE（Mixture of Experts）構造により推論時にアクティブになるのは38億パラメータのみです。具体的には、128個のエキスパートモジュールのうち8個がルーティング機構によって入力ごとに選択されます。つまり、8Bモデル並みの推論コストで、32B級の知識量を持つモデルとして動作します。
ベンチマークスコア
日本語MT-Benchのスコアは以下のとおりです（評価にはgpt-5.4-2026-03-05をLLM-as-a-Judgeとして使用）。
| モデル | 日本語MT-Bench | 英語MT-Bench |
|---|---|---|
| LLM-jp-4 8B (medium) | 7.54 | 7.79 |
| LLM-jp-4 32B-A3B | 7.82 | 7.86 |
| GPT-4o (2024-08-06) | 7.29 | 7.69 |
| gpt-oss-20b (medium) | 7.33 | 7.85 |
| Qwen3-8B | 7.14 | ― |
日本語MT-Benchで8Bモデルが7.54、32B-A3Bモデルが7.82を記録し、GPT-4oの7.29を明確に上回りました。英語MT-Benchでも同等以上のスコアを出している点は見逃せません。日本語に特化しつつ、英語性能を犠牲にしていないということです。
なお、8Bモデルにはreasoning_effortパラメータ（low / medium / high）が用意されており、上表のスコアはmedium設定時のものです。low設定では日本語MT-Bench 7.23、英語MT-Bench 7.54となり、思考量と性能のトレードオフを制御できます。参考として、評価に使用したgpt-5.4-2026-03-05自体のスコアは日本語8.87・英語8.89です。
MT-Benchはwriting、roleplay、reasoning、math、coding、extraction、STEM、humanitiesの8カテゴリで構成されますが、カテゴリ別の数値スコアは2026年4月時点で公式に公開されていません（llm-jp-evalのレーダーチャートのみ公開）。NII公式のllm-jp-eval v2.1.3（42タスク）の結果と合わせた詳細分析は、今後の論文公開を待つ必要があります。
なぜ日本語特化が有効なのか ── トークナイザーと訓練データの設計
「GPT-4oより優れている」と聞くと驚くかもしれませんが、技術的には合理的な理由があります。
トークナイザーの効率問題
英語中心で設計されたトークナイザーでは、日本語テキストが極端に非効率になります。この問題を理解するには、トークナイザーの仕組みから見る必要があります。
多くのLLMが採用するBPE（Byte Pair Encoding）は、訓練コーパスに頻出する文字列ペアを繰り返し結合して語彙を構築するアルゴリズムです。英語中心のコーパスで学習した場合、"the"や"ing"のような英語の頻出パターンは早期に1トークンへ統合されますが、日本語の文字列は出現頻度が低いため統合が進みません。結果として、日本語テキストはバイト単位やUTF-8のバイト列に分解されます。
具体例を示します。GPT-3.5/4のトークナイザー（cl100k_base）で「自然言語処理」をトークン化すると、["自然", "言", "語", "処理"] のように4トークンに分割されます。一方、英語の "natural language processing" は ["natural", " language", " processing"] の3トークンです。日本語の文字はUTF-8で1文字あたり3バイトを消費するため、バイトレベルBPEでは最悪の場合、日本語テキストは同じ意味の英語テキストの3〜4倍のトークンを消費します。GPT-3の学習データにおける日本語の割合はわずか0.11%であり、トークナイザーの語彙に日本語が十分に反映されていませんでした。トークン数が膨らむと、コンテキストウィンドウを圧迫し、API利用時のコストも比例して増加します。
この問題に対し、LLM-jpプロジェクトでは独自のトークナイザー llm-jp-tokenizer を開発しています。BPEではなくSentencePiece（Unigramモード）を採用している点が特徴的です。Unigramモデルは、大規模な候補語彙から出発し、各サブワードを除去した場合の全体損失の増加量を評価しながら語彙を刈り込んでいく方式で、日本語のように語境界が曖昧な言語に対して柔軟に語彙を構築できます。
llm-jp-tokenizer v3.0b1では語彙サイズが99,574に拡張され、日本語の圧縮効率は1トークンあたり約2.02文字を実現しました。これは、v2.2の約1.53文字/トークンから大幅に改善された数値です。比較として、PLaMo 2のトークナイザーは前バージョンから日本語トークン効率を45%改善したと報告されており、日本語特化トークナイザーの研究は国内で活発に進んでいます。
なお、LLM-jp-4ではllm-jp-tokenizer v4.0が使われており、Unigramのbyte-fallbackモデルとして実装されています。byte-fallbackにより、未知の文字列もバイト単位で確実にエンコードできるため、語彙に含まれない固有名詞や新語にも対応します。
訓練データの構成と品質管理
LLM-jp-4の事前学習コーパス LLM-jp Corpus v4 は、総量約19.5兆トークンのデータプールから約10.5兆トークンを選別して使用しています。
| 言語 | トークン数 | 主なデータソース |
|---|---|---|
| 英語 | 約17.8兆 | ウェブクロール（CommonCrawl等）、学術論文、書籍 |
| 日本語 | 約6,880億 | ウェブクロール、国会議事録、政府公開文書、NINJAL Web Japanese Corpus |
| 中国語・韓国語 | 約8,500億 | ウェブクロール |
| コード | 約2,000億 | GitHub等のオープンソースコード |
日本語データの特徴は、ウェブクロールだけに頼らない点です。国立国語研究所のNINJAL Web Japanese Corpus（whole-NWJC）や国会議事録・政府公開文書といった、品質が担保された公的データソースを組み込んでいます。ウェブクロールデータに対しては、言語識別フィルタリング、統計ベースの品質スコアリング（文の長さ・繰り返し率・記号比率等の指標）、キーワードベースの不適切コンテンツ除去を組み合わせた多段階フィルタリングが適用されています。
事前学習に続く訓練パイプラインは3段階で構成されています。
- 中間学習（Continual Pre-training）: 1.2兆トークンの追加学習。合成データを含み、日本語の知識をさらに強化
- SFT（Supervised Fine-Tuning）: 22種類の英日インストラクションデータを用いた教師ありファインチューニング。SFTデータは公開されている
- DPO（Direct Preference Optimization）: 人間の選好に基づく最適化。DPOデータも公開済み
ポイントは「大量の日本語データで事前学習する」だけでなく、「日本語での指示追従能力を多段階で鍛える」というパイプライン設計です。訓練データとファインチューニングデータの両方がオープンに公開されている点は、再現性の観点からも評価できます。
日本語の構造的な特性への対応
日本語は英語と語順が異なり（SOV構造）、助詞による格関係の表現、敬語の階層構造、漢字・ひらがな・カタカナの混在など、独自の複雑さを持ちます。汎用モデルはこれらを「多言語の一部」として扱いますが、日本語に最適化されたトークナイザーと十分な日本語インストラクションデータの組み合わせにより、こうした構造に適応した内部表現が学習されやすくなります。
LLM-jpプロジェクトの歩み
LLM-jp-4 は突然生まれたわけではありません。約3年にわたる段階的な開発の成果です。
| 時期 | モデル | 規模 | 特徴 |
|---|---|---|---|
| 2023年10月 | LLM-jp-1 | 13B | GPT-2ベース。270Bトークンで訓練。初の公開モデル |
| 2024年4月 | LLM-jp-2 | 175B級 | Llamaアーキテクチャに移行。255Bトークン |
| 2024年12月 | LLM-jp-3 | 172B | 2.1兆トークン。GPT-3級として公開 |
| 2026年4月 | LLM-jp-4 | 8B / 32B-A3B | 12兆トークン。MoE導入。GPT-4o超え |
訓練データ量は v1 の270Bトークンから v4 の12兆トークンへ、約44倍に増加しました。
このプロジェクトは2023年5月にNLP研究者約30名の研究会としてスタートし、2024年6月時点で参加者は1,500名を超えています。2024年4月にはNII内に「大規模言語モデル研究開発センター（LLMC）」が正式に設立され、約30名の専任研究者・開発者が配置されました。学術機関が主導しながら、産学1,900名以上のコミュニティで開発するという体制は、世界的にもユニークです。
出典: LLM-jp: A Cross-organizational Project for the Research and Development of Fully Open Japanese LLMs
デジタル庁「源内」と国産LLM 7モデル選定
LLM-jp-4の発表と前後して、もう一つ重要な動きがありました。2026年3月6日、デジタル庁が政府AI基盤「源内」で試用する国産LLM 7モデルを選定しています。
| 企業 | モデル名 |
|---|---|
| NTTデータ | tsuzumi 2 |
| カスタマークラウド | CC Gov-LLM |
| KDDI・ELYZA | Llama-3.1-ELYZA-JP-70B |
| ソフトバンク | Sarashina2 mini |
| NEC | cotomi v3 |
| 富士通 | Takane 32B |
| Preferred Networks | PLaMo 2.0 Prime |
15件の応募から7件が選定され、2026年8月から全府省庁39機関・約18万人規模で試用が始まります。2027年4月には成果を評価した上で正式調達に移行する計画です。
LLM-jp-4はこの7モデルには含まれていません。NIIは学術研究機関として、オープンソースでのモデル公開を主軸にしており、政府調達の商用枠とは立ち位置が異なります。ただし、LLM-jpプロジェクトの成果（コーパス構築手法、トークナイザー、評価基準など）は、選定された各モデルの開発にも間接的に貢献していると考えられます。LLM-jpコミュニティには選定企業のメンバーも多数参加しているためです。
実務で使えるか ── API・ライセンス・推論コスト
実務利用を考える場合に押さえるべきポイントを整理します。
公開状況とライセンス
- Hugging Face で公開済み: llm-jp/llm-jp-4-8b-thinking
- ライセンス: Apache License 2.0（商用利用可）
- 訓練コーパスも一部公開: 事前学習コーパス、SFTデータ
Apache 2.0ライセンスのため、商用利用・改変・再配布が自由です。これは企業が自社サービスに組み込む上で大きなメリットです。
モデルのダウンロードと推論
2026年4月時点では、NII公式のAPI提供はありません。Hugging Faceからモデルをダウンロードし、ローカルまたはクラウドで推論環境を構築する必要があります。
Hugging Face Transformersを使った基本的な推論コードは以下のとおりです。
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model_name = "llm-jp/llm-jp-4-8b-thinking"
tokenizer = AutoTokenizer.from_pretrained(
model_name,
trust_remote_code=True, # カスタムトークナイザーの読み込みに必須
)
model = AutoModelForCausalLM.from_pretrained(
model_name,
dtype=torch.bfloat16,
device_map="auto",
trust_remote_code=True,
)
messages = [{"role": "user", "content": "自然言語処理とは何か"}]
prompt = tokenizer.apply_chat_template(
messages,
tokenize=False,
add_generation_prompt=True,
reasoning_effort="medium", # "low", "medium", "high" から選択
)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.no_grad():
output_tensor = model.generate(
**inputs,
max_new_tokens=256,
do_sample=True,
temperature=0.7,
top_p=0.9,
)
generated_ids = output_tensor[0][inputs["input_ids"].shape[1]:].tolist()
response = tokenizer.decode(generated_ids)
parsed = tokenizer.parse_response(response)
print("Thinking:", parsed.get("thinking"))
print("Content:", parsed.get("content"))
trust_remote_code=True が必須である点に注意してください。LLM-jp-4はカスタムトークナイザーとレスポンスパーサーを使用しており、このフラグなしでは正しく動作しません。reasoning_effort パラメータで思考の深さを制御でき、"low"では高速な応答、"high"では深い推論が得られます。parse_response メソッドにより、思考過程（thinking）と最終回答（content）を分離して取得できます。
本番環境でのデプロイには、vLLMやText Generation Inference（TGI）などの推論フレームワークが適しています。vLLMを使う場合、OpenAI互換のAPIサーバーを立てられるため、既存のアプリケーションからの移行が容易です。公式の llm-jp-4-cookbook にvLLM向けの設定例（llmjp4_vllm ディレクトリ）が用意されています。
推論コストとハードウェア要件
8Bモデル（パラメータ数85.9億）はBF16形式で約16GBのVRAMを消費します。NVIDIA RTX 4090（24GB VRAM）であれば余裕を持って動作し、量子化（4bit/8bit）を適用すればRTX 4070 Ti（16GB）クラスでも動作可能です。公式cookbookではNVIDIA RTX 6000 Ada（CUDA 12.8環境）での動作が確認されています。
32B-A3Bモデルはパラメータ総数こそ320億ですが、MoE構造でアクティブパラメータが38億のため、推論時の計算コストは8Bモデルと同程度に抑えられます。ただし、128個のエキスパート全てのパラメータはメモリ上に保持する必要があるため、モデルのロードには32Bモデル相当のVRAMが必要です。
Claude / GPT との使い分け
| 観点 | LLM-jp-4 | Claude / GPT |
|---|---|---|
| 日本語の自然さ | 日本語MT-Benchで高スコア | 汎用的に高品質 |
| 多言語・推論 | 日本語・英語に強い | 多言語・複雑な推論に強い |
| データの外部送信 | ローカル実行可（データが外に出ない） | API経由で外部送信 |
| コスト構造 | GPU費用（固定費型） | トークン課金（従量制） |
| カスタマイズ | ファインチューニング自由 | APIの範囲内 |
抽象的な比較だけでは判断しにくいので、具体的なユースケース別に整理します。
LLM-jp-4が適するケース:
- 法律・行政文書の要約・分類: 契約書、社内規程、行政手続き文書など、外部に送信できない機密文書を扱う場合。ローカル環境で完結するため、情報漏洩リスクがゼロになる。日本語の書き言葉（法律用語、敬語表現）に対する理解度も高い
- 社内チャットボット・FAQ: 日本語での問い合わせ対応に特化したボットを構築する場合。Apache 2.0ライセンスのため、自社データでファインチューニングして専用モデルを作れる。トークン従量課金がないため、大量のリクエストを処理しても月額GPU費用のみで済む
- 日本語コンテンツの定型生成: メール文面、報告書テンプレート、議事録の整形など、日本語の文書品質が重要で、処理量が多い業務
Claude / GPTが適するケース:
- 多段推論・複雑な分析: 複数の条件を組み合わせた判断、数学的推論、長文の論理構成など。MT-Benchの総合スコアでは、評価に使用したgpt-5.4が8.87を記録しており、推論性能の上限には差がある
- コード生成・デバッグ: 多言語のプログラミング言語に対応し、大規模なコードベースの理解が求められる場面。Claude / GPTのコンテキストウィンドウの大きさも利点になる
- 多言語を跨ぐ業務: 英日翻訳だけでなく、中国語・韓国語・ヨーロッパ言語を含む多言語対応が必要な場合
- プロトタイピング・実験: APIを即座に呼び出せるため、PoC段階ではClaude / GPTの方が立ち上がりが早い
現実的には、機密性の高い日本語処理はLLM-jp-4をローカルで、複雑な推論や多言語対応はClaude / GPTをAPIで、というハイブリッド構成が多くの企業にとって最適解になるでしょう。
国産LLMの課題と展望
LLM-jp-4の成果は大きいですが、国産LLMが産業として成立するためには、いくつかのボトルネックが残っています。
1. 訓練コスト
大規模LLMの訓練にはGPU数千基×数週間〜数ヶ月の計算資源が必要です。LLM-jp-4はABCI 3.0（H200 × 6,128基）という国家レベルの計算基盤があったからこそ実現しました。民間企業が同等の訓練を行うにはクラウドGPUのコストが障壁になります。
2. 人材
LLM-jpコミュニティは1,900名を超える規模に成長しましたが、事前学習から評価までの全工程を担える人材は世界的に不足しています。NIIのLLMCに約30名の専任研究者がいるとはいえ、OpenAI（約2,000名）やGoogle DeepMind（約3,000名）と比べると規模の差は歴然です。
3. 日本語データ
高品質な日本語テキストデータの確保は継続的な課題です。LLM-jp-4では国立国語研究所のNINJAL Web Japanese Corpus（whole-NWJC）を活用するなど、学術機関連携でデータ基盤を強化していますが、英語圏と比べてウェブ上の日本語テキストの絶対量は限られます。
Microsoftの100億ドル投資が変えるもの
2026年4月3日（LLM-jp-4の発表と同日）、Microsoftが日本に100億ドル（約1兆6,000億円）を投資する計画を発表しました。2029年までに、さくらインターネット・ソフトバンクとの連携によるAI計算基盤の拡充、国家サイバー統括室との脅威インテリジェンス共有、NTTデータ・NEC・日立・富士通との連携による100万人のエンジニア育成を進めます。
この投資は上述の3つのボトルネックすべてに効きます。国内データセンターの拡充は訓練コスト問題を緩和し、100万人の人材育成はAI人材不足に対応し、国内事業者によるGPUインフラの選択肢が増えることで、国産LLMの訓練環境も改善されます。
まとめ
LLM-jp-4は、日本語MT-BenchでGPT-4oを上回るスコア（8B: 7.54、32B-A3B: 7.82 vs GPT-4o: 7.29）を記録し、日本語特化モデルの有効性を示しました。Apache 2.0ライセンスでの公開により、商用利用を含む幅広い活用が可能です。
デジタル庁の「源内」プラットフォーム、Microsoftの1兆6,000億円投資と合わせて見ると、2026年は国産LLMのエコシステムが本格的に動き出す年になりそうです。NIIはより大規模なパラメータのモデルを2026年度中に順次公開する予定とのことで、今後の展開にも注目です。