2026年3月に楽天が公開した大規模言語モデル「RakutenAI-3.0」をめぐり、Hugging Face上の公開物から、ベースアーキテクチャがDeepSeek-V3系であることを示す痕跡が確認できます。
モデルカードでは明示的にDeepSeekの名を前面に出していませんが、設定ファイルにはDeepseekV3ForCausalLM、model_type: "deepseek_v3"が記載され、ファイル一覧にはDeepSeek-V3タグが付与されています。さらに、後から追加されたNOTICEファイルには「Copyright (c) 2023 DeepSeek」とMIT系の許諾文が含まれています。少なくとも、楽天AI 3.0がDeepSeek-V3系のコードまたはその派生物を土台にしている可能性は極めて高いと見るべきです。
目次
エグゼクティブ・サマリー
-
Hugging Face上の
config.jsonには、RakutenAI-3.0のアーキテクチャとしてDeepseekV3ForCausalLM、モデル種別としてdeepseek_v3が明記されています。これはDeepSeek公式のDeepSeek-V3系設定と一致します。 -
RakutenAI-3.0の公開リポジトリには、公開後にNOTICEファイルが追加され、その中に「Copyright (c) 2023 DeepSeek」という表示とMIT許諾文が含まれています。これはDeepSeek由来コードの継承を示す有力な証拠となります。
-
671B総パラメータ、37Bアクティブ、128Kコンテキストという主要仕様も、DeepSeek-V3の公開仕様と一致しています。
-
ただし、楽天自身は「オープンソースコミュニティ上の最良なモデルを活用し、自社の高品質な日英バイリンガルデータや研究・エンジニアリングを重ねた」と説明しており、公開情報だけで「単なる名前の付け替え」と断定することはできません。
-
問題の本質は「中国製だから危険」という話ではなく、モデルの出自、ガバナンス、アラインメント、データ取扱い、サプライチェーン透明性をどこまで説明できるかにあります。DeepSeek本体については、データ保護や国家安全保障を理由に各国規制当局の scrutiny を受けていますが、そのリスクの一部はホスト型サービスに固有であり、オープンウェイト派生モデルとは分けて評価すべきです。
まず何が確認できるのか
RakutenAI-3.0のHugging Faceリポジトリを見ると、config.jsonのアーキテクチャ欄にはDeepseekV3ForCausalLM、モデル種別にはdeepseek_v3が記載されています。
これらは、DeepSeek公式のDeepSeek-V3系config.jsonに記載されているアーキテクチャ名・モデル種別と一致します。しかも、Hugging Face上のタグにもdeepseek_v3とDeepSeek-V3が付与されています。これは、単なる性能比較対象としてDeepSeek名が挙がっているのではなく、モデル実装の系譜そのものがDeepSeek-V3系であることを示す強い状況証拠です。
また、RakutenAI-3.0のモデルカードは、総パラメータ671B、トークン当たりの活性パラメータ37B、コンテキスト長128Kと説明しています。一方、DeepSeek-V3公式モデルカードも、同じく671B、37B、128Kを掲げています。アーキテクチャ名だけでなく、主要スペックまで一致している以上、少なくともDeepSeek-V3系の設計を採用している可能性が非常に高いです。
さらに重要なのがNOTICEファイルです。
RakutenAI-3.0のコミット履歴では、モデル本体のアップロード後に「Create NOTICE」「Add the permission notice」というコミットが追加されています。実際のNOTICEファイルには、「Copyright (c) 2023 DeepSeek」とMIT許諾文が記載されています。これはDeepSeek由来のコードやソフトウェア部分を継承していることを自ら示した形です。少なくとも、DeepSeekを利用している関係がある事が分かります
中身はDeepSeekそのもの?
楽天の公式リリースとモデルカードは、RakutenAI-3.0を「オープンソースコミュニティ上の最良なモデルを活用し、楽天の高品質な日英バイリンガル独自データ、エンジニアリング、研究を重ねて開発した」と説明しています。
公開情報から言えるのは、RakutenAI-3.0がDeepSeek-V3系アーキテクチャまたはその派生コードをベースにしている可能性が極めて高いということまでで、重みがバイト単位で同一か、追加学習や再調整がどの程度行われたかまでは断定できません。
逆に言えば、楽天側が国産・独自性を強調するのであれば、利用者や企業が知りたいのは、どのベースモデルを使い、どの層を変更し、どのデータで追加学習し、どのアラインメント調整を行ったのかです。現状のモデルカードはその説明が薄く、Hugging Faceの設定ファイルとNOTICEの方が、むしろ出自を雄弁に語っている状態です。これは技術的な問題であると同時に、開示姿勢の問題でもあります。
DeepSeekの危険性
DeepSeekのリスクは大きく三つに分けて考える必要があります。第一はデータ保護と越境移転、第二はサービス運用とセキュリティ管理の脆弱さ、第三は悪意ある利用に対するガードレールの弱さです。
データ保護と越境移転のリスク
最も重いのは、DeepSeek本体のサービスを利用した場合のデータ統制リスクです。韓国の個人情報保護委員会は2025年4月、DeepSeekが韓国内でサービス提供していた時期に、ユーザー情報とプロンプト内容を同意なく中国・米国の企業へ移転していたと公表しました。
加えて、Feroot SecurityはDeepSeekの一部コードを分析し、China Mobile系サイト「CMPassport.com」へのデータ送信能力がある隠しコードを発見したと主張しています。
関連:DeepSeek(ディープシーク)とは?何がすごい?セキュリティの懸念を解説
サービス運用とセキュリティ管理の脆弱さ
DeepSeekの危険性は、データ移転の問題だけではありません。
Wizは2025年1月、DeepSeekに関連する認証なしで外部から到達可能なClickHouseデータベースを発見し、そこから100万件超のログ、チャット履歴、APIシークレット、バックエンド情報にアクセス可能だったと公表しました。
ガードレールの弱さと悪用耐性の低さ
第三のリスクは、悪意あるプロンプトに対する耐性の弱さです。KELAのレッドチームは、DeepSeekが脱獄プロンプトによりマルウェア作成、危険行為、違法行為に関する詳細な手順やコード片を生成したと報告しています。Palo Alto NetworksのUnit 42も、DeepSeekに対して複数の単発・多段階の脱獄手法を試し、マルウェア生成や悪性スクリプト、危険行為の指示に対して脆弱性があると評価しました。
この種の弱さは、単なる評判リスクでは終わりません。企業内でコーディング補助や検索支援に利用した場合、不適切なコード、危険な手順、機密に関する誤った案内が自然言語で出力される危険があります。
各国政府が警戒している
こうした懸念を受け、DeepSeek本体の利用を政府端末で制限・禁止する動きは各国に広がりました。オーストラリアは2025年2月、DeepSeekを政府端末から全面的に排除し、「国家安全保障上受け入れがたいリスク」と位置付けました。その後も、イタリアのブロック、ドイツ当局によるアプリ削除要請など、各国規制当局の監視強化を報じています。
日本の省庁や鳥取県や三重県など自治体レベルでも利用回避・制限の流れが続いています
RakutenAI 3.0のようなDeepSeek由来OSSも危険なのか
RakutenAI 3.0のように、DeepSeek-V3系アーキテクチャまたはその派生コードをベースにしたオープンウェイトモデルを自社環境で動かす場合、DeepSeek本体のアプリやクラウドサービスに伴うデータ移転リスクが、そのまま自動継承されるわけではありません。
オンプレミスや閉域環境で推論し、外部APIへ送らないのであれば、少なくとも「入力内容がDeepSeek運営側へ送信される」型のリスクは別問題です。したがって、RakutenAI 3.0を評価する際に、DeepSeek本体アプリのデータ越境問題をそのまま当てはめるのは不正確です。
ただし、危険性が消えるわけではありません。
RakutenAI 3.0のような派生モデルで残るのは、
①ベースモデル由来のアラインメントやガードレールの弱さ、
②モデル供給網とライセンス継承の不透明さ、
③運用時のリモートコード実行や依存ライブラリを含むソフトウェア・サプライチェーンのリスクです。
特に、ベースがDeepSeek-V3系である以上、政治・安全保障・攻撃手法・違法行為に関する応答傾向がどこまで残るのかは、自社でレッドチーム評価しない限り分かりません。
つまり、RakutenAI 3.0のようなモデルは「中国へデータが送られるから危険」ではなく、出自・統制・安全性評価が甘いまま導入すると危険だと捉えるべきです。








