GUIDE LLM-jp-4 技術解説 & 導入ガイド 2026.04.03

国産LLM LLM-jp-4
ローカル環境で動かす

国立情報学研究所(NII)が2026年4月3日に公開した LLM-jp-4 シリーズの技術的な深掘り解説。
Mac mini M4 / Ollama 環境への導入手順と、PPQAT・RAG用途での活用戦略をまとめる。

LLM-jp-4 Llama 2 base MoE OSAID準拠 12T tokens Apache 2.0

2つのモデルの技術的差異

LLM-jp-4 8B

アーキテクチャLlama 2 (Dense)
総パラメータ86億 (8B)
Active params86億 (全結合)
VRAM (FP16)~16 GB
VRAM (Q4_K_M)~5 GB
コンテキスト~65K tokens
Mac mini M4適性◎ 余裕
MoEの実用的意味
32B-A3Bは推論時のコンピュート量が8Bとほぼ同等(38億パラメータのみ稼働)でありながら、128個のエキスパートから毎回8個を動的選択することで、はるかに大きな知識容量を持つ。 「メモリコストは32B級、推論速度は8B級、品質は32B級」という特性。ただし全パラメータをメモリに載せる必要があるためVRAMは32B相当を消費する。

3段階学習パイプライン

STAGE 1
事前学習
19.5Tトークンのコーパスから
~10.5Tを使用
ABCI 3.0で計算
STAGE 2
中間学習
1.2Tトークン
合成データ +
Instruction Pre-training
STAGE 3
SFT + DPO
22種のJA/ENデータ
Reasoning splits
(low / med / high)
中間学習が鍵
「事前学習 → いきなりSFT」ではなく、合成データを含む1.2Tトークンで日本語の指示理解力を底上げするステージを挟んでいる。 SFTデータにはreasoning難易度を3段階に分割した構成があり、段階的なチューニングを実現している。 またSFTとDPOによるアライメントのみで、強化学習(RLHF/GRPO等)は使っていない点も特徴的。

コーパス構成と設計思想

English
91%
~17.8T tokens
日本語
3.6%
~0.7T tokens
中/韓
4.4%
~0.85T tokens
Code
1%
~0.2T tokens

日本語の割合が全体の約3.6%にもかかわらず日本語性能でGPT-4oを上回れた設計思想がここにある。英語の大量学習で汎用的な推論能力を獲得した上で、中間学習で日本語の指示理解力を底上げし、さらにSFTで精密なチューニングを行う多段構成。

コーパスの内訳には、インターネット上の公開データ、政府・国会の文書、合成データが含まれる。OSAID(オープンソースAIの定義)に配慮し、すべて第三者が入手可能なデータで構成されている点が大きな特徴。コーパス構築スクリプトもGitLabで公開されている。

IP業務との関連性
政府・国会文書で学習しているため、法令・行政用語の理解精度が高い可能性がある。 特許明細書やJPO審査基準の解析・要約タスクにおいて、汎用多言語モデルに対する優位性が期待できるポイント。

ベンチマーク結果の読み方

日本語MT-Bench(GPT-5.4ジャッジ)

32B-A3B
7.82
8B
7.54
gpt-oss-20b
7.33
GPT-4o
7.29
Qwen3-8B
7.14

英語MT-Bench(GPT-5.4ジャッジ)

32B-A3B
7.86
gpt-oss-20b
7.85
8B
7.79
GPT-4o
7.69
Qwen3-8B
7.69
スコア解釈の注意点
今回の評価はGPT-5.4をジャッジに使用。以前のllm-jp-3シリーズではgpt-4o-2024-08-06を使用しており、新しいジャッジはより厳密な評価を行うため、過去のスコアとの直接比較はできない。 GPT-4oの日本語スコアが7.29と低めに見えるのは、この厳しいジャッジの影響も含まれる。

導入手順 A:Transformers(公式サポート)

Hugging Face Transformers 経由が最もシンプルな導入方法。公式cookbookも提供されている。

bash
# 依存関係
pip install torch transformers accelerate flash-attn
python
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,
    device_map="auto",
    torch_dtype=torch.bfloat16
)

chat = [
    {"role": "user",
     "content": "半導体製造プロセスの特許出願における進歩性の判断基準を説明してください"}
]

inputs = tokenizer.apply_chat_template(
    chat, add_generation_prompt=True,
    tokenize=True, return_tensors="pt"
).to(model.device)

with torch.no_grad():
    output = model.generate(
        inputs,
        max_new_tokens=512,
        do_sample=True,
        top_p=0.95,
        temperature=0.7
    )

print(tokenizer.decode(output[0], skip_special_tokens=True))
利用可能なモデル一覧
llm-jp/llm-jp-4-8b-thinking — 8B instruct済み(推奨)
llm-jp/llm-jp-4-32b-a3b-thinking — 32B-A3B instruct済み
llm-jp/llm-jp-4-8b-base — 8B 事前学習済み(ベースモデル)
llm-jp/llm-jp-4-32b-a3b-base — 32B-A3B ベースモデル

導入手順 B:Ollama(GGUF変換)

Ollama公式レジストリには未登録のため、GGUF変換→カスタムモデル登録の手順が必要。

Step 1:llama.cpp のビルド
bash
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j
Step 2:モデルダウンロード
bash
pip install huggingface_hub
huggingface-cli download llm-jp/llm-jp-4-8b-thinking \
    --local-dir ./llm-jp-4-8b

32B-A3Bの場合は llm-jp/llm-jp-4-32b-a3b-thinking に変更

Step 3:GGUF変換(Q4_K_M推奨)
bash
python3 convert_hf_to_gguf.py ./llm-jp-4-8b \
    --outfile llm-jp-4-8b-q4_k_m.gguf \
    --outtype q4_k_m

品質重視なら q8_0(~9GB)、軽量化なら q4_k_m(~5GB)を選択

Step 4:Ollama Modelfile 作成
Modelfile
FROM ./llm-jp-4-8b-q4_k_m.gguf

PARAMETER temperature 0.7
PARAMETER num_ctx 8192
PARAMETER top_p 0.95

SYSTEM "あなたは知財戦略を支援するAIアシスタントです。
特許分析、FTO調査、IP戦略の策定を正確かつ丁寧に行います。"
Step 5:登録 & 実行
bash
ollama create llm-jp-4-8b -f Modelfile
ollama run llm-jp-4-8b

# 動作確認
ollama run llm-jp-4-8b "特許法104条の3について要約してください"
トークナイザーの注意
このモデルのトークナイザーは llm-jp-tokenizer v4.0 ベースの Unigram byte-fallback モデル。 openai-harmony ライブラリとは互換性がないため、GGUF変換時に chat template の設定を慎重に行う必要がある。 公式提供のトークナイザーを使う Transformers 経由が最も安全。

導入手順 C:OpenAI互換APIとして公開

Mac mini M4 で Ollama サーバーとして起動し、Tailscale VPN 経由で他マシンからアクセスする構成。

bash
# ⚠ 0.0.0.0 バインド禁止(セキュリティルール)
# Tailscale内部IPまたはlocalhostのみ
OLLAMA_HOST=127.0.0.1:11434 ollama serve
bash
# 他マシンからTailscale IP経由でアクセス
curl http://<tailscale-ip>:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llm-jp-4-8b",
    "messages": [
      {"role": "user", "content": "半導体製造装置のFTOリスクを分析してください"}
    ]
  }'
セキュリティルール(vc_mcp_server.py 教訓)
すべてのサーバーは 127.0.0.1 または Tailscale IP のみでバインド。 ハードコードされたトークン禁止。環境変数での管理を徹底すること。

qwen3 との使い分け戦略

LLM-jp-4 8B を使う

日本語の特許文書解析
JPO審査基準の参照・要約
技術記事の下書き
公的機関の報告書の要約
政府・法務文書の理解

qwen3:14b を使う

英語特許・論文の読解
多言語コード生成
汎用的な推論タスク
数学・ロジック系の処理
パラメータ数の優位性が活きる場面

タスク 推奨モデル 理由
PPQAT Devil's Advocate llm-jp-4 日本語の法律・制度文書の理解精度
FTO先行技術調査の要約 llm-jp-4 特許明細書の日本語表現に強い
File Wrapper分析 qwen3 USPTO英語文書がメイン
PIDB RAG検索 両方 言語に応じてルーティング
コード生成・MCP構築 qwen3 コード学習データ比率の優位性
note.com記事の下書き llm-jp-4 自然な日本語生成

今後のロードマップ

NIIは2026年度中に以下のモデルを順次公開予定:

LLM-jp-4 32B

タイプDense(全結合)
パラメータ320億
想定VRAM~20GB (Q4)
ステータス開発中

LLM-jp-4 332B-A31B

タイプMoE
総パラメータ3,320億
Active~310億 (31B)
ステータス開発中
332B-A31Bのインパクト
アクティブパラメータ31Bクラス(推論負荷はqwen3:32b級)で知識容量332Bという非常に強力なモデルになる。 Mac mini M4では動かないレベルだが、DGX Spark GB10であれば検討可能。 クラウド推論やマルチGPU環境の準備を進めておく価値がある。

OSAID準拠の戦略的意味

OSAID(オープンソースAIの定義)に配慮し、すべて第三者が入手可能なデータで学習している。 コーパス構築スクリプトもGitLabで公開。 特許業務や企業内RAGで「学習データの出所が不透明」という懸念を排除できるのは大きな利点。

SEP戦略を進める企業にとって、AIインフラ自体の透明性・説明可能性を確保できることは、 クライアントや規制当局に対するリスクヘッジにもなる。

参照リンク