「全精度より9倍以上小さい」はどう読むべきか？

まず分母を問う：全精度版はFP16かFP32か、倍率は全く異なる。公式は Ternary Bonsai 2 27B が重みあたり1.76実効ビット、総占有5.9GBと発表——27Bパラメータ×1.76ビットで割り出すと5.9GB前後、これは検算できる。だが「98.2%の統合ベンチマーク」は公式が完全なリストと統合方法を提示しておらず、平均で平準化されたスコア低下が、ちょうど自社の重要タスクに当たる可能性がある。

near-lossless、deployment unlock のようなマーケティング用語はどう作られるのか？

near-lossless は一語足すことで「ロスレス」の重みを借りつつ、証明責任は負わない——三値化後は元の重みを取り戻せないため、誰もロスレスとは言えない。deployment unlock は数字ではなく物語を与える。「モデルが圧縮された」を「デプロイが解放された」と言い換えることで、聞き手の頭の中の問いは「モデルはどのくらいのサイズか」から「どれだけGPUを節約できるか」に変わる。受益者を並べてみよう：ベンダーの市場向け物語、コンテンツ発信者、プロジェクト立ち上げを後押ししたい人。唯一利益を得ないのは、契約前に言葉を分解しなかった人だ。

調達審査で3つの質問を使って言葉を分解するには？

第一に、再現可能な口径を求める：分母は何か、ベンチマークリストと統合ウェイトを列挙できるか。第二に、利益関係のない第三者による再測定を求める。自己申告の口径だけを信じてはいけない。第三に、宣伝文句を検収条項に書き込む——言葉が契約言語になれば、相手は各用語を真剣に定義するか、その用語が提案書から消えるかのどちらか。どちらの結果も発注者側の勝ちだ。

「9倍小さく、98.2%保持」：ベンダーの言葉を技術マネージャーはどう読むか

冒頭：ひとことで、ふたつの数字

9月17日、PrismML 公式ブログが Ternary Bonsai 2 27B を発表。公式見解はひとことで「全精度版より9倍以上小さく、同時に98.2%の統合ベンチマーク性能を保持」。この言葉は間違っているか？未必。だがこの言葉の読み方は、また別のスキルだ。同じ日、この言葉は Hacker News で563の賛成票を獲得した。そして時間を2ヶ月遡ると、この会社が初代 Bonsai 27B を発表したとき、公式の言葉はすでに「モデルを小さくする」から「圧縮がデプロイの解放になる（deployment unlock）」へと静かに変わっていた。

マーケティング用語は嘘の同義語ではないが、独自の造語ロジックと、独自の受益者がいる。技術マネージャーの仕事はそれを非難することでも、信じることでもなく、検証可能な部品に分解することだ。

拾聞：ひとことでふたつの数字、なぜわざわざ1回分にする価値があるの？

永亮：17年間のベンダー側報告と提案書審査をやってきて、意見の相違の半分以上は技術ではなく言葉にある。ベンダーが数字を出し、発注者側が別の数字を聞き、両者が同じことを言っていると思い込んで、契約後にまったく違うと気づく。今回の回はこれを分解する：数字の読み方、言葉の作り方、スターの増え方、最後に調達会議でそのまま使える3つの質問を提示する。

Q1：まず「9倍小さい、98.2%」というふたつの数字自体を分解する

永亮：先に口径を明言する：以下はすべて PrismML 公式ブログの自己申告数字であり、引用時はすべて「公式発表によると」を付ける。この前提で、このふたつの数字こそ最も分解する価値のあるサンプルだ。

公式ブログによると、Ternary Bonsai 2 27B は Qwen3.8 27B ベースで、重みを三値化——{-1, 0, +1} の3値——し、さらに FP16 グループスケーリングを追加。公式発表では重みあたり1.76実効ビット、モデル総占有5.9GB、262Kコンテキスト対応、マルチモーダル画像入力対応、Apache 2.0 ライセンス。これだけ見れば、工学的には堅実な仕事であり、その点は認めるべきだ。

ゆっくり読む価値があるのは後半の文だ。公式は「全精度版より9倍以上小さく、同時に98.2%の統合ベンチマーク性能を保持」と発表している。分解すると、3つの口径問題がある。第一に、「9倍」の分母は何か？全精度版はFP16かFP32か？分母が違えば、倍率は全く変わる。第二に、「98.2%」はどのベンチマークを統合し、どのようなウェイトで統合したのか？公式ブログには完全なベンチマークリストも統合方法も記載されていない——これは非難ではなく、開示レベルの問題だ。第三に、最も見落とされがちな点：ベンチマークスコアは実際のタスク体験と等しくない。統合ベンチマークは数十タスクの平均点であり、平均で98.2%を保持しているということは、個別タスクで大きく落ちるものもあれば、落ち方が小さいものもある。そして平均で平準化された部分が、ちょうど自社の業務上の重要タスクに当たる可能性がある。

もう一度自分の立場を言う：ベンダー側の報告を17年やってきて、この数字のパッケージング手法は、他人が使うのを見たこともあるし、自分でも使ったことがある。小数点以下1桁のパーセンテージは、正確に見せるためだ。「統合」と言ってリストを出さないのは、スコアが落ちる箇所を表に出さないためだ。公式が偽造していると言っているわけでは決してない——リストを出さないのは、紙幅の制限かもしれないし、選択的提示かもしれない。両方の可能性がある。だがマネージャーの読み方はひとつしかない：「X倍」「Y%」のようなパッケージ化された数字は、まず分母とリストを問い、それから信じるかどうかを判断する。

Q2：「near-lossless」「deployment unlock」のような言葉はどう作られるのか

永亮：言葉は適当に作られるものではない。それぞれのマーケティング用語の背後には、具体的な受益者がいる。

2ヶ月前、PrismML が初代 Bonsai 27B を発表したとき、公式の言葉は「圧縮がデプロイの解放になる」（deployment unlock）だった。今回の Bonsai 2 では、コミュニティの議論に near-lossless（ニアロスレス）という表現が出てきた。ふたつの言葉を並べて見ると、造語のやり方がはっきりわかる。

「ロスレス」は工学上明確な定義がある：情報が完全に復元できること。だが量子化モデルにはそれができない——三値化後は、元の重みを取り戻せない。だから誰もロスレスとは言えず、「near-lossless」という言葉が作られた：一語足すことで「ロスレス」の重みを借りつつ、「ロスレス」の証明責任は負わない。誰が得をするのか？短期的には発信者だ。専門的に聞こえる言葉は投稿の拡散を促進する。長期的にはベンダーだ。言葉が広まれば、デフォルトの印象が植え付けられる。

「deployment unlock」は別の道を行く：数字を与えず、物語を与える。「圧縮」は工学的な言葉で、言ってもエンジニアしか気にしない。「デプロイの解放」はビジネス用語で、経営者や投資家に話すためのものだ。5.9GB を「デプロイの解放」と言い換えることで、聞き手の頭の中の問いは「このモデルはどのくらいのサイズか」から「これでGPUをどれだけ節約できるか」に変わる。技術パラメータは変わらない。物語の対象が変わっただけだ。これは2ヶ月前の初回発表で完了していた転換だ。

受益者を並べてみよう：第一にベンダーの市場・資金調達の物語。第二にコンテンツ発信者、新しい言葉があれば書ける。間接的には、発注者側でプロジェクト立ち上げを後押ししたい人も得をする。なぜなら聞こえの良い言葉は立ち上げの抵抗を減らすからだ。唯一得をしないのは、お金を払って検収する人——契約前に言葉を数字に分解しなかった場合だが。

Q3：3日、5つのリポジトリ、数千のスター——Jev の同名プロジェクト群の波はどう読むか

拾聞：ベンダーの造語の話はここまでにして、コミュニティ側を見てみよう。TypeSafe の Jev モデル、3日間で GitHub に同じ方向性のプロジェクトが5つ出現、スター数は合計1万超。これは技術的な盛り上がりの証拠なのか？

永亮：まず検証可能な事実を整理してから、どう読むかを考える。

Jev は TypeSafe 社の商用モデルだ。TypeSafe 公式ブログによると、自称 system one モデル：回答をトークンごとに生成するのではなく、与えられた選択肢に対して各選択肢の確率を直接出力し、エージェントの高速な分岐判断に使う。TypeSafe はモデル設計を公開していない。

同名プロジェクトの波は9月16日に始まり、今日で3日目。GitHub の公開データによると：browser-use の jev-ultrafast は5487スター、README は「7.1秒でチューリッヒからロンドンへの航空券を予約」というデモがメインで、README 上部には Browser Use Cloud のウェイトリスト入口がある。tamaratran の fast-jev-compaction は3206スター。TheoLeeCJ の SemIf は1585スター、旧名 OpenJev、トップページで TypeSafe とは無関係と宣言。vinnylarouge の jevlike は885スター、「Jev は TypeSafe の商用モデルで設計は非公開、このリポジトリは同じ入出力形状の独立した入門モデル」と自己記述。jarrodwatts の jev-trader は866スター、300ミリ秒ごとに売買判断をするオンチェーン取引ボット。Hacker News の「OpenJev」スレッドは534の賛成票を獲得。

この数字の中には2種類のものが混在しており、分けて読まなければならない。1つ目はマーケティング施策：最も速く動いたリポジトリはデモとウェイトリストのファネルを同じ画面に配置しており、スター数の増加自体がファネルの入り口だ——これは技術的証拠ではなく、顧客獲得エンジニアリングだ。上手くやっているが、「このモデルが使えるかどうか」には答えていない。便乗の部分も同様だ：名前がホットトピックに乗ればスター数は速く伸びるが、スター数は使いやすさと同義ではない。古参のベンダー側として一言：審査会で GitHub スター数を技術的証拠として使うのは、レストランの待ち行列の長さを味の評価にするのと同じ方法論的誤りだ。

2つ目の種類こそ、まさに健全なシグナルだ。SemIf は改名して TypeSafe との無関係を宣言し、jevlike は「同じ入出力形状の独立した入門モデル」と明言している——この2つの免責事項は、コミュニティがベンダーの開示不足を補っているのだ。ホットトピックが発生した後、誰かが手間をかけて形状互換の独立実装を作り、「私は公式ではない、設計は知らない」とトップページに書く。これはコミュニティに再現性を重視する人がいることを示している。マーケティング施策はやがて引いていくが、免責事項は残る。この波を読むなら、後者を見れば十分だ。

Q4：調達とプロジェクト立ち上げのとき、3つの質問で言葉を分解する

永亮：これが今回の回で最も伝えたいことだ。3つの質問、審査会でそのまま使える。

最初の質問：再現可能な口径を提示してください。「9倍小さい」の分母はどのモデル、どの精度ですか？「98.2%」のベンチマークリストと統合ウェイトを列挙できますか？この質問のポイントは答えではなく、相手がどう対応するかだ。リストを出せるなら、数字はおそらく検証に耐える。「業界慣行」「非公開」と言い始めたら、わかるだろう——彼が守っているのは機密ではなく、数字だと。2つ目の質問：第三者による再測定はありますか？公式の数字を転載した記事ではなく、ベンダーと利益関係のないチームが、同等の条件で比較可能な結果を出しているかどうか。先週、私たちは公式自己申告の口径に基づくインフラストラクチャのケースを分解したが、技術スタックと難点はすべて一社の見解だった——自己申告の口径は信頼できないというわけではないが、それだけを信じてはいけない。3つ目の質問が最も鋭い：宣伝文句を検収条項に書き込む。「near-lossless と言うなら、検収基準は誤差範囲で書きましょう。98.2% と言うなら、検収はあなた方が提示したベンチマークリストに従って項目ごとに測定します。」言葉が契約言語になれば、相手は各用語を真剣に定義し始めるか、その用語が提案書から消えるかのどちらか——どちらの結果も発注者側の勝ちだ。

この3つの質問を私は10年以上使っている。原理はひとこと：マーケティング用語の特徴は、上には報告できても、下では検収できないことだ。検収条項に書けない言葉は、調達判断におけるウェイトはゼロであるべきだ。

Q5：締めくくり——どんな言葉に警戒すべきか、どんな誇張は許容できるか

拾聞：最後に、視聴者に判断の物差しを？

永亮：私の物差しは「誇張の方向」で分ける。業界では分けない。

速度系の誇張は許容度が高い。「7.1秒で航空券を予約」のようなデモは、たとえ最良の条件で撮影されたものでも、その主張の方向は「速い」であり、速さの検証コストは極めて低い——自分で実行すれば真偽がわかる。能力系の主張にはゼロ容認だ。「98.2%の性能保持」「near-lossless」のようなものは、主張の方向は「相当する」であり、「相当する」の検証コストは極めて高い。検証が終わる頃には、契約は終わり、金は支払われている。能力主張よりも警戒すべき別の種類がある：定義系の言葉だ。「deployment unlock」という言葉自体には検証可能な内容が何もなく、それがやっているのは問題の再定義だ——「モデルが圧縮された」を「デプロイが解放された」と言い換える。定義系の言葉の特徴は：聞けば聞くほど心地よく聞こえるほど、元の問題がどこへ行ったのかを探し直さなければならない。

だから私の優先順位は：速度の誇張は、笑って流して、自分で一度再現すればいい。能力の主張は、まず口径と第三者を問い、検収条項で決着をつける。定義の言葉は、直接元の問題を問いただす。17年で審査した提案書で、最終的に紛争になったものは、ほとんどが数字の誤りではなく、言葉が最初から最後まで定義されていなかったことによるものだ。

エピローグ

拾聞：最後に、この回をひとことでまとめると？

永亮：マーケティング用語は嘘ではなく、圧縮パッケージだ。技術マネージャーの仕事はそれを非難することでも信じることでもなく、契約前に解凍することだ——分母、リスト、検収条項、解凍してから見れば、それはたいてい恐れるほどでもなく、安くもない。

拾聞：この言葉を、みなさんに。次回お会いしましょう。

【技術の深掘り】三値量子化は一体何をしたのか、なぜ5.9GBがブログ全体で最も検算しやすい数字なのか

今回の回の本線は言葉の読み方だが、もう一歩深く知りたい読者もいるだろう：三値量子化とは何か、なぜ「1.76実効ビット」という奇妙な数字が、公式ブログの中で最も誠実な部分なのか。

三値の重み：{-1, 0, +1}。 通常の量子化は各重みを16ビットや32ビットの浮動小数点からより少ないビットに圧縮する。例えば4ビット整数。三値化はさらに進む：各重みはマイナス1、ゼロ、プラス1の3値のみを許容し、さらにFP16のグループスケーリング係数を組み合わせる。公式発表ではこの組み合わせで重みあたり1.76実効ビットになる。

1.76がなぜ誠実か。 3値自体は2ビットも使わずに符号化でき、グループスケーリングと符号化オーバーヘッドを加えて、各重みに割り振ると1.76ビットになる。この数字は小数付きで、きりのいい数字ではない。まさにそれが計算された平均値であり、選ばれた整数ではないことを示している。27Bパラメータ×1.76ビット、割り出すと5.9GB前後——この掛け算は誰にでもできる。数字が検算できること、それが信頼できる理由だ。信頼できる数字が、検算できない「98.2%」を包装するために使われる——それが言葉のすべてだ。

失われた1.8%は均等に分布していない。 三値化がタスクに与える影響は異なる：重みの分布が滑らかで、エラートレランスが高いタスクでは、損失はゼロに近い。繊細な数値の差異に依存するタスクでは、スコア低下が顕著だ。統合平均スコアが隠しているのは、まさにこの不均一さだ。これがQ1の言葉の根拠だ：まずリストを問い、それから信じるかどうかを判断する。

本線に戻る。検算できる数字は決して怖くない。怖い数字は往々にして検算できない。これがすべてのベンダー言葉を読む第一原理だ。

今回の情報源

PrismML 公式ブログ 2026-09-17：Ternary Bonsai 2 27B 発表（Qwen3.8 27B ベース；三値の重み + FP16 グループスケーリング；重みあたり1.76実効ビット；5.9GB；262Kコンテキスト；Apache 2.0；「9倍以上小さい、98.2%の統合ベンチマーク性能を保持」はすべて公式自己申告の口径であり、完全なベンチマークリストと統合方法は未開示）
PrismML 公式ブログ（2ヶ月前）：初代 Bonsai 27B 発表、公式の言葉「圧縮がデプロイの解放になる」（deployment unlock）
Hacker News 2026-09-17：Ternary Bonsai 2 議論スレッド、563 ▲
TypeSafe 公式ブログ：Introducing System One Models and Jev（Jev は商用モデル、モデル設計は非公開、すべて公式口径）
GitHub 公開データ（2026-09-19 午前時点）：browser-use/jev-ultrafast 5487★、tamaratran/fast-jev-compaction 3206★、TheoLeeCJ/SemIf 1585★（トップページで TypeSafe との無関係を宣言）、vinnylarouge/jevlike 885★（同じ入出力形状の独立した入門モデルと自己記述）、jarrodwatts/jev-trader 866★（5つのリポジトリはすべて2026-09-16に作成）
Hacker News：「OpenJev」議論スレッド、534 ▲