Cloudflare Workers AIでGLM-5.2を使う方法 モデルID・料金・TypeScript実装

Cloudflare Workers AIに、Z.aiのエージェント・コーディング向けモデルGLM-5.2が追加されました。モデル名だけを見て試すと、モデルIDや料金、Workers AI上で利用できるコンテキスト長を別々に調べることになります。そこで、実装前に必要な情報と最小構成をまとめます。

まず、Cloudflare公式のモデルページで確認できる仕様は次のとおりです。

項目	内容
モデルID	@cf/zai-org/glm-5.2
入力料金	100万トークンあたり1.40米ドル
キャッシュ入力料金	100万トークンあたり0.26米ドル
出力料金	100万トークンあたり4.40米ドル
Workers AI上のコンテキスト長	262,144トークン
Function calling	対応
Reasoning	対応

料金や上限は変更される可能性があります。実装時にはGLM-5.2のモデルページとWorkers AIの料金表を確認してください。

Cloudflare GLM-5.2で確認しておきたいこと

GLM-5.2自体は最大1,048,576トークンのコンテキストを想定したモデルですが、Cloudflareのリリース時点でWorkers AIから利用できる長さは262,144トークンです。モデル本体の上限と、利用する基盤が提供する上限を分けて考える必要があります。

また、公式にはFunction callingとReasoningへの対応が示されています。ただし、対応していることと、任意のツール定義や日本語の指示で安定して動作することは別問題です。本記事ではモデルカタログ上の対応状況と最小のテキスト生成構成までを扱い、ツール呼び出しの成功率や他モデルとの性能比較は評価していません。

Workers AI GLM-5.2をWranglerで設定する

Workersからモデルを呼び出すには、wrangler.jsoncへAI bindingを追加します。ローカルのWranglerから実際のWorkers AIへ接続する構成では、remote: trueを指定します。

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "glm-5-2-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-06-24",
  "ai": {
    "binding": "AI",
    "remote": true
  }
}

設定を追加したら、次のコマンドでbindingを含む型定義を生成します。

npx wrangler types

Wrangler 4系でこの設定を読み込み、AI: Aiを含む型定義を生成できることを確認しました。加えて、認証済みアカウントから同じモデルIDを呼び出し、日本語のテキスト生成がHTTP 200で成功することも確認しています。入力33トークン、出力275トークン、合計308トークンというusageが返り、回答本文はchoices[0].message.contentに格納されました。

TypeScriptからGLM-5.2を呼び出す

Worker本体では、AI bindingのenv.AI.run()へ正確なモデルIDとメッセージを渡します。

interface Env {
  AI: Ai;
}

export default {
  async fetch(_request, env): Promise<Response> {
    const response = await env.AI.run("@cf/zai-org/glm-5.2", {
      messages: [
        {
          role: "system",
          content: "日本語で簡潔に回答してください。",
        },
        {
          role: "user",
          content: "Cloudflare Workers AIを一文で説明してください。",
        },
      ],
    });

    return Response.json(response);
  },
} satisfies ExportedHandler<Env>;

ローカルで確認する場合はnpx wrangler devを起動し、表示されたURLへHTTPリクエストを送ります。AI bindingはリモートのWorkers AIを利用するため、ローカル実行でも推論分の利用量が発生します。

npx wrangler dev
curl http://localhost:8787/

公式ドキュメントでは、非ストリーミング時はenv.AI.run()の結果をJSONとして返す例、ストリーミング時はstream: trueを指定してtext/event-streamとして返す例が示されています。まずは非ストリーミング構成で入出力を確認し、その後にストリーミングやFunction callingへ広げるほうが、問題の切り分けはしやすくなります。

Function callingを実際に確認する

Function callingでは一度、ツール定義を次のようにツール直下へ置いたところ、APIの入力検証でfunctionフィールドがないとして拒否されました。

// この形式は今回のGLM-5.2 APIでは拒否された
tools: [{
  name: "get_weather",
  description: "指定された都市の現在の天気を取得する",
  parameters: { /* JSON Schema */ },
}]

OpenAI互換のtype: "function"とfunctionオブジェクトを使うと成功しました。

tools: [{
  type: "function",
  function: {
    name: "get_weather",
    description: "指定された都市の現在の天気を取得する",
    parameters: {
      type: "object",
      properties: {
        city: { type: "string", description: "都市名" },
      },
      required: ["city"],
    },
  },
}]

「東京の現在の天気を調べてください」と入力した実測では、finish_reasonがtool_callsになり、get_weatherと{"city":"東京"}が返りました。入力188トークン、出力50トークン、合計238トークンでした。これは一回の成功例であり、ツール選択の安定性や引数精度を評価するには、入力表現を変えた複数ケースが必要です。

実装時に見るべきポイント

GLM-5.2は長いコンテキスト、Function calling、Reasoningに対応していますが、実運用の判断には機能一覧だけでは足りません。少なくとも、入力・出力トークン数、Time to First Token、ツール呼び出しの成功率、構造化出力の検証失敗率を、実際のユースケースで記録する必要があります。

特にエージェント用途では、一度ツールを呼べたかではなく、複数ターンで引数を維持できるか、ツールの失敗を受けて計画を修正できるか、長い入力でも不要な呼び出しが増えないかが重要です。今回は単一ターンでのツール選択までを確認しましたが、これらの継続的な挙動は未検証です。

まとめ

Workers AIでGLM-5.2を使うときのモデルIDは@cf/zai-org/glm-5.2で、WranglerにはAI bindingを設定します。Cloudflare上のコンテキスト長は262,144トークンで、Function callingとReasoningに対応しています。

一方、機能対応と実タスクでの安定性は分けて評価すべきです。まず最小のテキスト生成を通し、その後にストリーミング、Function calling、長文入力の順で検証範囲を広げるのが現実的です。

参考資料

• GLM-5.2 Workers AIモデルページ
• Introducing GLM-5.2 on Workers AI
• Workers AI Pricing