【23】ついにフロンティアが全て自分のものに——GLM-5.2とOpusの間で、開いた隙間と埋まった隙間

2026年6月17日、Z.aiがGLM-5.2を出した。フラッグシップモデルを、MITライセンスで、1Mコンテキストを伴えて、OpenAIの前世代と同じくらいのAPI価格で世に出した。記事の冒頭にこれだけ書いてしまうと宣伝に見えるが、事実は事実として並べる。

数ヶ月前までは、空気があった。「Opus一強」。難しい仕事を任せるならClaude Opus、その一点に落ち着く。Geminiは長文脈が強いが仕上げが一歩足りない、GPTは旗艦が輝くがエージェント向けの作りが浅い、ローカルは論外——そういう見方をしている人が多かった。その空気が、ここ半年で割れている。Kimi K2.5、MiniMax系、そしてGLM-5→5.1→5.2と、オープンウェイトのフロンティア候補が一斉に追い上げてきた。

本稿は、そのうちGLM-5.2一つを、公式の数字と自分の実感を並べて、二つの隙間を確かめる。一つは「埋まった隙間」、コーディングとagenticと長文脈で、フロンティアまであと1%になった隙間。もう一つは「まだ開いた隙間」、創造性と判断力と指示追従で、最終的にOpusに落ち着いてしまう隙間。両方見て初めて、「フロンティアが全て自分のものになる」が現実になる。

1. GLM-5.2は何を足したか

GLM-5.2は、前世代のGLM-5.1から、三つの足を一つずつ太くした。第一に、文脈長だ。200Kだった最大コンテキストを、1Mへと据え直した。1Mという数字は最近あちこちで見かけるが、Z.aiは「solid」を強調する。1Mを謳うのは容易だが、汚れたコーディングエージェントの軌跡を入れたまま品質を保つのは難しい。そこで、コーディングエージェントのシナリオを大規模に学習させて、大規模実装・自動研究・性能最適化・複雑デバッグを1M文脈で回した。結果として、広いだけでなく、エンジニアリングの圧力に耐える1Mが出来たと公式は主張する。

第二に、コーディングとeffortの柔軟性だ。reasoning effortを2種類用意した。通常と、Maxだ。通常はtoken予算を抑えて速度と計算コストを稼ぎ、Maxは難題に追加の計算を回して能力を伸ばす。ユーザーがシナリオごとに選べる。この設計は、Opusには無かった。Opusは思考レベルを外からは選べない（thinking on/offはあるが、effortを2段階でユーザーに任せる作りではない）。ここでGLM-5.2は一つ、Opusに無い手足を出した。

第三に、Pure Openだ。MITライセンス、地域制限なし、技術的アクセスに国境を置かない。これはHuggingFace上で zai-org/GLM-5.2 と GLM-5.2-FP8 の両方が置かれていることに裏付けられる。FP8版まで公式に出すというのは、「量子化して自分のGPUで回していい」という意思表示だ。

2. 数字で見る——ここまで迫った

公式ブログが載せた三つのlong-horizonベンチマークを、そのまま並べる。

FrontierSWE。エージェントが、数時間から数十時間規模の技術プロジェクトを完遂できるかを見る。システム最適化・大規模コード構築・応用ML研究を跨ぐ。ここでGLM-5.2は、Opus 4.8と1%差、GPT-5.5に1%勝ち、Opus 4.7に11%勝ち。1%。小さく見える数字だが、長文脈のエージェント作業で、ここまで差が縮まった事実は大きい。

PostTrainBench。各エージェントにH100を1枚渡し、小モデルをポスト訓練でどこまで改良できるかを競う。ここでGLM-5.2は、Opus 4.7とGPT-5.5の両方を超え、Opus 4.8に次ぐ2位。つまり、ML研究の作業も、Opus 4.8以外には引けを取らない。

SWE-Marathon。超長文脈のソフトウェアエンジニアリング。コンパイラ構築・カーネル最適化・プロダクション級サービス開発を跨ぐ。ここはGLM-5.2もOpus 4.8に13%劣る。伸び代が残っている。それでも、Opus系列に次ぐ2位を維持している。三つのベンチマーク全てで、GLM-5.2はオープンソースの中で最高位。

標準コーディングベンチマークも一つ。Terminal-Bench 2.1で81.0。GLM-5.1から17.5ポイントも跳ねた（63.5→81.0）。Claude Opus 4.8の85.0とは4ポイント差。Gemini 3.1 Proを凌いでいる。SWE-bench Proは62.1、同じくGLM-5.1から3.7ポイント向上。

数ヶ月前まで、「オープンソースはSWE-bench 70台で頭打ち」と言われていたのが、今はOpus 4.8と4ポイント差である。

3. 1Mが速いだけでなく安くもなった——IndexShareとMTP

1Mコンテキストを謳うモデルは増えたが、1Mを速く・安く回すものは少ない。GLM-5.2は、DeepSeek Sparse Attention（DSA）の上に、IndexShareという仕組みを載せた。4層ごとに一つの軽量indexerを共用し、topkの索引を4層で使い回す。これで、1M文脈での1tokenあたりFLOPsを2.9分の1に削った。1Mを謳っても、これをやらないモデルは、文脈が伸びるほど計算量が比例して爆発する。GLM-5.2はそこを断ち切った。

推論側も詰めている。MTP（Multi-Token Prediction）層をspeculative decodingのdraftに使い、IndexShareとKVShareをMTPにも当て、さらにrejection samplingとend-to-end TV lossを訓練に導入した。結果、acceptance lengthがbaselineの4.56から5.47まで伸びた。20%の向上だ。speculative decodingが効くと、体感速度が段違いになる。1Mを保っても、生成が鈍くならない。

slimeという asynchronous RLインフラも、GLM-5.2の訓練を支えた。長文脈のエージェント作業は、rolloutが長くなり、訓練が立ち上がらない。slimeは、white-box/black-box rollout・compact trajectory・sub-agent workflowを一つの系で扱い、GLM-5.2のOPD訓練を「約2日」で終わらせた。十人以上の専門家モデルを一つに併合するのを2日で回す。この訓練効率が、API価格を前世代並に保てる理由の一つだ。

4. コーディングでOpusに並ぶ日・超える日

公式のeffortグラフを読むと、GLM-5.2は、同じtoken予算で並べたとき、GLM-5.1より大幅に強く、能力が概ねClaude Opus 4.7と4.8の間に定位する。Max effortを回せば、さらに上まで伸びる。

ここから先は、実感で補完する。コーディングタスクを日々回していると、GLM-5.2がOpusに並ぶ日がある。特に、縛られた仕様の実装・リファクタリング・テストを追加する作業・長いファイルを跨ぐ修正・CIの赤を潰す作業では、体感で違いが分からないほどまで迫る。特定領域では、Opusを超える場面すら出てくる。自分の経験では、既存コードの理解と部分修正、長文脈を保持したままのバッチ修正、ターミナルで連続して手を動かす作業、あたりはGLM-5.2が極めて強い。1Mコンテキストを活かしたlong-horizonのエージェント作業は、これまでOpusにしか出来なかった領域に、GLM-5.2が入り込んでいる。

価格も効く。APIで5〜8倍安い。ローカルでも、FP8版を回せば、Opus級の仕事が、自分のGPUで、時間切れなしに、出せる。これは、数ヶ月前には「Opus一強」の理由だった「高くてもOpusしか出来ない」が、一人一人の環境で崩れることを意味する。

5. それでもOpusに落ち着く瞬間——まだ開いた隙間

では、全部Opusを捨ててGLM-5.2に替えればいいか。筆者はそうはしていない。日常使いでOpusに落ち着くことが多い。ここを正直に書く。

落ち着く瞬間は、幾つかある。第一に、創造的な構想を練る時だ。新しい仕組みを言葉で設計する、記事の構成を整える、方向が二つある時にどちらを選ぶかを論理で考える、こうした仕事は、Opusの判断力が一歩出る。GLM-5.2も書けるが、出てくる構えが、Opusの方が一段拔けている。言葉を選ぶ精度、論理の展開、文脈の持ち方、最終的な信頼感が、まだOpusに軸が移る。

第二に、指示追従の洗練度だ。複雑な指示を一つ渡した時、Opusは指示の枝を漏れなく拾う。GLM-5.2も概ね拾うが、極めて細かい拘束をかけた時、枝を一本刈り落とすことがある。仕様に「絶対触るな」「触れてはいけないファイル」「含めてはいけないコミット」など拘束を並べた仕事——本稿の元になったパイプライン記事の仕様もそうだった——では、拘束を守り抜く確実さが、Opusが一歩出ている。

第三に、予期せぬ狀態への対応だ。ツールが返す狀態が想定と違う、エラーの文面が意味を取りづらい、作業の途中で前提が崩れる、こういう時にOpusが立て直すのが早い。GLM-5.2も迚回できるが、Opusの「狀態を言葉で整理して、次の手を主動で提案する」が、信頼できる。

第四に、仕上げの最後の一押し。これでいいかと間に合わせるか、もう一歩詰めるか。Opusは、自分からもう一歩詰める。GLM-5.2は、指示で詰めろと言えば詰めるが、言わなければ間に合わせる。この「言わなくても詰める」ところが、最終的な成果物の質を決める。

つまり、埋まったのは「実行と継続と長文脈」の隙間。まだ開いているのは「判断と創造と指示追従の洗練」の隙間。この二つは、同じ「能力」とは限らない。GLM-5.2は前者でOpusに並んだ。後者は、もう少し時間が要る。

6. 価格の革命——5〜8倍安いAPIと、自分のGPUで回るFP8

Opus一強が崩れる理由は、能力だけではない。価格だ。APIで、GLM-5.2はOpusの5分の1〜8分の1くらいで打っている。長文脈を回す仕事では、この差が直に効く。1M tokenを扱う作業をOpusで回せば、すぐに日本円で四桁の料金が積む。GLM-5.2なら、同じ仕事を数百円台で回せる。 Developers が「フロンティア級を安く・自由に使える」ようになったのは、この価格破壊が一面ある。

ローカルも同じだ。zai-org/GLM-5.2-FP8 がHuggingFaceに置いてある。FP8は、量子化されずに原則の精度を保ったまま、VRAMと計算を抑える形式。自分のGPU——M1 Max 64GBクラスのMacでなら、余裕を持って回る。APIを使わずに、時間切れなく、Opus級の仕事を、自分の机の上で出せる。これを数ヶ月前に言えば、「夢物」だった。今は、HuggingFaceから重みを落とせば、夜の間に回っている。

GLM-5.2は、Claude Code・OpenCode・Kilo Code・Roo Code・Cline・Droidと互換がある。つまり、既存のコーディングエージェントの設定を、モデル名一つ替えるだけでGLM-5.2に切れる。Claude Codeの ~/.claude/settings.json の model を "GLM-5.2" に替えれば、あとはそのまま動く。この「既存の仕組みに素直に刺さる」も、移行コストを下げる。

7. 744Bを、誰も全部持たないのに回す——フロンティアが物理的に自分のものになる日

ここまでの話は、APIか、1台のGPUか、どちらかでフロンティアを回す話だった。しかし、GLM-5.2の744Bは、1枚のGPUには載らない。RTX Pro 6000 Blackwellを1枚買っても、744Bの4-bit（NVFP4）すら、1枚には入らない。ここで「フロンティアが全て自分のものになる」は、一つ壁に当たるように見えた。大きなモデルは、大きな1台が必要だ、と。

2026年6月18日、その壁が崩れた。leytenのshardというエンジンが、GLM-5.2の744B（NVFP4、78層）を、アメリカ6州に散らばった6台のRTX Pro 6000で、WAN（公開インターネット）越しに、約30 tok/sで回した。greedy、deterministic、検証可能。1枚のカードにも、1台のホストにも、1つのデータセンターにも、モデル全体は載らない。6台が、それぞれ自分の13層だけを持つ。活性化テンソルが、毎トークン、国を横断して流れる。

これが「フロンティアが全て自分のものになる」の、最も物理的な意味だ。1枚では持てない744Bを、WANで繋いだプロシューマのGPU6台で、実用速度で回す。誰もモデル全体を持たない。検閲なし。分散。Apache 2.0ライセンス。c0mputeというプロジェクトのインフラとして公開されている。

30 tok/sに至る道は、一つの直感から始まる。WANでは、ラウンドトリップが稀少資源で、計算はそうではない。だから、データセンターでは有利度が限定的なspeculative decodingが、WANでは勝負の全てになる。小さなdraft（GLM-4-9B）がK個のトークンを提案し、分散した744Bが1回のパイプライン走査で検証し、貪欲に確定する。これだけだと1.99 tok/s。そこに、ring direct-return（末尾がcoordinatorに1ホップで戻る）を足して2.94。async pipelining（複数の検証チャンクを並行で飛ばす）を足して16.6。最後に、draftをCUDA graphで捕まえて3.8倍に速くして、約30。WANがループの5%まで隠れる。

一番困難だったのは、CUDA graph下の静的KVキャッシュに、speculativeのロールバックを食わせることだった。書き込みスロットを静的アドレスの位置テンソルで駆動することで解決し、結果はeagerパスとバイト同一。つまり、最適化がlosslessであることが証明できる。これが「greedy、deterministic」の意味だ。推論結果に揺らぎがない。

全ての実行は、検証可能なレシートを吐く。異なるGPU UUID、公開IP、地域、計測されたWAN端RTT（22〜75ms）、出力トークンのハッシュ。懐疑者はdocs/PROOF.mdで確認できる。744BをWANで回した、と口先で言うのではなく、証拠を出す。この誠実さが、プロシューマの分散推論を「ネタ」から「事実」に変えた。

これが意味するのは、「フロンティアが全て自分のものになる」が、APIでも1台のGPUでもなく、ネットで繋いだGPUの群れでも可能になった、ということだ。744BのOpus級モデルを、誰も全部持たないのに、6台で回す。1台のマシンの限界が、フロンティアの限界ではなくなった。これを数ヶ月前に言えば、夢物だった。今は、GitHubのleyten/shardから、レシート付きで、読める。

8. 自分のパイプラインに、OpusとGLM-5.2をどう割り振るか

ここからが本題だ。「フロンティアが全て自分のものになる」は、Opusを捨てることではなく、二つを仕分けて使うことだ。筆者のパイプラインは、今こんな形になっている。

• 構想と指示の段階はOpus。記事のテーマを練る、仕様を書く、構成を決める、判断を仰ぐ。創造と判断の隙間はOpus。
• 実装と長文脈の作業はGLM-5.2。仕様が決まったら、コードを書く、テストを足す、リファクタリングする、長いファイルを跨ぐ修正、CIを赤にする。実行と継続の隙間はGLM-5.2。effortは、通常作業は通常、難所はMax。
• 仕上げの最後の一押しは、またOpusに戻す。出来上がったものを見せて、「もう一歩詰められる所」を指してもらう。

こう分けると、APIコストは段違いに下がる。Opusを全工程に振れば、1Mを跨ぐ実装作業だけで料金が吹く。Opusは創造と判断と仕上げだけに注ぎ、実装の長文脈はGLM-5.2に預ける。これが、筆者の言う「Opusに落ち着く」の実態だ。全工程をOpusにするわけではなく、Opusが本質の仕事を、Opusに残す。それ以外をGLM-5.2に移す。結果として、Opusの使用tokenは減り、GLM-5.2の使用tokenは増える。コストが下がるのに、仕事の質は落ちない。むしろ、長文脈をGLM-5.2に任せた方が、速く、安定したりもする。

9. 終わりに——フロンティアが全て自分のものになる日

フロンティアと呼ばれるモデルは、これまで一つだった。高くても、Opusに頼るしかなかった。その時代は、2026年6月17日に、一つ分の隙間が埋まった。1Mコンテキストを、MITライセンスで、Opus 4.8と1%差で、API価格は前世代と同じ——これが、Z.aiのGLM-5.2一本で起きた。

全部がOpusを下したわけではない。創造と判断と指示追従の隙間は、まだ開いている。仕上げの最後の一押しは、Opusが一歩出ている。だから筆者は、日常使いでOpusに落ち着く。ただ、そのOpusを、全工程に振らなくてよくなった。実装と長文脈は、GLM-5.2に任せれば、安く、速く、同じ仕上が得られる。

「フロンティアが全て自分のものになる」は、一つのモデルで全部を済ますことではない。二つのフロンティアを、それぞれの強い所に仕分けて、自分の仕事全体を支えることだ。Opusが創造と判断を担い、GLM-5.2が実装と長文脈を担う。APIとローカルを、仕事の段階に応じて切る。こうした時、初めて「高くても仕方なく」が消えて、「自分の仕事の形に合わせて、フロンティアを選ぶ」が現実になる。

数ヶ月前に「Opus一強」を見ていた人が、今、GLM-5.2・Kimi・MiniMaxを並べて迷っている。この迷いこそが、フロンティアが一つではなくなった証拠だ。迷いは、選択肢が現実になった時に生まれる。この記事が、誰かのパイプラインを、Opus一本から、二本の仕分けに替える一つの材料になればいい。フロンティアが全て自分のものになる日は、まだ全部は来ていない。ただ、一つの隙間は、確実に埋まった。