Claude CodeとClineでGLM-5.3-Flashを使う方法

すでにGLMコーディングプランを購読している場合、GLM-5.3-Flashに注目すべき具体的な理由があります。それは、同じプランでGLM-5.3の**3倍の使用可能なクォータ**を持つと報告されているからです。これが議論の全てです。AI分析インテリジェンス指数で60ではなく57を出すモデルと引き換えに、3倍多くのリクエストが可能です。

日常的なコーディング作業であれば、このトレードオフは簡単です。このガイドでは、FlashをClaude CodeとClineに組み込む方法、GLM-5.3を使い続けるべき時、そして問題を引き起こしがちな設定の詳細について説明します。

ボタン

まず必要なもの

z.aiのGLMコーディングプランの購読。プランは月額約18ドルから。
Z.aiダッシュボードからのAPIキー。
Claude CodeまたはClineがインストールされていること。

クォータ乗数とプランのティアをz.aiで確認してから計画を立ててください。プランの条件はモデルの仕様よりも頻繁に変更され、3倍という数字はZ.aiの公式ドキュメントからのものです。

Claude Code

Z.aiはAnthropic互換のエンドポイントを公開しており、2つの環境変数を変更することでClaude CodeがGLMモデルと通信できるようになります。

簡単な方法

Z.aiには、設定を自動で記述してくれるヘルパーが付属しています。

npx @z_ai/coding-helper

これにより、キーの入力を求め、設定が行われます。もしこれが機能すれば、以下のモデル選択のセクションに進んでください。

手動で行う方法

シェルプロファイルでベースURLとトークンを設定します。

export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="your-z-ai-key"

その後、通常通りClaude Codeを起動します。リクエストはAnthropicではなくZ.aiにルーティングされます。

ここで特に問題になりやすい点が2つあります。

ANTHROPIC_API_KEYはANTHROPIC_AUTH_TOKENとは異なる変数です。古いAnthropicキーがエクスポートされている場合は、それを解除してください。両方が設定されていると、競合ではなく無効なキーのように読める認証エラーが発生します。

環境がプロセスに到達する必要があります。これらを.zshrcに設定し、シェルプロファイルを読み込まないエディタやランチャーからClaude Codeを起動すると、それらは認識されません。起動元のコンテキストでecho $ANTHROPIC_BASE_URLを実行してテストしてください。

モデルの選択

接続後、モデルとしてglm-5.3-flashを選択します。設定ファイルを使用している場合は、そこにモデルIDを記述します。

{
  "model": "glm-5.3-flash"
}

100万トークンのウィンドウはリクエストが正当に時間がかかる可能性があるため、長いコンテキストの作業ではタイムアウトを長くすることが有効です。

export API_TIMEOUT_MS=3000000

この値はGLM-5.2の設定から引き継がれており、ご自身の経験と照らし合わせて確認する価値があります。既存の設定を移行する場合は、GLM-5.2ハーネスガイドが前世代について説明しています。

Cline

ClineはAnthropic互換のプロバイダーではなく、OpenAI互換のプロバイダーを通じて接続します。

Clineの設定を開き、APIプロバイダーとしてOpenAI Compatibleを選択します。
ベースURLをhttps://api.z.ai/api/coding/paas/v4に設定します。
Z.aiのAPIキーを貼り付けます。
Custom Modelを選択し、glm-5.3-flashを入力します。

ベースURLに注意してください。コーディングプランのエンドポイント（/api/coding/paas/v4）は、当社のAPIガイドで直接API呼び出しに使用される標準APIエンドポイント（/api/paas/v4）とは異なります。両方のURLがドキュメントやコミュニティの投稿で出回っており、コーディングプランのキーで標準のURLを使用すると、混乱を招く認証失敗の一般的な原因となります。これらのパスは以前にも変更されているため、現在のZ.aiドキュメントと照らし合わせて両方を確認してください。

コンテキストウィンドウの設定

Clineはカスタムモデルのコンテキストウィンドウを常に正しく推測するとは限りません。大規模なコードベースを扱っていて、早期に切り詰められている場合は、コンテキストウィンドウを手動で1,000,000に設定してください。

これはGLM-5.2のユーザーにも同様に当てはまりました。症状としては、モデル自体はファイルコンテキストを完璧に保持できるにもかかわらず、Clineが本来よりも早くファイルコンテキストを破棄してしまうというものです。

エージェント型コーディングにFlashを選ぶ理由

Z.aiの公開データを用いたベンチマークケースです。

ベンチマーク	GLM-5.3-Flash	GLM-5.2
Terminal-Bench 2.1	84.3	直接比較不可
DeepSWE	63.4	46.2
AutomationBench	48.8	26.2

Terminal-Benchの数値はClaude Code 2.1.207に対して評価されており、ここを読んでいるほとんどの読者が使用しているハーネスに直接関連しています。独立した検証結果が出るまでは、これらをベンダーの主張として扱ってください。

Artificial Analysisによる独立した測定では、GLM-5.3の60に対し、インテリジェンス指数は57でした。

コーディングハーネスにとって真に新しい点が一つあります。それはネイティブ画像入力です。Flashは、コードと同じリクエスト内でコンテンツブロックとしてスクリーンショットを受け入れます。フロントエンド作業の場合、これは破損したレイアウトのスクリーンショットを会話に貼り付け、モデルがレンダリングの説明ではなく、レンダリングについて推論することを意味します。Z.ai自身の説明では、インターフェースの観察とレンダリング結果について言及しています。弊社のビジョンガイドでは、この経路が何をもたらすかについて説明します。

速度のトレードオフを明確に述べる

GLM-5.3-Flashは毎秒約49トークンを生成します。GLM-5.3は約86トークンです。長いファイルの書き換えをストリーミングするコーディングハーネスでは、この差を感じるでしょう。

最初のトークンまでの時間は、1.52秒対1.57秒と実質的に同じなので、モデルは同程度の速さで応答を開始します。違いは長い出力で現れます。

これがクォータに関する議論に対する正直な対抗意見です。3倍のクォータと引き換えに、生成速度は約半分になります。短い編集、ツール呼び出し、反復作業ではクォータが有利です。「この800行のファイルを書き換えろ」という場合、待機時間は現実的な問題となります。

実用的なルーティング戦略

どちらか一方を選ぶのではなく、両方を使用します。

探索、コードの読み込み、コマンドの実行、小さな編集、および画像関連のあらゆる作業には、デフォルトでFlashを使用します。
難しいアーキテクチャの問題、大規模なリファクタリング、およびFlashが一度失敗したことが判明しているあらゆる作業には、GLM-5.3を使用します。

切り替えはハーネスの設定でモデルIDを変更するだけなので、対応にかかる時間は数秒です。コーディングプランを利用している場合、これによりほとんどの処理量を3倍クォータのモデルで行い、高価なクォータはそれを必要とする作業のために温存できます。

Z.aiはまた、オフピーク時の呼び出しは標準ポイントの半分しか消費しないため、バッチ処理やバックグラウンドエージェントの作業をピーク時間外にスケジュールすることで、プランをさらに有効活用できると述べています。

トラブルシューティング

この設定での失敗は、いくつかのパターンに集約されます。

すべてのリクエストで401または403エラー。ほとんどの場合、お持ちのキーに対して誤ったベースURLを使用しているか、古いANTHROPIC_API_KEYがANTHROPIC_AUTH_TOKENを隠蔽しています。ハーネス設定を変更する前に、この記事の最後にある直接のcurl呼び出しで確認してください。
モデルが見つかりません。ID文字列を正確に確認してください。バージョンにドットがあり、flashの前にハイフンがあるglm-5.3-flashです。OpenRouterではz-ai/glm-5.3-flashという名前空間が付けられていますが、これはZ.aiのネイティブIDと互換性がありません。
コンテキストが早期に切り詰められる。Clineでコンテキストウィンドウを手動で設定してください。カスタムモデルに対して1,000,000を確実に推測するわけではありません。
大きなリクエストでのタイムアウト。API_TIMEOUT_MSを上げてください。本当に長いコンテキストのリクエストは、何も問題がない場合でもデフォルトのクライアントタイムアウトを超えることがあります。
クォータが予想よりも早く消費される。reasoning_effortはデフォルトでmaxであり、推論トークンがカウントされます。ハーネスで設定できる場合、日常的な作業ではlowに下げることで、プランを大幅に節約できます。
ツール呼び出しの失敗または形式が不正。ハーネスとエンドポイントがツール呼び出しの形式について一致していることを確認してください。これは統合の最もバージョンに敏感な部分であり、どちらかの側でアップデートがあった後に最も壊れやすい部分です。

その他のハーネス

同じ2つの接続形式でほとんどのツールをカバーできます。Anthropic互換のものは（Claude Code、一部のエージェントフレームワーク）はANTHROPIC_AUTH_TOKENとともにhttps://api.z.ai/api/anthropicを使用します。OpenAI互換のものは（Cline、Roo、Kilo、OpenCode、Codex、Cursorのカスタムモデルオプション）は、標準のAPIキーフィールドにキーを設定し、glm-5.3-flashをカスタムモデルIDとしてhttps://api.z.ai/api/coding/paas/v4を使用します。

以前のモデルに関するパターンは、弊社のこれまでのガイドで説明しています。GLM-5.1とClaude Code、およびGLM-4.7とClaude CodeおよびCursor。

接続の確認

ハーネスの設定を信頼する前に、エンドポイントが単独で機能することを確認してください。直接呼び出すことで、ハーネスが問題の原因ではないと判断できます。

curl https://api.z.ai/api/coding/paas/v4/chat/completions \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3-flash",
    "messages": [{"role": "user", "content": "reply with OK"}]
  }'

これにより応答が返され、なおハーネスが失敗する場合は、問題は資格情報ではなく設定にあります。

一時的なチェック以上の作業の場合、これらの呼び出しにはシェル履歴よりもApidogの方が適しています。コーディングエンドポイントと標準エンドポイントを環境変数としてキーを保存し、並べて保存しておくと、ハーネスが認証エラーを発生させ始めたときに、エンドポイントの問題かツールの問題かをワンクリックで判断できます。この区別が、これらの設定におけるデバッグ時間の大部分を占めます。

よくある質問

コーディングプランが必要ですか、それともAPIクレジットで動作しますか？両方とも動作します。コーディングプランは、日常的にコーディングする開発者にとっては通常安価であり、従量課金制のAPIアクセスはアプリケーションに適しています。弊社の料金に関する投稿で比較しています。
Flashは本当にGLM-5.3の3倍のクォータがありますか？それはZ.aiが公表している数値です。計画を立てる前にz.ai/subscribeで確認してください。
Clineが私のコンテキストを切り詰めるのはなぜですか？コンテキストウィンドウを手動で1,000,000に設定してください。Clineはカスタムモデルに対して常に正しく推測するわけではありません。
どのベースURLを使用しますか？Claude Codeにはhttps://api.z.ai/api/anthropic、コーディングプランでOpenAI互換ツールにはhttps://api.z.ai/api/coding/paas/v4、直接API呼び出しにはhttps://api.z.ai/api/paas/v4を使用します。
FlashでClaude Codeにスクリーンショットを貼り付けることはできますか？モデルはネイティブ画像入力をサポートしています。お使いのハーネスのバージョンがそれを公開しているかどうかは別の問題なので、それに頼る前にテストしてください。