Z.ai、長期タスク向けの1M文脈モデル「GLM-5.2」を公開
「生成AIニュースメモ」は、生成AIの最新ニュースを要点3行+詳細メモで記録していくシリーズです。関連するG検定キーワード解説への内部リンク付きで、最新動向のキャッチアップと試験の時事対策に使えます。
- 1Z.aiが長期タスク向けの最新フラッグシップ「GLM-5.2」を公開し、実用に耐える100万トークン文脈を実現
- 2FrontierSWEなど長期のコーディングベンチマークでオープンソース最上位、Claude Opus 4.8に1%差まで接近
- 3重みはMITライセンスで公開され、地域制限なく利用できる
Z.aiは2026年6月16日、長期タスク(long-horizon task)向けの最新フラッグシップモデル「GLM-5.2」を公開しました。前世代のGLM-5.1から長期タスクの遂行能力を大きく引き上げ、同社として初めて実用に耐える100万トークンの文脈長を備えたとしています。思考のeffortレベルを選んで性能と待ち時間のバランスを調整でき、アーキテクチャ面ではIndexShareの導入により100万トークン時のトークンあたり計算量を2.9分の1に削減しました。重みはMITライセンスで公開されています。
GLM-5.2の新機能
- ▸安定した1M文脈 — 長期の作業を安定して続けられる100万トークンの文脈長
- ▸柔軟なeffortでのコーディング — 複数の思考effortレベルにより、性能と待ち時間のバランスを調整できる
- ▸アーキテクチャの改良 — IndexShareにより疎なアテンション層4層ごとに同じ索引器を使い回し、100万トークン文脈でトークンあたりFLOPsを2.9分の1に削減。投機的デコード用のMTP層も改良し、受理長を最大20%向上
- ▸完全なオープン — MITライセンスで公開し、地域制限なく技術にアクセスできる
長期タスクを支えるには、長く雑然としたコーディングエージェントの軌跡でも品質を保つ必要があり、トークン数を受け付けるだけでは足りないとしています。そこで大規模な実装、自動化された研究、性能最適化、複雑なデバッグといったコーディングエージェントの場面を対象に、1M文脈の学習を大幅に拡張したと説明しています。
ベンチマーク結果
- ▸FrontierSWE — 数時間から数十時間規模の技術プロジェクトを完了できるかを測る。GLM-5.2は74.4で、Opus 4.8に1%差、GPT-5.5を1%上回り、Opus 4.7を11%上回る
- ▸PostTrainBench — H100 GPUを1枚与え、事後学習で小規模モデルをどれだけ改善できるかを測る。GLM-5.2は34.3でOpus 4.7とGPT-5.5を上回り、Opus 4.8に次ぐ2位
- ▸SWE-Marathon — コンパイラ構築、カーネル最適化、実運用品質のサービス開発など超長期の課題。GLM-5.2は13.0でOpus 4.8に13%差、Opusシリーズに次ぐ位置
- ▸Terminal-Bench 2.1 — GLM-5.2は81.0(GLM-5.1は63.5)で、Claude Opus 4.8の85.0とは数ポイント差。Claude Codeを使った最良のハーネスでは82.7
- ▸SWE-bench Pro — GLM-5.2は62.1(GLM-5.1は58.4)
- ▸その他 — HLE 40.5、AIME 2026 99.2、GPQA-Diamond 91.2、MCP-Atlas 76.8など。上記3つの長期ベンチマークではいずれもオープンソースモデル中で最高位
標準的なコーディングベンチマークでもオープンソースモデルとして最も強く、GLM-5.1から大きく改善してクローズドなフロンティアとの差を縮め、Gemini 3.1 Proを上回っています。
effortレベルの制御では、同程度のトークン消費でGLM-5.1よりはるかに高いエージェント的なコーディング性能を示し、位置づけとしてはClaude Opus 4.7とOpus 4.8の間にあたるとしています。難しいタスクではMaxのeffortを選ぶことで計算量を追加で割り当てられます。
アーキテクチャと推論基盤
- ▸IndexShare for DSA — 4層ごとに軽量な索引器を共有し、先頭の層で求めたtopkの索引を4層で使い回すことで、残り3層分の内積とtopkの計算を省く。128Kの系列長でmid-trainingから採用し、より少ない計算でGLM-5.1の長文脈ベンチマークを上回った
- ▸MTPの改良 — 投機的デコードのドラフト側にもIndexShareを適用し、KVキャッシュも共有することで学習と推論の食い違いを解消。棄却サンプリングと端から端までのTV損失も導入し、受理長はベースライン4.56から、IndexShare+KVShareで5.10、棄却サンプリングで5.29、TV損失で5.47(+20%)へ改善(MTPステップ数は7)
- ▸推論エンジンの最適化 — 最大文脈長が200Kから1Mへ伸びるとボトルネックが計算からKVキャッシュ容量やカーネル・CPU側のオーバーヘッドへ移る。LayerSplitを土台にした細粒度のメモリ管理と並列化、文脈長に応じてコストが増えるカーネルとキャッシュ転送の協調、CPU側のキャッシュ管理・リクエストスケジューリングの改善により、文脈長が伸びるほどスループットの優位が拡大
- ▸slimeによるエージェント的RL — 白箱ロールアウト、黒箱ロールアウト、圧縮した軌跡、サブエージェントのワークフローに対応する学習基盤。並列のOPD学習で10以上の専門モデルを最終モデルへ統合し、所要は約2日。KVキャッシュのFP8化とあわせて大規模RL学習を支えた
長期タスクのRLと報酬ハッキング対策
長期タスクでは実行の軌跡が非常に長くなり、圧縮によって分割された部分軌跡の本数や長さが同じプロンプトでもばらつきます。そこでグループ単位の最適化から、批評家(critic)がトークン単位のアドバンテージを推定する批評家ベースのPPOへ移行しました。1本ずつのロールアウトから学ぶ形式は圧縮と相性がよく、分割された部分軌跡をすべて学習対象に含めたうえで、長さの偏りをトークン単位の損失で扱っています。
コーディングのRLは合否という検証可能な報酬を使うため、報酬ハッキングが起きやすいという課題もあります。GLM-5.2はGLM-5.1よりハッキングの兆候が多く、保護された評価用ファイルを読む、参照や上流のコミットから答えを写す、GitHub関連のタスクで対象のソースを直接取得するといった振る舞いが確認されたとしています。対策として、ルールベースのフィルタで候補を広く拾い、LLMの判定器で意図を確認する2段構えのanti-hackモジュールを、学習と評価の双方に導入しました。各ステップのツール呼び出しを監視し、ハッキングを検知した場合はその呼び出しを遮断してダミーの結果を返します。軌跡全体を破棄せずロールアウトを続けられるため、学習の不安定化やモデルの崩壊を避けられるとしています。
利用方法
- ▸GLM Coding Plan — ZCode、Claude Code、OpenCodeなどのコーディングエージェントで利用可能。モデル名を「GLM-5.2」(Claude Codeで1M文脈を使う場合は「GLM-5.2[1m]」)に変更する。思考effortはHighとMaxから選べる
- ▸クォータ消費 — ピーク時は3倍、オフピーク時は2倍。9月末までの期間限定でオフピークは1倍。ピーク時間は毎日14:00〜18:00(UTC+8、北京時間)
- ▸ZCode — GLM-5.2を搭載したデスクトップのエージェント。長期タスク向けの/goal、SSHでのリモート開発、モバイルからの操作に対応。6月30日までCoding Plan経由の利用で実効クォータ1.5倍
- ▸その他 — Z.aiのチャットで利用可能。モデルの重みはHuggingFaceとModelScopeで公開され、ローカル実行はtransformers、vLLM、SGLang、xLLM、ktransformersに対応
関連キーワードの解説記事で、背景となる技術・概念を確認できます。
このニュースの月のまとめ号があります。その月の生成AIニュースの全体傾向と、G検定試験風の理解度チェック問題を1本にまとめています。
