GLM-5は、Zhipu AI（Z.ai）が2026年2月11日にリリースしたモデルで、GLM-4.7からの大幅なアーキテクチャ的飛躍を示します。より大規模なMoEスケール（総パラメータ ≈744B 対 ~355B）、より高いアクティブパラメータ容量、測定上のハルシネーション低減、そしてエージェント性やコーディング系ベンチマークでの明確な改善が見られます—ただし推論の複雑さと（場合によっては）レイテンシのコストが伴います。
GLM-5とは何か、なぜ重要か？
GLM-5はどのようなモデルか？
GLM-5はZhipu AI（Z.ai）による最新のフロンティア・オープンウェイト大規模言語モデルで、2026年2月11日に公開されました。Mixture-of-Experts（MoE）トランスフォーマーで、GLMファミリを~7440億の総パラメータへスケールしつつ、推論ごとに約400億パラメータを活性化します（つまり、MoEルーティングによりアクティブ計算は総パラメータ数よりもはるかに小さく保たれます）。モデルはMITライセンスで提供され、エージェント型のワークロード—ツールのオーケストレーション、コードの作成と洗練、ドキュメントエンジニアリング、複雑な知識作業などの長時間・多段ステップのタスク—に最適化されています。
以前のGLM系との差分のハイライトは？
主要な変更点の要約：
- パラメータのスケーリング： GLM-5 ≈ 総744B（アクティブ40B）対 GLM-4.7の ~総355B / アクティブ32B — モデルスケールが約2倍に。
- ベンチマークとファクト性： 独立ベンチマークで大幅な向上（Artificial Analysis Intelligence Index：GLM-5 = 50 対 GLM-4.7 = 42）、AA Omniscience指標におけるハルシネーションの大幅削減（GLM-4.7比で56ポイントの削減が報告）。
- エージェント能力： ツール呼び出し、計画分解、長期実行の信頼性が向上（Z.aiはGLM-5を“agentic engineering”向けに位置づけ）。
- デプロイとチップ： 中国国内の推論ハードウェア（Huawei Ascendほか）での動作に合わせて構築・ベンチマークされ、Z.aiの多様なチップスタックへの移行を反映。
なぜ重要か：GLM-5はエージェント性や知識タスクにおいて、オープンウェイトとプロプライエタリなフロンティアモデルの差を縮めます—制御可能なデプロイとライセンス柔軟性を必要とする企業に、高性能なオープンソースモデルという現実的選択肢を提供します。
GLM-5の新機能（詳細）
ポジショニング：“Agentic engineering”のスケール化
GLM-5はZ.aiにより「agentic engineering」向けモデルとして明確に位置づけられています。これは、モデルが計画し、ツール呼び出しを行い、結果を検査し、多段に自律的に反復するユースケース（例：CIパイプラインの構築、失敗したテストスイートのトリアージと修正、マイクロサービスの連携など）です。単一ターンのコード生成から、実行トレースやツール出力を横断して動作・推論するモデルへ戦略的にシフトしています。
Thinkingモード、保存／インタリーブされた推論
GLM-5は洗練された「思考」モード（ドキュメントではinterleaved thinking、preserved thinkingと記載されることがある）を導入し、モデルが内部の推論トレースを出力し、後続のターンやツール呼び出しで再利用できるようにします。実務的には、長いワークフローでの再導出コストを削減し、ツール結果を跨いで計画状態を保持すべきエージェントの一貫性を高めます。GLM-4.7は初期の思考バリアントやツール対応の振る舞いを導入しましたが、GLM-5はそのメカニクスと学習レシピを洗練し、トレースをより信頼でき再利用可能にしています。
長コンテキスト設計とシステム安定性
GLM-5の学習とファインチューニングでは、非常に長いコンテキストでの生成を明示的にテストしています（SFT/評価で202,752トークン）。複数のリポジトリ、テストログ、オーケストレーション出力を1つのプロンプトで見せる必要がある場合に意味のある実務的な増加です。評価設定では、一部の推論ワークロードで生成長を131,072トークンまで押し上げています。巨大なコンテキスト条件付け時の不安定性を緩和するための顕著なエンジニアリング努力です。
アーキテクチャとスケーリング（MoE）
公開情報によれば、GLM-5は総数百億パラメータ規模の大規模MoE（Mixture-of-Experts）アーキテクチャを採用しています（公開集計では ~744–745B）。GLM-4.7には、異なるデプロイのトレードオフに合わせたMoEとFlashバリアントがあり（例えば、ローカルや低コスト推論向けにアクティブパラメータを小さくした「Flash」バリアント）、MoE設計によりピーク能力を押し上げつつ、（より低いアクティブパラメータで）推論を安価にする構成選択が可能です。デプロイするバリアントに応じて推論プロファイル（レイテンシ、VRAM）が異なることを想定してください。
Z.aiはGLM-4.7と比べてGLM-5をどのように拡張・学習したか？
主要なアーキテクチャ差分
| 項目 | GLM-5 | GLM-4.7 |
|---|---|---|
| リリース日 | 2026年2月（フラッグシップ） | 2025年12月 |
| モデルファミリ | 最新世代 | 前世代 |
| 総パラメータ数 | ~744B | ~355B |
| アクティブパラメータ（MoE） | ~40B（フォワードパス毎） | ~32B（フォワードパス毎） |
| アーキテクチャ | Mixture-of-Experts＋スパースアテンション | Thinkingモードを備えたMoE |
| コンテキストウィンドウ | ~200Kトークン（同じベースサイズ） | ~200Kトークン |
要点： GLM-5はGLM-4.7比で総容量をほぼ倍増し、アクティブパラメータを増加。特に長文の技術コンテンツ、拡張された推論パイプライン、複雑なコードエンジニアリングタスクで、より良い推論と統合能力に寄与します。
アーキテクチャ：何が変わったか？
GLM-4.7は大型バリアントでMoE設計（総約355Bパラメータ、トークン毎のアクティブセットは小さく効率的）を採用しています。GLM-5はMoEスタイルのスパース性の考え方を維持しつつ、新たなスパースアテンション機構—レポートでは**DeepSeek Sparse Attention（DSA）**と呼ばれる—を重ねています。DSAは重要と判断したトークンに動的にアテンション資源を割り当て、長コンテキスト推論を維持（または改善）しながら推論／学習コストを低減する、と主張されています。これにより、従来のチェックポイントよりもはるかに長いコンテキストを扱いつつ、計算を管理可能に保ちます。
スケール：パラメータとデータ
- GLM-4.7： 主MoE版は約3550億総パラメータ（フォワードパスごとのアクティブセットは小さく効率的）。
- GLM-5： ~7440億パラメータが報告され、事前学習予算として~28.5兆トークンで学習。コードとエージェント的なシーケンスに重点が置かれています。この組み合わせは、コード合成と持続的なエージェント計画を改善する意図です。
パラメータのジャンプに加え、トークン予算の拡張とアーキテクチャ更新が、コードとエージェント系リーダーボードで数値的結果が良くなっている主因です。
学習戦略とポストトレーニング（RL）
GLM-4.7が多段推論やツール使用を改善するための「インタリーブ」や保持された思考モードを導入したのに対し、GLM-5は以下のパイプラインでそれを制度化しています：
- コンテキスト長の拡張を中期学習スケジュールで実施（200Kトークンまで段階的に拡張したと報告）。
- 逐次的なRLポストトレーニングパイプライン（Reasoning RL → Agentic RL → General RL）をオンポリシーのクロスステージ蒸留と組み合わせ、破滅的忘却を回避。
- 非同期RLと分離されたロールアウトエンジンを導入し、同期ボトルネックなしにRL中のエージェント軌跡をスケール。
これらの手法は、長期的なエージェント行動の改善を狙ったもの—例えば、複数の依存ツール呼び出しとコード編集を行う長いセッションでも内部状態を安定して維持する—です。
パフォーマンスと能力の比較：GLM-5 vs GLM-4.7
ベンチマークとインテリジェンス指標
| 評価領域 | GLM-5 | GLM-4.7 |
|---|---|---|
| コーディング（SWE-bench） | ~77.8%（オープンモデルのSOTA） | ~73.8%（SWE-bench Verified） |
| ツール＆CLIタスク | ~56%（Terminal Bench 2.0） | ~41%（Terminal Bench 2.0） |
| 推論（HLE＆拡張） | ~30.5 → ~~50（ツール使用時、社内ベンチマーク） | ~24.8 → ~42.8（HLE、ツール使用時） |
| エージェント＆多段タスク | 明確に強化（より長いチェーン） | 強力（Thinkingモード）だがGLM-5ほど深くはない |
解釈：
- GLM-5はGLM-4.7を広範に上回り、中核的なコーディングと推論ベンチマークで有意な差を示します。特に多段自動化、問題分解、深い論理タスクで顕著です。
- 改善は非自明：例としてTerminal Bench能力は ~41%から56%へジャンプし、エージェント自動化の信頼性が相対的に大きく向上。
- 推論テスト（HLEなど）では、GLM-5は生の推論とツール併用時の出力がより強力。
- 実務的エージェントテストでも測定可能な向上：CC-Bench-V2のフロントエンドHTML ISR指標ではGLM-5が38.9%、GLM-4.7は35.4%（フロントエンドタスクのサブセットでの自動評価指標の一つ）。
コンテキストサイズと長文タスク
- 両モデルとも**大きなコンテキスト（~200kトークン）**をサポート—つまり、より長いドキュメント、コードベース、対話を取り込み推論可能。
- 実務報告では、一部プラットフォームでGLM-5のデプロイが体感的にコンテキスト管理の問題を示すケースもあるようですが、これはホスト側の制約を反映している可能性があり、モデル設計そのものを示すものではないかもしれません。
ツール＆関数呼び出し
両モデルとも構造化された関数／ツール呼び出しをサポートします。GLM-5は特に分岐が多い拡張的なスクリプトロジックをより高い忠実度で実行します。
例：タスクにおける出力品質の違い
コーディング例（概念）
- GLM-4.7： 構文が正しく読みやすい、単一ファイルのスクリプトを有能に生成。
- GLM-5： 複数ファイルのコード生成、深いデバッグ提案、最小限のコンテキスト切り捨てでの長いフィードバックループに秀でる。
推論＆計画
- GLM-4.7： 多段推論は得意だが、非常に深い推論チェーンでは時折停滞。
- GLM-5： 推論の分割、過去ステップの想起、長いチェーンのナビゲーションが改善—データ統合や多領域戦略に有用。
GLM-4.7からGLM-5へ移行した場合のレイテンシとコストの変化
レイテンシのトレードオフとGLM-4.7が依然優れる場面
短いメッセージ＆軽快なUI： 実務者のベンチマークでは、GLM-5は短い応答に小さな固定オーバーヘッド（ルーティングやエキスパート選択の管理）が加わり、極小ペイロードではわずかにレイテンシが高く見えることがあります。超低レイテンシの短メッセージUIでは、GLM-4.7やFlashバリアントが依然魅力的です。
GLM-4.7とGLM-5の比較：
- GLM-4.7： 入力 $0.60/1M tokens、出力 $2.20/1M tokens。
- GLM-5： 入力 $1.00/1M tokens、出力 $3.20/1M tokens。
コストと人手による編集のトレードオフ
モデル価格が高くても、GLM-5が下流の人手時間（例：マージリクエストの編集、修正のトリアージ、モデル呼び出しの反復回避）を有意に減らすなら正当化されます。簡単な意思決定ルール：
GLM-5が手作業の編集時間をX%以上削減するなら（Xは人件費とワークフローのトークン量に依存）、トークン単価が高くても費用対効果が見込めます。複数のブログ分析では、ブレークイーブン条件をモデル化した結果、GLM-5は大規模な反復エージェントワークフロー（例：自動コード修復のスケール運用）でしばしば採算が取れるとしています。
レイテンシとハードウェア
推論時のVRAMとレイテンシはバリアント（Flash、FlashX、フルMoE）に依存します。コミュニティガイドでは、GLM-4.7のFlashXや30B Flashバリアントが24GB GPUでデプロイ可能、フルMoEバリアントは大型のマルチGPU構成を必要とするとされています。GLM-5のフル構成は同等スループットのために実質的により高いリソースを期待しますが、MoEのスパース性はトークン毎のアクティブ計算を減らす助けになります。プロダクションでは量子化、メモリマッピング、ストリーミングのチューニングへのエンジニアリング投資を見込んでください。
いつGLM-4.7からGLM-5へアップグレードすべきか？
アップグレードすべき場合：
- 複数ファイルのコード推論、長コンテキストのエージェントオーケストレーション、より高いエンドツーエンドのエージェント成功率が必要。
- タスクの価値が高く、より高いリクエスト単価のインフラ複雑性とコストが正当化される。
GLM-4.7を継続すべき場合：
- ワークロードが高ボリュームの短プロンプト（分類、タグ付け）で、コストとレイテンシの予測可能性が質の漸進的向上より重要。
- GLM-4.7を選好するユースケース
- 高スループットの短ペイロード： チャットボット、オートサジェスト、短い言い換え—GLM-4.7（特にFlashバリアント）がしばしば安価で低レイテンシ。
- 予算制約下の大量タスク： タグ付け、分類、スケールで実行する小タスクでは、GLM-4.7の効率と低いトークン単価が魅力的。
- MoEのシャーディング／複雑なオートスケーリングに対応するインフラや予算がない。
API呼び出しでモデルを選ぶには？（例）
cURL — モデルIDを切り替える（CometAPI / OpenAI互換の例）:
# GLM-4.7
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-4.7","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":800}'
# GLM-5
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-5","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":1200}'
Python（requests）：model フィールドを変更してGLM-4.7またはGLM-5にルーティングします。他のクライアントコードはそのままで構いません。
最終評価：
GLM-5は進化的であり、重要な変曲点を伴います：
- 進化的：GLMファミリのMoEと推論重視の設計を踏襲し、（4.5 → 4.6 → 4.7 → 5）という反復改善の流れを継続。
- 変曲点：スケールの拡大、DSAの導入、長期的エージェントタスクに特化したRLカリキュラムへのコミット—これらが広範な実務ベンチマークで意味のある、測定可能な改善を生みます。
リーダーボードの順位だけで評価するなら、GLM-5は複数指標でオープンウェイトのリーダーシップを主張し、エージェント性やコーディングタスクでトップのプロプライエタリシステムとのギャップを縮めます。開発者体験やレイテンシ敏感な用途で評価するなら、実運用の大規模デプロイを通じた実務的な長所短所の検証は今後も必要です。つまり、GLM-5は持続的なエージェント能力が要求されるユースケースで魅力的であり、GLM-4.7は今日の多くのプロダクションニーズに対して成熟しており、より高速でコストに優れた選択肢です。
開発者は GLM-5 と GLM-4.7 に CometAPI 経由で今すぐアクセスできます。まずは Playground でモデルの機能を試し、詳細は API guide を参照してください。アクセス前に、CometAPIへログインしてAPIキーを取得してください。CometAPI は公式価格より大幅に低い価格を提供し、統合を支援します。
準備はいいですか？→ 今すぐGLM-5に登録！