<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Zhipu AI on KnightLiブログ</title>
        <link>https://knightli.com/ja/tags/zhipu-ai/</link>
        <description>Recent content in Zhipu AI on KnightLiブログ</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>ja</language>
        <lastBuildDate>Thu, 18 Jun 2026 22:56:15 +0800</lastBuildDate><atom:link href="https://knightli.com/ja/tags/zhipu-ai/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>GLM 5.2 がオープンソース化：100万トークン文脈、Agentコーディング、ローカル導入の壁</title>
        <link>https://knightli.com/ja/2026/06/18/glm-5-2-open-model-agent-coding/</link>
        <pubDate>Thu, 18 Jun 2026 22:56:15 +0800</pubDate>
        
        <guid>https://knightli.com/ja/2026/06/18/glm-5-2-open-model-agent-coding/</guid>
        <description>&lt;p&gt;Zhipu AI は新しいフラッグシップモデル GLM 5.2 を正式にオープンソース化しました。&lt;/p&gt;
&lt;p&gt;最初、このニュースはそれほど珍しいものには見えませんでした。今はほぼ毎日のように新しいモデルが発表され、宣伝文句もますます大きくなっています。しかし GLM 5.2 のベンチマーク結果は、単独で見る価値があります。Terminal-Bench で 80% を突破した初のオープンウェイトモデルとなり、LiveBench の Agent coding テストでも第一線のグループに入りました。&lt;/p&gt;
&lt;p&gt;これは、Agent とコーディングの領域で、オープンモデルとクローズドモデルの差が縮まりつつあることを示しています。これまで多くの人は、最強の Agent は OpenAI、最強のコード能力は Anthropic、オープンモデルはその後を追う存在だと考えていました。GLM 5.2 の登場によって、その見方は少なくとも以前ほど絶対的ではなくなりました。&lt;/p&gt;
&lt;h2 id=&#34;100万-token-の文脈&#34;&gt;100万 Token の文脈
&lt;/h2&gt;&lt;p&gt;GLM 5.2 で最も目立つアップグレードは、100万 Token のコンテキストです。&lt;/p&gt;
&lt;p&gt;さらに重要なのは、公式が「安定して動作する 100万 Token 環境」と強調している点です。長文脈対応をうたうモデルは多いものの、実際に数十万字、複雑な文書、大規模なコードベースを入れると、前半の内容を徐々に忘れたり、回答がずれ始めたりすることがあります。&lt;/p&gt;
&lt;p&gt;GLM 5.2 は長周期タスクを重点的に最適化しています。向いているのは次のような用途です。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;一冊の小説や長大な資料；&lt;/li&gt;
&lt;li&gt;大規模なプロジェクトコードベース；&lt;/li&gt;
&lt;li&gt;複数の文書ライブラリやナレッジベース；&lt;/li&gt;
&lt;li&gt;長時間連続して動作する必要がある Agent タスク。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;これは将来の AI アシスタントにとって重要です。本当に価値のある Agent は、一つの質問に答えるだけではありません。ある目標を中心に、実行、デバッグ、修正、要約を継続し、数時間あるいは数日間作業できる必要があります。&lt;/p&gt;
&lt;h2 id=&#34;agent-能力が焦点&#34;&gt;Agent 能力が焦点
&lt;/h2&gt;&lt;p&gt;大規模モデルの競争は、もはや会話がうまいかどうかだけではありません。誰がより仕事をこなせるかが重要になっています。&lt;/p&gt;
&lt;p&gt;今回の実測では、GLM 5.2 を使って複数のフロントエンドと 3D サンプルを生成しました。Minecraft 風のミニゲーム、清明上河図をモチーフにした 3D シーン、空港フライトシミュレーター、地下鉄 FPS、GTA 風の俯瞰都市、そしてアーチェリーサイトの公式ページなどです。&lt;/p&gt;
&lt;p&gt;全体として、「自然言語から実行可能なプロジェクトを直接生成する」能力は悪くありません。生成されたページやゲームは完璧ではありませんが、多くのサンプルは実行でき、インタラクションがあり、基本ロジックを備え、エラーに応じて修正を続けることもできます。&lt;/p&gt;
&lt;h2 id=&#34;コード生成の実測結果&#34;&gt;コード生成の実測結果
&lt;/h2&gt;&lt;p&gt;最初のテストは、Minecraft をかなり再現したミニゲームの生成でした。&lt;/p&gt;
&lt;p&gt;生成後、ゲームは正常に動作しました。キャラクターはジャンプでき、ブロックを削除でき、数字キーで別のブロックに切り替えられます。完全なゲームではありませんが、一回の生成でできた Demo としては、基本的なインタラクションを備えています。&lt;/p&gt;
&lt;p&gt;二つ目のテストでは、Three.js を使って清明上河図の 3D シーンを作りました。GLM 5.2 は汴河、虹橋、両岸の建物、柳、船、通行人、城門楼、屋台などの要素を生成し、前の景、次の景、ローミングといった操作も用意しました。&lt;/p&gt;
&lt;p&gt;この Demo には問題もありました。たとえば船の位置が不自然だったり、人物が川に入ったり壁をすり抜けたりし、一部のオブジェクト関係も正確ではありません。それでも、シーン構造、動的要素、インタラクションロジックを組み立てられており、複雑なフロントエンドタスクでの完成度はすでに低くありません。&lt;/p&gt;
&lt;p&gt;DeepSeek や Gemini の同種の生成結果と比べると、GLM 5.2 は動的効果とシーンの完成度がより目立ちました。Gemini も全体シーン、昼夜切り替え、霧などの機能をある程度うまく扱えていましたが、UI スタイルや市井の雰囲気にはまだ差があります。DeepSeek の結果はより静的な展示に近く、動く人物や汴河という中核要素の扱いは弱めでした。&lt;/p&gt;
&lt;h2 id=&#34;フライトfps都市ドライブ&#34;&gt;フライト、FPS、都市ドライブ
&lt;/h2&gt;&lt;p&gt;空港フライトシミュレーターのテストでは、GLM 5.2 は滑走路、コックピット表示、スロットル制御、視点切り替え、リセット機能を備えた飛行 Demo を生成しました。キーボードでスロットル、離陸、旋回、ロールを操作でき、基本機能はほぼ使えます。&lt;/p&gt;
&lt;p&gt;地下鉄 FPS は、2049 年の廃棄トンネルを舞台にしたシューティングゲームという設定です。トンネルへの進入、発砲、効果音、ミニマップなどは生成されましたが、敵やステージ進行は未完成で、体験としては迷路プロトタイプに近いものでした。&lt;/p&gt;
&lt;p&gt;GTA 風の俯瞰都市では、車両、パトカー、衝突、運転制御が一回で生成されました。実行はできますが、操作感は粗く、車は街中で制御を失って走り回っているように感じます。プロトタイプとしては許容範囲ですが、本当に遊べるゲームまではまだ距離があります。&lt;/p&gt;
&lt;p&gt;これらのテストから分かるのは、GLM 5.2 は複雑な要求を実行可能なフロントエンドプロジェクトに分解できる一方で、生成結果にはまだ人間による確認、調整、修正が必要だということです。&lt;/p&gt;
&lt;h2 id=&#34;webサイト設計能力&#34;&gt;Webサイト設計能力
&lt;/h2&gt;&lt;p&gt;ゲームや 3D シーン以外に、GLM 5.2 はアーチェリーサイトの公式ページ生成にも使われました。&lt;/p&gt;
&lt;p&gt;この例はむしろ完成度が高めでした。モデルは「自分の本心を狙い、矢を外さない」といったコピーを自動生成し、ページにはコース予約、トレーニング紹介、料金プラン、申込・支払いプラン、連絡先が含まれています。ビジュアルスタイルは現在の主流 AI コーディングアシスタントが生成する Web サイトに近く、画像と文章の構成も比較的まとまっています。&lt;/p&gt;
&lt;p&gt;この種のタスクを見ると、GLM 5.2 は Landing Page、キャンペーンページ、製品サイトのようなフロントエンド作業でかなり実用的です。要件が明確であれば、後から編集できる初版をすばやく出せます。&lt;/p&gt;
&lt;h2 id=&#34;ローカル導入は簡単ではない&#34;&gt;ローカル導入は簡単ではない
&lt;/h2&gt;&lt;p&gt;GLM 5.2 はオープンウェイトモデルですが、ローカル導入のハードルは高いです。&lt;/p&gt;
&lt;p&gt;現在選べるデプロイフレームワークには SGLang、vLLM、Transformers があります。クラスタ Agent をデプロイする場合、性能とスループットを重視するなら SGLang が向いています。通常の推論であれば vLLM や Transformers も選択肢で、将来的には LM Studio や Ollama などのツールチェーンへの適配も考えられます。&lt;/p&gt;
&lt;p&gt;本当の問題はハードウェアです。&lt;/p&gt;
&lt;p&gt;フルモデルのサイズは 1TB 近くあります。量子化版を使っても、多くの場合は数百 GB 規模です。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;FP8 精度はおよそ 740GB 規模で、通常は H200 8 枚、または同等クラスのマルチ GPU サーバーが必要；&lt;/li&gt;
&lt;li&gt;Q4_K_M 量子化版はおよそ 470GB から 500GB で、現実的には 80GB VRAM GPU が複数枚必要；&lt;/li&gt;
&lt;li&gt;Q2 量子化版でも最低で約 240GB から 280GB の VRAM またはユニファイドメモリが必要；&lt;/li&gt;
&lt;li&gt;さらに低い量子化版でも、180GB 規模の VRAM リソースが必要になる可能性があります。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;つまり、一般的なコンシューマー向けハードウェアでフルローカル導入を考えるのはほぼ現実的ではありません。RTX 4090 を使う場合でも、非常に攻めたメモリ、VRAM、推論構成が必要で、体験をクラウド API と比べるのは難しいでしょう。&lt;/p&gt;
&lt;h2 id=&#34;企業は-api-利用のほうが現実的&#34;&gt;企業は API 利用のほうが現実的
&lt;/h2&gt;&lt;p&gt;企業が GLM 5.2 のフル版を導入しようとすると、全体投資は百万元級になる可能性があります。&lt;/p&gt;
&lt;p&gt;ローカルプライバシー、セキュリティ分離、データを外に出さないことを特に重視する業務でない限り、API Key を購入するほうが多くの場合は合理的です。現在のモデル更新は非常に速く、今日高コストなプライベート導入をしても、数週間後にはより強い新モデルが出るかもしれません。多くのチームにとっては、まず API で業務価値を検証し、その後にプライベート導入が必要か判断するほうが堅実です。&lt;/p&gt;
&lt;h2 id=&#34;まとめ&#34;&gt;まとめ
&lt;/h2&gt;&lt;p&gt;GLM 5.2 のポイントは、単なるパラメータ規模ではありません。長文脈、Agent コーディング、複雑なタスク実行です。&lt;/p&gt;
&lt;p&gt;Terminal-Bench と LiveBench Agent coding での成績は、オープンウェイトモデルがより強いエンジニアリング実用段階に入りつつあることを示しています。ゲーム、3D シーン、Web サイトを実際に生成すると、多くの実行可能なプロトタイプを作れますが、細部の正確性、操作感、複雑なロジックにはまだ人間の介入が必要です。&lt;/p&gt;
&lt;p&gt;体験やアプリ開発が目的なら、オンラインプラットフォームや API を優先するほうが現実的です。企業レベルのプライバシー、セキュリティ、イントラネット要件がある場合に、SGLang、vLLM などによるローカル導入を検討するとよいでしょう。&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
