GLM-5.2 API：料金、100万トークンコンテキスト、本番ルーティング

すでにGLM-5をルーティングレイヤーに組み込んでいて、GLM-5.2のリリースツイートが転送されてきてモデルIDを切り替えるべきか聞かれている場合、このページがGLM-5を再説明せずに答えを提供します。

GLM-5.2 APIはGLM-5に対するデルタとして読むのが最適です。まったく新しいモデルのリリースではありません。GLM-5のアーキテクチャに関する以前の記事がベースラインを解説しています。この記事では何が変わったか、何がライブで何がまだロールアウト中か、そして新しいコンテキストウィンドウとプライシングの方向性が迫るルーティング判断について説明します。

フレーミングについて一点。2026年6月中旬時点では、スタンドアロンのトークン課金APIがロールアウト中です。Coding Planエンドポイントはライブになっており、従量課金APIは「来週」とのことですが、ソースによって異なります。ここでのトークン課金価格は流通しているレートカードとして扱い、Z.aiの公式リストではありません。[この記事を読む時点での確認が必要]。

GLM-5.2がGLM-5から変えたこと

1Mコンテキストウィンドウとコーディング優先の位置づけ

最大の変更点はコンテキストウィンドウです。GLM-5.1は200Kトークンが上限でした。GLM-5.2は最大出力131,072トークンで1Mトークンウィンドウに移行します。長コンテキストバリアントのモデルIDはglm-5.2[1m]です。ブラケットタグは意味を持ち、エンドポイントはこれを推論しません。

5倍の増加は、ルーティング先を意味的に変える唯一のスペック変更です。リポジトリ全体のナビゲーション、長いエージェントプラン、以前はチャンキングが必要だった複数ファイルのリファクタリングが、シングルコールのワークロードになります。それらが良いシングルコールワークロードになるかは別の問題です。

もう一つの変化：Z.aiはThinkingモードをHighとMaxのみに絞りました。Auto、Lowはありません。明確なシグナルです。5.2は真剣な作業向けに位置づけられており、短い検索には向いていません。コスト節約のためにGLM-5に短い分類コールを送っていたルーティングレイヤーがあるなら、それは5.2が想定するユースケースではありません。

バージョン増分であって新しいファミリーではない理由

基盤となるアーキテクチャはGLM-5と同じMoE形状のようです。Z.aiのHugging FaceのGLM-5.2リリースによると、トークンあたりおよそ40Bがアクティブで、合計パラメータ数は約744〜753Bです。MITウェイトリリースはAPIローンチから約1週間後に予定されています。要確認。

ローンチ時に公開ベンチマークなし。Z.aiとしては珍しくなく、5.1と同じパターンです。ただし、5.2についての現時点でのパフォーマンスの主張はすべて5.1から引き継がれたものか、初日のサードパーティテストからのものです [ベンダー報告]。マーケティングは方向性として扱い、データとして扱わないでください。

結論：より大きなウィンドウとコーディング優先のスタンスを持つGLM-5。新しいファミリーではありません。

今日GLM-5.2にアクセスする方法

Coding Plan vs スタンドアロンAPI vs オープンウェイト

3つのパス、3つのコミットメントレベル：

Coding Plan。 ローンチ日にLite、Pro、Max、Teamの各ティアでライブ。従量課金トークンではなく、5時間サイクルごとのプロンプトベースの制限を持つサブスクリプション。Liteの入門価格は月$10〜18程度と報告されています（要確認。プロモーション価格は変動します）。チームがClaude Code、Cline、OpenCode、Roo Code、Goose、Crush、OpenClaw、またはKilo Codeを使っているなら、これが現時点で最も摩擦の少ないパスです。

スタンドアロントークン課金API。 公開時点ではまだロールアウト中。サードパーティのリストで流通しているレートは、入力トークン100万あたり約$1.40、出力100万あたり$4.40、キャッシュ済み入力は約$0.26/100万です。Z.aiが公式レートカードを発行するまでは、概算として扱ってください。

オープンウェイト。 HuggingFaceのMITライセンス（FP8バリアントを含む）。Coding Planローンチからおおよそ1週間以内にリリース予定。本格的なマルチGPUインフラを持つチームのみ現実的です。FP8チェックポイントはラップトッププロジェクトではありません。

Anthropic互換エンドポイントの意味

Coding PlanはAnthropic互換エンドポイントを公開しており、Claude Codeや類似のAnthropic-SDKクライアントが最小限の設定でZ.aiを指すことができます。通常はANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、モデル環境変数のオーバーライドだけです。

実際には、既存のClaude Code設定が3つの環境変数と長いタイムアウトでGLM-5.2を呼び出せます。1Mコンテキストの最初のトークンレイテンシーはClaudeのデフォルトのkillしきい値より明らかに長いため、API_TIMEOUT_MSを適切に設定してください。注意すべき失敗モード：長いエージェントループでのツール結果ブロックのフォーマットがネストされたコンテンツを時々落とし、その症状はアシスタントがツールコールを繰り返すことです。それが起きたら、影響を受けるワークフローを/api/coding/paas/v4のOpenAI互換エンドポイントに切り替えてください。

ボトルネックはモデルではなくブリッジにありました。

コストと本番環境の考慮事項

プロンプトベース vs トークン課金

Coding PlanとスタンドアロンAPIは異なるものに課金します。選択は使用パターンの形状によります。

プロンプトベース（Coding Plan）。 サイクルあたり固定プロンプト数。月次支出が予測可能。人間がエージェント内でコーディングするのに最適。多数の並列エージェントにファンアウトするプログラム的なワークロードには最悪です。サイクル制限をすぐに消費します。

トークン課金（スタンドアロンAPI、ライブ時）。 使った分だけ支払い。バックエンドサービス、バッチジョブ、マルチテナント製品に最適。最も重要なレバーはキャッシュ済み入力レートです。毎ターンツール定義とリポジトリコンテキストを再送するコーディングエージェントの場合、プロンプトキャッシングはプレフィックスの繰り返し部分で80%以上の割引になります。それを含めずにコストをモデル化しないでください。

ヒューリスティック：一人の開発者がモデルをインタラクティブに使う場合、サブスクリプションの方が安い。ユーザーリクエスト時にモデルを呼び出すプロダクトを構築している場合、従量課金APIと積極的なプレフィックスキャッシングが勝ります。クロスオーバーは日次コール量を2倍の範囲内で予測できない点付近です。

パイプラインでのレイテンシー、フォールバック、ルーティング

1Mコンテキストにはレイテンシーコストが伴います。ベンチマークでは見逃しやすいですが、本番環境では非常に顕著です。大型コンテキストコールの最初のトークンレイテンシーは30〜90秒と報告されています（ベンダー報告、負荷によって変動）。長い一時停止を期待するユーザーがいるコーディングエージェントには問題ありません。レスポンシブに感じる必要がある、ユーザー向けのものには問題です。

ルーティングパターン：ウィンドウが大きいからといってすべてをGLM-5.2に送らないこと。リクエストの形状でルーティングします。短いクエリはより速く小さなモデルへ、長コンテキストのコーディングタスクは5.2へ、5.2がキューに入っているか利用不可の場合のフォールバックパスを用意します。

統合された生成レイヤーを使用している場合、5.2をルーティングターゲットとして追加するかどうかは、新しいモデルと同じ問いです：スロットを獲得するか。ほとんどのチームでは、長いリポジトリのコーディングにはYes、それ以外はNoです。

ビルダーにとってGLM-5.2が適合する場所

長いリポジトリと複数ファイルのワークロード

これは GLM-5.2へのルーティングを真に正当化するワークロードです。300K〜500Kトークンのディレクトリをコンテキストに読み込み、コールパスをトレースするか、8つのファイルに触れるリファクタリングを計画するよう依頼します。ウィンドウ全体で一貫性を保つかどうか、確認する唯一の方法は公開デモではなく自分のリポジトリでテストすることです。

ローンチ時のVentureBeatの記事は、5.2をコストの1/6でクローズドフロンティアモデルと競合する長期コーディングとして位置づけています。「テストする価値あり」として読んでください。「デフォルトを切り替える」ではありません。

より小さいまたは速いモデルが良い選択肢の場合

別の場所にルーティングする場合：

短い単一ファイルの編集。1Mウィンドウが無駄になり、小さなモデルの方が速くて安い。
リアルタイムUIレスポンス。最初のトークンレイテンシーが高すぎる。
コンプライアンスのために独立したベンチマークが重要なワークロード。コミュニティが検証済みの実行を公開するまで、ベンダー報告のみ。
安定したワークロードでの純粋な推論コスト最適化。セルフホスト型の小さなモデルや安価なAPIへのキャッシュ済みコールが通常は勝ちます。

この結論には有効期限があります。オープンウェイトモデルは速く更新されます。

FAQ

1Mコンテキストウィンドウは実際のパイプラインルーティングでコストとレイテンシーにどう影響しますか？

ウィンドウ自体はドルベースでは無料です。送信したトークン分だけ支払います。しかし大きなプロンプトは大きな入力コストと長い最初のトークンレイテンシーを意味します。実際の影響：プレフィックスキャッシングがオプションではなく必須になり、ルーティングレイヤーには1Mコンテキストコールが終わる前にkillしないタイムアウトポリシーが必要です。現在の設定が30秒の最初のトークンレイテンシーを前提としているなら、[1m]バリアントはその前提を破ります。

GLM-5.2を既存のマルチモデルルーティング設定に統合する際にどのような課題が現れますか？

一貫して見られる2点。Anthropic互換エンドポイントはほとんどのパターンを変換しますが、長いエージェントループでネストされたツール結果ブロックを時々落とします。OpenAI互換のフォールバックを用意してください。またCoding Planとトークン課金APIは異なる認証情報と異なるエンドポイントを持つため、ルーティングレイヤーは特定のワークロードにどのパスがライブかを知る必要があるか、一方を選んでトレードオフを受け入れる必要があります。

チームはGLM-5.2のコーディング強みが本番環境への移行を正当化しないとどのような場合に判断しますか？

ワークロードが実際に長いコンテキストを必要としない場合。短い、集中した補完を行うチームはマーケティングが示唆するよりも改善が少ないでしょう。もう一つのケース：ステークホルダーの承認に独立したベンチマークがないことがブロッカーになる本番環境です。これはプロセスの問題であり、モデルの問題ではありませんが、現実的な問題です。

GLM-5.2のアクセスがまだプレビューまたはロールアウト中の場合、ビルダーはどのようにフォールバックを処理すべきですか？

スタンドアロンAPIがロールアウト中の間は、GLM-5.2をCoding Plan専用として扱い、トークン課金が有効でコストを適切にサイズ設定できるまで、プログラム的なワークロードを安定した代替手段にルーティングしてください。価格が公開されたレートカードにないエンドポイントに本番依存を移行しないでください。今5.2をテストしているなら、並列パスとして実施してください。トラフィックの一部を送り、出力とコストを比較し、少なくとも2つの請求サイクルの実際のデータが得られるまでフォールバックをライブに保ってください。

結論

GLM-5.2は有用なバージョン増分であり、カテゴリシフトではありません。 1Mコンテキストウィンドウが本当の変更点であり、リポジトリスケールのコーディングワークロードにルーティングスロットを獲得します。それ以外はすべてロールアウト中、ベンダー報告、または独立したベンチマーク待ちです。

すでにGLM-5を本番環境で実行しているなら、移行の問いは狭いです。コンテキスト制限のためにチャンキングされていたワークロードがありますか？あるなら、それらに特化して5.2をテストしてください。なければ、アップグレードは急ぎません。オープンウェイトを待ち、ベンチマークを待ち、トークン課金APIが公式に価格設定されたときに再検討してください。

ルーティング設定に書き込む前に、自分のワークロードで実行してください。それが私の言葉よりも多くを伝えます。

過去の記事：