WaveSpeedAI
← ブログ

WaveSpeedでGLM-5 APIをすぐに始める（コード例付き）

認証、最初のリクエスト、ストリーミング、エラーハンドリングまで、WaveSpeed APIを使って5分以内にGLM-5を動かす方法を解説します。

1 min read
WaveSpeedでGLM-5 APIをすぐに始める（コード例付き）

こんにちは、Doraです。2026年1月に小さなコンテンツ生成機能のプロトタイプを作っていたとき、モデルの選択肢を眺めていてGLM-5に出会いました。名前は耳にしたことがありました――堅実なパフォーマンス、合理的なアーキテクチャ。でも私が求めていたのはシンプルなことでした：1週間も配管工事をせずに既存のワークフローに組み込めるか？この記事はまさにそれです：認証情報を取得した瞬間から画像や動画パイプラインへの接続を考え始めるまでの、**GLM-5 API**の落ち着いたハンズオンガイドです。コマンドを示し、迷った箇所を指摘し、遭遇したトレードオフを書き留めます。あなたの作業スタイルに合うかどうか、判断する参考にしてください。

前提条件 — WaveSpeedアカウント＋APIキー

curlの1行目を書く前に、静かなステップが一つあります：アカウントとAPIキーです。私はWaveSpeedでセットアップしました。フローは分かりやすいですが、二つの小さな点に注意してください。

まず、GLM-5エンドポイント用にスコープされたキーを取得してください。高スループットモデル向けに別のトークンやロールが必要な場合があり、間違ったキーを使うと「model not found」という素っ気ないエラーが出ます。これが他のことのように見えて、確認するまで10分間悩みました。次に、ダッシュボードに記載されているリージョン/エンドポイントをメモしてください。アカウントによってはモデルがリージョナルエンドポイントにマッピングされており、動画やインタラクティブ機能を使う場合はレイテンシに影響します。

私が使った実用的なチェックリスト：

  • WaveSpeedアカウントを作成し、メールを確認する。
  • 開発/テスト用にラベルを付けたAPIキーを作成する。
  • ダッシュボードにGLM-5モデルが表示されていることを確認し、記載されたエンドポイントリージョンをメモする。
  • テストスクリプトに直接貼り付けるのではなく、キーをローカルの.envファイルに保存する（後々の摩擦が最小限になる）。

以上です。特殊なハードウェアやSDKの購入は不要。APIキーとエンドポイントマッピングを確認する根気があれば十分です。

3ステップで最初のリクエスト（curl + Python + JS）

curlリクエストから始めるのが好きです。抽象化なしに、ヘッダー、ステータスコード、生のJSONが正直に見えるからです。その後、実験にはPythonを使い、小さなUIをプロトタイプするときはJSに移ります。

モデルIDとエンドポイント

GLM-5 APIはモデルIDとエンドポイントURLを必要とします。私のテストではモデルIDはglm-5-v1のような形式でした（ダッシュボードで確認してください：リリースによって名前が異なる場合があります）。エンドポイントはPOSTするホストです：私の場合はリージョンプレフィックスが付いていました。どちらかが間違っていると、即座に404またはmodel-not-foundのJSONエラーが返ります。

私が実行したcurlの最小例（キーとエンドポイントを適宜変更してください）：

curl -X POST "https://your-region.api.wavespeed/v1/models/glm-5-v1/generate" \
-H "Authorization: Bearer $WAVESPEED_KEY" \
-H "Content-Type: application/json" \
-d '{"prompt":"Write a short intro about mindful workflows.","max_tokens":120}'

テキストとトークンメタデータを含む小さなJSONが返ってきました。クリーンで即座のフィードバックです。

ストリーミング vs 非ストリーミング

GLM-5はストリーミングと非ストリーミングの両方のレスポンスをサポートしています。シンプルさを保つために非ストリーミングから始め、小さなエディタープロトタイプにはストリーミングに切り替えました。ストリーミングは体感レイテンシを削減します：テキストが生成されながら表示されるため、インタラクティビティに役立ちます。ただしストリーミングは複雑さを増します――接続処理、部分的な結果、クライアント側での少しの状態管理が必要です。

ローカルデモ（Node.js、EventSourceスタイル）でストリーミングを使ったとき、二つの動作に気づきました：

  • 最初のトークンはすばやく届き、レスポンシブに感じられます。
  • 時折、小さなフォーマットの癖（文の途中でカット）を持つ部分的なチャンクが届きました。処理は簡単でしたが、知っておく価値があります。

即座のユーザーフィードバックを重視するなら――チャットUI、ライブアシスタント――ストリーミングから始めてください。バッチ生成やシンプルなスクリプトには、非ストリーミングの方がシンプルでエラーが少ないです。

キーパラメーター：シンキングモード、temperature、max tokens

私の経験を最も左右した3つのパラメーターがあります：シンキングモード、temperature、max tokensです。いくつかの短い実験を通じてこれらを調整しました。

シンキングモード

GLM-5は「シンキングモード」パラメーターを公開しており、モデルがプロンプトをどのように推論するかを誘導します。大雑把な命令セットとして考えてください：安価なモードはスピードと簡潔さを優先し、重いモードは深さと複数ステップの推論を優先します。短いマーケティングコピーには速いモードを、複数パートのチュートリアルのアウトライン作成を依頼するときは深いモードを使いました。

私の結論：シンキングモードを魔法のように扱わないこと。モデルのアプローチは変わりますが、複数ステップの出力が必要な場合はプロンプトを構造化する必要があります。

Temperature

Temperatureはランダム性を制御します。同じプロンプトを0.0、0.3、0.8で実行しました。0.0では出力が一貫していて安全で、テンプレートやコード生成に役立ちました。0.8ではモデルがより創造的な展開を提案し、時に助けになる言い回しを生み出し、時に無駄な内容に流れることもありました。

私が使った実用的なルール：本番テキストには0.2〜0.4から始め、決定論的タスク（SQLなど）には0.0、アイデア出しには0.6〜0.8。

Max tokens

Max tokensは出力の長さを制限します。GLM-5はレスポンスで予測可能なトークン数を返すことが分かりました。max_tokensを低く設定しすぎると、モデルが考えの途中でカットオフされ、箇条書きのアウトラインを作成するときにイライラしました。不明な場合は多めに設定してクライアント側でトリミングします。私が使った小さなヒューリスティック：単語数 × 1.3 = トークン数、そして10%のバッファを追加。

エラー処理 — レート制限、model not found、タイムアウト

エラーはプラットフォームの形を学ぶ場所です。

レート制限

WaveSpeedは明確なレート制限ヘッダーとHTTP 429を返します。私のプロトタイプでは、2台のマシンから並行テストを実行中に429に当たりました。指数バックオフとジッターを実装し、クライアント側でリクエストをキューイングすることで対処しました。それでほとんどの429が解消されました。アプリがユーザーリクエストをキューイングする場合は、エラーを表示するのではなく、穏やかな「処理中」状態を表示してください。

Model not found

これはよくある誤警報です。モデルIDのタイポ、そのモデルへの権限のないキー、またはリージョンでモデルが利用不可であることを意味する場合があります。これを見たときのチェックリスト：

  • モデルIDがダッシュボードと正確に一致していることを確認。
  • **APIキー**が正しいスコープ/ロールを持っているか確認。
  • 利用可能であれば別のリージョナルエンドポイントを試す。

タイムアウト

長い生成や重いシンキングモードでは、時折タイムアウトが発生しました。私のアプローチは保守的でした：GLM-5 APIを呼び出す特定のルートのサーバー側タイムアウトを増やし、ストリーミングが可能であれば進捗UIを提供する。タスクをより小さなステップに分割できる場合（アウトラインを生成→セクションを展開）、タイムアウトのリスクが減り、より管理しやすい障害が得られます。

ログとオブザーバビリティ

成功したレスポンスと失敗したレスポンスのリクエストIDをログに記録しています。後でサポートとデバッグするのがずっと楽になりました。

コスト見積もり — リクエストごとのトークン数

コストは重要です。2026年1月の4日間にわたって小さな実験を行い、リクエストごとに400〜800単語を生成するコンテンツ機能のトークン使用量を見積もりました。

測定したもの

  • プロンプトトークン：コンテキストサイズに応じて通常40〜120。
  • 補完トークン：600単語の出力で約750トークン（モデルによってトークン化が若干異なります）。リクエストあたりの合計は平均820〜900トークンでした。

コストを計算した簡単な方法：

  1. レスポンスメタデータからプロンプト + 補完トークンを追跡する。
  2. 特定のユースケースで30リクエスト分を平均する。
  3. モデルのトークン価格を掛ける（現在のレートはWaveSpeedダッシュボードで確認）。

驚いたこと

  • システムプロンプトと長い会話履歴はすぐに積み上がります。チャット履歴を保存する場合は積極的に刈り込んでください。
  • 開発中の繰り返しリトライが数字を歪めました：別の開発キーを使用し、トークンヘッダーを注意深く監視することをお勧めします。

大まかな数字を求めるなら：短いコピー生成（100〜200単語）にはリクエストごとに150〜300トークンを想定。長文（500〜800単語）には600〜900トークンを想定。実際の値は異なるので、実際のプロンプトで測定してください。

次のステップ — 画像/動画パイプラインへの統合

テキストで止まりませんでした。私にとって明らかな疑問は、GLM-5がメディアパイプラインにどう適合するかでした：キャプション、シーンの説明、動画スクリプト、またはメタデータの充実化。

試したいくつかの実用的なパターン

  • キャプションアシスタント：短いシーンの説明を送り、GLM-5に簡潔なキャプションを求める。一貫した言い回しのために、プロンプトを厳格にしてtemperatureを低く保つ。
  • スクリプト展開：GLM-5を使って箇条書きのアウトラインを短いスクリプトに展開する。長い補完を避け、生成を並列化するために、アウトラインをシーンごとのリクエストに分割しました。
  • メタデータタグ付け：クリップの自動タグ付けには、決定論的モードと小さなJSONスキーマプロンプトを使い、モデルが予測可能なキー/バリューペアを返すようにしました。

統合のヒント

  • 抽出したフレームやサムネイルを含める場合は、まず画像モデルに送り、短いキャプション（3〜6単語）を抽出してから、そのキャプションをGLM-5のコンテキストとして使用してください。プロンプトサイズが削減され、トークン数が低く保たれます。
  • できるだけリクエストをバッチ処理してください：一つの長いプロンプトではなく、複数の短いタスクを並列に送る方が、多くの場合安くて速いです。
  • 最終編集には人間のループを加えてください。プラットフォームをやりくりしているクリエイターやマーケターにとって、メリットは面倒な作業の削減であり、完璧な出力ではありません。

向いている人、向いていない人

制御できる柔軟なテキストモデルを求めているなら――決定論的タスク、コンテンツ展開、メタデータ生成――GLM-5は堅実です。トークン監視なしに大規模で超安価なアドホック出力が必要な場合には魅力が薄れます。

興味があれば、実際のプロンプトを使ってサンドボックス化された機能でテストし、トークンとレイテンシを測定してください。私の場合、モデルは小さなコンテンツ機能の中に静かな居場所を見つけました：派手ではありませんが、ステップを削減し、ワークフローの残りの部分をそのまま維持してくれました。

最後に小さな気になること：リージョンごとのレイテンシ数値を持つ公式なエンドポイントヘルスページが欲しいと思い続けています。リアルタイムUIを構築する場合、その可視性は大きな違いをもたらします。今のところ、いくつかの簡単なリージョナルpingとトークンログで対応しています。

共有