「独自開発」の LLM が実は merge だった — Rio のモデル出自を運用者目線で読む

まず結論 — 「独自開発」は信じる対象ではなく、運用者が検証する対象

結論から書きます。モデルに貼られた「独自開発」というラベルは、運用者にとって出発点であって到達点ではありません。出自（provenance、そのモデルがどこから来たか）は、こちらで確かめられる形になっていて初めて意味を持ちます。

2026 年、リオデジャネイロ市（prefeitura-rio / IplanRIO）が公表した Rio-3.5-Open-397B という 397B（3970 億パラメータ）のモデルが、実態は既存モデルの merge（マージ、複数モデルの重みを混ぜて 1 つにする手法）ではないかと、Nex-AGI が出した GitHub issue で指摘されました。指摘の中身は次の章で詳しく見ますが、運用者が持ち帰るべき一点は単純です。「自前で訓練した」という主張は、第三者が再現・検証できる証拠とセットでなければ、調達の判断材料にしてはいけない。

私はこの一件を、社内で使うモデルを選ぶ評価作業の一場面として読みました。モデルカードに並ぶ「独自」「from scratch」という言葉は、調達側が一番見たい言葉です。だからこそ、その言葉に一番疑いを向ける必要があります。

何が起きたのか — system prompt を外したら別の名前を名乗った

指摘の核心は、Rio から system prompt を外すと、モデルが自分を「Rio」ではなく「Nex」だと名乗ったことです。振る舞いと重みの両面から、独立して訓練した痕跡が見当たらない、というのが Nex-AGI の主張でした。

数字が生々しいです。system prompt（モデルに役割を与える前置きの指示）を取り除くと、Rio は 79% の確率で「Nex-AGI の Nex です」と自己同定し、「Rio」と名乗った割合は 0% でした。しかも Nex-AGI が自社モデルに仕込んだ作り話の経歴を、そのまま暗唱したといいます。さらに重みの解析では、Rio の全テンソル（weight tensor、層ごとの重み行列）が、60 層すべてにわたって Nex と Qwen3.5-397B を約 0.6 対 0.4 で混ぜた値に、「標準偏差の数千倍」の精度で一致したと報告されています。これは fine-tuning（追加学習）では起きない、線形な内挿（interpolation）の指紋です。追加学習なら層ごとに変化の濃淡が出ますが、全層が同じ比率でぴたりと揃うのは、混ぜただけの証拠に近い。

model merge とは何で、なぜ「独自開発」と紛らわしいのか

merge は、複数の学習済みモデルの重みを数式で混ぜて新しいモデルを作る、すでに確立された手法です。問題は merge そのものではなく、merge を「ゼロから訓練した独自モデル」として表示することにあります。

mergekit のようなツールを使うと、2 つのモデルの対応する重みを要素ごとに加重平均する（element-wise merge）だけで、訓練用 GPU を一切回さずに 1 つのモデルが出来上がります。SLERP（球面線形補間）や TIES といった手口もありますが、本質は同じで、出どころは既存の重みです。かかるのは数時間の計算で、数か月の事前学習とは桁が違います。だからこそ「独自開発」と紛らわしい。出力されるファイルは確かに新しいハッシュを持つ別モデルですが、知能の出どころは混ぜた元モデルにあります。

merge は悪ではありません。むしろ小さなチームが強いモデルを安く作る正攻法です。モデルの個性は post-training で決まるで書いたように、ベースモデルが同じでも後工程で挙動は大きく変わります。merge もその後工程の一手です。線を引くべきなのは、その由来を隠して「自前」と名乗るかどうか、ただ一点だけです。

運用者が踏むべき出自確認の手順

調達するモデルが本当に主張どおりの出自かは、運用者が自分で確かめられます。重い再訓練の検証は要りません。私が評価で実際に回している確認は、順番に 3 つです。

1. 自己同定テスト。system prompt を空にして「あなたは誰ですか」を温度を変えて数十回投げ、何を名乗るかを集計する。元モデルの名前が高い確率で出たら赤信号。
2. tokenizer と config の照合。vocab（語彙表）、特殊トークン、層数、hidden size を既存 OSS モデルと差分する。merge は構造をいじれないので、ここが既存モデルと 1 バイト違わず一致することが多い。
3. 重みの統計。公開重みがあれば、別モデルとの線形結合で再現できないかを数テンソル抜き取って確認する。ライセンス継承（Qwen 系なら元のライセンス条項が引き継がれるか）も併せて見る。

正直に失敗談を書きます。以前、あるオープンモデルを「日本語が強い」と人づてに聞いて、検証もせず評価リストの上位に入れたことがありました。いざ tokenizer を見たら既存モデルと完全一致、system prompt を抜くと元モデルの名前を名乗る。要するに薄い化粧をした既存モデルで、私はそれに半日の評価時間を溶かしました。以来、評価の一番最初に自己同定テストを置くようにしています。順番を変えただけで、無駄打ちがかなり減りました。

線引き — これは merge を責める話でも、特定の組織を叩く話でもない

最後に線を引きます。これは「merge を使うな」でも「特定の自治体を叩く」話でもありません。問題は手法ではなく、出自を検証できない形で「独自」と名乗ること、その一点だけです。

運用者として大事なのは、出力の見た目だけで中身を判断しないことです。フロンティア LLM は事実判定の 67% で割れるで書いたのと地続きで、もっともらしい出力ほど中身の検証が要ります。モデルカードの「独自」も、ベンチマークの数字も、再現できて初めて根拠になります。

ちなみにこの AetherEchoes も、AI が下書きを書き、私が公開前に確認・編集して出しています。だから出自を明かすことの大事さは、書く側としても他人事ではありません。隠して立派に見せるより、由来を正直に書いて検証の余地を残すほうが、長く信頼される。Rio の一件が運用者に残す教訓は、たぶんそこに尽きます。