ZCode を運用者目線で読む — GLM-5.2 の公式ハーネスとロックインの綱引き

ZCode は「モデルを作った会社が自前で出したコーディング・ハーネス」

結論から書くと、ZCode は GLM-5.2 を作った Z.ai(旧 Zhipu、中国の LLM ベンダ)が、その GLM-5.2 に最適化して出した公式のコーディング・エージェント・ハーネスです。ライブラリや SDK ではなく、macOS / Windows / Linux で動くデスクトップ IDE の形をしています。バージョンは 2026 年 4 月時点で 3.2.2 でした。

ここで言うハーネス(harness、エージェントを回す土台)とは、モデルにコードを書かせるだけでなく、計画を立て、実装し、テストで検証し、そのループを長時間回し続ける仕組みのことです。Claude Code や各社のコーディングエージェントと同じ土俵にある製品、と考えると位置づけがつかめます。

面白いのは提供元です。ZCode は Anthropic ではなく Z.ai の製品で、GLM-5.2 という自社モデルに深く結び付いています。「モデルを作った会社が、そのモデル専用のハーネスまで自前で出す」という構図そのものが、運用者にとっての論点になります。

何ができるのか — Goals と遠隔ステアリング

ZCode の核は「Goals」という考え方で、一つのゴールを与えると計画・実行・検証を継続的に回し、長時間タスクを走らせ続けます。ここが単発の補完ツールと違うところです。

公式の説明では、リポジトリ規模のコンテキストを保持し、20 種類以上のコーディングツールを GLM-5.2 に統合しているとされています。つまり「1 ファイルを直す」ではなく「リポジトリ全体を見ながら、計画→実装→検証を自分で回す」方向に振ってある。検証(verification、書いたコードを動かして確かめる工程)がループに組み込まれている点は、個人的にいちばんの見どころだと思っています。書きっぱなしではなく、動かして確かめてから次へ進む設計は、エージェントを放置運転するときの事故を減らします。

もう一つの特徴が遠隔ステアリングです。WeChat / Feishu / Telegram といったチャットアプリから、走っているタスクに指示を送れる。デスクの前を離れても、スマホから「その方針でいい」「そこは止めて」と口を挟める、という発想です。長時間タスクを回す前提だからこそ出てくる機能で、なるほどと思いました。(余談ですが、私はビルドの完了を Slack 通知で待つ癖があるので、この「途中で口を挟める」方向は感覚として腑に落ちます。)

料金 — 3 段サブスクの読み方

料金は月額サブスクで 3 段構成です。数字だけ先に置きます。

プラン	月額	目安
Lite	$16.2	軽い反復向け(Lite usage 20 単位)
Pro	$64.8	Lite の 5 倍の usage + 選抜された MCP ツール
Max	$144	Lite の 20 倍の usage + ピーク時の専有リソース

どのプランでも最新のフラッグシップモデルへ順次アクセスできる、とされています。ここで注意したいのは「usage 単位」が何を指すのかが外からは読みにくいことです。トークン数なのかリクエスト数なのか、実測してみないと Claude Code 系の従量課金や定額プランと横並びで比べられません。私が料金表を見て最初にやるのは、いちばん安い Lite で 1 週間だけ自分の実作業を流し、単位の消え方を実測することです。カタログの数字より、自分のワークロードでの消費速度のほうが判断材料になります。コストを設計で抑える発想は LLM API のコスト暴走を「呼ばない」で防ぐ でも書いたとおりで、まず自分の消費を測るところから始めます。

モデル提供者が自前ハーネスを出す構図 — 最適化とロックインの綱引き

ZCode がいちばん示しているのは、機能そのものより「モデルを作った会社が、そのモデル専用のハーネスまで垂直統合する」流れです。これは最適化とロックインの綱引きになります。

良い面は分かりやすい。ハーネスとモデルが同じ会社なので、GLM-5.2 の癖に合わせてツール呼び出しや検証ループを調整でき、他社の汎用ツール + そのモデル、という組み合わせより噛み合いやすい。Microsoft が自社の MAI-Code-1-Flash を出したときと同じで、モデルとツールを一体で設計できる強みです。

一方で、ハーネスとモデルと課金が 1 社に束ねられると、乗り換えコストは上がります。ワークフローを ZCode の Goals に最適化するほど、GLM-5.2 から離れにくくなる。以前 Claude Fable 5 / Mythos 5 が突然止まった日 で書いたように、単一プロバイダに依存した構成は、その 1 社が止まった瞬間に自分の作業も止まります。ツールチェーンの独立性という論点は VoidZero が Cloudflare に参画した件 とも地続きです。便利さは、たいてい囲い込みと同じ方向を向いています。

運用者として、どう付き合うか

運用の結論はシンプルで、試すのは歓迎、ただし業務のクリティカルパスは単一プロバイダのハーネスに預けない、です。

具体的には三つあります。第一に、モデルに依存しない層(プロンプトの資産、テスト、CI、リポジトリ構造)を ZCode の外に持っておくこと。ハーネスを乗り換えても、この層が残っていれば移植は効きます。第二に、Goals のような自動ループを回すなら、検証と撤退の条件を自分側で決めておくこと。コーディングエージェントに 18 万行書かせて見えた限界 で触れたとおり、長時間タスクは「どこで止めるか」を決めておかないと、静かに膨らみます。第三に、料金は必ず実測してから本採用すること。

私は新しいハーネスを見ると、まず一番安いプランで捨てても惜しくない小さなタスクを流します。そこで検証ループの精度と usage の消え方を見て、業務の土台に置くかどうかを決める。ZCode も同じで、GLM-5.2 の実力とセットで、便利さと移植性を天秤にかけます。便利さを取りにいくなら、乗り換え経路を残したまま取りにいく。それだけの話です。