Rakuten AI 3.0の正体を知りたい技術者が押さえるべきDeepSeek V3ベースの全体像

Rakuten AI 3.0の正体を知りたい技術者が押さえるべきDeepSeek V3ベースの全体像

2026年3月17日、楽天グループは国内最大規模をうたう大規模言語モデル「Rakuten AI 3.0」の一般提供を開始しました。約7,000億パラメータを誇るこのモデルは、日本語処理に特化した設計を特徴とし、経済産業省・NEDOが推進するGENIACプロジェクトの第3期採択事業として開発されています。しかし公開直後、Hugging Face上のリポジトリからDeepSeek V3アーキテクチャとの深い関連が指摘され、技術コミュニティで大きな議論を呼びました。本章では、開発の経緯からスペックの読み方まで、Rakuten AI 3.0を理解するうえで欠かせない全体像を整理します。

2025年12月発表から2026年3月公開までの開発経緯と追加ファインチューニングの内容

Rakuten AI 3.0が最初に発表されたのは2025年12月のことです。この時点では楽天グループの各種サービスへ順次導入する計画が示されたのみで、モデル本体の一般公開は行われていませんでした。発表から約3カ月を経た2026年3月17日、Hugging Face上の楽天公式リポジトリを通じてモデル重みが無償ダウンロード可能となり、正式に提供が開始されています。

この3カ月間に施された主な改良がファインチューニングです。楽天のプレスリリースによれば、2025年12月の初期発表バージョンに対して追加の調整が行われ、複数の日本語ベンチマークで改善されたスコアを達成したとされています。具体的なファインチューニング手法の詳細は公開されていませんが、一般的にはSFT（教師ありファインチューニング）やRLHF（人間のフィードバックによる強化学習）といった工程が想定されます。発表時点から公開時点までの間に楽天独自のバイリンガルデータを用いた品質向上が進められたことは、ベンチマークスコアの改善からも裏付けられるでしょう。

楽天が公式に述べた「オープンソースコミュニティ上の最良なモデル」の具体的意味

楽天の公式プレスリリースには「オープンソースコミュニティ上の最良なモデルを基に」という表現が繰り返し使われています。この文言が指し示す具体的なベースモデルについて、楽天は当初モデルカード上で明示していませんでした。しかし、公開されたリポジトリのconfig.jsonファイルに「model_type: deepseek_v3」という記述が含まれていたことから、ベースモデルがDeepSeek V3であることが技術コミュニティによって即座に特定されています。

DeepSeek V3は中国のDeepSeek社が開発した671Bパラメータ規模のMoEモデルであり、MITライセンスのもとでコードリポジトリとモデル重みが公開されています。楽天がこのモデルを「最良なモデル」と表現した背景には、同規模帯のオープンソースモデルの中でDeepSeek V3が多くのベンチマークで上位の性能を示していた事実があります。つまり「オープンソースコミュニティ上の最良なモデル」とは、事実上DeepSeek V3を指す表現であったと理解するのが妥当です。この点に関する楽天側の説明の曖昧さが、後述するベースモデル開示の議論へとつながっています。

Rakuten AI 7B→2.0→3.0で70億から7000億へ拡大したパラメータ推移と設計思想の変化

楽天のAIモデル開発は段階的にスケールアップしてきました。最初のRakuten AI 7Bは約70億パラメータの比較的小規模なモデルで、Mistral-7Bをベースに日本語最適化を施したものでした。続くRakuten AI 2.0は約470億パラメータへ拡張され、より高度な日本語理解を実現しています。そして今回のRakuten AI 3.0では約7,000億パラメータと、前世代の約15倍の規模に達しました。

注目すべきは設計思想の変遷です。Rakuten AI 7Bの時代はMistral-7Bという比較的シンプルなDenseモデルをベースにしており、ベースモデルの出自も明確に表記されていました。一方、Rakuten AI 3.0ではMoE（Mixture of Experts）アーキテクチャを採用しており、総パラメータ数は巨大でも実際に推論時に活性化するのは37B相当にとどまる設計です。パラメータ規模の拡大と同時に計算効率を高める方向へと設計思想が大きく転換しており、大規模モデルを実運用に耐えるコストで動かすという課題に正面から取り組んだ結果といえます。

GENIACプロジェクト第3期採択が開発資金とGPUリソースに与えた影響の規模感

Rakuten AI 3.0の開発は、経済産業省とNEDOが推進するGENIAC（Generative AI Accelerator Challenge）プロジェクトの第3期公募に採択された事業として進められました。楽天は2025年7月にこの第3期に採択されており、モデルの学習費用の一部についてGENIACからの補助を受けています。GENIACは日本国内における生成AI開発力の強化を目的としたプロジェクトであり、採択企業に対して計算資源の支援や資金補助を提供する枠組みです。

671Bパラメータ規模のMoEモデルを学習するには膨大なGPUリソースが必要になります。DeepSeek V3の論文によれば、事前学習だけで約266万H800 GPU時間、コンテキスト長拡張やポストトレーニングを含めた全訓練では約278.8万H800 GPU時間が費やされたと報告されています。楽天の場合はゼロからの事前学習ではなく追加学習が中心と考えられますが、それでも相当規模の計算資源が必要です。GENIACの支援がなければ、国内企業が単独でこの規模のモデル開発に踏み切ることは資金面で容易ではなかったでしょう。公的資金が投入された事実は、後述する「国産AI」表記の透明性議論にも直結しています。

モデルカード記載のContext Length 128K・FP8推論が示す実用スペックの読み方

Rakuten AI 3.0のモデルカードには、コンテキスト長128Kトークンおよびfp8（8ビット浮動小数点）推論対応と記載されています。128Kトークンのコンテキスト長は、日本語に換算するとおおむね6万〜8万文字程度のテキストを一度に処理できる能力に相当します。長大な契約書や社内規程の全文を投入して要約や分析を行う業務には十分な長さといえるでしょう。

FP8推論への対応は、運用コストの面で大きな意味を持ちます。一般的にFP16（16ビット浮動小数点）からFP8へ量子化することで、必要なGPUメモリを約半分に削減しつつ推論速度を向上させることが可能です。Rakuten AI 3.0の推奨Docker環境としてsglangのv0.5.6.post2が指定されており、tp8（テンソル並列数8）での起動が標準構成として案内されています。つまり最低8基のGPUによる並列推論が前提となる規模ですが、FP8対応により同等精度を維持しつつハードウェアコストを抑えた運用が可能な設計です。

671Bパラメータ・MoE構成が日本語処理にもたらす精度向上と計算効率の仕組み

Rakuten AI 3.0が採用するMixture of Experts（MoE）アーキテクチャは、巨大なパラメータ数と実用的な推論コストを両立させる技術です。全体で671Bのパラメータを持ちながら、1トークンの処理に使われるのは37Bにすぎないという構造は、日本語のように語彙や表現が多様な言語の処理に適した設計といえます。本章では、この技術的な仕組みと日本語処理における具体的な利点を掘り下げます。

総パラメータ671Bに対しトークンあたり活性化37Bで推論負荷を抑える仕組みの要点

MoEモデルの最大の特徴は、モデル全体のパラメータのうちごく一部だけを各トークンの処理に使用する点にあります。Rakuten AI 3.0の場合、671Bのパラメータのうち推論時に実際に活性化するのは約37Bです。これは全体の約5.5%にすぎません。入力されたトークンに対して最適なエキスパート（専門家サブモデル）だけが呼び出される仕組みにより、巨大モデルの知識量を維持しながら計算コストを大幅に削減しています。

この設計は、同じ37Bパラメータ規模のDenseモデルと比較した場合に明確な優位性をもたらします。Denseモデルでは37Bのパラメータがすべての知識を担う必要がありますが、MoEモデルでは671B分の知識プールから必要な37B分だけを選択的に使えるため、同じ推論コストでもはるかに豊富な知識にアクセスできます。日本語の敬語や方言、ビジネス用語、文学的表現といった多様な言語パターンに対応するには、この「知識量と計算量の分離」が非常に有効に機能するのです。

128エキスパートから2つだけ選択するルーティング設計がタスク精度に与える効果

DeepSeek V3のアーキテクチャでは、各MoEレイヤーに128のエキスパートが配置され、1トークンあたり2つのエキスパートだけが選択されます。Rakuten AI 3.0もこの構成を踏襲しているとみられます。128分の2という選択率は非常に絞り込まれた設計であり、これによりエキスパート間の役割分担が明確になります。

たとえば、日本語の文化的知識に関する質問が入力された場合、日本文化に精通したエキスパートが優先的に選択される可能性があります。一方、数学的推論が求められる場合には数理処理に強いエキスパートが活性化します。このようにタスクの性質に応じて最適な組み合わせが動的に決定されるため、単一のモデルでありながら多様なタスクに高精度で対応できるわけです。さらに、ノード制限ルーティングにより各トークンの処理が最大4ノードに制限されており、分散推論環境でのネットワーク通信コストも抑制されています。

Multi-head Latent Attentionによるメモリ圧縮が長文日本語処理で有利に働く理由

Rakuten AI 3.0のベースとなったDeepSeek V3は、Multi-head Latent Attention（MLA）という独自のアテンション機構を採用しています。MLAは、従来のMulti-head Attentionで必要だったKey-Valueキャッシュのメモリ消費量を圧縮する技術です。具体的には、KV圧縮次元を512に設定することで、128ヘッド分のアテンション情報をコンパクトに保持できる仕組みとなっています。

この技術は長文処理において特に威力を発揮します。128Kトークンのコンテキスト長を持つRakuten AI 3.0で、たとえば日本語の長大な契約書を全文処理する場合、通常のアテンション機構ではKVキャッシュだけで膨大なGPUメモリを消費します。MLAによるメモリ圧縮があるからこそ、128Kという長いコンテキスト長を実用的なハードウェア構成で実現できているのです。日本語はトークンあたりの情報密度が英語と異なるため、長文処理の安定性はビジネス利用において重要な評価軸となります。

楽天独自のバイリンガルデータ投入が日本語ニュアンス理解に寄与した3つの領域

楽天がDeepSeek V3をベースとして追加学習に用いたのは、同社が長年蓄積してきた高品質なバイリンガルデータです。楽天グループはECプラットフォーム、金融サービス、モバイル通信、旅行予約など多岐にわたる事業を展開しており、これらのサービスから得られるデータは日本語の実用的な表現を豊富に含んでいます。

このバイリンガルデータが特に効果を発揮したと考えられる領域は3つあります。第一に、日本固有の商慣習や敬語表現を正確に理解する能力です。ビジネスメールの定型表現から微妙なニュアンスの違いまで、実際の商取引データから学習したことで精度が向上しています。第二に、日本の歴史・文化に関する知識の深化です。JamC-QAベンチマークで76.9点という高スコアは、この領域での追加学習の成果を示唆しています。第三に、日本語と英語の対訳精度の向上です。楽天のグローバル展開に伴う日英バイリンガルデータが、翻訳や多言語タスクの品質改善に貢献していると考えられます。

同規模のフルパラメータモデルと比較した場合のGPUメモリ消費量と推論速度の差

MoEモデルとDense（フルパラメータ）モデルの効率差は、運用コストに直結する重要な比較軸です。仮に671BパラメータのDenseモデルが存在した場合、FP8精度でもモデル重みだけで約671GBのGPUメモリが必要になります。一方、MoEモデルでは全パラメータをメモリに載せる必要があるものの、推論時に活性化するのは37B相当分のみです。計算量としてはDense 37Bモデル相当で済むため、推論速度は大幅に速くなります。

ただし注意すべき点があります。MoEモデルはパラメータ全体をメモリに保持する必要があるため、メモリ使用量自体は671B規模のままです。FP8量子化を適用しても、モデル重みだけでおおむね670GB前後のVRAMが必要となります。これが8GPU並列構成を前提とする理由であり、1GPUあたり約80GB以上のVRAMが求められる計算です。計算速度は37B Dense相当でも、メモリ確保は671B分が必要という非対称性を理解しておくことが、導入判断において不可欠な視点です。

JamC-QAからM-IFEvalまで4指標で示されたGPT-4o超えの根拠と評価条件の注意点

楽天はRakuten AI 3.0の性能を4つの日本語ベンチマークで評価し、いずれにおいてもGPT-4oを上回るスコアを達成したと発表しています。JamC-QA（日本文化・歴史QA）、MMLU-ProX（大学院レベル推論）、MCLM MATH-100（競技数学、以下MATH-100）、M-IFEval（指示追従能力）の4指標は、それぞれ異なる能力を測るものです。本章では各指標の意味と、スコアを解釈するうえでの注意点を検討します。

JamC-QA 76.9点が示す日本固有の文化・歴史知識における正答率の具体的な強み

JamC-QAは日本固有の文化的知識や歴史に関する質問応答ベンチマークで、2025年に自然言語処理学会の年次大会で発表されたものです。Rakuten AI 3.0はこのベンチマークで76.9点を記録し、GPT-4oの74.7点を約2ポイント上回りました。日本の地域行事や伝統芸能、歴史的事象に関する問いに対して、より正確な回答を返せることがこのスコアに反映されています。

この2ポイントの差は数字上は小さく見えるかもしれませんが、日本語特化モデルとしての意義は大きいといえます。GPT-4oは世界中の知識を広くカバーする汎用モデルであり、日本文化に特化した学習を受けていないにもかかわらず74.7点という高い正答率を示しています。そこからさらに上回るには、日本の文化的文脈を深く理解した追加データが不可欠です。楽天が投入した独自のバイリンガルデータが、まさにこの領域で効果を発揮したことを示す結果といえるでしょう。ただし、このベンチマーク自体がまだ新しく、評価対象の問題数や分野の偏りについても今後の検証が必要です。

MMLU-ProX日本語71.7点で大学院レベル推論をGPT-4oの64.9点と分けた差の要因

MMLU-ProXは大学院レベルの知識と推論力を問うベンチマークを日本語に拡張したものです。Rakuten AI 3.0は71.7点を記録し、GPT-4oの64.9点に対して約7ポイントのリードを見せました。この差は4指標の中でも顕著であり、高度な推論タスクにおける強みを示しています。

このスコア差の背景として、ベースモデルであるDeepSeek V3自体の推論能力の高さが挙げられます。DeepSeek V3は英語ベースのMMLU-Proでも高い成績を収めており、その推論基盤の上に日本語データで追加学習を施したことで、日本語での推論力がさらに強化されたと考えるのが自然です。一方、GPT-4oは汎用性を重視した設計であり、日本語での専門的な推論に特化した最適化は相対的に弱い可能性があります。ただし、MMLU-ProXの日本語版は翻訳品質によってスコアが左右される側面もあるため、スコア差のすべてがモデル性能の差に帰結するわけではない点には留意が必要です。

MATH-100日本語86.9点が競技数学分野で突出した背景にあるDeepSeek V3譲りの数学力

4つのベンチマークの中で最もスコアが高かったのがMATH-100の86.9点です。MATH-100は競技レベルの数学問題を100問集めたベンチマークであり、高度な数式処理と論理的推論の両方が求められます。この突出したスコアは、Rakuten AI 3.0がDeepSeek V3をベースとしていることの強力な証左となっています。

DeepSeek社はもともと数学・コーディング分野に強いモデル開発を得意としており、DeepSeek-Proverシリーズなど数学証明に特化したモデルも発表しています。DeepSeek V3はそうした技術的蓄積の上に構築されたモデルであり、数学的推論能力は同規模帯のオープンソースモデルの中でもトップクラスです。Rakuten AI 3.0がこの数学力を受け継いでいることは、ベースモデルの選択が性能に直結する好例といえます。日本語での数学問題を扱う場合でも、計算ロジック自体は言語に依存しにくいため、ベースモデルの数学力がそのまま活きる構造です。

M-IFEval 72.1点の指示追従能力がビジネス用途で意味する実務的な信頼度の目安

M-IFEvalは多言語環境での指示追従能力を測るベンチマークで、モデルが与えられた指示にどれだけ正確に従えるかを評価します。Rakuten AI 3.0はこの指標で72.1点を獲得しました。指示追従能力は、ビジネス用途でのAI活用において最も実務に直結する指標のひとつです。

たとえば「300文字以内で要約してください」「箇条書き5項目で整理してください」「です・ます調で書き直してください」といったフォーマット指定付きの指示に対し、72.1点は約7割の場面で指示通りの出力が得られることを意味します。裏を返せば、約3割のケースでは指示からの逸脱が生じうるということです。ビジネスでの本格運用においては、出力に対する人間のレビュー工程を完全に省略できるレベルには至っていないといえます。とはいえ、GPT-4oの同指標スコアと比較して上回っている点は、日本語の指示理解において一定の優位性があることを裏付けています。

評価プロンプト設計やfew-shot条件の違いがスコア再現性に影響する点への注意喚起

ベンチマークスコアを他モデルと比較する際には、評価条件の違いに細心の注意を払う必要があります。楽天が公開した比較表では、Rakuten AI 3.0のスコアと並んでGPT-OSS-Swallow-120B-RL-v0.1のスコアが掲載されていますが、たとえばMATH-100においてSwallowモデルは楽天の評価環境で70.5点を記録した一方、開発チーム独自の評価環境では約97点という大幅に高いスコアが報告されています。

この乖離はモデルの性能差ではなく、評価時のプロンプト設計、few-shot例の有無や数、正解判定のロジックといった条件の違いから生じるものです。特に数学問題では、解答の最終値だけを判定するか途中過程も評価するか、数値のフォーマットをどこまで許容するかといった判定基準の差がスコアに大きく影響します。したがって、楽天が公開した比較表はあくまで「楽天の評価環境における相対比較」として解釈すべきであり、各モデルの絶対的な優劣を決定づけるものではありません。導入を検討する際には、自社のタスクに即した独自の評価を実施することが不可欠です。

config.jsonで判明したDeepSeek V3問題とベースモデル開示をめぐる業界の論点

Rakuten AI 3.0の公開直後、技術者コミュニティで最も注目を集めたのはモデルの性能そのものではなく、ベースモデルの出自に関する情報開示の問題でした。Hugging Faceリポジトリに含まれる技術的な設定ファイルからDeepSeek V3との密接な関係が明らかになり、SNSや技術ブログで活発な議論が展開されています。本章では、一連の経緯と業界が直面する透明性の課題を整理します。

Hugging Faceリポジトリのconfig.jsonに残った「model_type: deepseek_v3」発覚の経緯

Rakuten AI 3.0が2026年3月17日にHugging Faceで公開された直後、X（旧Twitter）上の技術者たちがリポジトリの中身を精査し始めました。その過程でconfig.jsonファイル内に「model_type”: “deepseek_v3」という記述が発見され、瞬く間に拡散されています。config.jsonはモデルのアーキテクチャや設定を定義するファイルであり、model_typeフィールドはモデルの基盤構造を示す最も基本的な情報のひとつです。

さらに、パラメータ構成が671B総パラメータ・37Bアクティブパラメータ・MoE構造という点でDeepSeek V3と完全に一致することも確認されました。加えてリポジトリのタグにも「deepseek_v3」が含まれており、技術的な痕跡が複数箇所に残っていた状態です。これらの情報を総合すると、Rakuten AI 3.0がDeepSeek V3をベースモデルとして構築されていることは疑いの余地がなく、議論の焦点は「使ったこと」ではなく「それをどう説明したか」へと移行しました。

NOTICEファイルに追記されたDeepSeek著作権表示とMIT・Apache 2.0ライセンス併存の意味

ベースモデル問題が指摘された後、楽天のHugging Faceリポジトリに「NOTICE」というファイルが追加されました。このファイルのコミットメッセージは「Add the permission notice」とされており、その内容にはMITライセンスの条文とともに「Copyright (c) 2023 DeepSeek」という著作権表示が記載されています。

この追記は、ベースモデルであるDeepSeek V3のコードリポジトリがMITライセンスで公開されていることに対応するものと解釈できます。Rakuten AI 3.0自体はApache 2.0ライセンスで提供されていますが、ベースモデルのMITライセンス条件も遵守する必要があるため、NOTICEファイルとして帰属表示を追加した形です。技術的にはApache 2.0とMITの両ライセンスは商用利用・改変・再配布を広く認める寛容なライセンスであり、利用者にとって実質的な制約の違いはほぼありません。ただし、Apache 2.0には特許権の明示的な付与条項が含まれるという構造上の相違があるため、派生開発を行う際にはこの点を確認しておく必要があります。

Rakuten AI 7BがMistral-7Bベースを明示した前例と今回の曖昧な表記を比較した違和感

今回の議論が拡大した理由のひとつとして、楽天自身の過去の対応との比較が挙げられます。Rakuten AI 7Bのリリース時、楽天はモデルカード上で「Mistral-7Bをベースにした」と明確に記載していました。ベースモデルの出自を隠さず開示した姿勢は、オープンソースコミュニティの慣行に則ったものとして好意的に受け止められています。

ところがRakuten AI 3.0では、プレスリリースやモデルカードにおいて「オープンソースコミュニティ上の最良なモデルを基に」という曖昧な表現にとどまり、DeepSeek V3という具体名は記載されていませんでした。この変化に対して「前回は正直に書いていたのに、今回はなぜ隠したのか」という疑問が技術者コミュニティから提起されています。背景として、DeepSeek V3が中国企業のモデルであることへの配慮や、GENIACの「国産AI開発支援」という文脈でのブランディング上の判断があった可能性が推測されていますが、楽天から公式の説明は出されていません。

GENIAC公的資金が絡む場面で「国産AI」を名乗る際に求められる透明性の水準

今回の議論で特に厳しい目が向けられたのは、GENIACという公的支援の文脈です。GENIACは日本国内の生成AI開発力強化を目的とした国家プロジェクトであり、採択企業には計算資源や資金の補助が提供されます。楽天のプレスリリースでは「国内最大規模の高性能AIモデル」というフレーズが前面に出ており、報道各社も「国産AI」という文脈で取り上げました。

しかし実態としてはベースモデルが中国企業のDeepSeek V3であったことから、「公的資金で海外モデルのファインチューニングを行い、それを国産AIと称するのは適切か」という問いが浮上しています。技術的に見れば、オープンソースモデルを基盤に追加学習で特化性能を高める手法は業界で広く行われているものであり、楽天の開発アプローチ自体は合理的です。問題の本質は手法そのものではなく、情報開示の姿勢にあります。公的資金が投入されたプロジェクトにおいては、何をベースにし、どこに独自の付加価値があるのかを明確に説明する責任がより強く求められるという点で、今回の事例は業界全体への示唆を含んでいます。

オープンモデルを基盤に追加学習する開発手法自体は業界標準である点の正しい理解

一連の論争を正しく理解するためには、AI開発における業界全体の傾向を把握しておく必要があります。現在のLLM開発では、巨大なベースモデルをゼロから事前学習できる企業は世界的にも限られています。OpenAI、Google、Anthropic、Meta、DeepSeekといったごく少数の企業だけがそれを実行できる計算資源を持ち、多くの企業や研究機関はオープンソースモデルを基盤に追加学習を施す形で独自モデルを開発しています。

日本国内でもこの傾向は同様です。GPT-OSS-Swallow-120B-RL-v0.1はOpenAIが公開したgpt-oss-120bをベースに日本語強化を施したモデルですし、多くの国産LLMがLlama、Mistral、Qwenなど海外のオープンモデルを基盤としています。つまり、楽天がDeepSeek V3をベースとしたこと自体は技術的に何ら問題のない標準的なアプローチです。重要なのは、その事実を率直に開示し、自社がどの部分で付加価値を生み出したかを明確にすることです。透明性のある情報開示は、技術コミュニティからの信頼獲得と健全なオープンソースエコシステムの維持に不可欠な要素といえるでしょう。

Swallow・Stockmark・ABEJAとの横並び比較で見えるRakuten AI 3.0の競争優位と弱点

Rakuten AI 3.0は国内最大規模のモデルとして登場しましたが、日本語に特化したオープンモデルはほかにも複数存在します。楽天が公開した比較表に含まれるGPT-OSS-Swallow、Stockmark、ABEJAの各モデルとの性能差を整理し、それぞれの得意領域とRakuten AI 3.0の立ち位置を検証します。

GPT-OSS-Swallow-120B-RL-v0.1との4ベンチマーク比較で10ポイント以上開いた項目の分析

楽天の公開した比較表において、GPT-OSS-Swallow-120B-RL-v0.1はJamC-QAで63.0点、MMLU-ProXで63.0点、MATH-100で70.5点、M-IFEvalで69.5点というスコアが示されています。Rakuten AI 3.0との差はJamC-QAで約14ポイント、MMLU-ProXで約9ポイント、MATH-100で約16ポイント、M-IFEvalで約3ポイントとなり、特にJamC-QAとMATH-100で大きな差が開いています。

ただし、この差をそのままモデルの優劣として受け取るのは早計です。GPT-OSS-Swallowの開発チームが独自に実施した評価では、MATH-100で約97点というRakuten AI 3.0をはるかに上回るスコアが報告されています。この乖離は評価環境の違いに起因するものであり、プロンプト設計やfew-shot条件、正解判定ロジックが異なると同一モデルでもスコアが大きく変動することを端的に示しています。したがって比較表の数字は参考値として扱い、実際の導入判断では自社の利用シナリオに合わせた独自評価を行うことが重要です。

Stockmark-2-100B-Instructが得意とする企業文書処理領域でのスコア差と用途の違い

Stockmark-2-100B-Instructは、ストックマーク社が開発した約1,000億パラメータの日本語特化モデルです。楽天の比較表では4つのベンチマークすべてでRakuten AI 3.0を下回るスコアが示されていますが、このモデルの本来の強みはビジネス文書や産業レポートの処理にあります。Stockmarkは企業向けの情報分析プラットフォームを主力事業としており、そのデータ資産を活かしたモデル設計が特徴です。

Rakuten AI 3.0との比較においては、パラメータ規模の差（671B対100B）を考慮する必要があります。100Bパラメータ規模のDenseモデルは、推論に必要な計算リソースが大幅に少なく、導入のハードルが低いというメリットがあります。企業文書の分類や要約といった定型的なタスクであれば、必ずしも671B規模のMoEモデルが最適とは限りません。タスクの複雑さと運用コストのバランスを考慮して選択すべきであり、両モデルは直接競合というよりも用途に応じた棲み分けの関係にあるといえるでしょう。

ABEJA-QwQ32b-Reasoning-Japanese-v1.0の推論特化設計と総合力の差が出る場面

ABEJA-QwQ32b-Reasoning-Japanese-v1.0は、ABEJA社がQwen2.5-32B-Instructをベースに日本語継続事前学習を施したモデルへ、QwQ-32BのChatVectorをマージして推論能力を付与した約320億パラメータのモデルです。パラメータ数はRakuten AI 3.0の20分の1以下ですが、推論タスクに特化した設計により特定のベンチマークで高いスコアを示す場合があります。

このモデルの特徴は、限られたパラメータ数で推論力を最大化するアプローチにあります。ファインチューニング済みモデルに対してChatVectorマージと追加学習を組み合わせることで、数学的推論や論理的思考において大規模モデルに匹敵する性能を引き出す設計思想です。一方で、32Bパラメータという規模では保持できる知識量に限界があるため、JamC-QAのような幅広い知識を要する問いではRakuten AI 3.0に及ばない可能性が高くなります。推論力と知識量のどちらを重視するかによって、最適な選択は変わってきます。実務において数学的処理や論理判断が中心であればABEJAモデルのコストパフォーマンスは高く、幅広いタスクに1つのモデルで対応したいのであればRakuten AI 3.0が有利です。

パラメータ規模671B対120B・100B・32Bという非対称比較が持つフェアネスの限界

楽天が公開した比較表を見る際に意識すべき最大の前提条件は、モデル間のパラメータ規模が大きく異なるという点です。Rakuten AI 3.0は671Bパラメータ（活性化37B）であるのに対し、GPT-OSS-Swallowは120B、Stockmarkは100B、ABEJAは32Bと、規模に数倍から20倍以上の差があります。一般的に、パラメータ規模が大きいモデルほどベンチマークスコアが高くなる傾向があるため、この比較で上回るのはある意味当然ともいえます。

より公正な比較を行うためには、パラメータあたりの性能効率や、同等の計算コストで達成できるスコアといった指標が必要です。たとえばABEJAの32BモデルがRakuten AI 3.0のスコアの80%を20分の1の計算リソースで達成できるとすれば、コストパフォーマンスではABEJAが優位ということになります。楽天の比較表にはこうした効率指標が含まれていないため、絶対スコアだけでモデルの優劣を判断するのは適切ではありません。導入検討時には、自社が確保できるGPUリソースの制約を踏まえた上で、実現可能な構成の中から最適なモデルを選択する視点が求められます。

評価環境の差でMATH-100が70.5点対約97点まで乖離した事例が教える比較表の読み方

ベンチマーク比較の信頼性を考えるうえで、GPT-OSS-Swallow-120B-RL-v0.1のMATH-100スコアが楽天の評価では70.5点、開発チームの評価では約97点と大幅に異なった事例は極めて示唆的です。同一のモデルに対してこれほどの差が生じるということは、評価条件がスコアに与える影響の大きさを物語っています。

スコア乖離の具体的な原因としては、まずプロンプトテンプレートの違いが考えられます。問題文の提示方法やシステムプロンプトの有無によって、モデルの回答品質は大きく変動します。次にfew-shot例の数と質です。数学問題の場合、適切なfew-shot例を与えることで正答率が劇的に向上する場合があります。さらに正解判定の基準も重要です。最終解のみを評価するか、途中式の正確さも加味するか、数値のフォーマット（分数・小数・LaTeX表記）をどこまで同一視するかで結果は変わります。こうした事実を踏まえると、公開された比較表は参考情報のひとつとして活用しつつ、最終判断は自社で再現可能な評価に基づいて行うべきです。

Apache 2.0ライセンスとGENIAC補助が企業導入コストに与える実務上のメリット

Rakuten AI 3.0の導入を検討する企業にとって、ライセンス条件と費用構造は性能と並ぶ重要な判断材料です。Apache 2.0ライセンスによる商用利用の自由度と、GENIACプロジェクトの補助が開発コストに与えた影響を踏まえ、実際の運用で発生するコストの全体像を把握します。

Apache 2.0の特許付与条項がMITライセンスにはない商用利用時の法的安心材料になる理由

Rakuten AI 3.0はApache 2.0ライセンスで公開されており、商用利用・改変・再配布が広く認められています。Apache 2.0の特徴的な条項のひとつが、明示的な特許権の付与です。MITライセンスでは特許に関する規定が存在しないため、モデルの利用が第三者の特許を侵害した場合の法的リスクが曖昧なままとなります。Apache 2.0ではコントリビューターが保有する特許のうち、そのソフトウェアの利用に必要なものについて利用者に自動的にライセンスが付与されます。

これは企業がRakuten AI 3.0を自社サービスに組み込む際の法的な安心材料となります。とくにAI技術は特許の対象範囲が広く、モデルのアーキテクチャや推論手法に関連する特許が存在する場合、ライセンス条件によっては意図しない権利侵害のリスクが生じます。Apache 2.0の特許付与条項はこのリスクを軽減する役割を果たしており、法務部門のある企業にとっては採用のハードルを下げる要素です。ただし、ベースモデルのDeepSeek V3はMITライセンスで公開されているため、NOTICEファイルの帰属表示との関係を社内で確認しておくことが望ましいでしょう。

モデル本体を自社サーバーに配置しAPIコストゼロで運用する場合の初期構成と費用試算

Rakuten AI 3.0をオンプレミスで運用する場合、モデル本体のダウンロードと利用自体は無償です。しかし、671BパラメータのMoEモデルを動かすためのハードウェアコストは無視できません。FP8量子化を前提としても、モデル重みの格納だけでおおむね670GB前後のVRAMが必要となります。

推奨構成であるtp8（テンソル並列数8）で運用する場合、NVIDIA H100（80GB VRAM）またはA100（80GB VRAM）を最低8基搭載したサーバーが必要です。H100搭載のDGXサーバーを1台購入する場合、2026年時点での市場価格は数千万円規模となります。クラウドで同等の構成を利用する場合、主要クラウドプロバイダのH100インスタンス8基相当の時間単価は1時間あたり数万円程度です。月間稼働時間を720時間（常時稼働）とすると、月額コストは数百万円から1,000万円超に達する可能性があります。APIコストはゼロでも、インフラコストが相当額になる点を初期段階から計画に組み込む必要があります。

Rakuten AIゲートウェイのAPI経由で利用する際の料金体系と月10万文字制限の注意点

自社でGPUサーバーを用意できない場合の選択肢として、楽天が提供するRakuten AIゲートウェイのAPI経由での利用があります。開発者向けプラットフォームとしてAPIが公開されており、実験・開発・本番運用に必要な機能が一通り整備されています。また、Webアプリ版（ai.rakuten.com）はベータ版として現時点では無料で利用可能です。

法人向けの「Rakuten AI for Business」は有料プランとなっており、一部報道によれば2026年3月に料金体系が改定されたとされています。1ユーザーあたり月間10万文字程度の利用上限が設けられているとの情報がありますが、最新の正確な条件は楽天の公式サイトで確認する必要があります。仮にこの水準の制限が適用される場合、日常的なメール下書きや短い文書の作成であれば十分ですが、大量の文書解析や長文生成を業務フローに組み込むには制約となりえます。利用量が多い企業は、オンプレミス運用とAPI利用のコスト比較を早い段階で行うことが推奨されます。

GENIAC第3期の補助スキームが楽天の開発原価を下げた構造と利用者への波及効果

GENIACプロジェクトからの補助は、Rakuten AI 3.0の学習費用の一部をカバーしています。具体的な補助金額は公開されていませんが、671B規模のモデルの追加学習に必要な計算リソースのコストを考えると、相当額の支援が行われたと推察されます。この公的補助がなければ、楽天がApache 2.0ライセンスでモデルを無償公開するという判断に至ったかどうかは不明です。

利用者にとっての波及効果は、国内最大級のオープンソース日本語モデルが無償で手に入るという直接的なメリットです。通常、同規模のモデルをAPI経由で利用する場合には相応の従量課金が発生します。モデル本体をダウンロードして自社環境で動かせることで、APIの従量課金に縛られず、処理量に応じた柔軟な運用が可能になります。GENIACの目的である「国内AI開発力の強化」という観点からは、楽天だけでなくエコシステム全体にメリットが波及する構造となっており、公的支援の成果が広く共有されている点は評価に値するでしょう。

クローズドモデルAPI利用と比較した年間ランニングコスト差のシミュレーション例

Rakuten AI 3.0のオンプレミス運用とクローズドモデルのAPI利用を比較するために、具体的なシミュレーションを試みます。月間100万トークンの処理を想定した場合、GPT-4oのAPI利用料はインプット・アウトプットの合計でおおむね数万円から数十万円程度です。一方、月間1,000万トークン以上の大量処理が必要な場合、API従量課金は月額数十万円から百万円規模に膨らむ可能性があります。

上記の通り、処理量が少ない段階ではAPI利用のほうが圧倒的にコスト効率が高くなります。オンプレミス運用がコスト面で有利になるのは、月間処理量が数百万トークンを超え、かつデータの外部送信を避けたい要件がある場合です。導入判断においては、現在の処理量だけでなく将来的な拡張計画も含めた中長期のコスト試算が欠かせません。

楽天サービス連携から自社デプロイまで想定される具体的な業務活用シナリオ

Rakuten AI 3.0の性能を実務に活かすためには、自社の業務課題に適した活用シナリオを明確にする必要があります。楽天自身が推進するEC連携から、一般企業が自社サーバーにデプロイして利用するケースまで、想定される活用の幅を具体的に整理します。

楽天市場アプリ搭載のRakuten AIチャットによる商品検索活用が示すEC連携の方向性

楽天は2026年に入り、楽天市場のスマートフォンアプリにチャットAI「Rakuten AI」を搭載しました。ユーザーはAIとの対話を通じて商品を検索できるようになっており、Rakuten AI 3.0の技術がこのサービスに活用されているとみられます。従来のキーワード検索では意図通りの商品に到達しにくかった場合でも、自然言語で「予算5,000円以内で母の日に贈れる和菓子」のように条件を伝えることで、AIが最適な商品を提案する仕組みです。

この活用事例はEC領域でのLLM導入の方向性を端的に示しています。日本語特化モデルならではの強みが活きるのは、敬語や曖昧な表現を含む顧客の要望を正確に解釈する場面です。たとえば「ちょっと高級感のあるもの」という表現から価格帯やブランドイメージを推定し、適切な商品カテゴリに絞り込む処理は、日本語のニュアンスを深く理解したモデルでなければ精度が上がりません。楽天のEC連携はRakuten AI 3.0の実用性を検証する最大のテストケースであり、この成否が他企業への導入拡大にも影響を与えるでしょう。

日本語の契約書・社内規程を対象とした文書解析と要点抽出での精度向上が見込める業務

128Kトークンのコンテキスト長を持つRakuten AI 3.0は、長大な日本語文書の解析に適した設計となっています。企業が日常的に扱う契約書、就業規則、取引基本約款、各種ポリシー文書といった長文ドキュメントを全文投入し、要点の抽出や条項間の矛盾検出を行うタスクが想定されます。

従来のクローズドモデルAPIを使って同様の文書解析を行う場合、機密性の高い契約文書を外部サーバーに送信するという情報管理上の懸念がありました。Rakuten AI 3.0をオンプレミスで運用すれば、文書データが社外に出ることなく解析処理を完結させることが可能です。日本語の法律文書特有の回りくどい表現や二重否定、条件分岐の複雑な構造を正確に解析するには、日本語に特化した追加学習の効果が期待されます。ただし、法的判断を伴う業務においてはAIの出力を最終判断とせず、人間の専門家によるレビューを組み合わせた運用が不可欠です。

カスタマーサポート自動応答に導入する場合の日本語敬語処理と回答品質の検証ポイント

カスタマーサポートへのLLM導入は、多くの企業が検討している活用シナリオのひとつです。Rakuten AI 3.0を問い合わせ対応の自動応答に利用する場合、日本語の敬語処理が品質を左右する最重要の検証ポイントとなります。「です・ます調」の統一、尊敬語と謙譲語の適切な使い分け、クッション言葉の挿入といった要素が、顧客満足度に直接影響を与えるためです。

検証すべき観点は大きく3つあります。第一に、問い合わせの意図を正確に把握できるかどうかです。日本語の問い合わせでは遠回しな表現や含みのある言い方が多用されるため、表面的なキーワードだけでなく文脈からの意図推定が求められます。第二に、回答のトーンが一貫して丁寧であるかどうかです。途中で語調が崩れたり、不自然な敬語が混入したりすると信頼性が損なわれます。第三に、回答の正確性と安全性です。誤った情報を自信満々に返す「ハルシネーション」のリスクは依然として存在するため、ファクトチェックの仕組みをバックエンドに組み込む設計が必要です。

コード生成タスクでPython・JavaScript対応を実務検証する際の3つの評価観点

Rakuten AI 3.0は文書処理だけでなくコード生成にも対応しています。DeepSeek V3がコーディング分野で高い性能を持つことから、その能力を受け継いだRakuten AI 3.0もPythonやJavaScriptを中心としたコード生成で一定の品質が期待されます。しかし、実務で使えるレベルかどうかは独自に検証する必要があります。

検証すべき評価観点は3つです。まず、生成されたコードの構文的正確性です。実行可能なコードが生成されるか、構文エラーの頻度はどの程度かを確認します。次に、日本語によるコメントや関数名の指示に対する追従性です。たとえば「ユーザー一覧を取得する関数を作成してください」という日本語指示に対し、適切な命名と構造のコードが生成されるかを見ます。最後に、日本固有のライブラリやフレームワークへの対応力です。国内で広く使われるライブラリ（たとえばMeCab、Janomeなどの形態素解析器）を組み込んだコードを正しく生成できるかどうかは、日本語特化モデルならではの検証ポイントといえるでしょう。

sglangサーバー構成でローカルデプロイする場合のDockerイメージとtp8設定の手順概要

Rakuten AI 3.0をローカル環境にデプロイする際の推奨構成として、モデルカードにはsglangフレームワークを使用した起動方法が記載されています。推奨Dockerイメージはlmsysorg/sglang:v0.5.6.post2であり、テンソル並列数tp8での起動が標準とされています。

1. Dockerイメージをプルする：推奨イメージをDocker Hubから取得します
2. モデル重みをダウンロードする：Hugging Faceの楽天公式リポジトリからモデルファイルを取得します
3. sglangサーバーを起動する：python -m sglang.launch_server --model-path Rakuten/RakutenAI-3.0 --tp 8 --mem-fraction-static 0.85 --trust-remote-code --show-time-cost のコマンドでサーバーを立ち上げます
4. APIエンドポイントを確認する：起動後、ローカルホスト上にAPIが公開されるため、テストリクエストを送信して動作を確認します
5. 負荷テストを実施する：実際の想定処理量でスループットとレイテンシを計測し、本番運用の可否を判断します

tp8の設定はテンソル並列で8基のGPUにモデルを分割配置する構成を意味し、最低でも8基のGPU（各80GB VRAM推奨）が必要となります。mem-fraction-staticパラメータの0.85は、GPU メモリの85%をモデルの静的割り当てに使用する設定です。残りの15%がKVキャッシュや動的処理用に確保されます。初回起動時にはモデルの読み込みに時間がかかりますが、一度起動すれば継続的にAPIリクエストを受け付ける構成となります。

導入判断前に確認すべき推論コスト・GPU要件・データ安全性のチェックポイント

Rakuten AI 3.0の導入を本格的に検討する段階では、ベンチマークスコアや機能面だけでなく、実際の運用に伴うコスト・ハードウェア要件・安全性の観点から総合的に判断する必要があります。本章では、導入前に確認すべき実務的なチェックポイントを整理します。

671BモデルをFP8で動かすために最低限必要なGPU枚数とVRAM容量の現実的な目安

671BパラメータのMoEモデルをFP8精度で推論するには、モデル重みの格納だけで約670GBのVRAMが必要です。これにKVキャッシュや推論時のワーキングメモリを加えると、実運用では700GB以上のGPUメモリ総量を確保する必要があります。NVIDIA H100（80GB VRAM）を使用する場合、最低8基で合計640GBとなり、mem-fraction-staticを0.85に設定してギリギリ収まる計算です。

余裕を持った運用やバッチ処理への対応を考慮すると、10基以上のGPU構成が現実的な選択肢となります。また、A100（40GB VRAM）を使用する場合は16基以上が必要となり、サーバー構成がさらに大規模になります。クラウド環境ではAWS p5インスタンス（H100×8）やGoogle Cloud A3インスタンスなどが候補となりますが、いずれも高額な利用料金が発生します。中小企業が個別に専用環境を構築するにはハードルが高く、共同利用型のGPUクラウドサービスを活用するか、処理量に応じてAPI利用と使い分けるハイブリッド構成が現実的な選択肢となるでしょう。

推論レイテンシとスループットを本番環境で許容範囲に収めるためのハードウェア選定基準

モデルのデプロイ後に最も重要な運用指標となるのが、推論レイテンシ（応答速度）とスループット（単位時間あたりの処理能力）です。MoEモデルはトークンあたりの活性化パラメータが37Bと比較的小さいため、同規模のDenseモデルに比べて推論速度は速い傾向にあります。しかし、128Kトークンの長いコンテキストを扱う場合はKVキャッシュのサイズが増大し、レイテンシが上昇する可能性があります。

本番環境での許容レイテンシはユースケースによって異なります。チャットボットのようなリアルタイム応答が求められる場面では、最初のトークンが返されるまでのTime to First Token（TTFT）が1秒以内であることが一般的な目安です。一方、バッチ処理による文書解析では数十秒単位のレイテンシでも問題ない場合が多くなります。スループットについては、同時接続ユーザー数やリクエスト頻度から逆算して必要なGPU構成を決定します。sglangフレームワークは連続バッチ処理に対応しており、複数リクエストの並列処理でスループットを向上させることが可能です。本番投入前には想定最大負荷での検証を必ず実施すべきです。

日本語入力データの社外流出リスクをゼロにするオンプレミス運用の設計上の留意点

Rakuten AI 3.0をオンプレミスで運用する最大のメリットのひとつが、データの外部送信を完全に排除できる点です。クローズドモデルのAPIを利用する場合、入力データは必然的にサービス提供者のサーバーを経由します。個人情報や営業秘密を含むデータの処理において、この外部送信リスクは企業のコンプライアンス上の大きな懸念材料です。

オンプレミス環境を構築する際には、以下の設計上の留意点を押さえておく必要があります。

• ネットワーク構成の隔離設計：外部インターネットからの遮断（エアギャップ環境）が理想ですが、モデルの更新やパッチ適用の利便性とのバランスを取る必要があるため、DMZを介した限定的な外部接続を許容するケースも想定されます
• 推論ログの保存・アクセス制御：入力テキストと出力結果を含むログにはユーザーの機密情報が含まれうるため、保存期間の上限設定、暗号化、アクセス権限の最小化を徹底すべきです
• モデル重みファイルの知財保護：671Bパラメータの重みデータは知的資産として高い価値を持つため、不正コピーや外部持ち出しを防止する物理的・論理的なセキュリティ措置が不可欠です

これらの留意点を事前に設計へ組み込むことで、データ流出リスクを限りなくゼロに近づけた運用体制を構築できます。

DeepSeek V3ベースである事実が安全保障やコンプライアンス審査で問われうる論点

Rakuten AI 3.0のベースモデルがDeepSeek V3であるという事実は、特定の業種や用途においてコンプライアンス上の検討事項となりえます。DeepSeek V3は中国企業が開発したモデルであり、学習データの構成や内在するバイアスについて完全な透明性が確保されているとはいえません。一部のユーザーからは、特定の政治的トピックに関してモデルの回答が中国寄りの立場を示すとの指摘もなされています。

官公庁や防衛関連産業、金融機関などセキュリティ要件が厳格な組織では、AI モデルの出自がコンプライアンス審査の対象となる場合があります。ベースモデルの学習データに含まれる可能性のあるバイアスや、特定の話題に対する回答傾向が業務上の問題を引き起こさないかを事前に検証する必要があるでしょう。楽天がファインチューニングによってこうしたバイアスをどの程度軽減しているかは公開されていないため、機密性の高い用途に導入する場合には、自組織で安全性の評価を独自に実施することが強く推奨されます。

今後のアップデート頻度とコミュニティ貢献の見通しから判断する中長期採用リスク

LLMの導入は一時的な判断ではなく、中長期的な視点での評価が求められます。モデルのアップデート頻度、コミュニティの活発さ、開発企業の継続的なコミットメントといった要素が、採用後のリスクに直結するためです。Rakuten AI 3.0は楽天にとって3世代目のAIモデルであり、7B→470B→671Bと着実にスケールアップしてきた実績があります。

一方で、いくつかの不確実性も存在します。まず、次期バージョンの開発計画やアップデート頻度は公開されていません。オープンソースモデルの価値は継続的な改善にあるため、一度公開されたきりアップデートが止まるとユーザーは他のモデルへの移行を迫られます。次に、コミュニティの貢献状況です。Apache 2.0ライセンスで公開されているため、外部の開発者がモデルに手を加えることは技術的に可能ですが、671Bという巨大なモデルを扱える開発者は限られています。最後に、楽天自体のAI戦略の方向性です。楽天はAI-nizationを掲げてAI活用を推進していますが、モデル開発への投資が今後も継続される保証はありません。導入を検討する企業は、モデルの陳腐化リスクと代替モデルへの移行コストも含めた計画を立てておくことが賢明です。