TITLE

744B オープンウェイト LLM が MIT ライセンスで登場 ─ GLM-5.2 と自社システムへの組み込みを考える

投稿日:2026.07.01

CATEGORY

  • AI開発
744B オープンウェイト LLM が MIT ライセンスで登場 ─ GLM-5.2 と自社システムへの組み込みを考える

2026年6月16日、Zhipu AI が「GLM-5.2」の weights を MIT ライセンスで公開しました。総パラメータ数は 744B、アクティブパラメータは 40B/token のスパース MoE アーキテクチャです。コンテキスト長は入力 100万トークン、出力 131,072 トークンに達します。

地域制限なく公開されました。この事実のもつ意味を整理します。

アーキテクチャ: IndexShare が 1M コンテキストを現実的にする

GLM-5.2 の IndexShare アーキテクチャ概念図 — Indexer を 4 層ごとに共有して FLOP を削減する仕組み

スパース MoE モデルは総パラメータ数が大きくても、1 トークンあたりのアクティブパラメータを絞ることで推論コストを抑えます。GLM-5.2 の場合、744B 総パラメータのうち 1 トークンあたり 40B だけを活性化します。これ自体は他の MoE モデルと同様の設計思想です。

GLM-5.2 が独自に打ち出したのは「IndexShare アーキテクチャ」です。Zhipu AI が公開した技術資料によると、スパース Attention の Indexer コンポーネントを 4 層ごとに共有する仕組みで、1M コンテキスト時の FLOP を 2.9 倍削減できるとされています。

具体的には: 1M コンテキストを処理する際、通常のスパース Attention では Indexer を各層ごとに計算します。IndexShare はこれを 4 層単位でまとめることで、計算量を圧縮します。FLOP 削減率 2.9 倍という数字は、計算コスト面での実用化に向けた前進を示しています。長大なコードベースやドキュメント全体を一度に入力してモデルに処理させるユースケースが、API コストとして成立するかどうかはここにかかっています。

ベンチマークと位置づけ: 何が得意で何が苦手か

GLM-5.2 のベンチマーク比較 — Arena.ai コード部門・SWE-bench Pro の位置づけ

コーディング・エージェント・UI 生成の 3 領域で、GLM-5.2 はオープンモデルの中で際立った結果を残しています。Arena.ai(LLM のコミュニティベースのリーダーボード)のコード部門では 1,595 pt で 2 位、エージェント部門ではオープンモデル最高位、デザイン部門では 1 位です。コードを書いて実行して修正するループ全体で、オープンモデルとして現時点の天井を更新しているという評価です。Terminal-Bench 2.1 では 81.0、FrontierSWE では 74.4 という数字も公表されています。

一方、SWE-bench Pro は 62.1 で、Claude Opus 4.8 の 69.2 を下回ります。「最高精度の自律型コーディングエージェント」を求める用途では、現時点でプロプライエタリモデルに分があります。

ここまでをまとめると、コーディング支援・エージェント・UI 生成の用途でオープンモデルを選ぶ判断材料としては、現実的な水準に達しています。ただし、精度の絶対値で最上位を求めるなら、今はまだプロプライエタリモデルとの差が残っています。私がこの記事でどちらを選ぶかを言うなら、後者の判断は次のセクションで示します。

API コストとセルフホストの判断軸

GLM-5.2 の API 価格は入力 $1.40/1M tokens、出力 $4.40/1M tokens です。MIT ライセンスのため、vLLM・SGLang を使ったセルフホストも可能です。推論モードは High(高速・汎用)と Max(深い多段階推論・大規模コーディング向け)の 2 種類から選べます。

ただし、「セルフホスト可能」と「自社で運用できる」は別の話です。744B 総パラメータのモデルを運用するには相当の GPU メモリが必要で、vLLM・SGLang でのデプロイを含むインフラ設計と継続的なエンジニアリングリソースが前提となります。

私なら、まず API から試して実際の利用量とコストを確認します。API の従量コストと自社インフラの初期投資・運用コストを実測値で比較できてから、セルフホストへの移行を判断します。この順序で進めない理由はありません。

私の判断: 「コーディング支援 × 1M コンテキスト」が最初の試し場

各論点を踏まえたうえで、私はこう判断しています。

GLM-5.2 を今すぐ自社システムへ組み込む判断をするとしたら、対象は「コーディング支援 × 1M コンテキスト」の組み合わせが必要なユースケースです。大規模コードベースの横断検索・既存ドキュメントを丸ごと読ませての仕様抽出・レガシーコードの分析——こうした用途では、1M コンテキストと Arena.ai コード部門 2 位という実績が直接効きます。

まず Z.ai の API に登録して試してみるのが最初のステップです。Leadeas でも次に扱う大規模コードベースの仕様抽出タスクで、GLM-5.2 を当てはめてみるつもりです。SWE-bench Pro のスコアで Claude Opus 4.8 に届いていない点は承知のうえで、コスト比と MIT ライセンスの自由度を天秤にかけると、少なくとも試す価値は明確にあります。

ライセンスとコストの壁を主な懸念としていた組織にとっては、オープンウェイト LLM の実用ラインは2026年6月に更新されました。


出典

AI

AI導入やシステム開発の ご相談を承っています。

お気軽にお問い合わせください