国産LLM比較2026｜主要モデルの違いと選び方をわかりやすく解説

最終更新日：2026年10月4日

---

機密文書を外へ出せない。既存GPUは1枚しかない。なぜNTTは世界最大を追わず、約300億パラメータをGPU1枚に収めたのか。本稿は国産LLMを、DeepSeekとMistralという海外の鏡に映し、各社が何を得て何を捨てたかで読み解く。

国産LLM比較で「何Bか」だけを見てはいけない

コンテキスト長、総パラメータ数、活性パラメータ数は、性能ランキングではなく「そのモデルが何をするために作られたのか」を読む材料である。

LLMのニュースでは「300億パラメータ」「1兆パラメータ」といった数字が目立ちます。しかし数字だけでは、約30Bのtsuzumi 2と、1T級モデルを土台に持つNamazuを正しく比べられません。

両者は能力の大小より先に、解こうとしている経営課題が違うからです。 以下では、数字を順位表ではなく、設計判断を読み解く手掛かりとして使います。

コンテキスト長は「作業机の広さ」

コンテキスト長は、AIが一度の処理で保持・参照できる情報量の上限です。256Kは約26万トークン、1Mは約100万トークンを一つの作業状態として扱えることを意味します。

長い契約書、コードベース、RAGで取得した複数資料、ブラウザ操作履歴、AIエージェントが呼び出したツールの結果などを一緒に置ける「作業机の広さ」と考えると分かりやすいでしょう。ただし机は広ければ広いほどよいわけではありません。長い文脈を保持するほど、KVキャッシュやメモリ、推論処理の負荷も増えます。

総パラメータ数は「会社に在籍する専門家の総数」

総パラメータ数は、モデルが持つ知識や表現能力の容量を理解するための一つの目安です。会社にたとえるなら、在籍している専門家の総数に近いものです。

しかし、社員数1万人の会社が社員数1,000人の会社より、すべての案件で優れているわけではありません。パラメータ数も同じです。学習データ、アーキテクチャ、事後学習、推論方法、配置環境が変われば実務価値も変わります。

活性パラメータは「その案件で実際に働く人数」

MoE（Mixture of Experts）では、総パラメータを毎回すべて動かすわけではありません。入力に応じて必要なExpertを選び、実際に計算する範囲を絞ります。

本記事では参考指標として、活性率＝活性パラメータ÷総パラメータ×100も使います。ただし、活性率1％のモデルが活性率100％のDenseモデルより優れているという意味ではありません。Denseには構造の単純さや運用の予測しやすさがあります。

見るべきなのは、なぜその会社は、その活性率・その構造を選んだのかです。

主要LLMを「設計判断」で比較する

同じLLMでも、想定する配置場所、仕事、コスト、データ管理条件が違えば、合理的なモデルサイズもコンテキスト長も変わる。

以下は性能ランキングではありません。各社が何を問題と見て、その解決のためにどの設計を選び、何を優先しなかったのかを一枚にした「設計思想の地図」です。

この表の数字は、モデルを大きい順に並べるためのものではありません。その会社は、どの制約条件を先に置いたのかを読むために使います。

DeepSeek――知能を「モデル内部の計算経済性」で作る

DeepSeek V4.1-Flashの設計テーマは最大モデルを作ることではなく、長大な文脈を抱えたAIエージェントをいかに安く動かし続けるかである。

AIエージェントは、通常のチャットボットとは違います。コードを読み、検索し、ブラウザを操作し、ツールを呼び出し、結果を確認し、失敗すればやり直します。この処理が長時間続くと、回答生成だけでなく、大量の入力を最初に読み込むprefillと、過去の文脈を保持するKVキャッシュが大きなコストになります。

DeepSeek V4.1-Flashは、552Bバックボーンを持つMoEで、最大1Mトークンのコンテキストを扱います。Causal Encoder-Decoder構造により、prefill時は8B、decode時は16Bを活性化し、さらにKVキャッシュを大幅に圧縮しています。DeepSeek自身も、入力が長いエージェント型ワークロードの推論効率を、この設計の中心に置いています。

なお、552Bバックボーンとは別に、196BのEngram条件付きメモリを持ちます。Engramは通常のバックボーンと同じ意味で毎回すべてを計算する領域ではないため、本稿では単純に加算した「総パラメータ」として比較しません。

会社にたとえてみます。巨大な専門家集団を抱えながら、資料を読むprefill段階ではモデルの前半側を中心に動かし、回答を書くdecode段階では後半側も加える。さらに各段階の内部ではMoEによって必要なExpertだけを選びます。能力の在庫は大きく持ちつつ、案件ごとの実働を抑える設計です。

DeepSeekは何を得て、何を捨てたのか

得たものは、1M級の長文脈と、入力の重いAgent処理を大量に回すための推論経済性です。一方で、巨大な重みと条件付きメモリを効率よく配置する推論基盤が必要であり、一般企業がGPU1枚で気軽に置くモデルではありません。

DeepSeekは小型化したAIではありません。巨大な知能を保ったまま、必要な場所だけを動かすAIです。

Arpableの既存DeepSeek記事はV2世代を中心とする2025年版です。MoEやDeepSeekの基本像を確認したい場合は、たとえ話でスッキリ理解！DeepSeekの全貌を解説（2025年7月時点）を参照してください。

tsuzumi 2――知能を「配置可能なサイズ」から逆算する

NTTのtsuzumi 2は、世界最大を狙うのではなく「企業が自分で所有できるAI」を先に定義し、そのハードウェア制約からモデル規模を決めている。

tsuzumi 2のパラメータ数は、AWS講演資料では28B、NTTの公式発表では約300億と表記されています。重要なのは数値のわずかな差ではなく、NTTがGPU1枚で動かせる規模を強く意識している点です。公式には1GPUで動作可能な軽量モデルとして位置付けられ、機微情報を扱うオンプレミス／プライベートクラウド用途を重視しています。

想定業務も明確です。社内文書QA、RAGによる検索・要約、情報抽出、定型フォーマットへの変換など、企業内で頻繁に発生する文書処理です。大型トレーラーの最高速度を競うのではなく、自社の駐車場に入り、自社社員が毎日使える営業車を作る発想に近いでしょう。

高頻度で使うほど、外部APIの従量課金より自前運用が有利になる場合があります。加えて、機微情報を社外へ出しにくい業務では、モデルを自社環境へ置けること自体が価値になります。

tsuzumi 2は何を得て、何を捨てたのか

得たものは、1GPU運用、オンプレミス、データ境界の明確さ、予測しやすい運用費です。その反面、Arpable編集部の読みとしては、数百B級モデルと同じ方向で、広範な世界知識や最大級の汎用推論性能を追う設計ではありません。

なお、tsuzumi 2のコンテキスト長は今回確認した一次情報では公表されていないため、長文処理の上限について本稿では評価しません。30Bだから弱いのではなく、「1GPUで所有する」という経営条件に対して、この規模が選ばれたと読むべきです。

PLaMo――知能を「企業Agentの文脈と制御」で作る

PLaMo 3.0 Primeは、日本語性能だけでなく、企業のAIエージェントが実際に働くときに必要になる長い文脈と、考える／即答する制御を重視している。

PLaMo 3.0 Prime本体のパラメータ数は、公式発表では明示されていません。したがって本記事では、何Bかを推定して比較表を埋めることはしません。

代わりに見るべきは、コンテキスト長を64Kから256Kへ拡張した理由です。PFNは、エージェント環境ではLLMが長大なツール利用履歴を保持できる必要があるとして、コンテキストを256Kへ拡張したと説明しています。さらにReasoningモデルに加え、高速応答向けのNon-reasoningモデルを提供し、業務によって「考える時間」を使い分けられるようにしています。

たとえば契約書、過去の稟議、社内規程、RAGで取得した資料、ツール実行結果を参照しながら回答するAIエージェントでは、会話履歴だけを持てばよいわけではありません。企業業務で必要になる作業状態を、どこまで保持できるかが重要になります。

PFNが公開しているPLaMo 3の基盤モデル（31B）では、通常のAttentionとSWA（Sliding Window Attention）を組み合わせ、長い文脈を扱う際の計算量とKVキャッシュを抑える構成が説明されています。Prime本体の内部構造は公開されていないため、これをPrimeの仕様として断定はできません。

Arpable編集部は、PLaMo 3系全体から「長い業務文脈を扱いつつ、推論コストを制御する」という設計思想が読み取れると考えます。

PLaMoは何を得て、何を捨てたのか

得たものは、日本語業務、長い企業文脈、Reasoning／Non-reasoningの使い分け、APIとオンプレミスという企業向けの配置選択です。

現時点のPrimeは、全ウェイト公開を前提にした外部再配布よりも、API、企業導入、オンプレミス展開を中心に提供されています。したがって本稿では、全面的なオープンウェイト競争とは異なる配置戦略を取っていると整理します。

Sarashina3――知能を「業務システムの部品分業」で作る

Sarashina3の面白さは非公開のパラメータ数ではなく、mini・nano・guard・embedding・rerankという構成から読み取れる、業務処理の分業思想にある。

Sarashina3 mini／nanoのパラメータ数やコンテキスト長は、今回確認した公式情報では公開されていません。一方、SB Intuitionsはminiとnanoに加え、guard、embedding、rerankなど、役割別のモデル群を揃えています。

mini／nanoは、長い思考を必要としないInstructモデルとして、入力へ素早く応答することを特徴にしています。SB Intuitionsは約30Tトークンの事前学習、日本語アノテーション、強化学習などを通じ、日本語の自然さ、丁寧さ、簡潔さ、実用性を高めたと説明しています。

一つの万能モデルへすべてを集約せず、検索、再順位付け、安全判定、応答生成を分業させる。この構成は、大量の定型業務を処理する企業システムと相性が良いと考えられます。

ただし、Reasoningを載せなかったことを単純に「遅れている」と評価するのも、逆に「戦略的にReasoningを捨てた」と断定するのも適切ではありません。SB Intuitions自身も、エージェント能力などで求められる水準に届かない点があると説明しています。

さらに2026年9月には、社内で開発中のthinkingモデルを用いた評価結果も技術ブログで公開しました。したがって、現行mini／nanoの即答型という製品判断と、Sarashina系列全体の将来ロードマップは分けて読む必要があります。

Sarashina3は何を得て、何を捨てたのか

現行mini／nanoで優先しているのは、長い思考より即答性、日本語業務性能、実用性です。mini／nanoで優先していないのは、長い思考を前提に、単一モデルで最大推論性能を狙う用途です。

一方、系列全体がReasoningを不要と判断したわけではありません。「現在の製品」と「次の研究開発」を混同しないことが重要です。

Mistral――知能を「モデルと配置の選択肢」で作る

Mistralは一つの理想サイズへ収束せず、LargeとMediumで異なる配置条件と運用のしやすさを提示している。

Mistral Large 3は、公式モデルカード冒頭では675B総パラメータ、41B活性のMoEとして示され、256Kコンテキストを持ちます。オープンウェイトとして提供され、企業側が自社インフラへ配置・調整できることも重要な特徴です。

一方のMistral Medium 3.5は128B Dense、256Kコンテキストです。Mistralはinstruction-following、reasoning、codingを一つの重みに統合し、最小4GPUからセルフホスト可能と説明しています。reasoning effortもリクエストごとに変更できます。

Large 3は、より大きな能力と自社配置の自由度を同時に狙うモデルです。Medium 3.5は、チャット、推論、コーディングを一つのDenseモデルへまとめ、用途ごとに別モデルを切り替える運用負荷を抑える方向に見えます。

Mistralは何を得て、何を捨てたのか

Large 3は高性能と自社配置の自由度を得る一方、1GPU級の軽さは持ちません。Medium 3.5は、比較的小さなセルフホスト構成と単一モデル運用を取り、Large級の最大規模は追っていません。

675Bと128Bを単純な上下関係として見ると、どの環境へ置き、どの運用負荷を減らすかという配置戦略の違いを見落とします。

※MistralはDense／MoEを採用した理由そのものを詳細には説明していません。上記の設計意図は、公開されたモデル構成・配置条件からのArpable編集部の読みを含みます。またLarge 3とMedium 3.5ではライセンス条件が異なります。

Namazu――知能を「日本適応レイヤー」で作る

Sakana AIのNamazuは、基盤モデルをゼロから所有するより、世界水準の知能を日本語・日本業務へ適応する部分に価値を置く。

現行Namazuは、Moonshot AIのKimi K2.6をベースに、日本語と日本の利用環境へ追加学習したLLM APIです。Sakana AIは、特定話題での不要な応答回避や出力の偏りを抑える調整も加えています。OpenAI互換APIとして、Web検索やコード実行の組み込みツールも提供します。

Kimi K2.6は、Moonshot AIのモデルカードで1T総パラメータ、32B活性のMoEとして公開されています。しかしSakana AIは、Namazu APIの実効コンテキスト長をKimi K2.6の仕様と完全に同一だとは明示していません。そのため本稿の比較表では「提供仕様を要確認」としています。

Sakana AIは、自前の事前学習を行わない理由を詳細には説明していません。公開された製品構成から読むと、世界水準のオープンモデルを基盤に、日本語、日本の業務文脈、商習慣、応答の中立性を追加学習で整える戦略に見えます。

これは「エンジンまで毎回自社開発する」戦略とは異なります。基礎知能の進化を外部エコシステムから取り込み、日本で差がつく適応レイヤーへ研究開発資源を集中できます。

Namazuは何を得て、何を捨てたのか

得たものは、開発速度、世界水準の基礎能力、日本語・日本業務への適応、費用対効果です。一方で、基盤モデルの重み、学習過程、将来のモデル世代までを自ら完全に支配する主権性は持ちません。

だからNamazuは、PLaMoやtsuzumiとは別の意味での「日本のAI」です。重みの国籍より、適応レイヤーに日本側の価値を置くAIと捉える方が実態に近いでしょう。

Namazuの詳細は、Sakana AI「Namazu」の解説記事で扱っています。Sakana AI全体の技術思想は、Sakana AIの技術・事業戦略解説も参照してください。

Fugu――知能を「モデル外部の指揮・編成」で作る

Fuguでは「何Bのモデルか」という問いだけでは価値を説明しきれず、どのAIをいつ使い、どう委任・協調させるかという編成能力が競争力になる。

Sakana AIのFuguは、単一APIの背後に複数の外部モデルを候補プールとして持ち、問い合わせに応じて直接処理したり、別のモデルへ処理を委任したりするオーケストレーションモデルです。

Fugu Ultraは、より難度の高い多段階タスクで複数のモデルを協調させる上位構成です。さらにFugu Maxでは、課題を解ける範囲でより軽量なモデルを選び、性能とコストのバランスを最適化する方向が強く打ち出されています。

この製品思想は、同社のTRINITYやConductorといった研究につながっています。Fuguの技術報告では、ユーザーの問い合わせを理解し、必要に応じて外部モデルへの委任や動的な処理構成を行うオーケストレーターとして説明されています。

DeepSeekがモデル内部で必要なExpertを選ぶとすれば、Fuguはモデル外部で誰に仕事を振るかを選びます。知能の競争軸が、単一モデルの内部から、モデル群をどう使うかというメタレイヤーへ移っています。

Fuguは何を得て、何を捨てたのか

得たものは、複数AIの長所を組み合わせる能力、モデル選択の柔軟性、単一ベンダーへの依存を低減する強靭性です。その代わり、単一モデルだけを使う場合よりも、処理経路・データ境界・監査対象が複雑になります。

企業がFugu型の仕組みを導入するなら、モデル選択のログ、サブタスクごとのデータ送信先、再実行時の経路、費用上限を記録・統制できることが前提になります。

最強の一人を作るのではなく、最適なチームを編成する。ただし、そのチームを誰がどう監督するのかまで含めて設計する必要があります。

7つの設計から見えた本質――知能をどこで作るか

各社の違いはパラメータ数ではなく、知能を「モデル内部・配置・文脈・業務部品・適応・編成」のどこで作るかという設計レイヤーの違いである。

今回取り上げたモデル群は、同じ競技をしていません。DeepSeekはモデル内部の計算経済性、tsuzumiは配置可能なサイズ、PLaMoは企業Agentの文脈と制御、Sarashinaは業務部品の分業、Mistralは配置の選択肢、Namazuは日本適応、Fuguはモデル外部の指揮・編成に重心があります。

だから1M、256K、30Bといった数字は上下関係ではありません。DeepSeekの1Mは長時間Agent、tsuzumiの約30Bは1GPU所有、PLaMoの256Kは長大なAgent履歴というように、数字の背後に置かれた制約が違います。

LLMの仕様は、業務上の制約条件をモデル構造へ翻訳した結果である。

「国産LLM」という一語では足りない――4つの主権と企業の選び方

2026年のAI主権は、モデルを自作することだけでなく、持つ・適応する・選択するという複数の形へ分岐している。

PLaMo、Sarashina、tsuzumiは、基盤モデルや学習過程を日本側で持つ「作る主権」。Mistralは、オープンウェイトを自社環境へ配置・調整できる「持てる主権」の参照点です。Namazuは世界の知能を日本へ寄せる「適応する主権」、Fuguは依存先を固定せず使う知能を選ぶ「選べる主権」と整理できます。

ただし、これは政治・法制度上の確定した分類ではなく、本稿でLLMの設計思想を比較するためのフレームです。

また、重みを保有できることと、利用・再配布・商用条件に制約がないことは同じではありません。Mistral Large 3とMedium 3.5でもライセンス条件は異なります。企業導入では、モデルごとのライセンス、商用利用条件、再配布条件、サポート範囲を確認する必要があります。

DeepSeekやKimi K2.6のように重みを取得できるモデルでも、重みを持てることと、モデルの来歴を完全に説明できることは別問題です。学習データの説明、ライセンス、データ送信先、輸出規制、調達継続性まで確認して初めて企業の「主権」になります。

LLMを選ぶ前に、まず次の問いに答えてください。

• 機密データは、外へ出せるか。
• 既存GPUは1枚か、4枚か、8枚以上か。あるいはGPUを自社保有しないのか。
• 巨大な契約書やコードベースを丸ごと扱うのか、RAGで必要な情報だけを取得するのか。
• AIエージェントは数分使うのか、数時間自律実行させるのか。
• 日本語の敬語・商習慣、重みの自社保有、国内データ処理、複数ベンダーの切り替えのうち、何が最優先か。

例えば「GPU1枚・機微データ・社内文書QA」が絶対条件なら、1Tモデルのランキングを眺める意味は薄くなります。逆に、数十万トークン規模のAgent履歴を大量処理するサービスなら、1GPUであることよりprefillやKVキャッシュの経済性が重要です。

したがって企業のLLM選定は、モデル名から用途を考えるのではありません。

用途・制約 → 必要な設計 → モデル

この順序で考えるべきです。LLMをモデル単体ではなく業務配置から選ぶ方法については、LLM比較・選び方2026｜企業のモデル選定・使い分け・Evals実践ガイドも参照してください。

「何を捨てたか」を見れば、設計の本質が見える

優れた設計とはすべてを盛り込むことではなく、何を優先し、何をしないかを決めることである。

比較表の最右列を読むと、各社の個性が見えてきます。DeepSeekは小型配置より長時間Agentの経済性、tsuzumiは最大級の汎用性能より1GPU所有、Namazuは基盤モデル自前開発より日本適応、Fuguは単一モデルの単純さより編成能力を優先しています。

なお、本稿の「あえて捨てたもの」は企業の公式表明ではなく、公開仕様・提供形態を基にしたArpable編集部の読みです。LLM選びでも、メリット一覧だけを見るのではなく、その強みのために何を優先しなかったかを見ると、自社との相性が見えます。

まとめ――「何Bか」ではなく、「なぜそのBなのか」を読む

LLMの数字は順位表ではない。各社が何を問題と見て、何を優先し、何を捨てたかを記録した設計判断の結果である。

DeepSeekは、長時間Agentの入力履歴とKVキャッシュを経済的に扱うため、巨大なバックボーンの一部を段階的・選択的に動かす構造へ進みました。tsuzumi 2は企業がGPU1枚で所有できることからモデル規模を逆算し、PLaMoは企業Agentの長い作業履歴を見据えて256Kへ広げました。

Sarashina3は現行mini／nanoで即答性と日本語業務性能を重視し、MistralはLargeとMediumで配置条件を分けました。Namazuは海外の基盤モデルを日本へ適応するレイヤーに価値を置き、Fuguは単一モデルの性能競争を越えて、モデル群の選択・委任・編成を知能へ変えようとしています。

この「配置場所、遅延、計算資源、データ境界から知能の形を逆算する」という視点は、Physical AIではさらに厳しく問われます。ロボットでは通信、電力、安全性、リアルタイム性という物理制約まで加わるからです。詳しくは、Physical AIとは？次世代AI技術の全体像、およびNoetraとは？国産フィジカルAI連合の正体をご覧ください。

だから企業が問うべきなのは、「一番大きなLLMはどれか」ではありません。

自社の仕事を、どこで、誰が、どれだけのコストで動かすのか。その条件に対して最も合理的な設計をしているのはどのモデルか。

パラメータ数、活性率、コンテキスト長は、その答えを探すための材料です。2026年のLLM選定で問われるのは、まさにこの順序です。

次にAIを選ぶとき、最初に開くのはスペック表ではなく、自社のサーバールームの扉と、社員が毎日使う業務の一覧かもしれません。

専門用語まとめ

記事内で重要な技術用語を、モデル選定に必要な範囲に絞って整理する。

コンテキスト長

1回の推論でモデルが保持・参照できるトークン量。会話、文書、ツール履歴などを含む。

総パラメータ

モデル全体が保持する学習済みパラメータの総数。知識・表現容量の一つの目安だが、性能順位そのものではない。

活性パラメータ

MoEなどで、1回の推論時に実際に利用されるパラメータ数。

MoE

Mixture of Experts。入力に応じて一部のExpertを選び、総容量を大きく保ちながら実効計算量を抑える方式。

Dense

推論時にモデル全体の重みを広く一貫して使う一般的な構造。MoEより構成が単純で、運用特性を読みやすい場合がある。

prefill

入力されたプロンプトや文書を最初に読み込み、生成に必要な内部状態を作る処理。

KVキャッシュ

過去の文脈を毎回計算し直さず利用するための中間情報。長文脈ではメモリ・帯域・保存容量の負荷が大きくなる。

Reasoning

複雑な問題について、追加の推論時間やトークンを使いながら段階的に解く能力・モード。

ソブリンAI

モデル、データ、計算基盤、運用、依存先などを国家・企業がどこまで自ら制御できるかを重視するAI戦略。

参考文献 / 出典

数値・仕様・設計理由は、原則として開発元の公式発表、論文、モデルカード、技術ブログを優先して確認した。

※企業が設計理由を明言していない箇所は、公開仕様や提供形態からのArpable編集部の分析として記述しています。特にSarashina3のパラメータ数・コンテキスト長、tsuzumi 2のコンテキスト長、PLaMo 3.0 Prime本体の内部構造、MistralのDense／MoE採用理由、Namazu APIの実効コンテキスト長などは、確認できない事項を推定値で埋めていません。

次に読むならこの3本

補足Q&A

Q1.
LLMはパラメータ数が大きいほど高性能ですか？

A1. いいえ。パラメータ数は能力を決める一要素であり、実務価値の順位表ではありません。

アーキテクチャ、学習データ、事後学習、Reasoning、ツール利用、推論方法で結果は変わります。企業利用ではGPU要件、レイテンシ、機密性、運用費も重要です。

Q2.
国産LLMはどれを選べばよいですか？

A2. モデル名より先に、機密性、GPU、扱う文書量、運用者という制約を決めてください。

1GPUオンプレが必須なのか、長時間Agentを大量運用するのか、日本語業務への適応を優先するのかで、合理的なモデルは変わります。

Q3.
1Mコンテキストは256Kより必ず優れていますか？

A3. 用途によります。長いほど常に有利というわけではありません。

巨大なコードベースや長時間Agentでは1Mが価値を持ちますが、長いコンテキストほどメモリやサービングコストの課題も増えます。RAGで必要情報だけを取得する業務では、256K以下でも十分な場合があります。

更新履歴