Bonsai 8B でローカル LLM をミニマムから始める

1-bit Bonsai 8B は、約 82 億個のパラメーターを持ちながら、開発元が示す重み領域を約 1.15 GB に収めた言語モデルである。埋め込み層、注意機構、全結合層、出力層を含む主要な重みに 1-bit 表現を適用しており、一般的な 8B 級の半精度モデルと比べて、重みの保存に必要な容量を大幅に減らしている[1]。公式モデルカードによれば、配布される Q1_0 形式では 128 個の 1-bit 重みに対して 1 個の半精度尺度を共有する。この尺度を含めた実効値は 1 重み当たり 1.125 bit となり、GGUF ファイル全体は約 1.16 GB である[2]。

約 1.15 GB という値が変えるのは、モデルを保存できる端末の範囲だけではない。数十 GB の重みを必要とするモデルでは、モデルの取得、保存、読み込み、常駐がそれぞれ運用上の負担になる。起動のたびに大きな重みを記憶装置から読み込み、推論中も広いメモリ領域を占有するため、短い文章を数件処理するだけの用途では、実際の生成処理より環境維持の負担が大きくなりやすい。重み領域が約 1 GB まで縮小すれば、モデルを長時間常駐させ、短い要約、分類、抽出、文章整形を繰り返す構成や、外部ネットワークへ接続できない端末へ配置する構成が現実的な候補になる。

一方、保存容量の削減は、生成内容の正確性を直接改善しない。モデルファイルが小さくても、入力に含まれない事実を補う可能性、長い文章から重要な条件を落とす可能性、複数の指示を保持できない可能性は残る。実行時には、重み以外にも推論器、トークナイザー、計算用の一時領域、文脈を保持する KV キャッシュが必要であり、約 1.15 GB というファイルサイズが、そのまま必要メモリの総量になるわけでもない。Bonsai の採用判断には、重みの小ささ、実行時の資源消費、対象業務での出力品質、人間による確認時間を分けて測る必要がある。

この性質から、Bonsai の役割は大型モデルが担っていた仕事を一括して置き換えることにはならない。適しているのは、必要な情報が入力内に存在し、出力形式を限定でき、誤りを原文や規則と照合できる処理である。要約では原文を読む位置を絞り、校正では内容を変えずに表現を整え、分類では定義済みの候補から一つを選び、抽出では入力中に明記された日時や担当者を取り出す。このように仕事を小さな検証単位へ分解したとき、低い常駐負荷と高い反復性が業務上の利益へ変わる。

本稿では、Bonsai 8B を限定的な言語処理を常時実行する最小基盤として構築する。前半では、要約、校正、分類、抽出へ投入できる条件と、判断や承認へ進ませない境界を整理する。後半では、本家 llama.cpp と Bonsai 8B Q1_0 を用い、CPU だけで単発推論とローカル API が成立する環境を作る。完成条件は、一度だけ応答を取得することではない。入力の準備、モデルの読み込み、推論、出力の確認、修正までを一つの工程として計測し、人間だけで処理した場合より短縮できる仕事を特定することである。

1. 1.15 GB のモデルは、何を小さくしたのか

1.1 低ビット化は、完成後の圧縮だけを意味しない

1-bit LLM は、半精度で学習したモデルを完成後に極端な精度へ丸めるだけの技術ではない。BitNet は、通常の線形層を 1-bit 重みの利用を前提とする BitLinear へ置き換え、学習時から重みの表現範囲を制約する構造を提案した[3]。学習後に数値を粗く丸める方法では、元のモデルが細かな数値差を利用して獲得した関係を後から失う。これに対し、低ビット表現を前提として学習すれば、モデルは限られた重みの組み合わせの中で誤差を抑える方向へ調整される。

BitNet b1.58 は、この考え方を重みが -1、0、+1 のいずれかになる三値モデルへ拡張した。3 種類の値を表すために必要な情報量が理論上約 1.58 bit であることから、1.58-bit LLM と呼ばれる[4]。ここでいう 1-bit と 1.58-bit は、同じ圧縮率を別の方法で表現した名称ではない。二値モデルは重みを 2 種類へ制限し、三値モデルは 0 を加えることで表現力と計算効率の均衡を変える。

その後、約 20 億パラメーターのモデルを 4 兆トークンで学習した BitNet b1.58 2B4T と、CPU・GPU 向けの推論実装が公開された[5]。低ビット LLM は、理論上の圧縮手法から、モデルファイル、実行形式、推論器を組み合わせて配布できる段階へ進んだ。Bonsai もこの技術潮流に属するが、Bonsai 固有のサイズ、重み形式、評価値は、BitNet 系研究の結果ではなく、Bonsai の公式資料と実物のモデルファイルによって確認する必要がある。

1.2 小さな重みを実行時の利点へ変えるには推論器が必要になる

重みのビット幅を減らすと、最初に保存容量が減る。半精度では 1 個の重みに 16 bit を使用するのに対し、1-bit 表現では理論上 1 bit で保持できるため、重み部分だけを比べれば 16 分の 1 まで縮小できる。ただし、実際のモデル形式には、量子化単位ごとの尺度、テンソルの形状、語彙、トークナイザー、モデル構造の情報が含まれる。Bonsai 8B Q1_0 の実効値が 1.125 bit になるのは、128 個の 1-bit 重みに対して半精度の尺度を 1 個保持するためである[2]。

保存した低ビット重みを、推論のたびに半精度へ展開して通常の行列演算へ渡せば、ファイルは小さくても、計算時のメモリ転送と作業領域は再び大きくなる。低ビット化の利益を推論中まで維持するには、詰め込まれた重みを直接読み、尺度を適用しながら積和演算を行う処理が必要である。Bitnet.cpp が三値モデル向けの専用行列演算と重み配置を実装したのは、この変換負荷を抑えるためである[6]。

Bonsai の Q1_0 でも同じ構造がある。モデルファイルを 1-bit にするだけでは、低いメモリ転送量と高速な推論は得られない。推論器が Q1_0 の重み配置と共有尺度を理解し、対象の CPU または GPU で効率よく処理できて初めて、保存容量の削減が実行時の利点へ接続される。このため、Bonsai の性能を評価するときは、モデルファイルと推論器を分離せず、両者の組み合わせを一つの実行環境として記録する必要がある。

1.3 配置密度の改善と回答品質は別の評価軸になる

開発元は、6 種類の評価を平均した Bonsai 8B の値を 70.5 とし、Qwen 3 8B の 79.3 より低い一方、格納容量当たりの能力が高いと説明している[1]。この数値が直接示すのは、同じ 8B 級のモデルと同等の品質を維持したことではない。比較対象より評価値を落としながら、モデルファイルを大幅に小さくしたことで、単位容量当たりに配置できるモデル能力を高めたという関係である。

格納容量当たりの能力が高ければ、同じ記憶容量へ複数のモデルを置く、低容量の端末へ配布する、モデルを常駐させるといった構成を選びやすくなる。ところが、業務で必要になるのは、一般評価の平均値ではなく、特定の入力に対する失敗率である。日本語の会議録を要約する処理では、決定事項、担当者、期限、否定表現を落とさないことが必要になる。問い合わせ分類では、平均正解率より、重要な警告を通常質問へ誤分類する割合の方が大きな意味を持つ。

開発元が公表した評価項目には、一般知識、数学、コード、指示追従、ツール利用などが含まれるが、日本語の社内メール、障害報告、議事録を対象とした業務試験ではない[1]。評価項目が異なれば、同じ平均点でも実務上の意味は変わる。数式問題で失点するモデルでも定型分類には使える場合があり、一般知識で高得点を得たモデルでも、入力文にない担当者名を補えば抽出処理には使えない。

言語モデルの評価には、正確性だけでなく、頑健性、効率、出力の確信度と実際の正答率の対応など、用途ごとに異なる指標が必要になる[7]。Bonsai では、これらにモデル読み込み時間、実行時メモリ、入力長による速度低下、人間の確認時間を加える必要がある。小ささを重視するモデルである以上、品質だけを測れば配置上の利点を捨て、速度だけを測れば修正負担を見落とす。

1.4 小ささは業務の分解によって価値へ変わる

モデルの想定用途、評価条件、制約、適さない利用状況を文書化するモデルカードの考え方は、同じモデルが異なる責任を持つ業務へ無制限に転用されることを防ぐために提案された[8]。Bonsai についても、「文章を生成できる」という機能だけでは用途を決められない。入力された事実を保ったまま文体を整える仕事と、入力にない事情を推測して顧客への回答方針を作る仕事では、同じ文章生成でも必要な能力と誤りの影響が異なる。

既稿では、ローカルでモデルから応答を得ることと、入力範囲、検証手段、権限、保存経路を含む業務環境が成立することを分けて整理した[9]。Bonsai は、モデルが小さいことでこの区別を解消するものではない。むしろ、従来は大型モデルへまとめて渡していた仕事を、要約、分類、抽出、整形という小さな処理へ分け、それぞれの入力、出力、検証方法を固定する機会を作る。

会議録を例にすると、「内容を判断して報告書を作る」という依頼は、重要度の判断、事実の抽出、文章構成、責任者の決定を一度に含む。このままでは、どの段階で誤りが入ったかを特定しにくい。処理を「議題を列挙する」「明記された担当者と期限を抽出する」「各議題を 100 文字以内で要約する」に分ければ、出力形式を固定し、原文との対応を個別に確認できる。Bonsai の小ささは、このような短い処理を多数回実行するときに生きる。

1.15 GB という値が示す最終的な利点は、同じ仕事をより賢く解くことではなく、検証可能な小さな仕事を、低い常駐負荷で繰り返せることである。Bonsai の採用可否は、モデルが生成した文章の自然さだけでは決まらない。処理単位を狭めても必要な品質を維持できるか、誤りを入力と照合できるか、確認と修正を含む総作業時間が短くなるかを測定して初めて、約 1.15 GB という小ささが業務上の価値へ変わる。

2. 小ささが価値になるのは、常時反復する処理を任せるときである

2.1 反復回数が初期構築の負担を分散する

小型モデルの利益は、難しい問題を一度だけ解く場面より、同じ入力形式と確認手順を持つ処理を多数回繰り返す場面で生じる。会議録を 1 件だけ要約するために、推論器を導入し、モデルを取得し、出力形式を調整するなら、環境構築に費やす時間が手作業の要約時間を上回りやすい。反対に、毎日数百件の問い合わせを分類し、長い記録から読むべき箇所を絞り、入力中の項目を一定の形式へ変換するなら、初期構築と評価に要した時間を多数の処理へ分散できる。

この関係では、モデルの小ささが直接生産性を高めるわけではない。第 1 段階では、重み領域が小さいことで、取得、読み込み、常駐に必要な資源が減る。第 2 段階では、その軽さによってモデルを繰り返し起動する負担や、長時間保持する負担が下がる。そこで初めて、1 件当たり数秒または数十秒の短縮を、多数の処理へ積み上げられる。処理頻度が低い場合は第 2 段階まで進まず、構築、更新、評価に必要な固定費だけが残る。

たとえば、1 件の問い合わせを担当部署へ振り分ける作業が短時間で終わるとしても、同じ形式の問い合わせが継続して届くなら、自動分類による短縮は件数に比例して増える。一方、案件ごとに分類基準が異なり、毎回担当者が前提を説明し直す必要があるなら、入力準備の負担が繰り返し発生する。小型モデルと相性がよいのは、件数が多い処理一般ではなく、入力形式、出力形式、確認方法を再利用できる処理である。

2.2 常駐性は、短い処理の待ち時間を減らす

約 1 GB の重みを持つモデルでは、モデルを必要なときだけ起動する構成と、一定時間常駐させる構成の両方を検討しやすい。重いモデルでは、短い文章を処理するたびに大容量の重みを読み込むと、実際の生成より起動と読み込みに長い時間を要することがある。常駐させればこの待ち時間を避けられるが、今度は広いメモリ領域を長時間占有する。Bonsai の小ささは、起動時の負担と常駐時の負担を同時に抑え、数行の分類や抽出を必要な時点で実行する余地を広げる。

ただし、モデルファイルが小さくても、プロセス全体が小さいとは限らない。推論器、計算用の一時領域、トークナイザー、入力と生成履歴を保持する KV キャッシュが追加される。短い入力では軽く動作しても、長い記録を連続して処理したり、複数の要求を同時に受けたりすれば、メモリ消費と待ち時間は増える。常駐性を評価するには、モデル読み込み直後の値だけでなく、代表的な入力を処理したときの最大使用量と、連続実行後の状態を測定する必要がある。

2.3 閉じた情報経路は、正確性ではなく管理可能性を高める

ローカルで推論する構成では、会議録、問い合わせ内容、障害記録などを外部 API へ送らず、管理下の端末内で処理できる。外部事業者へ入力を渡さなければ、第三者側での保存、利用、通信経路に関する不確実性を減らせる。通信障害や外部サービスの停止に左右されず、ネットワークへ接続できない環境でも同じ処理を継続できる点も、反復処理では運用上の利点になる。

この利点が改善するのは、情報の処理場所と利用可能性である。出力の忠実性は別の評価軸として残る。モデルが端末内にあっても、長い会議録から期限を落とすことや、入力中に存在しない担当者を補うことは起こり得る。ローカル実行を理由に確認を省けば、外部送信を避けるための構成が、誤った結果を内部で反復する構成へ変わる。

閉じた情報経路を業務価値へ変えるには、入力の所在だけでなく、出力の利用先も制御する必要がある。要約を原文と並べて表示し、分類結果を候補として提示し、抽出値を入力中の文字列と照合できる構成なら、モデルの誤りを処理確定前に発見できる。反対に、分類結果をそのまま破棄、拒否、承認へ接続すれば、ローカルであることとは無関係に誤処理が実環境へ伝播する。

2.4 推論速度は、条件を固定しなければ比較できない

Bonsai の反復処理性能を確認する際、トークン毎秒という値だけを取り出しても、業務上の待ち時間は判断できない。ハードウェア、推論器の版、入力長、出力長、スレッド数、使用する命令セット、GPU へ割り当てる処理、ウォームアップの有無が異なれば、測定値は直接比較できない。特に短い分類や抽出では、生成速度よりモデル読み込みや初回出力までの遅延が大きな割合を占める。

MLPerf Inference が異なる計算環境を比較するために、測定条件と再現性を重視しているのは、単一の速度値が実行環境から切り離せないためである[10]。Bonsai の測定でも、CPU、メモリ、推論器の版、モデルファイル、入力、出力上限、スレッド数、実行回数を記録する必要がある。初回実行と、モデルやファイルが記憶装置のキャッシュへ載った後の実行も分けなければならない。

要約、分類、抽出では、入力長と出力長の性質も異なる。要約は長い入力を読み、比較的長い文章を生成する。分類は入力を読んだ後、数語だけを返す。抽出では入力が長くても、出力は限られた項目に収まる。平均的な生成速度が同じでも、入力処理が支配的な用途と出力生成が支配的な用途では、待ち時間の内訳が変わる。速度評価はモデル全体に一つの数字を付ける作業ではなく、業務処理ごとの時間構造を確認する作業になる。

2.5 採用可否は、人間を含む総作業時間で決まる

処理件数が多く、推論が高速でも、人間が出力を最初から書き直すなら利益は残らない。要約で重要事項が抜ければ原文を最初から読み直す必要があり、分類の誤りが多ければ担当者が全件を再確認する。抽出結果の形式だけが整っていても、入力にない値が混ざれば照合に時間を要する。モデルが短縮した時間より、確認と修正に追加された時間が大きければ、処理を自動化したように見えても業務工程は長くなる。

評価対象には、入力をモデルへ渡せる形へ整える時間、推論時間、原文との照合時間、修正時間、形式違反や応答失敗による再処理時間を含める必要がある。さらに、モデルの取得、推論器の更新、代表入力による回帰試験、障害対応も継続費用として残る。ローカル化によって外部 API の従量課金がなくなっても、費用は端末資源と保守作業へ移るため、処理単価が自動的にゼロになるわけではない。

既稿で、生成 AI の競争軸がモデル単体の性能から業務実装へ移ると整理したのは、出力品質を実際の業務価値へ変えるには、入力範囲、検証手段、判断主体、反映手順を設計する必要があるためである[11]。Bonsai では、公表された総合評価が比較対象の 8B モデルを下回るため、この関係が表面化しやすい。曖昧な仕事をまとめて任せれば確認負担が増えるが、定型的な処理へ分解すれば、軽い常駐モデルを反復的な中間処理として配置できる。

Bonsai の小ささが価値になる条件は、単に利用回数が多いことではない。入力と出力の形式を再利用でき、結果を短時間で検証でき、失敗しても処理確定前へ戻せる仕事が、十分な件数だけ存在することである。この条件を満たしたとき、約 1.15 GB という小ささは、保存容量の記録から、起動待ち時間、常駐負荷、外部通信、反復処理費用を減らす業務上の利益へ変わる。

3. Bonsai に任せるのは、入力内で閉じる仕事である

3.1 モデルの能力ではなく、仕事の境界を先に定義する

Bonsai に任せやすい仕事には共通する構造がある。処理に必要な事実が入力中に明記され、期待する出力形式が事前に決まり、結果を原文または規則と短時間で照合できることである。さらに、誤りが見つかったときに、送信、承認、削除、設定変更などが確定する前へ戻せなければならない。この条件がそろえば、モデルが扱う情報の範囲と、失敗した場合の影響を同時に狭められる。

たとえば、会議録から明記された担当者と期限を抽出する処理では、情報源が会議録内に限定される。出力を担当者名、期限、根拠文の 3 項目へ固定すれば、担当者名が原文中に存在するか、期限が日付形式に適合するか、根拠文が実際の記述と一致するかを確認できる。モデルが誤っても、抽出結果を議事録へ自動登録せず候補として表示する限り、修正してから確定できる。

同じ会議録を使っても、「遅れている案件の責任者を決める」という依頼は構造が異なる。責任者が文書中に明記されていなければ、モデルは役職、発言内容、過去の慣行などから推測する必要がある。出力の妥当性は文字列照合では確認できず、組織内の責任分担や案件の経緯を理解した人間の判断が必要になる。前者は入力内の事実を変換する処理であり、後者は入力を材料として新しい判断を作る処理である。

Bonsai のような小型モデルでは、この違いを曖昧にしないことが特に重要になる。処理範囲が広がるほど、入力にない情報を補う必要が増え、モデルの一般知識、推論能力、長い文脈の保持能力へ依存する割合が大きくなる。仕事を入力内で完結する単位まで分解すれば、モデルの能力上限を業務上の危険へ直接つなげずに済む。

3.2 入力閉包性は、事実生成と情報変換を分ける

入力閉包性とは、出力に必要な情報が入力文または明示的に与えた資料の中に存在することである。要約であれば要約対象の文章、抽出であれば取り出す項目、分類であれば判断材料と分類規則が入力側にそろっている状態を指す。モデルは新しい事実を発見するのではなく、既に与えられた情報の選択、圧縮、並べ替え、形式変換を担う。

入力閉包性が高い処理でも、指示が曖昧なら出力範囲は広がる。「重要な点をまとめる」という依頼では、何を重要とみなすかをモデルが決める。会議録に予算、期限、担当者、技術課題が含まれている場合、どの項目を残すかは利用目的によって異なる。これを「決定事項、未決事項、担当者、期限をそれぞれ抽出し、記載がない項目は空欄にする」と分解すれば、重要度の判断をモデルへ渡さずに済む。

分類処理でも同様である。「適切な部署へ分類する」だけでは、部署の役割や例外規則をモデルが推測する。分類先をあらかじめ列挙し、それぞれの条件を入力へ含めれば、モデルは有限の候補から選択する処理になる。判断材料が不足している場合に「判定不能」を返す選択肢も設ければ、無理に一つへ振り分ける必要がなくなる。

入力閉包性は、モデルへ知識を与えれば自動的に成立する性質ではない。必要な情報が資料中に存在していても、長い文書の別々の箇所へ分散し、例外条件や否定表現を組み合わせなければならない場合、処理は複雑になる。入力内に情報があることと、その情報を小型モデルが安定して結び付けられることは分けて評価する必要がある。

3.3 検証可能性は、出力形式と根拠の残し方で決まる

モデルの出力を業務へ利用するには、正しさを人間の印象だけで判断しない構成が必要になる。自然な文章は読みやすいが、流暢さによって誤りが見えにくくなる。Bonsai が「担当者は田中、期限は 7 月 31 日」と答えても、その値が原文に存在するか、別案件の記述を混ぜていないかは、回答文だけでは確認できない。

検証可能性を高めるには、回答とともに根拠を返す。担当者名や期限に加えて、その値を取得した原文の一文を出力させれば、利用者は判断結果ではなく対応関係を確認できる。分類では選択した分類名だけでなく、分類条件に該当した入力箇所を示す。要約では各項目へ参照位置を付ける。こうした構造にすると、出力の正誤を全文読解ではなく局所的な照合で確認できる。

形式検証も有効である。分類結果を定義済みの列挙値へ限定し、期限を日付形式へ固定し、必須項目が欠けていないかを機械的に確認すれば、少なくとも構造上の失敗を後段へ流さずに済む。ただし、形式が正しいことと内容が正しいことは別である。存在しない期限を正しい日付形式で返すことも、誤った部署名を許可された分類値として返すこともできる。

このため、検証は二層に分ける必要がある。第 1 層では、形式、列挙値、日付、必須項目などを機械的に確認する。第 2 層では、抽出値や要約内容が入力中の根拠と対応しているかを確認する。小型モデルの出力を安全に利用するには、構文上の正しさを内容上の正しさと取り違えないことが必要になる。

3.4 可逆性は、モデルの誤りを業務上の損失へ変えない

モデルの精度が同じでも、出力の使い方によって危険の大きさは変わる。問い合わせを「技術」「請求」「契約」のいずれかへ分類し、担当者へ候補として表示する処理では、誤分類が起きても人間が振り直せる。分類結果に基づいて問い合わせを自動削除したり、契約上の回答を自動送信したりすれば、同じ誤分類が顧客対応や記録消失へつながる。

可逆性を確保するには、モデル出力と確定操作を分離する。文章校正では修正版を下書きとして残し、送信操作を人間へ委ねる。抽出では登録前に値と根拠を並べて表示する。分類では処理先を提案するだけにし、警告の抑止や申請の拒否へ直結させない。モデルは候補を作るが、業務状態を変更する主体にはならない。

この分離によって、モデルが誤った場合の損失を局所化できる。誤った候補が一件表示されることと、誤った判断が複数システムへ反映されることでは、復旧に必要な時間が異なる。モデルの精度を上げることだけでなく、誤りがどこまで伝播するかを制御することが、実務投入の条件になる。

NIST の AI リスク管理枠組みは、信頼性、安全性、透明性などの特性を固定的な合否として扱わず、利用状況に応じて管理、状況把握、測定、対処を継続する構造を示している[12]。同じ出力誤りでも、個人用の下書きに残る場合と、顧客通知として送信される場合では影響が異なる。評価対象にはモデルの正答率だけでなく、出力が通過する業務経路を含める必要がある。

生成 AI 向けの補足文書も、導入時の性能試験だけでなく、利用中に発生する失敗、利用目的の変化、組織の許容リスク、管理資源に応じて対策を見直す必要を示している[13]。定型分類として導入した処理が、後から自動拒否へ転用されれば、同じモデルでも必要な管理水準は変わる。業務投入の境界はモデル導入時に一度決めて終わるものではなく、出力の利用方法が変わるたびに再確認する必要がある。

3.5 判定不能を失敗ではなく正常な出力として設計する

入力内で閉じる仕事に限定しても、すべての入力が条件を満たすわけではない。期限が記載されていない議事録、複数の分類条件へ同時に該当する問い合わせ、途中で文章が欠けた障害報告などが混ざる。こうした入力へ必ず回答を返すよう求めると、モデルは不足した情報を補い、もっともらしい値を生成しやすくなる。

処理条件を満たさない入力では、「該当なし」「根拠不足」「複数候補」「判定不能」を返せるようにする。これはモデルが何もできなかったことを意味しない。自動処理できる事例と、人間へ渡すべき事例を区別できたという結果である。自動化率を高く見せるために未回答を減らすと、誤答率と確認負担が増え、小型モデルを使う利点を失う。

人間と AI の対話設計では、AI の提案を拒否しやすくし、誤りを訂正でき、利用者が機能の限界を理解できる構成が求められる[14]。Bonsai の出力画面でも、生成結果だけを完成形として表示するのではなく、採用、修正、破棄、判定不能として扱う経路を用意する必要がある。

機械学習研究では、すべての入力をモデル自身が処理せず、難しい事例を後段の判断者へ移す方式が提案されている[15]。後続研究も、予測器だけの正解率ではなく、モデルが処理した事例と専門家へ移した事例を合わせたシステム全体を評価している[16]。Bonsai へ同じ学習方式を組み込む必要はないが、自動処理の対象外を明示し、人間へ戻す経路を通常の運用として設計する考え方は共通する。

実装上は、入力の長さ、必須項目の存在、分類候補の競合、出力形式の失敗などを前後のプログラムで確認できる。条件を外れた入力は Bonsai へ渡さないか、結果を確定処理へ送らず確認待ちへ置く。モデル自身の「自信があります」という文章を信頼度として利用するのではなく、入力条件と検証結果によって退避を決める必要がある。

3.6 Bonsai は処理主体になれても判断主体にはならない

入力閉包性、検証可能性、可逆性、退避経路を備えた構成では、Bonsai は業務処理の一部を担当できる。文章を短くし、指定された項目を取り出し、有限の分類先を提示し、表現を整える処理である。これらは人間が定めた目的と規則の内側で、情報の形を変える仕事に当たる。

組織としての判断は別の層に残る。顧客への謝罪内容、申請の承認、障害原因の確定、契約解釈、担当者の責任認定には、入力文だけでは完結しない事情が含まれる。判断によって利益や不利益を受ける相手が存在し、決定理由を説明し、結果へ責任を持つ主体も必要になる。自然な文章を生成できることは、この責任を引き受けられることを意味しない。

既稿で医療 AI を扱った際には、中心となる問題を正答率の競争ではなく、説明、最終判断、結果責任を誰が引き受けるかという配置として整理した[17]。医療と一般業務では影響の大きさや制度条件が異なるが、モデル出力と組織判断を区別する構造は共通する。分類結果を担当者候補として表示する処理と、その結果だけで申請を拒否する処理では、同じ出力でも意思決定上の意味が変わる。

Bonsai を実務へ残す条件は、モデルへ判断を任せる範囲を広げることではない。人間が判断する前に必要となる要約、分類、抽出、整形を切り出し、それぞれの情報源、出力形式、検証方法、失敗時の退避先を固定することである。約 1.15 GB のモデルが担うのは、組織の意思を決める役割ではなく、意思決定へ入る前の情報処理を低い常駐負荷で反復する役割である。

4. 要約、校正、分類、抽出は同じように見えて責任が異なる

要約、校正、分類、抽出は、いずれも入力された文章を別の形へ変換する処理である。しかし、モデルが変更してよい情報の範囲と、誤った場合に失われるものは異なる。要約では情報を選別し、校正では表現を変更し、分類では後続処理の候補を選び、抽出では入力中の値を構造化された項目へ移す。それぞれに同じ確認方法を当てはめると、文章として自然な誤答や、形式だけが正しい誤答を見逃す。

Bonsai の投入範囲を決めるには、「文章を処理できるか」ではなく、各処理でモデルへ認める自由度を定義する必要がある。要約では何を残すかを選ぶ自由、校正ではどのように言い換えるかという自由、分類では候補を一つ選ぶ自由、抽出では入力中のどの記述を値として採用するかという自由が生じる。この自由度を制約し、用途ごとに異なる失敗を検出できる場合に、出力を実務工程へ置ける。

4.1 要約は、原文を捨てるためではなく読む位置を絞るために使う

要約では、入力文書に含まれる情報の一部を残し、残りを削る。文章を短くする以上、情報の選別は避けられない。モデルが正確に文章を書き換えたとしても、期限、否定、例外、担当者など、利用者にとって重要な条件を選ばなければ、要約全体の用途を満たさない。要約の品質は、文法的に自然であることだけでなく、何を残し、何を落としたかによって決まる。

生成要約の研究では、流暢に読める文章であっても、入力文書から支持されない内容が含まれることが人手評価によって確認されている[18]。これは、原文中の情報を落とす問題とは異なる。原文にない人物関係や出来事を補い、短い文章の中へ新しい事実を作る問題である。要約結果が読みやすいほど、利用者は文章上の不自然さから誤りを発見しにくくなる。

自動評価指標だけでも、業務上の正しさを十分には測れない。原文と同じ単語を多く含む要約は文字列上の類似度を高くできるが、否定を落としたり、複数の案件を混ぜたりしても、一定の得点を得る場合がある。SummEval は、複数の自動指標が人間の専門的な評価と異なる側面を測ることを示し、要約評価を単一の得点へ還元する限界を整理している[19]。

事実誤りの形も一つではない。FRANK は、人物や物体の取り違え、出来事の誤り、関係の反転、原文の文脈と整合しない記述などを区別している[20]。たとえば「更新は延期された」を「更新を実施した」と要約する誤りと、「田中が確認する」を「佐藤が確認する」と要約する誤りでは、誤った箇所も業務上の影響も異なる。Bonsai の試験でも、単に要約全体を正解または不正解とせず、数値、担当者、期限、否定、例外、因果関係を分けて確認する必要がある。

この性質を踏まえると、要約は原文の代替ではなく、原文へ戻るための索引として利用するのが安定する。会議録であれば議題ごとの概要を作り、メールスレッドであれば話題の変化と未回答事項を示し、障害記録であれば発生、調査、暫定対応、復旧の時系列を並べる。各項目に根拠となる原文の一文や位置を付ければ、利用者は要約だけを信頼せず、重要な箇所を短時間で確認できる。

一方、契約上の義務、支払期限、例外条項、監査上の不備などを漏れなく残す処理では、要約による選別そのものが危険になる。全体の 99％を正しく圧縮しても、残りの 1％に違約条件が含まれていれば、業務上の目的を満たさない。欠落が許されない情報は、自由な要約ではなく、項目を定義した抽出と原文照合によって扱う必要がある。

Bonsai による要約の役割は、長文を読まなくてよい状態を作ることではない。読む順序と確認範囲を狭め、原文へ到達するまでの時間を短縮することである。この配置なら、要約に含まれる情報の選別を利用しながら、選別によって失われた情報を原文から回収できる。

4.2 校正は、内容を決めさせない限り実用性が高い

校正では、入力中の事実と判断を維持しながら、表記、文体、語順、文章構造を変更する。誤字脱字の修正、敬体と常体の統一、箇条書き化、冗長表現の圧縮、件名の生成などは、入力と出力を比較しやすい。モデルへ許される変更範囲を文章表現に限定すれば、小型モデルでも実務へ配置しやすい。

たとえば、「7 月 31 日までに調査結果を提出する」という入力を、「調査結果は 7 月 31 日までにご提出ください」と整える処理では、期限と依頼内容が保持されているかを確認できる。文体は変わっても、事実関係は変わらない。入力と出力に含まれる日付、金額、固有名詞、否定表現を比較すれば、意味の変更を局所的に検出できる。

校正が不安定になるのは、入力中に不足している内容まで補わせた場合である。「丁寧な謝罪文にする」という指示だけを与えると、モデルは原因の認定、責任の範囲、再発防止策、補償の可能性まで追加することがある。文章としては自然でも、組織として決定していない事実や約束が含まれれば、表現変換ではなく意思決定になる。

依頼内容を「入力中の事実を変更せず、敬体へ統一し、200 文字以内に短縮する」と定義すれば、モデルが扱う範囲を狭められる。不明な箇所を推測せず、入力中にない日付、金額、人物、原因、約束を追加しない条件も必要になる。内容が足りない場合は文章を完成させず、不足箇所を残すほうが安全である。

確認方法も、文章全体を読み直すだけでは足りない。固有名詞、数値、日付、製品名、否定表現を入力と出力から取り出し、増減を比較する。入力に存在しない値が出力へ追加されていれば、人間の確認対象へ戻す。文章の読みやすさと事実の維持を別々に検査することで、表現だけを整える役割を保てる。

校正結果は、完成した通知や返信として直接送信せず、下書きとして止める。送信前に人間が内容を確認できれば、誤った言い換えや過剰な約束を修正できる。Bonsai が担うのは、組織の回答を決める処理ではなく、決定済みの内容を読みやすい文章へ移す処理である。

4.3 分類は、有限の選択肢と退避先を持たせる

分類では、入力をあらかじめ定義した候補の一つへ対応させる。問い合わせ種別、文書種別、担当部署候補、障害区分などは、自由文を生成するより出力範囲を狭くできる。分類先を有限の列挙値へ限定すれば、許可されていない値や説明文が返った場合に形式違反として検出できる。

出力候補を限定しても、分類規則が入力に含まれていなければ、モデルは一般知識や表面的な単語へ依存する。たとえば「請求」「契約」「技術」「その他」という分類先だけを示しても、利用者登録の変更が契約部門と技術部門のどちらに属するかは組織ごとに異なる。分類名とともに、各分類へ該当する条件、除外条件、境界事例を与える必要がある。

分類結果には「判定不能」または「確認が必要」を含める。複数の条件へ同時に該当する問い合わせや、必要な情報が欠けた入力を無理に一つへ振り分けると、誤分類が増える。自動処理率を上げるために退避先を削ると、形式上は全件処理できても、人間が後から振り直す件数と確認時間が増える。

平均正解率だけでは、業務上の危険を評価できない。一般的な質問を別部署へ送る誤りは、担当者が転送すれば回復できる。一方、セキュリティー警告を通常の問い合わせへ分類し、自動的に優先度を下げれば、対応遅延へつながる。分類ごとに誤りの影響が異なるため、重要な分類については、該当する入力を取りこぼさない割合を個別に測る必要がある。

分類結果の後続処理も制約する。担当部署の候補を表示する処理や、確認待ちの一覧へ並べる処理には利用できる。結果だけを使って問い合わせを削除し、警告を抑止し、申請を拒否する構成では、誤分類が不可逆な操作へ変わる。分類は処理を確定する判断ではなく、次に人間が確認する範囲を狭めるために使う。

4.4 抽出は、入力中に存在する値だけを取り出す

抽出では、文章中に明記された日時、担当者、期限、製品名、版番号、エラー番号、依頼事項などを、定めた項目へ移す。出力項目を事前に定義できるため、要約より情報の選別基準を明確にしやすい。入力中に値が存在しない場合は空欄または該当なしとし、推測によって項目を埋めないことが基本になる。

たとえば障害報告から、発生時刻、対象システム、エラー番号、暫定対応、復旧時刻を抽出する場合、それぞれの値と根拠文を返させる。日付形式、許可された製品名、エラー番号の書式はプログラムで確認できる。さらに、出力値が入力中に実際に存在するかを照合すれば、原文にない値を補った出力を検出できる。

構造化出力を安定させる方法として、文法制約がある。Grammar-Constrained Decoding は、生成時に許可する構文を限定し、情報抽出などの出力を定めた構造へ適合させる方法を示している[21]。自由文の指示だけに依存する場合と比べ、括弧の不足、項目名の変化、余計な説明文の混入を減らせる。

JSON Schema を用いた評価でも、出力が構造へ適合したかだけでなく、生成効率、対応できる制約の範囲、内容品質を別々に測る必要があるとされている[22]。構文上正しい JSON が返れば後段のプログラムは読み取れるが、担当者と期限が入れ替わっていれば業務上は誤りである。構造適合率は処理可能性を示すが、抽出精度を代替しない。

小型モデルを対象とした新しい実験では、強い構造制約によって形式上妥当な出力が増える一方、回答内容の正確性が下がり、構造は正しいが意味が誤っている出力が増える場合が報告されている[23]。この結果は新しいプレプリントによるものであり、すべての小型モデルへそのまま適用できる一般則ではない。それでも、Bonsai の試験で形式適合と内容正解を別の指標として記録する必要性を示している。

抽出の評価では、項目ごとに正解を用意し、正しい値を取得した件数、存在する値を落とした件数、存在しない値を追加した件数を分ける。担当者を空欄にした失敗と、原文にない担当者名を作った失敗では、後者のほうが利用者に誤った事実を提示する。空欄を許容することで自動抽出率は下がるが、推測値が業務記録へ入る危険を減らせる。

4.5 同じ入力でも、用途を変えると責任の位置が変わる

一つの会議録に対しても、四つの処理は異なる役割を持つ。要約では議題ごとの概要を作り、校正では人間が作成した議事録の表現を整え、分類では各議題を技術、契約、運用などへ振り分け、抽出では担当者と期限を項目へ移す。入力は同じでも、モデルが変更できる情報の範囲と、確認すべき失敗は一致しない。

要約で担当者を落とすことは情報の欠落であり、校正で担当者名を変えることは事実の改変である。分類で担当部署を誤ることは処理経路の誤りであり、抽出で存在しない期限を追加することは事実の生成である。すべてを「回答が間違った」という一つの評価へまとめると、修正方法と影響範囲を判断できない。

この違いから、Bonsai に共通の万能なプロンプトを一つ用意する構成は適さない。用途ごとに入力条件、出力形式、禁止する変更、判定不能時の値、確認方法を分ける必要がある。要約へ使う指示を抽出へ流用すれば、モデルは項目を選別して落とす。校正へ使う指示を要約へ流用すれば、長さを保ったまま表現だけを変え、必要な圧縮ができない。

Bonsai の業務投入では、自然な文章を生成できたことを成功条件に置かない。要約では確認範囲を狭められたか、校正では事実を維持できたか、分類では重要な入力を正しい経路へ残せたか、抽出では原文中の値を正確に移せたかを測る。用途ごとに責任を分けることで、小型モデルの出力を一括して信用せず、検証可能な処理だけを残せる。

5. Bonsai 8B は本家 llama.cpp で動く段階へ入った

5.1 推論経路の標準化が、最小環境の条件を変えた

Bonsai 8B の公開直後は、1-bit の Q1_0 形式を処理するために、PrismML が管理する llama.cpp の派生実装を利用する手順が中心だった。モデルの重み形式を通常の GGUF 読み込み処理が解釈できず、Q1_0 に対応した読み込み処理と計算処理を別途必要としたためである。この段階では、Bonsai を導入することはモデルファイルを取得するだけでは済まず、特定の推論器を選び、その更新状況を追跡することまで含んでいた。

2026 年 7 月 21 日時点の公式 Bonsai-demo は、1-bit Bonsai で使われる Q1_0 が本家 llama.cpp へ完全に統合されたと説明している[24]。公式モデルカードの利用案内にも、本家 llama.cpp を取得して構築し、Hugging Face 上の Bonsai 8B Q1_0 を指定してコマンドライン推論と OpenAI 互換サーバーを起動する手順が掲載されている[2]。Bonsai 固有の形式を扱うためだけに別系統の推論器を維持する必要が薄れ、標準的な llama.cpp の実行経路へ接続できる状態になった。

この変化が減らすのは、インストール手順の数だけではない。本家へ統合される前は、Bonsai の対応状況、推論器の更新、CPU や GPU の対応、上流実装との差分を個別に確認する必要があった。本家 llama.cpp へ入れば、モデルの読み込み、推論、HTTP サーバー、構築手順を同じプロジェクトの更新経路で追跡できる。推論器の特殊性が小さくなることで、Bonsai の評価対象をモデル形式と出力品質へ寄せやすくなる。

ただし、本家へ統合されたことは、すべての環境で同じ速度と安定性が得られることを意味しない。CPU の命令セット、コンパイラ、推論器のコミット、使用する計算基盤によって実行結果は変わる。統合によって共通の実装経路は得られたが、個別環境における性能と再現性は、構築条件を固定して確認する必要がある。

5.2 公式資料の更新差を、そのまま構築手順へ持ち込まない

Bonsai の公式資料には、更新時期の異なる手順が併存している。モデルカード上部の利用案内は本家 llama.cpp を使用する現在の経路を示す一方、同じページの詳細説明には PrismML の派生実装を取得する旧手順が残っている。どちらも公式資料に書かれているため、資料の出所だけを見ても現在の推奨経路を判定できない。

継続的に更新されるソフトウェアでは、文書の一部だけが新しい状態へ置き換わり、過去の手順が同じページ内に残ることがある。古い手順が直ちに動かなくなるとは限らないが、現在の依存関係、修正状況、対応基盤を反映している保証はない。公式という属性と、現在の実装へ適合していることは分けて確認する必要がある。

最小環境では、本家 llama.cpp を基準経路とし、公式 Bonsai-demo の対応表と、実際の構築結果を突き合わせる。資料に「統合済み」と書かれていることだけで完了とせず、対象コミットの llama.cpp が Bonsai 8B Q1_0 を読み込み、単発推論とサーバー起動を完了できることを確認する。この二重確認によって、文書の更新差と実装状態のずれを切り分けられる。

再現条件として記録するのは、取得日だけでは足りない。llama.cpp のコミット番号、Bonsai 8B のモデルファイルまたはリビジョン、構築時の設定、コンパイラ、実行引数を残す。同じ URL を後日参照しても内容が更新されるため、「最新版を使用した」という記録では、同じ結果を再現できない。

5.3 llama.cpp は、推論と API を一つの実装で確認できる

llama.cpp は、GGUF 形式のモデルをローカルで実行する C/C++ 実装であり、対話や単発推論に使う llama-cli と、HTTP 経由で推論を提供する llama-server を含んでいる[25]。Bonsai 8B Q1_0 を本家実装が直接読み込めるなら、モデルの取得、読み込み、文章生成、API 提供までを一つの推論器で確認できる。

この一貫性は、最小環境の評価に向いている。コマンドライン推論では、通信、認証、画面表示を介さず、モデルの読み込みと生成処理だけを確認できる。そこで正常な応答を得た後、同じ推論器の llama-server を起動すれば、HTTP 通信を加えたときの差だけを調べられる。別の API 実装や管理画面を導入する場合と比べ、単発推論とサービス化の間で変わる要素が少ない。

構築順序は、推論器の機能を段階的に増やす形になる。最初に llama-cli で固定入力を処理し、モデル読み込み、終了状態、生成結果、所要時間を確認する。次に llama-server を起動し、同じ入力を HTTP から送信する。両者の出力と資源使用量を比較すれば、モデル本体の問題と、サーバー経由で追加される処理を分離できる。

OpenAI 互換 API を利用できることも、既存の大規模な基盤へ接続するためだけの機能ではない。固定した要求を繰り返し送信し、応答時間、形式違反、出力変動を自動計測するための最小境界になる。コマンドラインの対話だけでは、人手による入力差が混ざる。HTTP 要求を固定すれば、要約、分類、抽出の同じ試験を繰り返し実行できる。

5.4 本家 llama.cpp を使うことと、Bonsai 固有の確認は分ける

推論器が標準化されても、モデルの性質まで llama.cpp の資料だけで確認できるわけではない。llama.cpp が説明するのは、GGUF の読み込み、計算基盤、コマンドライン、HTTP サーバーなどの実行機能である。Bonsai 8B の重み形式、モデルサイズ、ライセンス、想定される使い方は、PrismML のモデルカードと公式資料を参照する必要がある。

推論器とモデルの役割を混同すると、障害の原因を判断しにくくなる。モデルファイルを読み込めない場合は、形式対応、ファイル破損、モデル指定、推論器の版を確認する。読み込み後に日本語出力が不安定な場合は、プロンプト形式、生成設定、モデル能力を確認する。HTTP 要求だけが失敗する場合は、サーバー設定、要求形式、ポート、接続経路を調べる。実行経路を分けることで、モデル品質の問題を構築問題として扱う誤りを避けられる。

本家 llama.cpp を基準にする利点は、Bonsai 固有の検証が不要になることではない。汎用的な推論部分を標準実装へ任せ、Bonsai 固有の評価をモデル形式、資源使用量、日本語出力、業務タスクの品質へ集中できることである。共通部分を既存実装へ寄せるほど、独自に確認すべき範囲が明確になる。

5.5 Bonsai-demo は、公式の選択肢と対応状況を確認する入口になる

Bonsai-demo は、本家 llama.cpp への統合後も役割を持つ。Bonsai と Ternary-Bonsai というモデル系列、1.7B、4B、8B、27B という規模、CPU、Metal、CUDA、Vulkan、ROCm などの対応状況を、PrismML が一つの場所で整理しているためである[24]。特定の推論器だけを見る場合より、Bonsai 系列全体の現在位置を把握しやすい。

一方、Bonsai-demo のセットアップスクリプトは、最小環境の目的を自動的に理解してモデルを選ぶわけではない。何も指定せずに実行すると、既定では Ternary-Bonsai 27B が選択される[24]。1-bit Bonsai 8B を検証したい場合に既定値を使えば、重み形式、モデル規模、必要メモリ、機能が異なる別のモデルを測定することになる。

この差は、単なる容量の違いではない。1-bit Bonsai と Ternary-Bonsai では重みの値域が異なり、8B と 27B ではパラメーター数、必要資源、想定機能が変わる。27B 系列の画像入力や長い文脈などを含む評価結果を、8B の最小環境へ適用することはできない。モデル系列と規模を明示しなければ、構築に成功しても、検証対象を取り違えたことになる。

Bonsai-demo を使う経路では、少なくともモデル系列とサイズを明示し、実際に取得されたファイル名、容量、リビジョンを確認する。スクリプトが正常終了したという結果だけでは、目的のモデルが選ばれたことを保証しない。自動化された手順ほど、入力した条件と生成された成果物の対応を記録する必要がある。

5.6 最小環境では、選択肢の多さより評価対象の少なさを優先する

Bonsai 8B を動かす経路として、本家 llama.cpp、Bonsai-demo、高水準の管理ツールを選べる。しかし、最初の検証で必要なのは選択肢を最大化することではない。モデル、推論器、入力、出力という最小限の要素だけを残し、失敗時に原因を追える状態を作ることである。

最小環境の基準には、本家 llama.cpp を採用する。Bonsai 8B Q1_0 のモデルファイルを一つだけ使用し、最初に llama-cli、次に llama-server を確認する。Bonsai-demo は、公式の対応状況と別経路を確認する補助資料として利用する。高水準の管理ツールは、モデル単体の評価が終わり、利用者向けの操作性が必要になった段階で追加する。

この順序なら、コマンドラインで失敗した処理を管理画面の設定で解決しようとする混乱を避けられる。モデルが読み込めるか、入力へ応答できるか、API として呼び出せるかを一段ずつ確認し、各段階で変化した要素だけを調べられる。構成を小さく保つ目的は、導入を簡単に見せることではなく、Bonsai 8B Q1_0 の実行条件を観察可能にすることにある。

5.7 標準化によって、Bonsai の採用判断は実装より用途へ近づく

Bonsai 8B Q1_0 が本家 llama.cpp で動くようになったことで、導入可否を左右する最大の論点は、専用フォークを維持できるかどうかから、約 1.15 GB のモデルが対象業務で十分な品質を出せるかへ移る。推論器の特殊性が小さくなれば、構築と保守の固定費が下がり、小型モデルを試験するための入口も広がる。

それでも、標準的な推論器で起動できることは採用条件の一部にすぎない。要約で重要事項を落とす、分類で重要な入力を取りこぼす、抽出で存在しない値を補うなら、構築が容易でも業務へは置けない。反対に、限定した処理で十分な品質を保ち、低いメモリ使用量と短い待ち時間を確認できれば、専用実装の保守負担を理由に候補から外す必要は薄くなる。

本家 llama.cpp への統合が持つ意味は、Bonsai を一般的な 8B モデルと同じ品質にしたことではない。モデルを動かすための特殊な経路を縮小し、小ささ、速度、品質、確認時間という本来の評価へ進みやすくしたことである。ここから先の採用判断は、推論器の珍しさではなく、Bonsai が検証可能な業務処理をどれだけ低い総費用で反復できるかによって決まる。

6. 最小環境は、Bonsai 以外の要因を評価から排除する

6.1 最小環境は、構成要素を減らすことではなく評価変数を固定することである

最小環境の目的は、コマンド数を減らして構築を簡単に見せることにはない。Bonsai 8B Q1_0 のモデル読み込み、生成処理、HTTP 経由の呼び出し、資源消費を個別に観察し、それ以外の要因を評価結果へ混入させないことにある。モデルが正しい文章を返さなかった場合に、原因がモデル能力、入力形式、生成設定、推論器のいずれにあるかを追跡できる状態を作る。

検索基盤を加えると、取得対象の選択、文書分割、検索順位、検索漏れが回答品質へ影響する。利用画面を加えると、システム指示、会話履歴、入力加工、保存済み設定が推論結果へ混ざる。エージェントを加えると、計画作成、道具の選択、実行結果の解釈、再試行という別の判断段階が生じる。周辺機能を先に増やせば、誤回答が Bonsai 自身によるものか、入力へ渡されなかった情報によるものかを区別できなくなる。

初期検証では、入力から出力までの経路を一方向に固定する。検索や履歴から動的に入力を作らず、同じ固定プロンプトをコマンドラインまたは HTTP から渡す。推論器とモデルを固定し、生成結果と測定値を保存する。この構成なら、入力、モデル、推論器、実行条件のうち一つだけを変更し、その変更が出力と資源使用量へ与えた影響を比較できる。

この経路で確認できない機能は、Bonsai 8B の単体評価が終わった後に追加する。最初から実運用に近い構成を再現するのではなく、モデルが入力を読み、指定された形式で応答し、その処理にどれだけの時間とメモリを使ったかを観察可能にすることを優先する。

6.2 各構成要素には、一つの役割だけを持たせる

最小環境へ含めるのは、Git、C++ コンパイラ、CMake、本家 llama.cpp、Bonsai 8B Q1_0、HTTP 要求を送るクライアント、測定ログである。いずれも、モデルを取得し、推論器を構築し、入力を渡し、結果を記録するために必要な要素である。会話履歴の管理、文書検索、利用者認証、画面表示など、出力品質の評価に直接必要のない処理は加えない。

構成要素を限定するだけでなく、それぞれの責任を重複させないことも必要になる。llama-cli は単発推論の確認に使い、llama-server は HTTP 境界の確認に使う。モデルの取得先は LLAMA_CACHE で指定した検証用ディレクトリへ集約し、実行条件と出力はログへ残す。複数の起動方法や保存先を同時に使うと、どのモデルファイルと設定で生成した結果かを後から特定できなくなる。

この構成では、モデルファイルを自動取得する場合でも、実際に使用されたファイルを確認する。モデル指定が同じでも、配布元のリビジョンが更新されれば内容が変わる可能性がある。推論器のコミットとモデルのチェックサムを組み合わせて記録することで、生成結果を一つの実行環境へ対応付けられる。

6.3 CPU 基準は、性能を最大化するためではなく推論経路を分離するために使う

最初の成立確認では、GPU への処理移送を無効にし、CPU だけで推論する。これは CPU が Bonsai 8B の最適な配置先であると先に結論づけるためではない。モデルの読み込み、Q1_0 の処理、日本語生成、文脈管理という基本経路を、GPU ドライバ、実行環境、メモリ転送、計算基盤固有の最適化から分離するためである。

GPU を最初から利用すると、モデルを読み込めない場合に、Q1_0 の形式対応、GPU 用カーネル、ドライバ、推論器の構築設定のどこに原因があるかを調べなければならない。CPU だけで正常に生成できれば、少なくともモデルファイル、トークナイザー、プロンプト形式、推論器の共通部分が成立したことを確認できる。その後に GPU オフロードを有効にすれば、追加された計算基盤による速度、メモリ、構築手順の差だけを比較できる。

CPU 基準では、使用するスレッド数と GPU オフロードを明示する。GPU オフロードを 0 層に固定していても、スレッド数、CPU の省電力制御、他のプロセスの負荷によって速度は変わる。測定時には同じ入力を複数回実行し、初回実行と後続実行を分けて記録する。初回にはモデルファイルの読み込みや記憶装置のキャッシュ状態が影響するため、後続実行だけを示すと実際の起動負担を見落とす。

GPU を追加する段階でも、CPU の結果を置き換えず比較基準として残す。GPU 利用によって生成速度が上がっても、構築依存関係、待機時メモリ、消費電力、別端末への再現性が悪化する場合がある。最小モデルを採用する目的は最高速度を得ることではなく、必要な品質を満たす処理を最小の総費用で継続することにある。

6.4 文脈長は、モデルの上限ではなく対象業務から決める

公式モデルカードは Bonsai 8B の文脈長として 65,536 トークンを示している[2]。文脈長は、モデルへ一度に渡して保持できる入力と生成履歴の上限を表す。ただし、上限まで入力できることと、その長さを初期設定として使うべきことは同じではない。

長い文脈を扱うと、KV キャッシュが増える。KV キャッシュは、注意機構が過去の入力を毎回最初から計算し直さずに済むよう、各トークンに対応する中間結果を保存する領域である。重みは約 1.15 GB に固定されていても、KV キャッシュは指定した文脈長と実際に処理したトークン数に応じて増える。文脈長を最大値へ設定すれば、Bonsai の小さな重み領域だけを見たときには分からないメモリ負担が発生する。

最初の試験では、文脈長を 4,096 トークン、出力上限を 128 トークン程度へ固定する。この範囲なら、短い会議記録、問い合わせ、メール、障害記録を対象に、要約、分類、抽出、校正の基本的な挙動を確認できる。入力を短く固定することで、長文読解の失敗と、短い指示への追従失敗を区別しやすくなる。

文脈長を広げるのは、4,096 トークンでは収まらない具体的な用途が確認された後になる。たとえば、長い会議録全体を一度に要約する必要がある場合は、8,192、16,384 と段階的に増やし、最大メモリ、初回応答時間、要約の欠落、指示保持の変化を測定する。一度に最大値まで増やすと、どの長さから速度と品質が崩れたかを確認できない。

6.5 単発推論と HTTP 推論を分けて確認する

最小環境の検証は、llama-cli による単発推論から始める。コマンドラインでモデルを直接読み込み、固定入力を渡せば、ネットワーク通信、要求形式、サーバー状態を介さずに生成処理を確認できる。この段階でモデル読み込み、終了状態、日本語出力、所要時間、最大メモリを記録する。

単発推論が成立した後に llama-server を起動する。HTTP 経由では、要求を JSON へ変換し、サーバーが入力を受け、推論結果を応答へ変換する処理が加わる。llama-cli と同じ入力、文脈長、出力上限、乱数種を使用すれば、サーバー経由で追加された待ち時間と出力差を確認できる。

HTTP 要求の固定は、後続の業務評価にも必要になる。要約、分類、抽出の入力を同じ形式で繰り返し送り、応答時間と結果を自動保存できるからである。人間がターミナルへ毎回入力すると、空白、改行、指示表現の違いが出力差へ混ざる。HTTP クライアントから同じ要求本文を送ることで、推論器や設定を変更した前後の比較が可能になる。

HTTP サーバーはローカルのループバックアドレスだけで待ち受ける。最小評価に外部接続は必要なく、ネットワークへ公開すれば認証、通信暗号化、接続制御という別の検証項目が加わる。ローカル API の目的は利用者を増やすことではなく、推論処理を再現可能な方法で呼び出す境界を作ることにある。

6.6 ログは、出力を実行条件へ結び付ける

生成結果だけを保存しても、その結果を再現できるとは限らない。Bonsai 8B が同じでも、llama.cpp のコミット、構築設定、入力、文脈長、乱数種、スレッド数が異なれば出力と速度は変わる。測定ログには、文章だけでなく、どの環境と条件から生成されたかを残す必要がある。

最低限、実行日時、推論器のコミット番号、モデルのチェックサム、構築条件、実行コマンド、入力全文、標準出力、標準エラー出力、終了状態、経過時間、最大メモリを記録する。HTTP 試験では、要求本文、HTTP 状態、応答本文も保存する。これらを同じ実行単位へまとめれば、異常な出力が発生したときに条件を遡れる。

ログは成功例だけを残さない。モデル読み込みの失敗、形式違反、応答打ち切り、空の出力、異常終了も記録する。失敗を除外して正常な実行だけを平均すると、実務で発生する再試行時間と障害率を過小評価する。最小環境の段階から失敗を測定対象へ含めることで、後続の総作業時間評価へ接続できる。

6.7 最小環境の完成条件は、原因を切り分けられることである

最小環境は、Bonsai が一度文章を返した時点では完成しない。固定したモデルと推論器で単発推論を再現でき、同じ条件を HTTP から呼び出せて、各実行の資源使用量と生成結果を記録できる状態まで必要になる。失敗した場合に、モデル、推論器、入力、HTTP 境界のどこで止まったかを判別できなければ、後続の業務評価へ進めない。

完成条件は、第一に llama-cli で Bonsai 8B Q1_0 を読み込み、固定した日本語入力へ応答できることである。第二に llama-server をローカルで起動し、同じ入力を HTTP から送信して応答を得られることである。第三に、モデルサイズ、読み込み時間、初回応答時間、生成時間、最大メモリを同じ実行条件のログとして残せることである。

この段階では、検索、利用画面、認証、エージェントを備えていなくても不足ではない。Bonsai 以外の要因を増やさず、モデルが限定された文章処理を実行するための最小経路を観察できている。ここで得た基準値が、後に GPU、長い文脈、同時実行、業務プロンプトを追加したときの比較対象になる。

最小環境が排除するのは、機能そのものではなく、評価時点で説明できない変数である。Bonsai の小ささ、速度、出力品質を個別に測れる状態を作ることで、後続の構築と業務評価は、周辺機能の印象ではなく、基準環境との差として判断できる。

7. Bonsai 8B Q1_0 の最小環境を構築する

ここまでに定めた最小環境を、実際のコマンドへ落とし込む。構築の目的は、利用画面や外部連携を完成させることではなく、本家 llama.cpp が Bonsai 8B Q1_0 を読み込み、固定した日本語入力を処理し、同じモデルをローカル API から呼び出せる状態を作ることにある。各段階で使用した版、モデルファイル、実行条件、標準出力、診断出力を記録し、失敗した位置を特定できるようにする。

7.1 前提となる道具を確認する

以下の手順は、POSIX 形式のシェルと CPU 実行を基準にする。特定の CPU 製品や GPU は前提としない。本家 llama.cpp を取得する Git、構築に使う CMake と C++ コンパイラ、API の確認に使う curl が利用できることを先に確認する[25]。

この確認は、単にコマンドが存在することを見るためだけではない。llama.cpp の構築結果は、取得したソースコードだけでなく、コンパイラ、CMake、OS、CPU アーキテクチャによっても変わる。後から同じ手順を再現できるよう、実際に使った版をログへ残す。

不足している道具は、利用する OS の公式なパッケージ管理手段で導入する。パッケージ名と導入方法は OS ごとに異なるため、ここでは特定の管理方式へ固定しない。構築前に必要なのは、四つのコマンドが正常に版を表示できる状態である。

7.2 独立した作業ディレクトリーを作る

ソースコード、モデルキャッシュ、ログ、生成結果を一つのディレクトリーへ閉じ込める。本家 llama.cpp が Hugging Face から取得するモデルの保存先は LLAMA_CACHE で指定する。既存のモデルキャッシュと分離することで、別の量子化形式や過去に取得した同名モデルを誤って使うことを防ぐ。

推論用のスレッド数と構築時の並列数は、初期値としてそれぞれ 4 に固定する。CPU の全論理コアを自動的に使わせると、端末ごとに実行条件が変わり、処理中に他の業務へ与える負荷も比較しにくくなる。いずれも最高速度を得る設定ではなく、異なる実行を同じ条件で比較するための基準値である。

LLAMA_CACHE の扱いは llama.cpp の更新によって変更される可能性があるため、環境変数を設定しただけで保存先を確定したと判断しない。モデル取得後に、実際の GGUF ファイルがこのディレクトリー内へ置かれたことを確認する。使用するコミットで保存先の挙動が異なる場合は、そのコミットの仕様を記録し、モデルファイルの実体を基準にする。

作業環境を作った後、道具と OS の情報を保存する。

このディレクトリーを削除すれば、ソースコード、モデル、実行結果をまとめて撤去できる。ただし、コンパイラや CMake など、OS 側へ導入した道具は検証ディレクトリーの外側に残る。環境の撤去範囲は、記事内で作成したファイルと、OS へ導入した依存関係を分けて考える必要がある。

7.3 本家 llama.cpp を取得して版を固定する

本家リポジトリーを取得し、検証に使用するコミット番号を記録する。本家 llama.cpp は継続的に更新されるため、同じ URL から取得しても、日時が異なれば Q1_0 の実装、既定値、コマンド引数が変わる可能性がある[25]。

コミット番号は、検証結果を推論器の実体へ結び付ける識別子になる。作業ツリーの状態も保存し、取得後にソースコードを変更していないことを確認する。状態ログが空であれば、記録したコミットの内容をそのまま使っている。

後日、同じ版を再現する場合は、保存したコミット番号を指定して切り替える。切り替え後にもコミット番号を再確認する。

この操作ではブランチの先端ではなく、特定のコミットを直接使用する。記事公開後に不具合修正や性能改善が入った場合は、新しいコミットで別の測定を行い、以前の結果を上書きせず比較対象として残す。

7.4 llama-cli と llama-server を構築する

CMake で構築条件を生成し、単発推論に使う llama-cli と HTTP サーバーに使う llama-server を同じソースコードから構築する。特定の GPU 用機能は明示的に追加せず、実行時には GPU へ移すモデル層を 0 に固定する。

この構築方法は、実行時に CPU だけを使うことと、GPU 用の処理がバイナリへ一切含まれないことを同一視しない。OS や llama.cpp の既定設定によっては、利用可能な計算基盤が構築時に検出される場合がある。CPU 基準を保証するのは、後続の実行で GPU へ移す層数を 0 に指定することである。

構築後は、二つの実行ファイルが存在し、版情報を取得できることを確認する。

コミット番号と実行ファイルの版表示を両方残すことで、測定結果がどのソースコードと構築成果物から得られたかを追跡できる。ここで構築に失敗した場合は、まだ Bonsai のモデル品質を評価する段階には達していない。CMake の構成ログと構築ログから、コンパイラ、依存関係、対象命令の問題を先に解消する。

7.5 Bonsai 8B Q1_0 を取得して単発推論する

本家 llama.cpp は、Hugging Face のリポジトリーと量子化形式を指定し、対応する GGUF ファイルを取得して直接実行できる[25]。Bonsai 8B の公式モデルカードが示す Q1_0 を指定し、最初の取得と単発推論を同時に行う[2]。

モデルには会話用のテンプレートが含まれるため、llama-cli は対話モードを自動的に選ぶ場合がある。固定入力を一度処理して終了させるため、単一ターンを明示する。これにより、生成後に追加入力を待ち続ける状態を避ける。

標準出力と標準エラー出力を分離する。生成された文章は results ディレクトリーへ保存し、モデル読み込み、計算基盤、処理時間などの診断情報は logs ディレクトリーへ保存する。両者を一つのファイルへ混ぜると、後から生成内容だけを比較するときに診断行を除去しなければならない。

この段階の合格条件は、要約の品質が業務基準を満たすことではない。Bonsai 8B Q1_0 が取得され、本家 llama.cpp がモデルを読み込み、CPU 基準で日本語入力から出力を生成し、終了状態 0 で処理を終えることである。要約内容の忠実性や実務適合性は、同じ条件を再実行できる状態を作った後に評価する。

温度を 0 にしたのは、初期構築における出力変動を抑えるためである。これは Bonsai の推奨生成設定を決定するものではない。公式モデルカードは別の温度範囲も提示しているため、品質評価では温度を変えた試験を別に行う[2]。

7.6 取得したモデルファイルを特定してチェックサムを記録する

Hugging Face 上のリポジトリー名と量子化指定だけでは、実際に試験したファイル内容を一意に残せない。配布元で同名の成果物が更新された場合でも区別できるよう、LLAMA_CACHE 内の GGUF ファイルを列挙し、SHA-256 を記録する。

独立したキャッシュには、対象となる GGUF ファイルが 1 個だけ存在する状態を期待する。複数のファイルが見つかった場合は、量子化形式や過去の取得結果が混在している可能性があるため、先へ進まず、ファイル名と容量を確認する。

SHA-256 の計算コマンドは OS によって異なる。GNU 系の sha256sum がある場合はそれを使い、ない場合は shasum の SHA-256 指定を使う。どちらも存在しない場合は、OS が提供する同等の手段を確認する。

ファイル名、容量、チェックサムを組み合わせることで、後続の測定結果をモデルの実体へ結び付けられる。同じ Q1_0 という名称でもファイル内容が変わればチェックサムが変わるため、再試験時にモデル更新の有無を検出できる。

7.7 ローカルファイルを指定して基準推論を再実行する

最初の推論では、モデル取得処理と文章生成が同じ実行に含まれている。取得時間を含む初回結果と、既に存在するモデルを読み込む通常の実行を分けるため、特定したローカルファイルを直接指定して同じ入力を再実行する。

この再実行では、Hugging Face 上の指定ではなく、チェックサムを記録したローカルファイルを直接使用する。後続の品質試験や速度試験も同じファイルを指定すれば、配布元の更新やキャッシュ解決の違いが測定へ混ざらない。

初回実行と基準実行の診断ログを比較すると、モデル取得を含む時間と、ローカルファイルを読み込んで生成する時間を分けられる。ただし、二回目以降は OS のファイルキャッシュが影響する場合がある。起動時間を正式に測定する段階では、初回と後続の実行を別の条件として記録する。

7.8 ローカル API を起動する

単発推論が成功した後に、同じモデルファイルを llama-server へ渡す。本家 llama.cpp の llama-server は OpenAI 互換の HTTP API を提供し、対話生成用のエンドポイントを持つ[25]。

外部から接続させないため、待受先はループバックアドレスに限定する。API のモデル名はローカルファイル名に依存させず、bonsai-8b-q1_0 という別名へ固定する。利用側の要求がキャッシュ内のパスや配布元の名前へ依存することを避けるためである。

プロセスをバックグラウンドで起動した直後は、モデルの読み込みが完了していない可能性がある。一定時間待つだけでは、速い環境で不要な待ち時間が生じ、遅い環境では準備完了前に API を呼び出すことになる。健康確認用のエンドポイントが成功するまで、上限を設けて繰り返し確認する。

健康確認が成功しない場合は、対話 API を呼び出さず、サーバーログを確認する。モデル読み込みの失敗、ポートの競合、引数の不一致を解消してから再起動する。健康状態と文章生成を分けることで、HTTP サーバーが動いていない問題と、モデルが回答できない問題を混同せずに済む。

7.9 OpenAI 互換 API から固定入力を送る

サーバーが準備完了した後、対話生成用のエンドポイントへ固定した JSON を送る。単発推論と同じシステム指示、入力、温度、出力上限を使い、コマンドラインと HTTP 経由の結果を比較できるようにする。

応答本文だけでなく、HTTP 状態を別に保存する。JSON にエラー説明が含まれていても、状態を確認しなければ成功応答として扱う可能性がある。API の最初の合格条件は、HTTP 200 と解析可能な JSON が返り、応答中に生成結果が含まれることである。

API から自然な文章が返ったことだけでは、コマンドラインと同じ処理が行われたとは限らない。チャットテンプレート、システム指示、要求の既定値が異なる場合がある。単発推論と API の出力が異なるときは、モデル能力の変動と決めつけず、実際に適用された入力形式と生成設定を確認する。

7.10 サーバーを終了して後始末を確認する

試験後は、起動時に記録したプロセス番号を使って llama-server を終了する。常駐サービスとして登録する前の段階では、起動と終了を手動で追跡できることも最小環境の成立条件になる。

停止後に健康確認用の URL へ接続できなければ、サーバーが終了したことを確認できる。プロセス番号の記録は、終了操作を簡単にする一方、古い記録を後日使うと別のプロセス番号へ再利用されている可能性がある。この手順は、起動した同じシェル作業の中で停止することを前提にする。

自動起動、再起動、認証、通信暗号化、外部公開、監視は、対象業務と運用責任が決まった後に追加する。モデル単体の評価段階で常駐サービス化すると、OS のサービス管理、権限、ログ保存、障害復旧という別の評価対象が増える。

7.11 Bonsai-demo を使う経路ではモデル系列と版を明示する

PrismML の公式 Bonsai-demo は、モデル取得、推論用バイナリ、複数の計算基盤、利用画面などをまとめて準備する検証入口である。ただし、何も指定しない場合は Ternary-Bonsai 27B が既定値となる。1-bit Bonsai 8B を試験するには、モデル系列を bonsai、規模を 8B と明示する必要がある[24]。

Bonsai-demo 自体も継続的に更新されるため、既定値とスクリプトの挙動を再現するにはコミットを固定する。以下では、2026 年 7 月 20 日時点のコミット 4aa062e061a1ffb066072e75de6bcd7c39e52647 を使用する。

セットアップ後に CPU だけで実行する場合は、GPU へ移す層数を 0 に指定する。セットアップ時のモデル選択と、実行時の計算基盤選択は別の条件である。

Bonsai-demo は、PrismML が想定するモデル系列と複数の実行経路を確認する用途に適している。一方、セットアップスクリプトは依存関係や補助機能を自動的に導入するため、どの要素が追加されたかを個別に把握する必要がある。本家 llama.cpp と単一の GGUF ファイルだけを使う経路の方が、Bonsai 8B Q1_0 の最小評価では変数を少なく保てる。

7.12 構築成功と性能合格を分ける

以上の手順が完了すれば、本家 llama.cpp、Bonsai 8B Q1_0、固定入力、ローカル API からなる最小実行経路は成立する。確認できたのは、対象モデルを取得し、CPU 基準で読み込み、日本語を生成し、HTTP から再利用できることである。

この結果だけでは、Bonsai を業務へ投入できるとは判断できない。本家 llama.cpp が Q1_0 を扱えることと、特定の CPU で十分な速度を得られることは別である。日本語の短い要約を返せることと、期限、否定、担当者を落とさず処理できることも別の条件になる。

構築段階で固定したコミット、モデルチェックサム、スレッド数、文脈長、生成上限、入力、API 要求が、後続の性能測定と品質評価の基準になる。ここから要約、校正、分類、抽出の代表入力を追加し、処理時間、最大メモリ、形式違反、事実誤り、人間の修正時間を測定する。

最小環境の完成が意味するのは、Bonsai 8B が実用的であるという結論ではない。Bonsai の小ささと出力品質を、周辺機能に隠さず測定できる地点へ到達したことである。

8. 評価するのは生成速度ではなく、人間を含む総作業時間である

8.1 1.15 GB という値だけでは、配置可能性を判断できない

Bonsai 8B の評価では、モデルファイル、実行時メモリ、処理時間、出力品質を分けて記録する。公式モデルカードが示す約 1.15 GB は主としてパラメーター領域を表し、配布される GGUF ファイル全体は約 1.16 GB である[2]。実際の推論では、これに llama.cpp の実行領域、トークナイザー、計算用の一時領域、入力と生成履歴を保持する KV キャッシュが加わる。

モデルファイルが端末へ保存できても、推論中の最大メモリが利用可能量を超えれば実行できない。短い入力では収まっても、文脈長を増やすと KV キャッシュが拡大し、同じ重みを使っていても必要メモリは増える。同時要求を受け付ければ、要求ごとの文脈や作業領域も追加される。モデルサイズは配置可能性の出発点にはなるが、常駐可能性と連続処理能力は実行時の測定によって判断する必要がある。

成果物の記録も性能評価の一部になる。モデル名だけを残しても、配布元でファイルが更新されれば同じ結果を再現できない。GGUF のファイル名、容量、SHA-256、llama.cpp のコミット、構築条件を一組として保存する。品質や速度の変化が見つかったとき、モデルの変更と推論器の変更を分けて追跡できる状態が必要である。

8.2 初回実行と通常実行を混ぜると、起動負担を評価できない

最初のモデル実行には、Hugging Face からの取得、GGUF の検査、記憶装置からの読み込み、OS のファイルキャッシュが空の状態などが含まれる。二回目以降はモデルファイルが既に存在し、一部が OS のキャッシュへ残るため、同じコマンドでも所要時間が短くなる。初回と後続を一つの平均へまとめると、導入時の負担と通常利用時の負担の両方が見えなくなる。

起動試験では、少なくとも三つの状態を分ける。第一はモデル取得を含む初回実行、第二はモデル取得後にプロセスを新しく開始する低温状態、第三は llama-server がモデルを読み込んだまま要求を受ける常駐状態である。必要時起動では第二の時間が利用者の待ち時間へ入り、常時起動では第三の時間と待機時メモリが支配的になる。

推論速度も、ウォームアップ後の生成トークン毎秒だけを示すと、短い業務処理を過大評価する。分類では数語しか生成しないため、重み読み込みと入力処理が全体の大部分を占める。長文要約では入力トークンの処理時間が増え、校正では入力と同程度の文章を再生成するため出力時間も大きくなる。処理種別ごとに待ち時間の内訳を分けなければ、同じ速度値から異なる利用者体験を説明できない。

MLPerf Inference が推論環境の比較で測定条件と再現性を重視するのは、速度がモデルだけの性質ではなく、ハードウェア、ソフトウェア、入力、実行方式の組み合わせから生じるためである[10]。本稿の測定を MLPerf 準拠とするわけではないが、CPU、メモリ、推論器の版、スレッド数、文脈長、入力長、出力上限、実行回数を固定する考え方は同じである。

8.3 OS ごとの測定値を、同じ名称だけで比較しない

資源測定の手段は OS によって異なる。Linux の GNU time、BSD 系の time、各 OS のプロセス統計では、最大常駐メモリ、利用者 CPU 時間、システム CPU 時間の単位や集計範囲が一致しない場合がある。同じ「最大メモリ」という名称でも、子プロセスを含むか、共有領域をどのように数えるかによって値が変わる。

異なる OS の値を一つの表へ並べる場合は、測定コマンド、版、単位、対象プロセスを併記する。最初の採用判断では、異なる端末間の優劣を急いで決めるより、同一環境で llama.cpp のコミット、文脈長、スレッド数、入力だけを変えた比較を優先する。測定手段を固定すれば、絶対値に多少の差があっても、設定変更による増減を追跡できる。

処理時間には、シェルからプロセスを開始して終了するまでの実時間を使用する。llama.cpp が表示する内部の入力処理速度と生成速度も保存するが、これらは工程全体の時間を代替しない。モデル読み込み、HTTP 要求の組み立て、応答の保存など、利用者が待つ時間を含めるためである。

8.4 品質評価は、用途ごとに異なる失敗を数える

Bonsai の品質を一つの総合点へまとめると、実務上の失敗が隠れる。要約、校正、分類、抽出では、モデルが担う変換と誤りの意味が異なる。各用途に固定した入力集合と正解条件を用意し、同じモデル設定で繰り返し実行する必要がある。

要約用の入力には、決定事項、未決事項、否定、数値、期限、例外、複数の人物を含める。評価では、文章の自然さより、残すべき項目を保持した割合、原文にない事実を加えた件数、否定や因果を反転した件数を数える。生成要約は流暢でも入力にない内容を含み得るため[18]、文字列類似度だけではなく、項目別の原文照合が必要になる。自動指標と人間評価が異なる性質を測ることも報告されているため[19]、重大情報の保持を独立した評価項目とする。

校正用の入力には、固有名詞、日付、金額、製品名、否定表現を含める。評価するのは、文章が読みやすくなったかだけではない。入力中の事実が保持されたか、入力にない約束や原因が追加されていないか、依頼の強さや責任範囲が変わっていないかを確認する。文章表現の改善と事実の維持を別々に採点する。

分類用の入力集合では、各分類の件数をそろえるだけでなく、境界事例、情報不足、複数条件へ該当する事例を含める。全体正解率に加えて、分類別に該当案件を取りこぼさなかった割合と、別分類を誤って割り当てた割合を測る。重要な警告を通常案件へ分類する誤りと、通常案件を別の一般分類へ送る誤りには、異なる重みを付ける。

抽出用の入力には、すべての値が明記された文章、項目の一部が欠けた文章、複数の日付や人物を含む文章を用意する。正しい値を取得した件数、存在する値を落とした件数、別の値を選んだ件数、入力にない値を作った件数を分ける。欠落項目へ null または該当なしを返せるかも、独立した合格条件になる。

8.5 重大誤りと許容誤りを、試験前に定義する

同じ誤答率でも、業務上の意味は用途によって変わる。文章校正で読点の位置が不自然になる誤りと、支払期限の日付を変更する誤りを同じ一件として数えれば、平均値は実際の危険を表さない。試験前に、重大誤り、修正可能な軽微誤り、判定不能として退避すべき入力を定義する。

NIST の AI リスク管理枠組みが、利用状況に応じた測定、管理、対処を求めるのは、モデルの出力が置かれる経路によって結果の大きさが変わるためである[12]。生成 AI 向けの補足文書も、導入時の試験だけでなく、利用中の失敗と目的変更を継続的に確認する構造を示している[13]。

要約を個人の読解補助に使う場合、軽微な言い換えは許容できる。一方、要約だけを正式な議事録として配布するなら、決定事項と期限の欠落は重大誤りになる。分類結果を候補として表示するだけなら振り直せるが、結果を使って警告を自動破棄するなら、重要分類の取りこぼしをほぼ許容できない。

採用基準は、平均精度の下限だけで定めない。重大誤りが一件でも発生したら用途を見送る条件、一定割合を超えたら人間確認へ戻す条件、形式違反が起きたら自動処理を停止する条件を分ける。判定不能を正常な出力として含めれば、無理な回答を減らせる代わりに、人間へ移す件数が増える。この均衡も総作業時間へ含めて判断する。

8.6 構造化出力は、形式適合と内容正解を分けて測る

分類や抽出では、JSON や定義済みの列挙値を返させることで、後段のプログラムから扱いやすくなる。括弧が閉じているか、必須項目が存在するか、日付が指定形式かを自動確認できる。しかし、構造が正しいことは、内容が原文と一致していることを意味しない。

JSON Schema を用いる構造化出力の評価では、制約へ適合した割合だけでなく、制約の対応範囲、生成効率、内容品質を分ける必要が示されている[22]。担当者と期限が入れ替わった JSON でも、構文上は完全に正しい。Bonsai の評価では、構造適合率と、項目ごとの意味的な正解率を別の列へ記録する。

小型モデルに対する強い構造制約が、形式上妥当な出力を増やす一方で、内容の正確性を下げる可能性を示した新しい報告もある[23]。これは確立した一般則ではないが、形式違反をなくすことだけを最適化すると、見た目が整った誤答を増やす可能性がある。自由生成、指示による JSON 出力、文法制約付き生成を比較する場合も、構造と意味の両方を測る必要がある。

8.7 総作業時間は、人間とモデルの間で時間が移動した結果である

モデルを導入すると、人間の作業が消えるのではなく、作業の種類が変わる。文章を最初から書く時間は減っても、入力条件を整え、出力を原文と照合し、誤りを修正し、判定不能な案件を処理する時間が増える。推論が高速でも、この移動後の作業時間が元の手作業を上回れば、業務工程は短縮されない。

この式は、将来の所要時間を厳密に予測する数理モデルではない。モデル導入によって見えにくくなる作業を、測定対象から落とさないための工程分解である。各項目は同じ案件ごとに記録し、人間だけで処理した場合の時間と比較する。

たとえば、Bonsai が 1 秒で返信文を生成しても、入力にない約束が含まれていないかを確認するために 5 分を要し、人間が最初から 2 分で作成できるなら採用理由はない。反対に、30 分分の会議記録から議題と確認箇所を 2 分で整理し、人間が 3 分で原文照合できるなら、総作業時間を 5 分まで短縮できる。

確認時間は、出力品質だけでなく、根拠の表示方法にも左右される。要約と原文を並べ、抽出値へ根拠文を付ければ、確認範囲を狭められる。自然な回答文だけを返す構成では、誤りがないことを確認するために原文全体を読み直す必要がある。モデルの品質を変えなくても、出力形式によって総作業時間は変わる。

8.8 継続運用では、処理時間に保守時間を加える

試験データで総作業時間が短縮されても、運用全体の利益が確定するわけではない。llama.cpp とモデルの更新、OS の変更、代表入力による回帰試験、ログの確認、異常終了への対応が継続的に必要になる。ローカル環境では外部 API の従量課金を減らせる一方、計算資源と保守作業を組織側が負担する。

推論器またはモデルを更新した場合は、同じ固定データ集合を再実行する。速度だけが改善しても、要約の重大項目保持率や抽出精度が下がれば更新を採用できない。チェックサムとコミットを記録していれば、問題が見つかった版から以前の基準版へ戻せる。

処理件数が少ない場合、初期構築と継続保守の固定費を回収できない。月に数件の校正を行うだけなら、手作業の方が短い可能性が高い。毎日多数の定型分類や抽出を行い、同じ試験と確認手順を再利用できる場合は、固定費を多くの案件へ分散できる。Bonsai の小ささが利益へ変わるには、精度だけでなく、十分な反復量が必要になる。

8.9 採用判定は用途ごとに行う

Bonsai 8B 全体を採用または不採用とする一つの結論は、実務上の配置を粗くしすぎる。要約では読解範囲を狭められても、正式記録の生成には使えない場合がある。校正では事実を維持できても、自由な返信作成では入力外情報が増える場合がある。分類は通常案件で十分でも、重要警告の再現率が不足する場合がある。

採用単位はモデルではなく、入力条件、指示、出力形式、確認方法を組み合わせた処理である。同じ Bonsai 8B でも、「200 文字以内で概要を作り、根拠文を付ける要約」と、「契約内容を判断して結論を書く要約」は別の評価対象になる。前者が合格しても、後者へ結果を一般化できない。

Bonsai の採用条件は、トークン毎秒が高いことでも、約 1.15 GB に収まることでもない。限定した入力で重大誤りを抑え、出力を短時間で検証でき、失敗を確定処理の前で止め、人間だけの工程より総作業時間を短縮できることである。

この条件を満たす用途だけを Bonsai へ移す。要約が合格しても分類へ一般化せず、通常案件の分類が合格しても重要警告へ広げない。最小モデルの評価は、モデル全体に一つの合否を付ける作業ではなく、検証可能な仕事を一つずつ選び出す作業になる。

9. 最小モデルは、仕事を小さく定義できる場合に採用できる

9.1 Bonsai 8B が小さくしたのは、判断の難しさではなく配置の負担である

Bonsai 8B の約 1.15 GB という重み領域は、大型モデルが持つ能力を同じ品質のまま約 1 GB へ移したことを意味しない。開発元の公表評価でも、より大きな格納容量を持つ上位 8B モデルとの能力差は残る。日本語の会議録、問い合わせ、障害報告、社内文書についても、一般評価の平均値から実務上の正確性を推定することはできない。

小ささが直接変えるのは、モデルを置ける場所と動かせる回数である。重みの取得、読み込み、常駐に必要な負荷が下がれば、大容量の計算資源を占有せず、短い文章処理を繰り返す構成を選びやすくなる。本家 llama.cpp が Bonsai 8B Q1_0 を直接扱える現在の環境では、特定の専用推論基盤を別系統で維持せず、モデル、推論器、コマンドライン、ローカル API だけからなる基準環境を作れる[24][25]。

この構成によって、Bonsai の能力上限がなくなるわけではない。期限を落とす要約、重要な警告を取りこぼす分類、原文にない担当者を補う抽出は、低いメモリ使用量では埋め合わせられない。Bonsai が小さくするのは推論環境の負担であり、入力の曖昧さ、判断の難しさ、誤りの影響まで小さくするわけではない。

9.2 採用単位はモデル名ではなく、入力から確認までを固定した処理である

Bonsai を採用するかどうかを、モデル全体に対する一つの合否で決めると、実際に使える範囲を正確に切り出せない。同じ Bonsai 8B でも、会議録の概要を作る処理と、契約上の義務を確定する処理では必要な品質が異なる。問い合わせを担当部署の候補へ分類する処理と、その分類結果で申請を拒否する処理でも、誤りが及ぼす影響は一致しない。

採用対象となるのは、「要約」「分類」といった広い用途名ではない。入力条件、指示、出力形式、確認方法、失敗時の退避先を組み合わせた個別の処理である。たとえば要約なら、「議題ごとに 100 文字以内で概要を作り、決定事項、担当者、期限の根拠文を付ける」という単位まで定義する。分類なら、候補を有限の値へ限定し、情報不足と複数該当を確認待ちへ送るところまで含める。

9.3 入力内で閉じ、検証でき、戻せる処理だけを残す

Bonsai へ移せる処理は、三つの条件を同時に満たす必要がある。第一に、出力へ必要な事実と規則が入力内に存在する。第二に、出力を原文、列挙値、日付形式、根拠文などと短時間で照合できる。第三に、誤っても送信、承認、削除、設定変更が確定する前へ戻せる。

モデルが入力の変換を越えて、責任、優先順位、例外の適用、原因、対応方針を補い始めた場所が、自動処理の境界になる。文章として自然に見えても、その結論を原文や規則から直接確認できなければ、Bonsai が確定すべき処理ではない。

9.4 人間確認付き採用は、未完成な自動化ではない

人間の確認を残す構成は、自動化に失敗した中間状態ではない。モデルが得意な情報変換と、人間が担う判断を分離した完成形の一つである。Bonsai が会議録から議題、担当者、期限の候補を作り、人間が原文との対応を確認して確定するなら、モデルは読解の初期処理を引き受け、人間は判断と責任を保持する。

この分担が成立するかは、確認時間によって決まる。生成結果を信用できず、毎回原文を最初から読み直すなら、モデルは文章生成を増やしただけになる。根拠文、参照位置、形式検証によって確認範囲を狭められるなら、人間を残しても工程全体は短縮できる。

9.5 総作業時間が減らない処理は、小型モデルでも採用しない

Bonsai 8B が低いメモリ使用量で動いても、確認と修正に長い時間がかかれば業務上の利益は残らない。推論が数秒で終わっても、入力にない情報が混ざっていないかを確認するために全文を読み直し、大部分を書き換えるなら、人間だけで処理する方が短い。

採用判定では、入力準備、推論、原文照合、修正、判定不能案件の処理、失敗時の再実行を合わせる。モデルが生成した時間だけを取り出さず、人間が利用可能な結果へ仕上げるまでを一つの工程として比較する。Bonsai の導入後に短縮された時間と、新たに増えた確認時間の差が、実際の効果になる。

9.6 構築は、用途を増やす前に基準点を作るところから始まる

Bonsai を採用する順序は、想定用途を並べ、検索、利用画面、エージェント、外部連携を先に追加することから始まらない。本家 llama.cpp と Bonsai 8B Q1_0 の最小環境を作り、固定したモデル、推論器、入力、生成条件で再現可能な出力を得る。そこから資源使用量、待ち時間、用途別の誤り、人間の確認時間を測定する。

最初の基準環境では、CPU による単発推論とローカル API までを確認する。要約、校正、分類、抽出の固定データを同じ API へ送り、モデルや推論器を更新しても同じ試験を繰り返せる状態にする。構築時に記録した llama.cpp のコミット、モデルのチェックサム、文脈長、スレッド数、生成上限が、後続評価の比較軸になる。

9.7 Bonsai の 1.15 GB は、検証可能な仕事を常駐させるための大きさである

Bonsai 8B の約 1.15 GB という特徴から導かれる結論は、大型モデルが不要になることではない。設計、原因分析、契約解釈、責任判断のように、入力外の前提と複数の根拠を統合する仕事には、より高い能力を持つモデルや専門家の判断が必要になる。

Bonsai が残せる役割は、その前後にある。長文から読むべき箇所を絞り、決定済みの文章を整え、有限の候補を提示し、明記された値を構造へ移す。これらの処理を入力内で閉じ、根拠と照合でき、誤りを確定前に止められる単位へ分ければ、小さなモデルでも継続的な仕事を持てる。

約 1.15 GB という値の意味は、モデルの知能を示す得点ではない。検証可能な短い処理を、低い常駐負荷で何度も実行できる配置条件を示している。その配置が業務上の価値へ変わるかは、処理件数、重大誤り、確認時間、保守負担によって決まる。

本家 llama.cpp と Bonsai 8B Q1_0 の最小環境は、この判断を始めるための基準になる。固定入力から再現可能な結果を得て、モデルサイズ、実行時メモリ、待ち時間、用途別品質、人間の作業時間を測る。その結果、仕事全体が短くなり、重大な誤りを確定前に止められる処理だけを Bonsai へ移す。

ミニマムな LLM を採用するとは、小さいモデルへ多くの仕事を渡すことではない。仕事を小さく定義し、その一部を確実に任せられるところまで、入力、出力、検証、責任の境界を狭めることである。Bonsai 8B は、その境界を作れる業務に限って、技術的な珍しさから、常時反復する実用的な言語処理基盤へ変わる。

参考文献

1. PrismML, Announcing 1-bit Bonsai: The First Commercially Viable 1-bit LLMs（2026-03-31）. https://prismml.com/news/bonsai-8b
2. PrismML, Bonsai-8B-gguf（参照 2026-07-21）. https://huggingface.co/prism-ml/Bonsai-8B-gguf
3. Hongyu Wang, Shuming Ma, Li Dong, Shaohan Huang, Huaijie Wang, Lingxiao Ma, Fan Yang, Ruiping Wang, Yi Wu, Furu Wei, BitNet: Scaling 1-bit Transformers for Large Language Models（2023）. https://arxiv.org/abs/2310.11453
4. Shuming Ma, Hongyu Wang, Lingxiao Ma, Lei Wang, Wenhui Wang, Shaohan Huang, Li Dong, Ruiping Wang, Jilong Xue, Furu Wei, The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits（2024）. https://arxiv.org/abs/2402.17764
5. Shuming Ma, Hongyu Wang, Shaohan Huang, Xingxing Zhang, Ying Hu, Ting Song, Yan Xia, Furu Wei, BitNet b1.58 2B4T Technical Report（2025）. https://arxiv.org/abs/2504.12285
6. Jinheng Wang, Hansong Zhou, Ting Song, Shijie Cao, Yan Xia, Ting Cao, Jianyu Wei, Shuming Ma, Hongyu Wang, Furu Wei, Bitnet.cpp: Efficient Edge Inference for Ternary LLMs（2025）. https://arxiv.org/abs/2502.11880
7. Percy Liang et al., Holistic Evaluation of Language Models（2022）. https://arxiv.org/abs/2211.09110
8. Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, Timnit Gebru, Model Cards for Model Reporting（2019）. https://arxiv.org/abs/1810.03993
9. id774, MacBook Pro でローカル LLM を実用化する条件（2026-07-17）. https://blog.id774.net/entry/2026/07/17/5102/
10. Vijay Janapa Reddi et al., MLPerf Inference Benchmark, ISCA（2020）. https://arxiv.org/abs/1911.02549
11. id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
12. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1（2023）. https://doi.org/10.6028/NIST.AI.100-1
13. Chloe Autio et al., Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1（2024-07-26）. https://doi.org/10.6028/NIST.AI.600-1
14. Saleema Amershi et al., Guidelines for Human-AI Interaction, Proceedings of CHI 2019（2019）. https://doi.org/10.1145/3290605.3300233
15. David Madras, Toni Pitassi, Richard Zemel, Predict Responsibly: Improving Fairness and Accuracy by Learning to Defer, Advances in Neural Information Processing Systems 31（2018）. https://proceedings.neurips.cc/paper/2018/hash/09d37c08f7b129e96277388757530c72-Abstract.html
16. Hussein Mozannar, David Sontag, Consistent Estimators for Learning to Defer to an Expert, Proceedings of the 37th International Conference on Machine Learning（2020）. https://proceedings.mlr.press/v119/mozannar20b.html
17. id774, 医療 AI と人間の判断（2026-05-28）. https://blog.id774.net/entry/2026/05/28/4814/
18. Joshua Maynez, Shashi Narayan, Bernd Bohnet, Ryan McDonald, On Faithfulness and Factuality in Abstractive Summarization, Proceedings of ACL（2020）. https://arxiv.org/abs/2005.00661
19. Alexander R. Fabbri, Wojciech Kryściński, Bryan McCann, Caiming Xiong, Richard Socher, Dragomir Radev, SummEval: Re-evaluating Summarization Evaluation, Transactions of the Association for Computational Linguistics（2021）. https://arxiv.org/abs/2007.12626
20. Artidoro Pagnoni, Vidhisha Balachandran, Yulia Tsvetkov, Understanding Factuality in Abstractive Summarization with FRANK: A Benchmark for Factuality Metrics, Proceedings of NAACL（2021）. https://arxiv.org/abs/2104.13346
21. Saibo Geng, Martin Josifoski, Maxime Peyrard, Robert West, Grammar-Constrained Decoding for Structured NLP Tasks without Finetuning（2023）. https://arxiv.org/abs/2305.13971
22. Saibo Geng, Hudson Cooper, Michał Moskal, Samuel Jenkins, Julian Berman, Nathan Ranchin, Robert West, Eric Horvitz, Harsha Nori, JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models（2025）. https://arxiv.org/abs/2501.10868
23. Jaideep Ray, The Constraint Tax: Measuring Validity-Correctness Tradeoffs in Structured Outputs for Small Language Models（2026）. https://arxiv.org/abs/2605.26128
24. PrismML-Eng, Bonsai-demo, commit 4aa062e061a1ffb066072e75de6bcd7c39e52647（参照 2026-07-21）. https://github.com/PrismML-Eng/Bonsai-demo/tree/4aa062e061a1ffb066072e75de6bcd7c39e52647
25. ggml-org, llama.cpp: LLM inference in C/C++（参照 2026-07-21）. https://github.com/ggml-org/llama.cpp