GLM-5.1 は、エージェント型エンジニアリングのために設計された次世代のフラグシップモデルであり、前身のモデルと比較して大幅に強化されたコーディング能力を備えています。SWE-Bench Pro において最先端のパフォーマンスを達成し、NL2Repo（リポジトリ生成）や Terminal-Bench 2.0（実世界のターミナルタスク）では GLM-5 を大きく上回るスコアを記録しました。
しかし、最も意味のある飛躍は初回のパスのパフォーマンスの先にあります。GLM-5 を含む従来のモデルは、初期の段階で手持ちの技術を駆使して短期的な成果を上げると、そこで頭打ちになる傾向がありました。いくら時間をかけても、それ以上の改善は見込めなかったのです。
対照的に GLM-5.1 は、はるかに長い時間軸を要するエージェントタスクにおいても有効性を保つように設計されています。あいまいな問題に対してもより優れた判断力を示し、長時間のセッションを通じて生産性を維持します。複雑な問題を細分化し、実験を実行して結果を読み取り、ボトルネックを正確に特定します。推論を再考し、反復を通じて戦略を修正することで、GLM-5.1 は数百回のイテレーションと数千回のツール呼び出しにわたって最適化を持続させます。実行時間が長ければ長いほど、成果は向上します。
この特性は、構造化されたフィードバックが段階的に少なくなる 3 つのタスクで実証されています。単一の数値指標でスコア付けされるベクトル検索の最適化問題、問題ごとの高速化測定が行われる GPU カーネルベンチマーク、そして指標が一切なく、次に何を改善すべきかはモデル自身の判断に委ねられる、自由度の高い Web アプリケーション構築です。
シナリオ 1:600 回を超えるイテレーションによるベクトルデータベースの最適化
VectorDBBenchは、近似最近傍検索を実行する高性能なデータベースを構築するモデルの能力を評価するオープンソースのコーディング課題です。モデルには HTTP API エンドポイントと空の実装スタブを含む Rust 製のスケルトンが与えられ、ツール呼び出しベースのエージェントを使用してファイルの読み書き、コンパイル、テスト、プロファイリングを 50 ターンというツール呼び出し予算内で行います。最終結果は SIFT-1M データセットでベンチマークされ、Recall（再現率）が 95% 以上という制約の下で QPS によってランク付けされます。この設定におけるこれまでの最高記録は、Claude Opus 4.6 が達成した 3,547 QPS でした。
ここで生じる自然な疑問は、この 50 ターンという予算がボトルネックになっているのではないか、という点です。私たちは評価を Claude Code フレームワークによる外部最適化ループへと再構成しました。各イテレーションにおいて、モデルはコードの編集、コンパイル、テスト、プロファイリングに必要な分だけツールを呼び出すことができ、その後、ベンチマークのために新しいバージョンを提出します。いつ提出し、次に何を試すべきかはモデルが自律的に決定します。
GLM-5.1 は 50 回や 100 回の提出で頭打ちになることなく、6,000 回を超えるツール呼び出しを伴う 600 回以上のイテレーションを通じて有意義な改善を見つけ続け、最終的に 21.5k QPS に到達しました。これは、単一の 50 ターンセッションで達成された最高結果の約 6 倍に相当します。最適化の軌跡は特徴的ない階段状のパターンを示しており、固定された戦略内での漸進的な調整期間と、パフォーマンスのフロンティアをシフトさせる構造的な変化が交互に現れます。
2 つの転換点はこのパターンを如実に表しています。イテレーション 90 回付近で、モデルはコーパス全体のスキャンから f16 ベクトル圧縮を伴う IVF クラスタプロービングへ移行し、6.4k QPS へとジャンプしました。イテレーション 240 回付近では、u8 によるプレスコアリングに続き f16 による再ランク付けを行う 2 段階パイプラインを導入し、13.4k QPS に到達しました。完全な実行期間中にこのような構造的な転換は 6 回発生し、それぞれがモデル自身によるベンチマークログの分析と、その時点でのボトルネックの特定によって開始されました。チャート内の赤い×印は Recall が 95% を下回ったイテレーションを示しており、これらは主要な転換点の周囲に集中しています。これは、モデルが新しい方向性を探るために一時的に制約を破り、その後でそれを回復させるように調整しているためです。
シナリオ 2:1,000 ターンを超える機械学習ワークロードの最適化
KernelBenchは、モデルが参照用の PyTorch 実装を受け取り、同一の出力を生成するより高速な GPU カーネルを作成できるかどうかを評価するベンチマークです。このベンチマークは、最適化の範囲とシステムの複雑さに応じて 3 つのレベルに整理されています。レベル 1 は単一の演算子、レベル 2 は融合された演算子シーケンス、レベル 3 は MobileNet、VGG、MiniGPT、Mamba などの完全なアーキテクチャを対象としたエンドツーエンドの最適化で、合計 50 の問題で構成されています。参考までに、デフォルト設定の torch.compile はこれらの問題で 1.15 倍の高速化を達成し、max-autotune では 1.49 倍です。私たちはレベル 3 に対して 4 つのモデルを実行し、ツール使用ターン数の関数として 50 の問題全体での幾何平均の高速化を報告しました。
この軌跡は、長期にわたる最適化行動の違いを浮き彫りにしています。GLM-5 は初期段階で急速に改善しますが、比較的早期に頭打ちになります。Claude Opus 4.5 はもう少し粘りますが、後半戦ではその伸びも鈍化します。GLM-5.1 はこのフロンティアをさらに押し広げ、3.6 倍の高速化を達成し、実行が進行するにつれても進歩し続けました。改善率は時間とともに低下するものの、GLM-5 と比較してはるかに長い期間にわたり有用な最適化を持続させています。なお、Claude Opus 4.6 はこの設定において最も強力なモデルであり、4.2 倍でフィニッシュし、終了時点でもなお余力を示していました。
シナリオ 3:8 時間にわたる Linux デスクトップの構築
これまでの 2 つのシナリオには、QPS や高速化率といった、モデルがベンチマークできる明確な数値目的関数が存在しました。一方、Web サイトの生成は本質的により主観的です。自然言語のプロンプトが与えられ、動作する Web アプリケーションを生成することが求められます。そこには最適化すべき単一の指標は存在せず、「良い」かどうかは完全性、視覚的な完成度、対話の質に依存します。
私たちは意図的に野心的なプロンプトでこれをテストしました。「Web アプリケーションとして Linux スタイルのデスクトップ環境を構築せよ」というものです。スターターコードもなく、デザインモックアップもなく、中間的なガイダンスもありません。1 回きりの実行では、GLM の初期バージョンを含むほとんどのモデルがすぐに音を上げます。静的なタスクバーといくつかのプレースホルダーウィンドウを含む基本的なスケルトンを生成すると、タスク完了を宣言してしまうのです。モデルには、一歩引いて何が欠けているかを自問するメカニズムが備わっていません。
私たちはこれを変えるシンプルな枠組みで GLM-5.1 をラップしました。各実行ラウンドの後、モデルは自身の出力をレビューし、欠けている機能、荒いスタイリング、壊れた対話など、改善できる点を特定して続行します。このループは 8 時間にわたって実行され、その差は顕著なものでした。
序盤、GLM-5.1 は短いセッションで生成されるのと同様に、タスクバーと単純なウィンドウを備えた基本的なレイアウトを提示します。しかし、そこで止まることはありません。継続するにつれて、システムは着実に充実していきます。ファイルブラウザ、ターミナル、テキストエディタ、システムモニター、計算機、ゲームといった各機能が、後付けではなく一貫した UI として統合されて追加されていきます。スタイリングは洗練され、インタラクションは滑らかになり、エッジケースも処理されるようになります。最終的には、ブラウザ上で動作する完全で視覚的に一貫性のあるデスクトップ環境が出来上がります。これは、モデルに時間をかけ、洗練し続ける能力を与えることで何が可能になるかを示す好例です。
3 つの設定すべてにおいて、重要なのは実行時間そのものではなく、追加された実行時間が有用であり続けるかどうかという点です。GLM-5.1 は、GLM-5 を超えてその生産的な時間軸を有意に延長しました。一方で、KernelBench などのタスクにおける残るギャップは、長期にわたる最適化が依然として開かれたフロンティアであることを示しています。依然として重大な課題は残されています。漸進的な調整が実を結ばなくなった際に、いかに早く局所最適解から脱出するか、数千回に及ぶツール呼び出しにわたる実行トレース全体で一貫性を維持する方法、そしておそらく最も重要なこととして、最適化すべき数値指標が存在しないタスクにおいて信頼できる自己評価を開発することです。GLM-5.1 はこの方向への第一歩であり、私たちはこれらの最前線で押し上げ続けていきます。
GLM-5.1 は MIT ライセンスの下でオープンソースとして公開されています。GLM-5.1 は開発者向けプラットフォームである api.z.ai および BigModel.cn においても利用可能で、Claude Code および OpenClaw との互換性を備えています。
GLM-5.1 の始め方
GLM コーディングプランでの GLM-5.1 の使用
お気に入りのコーディングエージェント（Claude Code、OpenCode、Kilo Code、Roo Code、Cline、Droidなど）でGLM-5.1をお試しください。https://docs.z.ai/devpack/overview
GLM コーディングプランご契約者様へ：すべてのコーディンプランユーザー向けに GLM-5.1 の展開を開始しています。モデル名を"GLM-5.1"に更新するだけで、今すぐ GLM-5.1 を有効にできます（例：Claude Code の~/.claude/settings.json）。当社の最も有能なモデルである GLM-5.1 は、ピーク時には 3 倍、オフピーク時には 2 倍のクォータを消費します。4 月末までの期間限定プロモーションとして、オフピーク時の利用は 1 倍で課金されます（ピーク時間は毎日 14:00～18:00（UTC+8/北京時間）です）。
GUI をご希望の方へ：Z Codeをご用意しています。これは、複数のエージェントが連携して動作する単一のインターフェースです。SSH 経由でリモートマシン上で開発したり、スマホからタスクを開始して後ほど確認したりできます。
今すぐ構築を開始：https://z.ai/subscribe
Z.ai で GLM-5.1 とチャット
GLM-5.1 は、数日以内にZ.aiで利用可能になります。
GLM-5.1 のローカルでの提供
GLM-5.1 のモデル重みはHuggingFaceおよびModelScopeで一般公開されています。ローカル展開用として、GLM-5.1 は vLLM や SGLang を含む推論フレームワークをサポートしています。包括的なデプロイ手順は公式 GitHub リポジトリで入手可能です。
注釈
- Humanity's Last Exam (HLE) およびその他の推論タスク: 最大生成長 163,840 トークン（
temperature=1.0, top_p=0.95, max_new_tokens=163840）で評価を実施。デフォルトではテキストのみのサブセットを報告しており、*印のものはフルセットの結果です。判定モデルには GPT-5.2 (medium) を使用。HLE-with-tools では最大コンテキスト長 202,752 トークンを採用。 - SWE-Bench Pro: カスタマイズした指示プロンプトを使用して OpenHands で SWE-Bench Pro スイートを実行。設定：
temperature=1,top_p=0.95,max_new_tokens=32768、200K コンテキストウィンドウ。 - NL2Repo: 200k コンテキスト下、
temperature=1.0,top_p=1.0,max_new_tokens=32768で評価。ハッキング防止のため、悪意のあるコマンド（例：無許可の pip や curl 操作）に対してルールベースの事前検出を行い、その後にモデルによる判定を実施。悪意のあるアクションは即座に遮断。 - BrowserComp: コンテキスト管理なしでは直近 5 ターンの詳細を保持。コンテキスト管理ありでは、GLM-5 および DeepSeek-v3.2 と同様の全破棄戦略を採用。
- Terminal-Bench 2.0 (Terminus 2): Terminus フレームワークを使用し、
timeout=3h, temperature=1.0, top_p=1.0, max_new_tokens=8192、200K コンテキストウィンドウで評価。リソース制限は CPU 16 コア、RAM 32GB に設定。 - Terminal-Bench 2.0 (Claude Code): Claude Code 2.1.14 (think mode) で評価。
temperature=1.0, top_p=0.95, max_new_tokens=131072。壁時計時間の制限は撤去したが、タスクごとの CPU およびメモリ制約は維持。Claude Code が導入した環境問題を修正し、曖昧な指示を解決した検証済みの Terminal-Bench 2.0 データセット（https://huggingface.co/datasets/zai-org/terminal-bench-2-verifiedを参照）での結果も報告。スコアは 5 回の実行の平均値。 - CyberGym: Claude Code 2.1.56 (think mode、Web ツールなし) で評価。
temperature=1.0, top_p=1.0, max_new_tokens=32000、タスクあたり 250 分のタイムアウト。結果は 1,507 タスクにおける単一実行の Pass@1。 - MCP-Atlas: すべてのモデルを think mode で 500 タスクの公開サブセットで評価。タスクあたり 10 分のタイムアウト。判定モデルには Gemini-3.0-Pro を使用。
- τ³-bench: ユーザーが対話を早期に終了させることによる失敗モードを回避するため、全ドメインのユーザーシミュレーターに追加のプロンプトを導入。銀行ドメインではターミナルベースのエージェント検索検索（terminal_use）を使用。ユーザーシミュレーター：GPT-5.2 (reasoning_effort: low)、4 試行。
- Vending Bench 2: 実行はAndon Labsによって独立して実施。
- KernelBench Level 3: 50 の問題それぞれを、1 つの H100 GPU を搭載し、1200 回のツール使用ターンに制限された分離された Docker コンテナで実行。正解性（
atol=rtol=1e-4）とパフォーマンスは、個別の CUDA コンテキストにおいて PyTorch eager ベースラインに対して評価。すべてのソリューションは、ベンチマークの不正利用がないか、Claude Opus 4.6（最大努力）および GPT-5.4（xhigh）によって独立して監査済み。各監査では、最適化がベンチマーク固有の動作を悪用しておらず、任意の新しい入力でも機能し、デフォルトの CUDA ストリーム上で全ての計算を維持していることを確認。監査時のより低い高速化率を採用し、外れ値の影響を制限するために 50 倍のハードキャップを適用。