国産LLM「LLM-jp-4 33B」は自社で動かせるか

「国産のオープンLLMが出た」というニュースを見るたびに、自社で使えるものなのか判断できないまま流してしまう——AIの導入を検討している方から、いちばん多く聞く声です。

結論から言うと、2026年8月18日に公開された「LLM-jp-4 33B」は、クラウドAIの置き換えではありません。外に出せないデータの一次処理を、社内の機械の中に閉じ込めるための選択肢です。使えるかどうかは、メモリ・速度・精度という3つの数字でほぼ決まります。

株式会社Fyveは、クラウドAIとローカルLLMを併用した業務自動化を自社でも常時稼働させています。この記事では、カタログスペックの紹介ではなく「手元のマシンに載せたとき、実際に何が起きるか」を基準に、導入判断の軸を整理します。

LLM-jp-4 33Bとは何か——2026年8月18日に公開された事実

国立情報学研究所（NII）が主宰するLLM-jpは、2026年8月18日、約332億パラメータの大規模言語モデル「LLM-jp-4 33B」を公開しました。公開されたのは2種類です。

• llm-jp-4-33b-base：事前学習と中間学習を終えたベースモデル
• llm-jp-4-33b-thinking：教師ありファインチューニング（SFT）と選好最適化（DPO）による事後学習まで済ませたモデル

ライセンスはApache License 2.0。商用利用が可能なライセンスで公開されており、重みはHugging Face上で配布されています。ITmediaは翌8月19日、同モデルが日本語・英語のMT-Bench、AnswerCarefully、llm-jp-instructionsの4種類すべてで従来のLLM-jp-4 Thinkingモデルおよびgpt-oss-20bを上回ったと報じました。

スペックを表で押さえる

公式のモデルカードに記載されている数値を、そのまま並べます。ここが後の判断材料になります。

ベンチマークのスコアは次のとおりです（評価器は gpt-5.4-2026-03-05）。

比較のために、2026年4月3日に公開された同シリーズの数値も並べておきます。日本語MT-Benchで、32B-A3Bが7.82、8Bが7.54、参考値として挙げられていたGPT-4oが7.29でした。今回の33Bが記録した8.00は、この系列の中では最も高いスコアです。

4月に出た「32B-A3B」との違いはDenseかMoEか

ここは実務上の意味が大きいので、少し丁寧に書きます。4月に公開された32B-A3BはMoE（Mixture of Experts）と呼ばれる構造で、総パラメータは約320億あるものの、1回の推論で実際に動くのはそのうち約30億分だけでした。対して今回の33BはDense型で、推論のたびにモデル全体のパラメータを使います。

この違いは、カタログ上は「どちらも約32〜33B」に見えるのに、動かしたときの挙動がまったく変わる原因になります。ざっくり言えば、MoEはメモリは食うが計算は軽い、Denseはメモリも計算も相応にかかる代わりに、パラメータを使い切るという関係です。手元のマシンで動かすときは、この差が待ち時間として直接返ってきます。

「オープン」と「国産」は、実務では別々の意味を持つ

この2語はニュースでは並べて語られますが、導入判断では別々に評価したほうが間違えません。

Apache 2.0が実際に許していること

Apache License 2.0は、商用利用・改変・再配布を原則として認めるライセンスです。使うために追加の商用契約を結ぶ必要はありません。派生物を配布する場合にはライセンス表示と変更点の告知が求められますが、社内で動かして社内で使うという一般的な使い方であれば、ここで詰まることはまずありません。

逆に言えば、Apache 2.0が保証してくれるのは「使ってよい」という一点です。出力の正しさも、安全性も、保証の対象ではありません。この点は後述するモデルカードの但し書きとあわせて理解しておく必要があります。

「学習に使われない」はライセンスではなく置き場所の話

私がよく受ける質問に「オープンなモデルなら、入力したデータが学習に使われないということですか」というものがあります。厳密には違います。入力が学習に使われるかどうかを決めているのは、モデルのライセンスではなく、そのモデルを誰のサーバーで動かしているかです。

クラウドの主要サービスも、法人向けプランでは業務データを学習に使わない方針を明示しているものが多く、そこは契約と設定の問題として整理できます。各社の方針の違いは、こちらの記事で比較しています。

AI業務効率化AIに業務情報を入れて大丈夫？主要4社の学習ポリシー

オープンモデルを自社の機械で動かす本当の価値は、「方針を信じる」という手続きを省略できることにあります。データが社内のネットワークから外に出ないことを、契約書ではなくネットワーク構成で示せる。法務や監査に説明する立場からすると、この差は小さくありません。

「国産」の実利は日本語スコアだけではない

日本語ベンチマークで高いスコアを出しているのはもちろん利点です。ただ、実務でより効いてくるのは、日本語の業務文書に特有の崩れ方をしにくいという点だと感じています。稟議書、議事録、手書きをOCRにかけた後のテキスト、社内用語の混じった箇条書き——こうした「きれいではない日本語」を扱わせたときに、破綻が少ないかどうかが分かれ目になります。

ここは数値では測りにくい領域なので、自社の実文書を10本ほど食わせて確かめるのがいちばん早い判断方法です。ベンチマークのスコアは候補に残すかどうかの足切りに使い、採否は自社文書で決める、という順番をおすすめしています。

動かす前に、必要なメモリを数字で押さえる

ここからが本題です。33.2BのDenseモデルは、手元の機械に載るのでしょうか。

計算は単純です。BF16は1パラメータあたり2バイトなので、重みだけで 33.2B × 2バイト ≒ 約66GB。これに加えて、推論中の途中経過を保持するKVキャッシュの分が必要になります。量子化してビット数を落とすと、比例して小さくなります。

数字だけ見ると「4bitなら20GB弱だから24GBのマシンで載る」と考えたくなりますが、ここに落とし穴があります。65,536トークンという長いコンテキストは、使えば使うほどKVキャッシュとしてメモリを追加で食うという点です。短いチャットでは動いていたのに、長い議事録を丸ごと投げた瞬間に落ちる、という失敗はここから起きます。

加えて、量子化には副作用があります。ビット数を落とすほど、日本語の品質は落ちる方向に働くとされています（量子化の影響は用途によって幅があるため、自社の文書で確かめるのが確実です）。4bitまで落とした33Bと、8bitの12Bクラスのどちらが自社の用途で良いかは、実際に比べないと分かりません。「大きいモデルを無理に載せる」より「収まるサイズで安定して回す」ほうが、業務では強いことが多いです。

手元の実測から、33Bの体感速度を見積もる

私たちは、Mac mini M4を常時稼働のAI処理機として運用しています。そこでの実測値は、24GBの構成でGemma 4 12B（MLX量子化）が毎秒40〜55トークンでした。日常のローカル処理はこのラインで回しています。構成の詳細はこちらにまとめています。

Ollama ローカル運用完全ガイド｜Gemma 4 × LM Studio で API コストゼロ

では33.2BのDenseモデルはどうなるか。ここから先は実測ではなく見積もりですが、判断には十分使えます。Denseモデルは推論のたびに全パラメータを読み出すため、生成速度はおおむねパラメータ数とメモリ帯域で決まります。33.2Bは12Bの約2.8倍なので、同じ機械・同じ帯域なら毎秒15〜20トークン前後に落ちる計算になります。

毎秒15トークンというのは、日本語でおおよそ1秒に10文字前後が流れてくる速さです。画面を見ながら読み進めるぶんには許容できますが、「一問一答をテンポよく」という使い方には向きません。逆に、夜間にまとめて要約させる・分類させるといったバッチ処理なら、この速度で困ることはほとんどないはずです。

「動く」と「業務で使える」の差

ローカルLLMの検証でいちばん見落とされるのが、この差です。単体で1リクエストを流せば動く、というのは出発点にすぎません。実際の運用では次が同時に起きます。

• 同時実行：2人が同時に投げた瞬間、メモリも速度も分け合うことになる
• 常駐：モデルをメモリに載せっぱなしにするなら、その分は他の用途に使えない
• 同居：同じ機械でバックアップやビルドが走ると、体感速度は簡単に半分になる
• 再起動：停電やOS更新のあと、誰が立ち上げ直すのか

ハードウェアの費用感と、常駐運用で実際にかかるコストについては、実測ベースでこちらに整理しています。

Mac miniでAIを常駐運用｜実測コストと構成

機材を買う前に、試せる順番がある

ローカルLLMの検討でいちばんもったいないのは、先に機材を買ってしまうことです。33B級が自社の仕事に足りるかどうかは、手持ちの環境でもかなりの部分まで確認できます。私が勧めている順番は次のとおりです。

ステップ1：借りたGPUで「精度だけ」を確かめる

最初に判断すべきは速度ではなく精度です。時間貸しのGPU環境を1〜2時間借りて、BF16のまま自社の実文書を通してみます。ここで「この品質なら仕事になる」と言えなければ、機材を買う理由はありません。量子化すると品質は落ちる方向に働くので、この段階で満足できない出力しか出ないなら、そこが上限だと考えて構いません。

推論はTransformers・vLLM・SGLang・Dockerに対応しているとモデルカードに明記されています。まとまった件数を流して比べるなら、スループットの出るvLLMが扱いやすいはずです。

ステップ2：量子化して、落ちる幅を測る

精度に納得できたら、次は4bitまたは8bitに量子化した状態で同じ文書をもう一度通します。ここで見るのは「使えるか」ではなく「BF16と比べてどれだけ落ちたか」です。落ち幅が許容範囲なら、そのビット数が自社の運用ラインになります。

このとき、必ず長い文書も混ぜてください。65,536トークンというコンテキスト長は魅力的ですが、実際に長文を投げるとKVキャッシュがメモリを追加で消費します。短文だけで検証を終えると、本番で最初に扱う議事録で詰まります。

ステップ3：必要メモリが確定してから機材を選ぶ

ステップ2まで終えれば、必要なメモリ量は推測ではなく実測値として手元にあります。そこで初めて機材の話をします。この順番なら「買ったのに載らなかった」「載ったが遅すぎた」という失敗はほぼ起きません。

DenseとMoE、どちらを選ぶか

今回の33B（Dense）と、4月に公開された32B-A3B（MoE）は、用途で選び分けられます。判断の軸は単純です。

• メモリに余裕があり、速度を優先したい→ MoEの32B-A3B。総パラメータは大きいものの、1回の推論で動くのは一部なので生成は軽い
• メモリが厳しく、量子化して詰め込みたい→ Denseの33B。全パラメータを使うぶん計算は重いが、必要なメモリは量子化で素直に下がる

「新しいほうが良い」と考えて自動的に33Bを選ぶ必要はありません。4月のモデルが劣化したわけではないので、自社の機材の制約に合うほうを選べば十分です。

コストは「単価×量」と「機材÷月数」で比べる

ローカルLLMの費用対効果は、感覚で語られがちな領域です。比べる式を先に決めてしまえば、判断は数分で終わります。

クラウドAIを使い続けた場合の費用は、処理するトークン量 × 各社の単価です。まずは直近1か月の実績から、その仕事で何トークン処理しているかを出します。使っているサービスの管理画面に利用量が出ているはずなので、推測は不要です。

社内で動かす場合の費用は、次の3つの合計になります。

• 機材費 ÷ 使用予定月数：36か月で割るのが現実的な目安です。自社の見積もり金額をそのまま入れてください
• 電気代：常時稼働させる場合、消費電力（W）× 24時間 × 30日 ÷ 1000 × 電力単価（円/kWh）で出ます。仮に平均30Wなら月21.6kWh、1kWhあたり27円として月およそ580円という規模感です
• 人の時間：これがいちばん大きく、いちばん見落とされます。初期構築と、月あたりの保守にかかる時間を時給換算して足します

この式で並べると、処理量が少ないうちはクラウドのほうが安いという当たり前の結論になることがほとんどです。ローカルが逆転するのは、処理量が大きい場合か、そもそも金額では比べられない「外に出せない」という制約がある場合に限られます。逆に言えば、制約が無いのにコスト削減だけを理由にローカル化するのは、たいてい失敗します。人の時間という最大のコストが、計算から漏れているからです。

導入判断は、4つの質問でほぼ決まる

ここまでの数字を踏まえて、私が相談を受けたときに順番に確認していることを共有します。

Q1. そのデータは、本当に外に出せないものか

いちばん最初に確認するのはここです。外に出せるデータなら、素直にクラウドAIを使ったほうが速く、安く、賢いからです。ローカルで動かす価値は「出せないデータがある」ことにしか宿りません。

実際に切り分けてみると、「なんとなく不安」で止まっていただけで、社内規程上は問題なかったというケースが少なくありません。逆に、人事評価・健康情報・図面・未公開の取引条件など、明確に外部送信が難しいものが残ることもあります。この仕分けを先にやらないと、判断そのものが始まりません。

Q2. どれくらいまで待てるか

前述のとおり、33B級をローカルで動かすと、クラウドの主要モデルより体感は遅くなります。「対話しながら考える」用途なのか、「投げておいて後で受け取る」用途なのかで、必要な速度はまったく変わります。後者であれば、速度は判断材料からほぼ外れます。

Q3. 求めているのは「だいたい合っている」か「間違いを見抜ける」か

分類・抽出・要約の下書きのように、後工程で人が必ず目を通す仕事であれば、ローカルモデルの精度で十分足ります。一方、出力がそのまま社外に出るもの、あるいは読んだ人が誤りに気づけないもの（数値の集計、規程の解釈、契約文言）は、モデルの大小にかかわらずAI単独で完結させるべきではありません。

Q4. 誰が面倒を見るのか

これが最後の関門で、実際にはここで止まる会社がいちばん多いと感じています。モデルの更新、ディスク容量、動かなくなったときの復旧——担当者が決まっていないローカル運用は、半年後にほぼ確実に放置されます。逆に、すでに社内にサーバーやNASを面倒見ている人がいるなら、追加負担は思うほど大きくありません。

モデルカードが自ら書いている「やってはいけない使い方」

ここは見落とされがちなので、原文を引いておきます。llm-jp-4-33b-thinkingのモデルカードには、開発者自身によるこの注意書きがあります。

The models released here are in the early stages of our research and development and have not been tuned to ensure outputs align with human intent and safety considerations.（ここで公開されているモデルは研究開発の初期段階にあり、出力が人間の意図や安全性の考慮に沿うようにはチューニングされていません）

これは謙遜ではなく、仕様の説明として読むべき一文です。実務に落とすと、次のような線引きになります。

• 置いてよい場所：社内文書の要約・分類・抽出、下書き生成、検索用のタグ付け、マスキング処理の一次判定——いずれも人の目が後段に必ず入る仕事
• 置いてはいけない場所：顧客対応の一次接点（そのまま相手に届く出力）、法務・労務・医療に関わる判断、社外公開物の最終稿

この線引きは、モデルの性能が上がっても当面は変えないほうが安全です。安全性のチューニングを明示的に行っていないモデルを、相手が誤りに気づけない場所に置くべきではない、という原則の問題だからです。

現実解は、いまも3層のハイブリッド

私たちが標準として提案している構成は、LLM-jp-4 33Bが出た後も変わりません。仕事を3つの層に分けて振り分けるやり方です。

• ローカル小型（8〜12B級）：定型応答・分類・抽出・整形。常時起動していても負担が小さい
• ローカル中型（今回の33B級）：社内文書の要約、ナレッジの深掘り、外に出せないデータの下書き生成
• クラウド（主要モデル）：提案書のドラフト、複雑な要件定義、最終アウトプットの整形

LLM-jp-4 33Bが増やしたのは、この真ん中の層の選択肢です。これまで「小型では精度が足りないが、クラウドには出せない」という穴に落ちていた仕事を、社内に留めたまま処理できる可能性が出てきました。逆に言えば、上と下の層を置き換えるものではありません。ここを取り違えて「全部これで置き換えよう」とすると、遅くて精度も足りない構成が出来上がります。

まとめ：判断チェックリスト

最後に、今日から確認できる形にまとめます。

• 外に出せないデータが具体的に何かを先に書き出す。無いならクラウドで足りる
• 載せるなら4bit量子化で17〜20GB＋コンテキスト分のメモリを見込む。24GB機は長文で詰まる可能性がある
• 速度は毎秒15〜20トークン前後を想定する（12B実測からの見積もり）。対話向きではなくバッチ向き
• 採否はベンチマークではなく自社の実文書10本で決める
• 安全性チューニング未実施を前提に、人の目が後段に入る仕事にだけ置く
• 運用担当者を決める。決まらないなら導入しない

国産のオープンモデルが商用利用可能なライセンスで出てくること自体は、選択肢が増えるという意味で率直に良いニュースです。ただし、選択肢が増えることと、自社に必要であることは別の話です。「出たから使う」ではなく「出せないデータがあるから使う」——この順番さえ守れば、判断を間違えることはほとんどありません。

自社のどのデータを外に出さず、どの仕事をAIに任せるか。その線引きの設計から運用の定着までを、私たちは月額の伴走という形で支援しています。「何から手をつければいいか分からない」段階でのご相談も歓迎です。

AI導入・活用の伴走支援について見る