この記事ではLLMに特化して解説する。LLM全般の仕組みやローカル実行は LLMとは？仕組みからローカル実行まで徹底解説【2026年完全ガイド】 を参照してほしい。
We're introducing GLM-5.2, our latest flagship model for long-horizon tasks. It marks a substantial leap in long-horizon task capability over its predecessor GLM-5.1 and, for the first time, delivers that capability on a solid 1M-token context.
（GLM-5.2を発表する。長期タスク向けの最新フラッグシップであり、前身のGLM-5.1から長期タスク能力を大きく引き上げ、それを初めて安定した1Mトークンのコンテキストで実現した。）
— Hugging Face モデルカード zai-org/GLM-5.2
Z.ai（智谱AI）がGLM-5.2をいつ・どの形式で公開したか、一次ソースの所在
744B MoE・1Mコンテキスト・IndexShareというアーキテクチャ上の特徴
公称ベンチマークと、Claude・GPT・DeepSeek・Qwenとの公称比較で読める位置
MITライセンスが許す範囲と、商用利用で確認すべき点
744Bモデルをローカルで動かすときに直面するメモリとコストの現実
GLM-5.2は、中国のAI企業Z.ai（旧Zhipu AI／智谱AI）が2026年6月13日に重みを公開したオープンウェイトの大規模言語モデルだ。
Hugging Faceの zai-org/GLM-5.2 で配布され、ライセンスはMIT。
本記事は、Hugging Faceのモデルカードと config.json、公式ブログ、arXivの技術レポートという一次ソースだけを根拠に、GLM-5.2の素性を整理する。
噂段階の数値や、出典の取れない性能主張は扱わない。
数値はすべて「公称（モデルカード掲載）」または「公開（第三者評価）」と明記する。
GLM-5.2 とは：Z.ai（智谱AI）の最新オープンモデル
GLM-5.2を出したのはZ.aiという会社だ。
旧称はZhipu AI（智谱AI）で、清華大学発のスタートアップとして知られる。
Hugging Face上の組織名は zai-org であり、GLM-4.5・GLM-5・GLM-5.1といった系譜のモデルを同じ組織アカウントから公開してきた。
公開日は2026年6月13日。 配布チャネルは3つある。
・Hugging Faceでの重み配布（zai-org/GLM-5.2、Safetensors形式・BF16）
・Z.ai APIプラットフォーム（https://docs.z.ai/guides/llm/glm-5.2）
・チャットUI https://chat.z.ai
モデルカードはGLM-5.2を「our latest flagship model for long-horizon tasks（長期タスク向けの最新フラッグシップ）」と位置づける。 ここで言う long-horizon task とは、数十ステップにわたる自律的なコーディングやエージェント実行のように、長い文脈と多段の判断を要する作業を指す。 GLM-5.2が掲げる4つの新機能を、モデルカードの記述に沿って並べる。
・Solid 1M Context：長期作業を安定して支える1Mトークンのコンテキスト
・Advanced Coding with Flexible Effort：思考量（effort level）を複数段階で切り替え、性能とレイテンシのバランスを取れる強化されたコーディング能力
・Improved Architecture：IndexShareの提案により、1Mコンテキスト時の1トークンあたりFLOPsを2.9倍削減
・Pure Open：MITライセンスによる「地域制限のない」公開
最後の「Pure Open」は、モデルカードが原文で An MIT open-source license — no regional limits, technical access without borders と書いている点だ。
中国発のモデルでは利用地域や用途に制約がつく例もあるなか、GLM-5.2は重み配布とライセンスのうえで地域制限を設けないことを明示している。
ライセンスの解釈は利用者の責任になるため、採用前に必ず最新のLICENSE本文を自分で読むことを勧める。
GLM 系譜の中の位置付け：GLM-5.1 から GLM-5.2 へ
GLM-5.2は突然現れたモデルではなく、GLM系統の連続した更新の一段だ。 Hugging Faceの公開履歴とモデルカードの記述から、近い世代の関係を時系列で示す。
オープンウェイト世代の確立"] --> B["GLM-5
技術レポート
arXiv:2602.15763"] B --> C["GLM-5.1
長期タスク強化
744B / 40B MoE"] C --> D["GLM-5.2
2026-06-13公開
1Mコンテキスト + IndexShare"]
GLM-5.2の技術的な土台は、arXivに公開された技術レポート「GLM-5: from Vibe Coding to Agentic Engineering」（arXiv:2602.15763）にある。 このレポートはGLM-5系統全体の設計思想を扱い、GLM-5.2はその系統上で長期タスクとコンテキスト長を伸ばした版という関係になる。
GLM-5.1との差分を、モデルカードの公称ベンチマークから読み取れる範囲で整理する。 Artificial Analysisによれば、GLM-5.2はGLM-5.1と同じサイズ（744B総・40Bアクティブ）でありながら、Intelligence Index v4.1で11ポイント上回るとされる。 つまり今回の更新は、パラメータ規模の拡大ではなく、アーキテクチャと学習の改良による性能向上という性格を持つ。
| 項目 | GLM-5.1 | GLM-5.2 |
|---|---|---|
| 公開 | GLM-5.2の前世代 | 2026年6月13日 |
| 規模（公称） | 744B総 / 40Bアクティブ MoE | 744B総 / 40Bアクティブ MoE |
| コンテキスト | 前世代 | 1Mトークン（公式に「solid」と表現） |
| SWE-bench Pro（公称） | 58.4 | 62.1 |
| AIME 2026（公称） | 95.3 | 99.2 |
| Terminal Bench 2.1（公称） | 63.5 | 81.0 |
| Artificial Analysis Index | 約40（公開） | 51（公開・オープン首位） |
数値の伸びは長期タスク系（Terminal Bench、SWE-bench Pro）で大きい。 GLM-5.2が「long-horizon tasks向けフラッグシップ」を名乗る根拠は、この差分に表れている。
アーキテクチャと技術特性：744B MoE と IndexShare
GLM-5.2の中身は、Hugging Faceに同梱された config.json で確認できる。
モデルカード本文はパラメータ総数を明記していないが、config.json のMoE構成は公式の一次情報として読める。
主要な設定値を抜き出す。
| 設定（config.json） | 値 | 意味 |
|---|---|---|
| model_type | glm_moe_dsa | MoE + DSA（疎なアテンション）構成 |
| num_hidden_layers | 78 | 78層 |
| first_k_dense_replace | 3 | 最初の3層はdense、以降はMoE |
| n_routed_experts | 256 | ルーテッドエキスパート256個 |
| num_experts_per_tok | 8 | 1トークンあたり8エキスパートを起動 |
| n_shared_experts | 1 | 共有エキスパート1個 |
| hidden_size | 6144 | 隠れ層次元 |
| max_position_embeddings | 1048576 | 1Mトークンのコンテキスト |
| kv_lora_rank / q_lora_rank | 512 / 2048 | MLA系の低ランク圧縮アテンション |
| num_nextn_predict_layers | 1 | MTP（投機的デコード用）層 |
公称の総パラメータは744B、1トークンの推論で実際に動くのは約40Bだ（256のルーテッドエキスパートのうち8と、共有1を起動する）。 この比率がMoEの要点になる。 保持すべき重みは744B分だが、1トークンの計算コストは40B級にとどまる。 表現力の上限を大きく取りつつ、推論時の演算量を抑える設計だ。
アーキテクチャ上の新しさはIndexShareにある。
モデルカードによれば、IndexShareは「同じindexerを4つの疎アテンション層ごとに再利用する（reuses the same indexer across every four sparse attention layers）」仕組みで、1Mコンテキスト時の1トークンあたりFLOPsを2.9倍削減する。
config.json の index_topk_freq: 4、index_topk: 2048、indexer_types に並ぶ full と shared のパターンが、この4層周期の共有構造に対応している。
詳細はIndexShareの論文（arXiv:2603.12201）が扱う。
もう一つ、MTP層（Multi-Token Prediction）の改良で投機的デコードの受理長を最大20%伸ばしたとされる。 投機的デコードは、小さなドラフトで先読みした複数トークンを本体が一括検証する高速化手法で、受理長が伸びるほど生成が速くなる。
最大1Mコンテキスト"] --> DENSE["先頭3層: dense"] DENSE --> SPARSE["残り75層: MoE層
256エキスパート中8起動 + 共有1"] SPARSE --> ATT["DSA 疎アテンション
IndexShare: indexerを4層ごとに共有"] ATT --> MTP["MTP層で投機的デコード
受理長 最大+20%"] MTP --> OUT["出力
最大131,072トークン"]
公称ベンチマーク：モデルカード掲載値
ここからの数値は、すべてHugging Faceモデルカードに掲載された公称値だ。 開発元による測定であり、ハーネスや評価条件は項目ごとに異なる。 読者の用途での再現確認を前提に読んでほしい。
| ベンチマーク | 分類 | GLM-5.2（公称） | GLM-5.1（公称） |
|---|---|---|---|
| HLE | 推論 | 40.5 | 31 |
| HLE (w/ Tools) | 推論 | 54.7 | 52.3 |
| AIME 2026 | 数学 | 99.2 | 95.3 |
| HMMT Feb. 2026 | 数学 | 92.5 | 82.6 |
| GPQA-Diamond | 知識 | 91.2 | 86.2 |
| SWE-bench Pro | コーディング | 62.1 | 58.4 |
| NL2Repo | コーディング | 48.9 | 42.7 |
| Terminal Bench 2.1 (Terminus-2) | コーディング | 81.0 | 63.5 |
| FrontierSWE (Dominance) | コーディング | 74.4 | 30.5 |
| SWE-Marathon | コーディング | 13.0 | 1.0 |
| MCP-Atlas (Public Set) | エージェント | 76.8 | 71.8 |
| Tool-Decathlon | エージェント | 48.2 | 40.7 |
伸び幅が際立つのはFrontierSWE（30.5→74.4）とSWE-Marathon（1.0→13.0）、Terminal Bench（63.5→81.0）だ。 いずれも長く続くコーディング作業を測る項目で、GLM-5.2が長期タスク向けを名乗る理由とつながる。 一方、HLE（人類最後の試験）は40.5で、絶対値としてはまだ高くない領域だ。 得意分野と苦手分野が数値にはっきり出ている点は、採用判断のときに見落とさないほうがいい。
競合モデルとの対比：DeepSeek・Qwen・Claude・GPT・Gemini
モデルカードは同じ表の中で、競合モデルの公称・引用値も並べている。
ここでは代表的な項目だけを取り出して対比する。
他社列の数値はモデルカードに記載された値であり、* 付きは出典元での引用値を意味する（条件が異なる可能性がある）。
| ベンチ（公称/引用） | GLM-5.2 | DeepSeek-V4-Pro | Qwen3.7-Max | Claude Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|---|---|
| SWE-bench Pro | 62.1 | 55.4 | 60.6 | 69.2 | 58.6 | 54.2 |
| Terminal Bench 2.1 | 81.0 | 64 | 75 | 85 | 84 | 74 |
| FrontierSWE | 74.4 | 29.0 | — | 75.1 | 72.6 | 39.6 |
| GPQA-Diamond | 91.2 | 90.1 | 90 | 93.6 | 93.6 | 94.3 |
| AIME 2026 | 99.2 | 94.6 | 97 | 95.7 | 98.3 | 98.2 |
| MCP-Atlas | 76.8 | 73.6 | 76.4 | 77.8 | 75.3 | 69.2 |
表から読めることを、煽らずに整理する。 コーディング系（SWE-bench Pro、FrontierSWE）でGLM-5.2はGPT-5.5・DeepSeek・Qwenを上回る項目があり、Claude Opus 4.8とは互角からやや下という位置にある。 数学のAIME 2026では99.2でClaude Opus 4.8を上回る。 一方、知識系のGPQA-Diamondでは91.2で、クローズドの上位モデル（93〜94台）にわずかに届かない。
独立評価では、Artificial AnalysisがIntelligence Index v4.1でGLM-5.2（max）に51を付け、オープンウェイトモデルの首位とした。 MiniMax-M3（44）やDeepSeek V4 Pro（max、44）を上回る、というのがArtificial Analysisの公開した位置づけだ。
GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index.
（GLM-5.2はArtificial Analysis Intelligence Indexで首位のオープンウェイトモデルとなった。）
— Artificial Analysis
VentureBeatは、GLM-5.2が複数の長期コーディングベンチでGPT-5.5を「6分の1のコスト」で上回ると報じた。 コスト効率の主張は配信元の記事に依存するため、自分の課金体系に当てはまるかは個別に検証する必要がある。
ライセンスと商用利用：MIT が許す範囲
GLM-5.2のライセンスはMITだ。
config.json の隣に置かれたモデルカードのメタデータにも license: mit と記載されている。
MITは、許諾表示を残せば、複製・改変・再配布・商用利用・サブライセンスを広く認める。
重みを社内サーバに置いて自己ホストする、独自データでファインチューニングする、製品に組み込んで販売する、といった使い方が原則として可能だ。
GLM-5.2のMIT採用で実務上効くのは次の点だ。
・自己ホストできるため、APIに機微データを送らずに済む
・ファインチューニング後の派生モデルも自分の裁量で配布・販売できる
・地域制限がないとモデルカードが明記しており、利用地域を理由に止まりにくい
・許諾表示（著作権表示とライセンス文の同梱）の義務は残るため、再配布時の同梱を忘れない
ただし、MITはモデルの出力に対する責任までは引き受けない。 生成物の権利や安全性、各国の規制適合は利用者側の判断になる。 商用採用の前には、LICENSEファイルの原文と、Z.ai側の利用規約（API利用時）を別々に確認しておきたい。
ローカル運用の現実：744B をどう動かすか
オープンウェイトであることと、手元のマシンで気軽に動くことは別の話だ。 GLM-5.2は744Bの重みを持つため、ローカル運用のハードルは高い。 モデルカードが挙げる対応フレームワークは次の通りだ。
・SGLang（v0.5.13.post1以降）
・vLLM（v0.23.0以降）
・Transformers（v0.5.12以降）
・KTransformers（v0.5.12以降）
・Ascend NPU向けにはvLLM-Ascend・xLLM・SGLang
メモリ要件を概算する（いずれも推定で、量子化方式や実装で増減する）。 BF16のままなら744B × 2バイトで、重みだけでおよそ1.4〜1.5TBに達する。 4ビット量子化でも約370〜400GB前後が目安になり、単一の消費者向けGPUには載らない。 現実的な選択肢は、複数の高VRAM GPUを束ねる構成か、KTransformersのようにCPUオフロードを併用する構成、あるいは大容量ユニファイドメモリを積んだ環境になる。
zai-org/GLM-5.2
Safetensors BF16"] --> DL["ダウンロード
重み 1TB級"] DL --> Q["量子化
4bit等で約370〜400GB（推定）"] Q --> ENG["推論エンジン
SGLang / vLLM / KTransformers"] ENG --> RUN["マルチGPU or 大容量メモリで実行"]
ローカルLLMを動かす土台づくりについては ローカルLLMツールガイド【2026年版】 で、Ollamaを使った具体的な手順は Ollama 0.24でOpenAI Codex CLIがローカルLLMで動く で扱っている。
ai-archive-jp 読者にとっての価値
OSS開発や個人開発の視点で、GLM-5.2が持つ意味を3つに絞る。
第一に、MITで配布される744Bクラスのモデルが選択肢に入ったことだ。 重みを自己ホストできるため、APIに依存しない開発フローを組める。 データを外に出せない案件や、レート制限・課金を気にせず長時間回したい実験で効いてくる。
第二に、1Mコンテキストと長期タスク特化という設計が、エージェント用途に向く点だ。 GLM-5.2の公称値が伸びているのは、まさに多段のコーディングやツール実行を続けるベンチだった。 長いコードベースを丸ごと読ませる、複数ファイルにまたがる変更を一括で扱う、といった作業との相性が見込める。
第三に、Z.aiが同じ組織から関連OSSを継続して出している点だ。 たとえばGLMファミリーのスキル集をまとめた GLM-Skills のように、モデル単体だけでなく周辺のツール群も公開されている。 GLM-5.2を採用するなら、こうした周辺リポジトリも合わせて見ておくと、組み込みの手数が減る。
macOS上でローカルモデルを動かすハーネスに関心があるなら、Osaurus のような軽量ランタイムと組み合わせる選択肢も検討の余地がある（744Bをそのまま載せる用途ではなく、量子化済みの軽量モデルや小型版を扱う場面での話だ）。
制限事項・注意点
最後に、GLM-5.2を評価するときに踏まえておきたい点を、事実ベースで挙げる。
公開時点で開発元の公式ベンチマークの一部が出そろっていなかった、という指摘がある。 Artificial Analysisなどの第三者評価が先行し、開発元の詳細値が後追いになった項目があった。 コミュニティの反応は概ね好意的（あるトラッカーでは約91%が肯定）だったが、否定的な声は2点に集まった。 一つは、「オープン」を掲げつつ実利用の入口が有料のCoding Plan経由に見える点への違和感。 もう一つは、大きな仕様更新に対してローンチ時のベンチ提示が手薄に見えた点だ。 これらは観察された評価であり、現在の配布状況はモデルカードと公式ブログで都度確認してほしい。
中国発のモデルである点については、事実だけを記しておく。 GLM-5.2のモデルカードは学習データや内容モデレーションの詳細を網羅的には公開していない。 中国国内のAIサービスには規制由来の出力制約が存在するが、自己ホストするオープンウェイトでその制約がどう作用するかは、モデルや運用設定によって変わる。 特定の話題での挙動が気になる用途なら、自分の環境で実際に試して確認するのが確実だ。 本記事は価値判断を下さず、判断材料の所在だけを示す。
数値はすべて公称・公開値である点も繰り返しておく。 ベンチマークは測定条件で動く。 採用を検討するなら、自分のタスクで小さく走らせて、公称値が再現するかを見るのが一番早い。
まとめ
GLM-5.2は、Z.ai（智谱AI）が2026年6月13日にMITで公開した744B MoEのオープンウェイトモデルだ。 1Mコンテキスト、IndexShareによる疎アテンションの効率化、長期タスク向けの公称ベンチ改善が要点になる。 Artificial Analysisの独立評価ではオープン首位（Index 51）とされ、コーディング系では一部のクローズドモデルに迫る公称値を示した。 一方で744Bの重みはローカル運用のハードルが高く、商用採用にはライセンス本文の確認が要る。 重みが手元に置ける以上、まずはAPIやチャットUIで挙動を確かめ、自分のタスクで公称値が再現するかを小さく検証することから始めるのが現実的だ。
