この記事の対象読者

国産LLMの動向に関心があるエンジニア
Mixture of Experts (MoE) アーキテクチャに興味がある方
ローカルLLMの選定基準を知りたい方
「オープンソースAI」の透明性について考えたい方

この記事で得られること

Rakuten AI 3.0 のアーキテクチャ・スペック・ベンチマーク結果を正確に把握できる
DeepSeek V3ベース疑惑の技術的根拠と、それが意味することを理解できる
671Bパラメータモデルを動かすために必要なハードウェア要件を現実的に見積もれる

この記事で扱わないこと

DeepSeekの政治的・安全保障的な是非（本記事は純粋に技術的な分析に限定します）
Rakuten AI 3.0 の商用利用の法的判断
他の国産LLM（NTT tsuzumi等）との網羅的な比較

1. 何が起きたのか — 公開から24時間で炎上

2026年3月17日、楽天グループが国内最大規模のLLM「Rakuten AI 3.0」の提供を開始した。

約7,000億パラメータ。MoE（Mixture of Experts）アーキテクチャ。Apache 2.0ライセンスで無償公開。経済産業省・NEDOのGENIACプロジェクト第3期として国の補助を受けて開発。日本語ベンチマークでGPT-4oを上回るスコア。

ここまでなら「素晴らしい。国産AI頑張ってるな」で終わる話だった。

だが、公開直後にHugging Faceのリポジトリを覗いた技術者たちが、ある発見をした。

config.jsonを開くと、こう書いてあった。

{
  "model_type": "deepseek_v3",
  ...
}

(;ﾟдﾟ)ﾎﾟｶｰﾝ

これがX（旧Twitter）上で瞬く間に拡散され、「国産最大規模のLLMがDeepSeek V3ベースだった」という議論が巻き起こった。

2. Rakuten AI 3.0の技術スペック — まずは事実を整理する

感情的な議論の前に、まずは公開されている事実を正確に把握しよう。

2.1 基本スペック

項目	詳細
モデル名	Rakuten AI 3.0
パラメータ数	約671B（6,710億）
アーキテクチャ	Mixture of Experts (MoE)
トークンあたり活性化パラメータ	約37B
エキスパート数	128（うち2つを選択）
コンテキスト長	128K
推論精度	FP8
ライセンス	Apache 2.0
公開場所	HuggingFace - Rakuten

2.2 楽天のLLM進化の軌跡

Rakuten AI 3.0 は、楽天にとって3世代目のLLMだ。

70億 → 470億 → 6,710億。約100倍の規模ジャンプ。この飛躍は、GENIACプロジェクトによる計算資源の補助なしには実現できなかっただろう。

2.3 MoEアーキテクチャの仕組み

「7,000億パラメータ」と聞くとGPT-4クラスを想像するが、MoEの実態はやや異なる。

レストランの比喩で言えば、128人のシェフ（エキスパート）がいるが、1つの注文に対しては2人しか稼働しない。残りの126人は休んでいる。

つまり:

総パラメータ数: 671B（モデル全体の知識量）
推論時の活性化パラメータ: 37B（実際に動く計算量）

これにより、671Bの「知識」を持ちながら、推論コストは37Bモデル相当に抑えられる。計算効率と性能のバランスを取る賢いアーキテクチャだ。

3. 日本語ベンチマーク — 本当にGPT-4oを超えたのか

楽天のプレスリリースでは、複数の日本語ベンチマークで優秀なスコアを報告している。

3.1 ベンチマーク結果

楽天公式の発表によると、日本固有の文化的知識・歴史、大学院レベルの推論、競技数学、指示遵守能力に関する複数のベンチマークで、GPT-4oを上回るスコアを達成したとされる。

ベンチマーク結果の解釈には注意が必要です。モデルの「賢さ」は特定のベンチマークスコアだけでは測れません。実際のユースケースでの検証が不可欠です。

3.2 MT-Benchでの評価

日本語MT-Benchにおいて、8.88というスコアが報告されている。これはGPT-4oを上回る数値だ。

ただし、ベンチマークスコアの高さと実用性は必ずしも一致しない。特に以下の点は検証が必要だ。

長文生成時の一貫性
ハルシネーション（事実と異なる生成）の頻度
コード生成能力
マルチターン対話での文脈保持

4. DeepSeek V3ベース疑惑 — config.jsonが語る真実

4.1 何が見つかったのか

HuggingFaceリポジトリのconfig.jsonに "model_type": "deepseek_v3" という記述が存在する。

config.jsonはモデルのアーキテクチャや設定を定義するファイルで、model_typeフィールドはそのモデルの基盤構造を示す最も基本的な情報の一つだ。

4.2 これが意味すること

冷静に整理しよう。

「DeepSeek V3ベース」であること自体は、技術的に問題ない。

楽天のプレスリリースにも「オープンソースコミュニティ上の最良なモデルを基に」と明記されている。DeepSeek V3はApache 2.0で公開されたオープンソースモデルであり、それを基盤にファインチューニングを行うことは、ライセンス上も技術的にも正当な手法だ。

問題は透明性にある。

楽天の公式表現	実態
「オープンソースコミュニティ上の最良なモデルを基に」	DeepSeek V3のアーキテクチャをそのまま使用
「楽天独自の高品質なバイリンガルデータ」で開発	ファインチューニングによる日本語最適化
「国内最大規模のAIモデル」	ベースモデル自体は中国発

楽天が「DeepSeek V3を使った」と一言も嘘は言っていない。しかし、積極的にベースモデルの出自を明示もしていなかった。技術者はconfig.jsonを見れば一発でわかるのだが、非技術者や経営層にとっては「国産AI」のイメージとの乖離が大きい。

4.3 他の国産LLMとの比較

この文脈を理解するために、国内の他のLLM開発状況を見てみよう。

モデル	パラメータ数	アプローチ	特徴
Rakuten AI 3.0	671B (MoE)	DeepSeek V3ベース + ファインチューニング	規模最大、日本語ベンチ高スコア
NTT tsuzumi	非公開（軽量）	スクラッチ開発（推定）	1GPUで動作、オンプレ特化
Preferred Networks PLaMo	100B級	独自開発	研究特化

「ベースモデルを使うか、スクラッチで作るか」は技術的なトレードオフであり、どちらが正しいということではない。重要なのは、その選択を透明に開示しているかどうかだ。

個人的所感: ベースモデルの出自を積極的に開示する文化が、日本のAI開発コミュニティにも根付いてほしいと思う。技術的に誠実であることが、長期的な信頼構築の基盤になるはずだ。

5. 実際に動かすには — ハードウェア要件の現実

5.1 必要なGPU構成

671BパラメータのMoEモデルをFP8で動かす場合、モデル重みの格納だけで約670GBのVRAMが必要になる。

構成	GPU	枚数	合計VRAM	推定コスト
推奨構成	NVIDIA H100 (80GB)	8基	640GB	DGXサーバ: 数千万円
最小構成	NVIDIA A100 (80GB)	8基	640GB	やや安いが厳しい
クラウド	H100 x8相当	-	-	月額数百万〜1,000万円超

RTX 5090（32GB VRAM）では到底足りない。RTX PRO 6000（96GB VRAM）を8枚並べても768GBで、テンソル並列の効率を考えるとギリギリだ。

つまり、個人開発者やスタートアップがローカルで動かすのは現実的ではない。

5.2 推論サーバ構成例

仮に自前で推論環境を構築する場合の構成:

# Rakuten AI 3.0 推論環境（推奨構成）
server:
  gpu: "NVIDIA H100 80GB"
  gpu_count: 8
  tensor_parallel: 8
  ram: "1TB+"
  storage: "2TB NVMe SSD"
  
inference:
  precision: "FP8"
  framework: "vLLM or TensorRT-LLM"
  context_length: 128000
  batch_size: "環境依存（要チューニング）"
  
estimated_cost:
  hardware: "3,000万〜5,000万円"
  cloud_monthly: "300万〜1,000万円/月（常時稼働時）"

5.3 量子化による軽量化の可能性

GGUF形式への変換や追加の量子化により、必要VRAM量を削減できる可能性はある。ただし:

671BパラメータのMoEモデルの量子化は、通常のDenseモデルより複雑
エキスパート選択ルーティングの精度劣化リスクがある
現時点でRakuten AI 3.0向けのGGUF変換は公式には提供されていない

llama.cpp や Ollama でカジュアルに動かせる日が来るかどうかは、コミュニティの変換作業次第だ。

6. 企業導入時の注意点

6.1 セキュリティ・コンプライアンスの観点

DeepSeek V3ベースであることが、企業導入のハードルになるケースがある。

懸念点	技術的事実	対応
「中国にデータが送られる？」	NO。オープンウェイトモデルをローカルで動かす場合、データは外部に送信されない	技術的根拠を含む社内説明資料の作成
「安全保障上の問題は？」	モデルの重みは公開情報。利用自体に法的問題はない	所管省庁のガイドライン確認
「監査で指摘されないか？」	ライセンス（Apache 2.0）の遵守を証明できればOK	NOTICEファイルの確認・保全

6.2 ライセンスの二重表記問題

先述の通り、リポジトリには「Apache 2.0」と「MIT（DeepSeek由来）」の二重表記がある。これは法的に矛盾するわけではない（Apache 2.0はMITと互換性がある）が、社内法務との確認を推奨する。

7. 学習ロードマップ

レベル	学習内容	リソース
Level 1	LLMの基本概念とMoEアーキテクチャ	DeepSeek V3 Technical Report (arXiv)
Level 2	HuggingFaceでのモデル利用方法	HuggingFace Transformers Documentation
Level 3	大規模モデルの分散推論（テンソル並列）	vLLM Documentation
Level 4	量子化技術（FP8, GPTQ, AWQ）	NVIDIA TensorRT-LLM Documentation
Level 5	日本語LLMのファインチューニング手法	GENIAC公開資料 + Rakuten公式リポジトリ

まとめ

Rakuten AI 3.0は、技術的には間違いなく国内最大規模のLLMであり、日本語性能も高い。GENIACプロジェクトを通じた国の支援もあり、日本のAI開発における重要なマイルストーンだ。

一方で、config.jsonを1行読めばわかるベースモデルの出自が、プレスリリースでは曖昧にされていたことは残念だ。「オープンソースを活用すること」と「ベースモデルを明示すること」は両立できるし、むしろ明示した方が技術コミュニティからの信頼は高まる。

個人的には、671Bパラメータという巨大モデルが Apache 2.0 で公開された事実は素直に歓迎している。H100を8枚買う余裕がある企業にとっては、日本語特化の強力な選択肢だ。ただ、我々のようなRTX 5090勢がローカルで動かせるかというと...まだまだ先の話だな。草

重要なのは「どこが作ったか」ではなく「何ができるか」「透明性があるか」だと思う。国産であることに価値を感じる気持ちはわかるが、技術の世界ではコードとデータが全てを語る。

参考文献

この記事に関連する他の記事:

LLMの基礎、vLLMでの推論高速化、GGUF量子化の仕組みについては過去記事で詳しく解説しています。

@geneLab_999 (X) でAIセキュリティ・ローカルLLM・GPU開発環境の情報を発信しています。