はじめに
GMOコネクトの永田です。
外に出せない資料をAIエージェントに読ませたい、という場面があります。12ファイル・約39万字の仕様書群をツールで探索させて、条件に合う項目を漏れなく表に起こす。ファイル一覧を取り、検索し、中身を読み、また検索する。ツールを何十回も呼ぶ長時間の作業です。
3か月前に同じ機材で単体テスト生成を試したときは、単発生成ですら苦戦しました。エージェント作業となればなおさらだろうと思っていました。
手元に正解データがあったので、採点できる形で試しています。直前の記事と同じ課題で、実行先だけをローカルに変えた記録です。
先にまとめ
同じ128GBに載る2つのモデルで、成立と不成立がはっきり分かれました。
正解は59行あります。1本のランで平均何行を当てられたか、そして10本を重ね合わせて何行に届くか（10本の和集合）で見ます。
| 指標 | GLM-5.3-Flash（2bit） | gpt-oss-120b |
|---|---|---|
| 1本で当てた数の平均 | 42.8 / 59 | 7.7 / 59 |
| 10本の和集合 | 58 / 59 | 27 / 59 |
| 1行も当てられなかったラン | 0/10 | 4/10 |
| 1本の所要 | 15.7分 | 0.5分 |
| 重み | 108.7GB | 65GB |
- 分かれ目はモデルのサイズでも生成速度でもなく、ツールを呼び続けられたかでした。所要時間の差も、生成の速さではなく処理したトークン数で決まっています
- 10本の和集合は59行中58行でした。参照のフロンティアも同じ58行で止まり、落ちた1行も同じです。この課題の上限が58行だったとみるのが自然で、ローカルが追いついたという話ではありません
- 分かれるのは間違え方です。誤検知は1本あたりでは3分の1なのに、10本の和集合では5.0倍に増えて逆転します
- 測り方で4回間違えて、6〜7時間を捨てました
1. 128GBに載るモデルを選ぶ
公開ベンチの上位モデルは、そのままでは128GBに載りません。
ここで一度判断を誤りました。4bit量子化を前提に計算して「候補がほぼ無い」と結論したのですが、2bitまで見ると話が変わります。GLM-5.3-Flash は総パラメータ320B・活性18BのMoEで、Unsloth が公開している2bitのGGUF（UD-Q2_K_XL）なら108.7GBです。自分で量子化したのではなく、公開されているものをそのまま使いました。実際に載せると121GiB中110GiBを使って動きます。
もう一方は gpt-oss-120b で、重みは65GBです。こちらは公式が学習後に MXFP4 を適用した形式がそのまま配布されています。
つまり2つは対称ではありません。GLM だけが本家の配布形から2bitまで落とされた版です。
ここで効いてくるのが文脈の長さです。重みで110GiBを使うと、文脈に回せるメモリはほとんど残りません。 GLM-5.3-Flash で実際に確保できたのは65,536トークンでした。ツールを何十回も呼ぶ作業では、この上限が直接効いてきます。2bitで載せる代償は、精度だけではありませんでした。
GLM-5.3-Flash は 2026年8月26日公開で、この記事を書いている時点でまだ2週間しか経っていません。gpt-oss-120b と違って追試の材料が揃っておらず、評価も固まっていません。この記事の数字も暫定です。
実行環境は DGX Spark（128GB統合メモリ、帯域273GB/s）、推論は llama.cpp です。
27B級の密なモデルも同じ条件で回しましたが、この課題ではほとんど出力が得られませんでした。量子化の影響なのか、エージェント作業との相性なのか、課題との相性なのかを切り分けていないので、この記事では扱いません。
2. どこまでできたか
課題と採点
課題は「大量の仕様書を読んで、条件に合う項目を漏れなく列挙する」ものです。正解は事前に人手で作ってあります。
| 項目 | 内容 |
|---|---|
| 入力 | 12ファイル・約39万字 |
| 正解 | 59行 |
| 入力の版 | 版A: 現行の仕様書一式 ／ 版B: 版Aに項目を13件足したもの（差は1ファイル・4,439字だけ） |
| ラン数 | 版ごとに10本 ＝ モデルごとに20本 |
2つの版は、もとの実験で「項目を足したとき、足した所以外の確認が薄くならないか」を見るためのものでした。その「足した所以外」がちょうど59行あり、そこが採点対象です。
版の違いはこの記事の主題ではないので、以下は版Aの数字を載せ、版で差が出たところだけ両方を示します。
エージェントのループは自作しました。既製のCLIは独自のシステムプロンプト・文脈の自動圧縮・ツール定義を持ち込むので、出た差がモデルのものか道具のものか分からなくなるからです。ターン数・トークン数・停止理由・出した行数もランごとに記録しました。この記事の数字の半分はそこから出ています。
与えたツールは5つだけです。
-
glob— ファイル一覧を取る -
grep— 中身を検索する -
read_file— 読む - 出力の追記
- 終了宣言
ターンごとに、モデルの返答とツールの結果を会話へ足し、次のターンで会話全体をまた送ります。往復するほど入力が伸び、収まらなくなったところで終わりです。ランが終わるのは次のどれかです。
- モデルが終了を宣言した
- 会話が95,000字に達した
- 100ターンに達した
上限をトークンではなく文字数にしたのは、日本語1トークンあたりの文字数がトークナイザごとに違うからです。「全モデル65,536トークン」で揃えると、読める中身の量がモデルごとに変わってしまいます。いちばん効率の悪いモデルを基準に換算しました。
温度や推論の強さといった設定は、追試しやすいように3章へまとめてあります。
結果
版A（現行の仕様書一式）で各10本を回した結果です。
| モデル（版A） | 1本で当てた数の平均（幅） | 10本の和集合 | 正解に無い行 | 1行も当てられなかったラン | 平均分 |
|---|---|---|---|---|---|
| GLM-5.3-Flash | 42.8（24〜50） | 58 | 4.0 | 0/10 | 15.7 |
| gpt-oss-120b | 7.7（0〜27） | 27 | 0.1 | 4/10 | 0.5 |
いずれも分母は正解59行です。「正解に無い行」は的外れな行を挙げた数で、少ないほど無駄がありません。
版B（項目を13件足した版）でも各10本を回しており、GLM 40.3・gpt-oss 9.6 と傾向は同じでした。
失敗の中身は2種類ありました。gpt-oss は10本中9本が表を出しているのに、そのうち3本は1行も当たっていません。残る1本は表そのものが空でした。
実行系もプロンプトも採点も共通なので、この差はモデルの違いに帰属できます。GLM-5.3-Flash は両版あわせて20本すべてで当てにいきました。 版Aの平均は gpt-oss の5.6倍です。gpt-oss-120b は1ラン30秒で終わりますが、10本中4本は1行も当てられていません。
差はどこから来たのか
所要時間は30.8倍違います。機材は同じ DGX Spark なので、処理したトークン数と、1トークンあたりにかかった時間に分けました。20ランずつの平均です。
| 指標 | GLM | gpt-oss | 比 |
|---|---|---|---|
| ターン数 | 23.8 | 8.8 | 2.7倍 |
| 入力トークン | 734,683 | 57,512 | 12.8倍 |
| 生成トークン | 5,955 | 1,165 | 5.1倍 |
| 処理したトークン合計 | 740,638 | 58,677 | 12.6倍 |
| 実測秒 | 956.9 | 31.1 | 30.8倍 |
| 1トークンあたりの秒数 | 0.00129 | 0.00053 | 2.4倍 |
所要時間の30.8倍は、処理したトークン数の12.6倍と、1トークンあたりの遅さ2.4倍に分かれます。大きいのはトークン数のほうでした。
その中身が、ターン数2.7倍に対して入力トークン12.8倍です。ループは毎ターン会話全体を送り直すので、入力側はターン数より速く膨らみます。
生成側の tok/s だけでモデルを選ぶと、この構造は見えません。
どちらも自力では終わっていない
都合の悪い事実があります。終了宣言を呼んだのは GLM が20ラン中0回、gpt-oss が4回でした。GLM は20ラン全部が、会話が上限に届いての打ち切りです。gpt-oss は残り16ランが「ツールを呼ばなくなった」ことによる停止でした。
つまり GLM について「粘り強く働けた」とは書けません。打ち切られるまで止まらなかった、が正確なところです。有益な探索の途中で切られたのか、95,000字を超えても終わらなかったのかは、上限を上げて試していないので区別できません。
網羅は58行で頭打ちになった
参照として、フロンティアのモデルでも同じ課題を同じ10本だけ回してあります。実際に動いたのは Opus 4.7 で、Opus 5 から見ると2世代前です。最上位ではありません。
ただし条件が揃っていないので、優劣の判定には使えません。Claude 側は claude -p で文脈200K・自動圧縮あり・推論の強さ high、ローカル側は自作ループで95,000字・圧縮なし・low です。以下は同じ課題を解かせたときの参考値です。
| 指標 | Claude（参照） | GLM-5.3-Flash |
|---|---|---|
| 1本で当てた数の平均 | 52.7（42〜58） | 42.8（24〜50） |
| 10本の和集合 | 58 | 58 |
| 正解に無い行・1本平均 | 11.2 | 4.0 |
| 正解に無い行・10本の和集合 | 14 | 20 |
1本あたりの当たり数は Claude のほうが多く出ました。10本どうしを総当たりで比べた100組では、GLM が上回るのは14組、引き分けが2組、残る84組は Claude です。
ところが10本の和集合はどちらも58です。59には届きません。しかも落ちた1行は両者で同じでした。まったく違う実行系で10本ずつ回して、同じ1行だけが最後まで挙がってきません。
ローカルが追いついたという読み方はできません。 能力が並んだのではなく、課題の側に58行という上限があって、両方がそこで止まったとみるほうが自然です。その1行が入力から辿れないのか、正解の作り方の問題なのかは切り分けていません。
分かれるのは間違え方
差が出るのは、当たりではなく間違いのほうです。
| 対象 | 1本の平均 | 10本の和集合 | 倍率 |
|---|---|---|---|
| Claude・当たり | 52.7 | 58 | 1.1倍 |
| Claude・正解に無い行 | 11.2 | 14 | 1.2倍 |
| GLM・当たり | 42.8 | 58 | 1.4倍 |
| GLM・正解に無い行 | 4.0 | 20 | 5.0倍 |
1本だけ見れば、誤検知は GLM のほうが3分の1です。ところが回数を重ねると逆転します。
Claude は毎回だいたい同じ所を間違え、GLM は毎回違う所を間違えています。 和集合は後者を罰します。当たりが散らばるおかげで網羅は伸びるのですが、外れも同じだけ散らばるので、その外れまで拾い集めてしまいます。
版B でも同じ形でした。 GLM の誤検知は1本3.5から和集合29へ、8.3倍に増えています。
回数で埋められるのは網羅だけです。 拾い上げの用途なら成立しますが、そのまま成果物にはできません。
3. 測った条件と実測値
追試する方のために、条件と数値をまとめて置いておきます。
ローカル2モデルに共通の条件
| 項目 | 設定 |
|---|---|
| 温度 | 1.0 |
| 推論の強さ | low |
| seed | ランごとに変更 |
| 会話の上限 | 95,000字 |
| 最大ターン | 100 |
| ハード | DGX Spark 128GB・帯域273GB/s |
| 推論 | llama.cpp（自作ループ） |
ローカル2モデルの違い
| 項目 | GLM-5.3-Flash | gpt-oss-120b |
|---|---|---|
| 入手元 | Unsloth 公開の GGUF | 公式配布のまま |
| 量子化 | UD-Q2_K_XL（2bit） | MXFP4（MoE部分） |
| 重み | 108.7GB | 65GB |
| 生成 tok/s | 14.99 | 50.34 |
| 入力処理 tok/s（推定） | 1,313 | 7,261 |
参照した Claude 側の条件
| 項目 | 設定 |
|---|---|
| 実行 |
claude -p（Claude Code CLI） |
| モデル |
--model opus → claude-opus-4-7（補助に Haiku 4.5） |
| 推論の強さ | --effort high |
| ツール | Read / Grep / Glob / Write / Edit / TodoWrite |
| 文脈 | 200K・自動圧縮あり |
| ラン数と所要 | 版A 10本・平均7.2分 |
| 費用 | 10本で $38.69 |
ローカル側の平均ターン数や所要時間は2章の表にあります。
4. 測る前に4回間違えた
いちばん時間を溶かしたのは、モデルの性能ではありませんでした。
間違い1: 温度0でも揺れると思い込んでいた
条件を揃えるつもりで温度0にしました。API経由の生成は温度0でも多少は揺れるという一般論から、ローカルでも同じだろうと考えていて、確かめていません。
4条件を10本ずつ、計40ラン。出てきたのは同じ条件の10本が1バイトも違わない同じファイルでした（gpt-oss の1条件だけ2種類）。所要時間まで862秒・860秒・863秒と揃います。llama.cpp のローカル実行は温度0で完全に再現するので、ばらつきも和集合も測れません。6〜7時間を捨てました。
間違いは温度0を選んだことではなく、揺れると思い込んだことです。 結果のほうは良好でした。
| 条件 | 1本の当たり | 1本の誤検知 | 10本の和集合 | 和集合の誤検知 |
|---|---|---|---|---|
| 温度0・版A | 52.0 | 0.0 | 52 | 0 |
| 温度0・版B | 25.0 | 1.0 | 25 | 1 |
| 温度1.0・版A | 42.8 | 4.0 | 58 | 20 |
| 温度1.0・版B | 40.3 | 3.5 | 58 | 29 |
温度0の版Aは1本で52行を当てて誤検知ゼロで、温度1.0の1本（42.8・誤検知4.0）を両軸で上回ります。ところが版Bは25行しか当たらず、再実行しても同じ25行が出るので、外れを引いたことに気づけません。
温度は成績を上げる設定ではなく、外したときに回復できるかどうかの設定でした。温度1.0は1本では劣ることもありますが、どちらの版でも10本で58に届きます。当てた数の幅は22〜50で、3本では足りません。
ただし和集合が常に得なわけでもありません。版Aなら、15分1本で52行・誤検知0か、2時間半10本で58行・誤検知20かの選択です。1本しか回さない運用なら温度0でしょう。この記事が温度1.0なのは、ばらつきを測りたかったからです。
間違い2: 推論の強さを指定していなかった
reasoning_effort を渡していませんでした。既定値はモデルごとに違います。
- GLM-5.3-Flash: 既定は
max。値は low / high / max（Unsloth に "GLM-5.3-Flash uses Max reasoning by default." と明記） - gpt-oss: 推奨は
medium。値は low / medium / high（Unsloth）
指定しなければ、モデルごとに違う強さで走ります。 モデルを比べているつもりで、強さの違いも一緒に測ることになります。
GLM を low にすると、1応答が20.7秒から2.3秒に、生成トークンが352から27になりました。探索の仕方まで変わり、read_file 中心から grep 中心になっています。同じモデルとは思えない動き方です。
low が良いという話ではありません。 この記事の結果はすべて low に揃えたときのもので、max でどうなるかは測っていません。時間をかけられる用途や、もっと速いハードなら max のほうが良い可能性は十分にあります。揃っていなかったことが問題でした。
llama.cpp では起動時に --chat-template-kwargs '{"reasoning_effort": "low"}' で渡します。APIのパラメータとして送っても効きません（llama-server が無視するという要望が出ています）。
間違い3: ハーネス側で取りこぼしていた
自作ループの不具合で、モデルの成果を捨てていました。
読み込みの既定行数が大きすぎて1回で26,000字返り、8ターンで95,000字を使い切る。表の行を数える処理が行頭の | を前提にしていて、それを欠く出力を0行と数える。しかも追記後の確認にも同じ判定を使っていたので、モデルには常に「現在0行」と返っていました。二重に書き足していた可能性があります。
ツールを呼ばずに本文へ表を書いた場合も捨てていました。実際に22行を捨てています。
モデルを比べる前に、ハーネスが成果を落としていないかを確認するべきでした。
間違い4: 生成側の tok/s だけを見ていた
Artificial Analysis の指標には既に Cost per Task（1タスクを完了する加重平均コスト）と End-to-End Response Time があり、後者の定義には "including input processing time" と入力処理時間を含むことが明記されています。llama.cpp の llama-bench も、prompt processing と text generation を別々の行で報告します。
道具のほうはとっくに分けて出していて、片方しか見ていなかったのが私でした。
Artificial Analysis が測っているのはAPI提供のモデルなので、自分の機材で自分の課題を自分のループで回したときの数字は、自分で測るしかありません。 測ったら、所要時間の差を決めていたのはトークン数のほうでした。
まとめ: いまローカルで引ける線
- 128GBのローカル機でも、長時間のエージェント作業は成立します。 ただしモデル選びで決まります。同じ機材に載る2つで42.8と7.7に分かれ、分かれ目はサイズでも生成速度でもなく、ツールを呼び続けられるかでした
- 1本15分かかり、しかも自力では終わりません。 GLM は全ランが文脈の上限で打ち切りです。重みで110GiBを使うと文脈が残らないので、対話ではなくバッチで回す用途になります
- 10本の和集合は59行中58行。 参照のフロンティアも同じ58行で止まり、落ちた1行も同じでした。課題の側の上限とみるのが自然で、ローカルが追いついたわけではありません
- 回数を増やせば良いとは限りません。 1本あたりの誤検知はローカルのほうが少ないのに、和集合では5.0倍に増えて逆転します。温度0なら1本で52行・誤検知0だったので、6行のために誤検知20と10倍の時間を払うかは用途次第です
- 課題は1種類、モデルは2つ、GLM は公開2週間です。数字はすべて推論の強さ
lowでの値で、maxは測っていません。Claude との比較も条件が違うので参考値です
3か月前は単体テスト生成すら怪しかったので、そこから見ると別物になりました。外に出せない資料をバッチで処理する用途なら、選択肢に入る段階まで来ていると思います。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。