GLM-5.2 ベンチマークとスペック：SWE-bench Pro、Terminal-Bench、そしてその数値が示すもの

Z.ai (Zhipu AI) のGLM-5.2は、複数のベンチマーク結果とともに公開されました。特に注目すべきは、SWE-bench Proで62.1を記録し、Z.aiが報告するGPT-5.5の58.6をわずかに上回った点です。ただし、実装者にとってより重要なのは、Terminal-Bench 2.1がGLM-5.1の62.0からGLM-5.2の81.0へ大きく伸びたことです。この記事では、各スコアが何を測っているのか、開発ワークフローでどう解釈すべきか、そして自分の環境でどう検証するかを整理します。

今すぐApidogを試す

ここに記載する発表時点の数値は、特に明記しない限りZ.aiが公開した結果です。ベンダー発表のスコアは、そのまま採用するのではなく、ベンチマークが何を証明し、何を証明しないのかを分けて読む必要があります。

💡 モデル評価と同時にAPIを構築・検証する場合、Apidogはエンドポイントの設計、デバッグ、モック、ドキュメント化に使えるオールインワンプラットフォームです。GLM-5.2の改善は、エージェント機能やツール利用の領域で目立っており、これは実質的にAPI設計・API検証の問題でもあります。

要約：GLM-5.2のベンチマークスコア概要

まずは全体像です。以下の比較列は、独立した再実行結果ではなく、Z.aiが各モデルについて報告した数値として扱ってください。

ベンチマーク	測定内容	GLM-5.2	GLM-5.1	GPT-5.5	Claude Opus 4.8
SWE-bench Pro	現実世界のレポジトリに対するバグ修正	62.1	58.4	58.6	n/a
Terminal-Bench 2.1	多段階のシェル / エージェントタスク	81.0	62.0	n/a	n/a
MCP-Atlas	MCPサーバー上でのツール利用	77.0	n/a	75.3	77.8
Humanity’s Last Exam（ツール付き）	高度な専門的推論	54.7	n/a	52.2	n/a
AIME 2026	競技数学	99.2	n/a	n/a	n/a
GPQA-Diamond	大学院レベルの科学	91.2	n/a	n/a	n/a

Z.aiはまた、GLM-5.2がFrontierSWE、PostTrainBench、SWE-Marathonにおいて、最も高得点を記録したオープンソースモデルであると報告しています。この「オープンソース」という条件は重要なので、後半で分解します。

モデルそのものの概要を先に押さえたい場合は、GLM-5.2の概要を参照してください。プロプライエタリモデルとの比較は、GLM-5.2 vs GPT-5.5, Opus, Geminiで詳しく整理されています。

SWE-bench Pro: 62.1が示すこと

SWE-bench Proは、オリジナルのSWE-benchより難しく、厳選された派生ベンチマークです。モデルには実際のGitHub issueと完全なリポジトリが与えられ、隠されたテストスイートを通過するパッチを作成することが求められます。

つまり、測っているのは次の能力です。

• 見慣れないコードベースを読む
• 関連ファイルを特定する
• 既存の設計を壊さずに修正する
• テストを通過する変更を作る

Z.aiによると、GLM-5.2は62.1、GPT-5.5は58.6、GLM-5.1は58.4です。

この結果は次のように読むのが現実的です。

• GPT-5.5に対する3.5ポイント差は意味があります。ただし、SWE系ベンチマークはプロンプト、リトライ回数、テストハーネスの影響を受けるため、「圧倒的」ではなく「トップレベルで競争力がある」と見るべきです。
• GLM-5.1に対する3.7ポイント差は、世代間改善としてより信頼しやすいシグナルです。同じ研究室が同じ条件で比較しているためです。

実務上、SWE-bench Proは「このモデルに既存コードベースの修正を任せられるか」を見るための公開プロキシとして有用です。ただし、最終判断には自社リポジトリでの再評価が必要です。

Terminal-Bench 2.1: 81.0という大きなジャンプ

GLM-5.2のベンチマークで最も実装者向けに重要なのは、Terminal-Bench 2.1です。

Terminal-Benchは、モデルを実シェル内のエージェントとして評価します。たとえば、次のような能力を測ります。

• 依存関係をインストールする
• コマンドを実行する
• 出力を読み取る
• エラーから復旧する
• 複数ステップの作業を最後まで完了する

GLM-5.1は62.0、GLM-5.2は81.0です。1世代で19ポイントの改善は大きく、「指示を補助するモデル」から「端末操作をある程度任せられるモデル」へ近づいたことを示します。

実際の開発タスクでは、モデルは次のような長い履歴を扱います。

$ npm install
...
error log
$ cat package.json
...
$ npm test
...
failed test output
$ edit source file
...
$ npm test
...

このようなエージェント実行では、長いコンテキストを保持し、途中のエラーや出力を忘れずに次の操作へ反映する必要があります。

Z.aiは、GLM-5.2の「IndexShare」スパースアテンションを説明しています。4つのスパースアテンション層ごとに1つのインデクサーを再利用し、長いコンテキストでのアテンションコストを抑える設計です。Terminal-Benchの伸びは、この長期エージェント実行に対する改善と整合します。

世代間比較を詳しく見る場合は、GLM-5.2 vs GLM-5.1を参照してください。

注意点もあります。Terminal-Benchの数値はZ.aiによる報告値であり、エージェント系ベンチマークはタイムアウト、リトライ回数、システムプロンプトなどの足場に影響されます。スコアの伸びは大きいものの、本番導入前には自分のタスクで検証してください。

MCP-Atlas: 77.0はツール利用能力の目安

MCP-Atlasは、モデルがModel Context Protocolを通じて外部ツールやサーバーを扱えるかを測定します。

実装者向けに言い換えると、次の能力を評価するベンチマークです。

• 適切なツールを選ぶ
• 引数を正しく構造化する
• レスポンスを解釈する
• エラーを処理する
• 次のツール呼び出しに反映する

Z.aiによると、GLM-5.2は77.0、GPT-5.5は75.3、Claude Opus 4.8は77.8です。

この差は小さいため、勝者を強く主張するよりも、GLM-5.2がトップクラスのツール利用グループに入ったと読むのが妥当です。

MCPやエージェントのツール呼び出しは、実質的にはAPI呼び出しです。つまり、通常のAPI統合と同じように、次の点を検証する必要があります。

{
  "tool": "createIssue",
  "arguments": {
    "title": "Fix login redirect",
    "priority": "high"
  }
}

確認すべきポイントは以下です。

• JSON schemaに合っているか
• 必須フィールドが欠けていないか
• enum値が正しいか
• 認証や権限エラーを扱えるか
• 失敗時に再試行や代替手段を取れるか

ここでApidogが役立ちます。本番APIに接続する前に、エージェントがアクセスするエンドポイントを定義し、モックし、モデルが生成するリクエストとレスポンスをデバッグできます。Apidogをダウンロードして、通常のAPIと同じ手順でツール呼び出しを検証できます。

推論と数学: HLE 54.7, AIME 99.2, GPQA-Diamond 91.2

GLM-5.2はコーディング専用モデルではなく、推論系ベンチマークでも高いスコアを示しています。

Humanity’s Last Exam（ツール付き）: 54.7

HLEは、多分野にわたる専門家レベルの質問を含む高難度ベンチマークです。「ツール付き」設定では、モデルは検索や計算を使えます。

Z.aiによると、GLM-5.2は54.7、GPT-5.5は52.2です。差は大きくありませんが、この難度のベンチマークで50点台を出すこと自体が強い結果です。

AIME 2026: 99.2

AIMEは競技数学のベンチマークです。99.2はほぼ天井スコアに近く、このテストだけでは最先端モデル同士を細かく区別しにくい可能性があります。

実務上は「数学で明確な弱点は見えない」というシグナルとして読むのがよいでしょう。

GPQA-Diamond: 91.2

GPQA-Diamondは、大学院レベルの科学Q&Aの中でも難しい部分を扱います。91.2は、GLM-5.2が技術的推論でも最先端に近い位置にあることを示します。

GLM-5.2にはHighとMaxの思考負荷レベルがあり、コーディングにはMaxが推奨されています。より難しいタスクでは、レイテンシーと推論深度のトレードオフを意識して設定する必要があります。

競合モデルとの推論比較は、GLM-5.2ベンチマーク vs 競合モデルで詳しく解説されています。

「最高峰のオープンソース」という主張の読み方

Z.aiは、GLM-5.2がFrontierSWE、PostTrainBench、SWE-Marathonにおいて、オープンソースモデルとしてトップであると報告しています。

ここで重要なのは、「全モデル中トップ」と「オープンソースモデル中トップ」は別の主張だということです。

GLM-5.2は、MITライセンスのオープンウェイトモデルとして提供され、地域制限なしで利用できるとされています。これは、クローズドAPIとして利用するモデルとは異なる導入判断になります。

実務では、次のような条件がある場合に特に重要です。

• セルフホストしたい
• データを外部APIへ送れない
• モデルの実行環境を制御したい
• ライセンス条件を明確にしたい
• 長期的な推論コストを抑えたい

一方で、すべてのプロプライエタリモデルを常に上回るという意味ではありません。SWE-bench ProやHLEのようにGPT-5.5を上回ると報告されている項目もありますが、MCP-Atlasのように僅差で並ぶ項目もあります。

より正確には、GLM-5.2は「全体として最先端クラスに近く、かつダウンロードして実行できるオープンウェイトモデルとして特に強い」と読むべきです。

VentureBeatは、GLM-5.2について「長期的なコーディングでGPT-5.5を約6分の1のコストで上回る」と報じています。これはVentureBeatによる特徴付けであり、独立した測定事実としてではなく、出典付きの見方として扱うのが適切です。

GLM-5.2のスペック概要

ベンチマークを読むときは、モデルの実行条件も確認する必要があります。特にセルフホストやAPIコストを検討する場合、スペックは導入判断に直結します。

スペック	値
パラメータ数	合計約753B、Mixture of Experts（MoE）
精度	BF16
アテンション	IndexShareスパースアテンション（4つのスパース層ごとに1つのインデクサーを共有）
コンテキストウィンドウ	1Mトークン（1,048,576）
最大出力	z.aiのドキュメントによると最大128K（ライブで確認。OpenRouterは数値未掲載）
モダリティ	テキスト入力、テキスト出力（視覚バリアントは未確認）
思考負荷	HighおよびMax。無効化も可能
ライセンス	MIT、オープンウェイト、地域制限なし
モデルID	HF zai-org/GLM-5.2, API glm-5.2, Ollama glm-5.2, OpenRouter z-ai/glm-5.2

注意点は以下です。

• 約753BパラメータはMoEの合計サイズです。トークンごとに753B相当の密な計算を行うという意味ではありません。
• 1Mトークンのコンテキストは、長いエージェント実行や大規模コードベースの解析に有利です。
• 最大出力128KはZ.aiドキュメント上の値として扱い、利用プロバイダーごとの制限を必ず確認してください。
• GLM-5.2の視覚モデルは確認されていません。「GLM-5.2V」のような表記を見ても、Z.aiが確認したものとは限りません。

価格面では、OpenRouterで入力1Mトークンあたり1.40ドル、出力1Mトークンあたり4.40ドル、キャッシュ入力は1Mあたり約0.26ドルとされています（VentureBeatの数値）。このコスト構造が「約6分の1のコスト」という主張の背景です。

詳細なコスト比較は、GLM-5.2の価格設定を参照してください。トークン課金なしで試したい場合は、GLM-5.2を無料で利用する方法でセルフホストの流れが解説されています。

自分の環境でベンチマークを検証する方法

ベンダー発表のスコアは出発点です。導入判断には、自分のワークロードで評価する必要があります。

1. 一次情報源を確認する

まず公式情報を確認します。

• Z.ai GLM-5.2ブログ
• Z.aiドキュメント
• Hugging Faceのモデルカード

アーキテクチャ、モデルID、制限、ライセンス条件はここで確認してください。

2. サードパーティの実行経路を確認する

次に、実際の利用経路を確認します。

• OpenRouterページ
• Ollamaライブラリのエントリ
• VentureBeatの報道

APIで使うのか、ローカルで動かすのか、セルフホストするのかによって、検証方法は変わります。

3. 自分のワークロードで評価する

最も信頼できるベンチマークは、自分のタスクです。たとえば、以下のような評価セットを作ります。

- 既存リポジトリのバグ修正
- 失敗しているテストの修正
- API仕様に沿ったクライアント実装
- DBマイグレーションを含む変更
- 外部ツール呼び出しを含むエージェントタスク

評価時は、成功 / 失敗だけでなく、失敗の種類も記録します。

- 正しいファイルを見つけられなかった
- テストを実行しなかった
- JSON schemaに違反した
- 存在しないAPIフィールドを使った
- エラー時にリトライできなかった
- 不要な大規模変更を加えた

以前の世代との比較には、GLM-5.1の解説と、GLM-5 vs DeepSeek vs GPT-5の速度とコストも参考になります。

4. ツール呼び出しをモックして検証する

エージェント評価では、モデルがAPIやツールをどう呼ぶかを確認する必要があります。本番サービスに直接接続する前に、モック環境で検証すると安全です。

例として、エージェントが次のAPIを呼ぶとします。

POST /issues
Content-Type: application/json
Authorization: Bearer <token>

期待するリクエストボディは次のような形式です。

{
  "title": "Fix login redirect bug",
  "description": "Users are redirected to /login after successful authentication.",
  "priority": "high",
  "labels": ["bug", "auth"]
}

検証すべき項目は以下です。

• title が空でないか
• priority が許可された値か
• labels が配列になっているか
• 認証ヘッダーがあるか
• 4xx / 5xx時の処理があるか

Apidogでエンドポイントをモックすれば、ライブサービスに負荷をかけずに、モデルが実際に送信するリクエストと受け取るレスポンスを観察できます。これは、ベンチマーク上で強いモデルが自分のスタックでも機能するかを確認する最短ルートです。

まとめ

GLM-5.2のベンチマークは、発表時のスコアカードとしては注目に値します。

特に重要なのは次の点です。

• Terminal-Bench 2.1が62.0から81.0へ大きく改善
• SWE-bench ProでGPT-5.5を小幅に上回ると報告
• MCP-Atlasではトップクラスのモデルとほぼ横並び
• MITライセンスのオープンウェイトモデルとして提供
• 1Mトークンのコンテキストを持つ
• コスト面でも有利と報じられている

ただし、ベンチマークは導入候補を絞るための材料です。最終判断は、自分のリポジトリ、自分のAPI、自分のエージェントタスクで評価して行うべきです。

APIやツール呼び出しを含む評価を行う場合は、Apidogでエンドポイントを定義・モックし、モデルが何を送信し、何を受け取っているかを確認してください。スコアではなく、自分のスタック上での挙動を基準に判断することが重要です。