楽天グループが2026年3月17日に公開した「Rakuten AI 3.0」は、DeepSeekのオープンモデルを土台にしたモデルです。楽天は公開当初ベースモデルを明かさず、3月27日になって採用を認めました。ただ、DeepSeek-V3には2024年12月の初期版と2025年3月の改良版（V3-0324）があり、どちらを起点にしたかは楽天も説明していません。この記事では、Hugging Faceで配布されている重みファイルの中身をDeepSeek公式の3つの版と1テンソルずつ突き合わせ、最も近い版、配布物に欠けている部品、動かすのに必要なGPUを一次情報で整理します。
まとめ：DeepSeek-V3-0324に最も近い重みを追加学習したモデル
- ベースはDeepSeek-V3の系列で、楽天も2026年3月27日に「DeepSeekのオープンモデルを採用した」と認めています。
- 比較したDeepSeek公式3版のうち、重みが最も近いのは改良版のV3-0324です。正規化層の重み16本を比べると16本すべてが0324に最も近く、ルーター重みの要素一致率は0324に対して68〜78%、初期版に対して17〜28%でした。
- ただし0324とも同一ではありません。専門家（エキスパート）・注意機構・ルーターのすべてに変更が入っており、楽天の説明どおり追加学習を経た重みです。
- config.jsonとtokenizer.jsonはDeepSeekのものとほぼ同じで、日本語向けの語彙拡張はありません。
- 配布物にはMulti-Token Prediction（MTP）層の重みが入っていません。DeepSeek-V3で使えるMTPの投機的デコーディングは、同じ手順では使えません。
- ライセンスはApache 2.0で、DeepSeek由来のMIT表示はNOTICEで保持されています。DeepSeekの重みのうちMITで配布されているのはV3-0324で、重みの照合結果とも食い違いません。
- FP8の重みは673.2GBです。H100 80GBを8基並べたノードには載らず、H200 8基か、H100なら2ノード16基が必要です。
楽天の説明の変遷：非開示から採用を認めるまで
出自をめぐる議論は、楽天の説明が途中で変わったことで大きくなりました。公開されている記録を日付順に並べます。Hugging Faceのコミット時刻はUTCで記録されているので、日本時間に直しています。
| 日付（日本時間） | 出来事 |
|---|---|
| 2025年7月 | GENIAC第3期に採択 |
| 2025年11月21日 | GENIAC中間報告会で開発状況を報告 |
| 2025年12月18日 | Rakuten AI 3.0を発表 |
| 2026年3月16日 21:42 | Hugging Faceのリポジトリ作成 |
| 2026年3月17日 0:20 | 重み・config・tokenizerをアップロード |
| 2026年3月17日 | 提供開始を発表（ベースは「最良なモデル」とだけ記載） |
| 2026年3月17日 13:45 | NOTICE（DeepSeekの著作権表示）を作成 |
| 2026年3月18日 10:00 | 公式ベンチマーク表の数値を更新 |
| 2026年3月19日 | 取材に「ベースモデルは非開示」と回答 |
| 2026年3月27日 | 広報が「DeepSeekのオープンモデルを採用」と回答 |
| 2026年6月4日 | GENIAC第4期のキックオフ（紹介された採択事業者に楽天は入らず） |
2026年3月19日のITmedia AI＋の取材記事では、楽天の担当者がベースモデルを「非開示」とし、Hugging Face上のDeepSeek表記についても「AIモデルのパラメータ数などが自動的に計算され、DeepSeekと出てしまうが、『表記＝DeepSeek』というわけではない」と答えています。同じ記事は、config.jsonから骨組みはDeepSeek-V3とみられる一方、「『重み』にも、DeepSeek-V3が学習した結果を使用しているかは不明だ」と書きました。
説明が変わったのは8日後です。山口健太氏のYahoo!ニュース エキスパートの記事によると、楽天は3月27日の回答で「Rakuten AI 3.0においてはDeepSeekのオープンモデルを採用した」と認めました。ただ、どの版を使い、どれだけ学習したかは、10月21日時点でも楽天から説明がありません。ITmediaが「不明」とした重みの出どころは、次の章で配布ファイルから確かめます。
config.jsonとtokenizer.jsonの照合結果
config.jsonの共通構造とバージョン指定の差
Rakuten AI 3.0のconfig.jsonは、architectures が DeepseekV3ForCausalLM、model_type が deepseek_v3 です。DeepSeek-V3（初期版）・V3-Base・V3-0324の3つのconfig.jsonと全キーを突き合わせると、どれと比べてもキーの和集合は46項目、共通する42項目で値が違うのは transformers_version だけでした。
| config.jsonの項目 | Rakuten AI 3.0 | DeepSeek-V3系 |
|---|---|---|
| n_routed_experts | 256 | 256 |
| num_experts_per_tok | 8 | 8 |
| n_shared_experts | 1 | 1 |
| first_k_dense_replace | 3 | 3 |
| num_hidden_layers | 61 | 61 |
| hidden_size | 7168 | 7168 |
| vocab_size | 129280 | 129280 |
| max_position_embeddings | 163840 | 163840 |
| transformers_version | 4.57.1 | 4.33.1（0324は4.46.3） |
この並びは、楽天自身が2025年12月18日のプレスリリースに書いた「アクティブパラメータには3つの密な層とエキスパートコンポーネントが含まれ、各トークンは、常にアクティブな『共有エキスパート』と8つの『専門エキスパート』を経由します」という説明とも合います。「128個のエキスパートから2つを選ぶ」と書いた解説がありますが、設定値とも楽天の説明とも違います。MoEの経路選択の仕組みはMoE（Mixture of Experts）とは？疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説にまとめています。
3つの版は構造が同じなので、configからは起点の版を絞り込めません。DeepSeek自身もV3-0324のモデルカードに「The model structure of DeepSeek-V3-0324 is exactly the same as DeepSeek-V3.」と書いています。
tokenizer.jsonの一致とtokenizer_config.jsonの上限値
tokenizer.jsonのMD5は、Rakuten AI 3.0・V3・V3-Base・V3-0324の4つとも a3acd066a7f206efd5d5dd020e847f1f で一致しました。語彙には手を加えていません。Rakuten AI 7BはMistral-7B-v0.1の語彙を32,000から48,000へ拡張し、2.0の8x7Bも語彙48,000だったので、日本語トークナイザの作り込みという従来の方針は3.0で引き継がれていません。同じ日本語文のトークン数は、DeepSeek-V3と変わりません。
違いはtokenizer_config.jsonにあります。model_max_length がDeepSeek-V3-0324の131072に対して、Rakuten AI 3.0は16384です。transformers 4.57.1で読み込み、例文を1,000回つなげた23,001トークンの文を入れると「Token indices sequence length is longer than the specified maximum sequence length for this model (23001 > 16384)」と警告が出て、truncation=True を付けると16,384トークンで切り詰められました。
from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("Rakuten/RakutenAI-3.0")
print(tok.model_max_length) # 16384
s = "楽天グループは2026年3月17日にRakuten AI 3.0を公開しました。"
long_text = s * 1000
print(len(tok(long_text)["input_ids"])) # 23001（警告が出る）
print(len(tok(long_text, truncation=True)["input_ids"])) # 16384モデルカードが掲げるコンテキスト長は128Kです。長い文書を自前の前処理でトークナイズするときは、max_length を明示して切り詰めの位置を自分で決めてください。チャットテンプレートはDeepSeek形式で、出力は <｜begin▁of▁sentence｜>（システム）<｜User｜>（質問）<｜Assistant｜> の並びになります。
重みテンソルの比較で最も近い版はV3-0324
重みファイル（safetensors）は先頭にテンソルの名前と位置を並べたヘッダを持つので、範囲指定のダウンロードで特定のテンソルだけを取り出せます。673GBを丸ごと落とさずに、Rakuten AI 3.0とDeepSeek公式の3版から同じ名前のテンソルを取り、数値を比べました（2026年10月21日実測）。比べたのは各リポジトリのmainブランチで、コミットはRakuten AI 3.0が b94f096、DeepSeek-V3が e815299、V3-Baseが afb92e1、V3-0324が e9b33ad です。
正規化層16本の平均絶対差による3版比較
BF16で保存されている正規化層の重みを、8つの層（1・5・15・25・35・45・55・60層目）から2種類ずつ、計16本比べました。平均絶対差が最も小さかった版は、16本すべてがV3-0324です。15層目の kv_a_layernorm は差がほぼゼロでした。
| テンソル（例） | 対V3初期版 | 対V3-Base | 対V3-0324 |
|---|---|---|---|
| 1層目 input_layernorm | 0.00012 | 0.00009 | 0.00003 |
| 5層目 kv_a_layernorm | 0.00038 | 0.00034 | 0.00003 |
| 15層目 kv_a_layernorm | 0.00040 | 0.00021 | 0.00000 |
| 60層目 input_layernorm | 0.00011 | 0.00009 | 0.00004 |
| 最も近い版になった本数 | 0本 | 0本 | 16本 |
数字は要素ごとの差の絶対値の平均です。MoEのルーター（mlp.gate.weight、256×7168）でも同じ傾向が出ました。BF16の値が完全に一致する要素の割合は、3・20・40・60層目で0324に対して68〜78%、初期版に対して17〜28%です。参考までに、DeepSeek公式の初期版と0324どうしの20層目ルーターの一致率は29.8%でした。楽天の重みは、DeepSeek自身の版の違いよりも0324の近くにあります。
抽出した専門家・注意機構・ルーター重みの差分
最も近い0324とも、重みは同じではありません。比べたテンソルはすべてMD5が異なり、FP8で保存された部分もバイト単位で一部が書き換わっています。
| テンソル | Rakuten対0324の一致率 | 公式V3対0324の一致率 |
|---|---|---|
| 50層目 専門家200 up_proj（FP8） | 81.5% | 78.2% |
| 30層目 注意機構 q_b_proj（FP8） | 89.2% | 81.1% |
| 20層目 ルーター gate（BF16） | 78.1% | 29.8% |
| 10層目 ルーター補正バイアス（F32） | 0%（256要素） | 100% |
表の専門家・注意機構は各1テンソルで、比べたのは保存されたFP8のバイトです。FP8はブロックごとの倍率と組み合わせて値を復元するので、この一致率だけでモデル全体の変更量は測れません。言えるのは、どのテンソルにも手が入っていることです。目立つのは最終行のルーター補正バイアス e_score_correction_bias です。DeepSeekの3版では同じ値なのに、楽天版は256要素すべてが違います。この値は、DeepSeek-V3が補助損失なしで専門家の負荷を均すために学習中に更新するものです。正規化層の重みやこのバイアスは、線形層に低ランクの差分を足す一般的なLoRAでは変わりません。少なくとも正規化層やルーターまで学習の対象に含めた追加学習だったと読めます。
照合結果は「名前を変えただけ」とも「一から作った」とも合いません。比較した3版のうちV3-0324に最も近い重みに、楽天が追加学習を施したモデル、というのが実データから言える範囲です。公開版の学習データ量は、重みの差からは逆算できません。楽天はGENIACの中間報告会で「日本語1,250億トークン規模の事前学習」と説明していますが、これが公開版に使われた量かどうかは確認できていません。ベースになったDeepSeek-V3自体の仕組みはDeepSeek-V3とは？671B MoEの仕組みと性能・公式API終了後の使い方で解説しています。
総パラメータ数の差とMTP層の配布状況
Hugging Faceが表示する総パラメータは、Rakuten AI 3.0が671,026,419,200、DeepSeek-V3初期版が684,489,845,504です。この差を「重みが別物の証拠」とする説明を見かけますが、根拠になりません。差の13,463,426,304は、DeepSeekがモデルカードで「685B, which includes 671B of the Main Model weights and 14B of the Multi-Token Prediction (MTP) Module weights」と書いているMTPモジュールの分にほぼ当たります。
Rakuten AI 3.0の model.safetensors.index.json には、MTPにあたる62層目（model.layers.61）のテンソルが788本載っています。ところが、それらを収めるはずの161〜163番のシャードは中身が16バイト（空のヘッダ {} だけ）のファイルでした。索引には名前があるのに、重みの実体は配布されていません。
実務への影響は推論の高速化に出ます。SGLangのDeepSeek-V3手順書は、MTPを使うEAGLE方式の投機的デコーディングで、H200のTP8構成で「up to 1.8× at batch size 1」高速化すると案内し、例に --model-path deepseek-ai/DeepSeek-V3-0324 --speculative-algorithm EAGLE を挙げています。Rakuten AI 3.0にはMTP層の重みが無いので、同じ指定で同じ効果は期待できません。仕組みはMTP（Multi-Token Prediction）とは？LLMの複数トークン予測の仕組みと投機的デコーディングでの使い方を参照してください。
GENIACで報告された研究内容と公開版のずれ
経済産業省のGENIAC第3期中間報告会の記録では、楽天は「日本語1,250億トークン規模の事前学習により約700Bパラメータの日本語特化モデルを構築し、Attentionの一部をLinear Attentionへ置き換えるアーキテクチャ変更を推進しています」と説明し、ロングコンテキストを「128Kから2M長へ段階的に対応」するとしていました。2026年3月27日の成果報告会の記録では「最大200万トークンに対応するロングコンテキスト処理を実現」と報告しています。
公開版では、報告されたLinear Attentionへの変更や200万トークン対応を確認できません。config.jsonにLinear Attentionを示す項目は無く、注意機構はDeepSeek-V3と同じMulti-head Latent Attention（kv_lora_rank 512）のままです。位置埋め込みの上限は163,840トークンで、モデルカードの表記は128Kです。報告会で説明された研究モデルが公開されるのか、楽天は10月21日時点で説明していません。200万トークンの長文処理を期待して3.0を選ぶと外れます。
楽天は補助を受けた成果物を公開しています。なお、2026年6月4日のキックオフイベントで紹介されたGENIAC第4期の採択16社に、楽天は入っていません。一から学習した国産モデルとの違いは、国産生成AI基盤モデル「PLaMo 3.0 Prime」とは｜2026年最新の性能・料金・使い分けやデジタル庁が選定した国産AI7モデルと試用中の5社｜源内の国産LLM比較・選定基準・2027年度公募と比べると分かります。
公式ベンチマーク表（3月18日更新後）の読み方
楽天の2026年3月17日のプレスリリースに載る比較表は、公開翌日に差し替えられています。表の直下には「※GPT-OSS-Swallow-120B-RL-v0.1とABEJA-QwQ32b-Reasoning-Japanese-v1.0について、MMLU-ProXおよびMATH-100のスコアを更新しました（2026年3月18日10:00時点）。」と注記があります。公開当日の数値を引用した記事は、この更新を反映していません。現在の表は次のとおりです。
| モデル | JamC-QA | MMLU-ProX(日本語) | MATH-100(日本語) | M-IFEval(日本語) |
|---|---|---|---|---|
| Rakuten AI 3.0 | 76.9 | 71.7 | 86.9 | 72.1 |
| gpt-4o | 74.7 | 64.9 | 75.8 | 67.3 |
| GPT-OSS-Swallow-120B-RL-v0.1 | 63.0 | 77.5 | 96.0 | 69.5 |
| Stockmark-2-100B-Instruct | 61.1 | 41.7 | 55.6 | 45.6 |
| ABEJA-QwQ32b-Reasoning-v1.0 | 61.1 | 71.2 | 89.9 | 61.9 |
gpt-4oには4指標すべてで勝っていますが、120BのGPT-OSS-Swallowには2勝2敗で、MMLU-ProXは71.7対77.5、MATH-100は86.9対96.0です。数学では32BのABEJA-QwQ32bにも及びません。671Bという規模が日本語の推論力や数学力に比例していないことを、楽天自身の表が示しています。
3.0が明確に強いのは、日本固有の文化・歴史知識を問うJamC-QAの76.9と、指示追従を測るM-IFEvalの72.1です。日本文化に関する知識や日本語の指示追従を重視する用途では候補になりますが、固有名詞や商習慣の正確さは対象業務の評価データで確認する必要があります。数学的推論を優先するなら、比較表のGPT-OSS-Swallow-120B-RL-v0.1も候補です。ただし、必要なGPU台数は重みの精度、GPUの容量、コンテキスト長で変わります。構成はSwallowとは？Llama 3.3 Swallowの特徴・日本語性能・商用利用を解説にまとめました。表の値は楽天が測ったもので、プロンプトや採点の条件が変われば数値は動きます。
Apache 2.0とMITが同居する商用利用の条件
Rakuten AI 3.0はApache 2.0で配布され、NOTICEに「Copyright (c) 2023 DeepSeek」で始まるMITの条文が入っています。DeepSeek-V3の重みのライセンスは版で違います。初期版のモデルカードは「The use of DeepSeek-V3 Base/Chat models is subject to the Model License.」として独自のModel License（利用制限条項付き）を課し、V3-0324のモデルカードは「This repository and the model weights are licensed under the MIT License.」です。NOTICEがMITであることは、重みが0324に最も近いという照合結果と食い違いません。
商用利用も派生モデルの公開もできます。派生モデルを再配布するときは、Apache 2.0のライセンスの写しと必要な帰属表示を保持し、変更したファイルには変更した旨を明示してください。NOTICEに収められたDeepSeekの著作権表示とMITの許諾文も、再配布物から失わせないことが必要です。Apache 2.0の明示的な特許許諾は、各貢献者が許諾でき、その貢献単独または作品との組合せによって必然的に侵害される特許請求項に限られます。一方、MITの本文には明示的な特許許諾の条項がありません。
見送るべき場面もあります。調達要件で中国由来の学習済み重みを除外している組織では、Apache 2.0や「国内最大規模」という表記を根拠に審査を通すと後から覆ります。楽天自身が採用を認めているので、審査にはconfig.jsonの model_type・NOTICE・3月27日の回答を先に出して議論したほうが手戻りは少なくなります。社内導入の要件整理から進めたい場合は、生成AI導入支援でモデル選定と閉域環境での運用設計をお手伝いしています。
ローカルで動かすときの重みサイズとGPU台数
公式リポジトリの重みは、FP8（e4m3、ブロックサイズ128×128）で量子化済みのsafetensorsが163シャード、合計673.2GB（626.9GiB）です。FP8という形式はFP8とは？FP16・BF16・FP4との違いとE4M3/E5M2の仕組み、対応GPU【2026年版】で解説しています。モデルカードは推奨Dockerイメージに lmsysorg/sglang:v0.5.6.post2 を挙げ、起動コマンドを次のように案内しています。
python -m sglang.launch_server \
--model-path Rakuten/RakutenAI-3.0 \
--tp 8 \
--mem-fraction-static 0.85 \
--trust-remote-code \
--show-time-cost--mem-fraction-static は、重みとKVキャッシュのプールを含む静的確保に使うGPUメモリの割合です。0.85なら各GPUの85%しか使わないので、公称80GBのH100を8基そろえても確保できるのは540〜580GB程度で、673.2GBの重みは載りません。SGLangの手順書も、FP8のDeepSeek-V3の推奨構成を「8× H200, 8× B200, 8× MI300X, 2×8× H100/H800/H20」としています。H100で動かすなら2ノード16基です。公称141GBのH200を8基なら合計約1,128GB、0.85でも950GB超を確保でき、KVキャッシュの余地も残ります。
手元がH100 8基までなら、4bit量子化版が候補です。rakuten-junliu/RakutenAI-3.0-W4A16 は2026年8月30日に公開され、重み合計402.1GB（374.5GiB）まで縮みます。ただし配布元のモデルカードは、同じ形式の以前のビルドを8×H100で動かした一方、この版そのものはH100での読み込みを未検証としています。SGLangの手順書もW4A8やAWQなどの4bit系なら「8× H20/H100」を挙げています。ほかに mmnga-o/RakutenAI-3.0-gguf（GGUF）と mlx-community/RakutenAI-3.0-MLX-4bit（Apple Silicon向け）がありますが、いずれも楽天の公式配布ではありません。
本体のダウンロードは、Hugging Face APIの集計で直近30日が310件、累計が69,637件です（2026年10月21日時点）。量子化版の直近30日はW4A16が103件、GGUFが84件でした。いきなり671Bに投資する前に、gpt-oss-120bの性能と20bとの違い｜ベンチマーク・推論レベル・必要GPUを一次情報で整理のような120Bクラスで要件を固めてから判断する順序を勧めます。
よくある質問
Rakuten AI 3.0は中国製のAIですか？
重みは中国のDeepSeek社が公開したDeepSeek-V3系で、比較した版の中ではV3-0324に最も近く、楽天も2026年3月27日にDeepSeekのオープンモデルを採用したと認めています。その上に楽天が日本語データで追加学習しました。重みを自社のサーバーに置けば外部と通信せずに動くので、「中国のサーバーにデータが送られる」性質のものではありません。DeepSeek社のアプリやAPIを使う場合とは、リスクの種類が違います。
Rakuten AI 3.0の中身はDeepSeek-V3と同じですか？
構造（config.json）と語彙（tokenizer.json）は同じですが、重みは同じではありません。照合したテンソルは、専門家・注意機構・ルーターのどれも値が書き換わっていて、ルーター補正バイアスは256要素すべてがDeepSeekの値と違います。名前を変えただけのモデルでも、一から学習したモデルでもありません。
Rakuten AI 3.0のAPIやRakuten AIゲートウェイは外部から使えますか？
楽天公式の外部向け公開APIは、確認した公式資料では案内されていません。公式に案内されている提供形態は、Hugging Faceからの重みの無償ダウンロードです。プレスリリースに出てくる「Rakuten AIゲートウェイ」は、2025年12月18日の注記で「生成AI APIを統合した楽天従業員向けのプラットフォーム」と定義されています。社外から使うには、自前のGPUでSGLangなどの推論サーバーを立てる必要があります。
楽天のサービスでRakuten AI 3.0は使われていますか？
2026年3月19日の取材で、楽天は3.0を「現時点で同社のAIサービスに導入しておらず、将来的な活用を検討している段階」と答えています。学習に「Rakuten ID」にひも付いたユーザー情報は使っていないとも説明しました。2026年7月29日に発表されたRakuten AI for Desktopが端末で動かすモデルはRakuten AI 7Bで、3.0の搭載を明記した発表は10月21日時点で見当たりません。なお同じプレスリリースは、7Bについて「Mistral-7B-v0.1」を継続学習したとベースを明記しています。
GGUF版やOllamaならPCでも動かせますか？
一般的なPCではメモリが足りません。mmnga-o/RakutenAI-3.0-gguf は最も軽いQ2_Kでも244.1GB、実用的なQ4_K_Mで404.5GBあり、単体GPUのメモリにも一般的なワークステーションの本体メモリにも収まりません。例外は大容量の統合メモリを積んだ機種で、AppleはM3 Ultra搭載Mac Studioの発表で最大512GBの構成と「6,000億以上のパラメータを持つ大規模言語モデル（LLM）を完全にインメモリで実行できます」と案内しています。容量の上ではQ2_Kが収まりますが、重み以外に必要なメモリや生成速度は別に確かめる必要があります。
