
ZCodeの実態
私はeeselでインテグレーションやエージェントの内部配線を作っている。だから新しいエージェント型ツールが登場すると、キャッチコピーではなく、マーケティングの裏でそのエージェントが実際に何をしているのかを読み解くようにしている。ZCodeには読み解くべき材料がたくさんある。
ZCodeは既存のエディタに後付けしたチャットサイドバーではなく、デスクトップアプリだ。Z.ai(旧Zhipu AIとして知られていた研究所)はこれを「エージェント型開発環境」と呼んでおり、その表現は的を射ている。今書いている行を自動補完するのではなく、タスク全体を引き受ける仕組みだからだ。やりたいことを説明すると、エージェントがリポジトリを調査し、複数のファイルにまたがって書き込み、シェルコマンドを実行し、自分の作業内容を確認したうえで、取り消しボタン付きの差分を提示してくれる。リリース時のチェンジログのバナーには「ZCode 3.0: GLM-5.2 optimized」と書かれていたが、インストーラーはすでにバージョン3.3.3になっており、かなりの速さで反復が進んでいる。

何もない状態の画面からも多くのことが読み取れる。タスクを入力するコンポーザー(「Ask ZCode, type @ to add files, / for commands, $ for skills」)、少し落ち着かないオレンジ色のFull Access権限トグル、Gitのブランチピッカー、そしてGLM-5.2のMaxエフォートに固定されたモデルセレクターがある。全体が垂直統合されており、エージェント、GLM-5.2モデル、サブスクリプションのすべてが同じ会社から提供されている。これはClaude Codeのようなモデル非依存のハーネスとは実質的に異なる点であり、その違いは良くも悪くも作用する。これについては後で改めて触れる。
バイブコーディングの潮流を追ってきた人や、私が書いたエージェント型コーディングCLIの入門記事を読んだ人にとって、ZCodeはその考え方をネイティブGUIに落とし込んだものだと言える。「プロンプトを入力してスニペットを得る」というより、「タスクを丸ごと任せて結果をレビューする」という発想に近い。
背後にあるモデル:GLM-5.2
ZCodeは、それが前提として構築されているモデルであるGLM-5.2と切り離しては語れない。Z.aiは2026年6月16日にGLM-5.2をリリースし、HuggingFaceとModelScopeでMITオープンソースライセンスの下でウェイトを公開した。コンテキストウィンドウは100万トークンで、GLM-5.1の20万から大幅に拡大している。Z.aiは、大きなコンテキスト数値は主張するのは簡単でも、実際に信頼性を保つのは難しいと率直に認めており、ベンチマークのスクリーンショット映えではなく、長く混沌としたコーディングの軌跡そのものに特化して学習させたと述べている。
見出しとなる主張は、同程度のトークン予算においてGLM-5.2のエージェント型コーディング性能が「おおよそClaude Opus 4.7とClaude Opus 4.8の中間」にあるというものだ。長期タスクの評価もこの主張を裏付けている。FrontierSWE(数時間から数十時間規模のオープンエンドなプロジェクト)では、GLM-5.2は74.4点を記録し、75.1点のOpus 4.8に約1%差で及ばず、72.6点のGPT-5.5は上回っている。

頭に入れておくべき注意点が2つある。まず、これらはZ.ai自身によるベンチマークであり、どのベンダーのチャートを読むときとも同じ注意を払う必要がある。次に、すべてのベンチマークに共通する結論は同じだ。GLM-5.2はオープンウェイトモデルとしてはトップだが、クローズドなフロンティアモデル(主にOpus 4.8、いくつかのベンチマークではGPT-5.5)には依然として明確に及ばない。超長時間タスクのSWE-Marathonでは、Opus 4.8の26.0点に対してGLM-5.2は13.0点にとどまり、タスクが長くなるほど差が広がっている。仕事に合うモデル選びがボトルネックになっているなら、私のモデル選択に関するノートと文章作成に最適なLLMの記事で、別の角度から同じトレードオフを扱っている。
私が見つけた中で最も説得力のある外部の評価は、率直にこう述べている。
「総合的に見て、Opus 4.8は依然としてより優れ、より信頼性が高く、より速いモデルだと思う。でも、もし明日それが消えてGLM 5.2しか使えなくなったとしても、そこまで落ち込まないだろう。GLM 5.2でも十分に物事を進められるはずだ。」
私自身もだいたい同じ結論に落ち着く。GLM-5.2は本物の、実用に耐えるフロンティア級に近いモデルであり、それがオープンウェイトであるという事実は大きな意味を持つ。ただし、巨人を倒すほどの存在ではない。
ZCodeの仕組み:ゴール、ボット、そして一枚岩のスタック
ZCodeの体験を決定づける要素は3つあり、そこにこのプロダクトの最も強い主張が表れている。
長時間タスクのための「ゴール」
作業の中核単位は「ゴール」だ。単発の補完ではなく、複数ステップからなる目標をZCodeに渡すと、それに対して継続的な計画・実行・検証を行う。デモに映るタスクの所要時間は2分から丸1日までさまざまだ。ホームページに掲載されているエージェントのログでは、まずリポジトリを調査し、index.html、app.js、styles.cssを一気に書き上げ、その後node --check app.jsを実行してタスク完了を宣言する前に自分の出力を検証している。この自己確認のステップこそが重要な部分だ。コードを書いて一度も実行しないエージェントは、単に少し洒落た自動補完にすぎない。

ゴールが裏側で何をしているのか、その概念的な仕組みを知りたければ、別記事でエージェントループについてまとめている。これと従来型のボットとの違いは、以前私がAIエージェントとルールベースのチャットボットの違いとして説明したものと同じだ。
チャットアプリからのボット操作
これは欧米のコーディングツールにはほぼ見られない機能だ。WeChat、Feishu、TelegramからZCodeのタスクを開始し、操作することができる。スマートフォンからボットに@メンションすれば、デスクトップから離れていても長時間タスクは動き続ける。良いアイデアではあるが、リリースページがLinuxベータへの参加のためにFeishuの招待を前面に押し出している点は、このプロダクトの主な想定ユーザー層がどこにあるかをさりげなく物語っている。

一枚岩の垂直統合スタック
ここに戦略的な選択がある。Claude Codeは基本的に、さまざまなモデルを指定できるハーネスだ。ZCodeはその逆で、エージェント、GLM-5.2モデル、GLM Coding Planのサブスクリプションが、Z.aiいわく「一緒にチューニングされた」一気通貫の自社完結スタックになっている。Anthropic、DeepSeek、Kimi、OpenRouterの自前のAPIキーを持ち込むことはできるが、GLM-5.2がデフォルトであり、すべてがそれに合わせて最適化されている。

垂直統合スタックの利点はチューニングにある。モデルとハーネスが互いを理解し合っているということだ。一方でその欠点はコミュニティですぐに表面化した。GLM-5.2はすでに既存のツールの中でも問題なく動くのに、なぜ専用のハーネスが必要なのかと疑問視する声が少なくなかったのだ。
「GLM-5.2は素晴らしいモデルだ!でも既存のハーネスでもすでに十分うまく動いている。専用のものがなぜ必要なのか、正直よくわからない。」
もっともな疑問であり、自分のワークフローを単一ベンダーのアプリに委ねる前に、じっくり考える価値のある問いだ。
ZCodeの料金
アプリ自体は無料だ。しかしその背後にあるモデルは無料ではない。GLM-5.2を動かすにはGLM Coding Planが必要で、プラン自体に無料枠は存在しない。
| プラン | 月額の通常料金 | 長期契約の場合(年払い、-30%) | 内容 |
|---|---|---|---|
| Lite | $18/mo | $12.60/mo ($151.20/yr) | 基本利用枠;小規模リポジトリでの作業;Claude Codeを含む20以上のコーディングツール |
| Pro(人気) | $72/mo | $50.40/mo ($604.80/yr) | Liteの内容すべて + Lite比5倍の利用枠;厳選されたMCPツール;生成速度の向上 |
| Max | $160/mo | $112/mo ($1,344/yr) | Proの内容すべて + Lite比20倍の利用枠;新モデルへの先行アクセス;ピーク時のリソース優先 |
Z.aiは月払いで-10%、四半期払いで-20%、年払いで-30%の割引を適用しており、1年間契約すれば同じプランでも月額12.60〜112ドルまで下がる。(他の場所で16.20〜144ドルという表記を見かけるかもしれないが、これは同じ価格を月払い表示にしたものであり、別のプランではない。)
ここで、これを予算に組み込もうとする人全員に指摘しておきたい点がある。各プランは、Z.aiが実際には一切公表していない基本利用枠の倍数として販売されている。Proは「Lite比5倍」、Maxは「Lite比20倍」とされ、Liteは「基本利用枠込み」とだけ書かれ、具体的な数字は付いていない。料金ページには「プランの利用上限はどれくらいですか?」というFAQ項目まで用意されているが、私が確認した時点ではそれは折りたたまれたままだった。

リリース週のあるコメントが、この苛立ちを私よりもうまく言い表していた。
「これだけ多くの企業が『基本利用枠込み』という表現で押し通せているのは驚きだ[...]上位プランをその『基本』の倍数として積み上げておきながら、その中身を一切開示していない。」
もう一つ重要なのは、GLM-5.2はタスクあたりの実行コストが安くないという点だ。Z.ai自身のエフォートレベル別チャートによれば、GLM-5.2がOpusに近いスコアに達するのは、タスクあたりの出力トークンをはるかに多く消費することで初めて実現されており、クォータメーターは北京時間のピーク時に利用量を3倍、オフピーク時には2倍としてカウントする。

ベンダーが誰も値段を計算できない単位で「自律性」を売っているのを目にするのは、私にとって見慣れた光景だ。eeselが解決済みチケット単位で料金を設定しているのも同じ理由からで、これは不透明な「クレジット」ではなく、実際に予測可能な単位だ。何らかのAI予算を見積もっているなら、AIサポートエージェントのコストについての記事で、サポート領域における同じ落とし穴を詳しく解説している。
実際に語られていること
ZCodeのリリース週は騒がしく、その評価は有益な形で分かれていた。いくつかのテーマが繰り返し取り上げられた。
見た目はCodexにそっくり。 「GLMの開発元によるClaude Code」という触れ込みにもかかわらず、UIはむしろOpenAIのCodexに近いという声が複数の人から上がった。
「手のアイコンも、テキストフィールドの使い方も、サイドバーのスタイルも、Codexと1対1でそっくりだ。この触れ込みは誤解を招く。Claude Codeに近いとは言えない。」
不安定でトークンを大量消費する。 実務上最も多く挙がった不満は、信頼性とトークン消費についてだった。
「APIがあまりに不安定で、各リクエストを最低でも3回はやり直さなければならない。しかもCoding Planのmaxプランに入っていても、こいつはCodexの200ドルプランやClaudeの200ドルプランに比べて、少なくとも5倍速いペースでトークンを消費する。」
そして消えることのない信頼の問題がある。 中国の研究所が開発した、フルのシステムアクセスを求めるプロプライエタリなエージェントというのは、ベンチマークがどうであれ、一定数の開発者にとっては受け入れがたいものだ。
「システムの完全な制御権を持つ、中国製のプロプライエタリなソフトウェアを、何か重要なものの上で動かすことは絶対にない。これは間違いなく、真剣な作業ではなく、おもちゃのプロジェクト用にラボ環境でサンドボックス化してのみ実行するようなものだ。」
こうした声は、GLM-5.2が悪いモデルであることを意味するわけではない。それが示しているのは、アプリとしてのZCodeがバージョン3.x台の、粗削りな部分を残したプロダクトだということであり、リリースから2週間ならまさに想定通りの姿だ。コーディングエージェントにこの種のアクセス範囲を与えるつもりなら、Claude Codeの権限管理についての私のノートが、「フルアクセス」が本来何を意味すべきかを確認する良い材料になる。
本当の教訓:自律性にはハーネスが必要だ
私が何度も立ち返る点があり、それは一つのコーディングアプリの話にとどまらない。自律的なエージェントは、それを取り巻くハーネス次第でしか信頼できない。
ZCodeの設計上の最良の判断は、自律性そのものではなく、ガードレールにある。機密性の高いコマンドや高権限の操作を実行する前には確認ステップが必須になっている。そのエージェントは、成功を宣言する前に実際のコマンドで自己検証を行う。「Full Access」トグルはデフォルトではなく、意図的で目に見える選択として設計されている。これらを取り除けば、マシンのroot権限を持ちながらブレーキのない非常に高性能なモデルが残るだけであり、それこそがスレッドの中で懐疑派が懸念していたことに他ならない。

これは私にとってむしろ安心材料だ。なぜならそれは、サポート向けにAIを構築する中で私自身がたどり着いた結論とまったく同じだからだ。私はこの3年余り、実際の顧客キューにAIエージェントを投入し続けてきたが、最初の痛みを伴う教訓は、自信満々に聞こえるボットが実際の顧客に間違った回答をするのを目の当たりにしたことだった。関数をハルシネーションするコーディングエージェントは、元に戻せるビルドを壊すだけだ。しかし返金ポリシーをハルシネーションするサポートエージェントは、元には戻せない信頼を壊してしまう。だからこそ業界全体が、ZCodeも含めて、同じ形に収斂しつつある。エージェントに作業する余地を与えつつ、取り返しのつかないあらゆる操作の手前にチェックポイントを置き、野放しにする前にそれがうまく機能することを証明するという形だ。
サポートに限って言えば、そのハーネスは3つの要素からなる。返信が送られる前のレビューのステップ、エージェントが自信を持てないときの明確なエスカレーション経路、そして推測に頼るのではなく封じ込め率と品質を測定する方法だ。自律性そのものは、もはや簡単な部分にすぎない。ハーネスこそがプロダクトなのだ。
eeselを試す
ZCodeを見ながら「こういうエージェントが自分のサポートキュー向けにも欲しい」と思っているなら、それはまさに私が作っているものだ。eeselはあなたのヘルプデスクのためのAIチームメイトだ。Zendesk、Freshdesk、Gorgias、HubSpot、Frontと連携し、導入初日から過去のチケットとヘルプドキュメントから学習し、一次対応の会話を下書きしたり、完全に解決したりする。

その違いを生んでいるのは、前のセクションで説明したのと同じハーネスの発想だ。eeselが一人の顧客に返信する前に、シミュレーションモードがエージェントを実際の過去のチケット数千件に対して走らせるので、実際にどう答えていたか、どれだけ解決できていたかを正確に把握でき、本番投入前にギャップを修正できる。最初は監督付きで下書きのみを行い、信頼できると判断した簡単なチケットから自律性を与えていく仕組みで、信頼度に基づくルーティングにより、確信度の低い質問は間違った回答ではなく下書きになる。実際のチームが本番規模で運用している例もある。Gridwiseはeeselによって初月で一次対応リクエストの73%を解決した。eeselは無料で試すことができ、不透明なクレジットではなく、解決済みチケット単位で料金が設定されている。
よくある質問
ZCodeとは何ですか?
ZCodeは無料ですか。GLM Coding Planの料金はいくらですか?
GLM-5.2はオープンソースですか?
ZCodeはClaude CodeやCursorより優れていますか?
ZCodeで自分のモデルを使うことはできますか?
同じエージェント型のアプローチはカスタマーサポートにも通用しますか?

Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.







