モデルの「作りの違い」について雑談していて、ふと手元のローカルLLMたちに早口言葉を解かせてみたくなった。お題は古典的なあれ――「にわにはにわにわとりがいる」。正解は「庭には二羽鶏がいる」。場所の庭、数の二羽、鳥の鶏（にわとり）。3つの「にわ」がそれぞれ別の役割を担う、分かち書きが本質の文だ。
始める前の私の見立ては素朴なものだった。「小さいモデルが間違えるのは、知識容量が足りないから」。自作の分散推論基盤Coordinatorを運用してきて、パイプラインに使う小さな子モデルのハルシネーションは「アーキテクチャやパイプラインの問題ではなく、知識容量の限界」だと何度も切り分けてきた。今回もその確認になるだろう、くらいの気持ちだった。
ところが、11台のモデルを順に試していくうちに、この仮説は4回書き換わった。容量 → 系統 → アーキテクチャ → そして最後に「日本語の出自」へ。おまけに、自分で設計しているbest-of評価の急所まで露わになった。今日はその記録を、間違えた順に書いていく。
第1幕：大きくすれば直るのか
最初の一台は、CPUワーカー機に載せた小さな gemma3:1b に決めた。……が、いきなり別のところでつまずいた。AI-Coreから叩くと Connection refused。pingは通るのにポートに届かない。調べると、このノードのOllamaは 127.0.0.1 にしかバインドしておらず、LANに出ていなかった。以前 MacBook で踏んだ「Expose to network」と同じ穴のLinux/systemd版だ。
直し方は OLLAMA_HOST=0.0.0.0:11434 を override.conf に足すだけ。ただしこのシステムでは過去に systemctl edit で override を全損させた前科があるので、systemctl edit は使わず、タイムスタンプ付きバックアップを取ってから直接ファイルに1行追記した。反映確認は必ずファイルではなくプロセス側の実効値（systemctl show -p Environment）で見る。バインドが 0.0.0.0:11434 に変わったのを確認して、ようやく本題に戻れた。
そして gemma3:1b の答え。
「にわにはにわにわとりがいる」 は「**静けさが…
「静けさ」。鶏どころか庭にもたどり着けず、音の雰囲気から和風っぽい何かを生成して暴走した。入力を認識する段階で崩壊している。これは予想どおり、容量が小さすぎる。
では容量を上げよう。qwen2.5:7b → qwen3:8b → gemma3:12b、さらに qwen3:14b を新しくpullして M1 Mac で動かした。すると確かに、8B以上は「庭」と「鶏」を安定して当てるようになる。1bが落とした強い結びつきは、容量で取れるようになった。
ところが――「二羽」だけは、14Bまで上げても誰も当たらない。それどころか、12bと14bは真ん中の「にわ」をまた「庭」に重ねたうえで、こう言い添えてきた。
（「庭」を二回繰り返すことで、場所の強調や文体の工夫を表している。）
間違えた上に、その間違いを「強調表現」と正当化までする。ここで第1の仮説「容量が原因」は崩れた。容量を上げると庭と鶏は取れるが、二羽の壁はびくともしない。
第2幕：Transformer 固有の癖なのか
ここで気づく。ここまで試した5台は、gemmaもqwenも、全部Transformerだ。「真ん中のにわを強調と解釈する」というあの癖は、もしかしてTransformerというアーキテクチャ固有のものではないか。だとしたら、非Transformerのモデルなら違う間違い方をするはずだ。
そこで非Transformer勢を当たった。が、ここは難航した。LFM2.5-1.2B-JP（Liquid系）は容量が小さすぎて毎回バラバラに崩壊。Falcon3-Mamba-7B（Mamba系）は日本語の指示自体を処理できず「年末年始の特別な日」と全く無関係な文を返す。falcon-mamba-7b に至っては、日本語で投げると空応答、英語で投げ直すと “In a rice paddy, there are many little frogs.”（田んぼにカエルがたくさん）。
この英語版が一瞬、希望を見せた。3回振って3回とも「繰り返し＝強調」を避け、”many”（複数）方向に解釈したのだ。私はここで「非Transformerは強調バイアスを持たないのでは」と勢いよく書きかけた。だが日本語で投げ直すと空応答に戻る。つまりこのモデルは日本語の土俵にそもそも立てておらず、英語タスクとして処理したから日本語の「強調」慣習が発動しなかっただけ、と考える方が筋が通る。1サンプルで飛びついた結論を、振り直して引っ込めた。
非Transformerが軒並み「日本語を喋れない」せいで、肝心の問いが検証できない。第2幕は宙ぶらりんのまま終わる。
第3幕：唯一正解したのは、3Bの国産モデルだった
まず「日本語が喋れる非Transformer」を本気で探した。見つかったのが RWKV7-G1f-13.3B。純粋なRNNアーキテクチャで、Transformerと違ってKVキャッシュを持たない正真正銘の非Transformerだ。これがGPU機で日本語の挨拶にちゃんと応答した。今日はじめて、非Transformerが「判定可能な土俵」に立った。
本番を投げると――
庭には鶏がいる。
二羽は落としたが、真ん中の「にわ」を「庭」に重ねも「強調」もせず、すっぱり消した。3回振っても安定。さらに thinking 出力を見ると、RWKVは「にわにわ」の繰り返しに気づいた上で、「繰り返しているように見えますが、実際には鶏を指す言葉として使われています」と、強調解釈を明示的に却下していた。Transformer勢が全員ハマった穴を、このモデルは避けた。
「やはり強調誤読はTransformer寄りの癖か」と思いかけたところで、念のため別方向も試すことにした。これまでの日本語勢は、ELYZA（海外のLlamaに日本語を追加学習したもの）止まりだった。では「最初から日本語前提で作られた」純国産モデルはどうか。SB Intuitions の Sarashina2.2-3b を pull して、これまでと一字一句同じプロンプトを投げた。
庭には二羽鶏がいる この文章は「庭には二羽の鶏がいます」という意味になります。
当てた。今日11台が全員落とした「二羽」を、わずか3Bの国産モデルが軽々と正解した。庭・鶏・二羽、すべて。4回振って3回当てる安定性まである。
ここで真の変数が見えた。容量ではない（最小の3Bが、12Bや14Bが落とした問題を解いた）。アーキテクチャでもない（同じTransformerのqwenやgemmaは外し、同じTransformerのSarashinaは当てた）。効いていたのは日本語学習データの密度と出自だった。8BのELYZA（日本語追加学習）が二羽を一度も当てられなかったのに対し、3BのSarashina（純国産フルスクラッチ）は75%で正解する。「にわ＝二羽」という珍しい数詞用法の結びつきが、純国産の学習データには十分な密度で入っていた、ということだ。
「ハルシネーションは知識容量の限界」という出発点の仮説は、ここで「容量だけでなく、そのモデルの学習データに該当の知識が含まれているかが効く」へと精密化された。海外モデルへの後付けでは届かず、日本語ネイティブ設計でないと入らない知識がある。その差が、たった一語「二羽」にくっきり出た。
（なお、中間的な存在として Swallow〈Llamaを日本語で大規模継続学習〉も試したが、呼び出し方で挙動が変わり他のモデルと条件を揃えられなかったため、今回は「評価保留」として正直に除外した。無理に証拠に組み込むと、せっかくの綺麗な対比が濁る。）
第4幕：その正解を、judge は選べるのか
最後にもう一つだけ確かめたいことがあった。Coordinatorで構想している「複数モデルに同じ問題を解かせ、judge（評価役のLLM）が一番良い答えを選ぶ」というbest-of方式。もしSarashinaを候補群に入れれば、judgeが正解を拾ってくれるはずだ――そう思って、本番で使っている採点ロジックをそのまま単体で動かし、8台の回答を gemma3:12b に採点させた。
結果は、静かに衝撃的だった。
qwen3:8b （二羽×・誤り） → スコア 1.00（満点） sarashina2.2 （二羽○・唯一の正解）→ スコア 0.80
judgeは、間違えたモデルに満点を与え、唯一正解したモデルをそれより低く採点した。二羽を当てた組と落とした組の平均スコア差は、わずか -0.01。区別できていない。
理由は単純だ。judge役の gemma3:12b 自身が、二羽を知らない。だから二羽を落とした「庭には庭鶏」を「正確な変換」と褒め、二羽を入れた正解を「もう漢字だから変換不要」と誤認した。極めつけは、judgeが自分の「強調」という誤読を採点理由の中で加点要素として肯定していたことだ。
つまり――judgeが共有している知識の穴については、best-of は機能しない。候補の中に正解者がいても、judgeがそれを正解と判定できなければ、正解は選ばれずに捨てられる。多数決や評価役で弱いモデルの誤りを救う、という素朴な期待は、「評価役も同じ穴に落ちているなら成立しない」という形でひっくり返った。
まとめ：間違いにも階層がある
一文の早口言葉から、こんな地層が見えた。
ハルシネーションには階層がある。容量で直るもの（庭・鶏：1bは落とすが8B以上で安定）と、容量でもアーキでも直らず、特定の学習データ由来でしか解けないもの（二羽：日本語ネイティブ設計のSarashinaだけが解いた）。この2つは、同じ「間違い」でも対処法がまるで違う。前者は大きいモデルに替えれば直るが、後者は「正解を知っているモデル」に当てるか、外部から事実を供給する（RAG）しかない。
そしてbest-of評価が効くのは「judgeが正解を正解と判定できる領域」に限られる、という現実。Coordinatorのv-nextで「多様性の源泉はアーキテクチャの差」と構想していたが、今日の早口言葉では全アーキが同じ穴に落ち、効いたのは「日本語の出自」という別の軸だった。多様化の設計には、まだ考える余地がある。
11台のモデルと1台のjudgeを、たった一つの早口言葉で測った。そのあいだに私の仮説は4回ひっくり返った。「計測してから信じる」という自分への戒めを、これほど短い一文で突きつけられた実験は、これまでなかった。