Z.ai、GLM-5.3を公開 - ベースモデルは据え置き、重みの公開は安全性評価の完了を待って2週間後に

Z.aiが2026年8月14日、GLM-5.3を公開した¹。冒頭の一文が「GLM-5.3でやったのはポストトレーニングのスケールだけだ」というもので、ベースモデルはGLM-5.2と同じまま、性能向上はすべてポストトレーニング由来だとしている¹。

もうひとつ目を引くのが、重みの公開時期だ。Z.aiは「安全性評価とハードニングが完了したあと、公開から2週間後に重みを公開する」としている¹。GLM-5.3のページに置かれたHugging Faceへのリンクは、現時点では「Coming Soon」の表示でリンク先が設定されていない¹。同じ発表の中でZ.aiは、サイバー能力が想定より速く伸びたとも述べている¹。

「訓練を大きくしたら、想定より速く伸びた」

Z.aiは、ポストトレーニングの一部として脆弱性発見のデータと環境を訓練に混ぜたと説明している¹。狙いは脆弱性を見つけて推論する能力の向上だったが、同社が「驚いた」と書いているのは、訓練の規模を大きくするにつれてその能力が伸び続けた速さのほうだった¹。個々の欠陥を見つけるのがうまくなっただけでなく、悪用の複数の段階をまたいで推論し、悪用チェーン全体について一貫した計画を立て始めた、という記述である¹。

数値は3つのベンチマークで示されている¹。ホワイトボックスのソースコードから脆弱性を特定・検証するCyberGymでは84.5%で、GLM-5.2の77.2%から上昇し、Z.aiはこれをベンチマーク上の最良の結果としている。実在する脆弱性とその悪用についてより深い推論を求めるExploitBenchでは54.4%で、GLM-5.2の24.4%から2倍を超えた。時間予算を正規化したうえで悪用タスクをいくつ完了できるかを測るExploitGymでは、2時間で105タスク・6時間で130タスクを完了しており、GLM-5.2の29タスク・39タスクから大きく増えている。

Z.aiは3つの結果に共通する構造も自ら書いている。悪用チェーンの上流に位置するベンチマークほどGLM-5.2からの伸びが大きく、同時にクローズドのフロンティアとの差も大きく残る、というものだ¹。「能力が最も速く伸びているのは、まさに我々が最も遅れている領域である」と結んでいる¹。

これらの数値はいずれもZ.ai自身の測定であり、第三者による検証ではない。フットノートには評価条件が細かく記載されていて、たとえばCyberGymは Claude Code 2.1.207 のハーネス上で、Webツールなし・タスクごとのタイムアウトなしという条件の、1,507タスクに対する単一実行のPass@1である¹。ExploitGymの「2時間」「6時間」も実時間ではなく、モデルごとのトークン毎秒の値でAPIの推論時間を再スケールして算出した予算だとしている¹。

実コードベースで2,436件、最も古い欠陥は1981年

ベンチマークの外での検証結果も公開されている。Z.aiはGLM-5.2の頃から中国国内の複数のセキュリティチームと組み、実在するコードベースに対してモデルを走らせてきたという¹。専門家によるレビュー・スクリーニング・重複排除を経て、269のプロジェクトで2,436件の脆弱性を特定したとしている¹。対象はシステムカーネル、OS、ブラウザエンジン、オープンソースのインフラ、Webアプリケーション、ネットワークプロトコルに及ぶ¹。

同社は開示の進行状況を追うために「Z.ai Security Disclosure Ledger」という公開台帳を用意しており、その集計がGLM-5.3のページにも掲載されている¹²。追跡中の指摘が2,436件、うち公開済みが53件、開示手続き中（embargo）が2,383件¹²。重大度の内訳はcriticalが107件、highが990件、mediumが1,286件、lowが53件で、criticalとhighの合計が1,097件となっている¹²。

年数の話が具体的だ。台帳の集計は「45年分の影響」を示し、最も古い欠陥は1981年に入り込んだもので、平均すると脆弱性は発見までに26.6年間コードの中に残っていた¹。これは第三者が検証した数字ではなく、Z.aiと協力先のセキュリティチームによるレビューを経た自己申告の集計である。

こうした能力の公表と公開の可否をめぐる判断は、直近では別のラボでも起きている。OpenAIは8月7日に、公開前のモデルAstraについてPreparedness Frameworkの「Critical」のサイバー能力を除外できないと結論づけたと公表し、強化した管理要件を満たさない社内活動を停止したとしていた。クローズドのモデルでは「社内での扱い」が論点になるのに対し、オープンウェイトのモデルでは「そもそも重みを出すかどうか」が論点になる。今回の2週間の保留は、後者の形で同じ問題に触れたものと言える。

重みの公開が予定から後ろにずれる例自体は、他社にもある。Alibabaは8月3日にQwen3.8-Maxを正式リリースした際、Maxクラスとして初となる重みの公開を「翌週」として、モデルの提供開始とは時期をずらしていた。ただしQwenの場合に語られていたのは公開の順序であり、安全性評価を理由に挙げたわけではない。GLM-5.3は理由の書き方がより踏み込んでいる。

コーディングの伸びとトークン効率

サイバー能力の話に埋もれがちだが、Z.aiがGLM-5.3の主眼に据えているのはコーディングである。同社は、コーディングで最も能力の高いオープンウェイトモデルであり、自社ベンチマークのZ.ai Code BenchでGLM-5.2から50%改善したと述べている¹。公開ベンチマークでは、Terminal-Bench 3.0が4.6から28.3、DeepSWE v1.1が46.2から66.9、Agents’ Last Examが23.8から28.5に上がっている¹。

興味深いのはトークンの使い方だ。Z.ai Code BenchのMax effortでGLM-5.3は1タスクあたり約7万5千出力トークンで34.5%に達し、GLM-5.2は9万6千トークンで23.4%だった¹。High effortでは約5万トークンで31.4%となり、12万トークンで29.5%のClaude Opus 4.8を上回るとしている¹。一方で、Max effortで39.5%に達するClaude Fable 5には及ばないとも書いている¹。スコアと消費トークンを併記する書き方は、実際にエージェントを回したときの請求額に効く部分である。

伸びの理由としてZ.aiが挙げているのは訓練環境の性質だ。コーディングの練習問題ではなく「専門家の仕事の実際の単位」に近いタスクへ環境を寄せたといい、中には経験のあるエンジニアで数日分の作業に相当するものもあるとしている¹。そうした環境を数多く用意するために、環境そのものを端から端まで合成するパイプラインを作り、一部のタスクではRLの報酬信号も合成した¹。判定役のエージェントが各タスクを実際に解いてみて、解けることを確かめる仕組みも入っている¹。ただしZ.ai自身、これらのパイプラインには依然として相当量の人手が要るとし、環境の生成と検証をより自律的にすることが次の課題だと書いている¹。

使う側の作業: thinkingの無効化が廃止された

GLM-5.3を実際に使う側にとって、最も直接的な変更はAPIの仕様である。GLM-5.3は思考の深さを low / high / max の3段階で指定でき、既定は max¹。そして thinkingの無効化はGLM-5.3ではサポートされなくなった¹。

Z.aiは移行手順を明示している。現在 thinking.type: "disabled" を使っているアプリケーションは、モデルIDを glm-5.3 に変える前に enabled へ変更し、reasoning_effort を low に設定する必要がある¹。そうしないとリクエストは失敗する、と書かれている¹。コーディング用途には max が推奨されている¹。

提供面では、GLM-5.3はZCode、Claude Code、OpenCodeなどのコーディングエージェントから使えるとしている¹。GLM Coding Planの加入者には全員に展開済みで、プランはポイント制のクォータに変わった¹。ポイントの消費は入力・キャッシュ済み入力・出力で別々に計算され、ピーク時間帯の外での呼び出しは標準の50%のポイント消費になる¹。ピーク時間帯は月曜から金曜の14:00-18:00（UTC+8）で、週末を含むそれ以外の時間はすべてオフピーク扱いとされている¹。

同じ週にはDeepSeekもAPI価格に時間帯課金を導入すると告知しており、中国系のモデル提供者が相次いで「いつ動かすか」を料金に織り込み始めている。エージェントを常時走らせる使い方が増えるほど、実行時刻の設計はコストの設計に近づいていく。

重みが実際に公開されたときには、Z.aiが挙げているサイバー能力の数値を第三者が検証できるようになる。それまでの2週間は、Z.aiの自己申告だけが判断材料という状態が続く。