Akira

Posted on Aug 27 Originally published at apidog.com

GLM-5.3-Flash Vision: 1Mコンテキストモデルへの画像送信

ほとんどのビジョンモデルでは、画像か大量のテキストのどちらかを優先する必要があります。GLM-5.3-Flashは、画像をコンテンツブロックとして受け取り、同一リクエスト内で最大1,048,576トークンのテキストコンテキストと組み合わせられます。

今すぐApidogを試す

このガイドでは、画像入力のペイロード、実装価値のあるワークフロー、検証すべき制限とコスト管理を説明します。

ネイティブな画像入力

以前のZ.aiのビジョンモデルであるGLM-5V-TurboとGLM-4.6Vは、個別のモデルID・エンドポイントとして提供されていました。GLM-5.3もビジョンをアダプター経由で処理します。

GLM-5.3-Flashでは、画像とテキストが同じモデル、同じコンテキスト、同じリクエストに含まれます。つまり、モデルID・請求・レート制限を分けずに、画像と長文仕様を同時に扱えます。

既存モデルを使う場合は、GLM-5V-Turbo APIガイドとGLM-4.6Vガイドを参照してください。

ペイロードを作成する

画像入力では、contentを文字列ではなく型付きブロックの配列として渡します。

from openai import OpenAI
import os

client = OpenAI(
    [REDACTED CREDENTIAL],
    base_url="https://api.z.ai/api/paas/v4/",
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is wrong with this layout on mobile?"}, # モバイルでのこのレイアウトのどこが間違っていますか？
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/mobile-view.png"},
                },
            ],
        }
    ],
)

print(response.choices[0].message.content)

ローカルまたは非公開画像には、Base64データURLを使います。

import base64
from pathlib import Path

def image_block(path: str) -> dict:
    data = base64.b64encode(Path(path).read_bytes()).decode("utf-8")
    suffix = Path(path).suffix.lstrip(".").replace("jpg", "jpeg")
    return {
        "type": "image_url",
        "image_url": {"url": f"data:image/{suffix};base64,{data}"},
    }

複数画像では、画像ごとにimage_urlブロックを追加します。

content = [
    {"type": "text", "text": "Image 1 is the design. Image 2 is what we built. List the differences."}, # 画像1はデザインです。画像2は私たちが構築したものです。違いをリストアップしてください。
    image_block("design.png"),
    image_block("built.png"),
]

ブロックの順序は重要です。画像の前に目的やラベルを置き、「画像1はデザイン」「画像2は実装結果」のように明示してください。モデルが画像間の情報を取り違えにくくなります。

認証と基本設定はGLM-5.3-Flash APIガイドを参照してください。

実装する価値のあるワークフロー

スクリーンショットデバッグ

壊れたレンダリングと、そのレンダリングを生成したソースコードを同一リクエストに入れます。

content = [
    {"type": "text", "text": "This component renders incorrectly below 400px. Here is the screenshot and the source."}, # このコンポーネントは400px未満で正しくレンダリングされません。これがスクリーンショットとソースです。
    image_block("bug-mobile.png"),
    {"type": "text", "text": f"```
{% endraw %}
jsx\n{component_source}\n
{% raw %}
```"},
]

人間が視覚的な不具合を文章へ変換する必要がなくなります。モデルは説明ではなく、実際のレンダリングを基に問題を推論できます。

デザイン比較

デザインと実装結果を2枚の画像として渡し、差分を尋ねます。CIでは、視覚的リグレッションのソフトチェックとして使えます。

ただし、モデルの判断だけでデプロイを停止させるべきではありません。ピクセル差分ツールは変更箇所を示し、モデルはその重要性をトリアージする用途に向いています。最終判断は人間または決定的な検証に委ねてください。

仕様と成果物の照合

100万トークンのコンテキストは、長い仕様とレンダリング済み成果物の比較で特に有効です。

content = [
    {"type": "text", "text": f"Specification:\n\n{spec_text}"}, # 仕様：\n\n{spec_text}
    {"type": "text", "text": "Below is the generated report. Does it satisfy every requirement above? List gaps."}, # 以下は生成されたレポートです。上記のすべての要件を満たしていますか？不足点をリストアップしてください。
    image_block("generated-report.png"),
]

40ページ程度の仕様と画像を単一プロンプトで照合できる点は、128Kコンテキストとアダプターベースのビジョンでは難しかった用途です。Z.aiは、オフィス文書や金融調査もエージェント的な利用例として挙げています。

チャートとダッシュボードの抽出

チャート画像から構造化データを取り出す場合は、JSONのみを返すよう要求し、必ずスキーマ検証を行います。

content = [
    {"type": "text", "text": "Extract the series in this chart as JSON: [{label, values: [...]}]. Return only JSON."}, # このチャートのシリーズをJSON形式で抽出してください：[{label, values: [...]}]. JSONのみを返してください。
    image_block("quarterly.png"),
]

モデルの出力は信頼せず、検証してください。スキーマ検証は値そのものの誤りを防げませんが、形式・構造の誤りは検出できます。専用の文書抽出が必要なら、ドキュメント理解のためのGLM-OCRも検討できます。

ビデオとファイル入力

Z.aiのドキュメントでは、画像と同じコンテンツブロック機構でビデオとファイルも入力できるとされています。

ただし、ビデオ対応は新しく、公開された検証例も多くありません。モデルが機能を持つことと、利用するゲートウェイでその機能を呼び出せることは別です。ビデオが重要な要件なら、設計前に自分のメディア・プロバイダー・利用経路で直接テストしてください。

事前に検証すべき制限

チャート上の数値

線や棒から値を読むタスクでは、もっともらしいが誤った数値が返る可能性があります。重要な数値は画像ではなく、元データから取得してください。

小さい文字

密度の高いUI、低解像度テーブル、圧縮されたコード画像では精度が低下します。フレーム全体を縮小するより、関心領域を切り出して送信してください。

空間的な測定

「ボタンが入力欄と重なっている」のような定性的な指摘は得意ですが、「左に12pxずれている」のような正確な測定は信頼できません。

複数画像の参照混同

複数画像を送る場合、詳細を別の画像に帰属させることがあります。テキストで明確にラベル付けし、精度が重要なタスクでは画像数を絞ってください。

これらはGLM-5.3-Flash固有ではなく、ビジョン言語モデルに共通する制限です。誤答がそのまま行動につながらず、検出されるようにワークフローを設計してください。

コストを管理する

画像は入力コンテキストトークンとして課金され、画像専用の追加料金はありません。

リスト価格は100万入力トークンあたり0.15ドルで、2026年9月9日まではローンチ割引で0.075ドルです。高解像度画像ほどトークンを消費するため、解像度は直接的なコストレバーになります。

reasoning_effortのデフォルトはmaxで、推論トークンは出力トークンとして課金されます。単純な抽出では通常lowで十分です。詳細はGLM-5.3-Flashの料金内訳を参照してください。

画像トークンを削減する手順

縮小前にトリミングする。 画面全体を半解像度で送るより、必要な領域をフル解像度で送る方が有効です。
質問に合わせて解像度を決める。 レイアウト崩れの判定は縮小に耐えますが、エラーメッセージの読取りは耐えません。
変更されていない画像を再送信しない。 マルチターン会話では、すでに送信した画像はコンテキストに残っています。再添付は再課金につながります。
reasoning_effortを明示する。 単純な抽出にmaxは通常不要です。

各レスポンスのusageオブジェクトで、実際のトークン消費量を確認してください。画像ファイルサイズから推測するより確実です。

マルチモーダル呼び出しをテストする

Base64データURLは長く、curlでの手動テストや再実行には向きません。また、自由形式の応答ではリグレッションを見落としやすくなります。

次の2つを習慣化してください。

参照画像と期待回答の小さな固定セットを維持する。
構造化抽出は目視で確認せず、JSONスキーマで検証する。

Apidogでは、画像を含むリクエストを保存し、APIキーを環境変数として管理し、JSON応答にアサーションを追加できます。モデルやプロバイダーを変更したときはテストスイートを再実行し、ユーザーから報告される前にビジョン経路の回帰を検出してください。

FAQ

GLM-5.3も画像をサポートしていますか？

ネイティブには対応していません。GLM-5.3は別アダプター経由でビジョンを処理します。Flashはネイティブなマルチモーダルモデルです。詳細はGLM-5.3-FlashとGLM-5.3の比較を参照してください。

1リクエストに何枚の画像を含められますか？

複数可能です。各画像を独自のimage_urlブロックとして指定します。実用上の上限はコンテキスト予算によって決まります。

URLとBase64のどちらを使うべきですか？

アクセス可能なホスト済み画像にはURL、ローカルまたは非公開画像にはBase64を使います。

ビデオも入力できますか？

Z.aiはビデオ入力を文書化していますが、新しく、検証例も限られます。導入前に自分のメディアとプロバイダーで確認してください。

画像の課金方式は異なりますか？

画像専用の追加料金はありません。入力トークンを消費するため、解像度がコストに影響します。

DEV Community