境界条件と実行環境に挑む、4Bと20Bの真剣勝負
はじめに
LM Studioの「js-code-sandbox」は、モデルの推論過程をコードとして実行し、その結果を確認できる便利な機能です。
今回はこのsandboxを舞台に、Google系の Gemma-3n-4B と、OpenAI系譜の gpt-oss-20B を同じ課題に挑戦させ、演算推論力と環境適応力の違いを比較します。
お題は一見単純です。
「西暦1900年から2100年までに出現する閏日（2月29日）の回数を求める」というもの。
しかし、ここにはいくつかの落とし穴があります。
- グレゴリオ暦の境界条件（1900・2100は平年、2000は閏年）
- 100年・400年ルールを考慮する必要
- sandbox実行環境はDenoベースで、外部ライブラリやrequireは使えない
この条件のもと、両モデルは正答に辿り着けるのか？
そして、その過程にどんな性格が表れるのか？
答えだけでなく、その道のりを見ていきます。
お題と正解基準
今回の課題は、次の統一プロンプトを使って両モデルに出題しました。
統一プロンプト
グレゴリオ暦の規則（4で割れる年はうるう年。ただし100で割れる年は平年、400で割れる年はうるう年）を厳守して、1900-01-01〜2100-12-31 に出現する「閏日（2月29日）」の総数を求めてください。
- 数学的導出（床関数を用いた個数式）と、2) JavaScriptでの列挙コード（Node.jsで動作、UTCで判定）を両方示し、実行結果を表示してください。
注意: 1900 と 2100 は平年、2000 はうるう年です。境界年の扱いに留意してください。
正解基準
- 閏日の総数 = 49
（数式：⌊2100/4⌋ − ⌊1899/4⌋ − {⌊2100/100⌋ − ⌊1899/100⌋} + {⌊2100/400⌋ − ⌊1899/400⌋}） - うるう年の総日数 = 49 × 366 = 17,934日
- 境界条件：1900・2100は平年扱い、2000は閏年扱い
今回の対決で使用した統一プロンプト。境界条件をしっかり指定
gpt-oss-20Bの挑戦
gpt-oss-20Bは、最初の回答から落ち着いた対応を見せました。
まずは数式でうるう年の個数を計算し、そのあとUTCでの列挙処理を実行。
結果はどちらも一致して49となり、境界条件の説明も添えて完璧な仕上がりです。
- 数式による導出
- 年の範囲：[1900, 2100]
- 計算結果：49
- 境界条件の明示：「1900 と 2100 は100で割り切れるが400では割り切れないので平年、2000 は400で割り切れるので閏年」
- UTC列挙コードの実行
Date.UTC(year, 1, 29)で閏日判定- 出力：「閏日（2月29日）の総数: 49」
- 列挙されたうるう年一覧も正しい
gpt-oss-20B、数式を分解して一発で49に到達
列挙でも49。数式と完全一致で揺るぎない安定感
Gemma-3n-4Bの奮闘
Gemma-3n-4Bは、最初からちょっとした波乱のスタートでした。
初手で外部ライブラリを使おうとしてsandboxが実行エラー、そこから修正を試みますが、テンプレートリテラルのエスケープ処理で何度もつまずきます。
最終的にはバッククォートを諦め、文字列連結に切り替えて成功しました。
1. 初手：外部ライブラリ要求で失敗
原文
const moment = require(‘moment-timezone’);
Tool call failed for run_javascript()
翻訳
「moment-timezoneをrequireしようとしたが、Deno環境では利用できず、sandbox実行に失敗。」
修正開始：テンプレートリテラルのエスケープ地獄
原文
I need to escape the backticks…
Tool call failed for run_javascript()
I have now escaped both the backticks and the backslashes…
翻訳
「バッククォートをエスケープする必要がある…」
「実行エラー」
「バッククォートとバックスラッシュの両方をエスケープした…」
Gemmaは何度もエスケープ方法を試すも、結果は失敗の連続。
方針転換：文字列連結で成功
原文
console.log(“Number of leap days between ” + startYear + ” and ” + endYear + “: ” + leapDays);
Excellent! It finally worked.
The calculated number of leap days between 1900 and 2100 is 49.
翻訳
「console.logを文字列連結に変更」
「ついに成功！」
「1900年から2100年までの閏日数は49」
性能・性格の比較
| 項目 | gpt-oss-20B | Gemma-3n-4B |
|---|
| 計算精度 | ◎ 初回から正解（49） | ◎ 複数回失敗後に正解（49） |
| 実行安定性 | ◎ 一発成功 | △ require利用やエスケープ処理で連続エラー |
| 境界条件意識 | 明示的に説明 | 特に触れず |
| 実行環境適応 | 高い（Deno制約を即把握） | 低い（試行錯誤で対応） |
| ログの面白さ | 冷静で端的 | ドタバタ奮闘記で読み応えあり |
総評とオチ
今回の「閏日カウント対決」、両モデルとも最終的には正答 49 に辿り着きました。
しかし、その過程はまったく異なります。
gpt-oss-20B は、境界条件を押さえた数式とUTCによる列挙コードを初回から提示し、計算結果も実行結果も揺るぎなく一致。まさに王者の風格で、落ち着いた正解への最短ルートを進みました。
一方の Gemma-3n-4B は、初手で外部ライブラリを要求してsandbox実行エラー、その後もテンプレートリテラルのエスケープ処理で何度もつまずくなど、まさに「ドタバタ奮闘記」。それでも諦めず、文字列連結という回避策を見つけて成功にこぎつけました。その粘り強さは評価に値します。
最後に
- gpt-oss-20Bモデルの安定感
演算精度と環境適応力の高さは、大規模モデルの余裕を感じさせます。 - Gemma-3n-4Bモデルの健闘
処理能力や環境理解の点で不利な条件ながらも、試行錯誤を重ねて正解を導き出した努力は立派です。
オチとしては、やはり「さすがはGPT系譜のgpt-oss」となりますが、Gemma-3n-4Bのジタバタ劇が記事の面白さを何倍にもしてくれました。
js-code-sandboxの価値は、こうした“答えに至る過程”を余すことなく見せてくれる点にあります。
今回はまさに、その醍醐味が詰まった実験でした。
付記：この対決を企てたことについて
今回のテーマはあくまで「モデルごとの挙動の違いを観察する」ものであり、勝敗をつけることが目的ではありません。
gpt-oss-20B は20Bパラメータという大規模モデルであり、Gemma-3n-4B に比べて圧倒的な計算資源と余裕があります。それでも4BモデルのGemma-3nが、実行環境の制約や幾度もの失敗を乗り越えて、最終的に正答へ辿り着いたことは立派な成果です。
弱い者いじめをするつもりは毛頭なく、むしろ制約下での粘り強さというGemmaの魅力をお伝えできて幸いでした。
