ApidogでGLM-5.3-Flash APIをテストする方法

アプリケーションでLLMを交換するのは、1行の変更であると同時に、はるかに大きなリスクを伴います。モデルIDは文字列です。その文字列を変更すると、応答のレイテンシー、トークンコスト、出力フォーマットの安定性、ツール呼び出しの挙動、そして画像パイプラインがそもそも機能するかどうかが変わります。

GLM-5.3-Flashはこれを具体的に示しています。これはGLM-5.3より約9倍安く、GLM-5.3がネイティブで画像をサポートしないのに対し、ネイティブで画像を処理でき、約半分の速度で生成します。これらは現実的なトレードオフであり、どちらの側に立つかを知る唯一の方法は、両方に対して独自のリクエストを実行することです。

このガイドでは、ApidogでGLM-5.3-Flash APIの再利用可能なテストコレクションをセットアップします。これには、テキスト呼び出し、画像呼び出し、ツール呼び出し、アサーション、およびより大きなモデルとの比較実行が含まれます。

なぜ単にcurlを使わないのか

このエンドポイントをcurlでテストすることはもちろん可能ですし、弊社のAPIガイドでもその方法を正確に示しています。しかし、最初の呼び出しを超えると、2つの問題が発生します。

Base64画像ペイロード。 スクリーンショットのデータURLは何千もの文字になります。それをターミナルに貼り付けると、読めず、編集できず、翌日には再実行できないコマンドが生成されます。マルチモーダルテストでは、シェル履歴は実用的なツールではなくなります。

何もアサートされない。 curlの応答は画面上のテキストです。それは呼び出しが成功したことを伝えるだけで、応答にアプリケーションが読み込むフィールドがまだ含まれているかどうかは教えてくれません。モデルを変更する場合、その区別こそがテストの全要点です。

保存されたコレクションは両方の問題を解決します。ペイロードは編集可能なリクエスト内にあり、アサーションは毎回実行されます。

環境をセットアップする

実行間で変わる値を持つ環境を作成します。モデルIDを変数として保持することが重要です。これにより、後でコレクション全体を別のモデルに再指定できるようになります。

変数	値
`base_url`	`https://api.z.ai/api/paas/v4`
`api_key`	あなたのZ.aiキー
`model`	`glm-5.3-flash`

キーはリクエストヘッダーに直接貼り付けるのではなく、環境変数として保存してください。これにより、エクスポートしたりチームメイトと共有したりするものからキーが除外されます。これは、誰かが初めてコレクションをコミットするときに思える以上に重要です。

リクエスト1：テキスト補完

{{base_url}}/chat/completionsへのPOSTリクエストを作成します。

ヘッダー：

Authorization: Bearer {{api_key}}
Content-Type: application/json

ボディ：

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Reply with exactly: OK"}
  ],
  "reasoning_effort": "low"
}

reasoning_effortに注目してください。このモデルではデフォルトでmaxになっており、推論は出力トークンとして課金されます。接続チェックとしては全くの無駄なので、ここではlowに設定してください。

応答にアサーションを追加します。

ステータスコードが200と等しいこと
choices[0].message.contentが存在すること
choices[0].finish_reasonがstopと等しいこと
usage.total_tokensが存在すること

finish_reasonのアサーションは、人々がスキップして後で後悔するものです。lengthという値は、応答が完了するのではなく、出力の上限で切り詰められたことを意味します。このモデルの最大出力値が情報源によって一貫していないことを考えると、切り詰めを明示的に検出することは、その1行の価値があります。

リクエスト2：画像呼び出し

これは、全体のセットアップを正当化するリクエストであり、GLM-5.3がネイティブで持たない機能です。

同じエンドポイントでも、ボディの形状が異なります。contentは型付きブロックの配列になります。

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "What color is the dominant shape in this image? Answer with one word."},
        {"type": "image_url", "image_url": {"url": "{{test_image_url}}"}}
      ]
    }
  ],
  "reasoning_effort": "low"
}

正しい答えを知っている安定した公開アクセス可能な画像を指すように、test_image_urlを環境に追加します。固定された画像に対する決定論的な質問は、これがデモではなく回帰テストとなる理由です。

ローカル画像の場合、同じフィールドがbase64データURLを受け取ります。リクエストボディが読みやすいように、環境変数として保存します。

data:image/png;base64,iVBORw0KGgo...

アサーション：

ステータスコードが200と等しいこと
choices[0].message.contentが既知の答えを含むこと
usage.prompt_tokensがテキストのみのリクエストのカウントよりも大きいこと

その最後のアサーションは有用なカナリアです。画像は入力トークンを消費するため、プロンプトトークン数が増加しない場合、画像は実際には処理されておらず、あなたの写真が黙って無視されているにもかかわらず200を返すリクエストになってしまいます。その失敗は、このチェックなしでは見えません。

ビジョンパスウェイとその失敗モードについては、弊社のGLM-5.3-Flashビジョンガイドで詳しく説明しています。

リクエスト3：ツール呼び出し

アプリケーションが関数呼び出しを使用する場合、それを明示的にテストしてください。ツール呼び出しのフォーマットは、あらゆるモデル統合において最もバージョンに敏感な部分であり、プロバイダーのアップデート後に最も破損しやすいものです。

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Is the checkout-api service healthy?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "Returns the current status of a named deployment.",
        "parameters": {
          "type": "object",
          "properties": {
            "service": {"type": "string", "description": "The service name."}
          },
          "required": ["service"]
        }
      }
    }
  ]
}

アサーション：

choices[0].message.tool_callsが存在し、空ではないこと
choices[0].message.tool_calls[0].function.nameがget_deployment_statusと等しいこと
choices[0].finish_reasonがtool_callsと等しいこと

ツール呼び出しの存在だけでなく、関数名でアサートすることで、より微妙な失敗（誤ったツールを呼び出すモデル）を検出できます。1つのツールしか定義されていない場合は可能性は低いですが、このアサーションはコストがかからず、ツールを追加しても正しく機能します。

すでに所有しているAPIからツール定義を生成している場合、OpenAPI仕様をエージェントツールに変換することで、手動でスキーマを記述することなくそれを行うことができます。

GLM-5.3との比較

ここに、モデルIDを環境変数に入れることのメリットがあります。

環境を複製し、modelをglm-5.3に変更して、同じコレクションを実行します。比較すべき3つの点：

正確性。 アサーションはまだパスしますか？GLM-5.3はネイティブで画像を受け付けないため、画像リクエストはパスしません。それは発見であり、壊れたテストではありません。

レイテンシー。 Apidogはリクエストごとの応答時間を報告します。GLM-5.3はFlashの49トークン/秒に対し、約86トークン/秒で生成するため、長い出力ではGLM-5.3の方が早く完了すると予想されます。

コスト。 usageオブジェクトは、呼び出しごとにprompt_tokensとcompletion_tokensを提供します。各モデルのレートで乗算すると、ブレンドされたマーケティング数値ではなく、実際の1リクエストあたりのコスト比較が得られます。弊社の料金内訳には現在のレートが記載されており、完全なモデル比較ではそれぞれのモデルがどの点で優れているかを説明しています。

reasoning_effort設定全体でcompletion_tokensを注意深く監視してください。reasoning_effortがデフォルトのmaxの場合、推論トークンは出力として課金されるため、短い目に見える回答でもその背後には多数の完了トークンが含まれている可能性があります。low、high、maxで同じプロンプトを実行し、トークン数を読み取ることは、ワークロードが実際に何を必要としているかを決定する最速の方法です。

ローカルデプロイメントのテスト

ウェイトをセルフホストしている場合、vLLMとSGLangは両方ともOpenAI互換のエンドポイントを公開しています。base_urlをサーバーに変更し、同一のコレクションを実行します。

これはスイートの最も価値の高い使用法です。量子化されたビルドは基本的なチャットテストには合格しても、ツールスキーマの処理を誤ったり、画像入力で性能が低下したりする可能性があり、これらはまさにスモークチェックではなく本番環境で現れる失敗です。弊社のローカル実行ガイドでは、デプロイメント側について説明しています。

CIに組み込む

コレクションが安定したら、スケジュールで、またはパイプライン内で実行します。役立つトリガー：

モデル移行前に、実行可否のシグナルとして。
スケジュールに基づいて、知らされていないプロバイダー側の変更を検出するため。
依存関係の更新後に、SDKの変更がリクエストのシリアル化を変化させる可能性があるため。

モデルプロバイダーは、安定したIDの背後でモデルを更新します。スケジュール実行は、ユーザーから聞くのではなく、動作が変化したことを知る方法です。

ハッピーパス以外でテストすべきこと

基本がパスしたら追加すべきいくつかのケース：

実際に使用する長さでの長文コンテキストリクエスト。5Kトークンでの動作は、500Kトークンでの動作を意味するものではありません。
不正な入力で、エラー処理が実行されることを確認します。
レート制限応答（トリガーできれば）で、リトライロジックが機能することを確認します。
1つのリクエストで複数の画像（アプリケーションの一部である場合）。各画像には独自のimage_urlブロックが必要です。
ストリーミング（使用する場合）。標準的な補完とは応答の形状が異なるため。

まとめ

ここでの価値は個々のリクエストではなく、それらが繰り返し可能であることです。30秒で再テストできるモデル選択は、9月9日に価格が変更されたとき、Z.aiが次の改訂版を出荷したとき、または誰かが完全に異なるプロバイダーへの移行を提案したときに、再検討できる決定となります。

Apidogは無料で開始でき、OpenAI互換のスキーマをインポートするだけで、各リクエストを手動で構築することなく、このセットアップのほとんどを得ることができます。最終的に得られるコレクションは、次回のモデル交換を大躍進ではなく、差分変更にするものです。

よくある質問

有料のApidogプランが必要ですか？ いいえ。環境変数とアサーションを含むコレクションは、無料プランで機能します。

読みにくいリクエストボディなしでbase64画像をテストするにはどうすればよいですか？ データURLを環境変数として保存し、ボディ内で{{test_image_url}}として参照します。

同じ方法でコーディングプランのエンドポイントをテストできますか？ はい。base_urlをhttps://api.z.ai/api/coding/paas/v4に変更してください。このエンドポイントは標準APIのものとは異なることに注意してください。これは、弊社のClaude Code and Clineガイドで説明されています。

これらのテストは他のプロバイダーに対しても機能しますか？ ほとんどの場合機能します。OpenRouter、Cloudflare Workers AI、Vercel AI GatewayはすべてOpenAI互換のインターフェースを公開しています。base_urlとモデルIDのネームスペースを変更してください。

非決定的な応答に対してアサートするにはどうすればよいですか？ 正確なテキストではなく、構造と制約に対してアサートします。フィールドの存在、型、トークン数、finish_reason、そして既知の答えを持つ質問に対する部分文字列の包含などです。