智谱AIのGLM-5.1、600回以上の反復で性能が落ちないLong-Horizonエージェントモデル
目次
中国の智谱AI（Zhipu AI）が4月7日、フラグシップモデルGLM-5.1を公式ブログで発表した。Hacker Newsでは497ポイント・201コメントと相当な注目を集めている。
GLM-5.1の売りは「Long-Horizon Task」対応。要するに、数時間・数百回の反復を経ても性能が劣化せず、自律的にタスクを進め続けるエージェント能力だ。従来のLLMは長時間の作業で出力品質が落ちたりループに陥ったりする傾向があったが、GLM-5.1はそこを正面から攻めている。
モデルのスペック
GLM-5.1は前世代のGLM-5をポストトレーニングで強化したもので、基盤アーキテクチャはMixture-of-Experts（MoE）を採用している。
| 項目 | GLM-5.1 |
|---|---|
| 総パラメータ | 744B |
| アクティブパラメータ/トークン | 40B |
| コンテキストウィンドウ | 200Kトークン |
| 最大出力長 | 131,072トークン（推論タスク時） |
| 事前学習データ | 28.5Tトークン |
| ライセンス | MIT |
| 推論フレームワーク | vLLM、SGLang、KTransformers、Transformers |
前世代のGLM-5は744B/40Bで同一だが、GLM-4.5からの進化は大きい。GLM-4.5は355B総パラメータ（32Bアクティブ）・事前学習23Tトークンだったので、パラメータ規模は約2倍、学習データは24%増。アーキテクチャにはDeepSeek Sparse Attention（DSA）を組み込んで、長コンテキスト処理のコストを下げている。
MoEはGoogle Gemma 4やLLM-jp-4でも採用されている構造で、全パラメータのうち一部だけを各トークンの処理に使う。744Bのうち40Bしかアクティブにならないから、同規模のDenseモデルと比べて推論コストが劇的に低い。
ベンチマーク結果
GLM-5.1はSWE-Bench Proで58.4%を記録し、GPT-5.4（57.7%）やClaude Opus 4.6（57.3%）を抑えてSOTAを達成した。ただしベンチマーク全体を見ると、得意・不得意がはっきり分かれる。
ソフトウェアエンジニアリング
| ベンチマーク | GLM-5.1 | GPT-5.4 | Claude Opus 4.6 | Gemini 3.1 Pro |
|---|---|---|---|---|
| SWE-Bench Pro | 58.4 | 57.7 | 57.3 | 54.2 |
| NL2Repo | 42.7 | 41.3 | 49.8 | 33.4 |
| Terminal-Bench 2.0 | 69.0 | 75.1 | 65.4 | 68.5 |
| CyberGym | 68.7 | — | 66.6 | — |
SWE-Bench ProとCyberGym（セキュリティ関連のタスク）ではトップ。一方でNL2Repo（自然言語からリポジトリ全体を生成するタスク）ではClaude Opus 4.6の49.8%に7ポイント差をつけられている。Terminal-Bench 2.0もGPT-5.4の75.1%には届かない。
推論
| ベンチマーク | GLM-5.1 | GPT-5.4 | Claude Opus 4.6 | Gemini 3.1 Pro |
|---|---|---|---|---|
| HLE（ツール使用） | 52.3 | 52.1 | 53.1 | 51.4 |
| AIME 2026 | 95.3 | 98.7 | 95.6 | 98.2 |
| GPQA-Diamond | 86.2 | 92.0 | 91.3 | 94.3 |
推論ベンチマークでは全般的にGPT-5.4やGemini 3.1 Proに劣る。AIME 2026（数学コンペ）で95.3%、GPQA-Diamond（専門知識）で86.2%と、いずれもトップとは5〜8ポイントの差がある。智谱AI自身もGLM-5.1を「推論ファーストのモデルではない」と位置づけており、汎用的な推論よりもエージェントタスクの持続力に注力したことが数字に表れている。
エージェント系
| ベンチマーク | GLM-5.1 | GPT-5.4 | Claude Opus 4.6 | Gemini 3.1 Pro |
|---|---|---|---|---|
| BrowseComp（コンテキスト付き） | 79.3 | 82.7 | 84.0 | 85.9 |
| MCP-Atlas（Public） | 71.8 | 67.2 | 73.8 | 69.2 |
| Tool-Decathlon | 40.7 | 54.6 | 47.2 | 48.8 |
MCP-AtlasではClaude Opus 4.6に迫る71.8%でトップだが、Tool-Decathlon（複数ツールの組み合わせ）では54.6%のGPT-5.4に大差をつけられている。BrowseCompでもGemini 3.1 Proの85.9%に対して79.3%。
Long-Horizonの実力
ベンチマークの数字だけ見ると「コーディング系の一部でSOTA、あとは横並びかやや劣る」で終わってしまう。だがGLM-5.1の本質はそこではない。
VectorDBBench
SIFT-1Mというベクトル検索ベンチマーク（95%リコール閾値）で、GLM-5.1に600回以上のイテレーションを与えた結果、6,000回超のツール呼び出しを経て21,500 QPSに到達した。Claude Opus 4.6の単一セッション最良が3,547 QPSだから、約6倍。
最適化の軌跡は階段状のパターンを示した。イテレーション約90回目、約240回目、そしてそれ以降で計6回の構造的な転換が起きている。つまりGLM-5.1は自分のベンチマークログを分析し、「このアプローチは限界だから別の構造に変えよう」という判断を自律的に行った。
graph TD
A[開始: 基本実装] --> B[~90回目<br/>第1転換点]
B --> C[~240回目<br/>第2転換点]
C --> D[第3-6転換点<br/>構造的再設計]
D --> E[600+回<br/>21,500 QPS達成]
F[Claude Opus 4.6<br/>単一セッション<br/>3,547 QPS] -.->|約6倍の差| E
style E fill:#2d5,stroke:#333,color:#000
style F fill:#aaa,stroke:#333,color:#000GPU最適化
CUDAカーネルのベンチマークでは、PyTorchのリファレンス実装に対して1,000回以上のイテレーションで3.6倍のスピードアップを達成した。ただしこのタスクではClaude Opus 4.6が4.2倍で上回っており、GLM-5.1が全面的に勝っているわけではない。一方GLM-5はもっと早い段階でプラトー（性能が頭打ち）に達しており、GLM-5.1の持続力が前世代から確実に向上したことは見て取れる。
利用方法
API
bigmodel.cnでAPIアクセスが可能。料金はクオータベースで、ピーク時間帯（UTC+8 14:00-18:00）は3倍消費。2026年4月中はプロモーションレートが適用される。
Z.AI Coding Plan
月額$10からのサブスクリプションで、Claude CodeやCline、Kilo Code、Roo Code、OpenCodeなどのコーディングツールと統合可能。モデル名の設定変更だけで切り替えられる。Cursor 3のようなAIコーディングエディタの普及に伴い、バックエンドのモデルとして差し込める設計になっている。
オープンソース
HuggingFaceのzai-org/GLM-5で重みが公開されており、MITライセンスなので商用利用・ファインチューニング・再配布がすべて可能。FP8量子化版（GLM-5.1-FP8）も用意されている。vLLMでのデプロイ例は以下のとおり。
vllm serve zai-org/GLM-5 \
--tensor-parallel-size 8 \
--gpu-memory-utilization 0.85 \
--speculative-config.method mtp \
--speculative-config.num_speculative_tokens 3 \
--tool-call-parser glm47 \
--reasoning-parser glm45 \
--enable-auto-tool-choice \
--served-model-name glm-58GPUでのテンソル並列が前提なので、個人のローカル環境で動かすには相当な設備が必要。744Bパラメータというのはオープンウェイトの中でも最大級で、FP8でも最低370GB以上のVRAMが要る。AMD LemonadeのようなローカルAIサーバーソリューションとは明らかにレイヤーが違う。
智谱AIの立ち位置
智谱AI（Zhipu AI）は清華大学のTHUDMグループから派生した企業で、中国のLLM開発では百度（Baidu）、アリババ（Qwen系）、DeepSeekと並ぶ主要プレイヤーの一つ。GLMシリーズは2021年から開発が続いており、GLM-OCRのような特化モデルも展開している。
中国系LLMの中での差別化は明確で、DeepSeekが推論効率を、Qwenがマルチモーダルの幅広さを追求するのに対し、智谱AIはエージェント能力の持続力という独自の軸を打ち出した。「8時間・6,000回のツール呼び出し」という数字は、現時点で他に並ぶものがない。
ただし、この持続力が実際のプロダクション環境でどこまで再現できるかは未知数だ。VectorDBBenchやGPUカーネル最適化といったベンチマークは、目標が明確で進捗が数値で測れるタスクに最適化されている。実際のソフトウェア開発のように、要件が曖昧だったり途中で変わったりする状況で同じ持続力が発揮されるかは、これからユーザーが検証する領域になる。
コンダクター型の使い方が本命かもしれない
GLM-5.1のベンチマークを見ると、単発の推論やコード生成ではClaude Opus 4.6やGPT-5.4に劣る場面が多い。
一方で600回以上のイテレーションを回しても劣化しないという持続力は他のモデルにない強みだ。
この非対称な特性を活かすなら、GLM-5.1自身にすべてを解かせるのではなく、「タスクを細分化して他のモデルに投げ、結果をレビューして次の指示を出す」コンダクター（指揮者）的な役割に据えるのが合理的に見える。
たとえばソフトウェア開発の場面を想定してみる。
大きなリファクタリングを進めるとき、個々のファイル修正はClaude Opus 4.6やClaude Codeのサブエージェントに投げる。
GLM-5.1はプロジェクト全体の状態を把握しつつ、何百回と繰り返されるサブタスクの発行・結果の検証・方針転換の判断を引き受ける。
VectorDBBenchで見せた「アプローチの限界を自律的に判断して構造転換する」能力は、まさにこういうオーケストレーション層で活きる。
graph TD
G[GLM-5.1<br/>コンダクター] -->|タスク分割・指示| C1[Claude Opus 4.6<br/>コード修正]
G -->|タスク分割・指示| C2[GPT-5.4<br/>テスト生成]
G -->|タスク分割・指示| C3[特化モデル<br/>セキュリティレビュー等]
C1 -->|結果| G
C2 -->|結果| G
C3 -->|結果| G
G -->|進捗評価・方針転換| GこのパターンはClaude Codeがサブエージェントを並列で走らせる設計や、
OpenAIのSwarmのようなマルチエージェントフレームワークと構造が似ている。
違いは、コンダクター自体が数時間・数千ステップを劣化なしに走り続けられる点だ。
既存のオーケストレーション層はステートレスなスクリプトか、せいぜいコンテキストウィンドウの範囲でしか状態を持てない。
GLM-5.1なら200Kのコンテキストと長期的な一貫性を組み合わせて、プロジェクト全体の文脈を保持したまま判断を続けられる。
もちろん課題はある。
複数モデルのAPI呼び出しが絡むのでレイテンシとコストが膨れる。
GLM-5.1のAPI自体もピーク時3倍のクオータ消費という価格設定で、長時間ジョブのコスト予測が難しい。
また、コンダクターとして機能するにはサブタスクの結果を正しく評価する能力が必要だが、推論ベンチマークで他のトップモデルに劣るGLM-5.1が、他モデルの出力を的確にレビューできるかは検証が必要だ。
それでも、「持続力は高いが単発の推論力は最強ではない」というプロファイルは、コンダクター役に向いている。
推論の瞬発力が求められるのはサブタスク側で、コンダクターに必要なのは全体を見渡す文脈保持と、いつ方針を変えるかの判断力だ。
GLM-5.1がVectorDBBenchで6回の構造転換を自律的に行ったという事実は、後者の能力を示唆している。
レビューゲートとしての運用
コンダクターの役割をもう少し具体的に掘り下げると、「レビューゲート」としての使い方が浮かび上がる。
たとえば大規模なコードベースのリファクタリングで、数百のファイル修正をClaude CodeやClineのサブエージェントに並列で投げるケースを考える。
個々の修正は各エージェントが高品質にこなせるとして、問題は全体の整合性だ。
あるモジュールの型定義を変えたら、依存する別モジュールのテストも通るか。
APIのインターフェースを変えたら、呼び出し元のエラーハンドリングは追従しているか。
こういった横断的なチェックは、プロジェクト全体の文脈を保持したまま何百回と繰り返す必要がある。
従来のCI/CDパイプラインでも自動テストで一部はカバーできるが、
テストでは拾えない設計意図の一貫性や、暗黙の契約（このモジュールはこういう前提で使われている）の検証はLLMのほうが得意な領域だ。
GLM-5.1の持続力があれば、数時間にわたるリファクタリングセッションの全工程をレビューし続けられる。
Claude Opus 4.6に個別の修正を任せ、GLM-5.1がその出力を逐一検証して差し戻すかパスするかを判断する——という分業は現実的に成立しうる。
ただし、ここで先ほどの推論ベンチマークの弱さが効いてくる。
レビュアーが被レビュアーより推論力で劣るという構図は、人間のコードレビューでも起こりうるが、
LLMの場合は「自信を持って間違える」リスクがある。
GPT-5.4やClaude Opus 4.6が書いた高度な最適化コードを、GLM-5.1が正しく評価できるかは実運用で検証するしかない。
一つの緩和策は、レビューの粒度を「ロジックの正しさ」ではなく「設計方針との整合性」や「インターフェース契約の遵守」に絞ること。
全体を見渡す視点と、細部の推論力が求められる判断とを分離すれば、GLM-5.1の強みが活きる配置になる。