0. 要約
- 企業のサーバで「現状を調べ、侵入の痕跡を探し、更新を計画し、実施し、脆弱性を直す」までをローカル LLM のエージェントにやらせて、自動で採点するベンチマークを作った。名前は GembaBench。試験の一式は GitHub で順次公開する。
- 同じ Qwen3.8-Flash-Next を、DGX Spark（128GB）と、RTX 4060 Ti 16GB 1 枚＋Strata の構成で、6 課題 × 3 回ずつ走らせた。
- 成績の中央値は 6 課題とも同じ範囲に入った。所要時間は全課題で 16GB 構成のほうが短く、6 課題の中央値の合計は約 1.8 時間（Spark は約 4.3 時間）だった。
- はっきり差が出たのは止まり方だった。Spark は 18 本中 3 本が時間切れか途中停止で、報告を出せなかった。16GB 構成は 18 本中 1 本だった。
- 外に出せないデータを扱うオンプレの AI 開発は、普及帯の GPU 1 枚で現実的な選択肢になったと見ている。
1. はじめに — なぜ「現場仕事」を測るのか
当ラボはこれまで、DGX Spark（NVIDIA GB10）と EVO-X2（Ryzen AI Max+ 395）でローカル LLM の速度と精度を測り、Qiita で公開してきた。Qwen3.8-Flash-Next を DGX Spark 1 台で動かした記録は こちらの記事 にある。
Aider Polyglot や SWE-bench は、主にコードを読み書きする力を測るベンチマークだ。だが企業の中で AI エージェントに任せたい仕事の多くは、その手前にある。誰も現状を整理していないサーバに入り、何が動いていて何がまずいのかを自分で調べる。そのうえで計画を立て、壊さずに直す。この力はコーディングベンチの点数からは読み取れない。9 月に 7 つのモデルを比べたときも、コーディングベンチの点が近いモデル同士が、実サーバの調査では大きく差がついた（9 月の記事）。
もう 1 つの背景がある。外に出せないデータを使う AI 開発は急務だ。ただ、大きなモデルを動かせる 128GB 級の AI 開発機（DGX Spark、EVO-X5 など）は 1 台 100 万円を超える。そこに Strata が登場した。Strata は、GPU に載り切らない部分を CPU メモリに置いて Qwen3.8-Flash-Next を動かす推論エンジンだ。これを使うと、中古の RTX 4060 Ti 16GB と CPU メモリ 64GB の PC 1 台（【価格の目安】）で同じモデルが動く。
ただし「動く」ことと「現場の仕事に使える」ことは別だ。本記事では、それを確かめるために作ったベンチマーク GembaBench の初回版と、それで測った最初の結果を報告する。
2. GembaBench とは
2.1 テスト環境
試験は、VM 2 台とモデルサーバで回す。左の VM でランナーがテスト環境を初期化し、テスト対象のハーネス（OpenCode）を起動する。ハーネスは右の VM にある架空企業のサーバへ SSH で入って調査や作業をし、推論はモデルサーバに要求する。終わったら、判定スクリプトが報告書とサーバの状態で採点する。2 台の VM は 1 台の PC の上に置ける。
架空の中小企業「株式会社ヒイラギ金属工業」の Web サーバと DB サーバを用意した（Ubuntu 22.04、自作 PHP の問い合わせ管理アプリ、MySQL）。どちらも Incus のコンテナで作り、試行ごとに初期状態へ戻す。
現場らしさを出すために、次のものを仕込んである。
- 前任者（退職者）の SSH 鍵、DB ユーザ、アプリの管理者アカウント、平文のトークンの残存
- 脆弱性を突かれた侵入の痕跡
- 直した設定を毎時元に戻す cron（作業後に確かめないと気づけない罠）
- 読み解かないと正しく扱えない運用スクリプト
- SQL インジェクションを持つコード
エージェントは隔離されたネットワークから SSH で入るだけで、外側の仕組みは見えない。外部への通信は、モデルサーバとテスト環境だけに制限している。
2.2 課題 6 本（シナリオ s01）
| ID | 内容 | 性格 |
|---|---|---|
| s01-survey（T1） | 現状調査。構成・サービス・設定・問題点を報告する | 調査 |
| s01-forensics（T2） | 侵入痕跡の調査。ログと痕跡から何が起きたかを特定する | 調査 |
| s01-plan / s01-replan（T3 / T3b） | OS 更新の計画。途中で方針変更の 2 通目が届き、計画を直す | 計画 |
| s01-upgrade（T4） | 更新の実施。サービスを壊さず 24.04 へ上げる | 実施 |
| s01-remediate（T5） | 設定の是正。退職者の権限を失効させ、設定の穴を塞ぐ | 実施 |
| s01-fix-sqli（T6） | SQL インジェクションの修正 | コーディング |
2.3 採点
採点はすべて機械で行う。
- 調査系（T1・T2）は、正解の事実をいくつ拾えたかで採点する。T1 は重み付きで 45 点、T2 は 8 点。
- 計画系（T3）は、必須項目（8 点）と、方針変更への追従（T3b、6 点）で採点する。
- 実施系（T4〜T6）は、報告書ではなく環境の実際の状態を check スクリプトで確かめる（T4 は 31 項目、T5 は 45 項目、T6 は 23 項目）。そのため、報告書を書く前に時間切れになっても、サーバ上の作業が済んでいれば点が入る。
- このほか、禁止操作の候補（外部への通信など）と、報告と実行の食い違い（「やった」と書いたのにログに無い）を数える。成果物を出さずにモデルが自分で応答を終えた「途中停止」も数える。
temperature 0 でも出力は毎回一致しなかった。そこで各課題を 3 回ずつ走らせ、中央値と範囲で示す。
判定は公開前に全試行で見直した。誤検出のパターンを 4 つ見つけて直し、全試行を同じ版の判定でやり直している。
2.4 先行研究との違い
IBM の ITBench（ICML 2025）は、SRE・セキュリティ準拠・FinOps のシナリオで IT 自動化エージェントを評価する。これは Kubernetes などのクラウド環境が前提で、評価対象は主にクラウドの API モデルだ。
GembaBench には 3 つの違いがある。ローカル LLM と普及帯の GPU を前提に、1 台で再現できること。1 社のサーバを相手に、調査から修正までを通しで測ること。そして、退職者の認証情報の残存や巻き戻しの cron のように、現場で実際に起きる罠を仕込んでいることだ。
3. 測定条件
3.1 モデルと 3 つの構成
モデルは全構成とも Qwen3.8-Flash-Next（125B の MoE）。
| 構成 | ハード | エンジン・量子化 | 位置づけ |
|---|---|---|---|
| Spark | DGX Spark（GB10、128GB） | SGLang、fp4 | 128GB 級の基準 |
| 16GB | RTX 4060 Ti 16GB 1 枚、CPU メモリ 64GB | Strata、IQ3_S、MTP4 | 本記事の主役 |
| 12GB×2 | RTX 3060 12GB × 2、CPU メモリ 64GB | Strata、IQ3_S、MTP4 | 参考 |
- IQ3_S は 3bit 級の量子化。MTP4 は投機的デコードの設定で、多くの利用者が使う設定を選んだ。
- ハーネスは OpenCode 2.0.25 を使った。本記事では、OpenCode のようにモデルにツールを使わせる仕組みを「ハーネス」、ハーネスとモデルを合わせた全体を「エージェント」と呼ぶ。
- 思考は medium、思考トークンの上限は 8192、1 回の出力の上限は 16384。コンテクスト長は、ハーネス側の上限を全構成とも 245,760 トークン（約 240K）にそろえた。モデルサーバ側の上限は、16GB と 12GB×2 が 256K、Spark が 384K。
- 同時実行は 1。これは個人が 1 セッションで使う条件に当たる。複数人で同時に使う構成は本記事の範囲外とする。
3.2 条件をそろえるためにしたこと
- Spark で使った SGLang は、思考トークンの上限を守らないことがある（sgl-project/sglang #25536）。そのままでは 16GB 構成と条件が変わるので、間にプロキシを挟んで上限を守らせた。実際に上限で思考を打ち切ったのは 18 本中 1 回（T3）だけだった。プロキシのログで見た、最初のトークンが返るまでの時間は 0.4〜0.9 秒。
- Spark は共用の機械なので、ほかからのアクセスを記録した。記録できた範囲では、重なりは T5 の 1 本で約 40 秒（0.6%）、ほかは 0 だった。
4. 結果
4.1 成績
値は中央値 [最小–最大]、N=3。
| 課題（満点） | Spark | 16GB | 12GB×2 |
|---|---|---|---|
| T1 現状調査（45） | 43 [38–45] | 40 [39–45] | 42 [40–42] |
| T2 侵入痕跡（8） | 6 [6–8] | 7 [5–8] | 7 [6–8] |
| T3 更新計画（8） | 8 [8–8] | 8 [0–8] | 8 [8–8] |
| T3b 方針変更（6） | 2 [2–4] | 4 [0–4] | 2 [1–3] |
| T4 更新の実施（31） | 31 [27–31] | 31 [31–31] | 31 [28–31] |
| T5 設定の是正（45） | 41 [11–43] | 39 [38–42] | 42 [39–43] |
| T6 SQLi 修正（23） | 23 [8–23] | 23 [23–23] | 23 [23–23] |
- 3 構成の中央値は、どの課題も互いの範囲に収まっている。3 回ずつの試行では、どの構成が上かは言えない。言えるのは、16GB 構成が 3bit の量子化でも 128GB 機と同じ範囲の成績を出したということだ。
- T4 と T6 は、ほぼすべての試行が満点だった（満点の本数は T4 が Spark 2/3・16GB 3/3・12GB×2 2/3、T6 が 2/3・3/3・3/3）。この 2 課題は Flash-Next には易しすぎて差が出ない。初回版の限界として 7 章で扱う。
- 3 構成で点が割れたのは T5 だけだった。満点は 3 構成とも 0 本で、16GB 構成は 38〜42 点に収まった。
- 範囲の下端（Spark の T5 の 11、T6 の 8、16GB の T3 の 0）は、いずれも次の 4.3 で述べる途中停止の 1 本によるもの。
4.2 所要時間
値は中央値 [最小–最大]、単位は分。「待ちを除く」は、sleep を含む 30 秒以上のコマンドの実行時間を差し引いたもの（理由は 6.1）。待ちは T4 と Spark の T5 にだけ出た。ほかの課題は全体と同じ値になる。
| 課題 | Spark | 16GB | 12GB×2 |
|---|---|---|---|
| T1 | 30.3 [21.0–60.7] | 11.0 [10.9–20.1] | 11.4 [10.2–12.3] |
| T2 | 24.6 [24.1–55.0] | 15.0 [11.5–20.0] | 17.2 [14.1–20.7] |
| T3 | 35.6 [29.5–48.0] | 19.7 [19.2–19.9] | 20.6 [17.4–23.2] |
| T4 全体 | 47.3 [42.8–64.3] | 37.4 [20.6–47.7] | 27.8 [26.2–67.1] |
| T4 待ちを除く | 27.2 [25.0–31.0] | 20.6 [15.9–21.6] | 18.9 [18.2–54.6] |
| T5 全体 | 108.8 [8.4–150.0] | 14.5 [12.9–17.9] | 17.6 [11.2–27.6] |
| T5 待ちを除く | 97.6 [8.4–149.5] | 14.5 [12.9–17.9] | 17.6 [11.2–27.6] |
| T6 | 10.7 [2.1–10.8] | 8.8 [7.0–11.2] | 16.7 [15.7–19.6] |
| 中央値の合計（全体） | 257 | 106 | 111 |
- 中央値で見ると、全課題で 16GB 構成のほうが短い。T1〜T3 では Spark が 1.6〜2.8 倍の時間をかけている。T5 では 7 倍以上だった。
- 16GB 構成では、T1〜T3 の 1 本が 11〜20 分ほどで終わる。初めて触るサーバの調査や計画を任せる時間としては、実用の範囲に入っている。
4.3 止まり方 — 報告まで届かなかった試行
| 構成 | 完走して成果物あり | 途中停止（モデルが自分で応答を終えた） | 時間切れ（課題の上限 150 分） |
|---|---|---|---|
| Spark | 15 / 18 | 2（T5、T6） | 1（T5） |
| 16GB | 17 / 18 | 1（T3） | 0 |
| 12GB×2 | 18 / 18 | 0 | 0 |
- 点の中央値には差が出なかったが、止まり方には構成の差が出た。
- Spark の T5 は、1 回目に 109 分・191 ステップで 43 点を取った。2 回目は 150 分の上限まで考え続けて、報告を出せずに時間切れになった（時間の 97% がトークンの生成で、同じ処理の繰り返しは無い。作業はサーバ上で済んでいたので、check スクリプトでは 41 点）。
- 途中停止には 2 つのケースがあった。
- 思考の途中で終了のトークンが出て、何も出さずに終わるケース。Spark の T5（8 分・11 点）がこれで、SGLang に同じ症状の報告がある（sgl-project/sglang #24839）。
- 「次に〜します」と宣言して、ツールを呼ばずに応答を終えるケース。Spark の T6（2 分・8 点）と 16GB の T3（計画書が作られず 0 点）がこれで、Flash-Next の fp4 版でも同じ症状が報告されている（MiaAI-Lab/Qwen3.8-Flash-Next-Single-DGX-Spark #48）。
- 途中停止は、ハーネスの不具合ではなくモデルと推論エンジンの振る舞いなので、そのまま成績に数えた。一方、ハーネスの実行方式が原因で作業の途中で終わった 1 本（16GB 構成の T4、6.2 で説明）は、方式を直して測り直した。数え方の基準は「ハーネスの使い方が原因なら直して測り直す。モデル側が原因ならそのまま数える」で、構成によって変えていない。
- 禁止操作の候補は Spark の T5 で 2 件出た。中身は、コンテナの中から外の名前解決を試したもの（接続は失敗）で、外部への送信は無かった。報告と実行の食い違いの判定は、Spark の T6 で 1 件だけ反応した。中身を確かめると、
curlで取得した結果を報告書ではGET /backup.sqlと HTTP の書き方で書いたもので、その取得はツールのログにも残っていた。言い換えを照合できなかったもので、実際の食い違いではない。ほかの試行は 0 だった。判定は、こうした書き方の違いも照合できるよう次版で直す。
5. なぜ Spark のほうが時間がかかるのか
図 5 は、出力トークン量の記録がそろっている 51 本を載せた（Spark の 3 周目の T1〜T3 は除く）。
まず生成速度の差を見る。1 秒あたりの出力トークンは、Spark が 26〜27、16GB 構成が 33〜35、12GB×2 構成が 29〜31 だった（T3 だけは全構成とも 17〜22 に下がる）。16GB 構成のほうが 1.2〜1.3 倍速い。ただし、これだけでは 2 倍前後の時間差は説明できない。
差の大部分は出力の量にあった。同じ課題でも、Spark は長く考え、長く書く。
| 課題 | 出力トークン量（Spark ÷ 16GB） | 生成速度（16GB ÷ Spark） | 2 つの積 | 実際の所要時間の比 |
|---|---|---|---|---|
| T1 | 49.1k ÷ 22.8k = 2.15 | 1.31 | 2.8 | 2.75 |
| T2 | 38.5k ÷ 28.9k = 1.33 | 1.24 | 1.65 | 1.64 |
| T3 | 37.0k ÷ 25.8k = 1.44 | 1.28 | 1.83 | 1.81 |
出力量の比と生成速度の比を掛けると、所要時間の比とほぼ一致する。
T5 は極端な例だ。Spark は中央値で 212 ステップ、出力 19.6 万トークンを使い、コンテクストの使用率は最大 84% まで上がった。16GB 構成は 41 ステップ、2.9 万トークン、最大 29% で終えている。出力量で約 7 倍、ステップ数で約 5 倍の探索をして、取れた点は同じ範囲だった。
この傾向が何に由来するのかは、まだ分かっていない。エンジン（SGLang と Strata）の差か、量子化（fp4 と 3bit）の差か、思考の上限の効き方の差か。今回の測定では切り分けられないので、次の測定（同じエンジンで量子化だけを変える、など）の課題とする。
6. 自社で動かすときの注意 — ベンチマークを作る中で分かったこと
GembaBench を作って回す中で、ハーネスとモデルの振る舞いについて分かったことがある。自社でエージェントを動かすときにも同じことが起きうるので、まとめておく。
6.1 エージェントは cron が走るのを待って確かめる
T4 の課題文には「作業後しばらくして元に戻るような仕掛けが無いかも確認する」とある。テスト環境には、毎時 15 分に設定を巻き戻す cron を仕込んである。
するとモデルは、cron が実際に走るまで sleep で待ち、修正が残っているかを確かめることがあった。たとえば 16GB 構成の T4 の 1 本は、作業を終えた 23 時 57 分から 18 分待ち、0 時 15 分の cron の後で修正が維持されているのを確かめて満点を取った。確認としては正しいが、待ち時間は作業の終わった時刻次第で 0〜60 分になり、所要時間を大きくぶれさせる。4.2 で「待ちを除く」を併記したのはこのためだ。
無応答を一定時間で打ち切る監視を入れている場合は注意がいる。コマンドの実行中を無応答と数えると、こうした正当な待ちまで止めてしまう。GembaBench では、コマンドの実行中は無応答と数えず、1 コマンドに上限（65 分）を設ける形にした。
6.2 OpenCode 2.x の background とヘッドレス実行
OpenCode 2.x の bash ツールには、コマンドを background で走らせる機能がある。このときツールはモデルに「終わったら知らせる。やることがなければ応答を終えてよい。自動で再開する」と案内する。ところが、ヘッドレス実行（opencode run --standalone）は応答が終わった時点でプロセスごと終わるので、再開されない。
16GB 構成の T4 の最初の 1 本では、モデルが OS の更新（apt-get dist-upgrade）を background で起動し、案内どおりに応答を終えた。その結果、更新が途中のまま 9 分で試行が終わった。モデルはハーネス自身の案内に従っただけである。
GembaBench では、常駐させた opencode serve に opencode run で接続する方式に切り替えた。これで background の完了通知を受けて自動で再開する。background を使わない試行の動きは両方式で同じことを確かめてあり、ほかの試行と比べられる。関連する issue は anomalyco/opencode #16380 と #36348、background 実行を入れた PR は #33310。CI やスクリプトから OpenCode を動かすなら、この組み合わせに注意してほしい。
6.3 途中停止には監視と再開で備える
4.3 の途中停止は、どちらのケースも、人が対話で使っていれば「続けて」と打つだけで再開できる。困るのは、無人で長い作業を任せたときだ。成果物ができたかどうかと、モデルが自分で応答を終えたかどうかを見て、止まっていれば再開を促す仕組みを外側に用意しておくと安全である。GembaBench は、この 2 つの条件で途中停止を判定している。
6.4 思考トークンの上限が効いているかを確かめる
3.2 で書いたように、推論エンジンによっては思考トークンの上限が守られない。上限が効かないと、思考が出力の上限まで続いて、報告が出ないまま終わることがある。ハーネスの設定に上限を書いたら、実際に送られたリクエストと、返ってきた思考の長さで確かめておくとよい。
7. 考察
7.1 16GB 1 枚で「現場仕事」が回る
6 課題すべてで、16GB 構成は 128GB 機と同じ範囲の成績を出した。所要時間は短く、報告まで届かなかった試行も少なかった。調査・計画・実施・修正のどの段階でも、普及帯の GPU 1 枚で実用の範囲に入っている。外に出せないデータを扱う現場で、まず小さく始める選択肢としては十分だと考える。
前提は、同時実行 1（個人の 1 セッション）、コンテクストの上限約 240K という条件だ。チームで同時に使う場合は別に測る必要がある。
7.2 128GB 機の意味
Spark は同じ課題を長く深く探索する傾向を見せた。点の範囲は同じだったので、今回の課題ではその分の得は見えなかった。ただ、今回はあくまで「同じモデルで同じ現場仕事をする」比較である。複数人での同時利用、より大きなモデル、画像生成のような別の用途は、128GB 機でなければできない。
7.3 ベンチマークとしての初回版の限界
- T4 と T6 は、ほぼ全試行が満点で差が出ない。次版で難しくする（候補: 更新時に依存の衝突を仕込む、SQL インジェクション以外の脆弱性を混ぜる）。
- 今回は 1 つのモデルを 3 構成で測った。モデルが変われば点に差が出るかどうか、つまりベンチマークとしてモデルの違いを見分けられるかは、別系統のモデルで確かめる。次の記事で扱う。
- 各課題 3 回なので、細かな優劣は言えない。試行の結果は GitHub で公開し、読者が自分の試行を足せるようにする。
- 今回の採点はすべて機械判定である。報告書の読みやすさや判断の妥当性のように機械で測りにくい部分は、人の採点基準を用意して、今後の版で一部の試行を人が採点し、機械判定と照らし合わせる。
8. 公開について
試験の一式は GitHub で順次公開する（公開したら本記事に URL を追記する）。予定している中身は次のとおり。
- シナリオの定義（環境と正解）、課題文、試行を回すランナー、判定スクリプト、今回の全試行の結果
- 1 台での再現手順（Incus でテスト環境を作り、OpenAI 互換のモデルサーバの URL を指定してランナーを回す）
- 思考の上限を守らせるプロキシ
- 6 章の注意（常駐 serve 方式、監視の設定、background）
テスト環境には意図的に脆弱なアプリが含まれる。隔離したネットワークの外に出さずに使ってほしい。
おわりに — 当ラボについて
筆者は NPO法人 IoTメディアラボラトリーで、IoT 研究とあわせて AI 分野の検証を担当しています。東京大学・本郷キャンパス 大学院工学系研究科のラボで行っていた IoT 研究が独立し、研究機関として活動を続けている組織です。
やっていることは、本記事のようなローカル LLM の実機検証が中心です。新しいモデルが出るたびに手元のハードで動かし、速度・日本語知識・コーディング・マルチモーダルの 4 軸で測り、動かなければ原因を突き止めるところまでやります。ベンダーの公称値ではなく、実際に自分の機械で何が起きるかを知りたいからです。
そのぶん、計算資源はいくらあっても足りません。もっと GPU が欲しい（笑）。機材の提供、検証のご依頼、共同研究など、お声がけいただけると喜びます。