100万トークン対応コーディングLLM「GLM-5.2」がMITで来週OSS化 — 長コンテキストを支えるアーキテクチャと「クラウド不要」の現実味
はじめに
2026年6月13日、中国・Z.ai（旧Zhipu AI）がコーディング特化の大規模言語モデル「GLM-5.2」を公開した。最大の特徴は100万トークンの長コンテキストと、来週中にMITライセンスでオープンソース化されるという2点だ。リポジトリ全体を丸ごと文脈に入れて作業できる規模と、商用利用も改変も自由なライセンスが同居する——これは「コーディングエージェントをどこで動かすか」という前提を静かに揺さぶる。本記事では、GLM-5.2が何者なのか、100万トークンを実用速度で捌くためのアーキテクチャ技法、そして同日に話題となったGemma 4のローカル実行と合わせて見えてくる「クラウド/プロプライエタリ依存からの回帰」という潮流を、エンジニア視点で掘り下げる。
GLM-5.2とは何か — ベンチマークで見える実力
GLM-5.2は、最大100万トークンのコンテキストウィンドウに対応し、1回の応答で生成できる出力は最大128K（131,072トークン）に達する。現時点で公開されているのは「GLM Coding Plan」（Lite/Pro/Max/Team）向けの利用で、単体API・チャットボット・そしてHugging Face上でのMITライセンスのオープンウェイトは「来週」展開予定とされている。つまりロードマップ上のOSSであり、6月13日時点ではまだダウンロードできない点には注意したい。
GLM-5.2自体の詳細なアーキテクチャやベンチマークは執筆時点で未公表だが、前世代GLM-5.1の実績が実力の目安になる。GLM-5.1はMoE（エキスパート混合）アーキテクチャで、総パラメータ7,440億・アクティブパラメータ400億という構成だった。注目すべきはコーディング能力の指標であるSWE-Bench Proで、
GLM-5.1が58.4%を記録し、GPT-5.4（57.7%）とClaude Opus 4.6（57.3%）を上回った
という点だ。現在の最前線はMiniMax M3（59.0%）、Kimi K2.6（58.6%）、GLM-5.1（58.4%）が僅差でひしめく激戦区であり、GLM-5.2は「同シリーズが首位を奪う展開も視野に入る」と見られている。さらにGLM-5.2は、長い推論・行動の連鎖でも安定するよう設計された新しい「Asynchronous Agent RL」アルゴリズムで訓練されたとされ、エージェント用途を明確に意識した世代であることがうかがえる。
技術的背景 — 100万トークンを成立させるアーキテクチャ技法
長コンテキスト対応の本質的な壁は、性能よりもメモリと計算量にある。Transformerはトークン同士の関係を保持するためにKVキャッシュ（Key/Valueの履歴）を持つが、これはコンテキスト長に比例して肥大化し、アテンションの計算量はおおむね長さの二乗で効いてくる。100万トークンを素朴に扱えば、メモリも速度も破綻する。この壁を崩すために2026年のモデル群が採用している技法が、GIGAZINEが整理した「KV共有」「mHC」「圧縮アテンション」だ。
KV共有（KV Sharing） は、後続レイヤーが先行レイヤーのKV状態を再利用してKVキャッシュ量そのものを削る手法。Gemma 4ではレイヤー間でKVの約半分を共有し、128Kのロングコンテキストでメモリを大幅削減している（E2Bで約2.7GB、E4Bで約6GB）。圧縮アテンション（Compressed Attention） はさらに踏み込み、トークン情報をシーケンス方向に圧縮した潜在空間でアテンション演算を直接行う。KVキャッシュだけでなくアテンションのFLOPs（計算量）も同時に削れるのが効きどころで、圧縮率を調整すれば速度と品質のバランスを取りながら超長文に対応できる。mHC（多様体制約付きハイパーコネクション） はDeepSeek V4が採用した残差ストリーム混合の技法で、層間の情報伝達を改善しつつ大規模モデルを安定してスケールさせる。
GLM-5.2が具体的にどれを採用しているかは未公表だが、100万トークンという数字の裏には、こうした「メモリと計算量を削る」地道な工夫の積み重ねがある。長コンテキストは単に窓を広げれば手に入るものではない、という点はエンジニアとして押さえておきたい。
エンジニアへの影響 — 「クラウド不要」はどこまで本物か
GLM-5.2が示すインパクトは、性能そのものより**「商用可能なMITライセンスで、リポジトリ規模の文脈を扱えるコーディングモデルが手に入る」**という構造の変化にある。同じ6月15日の話題には、ローカル実行できるGoogleの「Gemma 4 12B」、Gemma 4 + S3 Vectors + AgentCoreによる低コストRAG構築、さらにプロプライエタリな「Claude Fable 5」が輸出管理指令で突如アクセス停止になった体験記が並んだ。特定ベンダーのクラウドに依存することのリスクが可視化される一方で、ローカル/OSSの選択肢が実用域に近づいている——今日のダイジェストはこの対比が通底テーマだった。
実務への落とし込みとしては、(1) コードを外部に出せない受託・金融・医療系で、自前GPUやプライベート環境にOSSモデルを置く現実味が増す、(2) 100万トークンでリポジトリ全体を文脈化し、横断的なリファクタリングや影響範囲調査をエージェントに任せやすくなる、(3) MITライセンスゆえにファインチューニングや製品組み込みのハードルが低い、といった点が挙げられる。一方で、ウェイト公開は「来週」であり、自前運用には相応のGPUメモリと運用コストが伴う。API手軽さのプロプライエタリ vs 自由度・自律性のOSS という選択は、今後プロジェクトごとに意識的に天秤にかける場面が増えるだろう。
まとめ
- GLM-5.2はZ.aiのコーディング特化LLMで、100万トークン対応・MITライセンスでの来週OSS化が予告された（6/13時点ではまだ未ダウンロード）。
- 前世代GLM-5.1はSWE-Bench ProでGPT-5.4やClaude Opus 4.6を上回る58.4%を記録しており、最前線の激戦区に位置する。
- 100万トークンはKV共有・圧縮アテンション・mHCなど「メモリと計算量を削る」技法に支えられている。
- Gemma 4のローカル実行やFable 5のアクセス停止と合わせ、「クラウド/プロプライエタリ依存からローカル/OSSへ」という流れが現実味を帯びてきた。
ウェイトが実際にHugging Faceへ降りてきたとき、ベンチマークと自前運用の実コストがどう噛み合うか——OSSコーディングエージェントの主導権争いは、来週さらに動く。
今日のその他のニュース
- Supabase、Series Fで$500M調達: 同時にMultigres 0.1、passkey認証、ChatGPT連携（29ツール）、Claude Code/Cursor/Codex/Gemini CLI対応のAIエージェントプラグインを発表。BaaSがエージェント時代のインフラとして再定義されつつある。
- 実装前に要件を問い詰めるスキル
/grill-me: AIにいきなり実装させず、設計・要件をAI側から徹底インタビューさせるアプローチが143usersを集める。AI駆動開発の主戦場が「コード生成」から「要件・仕様の確定」へ移っていることを示す。 - The only scalable delete in Postgres is DROP TABLE: Postgresの大量DELETEがなぜ重いのかと、パーティション戦略による回避策。大規模データ運用者は一読の価値あり。