私はかなり「実戦派」のAIユーザーだ。オンライン講座で学ぶタイプではなく、日々の実務で code、docs 作成、debug にAIを使っている。ある日、Code Arena leaderboard を目にした。GLM-4.7 は順位2位、Claude Opus 4.5 に肉薄し、しかも GPT-5.2 を上回っている。スコアは1449。Opusとの差はわずか31ポイント。正直、かなり印象的だった。
その時は急ぎではなかったが、この名前は頭の片隅に残った。
そしてある週末、普段使っている model の request 制限を使い切ってしまった。仕事はまだ残っている。そんな時、GLM という名前が…まるで救命浮き輪のように浮かび上がった。
Z.AIに辿り着く
私は Z.AI ― GLM を提供している platform ― を調べ始め、彼らがとても洗練された「セールスファネル」を構築していることに気づいた。あるいは単に、私が彼らの想定ユーザーど真ん中だっただけかもしれない。
価格 がまず目に入った。Z.AI の Coding Plan は、Claude Pro や GPT Plus よりも明らかに安い。しかし安いだけではない。課金方式が賢い。他の platform は token 数や request 数で課金するが、Z.AI は 同時接続数 で課金する。一度に1接続しか使わないなら、いくら質問しても問題ない。これは marketing team ではなく、developer の発想だ。
ドキュメント も非常によくできている。VS Code、JetBrains IDEs、Vim、Neovim、さらには Emacs まで統合ガイドがある。サンプル、クイックスタート、トラブルシューティングも揃っている。ここで私は感じた。「この会社は、本気でユーザーを成功させたいと思っている」。
その後、YouTube、Reddit、developer forum を覗いてみた。出てくるのは興奮気味の動画ばかりだ。「GLM 4.7 => RIP Opus」「Finally, a Claude Killer」「Better than GPT for coding」。少し大げさな主張もあるが、コミュニティ全体が一斉に称賛していると、無視するのは難しい。FOMO が静かに忍び寄ってくる。「今試さなければ、乗り遅れるかもしれない」。
低価格 + 賢い課金 + 良質なドキュメント + 盛り上がるコミュニティ + 最新版。こうして、私の決断は驚くほど…簡単になった。
登録、セットアップ、そして…いくつか興味深いことが起きた
1つ目：速度 ― 何かが想像と違う
GLM 4.7 を初めて使った時、私は思った。「あれ…思ったより遅い？」
code を貼り、質問を投げて、そして…待つ。demo video のような「即レス」ではない。かなり長く考えている ― 少なくとも、とても深く考えているように見える。
面白いことに、私はこの待ち時間を活用し始めた。メールを確認したり、ドキュメントを読んだり、別の code を直したり。結果的に、私のマルチタスク能力は…なぜか向上した。
もちろん、これは「機能」ではない。ただの自己正当化だ。でも皮肉な話だ。性能を売りにする model が、その遅さ ゆえに 私に時間管理を教えてくれたのだから。
2つ目：GLM 4.6v ― 「慎重」が行き過ぎるとき
GLM 4.7 は image をサポートしていない。そこで私は GLM 4.6v ― 旧 version だが image 対応の model ― を試した。
そして…少し特殊な体験をした。
image を元に task list を更新してほしいと頼んだところ、model はこう動いた。
- task list を読む
- 「task list を更新して次のステップに進みます」
- task list を 再度 読む
- 「task list を更新して次のステップに進みます」 ← 同じ
- task list を もう一度 読む
- 「task list を更新して次のステップに進みます」 ← まだ同じ
私は画面を見つめ、少し混乱した。これは…loop？
さらに待った。コーヒーを淹れに行った。戻ってきた。まだ loop している。
約5分後、私は chat を強制的に止め、新しい chat を作り直した。古い chat に何を書いても、この loop が再開される。
幸い、GLM 4.7 ではこの問題は大きく改善されている。
何が起きたのか？ GLM 4.6v は、おそらく極端に慎重になるよう tuning されていたのだろう。二度、三度、何度も確認してからでないと行動しない。意図は良いが、実装が…やり過ぎだ。まるで「鍵を閉めたか不安で10回確認する」ようなものだ。
教訓：慎重さは美徳。でも、過剰な慎重さは別の問題になる。
3つ目：絶対的な遵守 ― それ以上でも以下でもない
私はある pattern に気づき始めた。GLM は、言われたことを正確に実行する。足さないし、引かない。
例えば、こんな code がある。
result = calculate(x)
print(result)
私は言った。「f-string を使うように修正して。」
GLM の修正結果はこれだ。
result = calculate(x)
print(f"{result}")
以上。import 追加なし、syntax check なし、改善提案なし。言われた通り、それだけをやる。
ある意味では良い。勝手に「創造」したり、不要な変更を加えたりしない。
しかし別の見方をすると…問題でもある。私は すべてを明示的に 指示しなければならない。「import を追加」「syntax を確認」「format を修正」。そう言わなければ、そこには触れない。
これは Opus 4.5 や GPT-5.2 とはかなり違う。あちらは、言わなくても不足を補い、より良い方法を提案してくることが多い。
GLM は、非常に勤勉だが指示待ちの assistant。Opus や GPT は、判断力を持つ partner に近い。
これは model の欠陥か？ いいえ。設計上の選択だ。ただし、prompt を非常に詳細に書く必要がある。厳密な control が好きなら、GLM は理想的だ。主体的な partner を求めるなら、少し物足りないかもしれない。
4つ目：Agent mode vs Plan mode ― Control についての教訓
最初、私は Agent mode に大きな期待を寄せていた。問題を説明すれば、AI が codebase を走査し、修正を適用する。完全自動化。夢のようだ。
だが、agent が codebase 内を行ったり来たりし、file を直しては戻し、また直す様子を何度も見て、私は悟った。Agent mode は production code 向けではない。
理由は知能不足ではない。「全体を俯瞰する能力」が足りないのだ。局所的に正しい変更を重ねるが、一歩引いて全体への影響を見ない。その結果、変更は断片的で一貫性を欠き、時に logic を壊す。
そこで私は Plan mode に切り替えた。
新しいワークフロー
-
GLM に計画を立てさせる
例：「この認証 module を OAuth2 対応にしたい。詳細な plan を作ってほしい」 -
GLM が plan を提示
構造があり、step と dependency が整理されていることが多い。 -
plan を丁寧に読む
logic、risk、抜け漏れを確認する。 -
追加で調整指示を出す
「step 3 は risk が高い」「step 5 は2つに分けた方がいい」 -
plan が固まったら実行
実装は別の model（Opus、GPT-5.2）を使うこともある。GLM は planning、他は execution。
なぜうまくいくのか？
control と可視性 があるからだ。AI に盲目的に任せるのではなく、commit 前に全体を把握できる。
GLM の plan はかなり実用的だ。天才ではないが、筋は通っている。数回ブラッシュアップすれば使える。
そして何より、code の品質が上がった。
「AI が勝手に書いて、私が後で直す」から、「道筋を理解した上で、管理された実装」へ変わった。
これは、GLM を使う上で私が見つけた、最も低リスクな方法だ。
なぜ Benchmark は高いのに、体験は違うのか？
GLM は悪い product ではない。特定の目的にはとても強い。 ただし、benchmark と現実の間にはギャップがある。
1. Benchmark は単発タスクを測る
Code Arena は「既存 code を維持する」「文脈を保った修正」を測らない。純粋な問題解決力だけを見る。それは実務の一部に過ぎない。
2. 実際の workflow ははるかに複雑
私は HumanEval 的な code は書かない。1万行以上の codebase、dependency、edge case、複雑な business logic を扱う。別世界だ。
3. Marketing の誇張
「RIP Opus」「Claude Killer」。刺激的だが正確ではない。GLM は強力だが、何かを「殺す」わけではない。YouTube では派手なタイトル＝再生数だ。
4. コミュニティのエコーチェンバー
ポジティブな体験は拡散され、ネガティブな体験は「使い方が悪い」で片付けられがち。confirmation bias は強い。
検討中の人へのアドバイス
「GLM 4.7 RIP Claude」の動画を見ているなら、自分に問いかけてほしい。
質問1：「AI を何に使うのか？」
- code sample、template 作成 → GLM はコスパ良い
- 既存 code のリファクタ → Opus 4.5 が向いている
- 複雑な debug → GPT-5.2 または Opus 4.5
- 何でも → 組み合わせて使うべき
質問2：「この Benchmark は自分の workflow に合っているか？」
多くの video は単純な問題しか試していない。保守・拡張・修正中心の workflow とは大きく違う。
質問3：「詳細な prompt を書けるか？」
GLM は具体性を要求する。雑な prompt なら失望する。丁寧に書けるなら問題ない。
質問4：「時間とのトレードオフを受け入れられるか？」
月 $10 節約して、5時間 review に使う。それで納得できるか？
結論：Benchmark は物語のすべてではない
GLM 4.7 は良い product だ。真面目な publisher、低価格。だが、benchmark の点数と実際の開発体験の間には、想像以上の距離がある。
GLM は高速な code 作成、sample、planning では優秀だ。しかし Opus や GPT をすべての場面で置き換えると期待すると、失望するだろう。
「本を表紙で判断するな」という言葉がある。今回、私は GLM を benchmark で判断し、教訓を得た。
高得点＝自分の問題を解決してくれる、ではない。
それに気づけたこと自体が、この subscription の価値だった。
もしあなたが GLM で違う体験をしているなら、あるいは「使い方が間違っている」と思うなら、ぜひコメントしてほしい。本当に聞きたい。コミュニティには、過剰な熱狂だけでなく、正直な視点が必要だ。
P/S: ちなみに、私は現在最強クラスの coding model 2つ ― Claude Opus 4.5 と GPT-5.1 Codex Max ― を詳細に比較した記事も書いている。「判断力」と「実行力」の違いに興味があれば、ぜひ読んでほしい。
Claude Opus 4.5 vs. GPT-5.1 Codex Max モダンAIコーディングにおける「判断」と「実行」