GLM 5.2とは？価格が6分の1のオープンウェイト・コーディングモデル

一言で言うと

GLM 5.2 は、Z.aiのオープンウェイトのフラッグシップ言語モデルです。2026年6月13日にリリースされ、コーディング、推論、ツールを駆使する「エージェント型」作業、つまりモデルが計画を立て、ツールを呼び出し、結果を読み取り、長いセッションを通じて修正を重ねるような複数ステップのタスクに特化して設計されています。

Z.aiは、2019年に清華大学の知識工学グループから分離して設立された、北京の研究企業Zhipu AIの国際ブランドです。「オープンウェイト」という言葉が重要です。モデルの実際のパラメータはHugging Face（zai-org/GLM-5.2）とModelScope、Ollamaで公開されており、地域制限のないMITライセンスで提供されています。誰の許可を求めることなく、セルフホスト、ファインチューニング、商用製品への組み込みが可能です。

オープンウェイトのコーディングモデルが、ベンチマーク以上に重要な理由

仕組みの前に、まず背景を説明します。このリリースが注目を集めた理由は、世界で最も賢いモデルだからではありません。実際、そうではありません。クローズドな最先端モデルとの性能差をほとんど埋めながら、無料でダウンロードでき、安価に呼び出せることが理由です。開発者にとって、これは以前なら決まっていた2つの判断の計算を変えます。

1つ目はベンダーロックインです。コーディングエージェントがクローズドAPI上で動作している場合、オフラインでは実行できず、内部を検査できず、料金は次の四半期にベンダーが決めるままです。オープンウェイトなら、これら3つの制約を一度に取り除けます。2つ目はコストです。GLM 5.2の報告されているAPI料金は、入力100万トークンあたり1.40ドル、出力100万トークンあたり4.40ドルで、Z.aiは同等の最先端モデルのおよそ6分の1のコストと位置づけています。大量のトークンを消費するワークロード、特にエージェント型コーディングでは大量に消費しますが、そこではこの比率がすべてを物語ります。

ただし、注意点があります。オープンウェイトは安全にセルフホストできますが、データをZ.aiのcloud API経由で処理すると、中国の国家情報法の対象となるインフラを通過します。米国土安全保障省は、この法律により中国企業が米国人に関するデータの引き渡しを強制される可能性があると警告しています。無料で検査可能な重みをどこでも実行できるという事実と、and実際のデータ管轄上の問題を抱えるホスト型APIが共存しているのです。どちらが適用されるかは、セルフホストするかクラウドを呼び出すかに完全に依存します。この点には後ほど戻ります。

曖昧さなしに仕組みを説明すると

GLM 5.2はMixture-of-Experts（MoE）モデルです。報告されている総パラメータ数は約7,440億から7,530億で、情報源によって少し異なります。これは正確な数値がまだ確定していないことの表れでもあります。一方、1つのトークンに対して実際にアクティブになるのは約400億パラメータだけです。

この分割が中心的な工夫なので、例えで説明する価値があります。密なモデルは、どんな質問にも毎回すべてを考えなければならない1人のゼネラリストのようなものです。MoEモデルは、大企業に近い存在です。非常に大規模な組織の知識を保持しながら、個々のタスクでは関係する少数の専門家だけを呼び起こします。7,440億パラメータモデルの容量を、約400億パラメータモデルに近い提供コストで利用できます。前世代のGLM 4.5（総数355B、アクティブ32B）と比べると、GLM 5は企業の規模を744B / 40Bまで拡大し、より多くのデータ（23兆トークンから28.5兆トークン）で学習しました。

他にも重要な要素が3つあり、それぞれ機能一覧を埋めるためではなく、特定の問題を解決するために存在します。

1つ目は、Z.aiがIndexShareと呼ぶスパースアテンション設計です。解決する問題は、コンテキストウィンドウが長くなるほどアテンションのコストが急激に増えることです。GLM 5.2のウィンドウは非常に長いため、この点は特に重要です。通常、モデルは各レイヤーで、どの過去トークンにアテンションを向けるかを再計算します。IndexShareは、4つあるアテンションレイヤーごとに最初のレイヤーでそのインデックスを一度だけ計算し、次の3つで再利用します。Z.aiによると、再利用するレイヤーでは内積インデックス計算のコストを75%削減し、100万トークンのコンテキスト長ではトークンあたりの計算量を約2.9倍削減できます。簡単に言えば、100万トークンのコンテキストを実際に実行可能なコストにする仕組みです。

2つ目はデュアル推論モードです。HighとMaxという、思考にかける労力を選べる2つの設定があります。Maxは、モデルが計画と修正を行うための余裕を必要とする、難しく複数ステップのコーディング向けです。1つのタスクで出力トークンを約85,000近く消費することがあります。Highは性能を数ポイントしか犠牲にせず、出力トークンをおよそ半分にできます。最後の数パーセントよりもレイテンシーとコストが重要な場合に選ぶ設定です。一言でまとめると、正確性がすべてならMax、日常業務ならHighです。

3つ目はマルチトークン予測です。1回のフォワードパスで複数のトークンを予測できるため、1つずつ予測するより推論が高速になります。また、副次的な効果として長距離の一貫性も向上します。

これらを合わせた実用上の目玉がコンテキストウィンドウです。入力は最大1,000,000トークン（glm-5.2[1m]識別子経由）、出力は最大131,072トークンです。GLM 5.1の約200,000トークンという上限のおよそ5倍です。100万トークンあれば、中規模のコードベースを一度にコンテキストへ保持できます。まさにこの用途を目指して設計全体が作られています。

実際の性能はどの程度か

ここでは、事実と報告値を明確に区別することが重要なので、率直に説明します。

事実は、Z.aiがGLM 5.2を公式ベンチマークスイートなしで出荷したことです。出回っている数値はすべて、事後にベンダーが報告したものか、初期の独立評価によるものです。まだ広く再現されたものはありません。個々の小数点以下の数値は、絶対的な真実ではなく方向性を示すものとして扱ってください。

この但し書きを踏まえても、報告値は情報源間で一貫しており、同じ方向を示しています。自律型ターミナルコーディングのTerminal-Bench 2.1では、GLM 5.2は81.0と報告されています。これはGLM 5.1の62.0から大きく伸び、Claude Opus 4.8の85.0にも約4ポイント差まで迫る数値です。実際のソフトウェアエンジニアリング問題を解決するSWE-bench Proでは62.1と報告され、GPT-5.5の58.6と前世代モデルの58.4を上回る一方、Claude Opus 4.8の69.2には及びません。Artificial AnalysisのIntelligence Indexでは51を記録したとされ、オープンウェイトモデルとして最高値です。

これらの数値が通常のベンダー表より重みを持つのは、操作が難しい独立した確認があるからです。Arena.aiのCode Arenaでは、目隠し形式のペア比較による人間の投票に基づくEloランキングで、GLM 5.2は総合2位に入ったと報告されています。また、クラウドソース型のDesign Arenaでは、Elo 1360で1位を獲得し、Claude Fable 5さえ上回ったとされています。人間による目隠しの選好投票は、自己申告の合格率よりはるかに操作しにくいため、私が最も信頼するのはこの2つの結果です。

事実ではなく判断として私の見解を述べるなら、GLM 5.2は現在利用できる最も強力なオープンウェイトのコーディングモデルです。複数のコーディングタスクでGPT-5.5を上回り、最も難しい長期的なタスクでは、内容に応じてClaude Opus 4.8に1ポイントからおよそ13ポイント差で遅れています。価格はわずかでありながら、近い性能を実現しています。上回っているわけではありません。

GLM 5.2、Claude Opus 4.8、GPT-5.5の比較

この3つから選ぶ人にとって、トレードオフは明確です。以下の表には、報告されているコーディングベンチマークのスコアと、料金、コンテキスト、ライセンスなど変わらない事実をまとめています。

率直なまとめ：最も難しいエージェント型コーディングでは、Claude Opus 4.8が依然として3つの中で最も高性能です。長時間の自律実行で正確性に対して料金を支払うなら、安全なデフォルト選択肢です。GPT-5.5は、今回のコーディングベンチマークでは中間に位置します。GLM 5.2の主張は「最高のモデルである」ではなく、「最高のモデルに数ポイント差まで迫り、オープンで、料金が何分の一か」というものです。コストを重視する場合、セルフホストしたい場合、またはファインチューニングしたい場合、この主張は強力です。数ポイントの信頼性向上が費用に見合う、ミッションクリティカルな長期エージェントを運用するなら、Claude Opus 4.8のほうが保守的な選択です。Claude側の料金はAnthropicが公開しており、GLMの数値はZ.aiが報告した料金です。

2つのクローズドな競合モデルを自分のプロンプトでA/Bテストしたい場合、どちらもGPT Protoの1つのAPIから呼び出せます。Claude Opus 4.8 (thinking)とGPT-5.5を、それぞれ100万トークンあたり一律4ドルで利用できます。（この一律料金はGPT Protoのものです。上の表にある入力5.00ドル / 出力25.00ドルという料金分割は、AnthropicがOpus 4.8に設定しているリスト価格です。同じモデルでも、料金体系が異なります。）3つすべてのモデルファミリーを1つのキーで利用できるため、自分で比較を実行する最も安価な方法です。

現在利用できるGLMモデルとGLM 5.2の比較

GLM 5.2自体は、ダウンロードしてホストするオープンウェイトとして提供されています。Z.aiのホスト型APIが呼び出しのための唯一のファーストパーティ手段であり、前述のとおり、そこにはデータ管轄上の問題があります。しかし、GLMシリーズは5.2から始まったわけではありません。前バージョンからの飛躍を見ることが、実際に何が変わったのかを理解する最も明確な方法です。

最も有用な比較対象は、直前のモデルであるGLM 5.1です。2つの違いが際立っています。コンテキストウィンドウは約200,000トークンから1,000,000トークンへ、5倍に拡大しました。これが最大のアップグレードです。コーディング性能の報告値も大きく向上しています。Terminal-Bench 2.1は62.0から81.0へ、SWE-bench Proは58.4から62.1へ上昇しました。つまり、GLM 5.2のランキング上の地位の大部分は、単なる小さな調整ではなく、前回のリリースからの改善によるものです。

オープンウェイトを構築するのではなく、現在すぐに単一のOpenAI互換APIからホスト型GLMを呼び出したい場合、GPT Protoで現在利用できるGLMモデルは、系譜上5.2の直前に位置するものです。

GLM-5.1は、ここで呼び出せる5.2に最も近いモデルです。同じファミリーに属する1世代前のモデルで、コンテキストは1Mではなく約200Kです。多くのコーディング作業では気にならない差ですが、コードベース全体を一度にコンテキストへ入れる必要があるリポジトリ規模のタスクでは、5.2が埋めた大きな差になります。全モデルのトークン単価はモデルページで確認できます。

Claude CodeでGLM 5.2を使う方法と実行可能な例

GLMシリーズを既存のワークフローに簡単に組み込める、特に重要な特徴があります。GLM 5.2はAnthropic互換エンドポイントを公開しています。Claudeと通信するように構築されたClaude Code、Cline、OpenCodeなどのツールは、そのまま接続できます。コーディングエージェントの統合を書き直すことなく、背後のモデルを入れ替えられます。そのため「Claude codingでGLM 5.2を使う」というパターンは、単なる検索フレーズではありません。エージェントの基盤はそのままで、下にあるモデルだけを変更できるのです。（5.2については、オープンウェイトがファーストパーティの手段なので、Z.ai独自のエンドポイントまたはセルフホスト環境を利用することになります。）

デプロイを管理したくない場合、現在の実用的な方法はGPT ProtoのOpenAI互換API経由でホスト型GLMを呼び出すことです。ここではGLM 5.1を使います。利用可能な最も近い兄弟モデルであり、5.2の追加コンテキストをセルフホストする価値があるか判断する前の基準として適しています。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_GPTPROTO_API_KEY",
    base_url="https://api.gptproto.com/v1",
)

resp = client.chat.completions.create(
    model="glm-5.1",
    messages=[
        {
            "role": "user",
            "content": (
                "Refactor this function for readability and explain the change:\n\n"
                "def f(x):\n"
                "    return [i for i in x if i % 2 == 0]"
            ),
        }
    ],
)

print(resp.choices[0].message.content)

同じリクエストをcURLで実行する場合：

curl https://api.gptproto.com/v1/chat/completions \
  -H "Authorization: Bearer $GPTPROTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.1",
    "messages": [
      {"role": "user", "content": "Write a Python function that returns the nth Fibonacci number, iteratively."}
    ]
  }'

glm-5.1をglm-5またはglm-5-turboに変更すれば、品質とコストのバランスを調整できます。上の表とまったく同じ比較を行うなら、claude-opus-4-8-thinking / gpt-5.5に変更してください。すべて同じキーで利用できます。

まずキーが必要です。GPT Protoダッシュボードで作成し、YOUR_GPTPROTO_API_KEYに入力すれば、上の呼び出しをそのまま実行できます。実行前にコストを計算したい場合は、全モデルのトークン単価をモデルページで確認できます。

得意なことと不得意なこと

強みは明確です。既存のランキングで最上位のオープンウェイト・コーディングモデルであり、本当に寛容なMITライセンスで提供されています。100万トークンのコンテキストは現実に利用可能で、IndexShareのおかげで実行コストも手頃です。さらに、同クラスで最高のコストパフォーマンスを実現しています。

弱みも同じく明確であり、隠さずに述べる価値があります。最も難しい長期的なコーディングではClaude Opus 4.8に遅れています。差は小さいものの、一貫しています。Z.aiは公式ベンチマークを公開していないため、より多くの独立研究機関が再現するまで、数値には注記が付きます。また、クラウドAPIのデータ管轄問題も現実のものです。データを特定の管轄区域の外へ合法的または契約上移動させられない場合、ホスト型Z.ai APIを使うべきではありません。その代わりにオープンウェイトをセルフホストしてください。オープンであることの本質はそこにあります。

利用すべき人、避けるべき人

最先端モデルに近いコーディング能力を最先端モデルの料金なしで使いたい開発者、セルフホストやファインチューニングが必要な開発者、またはトークン費用が大きな割合を占めるコスト重視のエージェント型製品を構築している開発者には、GLM 5.2が適しています。すでにClaude互換のエージェント基盤を持っていて、その背後に安価なエンジンを置きたい人には、特に相性の良いモデルです。

最後の数ポイントの信頼性にプレミアムを支払う価値がある、ミッションクリティカルで長期的な自律エージェントを運用している場合は、代わりにClaude Opus 4.8を選んでください。また、データレジデンシー規則によりホスト型GLM APIを利用できず、セルフホストもできない場合にも、Claude Opus 4.8が適しています。