GLM 5.2 対 Opus
(techstackups.com)- 同じワンショットプロンプトで raw WebGL 3Dプラットフォームゲーム を作らせたところ、Opus はより高速で完成度の高い結果を出し、GLM-5.2 は低コストとオープンウェイトという強みを示した
- GLM-5.2 は Z.ai の MITライセンスのオープンウェイト モデルで、1Mトークンのコンテキストと High/Max の思考レベルを提供するが、テキスト専用のため画像ベースの自己検証には限界がある
- 実際のテストコストは GLM-5.2 が $5.39、Opus が約 $21.92 で、ビルド時間はそれぞれ1時間10分40秒と33分30秒となり、速度とコストで選択肢が分かれた
- GLM-5.2 の成果物にはテクスチャ欠落、動作しないスパイク、勝利条件の欠如、デバッグオーバーレイの残存といった基本的な問題があり、Opus はよりクリーンだったが、薄い空中足場の当たり判定や遠い勝利トリガーが残った
- ベンチマークと外部評価でも GLM-5.2 は強力なオープンウェイトモデルと見られているが、多くのコーディング・エージェント作業では Opus が優勢で、コスト・開放性・視覚判断 が選択基準になる
同じ課題で現れた差
- GLM-5.2 はオープンモデルの可能性を示す最新事例だが、同一の実戦課題では Claude Opus 4.8 がより速く正確な成果物を出した
- テストでは両モデルに同じワンショットプロンプトを与え、ゲームエンジンや Three.js のような 3D レンダリングライブラリを使わず、ブラウザ向け3Dプラットフォームゲーム を raw WebGL でゼロから作らせた
- 両方の成果物とソースは公開されている
- 両ゲームとも無料の CC0 アセットである Kenney Platformer Kit を使用している
GLM-5.2 の性格とアプローチ
- GLM-5.2 は Z.ai の最新フラッグシップモデルで、MITライセンスのオープンウェイト として提供されている
- ダウンロードして自分で実行することも、Z.ai API で呼び出すこともできる
- Hugging Face と ModelScope にウェイトが公開されており、地域制限はない
- vLLM、SGLang、Transformers のようなフレームワークでローカルサービングが可能
- モデルは長時間の多段階コーディングエージェント作業のような long-horizon タスク を狙っている
- 1M トークンのコンテキストウィンドウを提供する
- 思考レベルは High と Max があり、テストでは High が使われた
- 決定的な制約は テキスト専用 である点
- GLM-5.2 は画像を読めない
- スクリーンショットや図を直接確認する必要があるワークフローには、Claude Opus のようなマルチモーダルモデルが必要になる
価格と実行コスト
- ベンダー文書ベースの 1M トークンあたり価格は、GLM-5.2 のほうが Opus より低い
- Claude Opus 4.8: 入力 $5、キャッシュ読み取り $0.50、出力 $25
- GLM-5.2: 入力 $1.4、キャッシュ読み取り $0.26、出力 $4.4
- 出力トークン基準では、GLM-5.2 は Opus 価格の 5分の1未満
- 実際のゲーム制作テストでは、時間とコストで逆の傾向が出た
| 指標 | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| 実時間ベースのビルド時間 | 1時間10分40秒 | 33分30秒 |
| 出力トークン | 131,000 | 216,809 |
| 最大コンテキスト使用量 | 1Mの16% | 1Mの19% |
| ツール呼び出し | 128 | 153 |
| コスト | $5.39 実請求額 | 約 $21.92 推定 |
- Opus は約半分の時間で完了し、GLM-5.2 ははるかに低いコストで作業を終えた
テスト課題: raw WebGL 3Dプラットフォームゲーム
- 課題は単純なランディングページ生成より構造が複雑だった
- GLB モデルパーサー
- 行列・ベクトル数学
- GLSL シェーダー
- スキニングされた骨格アニメーション
- 固定タイムステップループ
- 衝突処理
- フォローカメラ
- 両モデルは同一のプロンプト、同一のアセット、ヒントなしの単一試行を与えられた
- 完成条件は次の通りだった
- raw WebGL ベースの 3D エンジンとレンダラー
- 提供された 3D キャラクターとワールドモデルローダー
- 重力と衝突のあるキャラクター移動・ジャンプ
- フォローカメラとキーボード操作
- 1つのコマンドでブラウザ上で実行できる完全なゲーム
- 両モデルとも GLB バイナリパーサー、行列・クォータニオン数学、WebGL2 レンダラー、GLSL スキニングシェーダー、サブステップ AABB 衝突をかなりの部分まで自前で実装した
- ビルド記録も公開されている
プレイ結果と残ったバグ
- 両ゲームとも三人称視点の 3D プラットフォームゲームの形になっている
- WASD または矢印キーで移動
- Space でジャンプ
- Shift でダッシュ
- マウスドラッグでカメラ回転
- ホイールでズーム
- コインを集め、スパイクを避け、旗に到達する目標がある
- マップ外に落ちるとスタート地点に戻る
-
GLM-5.2 の結果
- GLM-5.2 のゲームは全体として 粗い完成度 を見せた
- キャラクターの一部マテリアルが欠け、移動方向とは逆を向いたまま歩く問題があった
- スパイクトラップはキャラクターを倒したりリセットしたりせず、旗に到達しても勝利条件が発動しなかった
- カメラが動くと頭が消え、デバッグオーバーレイも残っていた
- スプリングを踏むと次のプラットフォームまでキャラクターが跳ね上がる部分はうまく動作した
- Kenney モデルは別ファイルの共有カラーパレットを参照するが、GLM-5.2 のレンダラーはこのファイルを読み込まなかったため、フラットカラー に置き換えられた
-
Opus の結果
- Opus のゲームはよりクリーンでよく動作した
- カメラとコントローラーが機能し、スパイクがプレイヤーを倒すロジックも動作した
- テクスチャは正しく適用され、アニメーションは滑らかで、旗に到達すると勝利できた
- 残ったバグは基本機能より エッジケース に近かった
- プラットフォームの横の空中でキャラクターが一瞬立ててしまい、これは端から外れた直後でもジャンプを許す coyote-time の猶予が過剰に設定されていたためだった
- 旗からまだかなり離れていても勝利条件が発動した
自己検証で分かれたマルチモーダルの差
- 両モデルとも作業を終える前に結果を検証するよう指示されていた
- Opus はマルチモーダルモデルなので、ゲームをレンダリングしたあとキャプチャした スクリーンショットを直接検査 した
- 画面に残っていたデバッグ表示を見つけて削除してから仕上げた
- 最終シーンでブロック、階段、コイン、宝石、スパイク、旗、キャラクター、スコア HUD、ライティングとジオメトリを確認した
- GLM-5.2 は画像を読めないため、スクリーンショットを直接見ることができなかった
- 代わりに生のピクセルデータを読み、色が期待値とおおむね一致するか確認する迂回手段を使った
- 保存画像で grass green、dirt brown、coin gold、flag red、character bluish、half-Lambert lit、no black といった色条件を確認した
- この方式では実際の画面上の問題を見逃した
- キャラクターは灰色に見え、テクスチャが欠落した状態だった
- デバッグオーバーレイは依然として画面上に残っていた
- 視覚的成果物が重要な作業では、画像を理解できる マルチモーダル検証 が実際の品質差につながる
ベンチマークで見えた位置
- Z.ai のモデルカードのベンチマークでは、GLM-5.2 は最上位のクローズドモデルのすぐ後ろに位置する項目が多く、一部の推論ベンチマークでは上回っていた
- 主な数値は次の通り
- HLE: GLM-5.2 40.5, Opus 4.8 49.8
- HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
- AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
- IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
- SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
- NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
- ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
- SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
- MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
- Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
- ArtificialAnalysis の独立実行結果でも、GLM-5.2 は強力なオープンウェイトモデルと評価されている
- Intelligence Index v4.1 スコアは 51
- MiniMax-M3 44、DeepSeek V4 Pro 44、Kimi K2.6 43 を上回る
- TerminalBench v2.1 は 78% で、モデルカードの 81 または 82.7 とは異なるハーネスを使用している
- タスクあたりの出力トークンは約 43k で、GLM-5.1 の 26k より多い
- ベンチマークの流れは実戦テストと似ている
- GLM-5.2 はオープンウェイトモデルの中で先頭集団におり、推論では一部競争力がある
- Opus はコーディングとエージェント系ベンチマークの多くで優勢
外部の反応
- Simon Willison は GLM-5.2 を「おそらく最も強力なテキスト専用オープンウェイト LLM」と評価した
- 彼の SVG テストでは、GLM-5.2 は自転車に乗るペリカンを完全アニメーションで生成し、破綻もなかった
- スクーターに乗るオポッサムのテストは前の GLM-5.1 より良くなく、性能が均一ではないことも示した
- Artificial Analysis は GLM-5.2 を自社 Intelligence Index における 先頭のオープンウェイトモデル と評価している
- 同水準で最も安価なモデルであり、コスト対知能のフロンティアにあると見ている
- ただし、タスクあたり約 43k の出力トークンを使うトークン消費の大きいモデルとも記している
- Nathan Lambert は、LMArena リーダーボード基準では GLM-5.2 は Gemini より優れたエージェントと見なせる可能性があり、MIT ライセンスのオープンモデルとしては「serious accomplishment」だと評価した
- 最上位の米国モデルが依然として全体では先行しているが、中国の研究所がより少ない計算資源で高スコアに到達している点を強調した
どのモデルを選ぶべきか
- GLM-5.2 は Opus 価格の一部で強い性能を出す オープンウェイトモデル
- コストと開放性が重要で、作業が主にテキストと論理中心のときに向いている
- ダウンロード可能なウェイトは、クローズドモデルのように突然引退したり制限されたりしない
- Opus はテストでより速く、よりクリーンで、より正確な結果を出した
- 視覚的成果物を直接見て検証できる
- 正確性、仕上がり、視覚判断が重要で、コストを許容できる作業により適している
- GLM-5.2 は Opus を置き換える主力モデルというより、安価で常時アクセス可能な強力な補助モデルに近い
1件のコメント
Hacker Newsの意見
ワンショットプロンプティングがなぜこれほど大騒ぎされているのか、本当に分からない
定義上、単一のプロンプト1つでソフトウェアプロジェクトの複雑さを表現できるはずがない。結局のところ、モデルは学習コーパス内の既存コードをもとに複数の仮定を置いて結果を出しているだけだ
むしろ、人間がレビューした仕様のガードレールやコーディング規約を守りつつ、計画ファイルのステップを正確にたどるコーディングエージェントを見たい。人間が定めた目標に対して、エージェントループがガードレールを外れず、目標完了までぶれないかどうかも検証すべきだ
また、作ろうとしているユースケースの文脈を把握して、既存コードからバグや性能改善の余地を見つけ、リファクタリングを提案する能力のほうが、はるかに価値のある指標だ
出力が入力に合っているかを見るベンチマークというより、出力物が内部的に一貫しているかを見ることに近い。ゲームなら、目標に到達したら終了するか、とげに触れたら死ぬか、移動時におかしな境界ケースが生じないかを見るようなものだ
ただ、同じ実行環境を使って実験を複数回繰り返し、結果の分散も見るべきだったと思う
昔は、あるフレームワークのREADMEに従って空のプロジェクトで試しただけで「うちの10年物の本番アプリにはこのフレームワークが最高だ」と言うエンジニアをからかっていたものだ。グリーンフィールド的な発想は、あらゆる問題の解決策であり、同時にあらゆる解決策の問題でもある
ワンショット能力も重要な自己測定指標なので測るべきだが、すでに定着した大規模コードベースを対象にすべきだ
Claude CodeとOpusが大きく注目されたのは、実行環境が改善され、ユーザー入力なしでも多くのミスを自力で修正できるようになったからだ。長期的には、数時間単位の自律性と自己修正能力で今後最も大きな改善が出る気がする
入力トークン数個から数百万トークンを生成すること自体には、大した意味はないと思う
より良いモデルを評価したければ、タスクに要求事項を追加していけばよい。現実的なユースケースではなくても、有用な方法だと思う
もちろん、ソフトウェアエンジニアが操縦すれば、モデルははるかに良い結果を出せる。エンジニア次第では、逆に悪くなることもある
「同じワンショットプロンプトでClaude Opus 4.8と正面対決させた: 生のWebGLで3Dプラットフォームゲームをゼロから作る」といった単一のワンショット実行は、ベンチマークでもなければ現実の利用を代表しているわけでもない
たいていのエージェント利用は協調型なので、作業を任せたときにテスト結果を捏造せず完了するかといった信頼性や、こちらの指示に従うのか、それとも勝手に進めるのかといった操作可能性をテストすべきだ
このテストは、両モデルに時間がかかり技術的にも難しいワンショット作業を与えたとき、何ができるかを示している
協業、作業委任、完了、テスト駆動開発、操作可能性を見る形式は、今後ぜひ試す価値のある良いテストだと思う
考えてみると、自分が行っているエージェント作業の大半は、メインセッション内で独自プロンプトにより走るサブエージェントだ。これらも完全自律タスクの短い版と見なせる
記事でもそうした内容は扱っており、これ自体を正式なベンチマークとして意図したわけではない。正式なベンチマークはすでに十分ある
Anthropicがずっと529 Overloadedを返してくるので、昨日GLM 5.2に登録して使ってみた
気に入ってはいるが、GLM 5.2のxhighでプロンプト2つを入れた単一セッションだけで、5時間リセット枠のライトプラン利用量を22%消費した
結果には満足していて品質も悪くない。両方使いたいので、AnthropicとGLMを一緒に使える統合サブスクリプションプランがあるといい
いくつかのプロジェクトでGLM 5.2を使った感想としては、コードを書き始めるまでにかなり時間がかかり、決して速いモデルではないということだ
探索と計画の段階でかなり脇道にそれるが、その後に軌道修正するし、操作しやすくもない。あとで従わない内容を幻覚するからだ。それでも出力品質はかなり良い
たとえばSwift+Zigのコードベースでレンダリングを最適化したとき、5千件のデータ項目で詰まっていた。GLM 5.2はベンチマークを作ってデータを抽出するのに20分使い、しびれを切らして編集以外のツールアクセスを止めて席を外した。約30分後に戻ると、すでに作っておいたベンチマークといくつかの「結論」をもとに3つのボトルネックを最適化しており、疑いを検証できないので追加データが必要だとも述べていた
実装はうまく動き、イディオマティックで非侵襲的だった。同じリポジトリでGPT 5.5が作った結果より、よりイディオマティックだったと言ってもいい。もっと使いたいが、GPTは普通、同じ依頼を5倍速く終える
GLM 5.2のおかげで、隔離コンテナとJJワークスペース内で複数を並列実行する構成を準備することになった
macOSメニューバーで左クリックを横取りし、Ctrl+クリックや右クリックが元の左クリックのようにメニューを出すようにしつつ、条件付きで動作させるという問題だった
問題解決セッションの途中でモデルをGLM-5.2に切り替え、プロンプトを入れ直しもせず、推論途中で交換したのに、数分後には問題が直っていた。OpenCode Goのサブスクリプションベース割り当てで使ったのだが、この種の問題はOpusの使用量を今の5時間枠、あるいは週次上限まで使い切ってしまうことがあった
モデルが軌道を外れているのを見たり、こちらが言っていない部分を見つけたりしたら止めて修正できる。あるいは、なぜそういう選択をしたのかも学べるので、あとで疑問を持つ必要が減る
私の経験ともかなり近い。Piで使っているが、賢くて出力も良いものの、そこに至るまでの過程が効率的ではない
「GLM-5.2は画像を読めないので、ここで問題が起きた。マルチモーダルではないからだ。そこでスクリーンショットを見る代わりに、生のピクセルデータを読んで色がだいたい想定どおりに出ているか確認するスクリプトを書くという裏技を使った」とあるが、もっと良い方法は https://github.com/openbmb/MiniCPM-V を使うことだ
本当にやりたければ画像をOpusに呼ばせてもいいし、それでもコストは節約できそうだ
オープンソースモデルを試そうと思ってOllamaに登録した
この3か月間はずっと実験して使ってみる程度だったが、GLMはClaudeと並んで、実際のコーディング作業で毎日使っている最初のモデルだ。かなり良くて、毎日Ollamaの使用上限まで使い切っている
GLMは支払うトークン数も少なく、ツール呼び出しも少ないのに、完了までには2倍以上かかる
その時間がモデルの動作自体でないなら、どこで使われているのか気になる
個々のツール呼び出しがより複雑で時間がかかるのか、それともモデルがトークンごとにより多くの計算をしていて秒間トークン数が低いのか？
それにGLM 5.2やDeepSeek v4 Proのような一部のオープンウェイトモデルは、トークン生成速度がかなり遅めで、体感遅延に影響する。それでもGLM 5.2を遅いモデルと呼ぶのは難しく、たとえば現時点ではNotion内で最も速いモデルの1つだ
もう1つの可能性は、OpusがMixture of Expertsのような方式を使っていて、一度にメモリに載せるモデル部分がGLMより小さいことだ
GLM 5.2には、意味のある成功を制限する大きな問題が1つあり、それはコーディングサブスクリプションの価値だ
API価格だけを見ればGLM 5.2は競合に勝つ。しかし、コーディング作業でAPI課金を使うのは大企業くらいで、そうした企業では大きく補助されたサブスクリプション型商品が次第に姿を消しつつある
同時に、こうした企業は従業員に中国のAPIを使わせないだろう
個人や小規模チームの立場では、Z.aiのコーディングサブスクリプションはAnthropicやOpenAIに劣る。Claudeと同程度の使用量は得られるかもしれないが、Codexは支払額あたりの使用量が明らかに多い
Z.aiがGPT5.5やOpus 4.8にどれだけ追いついたかは議論できるとしても、全員が同じ価格で自由に選べる世界なら、私はGLMを選ばないだろう
したがって重要な問いは、GLM 5.3や6でZ.aiの商品がどれほど良くなるか、そしてOpenAIとAnthropicが近い将来に現在の商品をどれほど制限するかだ
いつでも奪われることのないAIを中心にインフラを構築することには、こうした企業にとって即時的な価値がある。ヨーロッパ以外の国々は価格にもっと敏感で、中国企業と関係を持つことに同じような恐れを抱いていない
同時に「こうした企業は従業員に中国のAPIを使わせない」というなら、GLMを提供するAmazon Bedrockは誰を狙っているのか気になる
個人はおそらくDeepInfraのような、より安いアメリカのプロバイダーを選ぶだろう。GLMのキャッシュ入力は100万トークンあたり$0.18で、Opusは$0.50だ。Fireworks AIも選択肢だ
20ドルや100ドルのプランで数千ドル分のトークンを使ってコーディングすることに慣れた従業員や学生が、企業支出を後押しするはずだ
競争力のある中国モデルが出てきたからといって、この企業支出が置き換わることはないだろうが、アメリカやEUでホストされるオープンモデルならその可能性はある
GLM 5.2の存在は、OpenAIとAnthropicがAPIアクセスに付けられる価格の上限を作ってくれる
ほとんどの作業はコーディングプランで行われているのではないか、というのが私の推測だ
ただ、プランが使用量制限以外にも制約が強すぎるのは腹立たしい。理解はできるが不便だ。実際に本当に厳しいのはAnthropicと、もしかするとGoogleくらいだ
Anthropicは、利用が利用規約に合っていないと判断した場合、後からAPI料金で請求する可能性があるという方針で不安をあおった。根拠のない心配かもしれないが、実際にそうしそうだという感じがして避けたくなる
ところが、あちらのインフラは明らかに過負荷で、5.2のチャットリクエストは100%タイムアウトした。インフラがモデル性能に追いついたら後でもう一度試して、その時に初めてサブスクリプションに価値があるか判断できそうだ
今日、GLM-5.2が美的感覚やUI作業でGPT-5.5よりはるかに優れていて驚いた
当面はConductor経由のClaude/Codex構成を維持するつもりだが、このモデルのせいでOpenCodeを設定してデスクトップアプリをダウンロードし、今日の作業の大半をそこで行うことになった
「GLM-5.2はコストがかなり低かった。Opusは半分の時間で終わらせ、より洗練されたゲームを出した」のような文を見ると、すぐにLLMっぽい文体を感じる
モデルはみなこういう書き方に収束したようで、性能が良くなってもこの部分はあまり変わらないようだ
テクニカルライティング業界は現在、大きな打撃を受けている。企業はより短い時間でより多くの作業を求める一方で品質は大きく低下しており、日常的に文章の文質を磨く時間はますます減っている
私たちは今、この変化の最前線で働いているため最も大きな影響を受けているが、同時に変化をいち早く試せるという点は刺激的である一方、非常にもどかしい