---
title: "Cloudflare Workers AIでGLM-5.2を使う方法 モデルID・料金・TypeScript実装"
description: "Cloudflare Workers AIでGLM-5.2を呼び出すためのモデルID、料金、コンテキスト長、Wrangler設定、TypeScript実装を整理した技術メモ。"
lang: "ja"
canonical: "https://llm-lab.dev/posts/cloudflare-worker-ai-glm-5-2/"
source: "https://llm-lab.dev/posts/cloudflare-worker-ai-glm-5-2.md"
publishedAt: "2026-06-18"
updatedAt: "2026-06-18"
category: "技術メモ"
tags:
  - "cloudflare"
  - "workers-ai"
  - "glm"
  - "llm"
---

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

> [!NOTE]
> この記事で確認したこと
>
> 今回は、Cloudflare Workers AIからGLM-5.2を呼び出すために、モデルID、料金、コンテキスト長、WranglerのAI binding、TypeScript実装を整理しました。
>
> 実測では、`@cf/zai-org/glm-5.2` をWorkers AI binding経由で呼び出せることと、OpenAI互換の `type: "function"` 形式で単一のFunction callingが成功することを確認しました。カタログ上の対応と実タスクでの安定性は、分けて評価する必要があります。

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のモデルページ](https://developers.cloudflare.com/workers-ai/models/glm-5.2/)と[Workers AIの料金表](https://developers.cloudflare.com/workers-ai/platform/pricing/)を確認してください。

## 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`を指定します。

```jsonc
{
  "$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を含む型定義を生成します。

```bash
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とメッセージを渡します。

```typescript
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を利用するため、ローカル実行でも推論分の利用量が発生します。

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

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

## Function callingを実際に確認する

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

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

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

```typescript
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モデルページ](https://developers.cloudflare.com/workers-ai/models/glm-5.2/)
- [Introducing GLM-5.2 on Workers AI](https://developers.cloudflare.com/changelog/post/2026-06-16-glm-52-workers-ai/)
- [Workers AI Pricing](https://developers.cloudflare.com/workers-ai/platform/pricing/)