LLM-jp-4 33Bとは？国立情報学研究所の国産オープンLLM・Apache 2.0・gpt-oss-20b超えの日本語性能を解説【2026年8月速報】

LLM-jp-4 33Bは、国立情報学研究所（NII）の大規模言語モデル研究開発センター（LLMC）が2026年8月18日に公開した、約332億パラメータのDense型オープンLLMです。 Apache License 2.0で商用利用でき、日本語MT-Benchで8.00を記録してgpt-oss-20b（7.33）とGPT-4o（7.29）を上回りました。

ただし「GPT-4o超え」が成立するのはMT-Benchの2指標のみで、安全性評価（AnswerCarefully）と指示追従評価（llm-jp-instructions）では依然GPT-4oに届いていません。公式モデルカードのベンチマーク全数値をそのまま掲載したうえで、その数字が何を意味するのか、実際に動かすには何が必要なのかを2026年8月時点の一次情報から整理します。

この記事でわかること

• LLM-jp-4 33Bの基本スペック（332億パラメータ／64Kコンテキスト／11.7兆トークン学習）
• 公開されたbaseとthinkingの役割の違い
• 公式ベンチマーク全12行の数値と、「gpt-oss-20b超え」「GPT-4o超え」の正確な線引き
• 評価者がgpt-5.4-2026-03-05に変わったことの意味（過去世代と数字を直接比べられない理由）
• 33B Dense と 32B-A3B MoE のどちらを選ぶべきか
• 必要VRAMの目安と運用コストの考え方
• 導入前に踏みやすい実装上の落とし穴（trust_remote_code／Harmonyパーサー／GGUF変換）
• こんな組織におすすめ／おすすめしない判断基準

想定読者

• 日本語データを外部APIに出せない企業・自治体・医療／金融の情報システム担当
• オンプレ／自社クラウドでLLM推論基盤を構築しているエンジニア
• 国産オープンLLMの選定を進めているAI推進担当・PM
• LLM-jpシリーズの世代差・モデル差を正確に把握したい研究者

LLM-jp-4 33Bの基本情報

出典: Hugging Face llm-jp/llm-jp-4-33b-thinking

LLM-jp-4 33Bは、LLM-jp-4シリーズで初めて公開された大型Denseモデルです。2026年4月に公開された8B Dense・32B-A3B MoEに続く第3のラインで、推論時に全パラメータを使う構成で日本語性能を引き上げています。

モデルスペック

出典: Hugging Face: llm-jp/llm-jp-4-33b-thinking モデルカード

パラメータ数が「32B」ではなく「33B」表記なのは、埋め込み層を含めた総パラメータが約332億になるためです。埋め込みを除いた非埋め込みパラメータは約322億で、この数字が32B-A3B（総321億）と近い値になっています。

何が新しいのか

前世代・兄弟モデルと比べたときの差分は3点に集約されます。

1. Dense型への回帰 — 32B-A3BはMoE（Mixture of Experts）で推論時に約38億パラメータしか使いませんでしたが、33Bは全332億を使います。速度と引き換えに精度を取った設計です。
2. 層の深さ — 8B・32B-A3Bがともに32層だったのに対し、33Bは64層。Hidden sizeも5,120に拡大しています。
3. 学習量は多段階パイプラインで11.7兆トークン — モデルカードの記載は事前学習＋中間学習で合計11.7兆トークン。4月公開の8B / 32B-A3Bもリリース時点で約12兆トークン規模と案内されており、トークン総量そのものが大きく増えたわけではありません。スコア向上はDense化と層の深さによる寄与が大きいとみられます。

LLM-jpシリーズ全体の設計思想や8B／32B-A3Bのスペックは、LLM-jp-4とは｜国立情報学研究所の国産LLM解説で整理しています。

開発の背景

LLM-jpは、NIIを中心に2,600名以上（2026年3月31日時点）の研究者・技術者が参加する産官学連携プロジェクトです。計算資源には産業技術総合研究所のAI橋渡しクラウド「ABCI 3.0」が使われ、文部科学省の補助金「生成AIモデルの透明性・信頼性確保に向けた研究開発拠点形成」が資金基盤になっています（33Bの学習にABCI 3.0が使われたかどうかは、8月18日の発表では明示されていません）。

学習コーパスの構築は河原大輔教授、モデル構築は鈴木潤教授、チューニング・評価は宮尾祐介教授が主要ワーキンググループを率いる体制です。「オープンソースAIの定義（OSAID）に配慮した公開」を方針として掲げており、モデル重みだけでなくコーパス・学習レシピも可能な範囲で公開されています。

なお、海外モデルをリブランドした「国産LLM」との違いという論点については、楽天 Rakuten AI 3.0のDeepSeekリブランド問題で扱った経緯が参考になります。LLM-jp-4は事前学習からコーパス設計まで国内で行われたフルスクラッチ系列である点が、この文脈での大きな差です。

公開された2つのモデル（base / thinking）の違い

出典: Hugging Face llm-jp 組織ページ

33Bで公開されたのはbaseとthinkingの2種類のみです。8Bに存在するinstruct（思考なしで素早く応答するバリアント）は、現時点で33Bには用意されていません。

thinkingには強化学習（RL）が適用されていない点が公式に明記されています。SFTとDPOのみで事後学習されており、DPO用データセットllm-jp/llm-jp-4-33b-thinking-dpo-dataも同時に公開されました。学習手順の再現性を重視する研究用途では、この透明性が実用的な価値になります。

instructがないことの実務的な意味

33Bを使う場合、思考プロセスを挟まない軽量応答は選択肢にありません。thinkingはHarmony形式に従い、思考内容をanalysisチャネルに、最終回答を別チャネルに出力します。

• 応答レイテンシはinstruct型より確実に長くなる
• 出力を扱うアプリケーション側で、チャネル分離の処理が必須になる
• 「短い定型応答を大量に高速に返す」用途には構造的に不向き

短文応答を高スループットで回したい場合は、8Bのinstructか32B-A3Bのinstructを選ぶほうが合理的です。

公式ベンチマーク全数値と、その正確な読み方

出典: LLM-jp 公式ニュース（国立情報学研究所）

ここが本モデルの評価で最も誤解されやすい部分です。公式モデルカードに掲載されている全数値をそのまま掲載します。

公式ベンチマーク結果（全12行）

評価には公式の評価フレームワークllm-jp-judgeが使われ、評価者モデルはgpt-5.4-2026-03-05、3回推論の平均値です。

出典: Hugging Face: llm-jp/llm-jp-4-33b-thinking

各指標の意味は以下のとおりです。

• MT-Bench (JA/EN) — 多ターン対話の応答品質。10点満点
• AnswerCarefully — 日本語の安全性評価（AnswerCarefully v2.0テストセット336問）。5点満点
• llm-jp-instructions — 日本語の指示追従性能。5点満点

「gpt-oss-20b超え」は4指標すべてで事実

33B thinking（medium）と gpt-oss-20b（medium）を並べると、差は明確です。

4指標すべてで上回っており、この点については留保なく「超えた」と言えます。ただしモデルサイズ帯は同じではありません。gpt-oss-20bは総21B・アクティブ3.6BのMoEで、MXFP4量子化により16GBメモリで動作します。一方の33Bは全332億パラメータを使うDense型です。「同じApache 2.0＋Harmony形式の土俵」という共通点はありますが、消費リソースが大きく異なる比較である点は押さえておく必要があります。

「GPT-4o超え」が成立するのは2指標だけ

ここが多くのニュース記事で省略されている論点です。

つまり、対話品質ではGPT-4oを上回るが、安全性と指示追従ではまだ届いていないというのが正確な現状です。AnswerCarefullyは有害・機微な問いへの応答適切性を測る指標であり、ここでGPT-4oに劣るという事実は、エンドユーザー向けプロダクトに組み込む際の判断に直結します。

そして最も重要な留保として、フロンティアモデルとの差は依然として大きいという点があります。公式評価表のgpt-5.4-2026-03-05は日本語MT-Benchで8.87〜8.98、llm-jp-instructionsで4.79〜4.83を記録しており、33B（8.00 / 3.79）とは明確な開きがあります。最新の商用モデルの水準についてはGPT-5.4とはも参照してください。

評価者が変わったため、旧世代の数字と直接比較できない

公式モデルカードには、「llm-jp-3系列はgpt-4o-2024-08-06を評価者として評価しており、新しい評価者はより厳格なため、MT-Bench等のスコアは低めに出る」という趣旨の注記があります。

これは実務上、次の意味を持ちます。

• 過去に発表されたllm-jp-3系のスコアと、今回の33Bのスコアを同じ表に並べて比較してはいけない
• 「llm-jp-3.1の数字のほうが高かった＝性能が落ちた」という読み方は誤り
• 33Bの数字を評価するときは、同一の評価条件で測られたモデル（gpt-4o / gpt-5.4 / gpt-oss-20b / 8B / 32B-A3B）とだけ比べる

ベンチマークスコアを社内稟議や比較資料に使う場合、評価者モデルと評価日時をセットで記載しておくのが安全です。

reasoning_effortはlowとmediumのみ公表

thinkingモデルはreasoning_effortで推論量を切り替えられますが、公式評価表に掲載されているのはlowとmediumの2水準のみです。highのスコアは公表されていません。low→mediumで日本語MT-Benchが7.67→8.00（+0.33）と伸びており、精度が必要な場面ではmedium以上を選ぶ判断になります。

33B Dense と 32B-A3B MoE、どちらを選ぶべきか

同じ「約32〜33B」でも、両者は設計思想がまったく異なります。精度を最優先するなら33B Dense、同じVRAMで速度とコストを取るなら32B-A3B MoEという明確なトレードオフです。

スペックとスコアの比較

「+0.18点」にアクティブ8.7倍を払うか

33Bと32B-A3Bのスコア差を整理すると次のようになります（いずれもmedium）。

一方で、推論時のアクティブパラメータは約38億から約332億へ、およそ8.7倍になります。VRAM使用量・スループット・レイテンシ・GPU課金はいずれも大幅に悪化します。

判断の目安は次のとおりです。

MoEとDenseの一般的な違いについては、Meta Llama 4 Scoutとは（17B active / 109B MoE）でも構造面を解説しています。

料金・必要GPUと運用コスト

モデル自体は完全無料です。 Apache License 2.0で配布されており、商用利用・改変・再配布にライセンス料は発生しません。ただし公式のホスティングAPIや有料プランは提供されていないため、実質的なコストはGPU調達費・クラウドGPU時間・運用工数になります。

料金体系

必要VRAMの目安

公式は推論に必要なVRAMの実測値を公表していません。以下は公式配布GGUFの実ファイルサイズから算出した目安であり、公式値ではない点に注意してください。

このモデルファイル容量に加えて、64Kコンテキストを使う場合はKVキャッシュ分のメモリが別途必要です。長文RAGを想定するなら、ファイルサイズ＋十数GBの余裕を見ておくのが安全です。

参考までに、公式Cookbookのテスト環境は Intel Core i9-14900K / RAM 32GB / NVIDIA RTX 6000 Ada / CUDA 12.8 と記載されています。個人・小規模チームでの検証は、量子化版＋24〜48GB級GPUが現実的な出発点になります。

自前運用とAPI利用のコスト構造の違い

「APIコストはゼロだがGPU時間は発生する」という構造を最初に理解しておくことが導入判断の起点です。小規模利用なら商用APIのほうが安く済むケースは珍しくありません。国内でオンプレ／ソブリン環境を検討する場合は、SoftBank「Cloud PF Type A」（国産ソブリンクラウド）やデジタル庁の国産AI基盤の事例も選択肢の整理に役立ちます。

使い方と対応実行環境

出典: GitHub llm-jp/llm-jp-4-cookbook

公式が案内している実行方法は以下のとおりです。いずれも自前でGPU環境を用意する前提で、ブラウザからすぐ試せるチャットUIは提供されていません。

公式のサンプルコードはllm-jp/llm-jp-4-cookbook（GitHub）にまとまっています。まず手元で挙動を確認したい場合は、量子化版をOllamaで動かすのが最短ルートです。Ollamaの基本的な使い方はOllamaとは｜ローカルLLM実行ツールの使い方で解説しています。

本番用途では、OpenAI互換エンドポイントを立てられるvLLMまたはSGLangが標準的な選択になります。

導入前に押さえておきたい実装上の落とし穴

LLM-jp-4シリーズは「動かす前に知らないと確実にハマる」ポイントがいくつかあります。ニュース記事にはまず出てこない部分なので、検証を始める前に確認しておいてください。

① trust_remote_code=Trueが必須

Transformersでロードする際、trust_remote_code=Trueを指定しないと正しく読み込めません。モデルが複数のカスタムプラグインを同梱しているためです。社内のセキュリティポリシーでリモートコード実行を制限している場合は、事前に例外申請が必要になることがあります。

② vLLMではHarmony対応のreasoningパーサー指定が必要

thinkingモデルの思考トークンは、Harmony形式のanalysisチャネルに出力されます。vLLMでカスタムreasoningパーサーを指定しないと、思考プロセスが最終出力に混入します。 JSONなどの構造化出力を求めるタスクでは、これだけで出力が破綻します。

この挙動は32B-A3Bで実務検証を行ったQiitaの技術記事でも報告されています（同記事は32B-A3Bを対象としたものですが、Harmony形式という設計は33Bにも共通するため、同じ注意が必要です）。

③ GGUFは自前変換せず公式版を使う

llm-jp-4のトークナイザは標準BPEではなくUnigram byte-fallbackです。一方で変換ツール側はモデル構造から既存アーキテクチャ（32B-A3BではQwen3-MoE系）と自動判定するため、この乖離により異常出力やクラッシュが起きるケースが32B-A3Bの検証で報告されています。33Bはアーキテクチャの公式表記がなく同一とは断定できませんが、トークナイザ方式は共通のため同じリスクを想定しておくのが安全です。

• 自前でGGUF変換しない
• 公式配布のGGUFリポジトリを使う
• llama.cppはLLM-jp fork版を使う（本家にはトークナイザ修正が未反映）

④ openai-harmonyライブラリでのトークナイズは非対応

チャットテンプレートはHarmony互換ですが、トークナイザが異なるため、openai-harmonyライブラリで直接トークナイズすることはできません。必ずモデル同梱のトークナイザを使ってください。gpt-ossからの移行を検討している場合、この点は事前に確認が必要です。

⑤ 33Bにはinstructがない

33Bで公開されているのはbaseとthinking（＋GGUF）のみです。「思考なしで即応答」を前提としたアプリケーション設計をしている場合、33Bをそのまま差し込むことはできません。

制約・セキュリティ上の注意点

公式が明示している限界

Hugging Faceのモデルカードには、Risks and Limitationsとして次の趣旨が記載されています。

ここで公開されたモデルは我々の研究開発の初期段階にあり、出力が人間の意図や安全性への配慮に沿うようチューニングされていない。

つまりそのままエンドユーザーに出力を提示する設計は推奨されていません。入力モデレーション・出力フィルタリング・人手レビューを前提に組み込む必要があります。AnswerCarefullyのスコアが3.79とGPT-4o（4.00）を下回っている事実も、この判断を裏づけます。

そのほかの制約

セキュリティ上のメリットとリスク

メリットは明快です。モデル重みをローカルまたは自社クラウドで動かせるため、外部APIへ一切データを送らない推論構成（データ主権・オンプレ推論）が取れます。個人情報・診療情報・金融取引データなど、外部送信が制限される領域では決定的な利点になります。

リスクは、その裏返しです。自前運用ゆえのセキュリティ責任が全面的に利用者側に乗ります。

• 推論サーバーの認証・認可設計
• プロンプトインジェクション対策
• 推論ログの保管・アクセス管理
• モデルファイルの改ざん検知

システムプロンプトに認証情報を書かない、外部入力をそのままプロンプトに連結しない、といった基本の対策は必須です。生成AI全般のセキュリティ設計は生成AIのセキュリティリスクと対策にまとめています。

Apache 2.0で商用利用する際の実務ポイント

Apache License 2.0は非常に緩いライセンスですが、無条件ではありません。一般的には次の点が実務上の確認事項になります（法的な判断は自社の法務部門にご確認ください）。

1. ライセンス表示義務 — モデルや派生物を配布する場合、Apache 2.0ライセンスのコピーとNOTICEを含める
2. 変更明示義務 — 改変・ファインチューニングして配布する場合、変更した旨を明示する
3. 無保証条項 — 出力に起因する損害についてモデル提供者は保証しない
4. 学習データの扱い — モデル重みはApache 2.0だが、コーパスを独自利用する場合は個別にライセンスを確認する

自社内で利用するだけであれば追加の制約は少なく、外部にモデルを配布・OEM提供する場合にこれらの義務が効いてきます。

他の国産LLM・オープンモデルの中での位置づけ

LLM-jp-4 33Bは、「産官学連携・フルオープン・Apache 2.0」という3条件を同時に満たす国産大型LLMとして、他の国産モデルとは異なるポジションにあります。

各モデルの詳細と選定基準は国産LLM 7選 徹底比較で横断的に整理しています。個別に検討する場合は、PLaMo 3.0 Primeとは、Sarashina3とは、Qwen3.8-27Bとはもあわせて参照してください。

LLM-jp-4 33Bを選ぶ理由になりやすいのは、次の3点です。

1. 透明性 — 学習コーパス（llm-jp-corpus-v4.1、llm-jp-corpus-midtraining-v2）とSFT／DPOデータが可能な範囲で公開されており、監査要件のある組織でも説明しやすい
2. ライセンスの自由度 — Apache 2.0で追加契約不要。ファインチューニングした派生モデルの扱いも明快
3. 継続性 — 国の研究基盤に支えられたプロジェクトで、民間企業の事業判断で突然終了するリスクが相対的に低い

なお、Apache 2.0の大型オープンモデルという潮流自体は世界的に広がっており、Arcee AI Trinity Large（400B・Apache 2.0）のような事例も出ています。国内のAI基盤側の動きは富士通PHOTONなどが参考になります。

今後のロードマップ

出典: 国立情報学研究所 公式サイト

2026年4月時点の公式発表では、2026年度中に以下のモデルを順次公開する計画が示されていました。

332B-A31B（総3,320億・アクティブ約310億のMoE）は、公開されれば国産オープンLLMとして過去最大級の規模になります。ただし公開時期は「2026年度中」とのみ示されており、正確な日付は未確定です。

LLM-jpシリーズの公開履歴

最新情報はLLM-jp公式ニュースで確認してください。

こんな組織・用途におすすめ／おすすめしない

導入の可否は「日本語品質へのこだわり」と「GPU基盤を持てるか」の掛け算でほぼ決まります。

おすすめの組織・用途

おすすめしない組織・用途

判断に迷う場合は、まず量子化版（Q4_K_M・20.2GB）をローカルで動かし、自社タスクでの日本語品質を確認してから本番構成を決めるのが現実的です。その結果「精度は足りているが速度が足りない」となれば32B-A3B、「精度が足りない」となれば商用APIとの併用を検討する、という順序になります。

関連記事

国産LLMやオープンモデルの選定を進める際は、以下もあわせて確認してください。

• LLM-jp-4とは｜国立情報学研究所・約12兆トークン学習の国産LLM — シリーズ全体（8B / 32B-A3B / VL）の解説
• 国産LLM 7選 徹底比較 — 国産LLMの横断比較と選び方
• Ollamaとは｜ローカルLLM実行ツールの使い方 — GGUFモデルをローカルで動かす手順
• PLaMo 3.0 Primeとは — PFNのフルスクラッチ国産LLM
• Sarashina3とは — SB Intuitionsの国産LLM
• Qwen3.8-27Bとは — 同サイズ帯のApache 2.0オープンモデル
• 生成AIのセキュリティリスクと対策 — オンプレLLM運用時のセキュリティ設計

よくある質問（FAQ）

Q1. LLM-jp-4 33Bは商用サービスに組み込めますか？

Apache License 2.0のため、ライセンス上は商用利用・改変・再配布が可能です。ただし公式が「出力が人間の意図や安全性配慮に沿うようチューニングされていない」と明記しているため、そのままエンドユーザーに出力を返す設計は避け、出力フィルタリングや人手レビューを前提に組み込んでください。配布を伴う場合はライセンス表示・変更明示の義務も確認が必要です。

Q2. 「GPT-4oを超えた」と報じられていますが、GPT-4oの完全上位互換ですか？

いいえ。公式表で確認できる範囲では、上回っているのはMT-Bench（日本語8.00 vs 7.29／英語8.24 vs 7.69）の2指標のみです。安全性評価のAnswerCarefully（3.79 vs 4.00）と指示追従のllm-jp-instructions（3.79 vs 4.07）ではGPT-4oを下回っています。「日本語の多ターン対話品質でGPT-4oに競合できるオープン代替」という理解が正確です。

Q3. なぜLLM-jp-3のときより数字が低く見えるのですか？

評価者モデルが変わったためです。llm-jp-3系はgpt-4o-2024-08-06を評価者として評価されていましたが、今回はgpt-5.4-2026-03-05が使われています。公式は新しい評価者のほうが厳格でスコアが低めに出ると注記しており、世代をまたいだスコアの直接比較はできません。

Q4. 32B-A3Bを使っています。33Bに乗り換えるべきですか？

用途次第です。バッチ処理中心で日本語・英語の生成品質を上げたいなら乗り換える価値があります（日本語+0.18、英語+0.38）。一方、多数の同時アクセスを捌くチャットサービスの場合、推論時アクティブパラメータが約38億から約332億に増える影響が大きく、GPU台数を増やさない限りスループットが落ちます。まず自社タスクで両方を評価してから判断してください。

Q5. 24GBのGPU（RTX 4090など）1枚で動かせますか？

公式配布のQ4_K_M量子化版はファイルサイズ20.2GBのため、ギリギリ載る計算にはなりますが、KVキャッシュの分を考えると64Kコンテキストをフルに使うのは厳しいと見ておくべきです。短めのコンテキストでの検証用途なら現実的です。余裕を持って動かすなら48GB級以上を推奨します（これらはファイルサイズからの目安であり、公式の実測値ではありません）。

Q6. Ollamaやllama.cppで動かすときの注意点は？

GGUFを自前変換しないことが最大の注意点です。llm-jp-4のトークナイザはUnigram byte-fallback方式で、変換ツールがモデル構造から自動判定する既存アーキテクチャの想定と食い違い、異常出力やクラッシュが起きる可能性があります（32B-A3Bでの検証報告に基づく注意点です）。公式配布のGGUFリポジトリを使い、llama.cppはLLM-jp fork版を使ってください。

Q7. 思考プロセス（reasoning）が回答に混ざってしまいます。どうすればいいですか？

Harmony形式では思考内容がanalysisチャネルに出力されるため、vLLMなどのサーバー側でHarmony対応のreasoningパーサーを指定する必要があります。指定しないと思考トークンが最終出力に混入し、特にJSONなどの構造化出力が破綻します。

Q8. 332B-A31Bの大型MoEモデルはいつ出ますか？

2026年8月20日時点では未公開です。2026年4月の公式発表で「2026年度中に順次公開予定」とされているのみで、正確な時期は示されていません。LLM-jp公式ニュースで最新情報を確認してください。

Q9. baseとthinkingのどちらをダウンロードすればいいですか？

そのまま推論に使うならthinking、自社データでファインチューニングする土台にするならbaseです。baseは事前学習＋中間学習までしか行われておらず、指示に従った応答はできません。まず動かして品質を確認したい段階であれば、thinkingのGGUF量子化版が最も手軽です。