PLaMo・LLM-jp・Sakana Fuguで国産LLMの作り方が三つに割れた

6月22日、PLaMo 3.0 Prime（PFN）とSakana Fugu（Sakana AI）が同じ日に出た。
ニュースの見出しとしては「国産AIの新作が2つ」で並ぶ。ただ中身を開けると、作っているものがまるで別だった。
PFNはモデルの重みをゼロから学習している。Sakanaはフロンティアモデルを自分では学習せず、外部のGPTやClaudeを実行時に呼び出して束ねる、小さな司令塔だけを作った。

ここに国立情報学研究所（NII）のLLM-jpを足すと、三つ目が出てくる。
PFNと同じくゼロから学習するが、出来上がった重みもコーパスも学習レシピも全部公開してしまう。
同じ「国産LLM」でも、片方はモデルを売り、片方は配り、もう一方はそもそもモデルを作らない。やっていることがここまで違う。

前に日本語LLMを整理したときは、モデルを学習方式で並べたカタログにした。
今回はモデルの一覧ではなく、三社の作り方そのものと、中で使われている技術の話。

ゼロから学習して売る（PLaMo / PFN）

PLaMo 3.0 Primeは、PFNが重みをゼロから学習した自社モデル。APIとオンプレミスで売る。
重みは公開しない。手元に落として動かすものではなく、国内ベンダーと契約して使う。

6月22日の正式版は、3月のβからの変更が大きい。

項目	正式版での中身
コンテキスト長	65,536→262,144トークン（256k）。YaRN（RoPEの位置エンコーディングを外挿するスケーリング）と継続事前学習を組み合わせて伸ばした。コンテキスト窓を広げただけでなく、長文で学習し直している
二つの応答モード	推論重視のReasoningと速度重視のNon-reasoning。Reasoningは強化学習をβ版比で約2倍のステップ回したモデルで、`reasoning_effort` を `medium` にすると考えてから答え、`none` だと推論を省いて即答する
安全性	NICTから提供された安全性データを学習に使用。HELM Safetyで海外モデルと同等以上としつつ、非推論側に過剰拒否や危険応答が残る領域も明記している
提供	OpenAI互換のPLaMo API＋オンプレミス。`plamo-2.2-prime` 以前は2026年9月30日、`plamo-3.0-prime-beta` は7月31日に終了

料金は100万トークンで入力60円・出力250円の従量。GPT-4o miniあたりと同じ水準だ。
無料プランはまだ準備中で、いま試すなら新規登録で付く1,000円分（約1,000万トークン相当・1ヶ月）のクレジットになる。
OpenAI互換なので、既存コードはエンドポイントとモデルIDを差し替えるだけで動く。

from openai import OpenAI

client = OpenAI(
    api_key="<PLAMO_API_KEY>",
    base_url="https://api.platform.preferredai.jp/v1",
)

resp = client.chat.completions.create(
    model="plamo-3.0-prime",
    messages=[{"role": "user", "content": "この社内規程を3行で要約して"}],
    reasoning_effort="none",  # 推論させるなら "medium"
)
print(resp.choices[0].message.content)

想定しているのは、企業データを外に出せず、オンプレで長い社内文書を回したい現場だ。
モデルの精度より、データをどこに置くか、どう契約するかで選ぶことになる。

ここまで書いた中身（スクラッチ学習・YaRN・強化学習）は、全部PFNの発表が出どころだ。
重みもデータも非公開だから、外から同じものを再現して確かめることはできない。次のLLM-jpはそこが真逆になる。

ゼロから学習して全部公開する（LLM-jp / NII）

LLM-jpは、NIIの大規模言語モデル研究開発センター（LLMC）が主宰するプロジェクト。PFNと同じくゼロから学習する。ただ、できた重みの扱いが逆になる。
約12兆トークンで学習した重みを、Apache 2.0でそのまま出す。学習データにGPTやClaudeの合成出力を混ぜていないので、何で学習したかもライセンスもはっきり追える。

「完全オープン」は重みに限らない。
コーパスの構成も、学習レシピも、評価結果まで出ている。第三者が同じものを再現できるし、続きを学習させることもできる。
4月3日に出たのはLLM-jp-4の8Bと32B-A3B。32B-A3BはMoEで、全32Bのうち1トークンで実際に動くのは3.8Bだけだ。32B級の知識を3B級の計算量で引ける。手元のGPU1枚でも現実的に回るのはこのおかげになる。

日本語が薄まらないように、学習中は日本語を4.5倍オーバーサンプリングして、コーパス比を3.5%から15.9%まで持ち上げている。
MT-Bench JAでは7.82。項目によってはGPT-4oの7.29を上回った。
この先、32B Denseと、3,320億パラメータ・アクティブ310億の LLM-jp-4 332B-A31B が2026年度内に順次出る予定だ。

完全オープンの一番の実利は、依存が無いことに尽きる。
ローカルでも自前サーバーでも動くし、追加学習も、安全フィルタを緩めるのも自分で決められる。実際に手元のGPUで回したログは別記事にした（→LLM-jp-4をROCmで動かした）。
APIで済ませたいなら、さくらインターネットの「さくらのAIエンジン」にLLM-jp-3.1が載っていて、月3,000リクエストまで無料枠がある。

モデルを作らず束ねる（Sakana AI）

Sakanaは昔から、巨大モデルをゼロから作る競争には乗っていない。
ずっとやってきたのは、既存のモデルをどう組み合わせるか、どう作り変えるかの方だ。進化的モデルマージ（EvoLLM-JP）では、既存モデルの重みを勾配学習なしの進化的探索で混ぜ、新しいモデルをこしらえた。Transformer²は、推論のたびにタスクを見て、重みをSVD（特異値分解）で分解した「スキル」成分だけを動的に調整する。3月のNamazuは、DeepSeek-V3.1やLlama 3.1 405B、gpt-ossといったオープンモデルに事後学習をかけ、日本仕様に寄せたものだった。

やり方は毎回違うが、どれも既存モデルの重みをいじる話ではある。

Fuguは基盤モデルを作らない

6月22日に正式提供が始まったFuguは、その延長線上で、もう一歩振り切っている。
フロンティアモデルはここでも作らない。用意したのは、外部モデルを実行時に呼び分ける小さな「司令塔」だ。これを強化学習で仕上げた。フロンティアをまるごと学習するのとは、かける労力が桁で違う。

ややこしいのは名前で、Fuguはサービス名であり、司令塔そのもののモデル名でもある。
公式も “Sakana Fugu is itself a language model”（Fugu自体が言語モデル）と言っていて、このFuguというLLMが、プールの中の他モデルを呼び出す。
Sakanaが学習させたのは、答えを生成するモデルではない。誰に何をやらせるかを決める係だ。

固定のif/elseで振り分けているわけではなく、編成のしかた自体を学習している。
リクエストが来ると、自分で答えるか、専門家チームを組むかをまず決める。チームを組むなら、Thinker（方針立案）・Worker（実作業）・Verifier（検証）に役割を振り、出てきた答えを一つにまとめる。Workerとして自分自身を再帰的に呼ぶこともある。

flowchart TD
  Q[リクエスト] --> F{司令塔Fugu}
  F -->|単純| D[自分で直接回答]
  F -->|複雑| T[Thinker 方針立案]
  T --> W[Worker 各専門モデルが分担]
  W --> V[Verifier 検証]
  V -->|不十分| T
  V -->|完了| S[合成して1つの回答]
  D --> A[応答]
  S --> A[応答]

この仕組みは、ICLR 2026の論文2本が下敷きになっている。
TRINITY（arXiv:2512.04695）は、Thinker/Worker/Verifierの役割を進化的探索で最適化する軽量コーディネータ。
Conductor（arXiv:2512.04388）は、7Bの司令塔を強化学習で訓練し、再帰を含む編成のしかたを身につけさせる手法。
製品版Fuguの正確なサイズは出ていないが、根っこにあるのはこの7B級の司令塔だ。

束ねる相手は、GPT-5.5、Claude Opus 4.8（max）、Gemini 3.1 Pro（high）あたりの公開フロンティアモデル。
逆にFable 5やMythosは「公開アクセスがない」のでプールに入れていない。
製品はFugu（速度と質のバランス）とFugu Ultra（質重視・より深い専門家プール）の2つ。SWE-Bench ProやLiveCodeBenchのようなコーディング系で、Fable 5やMythos Previewと肩を並べると言っている。

構図はMoEをモデル単位に引き上げたもの

並べてみると、MoE（Mixture of Experts）に似ている。
MoEは1つのモデルの中で、ゲートという小さなルーターがトークンごとに専門家（FFN＝フィードフォワード層）を選び、出力を足し合わせる。さっきのLLM-jp-4 32B-A3Bも、32Bのうち3.8Bだけ動かすこのMoEだ。
Fuguは、その「ゲートが専門家を選ぶ」をモデルの中から外へ出した格好になる。専門家がFFNではなく丸ごとのGPT-5.5やClaude Opusで、ゲートが学習済みのFugu。研究の言い方だとMixture-of-Agents（MoA）が近い。

ただし、同じMoEとは言い切れない差もある。

観点	MoE（モデル内部）	Fugu（モデル横断）
粒度	トークン単位・各層ごと	クエリやサブタスク単位
合成	活性ベクトルの重み付き和	テキスト出力をVerifierが組み直す
学習	ゲートと専門家を一緒に学習	司令塔だけ学習・専門家は固定

ゲートだけ学習して、専門家は固定。モデル単位のMoEと言ってもいい。
司令塔の出来がそのまま全体の質になるし、呼び出す側のモデルには手を入れられない。

似ているのは形だけで、狙いはむしろ逆だ。
MoEは、専門家を全部動かさず必要な3.8Bだけ通すことで、同じ質を軽い計算で出すのが目的になる。うまく当たれば速い。
Fuguは反対に、丸ごとのモデルを複数動かして、検証まで挟む。そのぶん遅いし高い。速さではなく、1モデル単独より上の答えを引き出すことを狙っている。

OpenRouterと並べると位置がわかる

Fuguはよくモデルルーティングと一緒にされる。OpenRouterと並べると、どこが同じでどこが違うか見える。
OpenRouterには毛色の違うルーターが2つある。
Auto Routerは、1プロンプトごとに最適な「1モデル」をNotDiamondで選び、そのモデルに丸ごと渡す。フォールバックはあるが、これは可用性（5xxやレート制限）対策の切り替えで、複数モデルを合成するわけではない。
もう一つのFusion Routerは、複数モデルが並列で同じプロンプトに答え、judge（審判役）が全部読んで最終回答を書く。出力をトークン単位で混ぜる（merge）のではなく、審判が書き直す形だ。

「複数モデルに投げて一つにまとめる」発想自体は、このFusion Routerにもある。
Fuguの違いは、その編成をやる部分まで学習済みのモデルにしているところだ。
Fusionの「並列で出して審判がまとめる」が固定の手順なのに対して、Fuguはタスクを分解して役割を振り、検証して、必要なら再帰する流れごと、司令塔が入力に合わせて決める。
ざっくり言えば、Auto Routerは1モデルに渡すだけ、Fusionは並列回答を審判がまとめる、Fuguは学習した司令塔がチームを組んで解く、という並びになる。

結局、何が取り柄なのか

正直、読みながら「OpenRouterでよくないか」と何度か思った。
複数AIを1本のAPIで使い分けるだけなら、OpenRouterのAuto RouterやFusion Routerで足りる。そっちの方が安いし、中身も見える。
Fuguがそこを超えられるとすれば、理由は一つだ。学習した司令塔がタスクを割って検証して組み直すことで、プールにある単独のどのモデルよりいい答えを出す。これが本当なら、の話だが。
Sakanaは、プールに入っていないはずのFable 5やMythosとコーディング系で並ぶ、と主張している。手持ちの駒より上のクラスに編成で届く、というのが売りだ。
裏を返すと、その底上げが要らない用途なら、単独の最強モデルかOpenRouterで十分になる。難しい多段タスクで、高い料金と再現性の低さを飲めるとき、はじめて元が取れるタイプだと思う。

自前で組めるか、コストはどうか

枠組みだけなら、オープンモデルで自作できる。
LLM-jpを国内完結のWorkerに置いて、GemmaやQwenを並べ、ルーティングと審判を書く。これでFusion Router相当までは手元に作れる。
詰まるのはその先だ。Fuguの価値は配線そのものより、司令塔を学習させる部分（TRINITY/Conductor）にある。ルールで手書きした編成と、学習で身につけた編成の差が出るのは、ここから先になる。

値段の桁も見ておきたい。
中身が海外のフロンティアモデルなので、従量で入力$5・出力$30（100万トークン）。PLaMoの60円・250円とは桁が違う。サブスクは月$20・$100・$200の3段だ。
おまけに、どのモデルがどこを担当してどう混ざったかは入力ごとに変わり、しかも非公開。固定モデルのAPIみたいに同じ答えを当てにはできない。データの扱いも、最後は呼び出し先の海外モデル次第になる。

依存先が閉じたときが本当のリスク

ここが一番のリスクだと思う。Fuguの性能は、ほとんど他社のクローズドモデルから借りている。
司令塔のFugu自体は編成に振り切った小型モデルだ。簡単な質問は自分で返せても、フロンティア級の難問をひとりで解く力はない。質の大半はGPT-5.5やClaude Opus 4.8の側が出している。
だからベンダーがアクセスを絞った瞬間、フォールバックは動いても質は落ちる。司令塔は残った相手に振り直すだけで、抜けた分を自分で埋められない。

これは仮の話ではない。
現にFable 5やMythosは「公開アクセスがない」という理由でプールに入っていない。最上位モデルを競合の編成に貸さない判断は、もう現実に出ている。
アクセス制限でも規約変更でも、何か一つ起きるたびにFuguの実力は他社の都合で変わる。それでいて、入口で払う額はPLaMoより桁違いに高い。

三つを並べる

	PLaMo 3.0 Prime	LLM-jp-4	Sakana Fugu
開発元	PFN	NII / LLM-jp	Sakana AI
何を作ったか	重みをゼロから学習	重みをゼロから学習	外部モデルを束ねる司令塔
重みの公開	非公開	Apache 2.0で全公開	司令塔は自社・中身は海外モデル
入手	API・オンプレミス	重みDL＋API（さくら）	OpenAI互換API・サブスク
国内完結	API/オンプレで可	ローカルで完全に可	不可（海外モデルを呼ぶ）
料金の目安	入力60円/出力250円（100万tok）	重みは無料・APIは従量	入力$5/出力$30（100万tok）
向く相手	オンプレで長文業務	改造・研究・国内完結	自前モデルなしで最高性能

選ぶ基準はスコアだけじゃない。
データを外に出せないならPLaMoのオンプレかLLM-jpのローカル。重みを手元に置いて自分で直したいならLLM-jp。自前で基盤を持たずに最先端の性能だけ借りたいならFugu。だいたいこの3択になる。

それでも本命はLLM-jpだ。借り物の上に作るのではなく、コーパスから全部自分で積んでいる。そこに国産の希望を感じている。
依存の重さで並べると、一番危ういのはFuguだと思う。高い金を先に払うのに、性能の出どころは他社のモデルで、そこが閉じたら何が残るか読めない。PLaMoはまだ自社モデル1本なので、畳むか値上げか、というシンプルなリスクで済む。
LLM-jpは、もう重みがApache 2.0で手元にある。この先の版がクローズドに寄っても、出てしまったものは消えない。自分で直せるし、さっきの自前オーケストレーションでも、国内完結のWorkerとして真ん中に置ける。
というわけで、2026年度の332B-A31Bがどこまで伸びるか、今年はそこを一番楽しみにしている。