ハクソク

世界を動かす技術を、日本語で。

GLM 5.2とOpus

2026年6月22日原文(techstackups.com)

概要

  • GLM-5.2 はオープンモデルとして登場し、 Claude Opus 4.8 と比較される存在
  • Opus は速度・品質で優れ、自己検証も可能だが、 GLM-5.2 は価格面で大きな利点
  • GLM-5.2 はMITライセンスのオープンウェイトで、自由に利用・改変・配布が可能
  • 3Dプラットフォーマー制作 で両モデルを同条件でテストし、それぞれの強みと弱みを検証
  • Opus はマルチモーダル対応、 GLM-5.2 はテキスト専用だが、コストパフォーマンスが高い

GLM-5.2 vs Claude Opus 4.8：3Dプラットフォーマー制作対決

  • GLM-5.2 はZ.aiがリリースした最新フラッグシップモデル、MITライセンスの オープンウェイト
  • Claude Opus 4.8 はAnthropicのクローズドモデルで、 マルチモーダル対応 （画像認識が可能）

テスト内容

  • 両モデルに「 WebGLのみで3Dプラットフォーマーをゼロから構築」という同一プロンプトを与えて比較
  • ゲームエンジンや3Dライブラリ（Three.js等）未使用、3DモデルはKenneyのCC0アセットを使用

ビルド結果比較

  • Opus
    • ビルド時間 ：33分30秒
    • 出力トークン数 ：216,809
    • コスト ：推定約$21.92
    • 完成度 ：アニメーション・テクスチャ・判定処理など全体的に高品質
    • 自己検証 ：スクリーンショットを直接解析し、デバッグ表示も自動で削除
  • GLM-5.2
    • ビルド時間 ：1時間10分40秒
    • 出力トークン数 ：131,000
    • コスト ：$5.39（実費）
    • 完成度 ：キャラのテクスチャ抜け、判定処理漏れ、勝利条件未実装など基本的なバグ多数
    • 自己検証 ：画像が読めないため、ピクセル値を数値で判定する回避策

ゲームプレイ評価

  • 両モデルとも WASD/矢印キー移動、スペースでジャンプ、シフトでダッシュ、マウスでカメラ操作など共通仕様
  • Opus は判定・勝利条件・アニメーションなどが正しく機能し、見た目も良好
  • GLM-5.2 はキャラの向きやテクスチャ、判定処理など根本的なバグが目立つが、スプリングジャンプなど一部機能は実装

バグ・問題点

  • GLM-5.2
    • キャラの向きが逆
    • テクスチャ未適用、頭部消失
    • スパイク判定が機能せず、勝利条件も未実装
  • Opus
    • 空中に立てる（コヨーテタイムの調整過剰）
    • フラグ到達前に勝利判定が発生

コスト・パフォーマンス

  • GLM-5.2 は Opusの約1/4のコスト で動作し、ハードウェアがあれば 無料運用も可能
  • Opus は 高品質・高速 だが、 費用が高い 点がネック

マルチモーダルの優位性

  • Opus は画像認識で自己検証ができるため、 ビジュアルタスクで優位
  • GLM-5.2 はテキストのみのため、 視覚的なバグ検出が困難

GLM-5.2の特徴と利用方法

  • GLM-5.2 は 1Mトークンのコンテキストウィンドウ を持ち、長時間・多段階のタスクに強み
  • 高（High）と最大（Max） の2つの推論モードを搭載し、用途に応じて速度と精度を調整可能
  • API経由の利用 や ローカル実行 が可能で、 vLLM・SGLang・Transformers などのフレームワーク対応
  • MITライセンス で Hugging Face・ModelScope からウェイトをダウンロード可能、地域制限なし

価格比較（1Mトークンあたり）

  • Claude Opus 4.8 ：$25（出力）、$5（入力）、$0.50（キャッシュリード）
  • GLM-5.2 ：$4.4（出力）、$1.4（入力）、$0.26（キャッシュリード）

ベンチマーク結果

  • GLM-5.2 は Opus 4.8 や GPT-4/5 等クローズドモデルと比較しても 上位水準
  • 推論・コーディング・知識系タスク で高得点を記録
  • 一部ベンチマークではOpusやGPT-4/5に劣るが、価格面で圧倒的優位

オープンモデルのメリット

  • オープンウェイト はダウンロード後の 自由利用・改変・配布 が可能
  • クローズドモデル は突然のサービス終了や制限リスク（例：Fableの事例）
  • GLM-5.2 は 永久に手元で運用可能 な安心感

総評・活用指針

  • Opus は 高品質・高速・多機能 だが、 コスト高・クローズド
  • GLM-5.2 は 低コスト・オープン・長期運用向き、用途によっては 十分実用的
  • ビジュアルタスクや厳密な品質管理が必要な場合はOpus推奨
  • コスト重視・長期利用・カスタマイズ性重視ならGLM-5.2が有力な選択肢

参考リンク

Hackerたちの意見

だから、Claude Opus 4.8と直接比較してみたんだ。同じワンショットプロンプトで、ゼロからWebGLで3Dプラットフォーマーを作るってやつ。ワンショットプロンプトを一回実行するだけじゃベンチマークにならないし、実際の使用状況を反映してるわけでもないよね。ほとんどのエージェントの使い方は協力的だから、信頼性（タスクを委任したときに、テスト結果を作り上げずにちゃんと完了するかどうか）や、指示に従うかどうか（自分の指示を守るのか、それとも自分が最適だと思うことをするのか）をテストする必要があるんだ。

└

そうそう、だから私たちは正式なベンチマークの混合、サイドバイサイドの長めの分析、そして信頼できる他の人たちの意見を見てるんだ。記事に全部載ってるよ。正式なベンチマークを意図してるわけじゃないし、そういうのは十分あるからね。

└

こんにちは、私は著者です！完全に同意します！これはベンチマークじゃなくて、雰囲気テストをするつもりだったんです。実際のベンチマークはリストアップしてあります。私のテストは、モデルが長時間かかる技術的に難しいワンショットタスクを与えられたときに何ができるかを示しています。あなたが言ってるテスト（協力的、タスクの委任、タスクの完了、TTD、指示に従うかどうか）は、将来のテストにとって素晴らしいフォーマットだと思うので、ぜひ試してみます。

└

一方で、私は明確に定義された長時間のタスクでGPT 5.5を一晩中動かしていたんだ。今10時間くらい動いてて、ほぼ終わったところ。だから、こういう使い方も有効だと思う。考えてみると、私がやってるエージェントの仕事の大半は、メインセッションから立ち上げられるサブエージェントで、選んだプロンプトを使ってる。これらは完全自律タスクの短縮版と考えられるかも。

└

完全に同意だね。単発のプロンプトじゃ何も証明できないよ。

GLM 5.2をいくつかのプロジェクトでチェックしてみたんだけど、いくつかの感想を。 - コードを動かすのに時間がかかる、決して最速のモデルではない - 発見や計画の段階で迷うことが多いけど、その後は修正する - 指示に従うのが苦手で、後で従わないことを妄想することがある - 出力はかなり良い 一例として、Swift+Zigのコードベースでレンダリングを最適化してたんだけど、5,000件のデータエントリーで詰まった。GLM 5.2はベンチマークを作成してデータを出すのに20分かかったから、イライラして非編集ツールへのアクセスをブロックしてAFKになった。約30分後、すでに作成されたベンチマークといくつかの「結論」を使って3つのボトルネックを最適化したことが分かった。出力は疑念を検証できず、もっとデータを求めてきた。実装はうまくいったし、自然で非侵襲的だった。GPT 5.5が同じリポジトリに与えた影響よりも、むしろ自然だったと言える。もっと使いたいけど、GPTは通常同じリクエストを5倍早く完了するからな。GLM 5.2はJJワークスペース内で隔離されたコンテナを準備して実行するきっかけになった（複数を並行して実行できるように）。

└

これ、私の経験と一致してる。Piで使ってるけど、賢いし出力も良いけど、そこに達するのが効率的じゃないんだよね。

└

それに価格もね。試してみたかったけど、価格がOpusより30%安いだけじゃ、こういう問題があると手を出せないな。

└

それに、全ての推論の過程が見えるのもいいよね。脱線してるのが見えたり、伝え忘れたことに気づいたりして、止めて修正できる。あるいは、なぜその選択をしたのかを理解できて、後で疑問に思う必要がなくなるんだ。

└

先日、あまり重要じゃないことに使ったんだけど、他のモデルが全然解決できなくて、Opus 4.8を無駄にしたくなかったんだ。（macOSのメニューバーで左クリックをオーバーライドして、Ctrl+クリックや右クリックで左クリックと同じようにメニューを出すっていう条件付きのやつ。）トラブルシューティングの途中でモデルをGLM-5.2に切り替えたんだけど、再プロンプトもせずにそのまま理由付けの途中で変更したんだ。数分待ったら、問題解決。これはOpenCode Goのサブスクリプションベースの割り当てで、こういう問題が起きると、今の5時間や今週のOpusを完全に無駄にしちゃうところだった。

正直、ワンショットプロンプトについてのこの大騒ぎが理解できない。定義上、単一のプロンプトではソフトウェアプロジェクトの複雑さを構成しないからね。つまり、得られるのはモデルがトレーニングコーパスの既存コードに基づいて作った一連の仮定だけ。私は、計画ファイルのステップを忠実に守りながら、ガードレールに従い、人間がレビューした仕様の適切なコーディング規約に従うコーディングエージェントを見たい。人間が定義した目標に対してエージェントループでのパフォーマンスを見たいし、定義されたガードレールを守りながら、目標が完了するまでドリフトせずに続けることが確認できるようにしたい。バグを特定したり、既存のコードを見つけて、作成しようとしている特定のユースケースに基づいてリファクタリングを提案することで、パフォーマンス向上を見つけることもしてほしい。これらは「Xを作れ」よりもずっと価値のある指標だと思う。

└

確かに、今は誰も真剣なことを一発でやろうとはしてないけど、それでも重要な指標だよね。Claude CodeとOpusは、ユーザーの入力なしで多くのミスを自己修正できるように改善されたときに、本当に伸びたと思う。実際、数時間の長期的な自律性と自己修正機能が、今後数年で最も改善されるところになると思う。

Hacker Newsで議論の続きを見る