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

GLM-5.3-Flashは、1Mトークンのウィンドウ内で画像をネイティブに取り込みます。image_urlペイロード、スクリーンショットのデバッグ、グラフの抽出、そして失敗する箇所。

INEZA Felin-Michel

INEZA Felin-Michel

27 8月 2026

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

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

ほとんどのビジョンモデルでは、選択を求められます。画像を送信することも、大量のテキストを送信することもできますが、一方をうまく処理するモデルは、もう一方をうまく処理することはめったにありません。

GLM-5.3-Flashは、選択を強要しません。他のすべてと同じリクエスト内で、1,048,576トークンのコンテキストウィンドウ内にコンテンツブロックとして画像を受け入れます。ネイティブな画像入力と100万トークンの組み合わせは、どちらか一方の機能だけでは不可能だったワークフローを可能にします。

このガイドでは、ペイロード、構築する価値のあるワークフロー、そしてまだ未検証の部分について説明します。

アダプターベースではなく、ネイティブ

Z.aiの以前のビジョン関連の作業は、別々のモデルとして出荷されました。GLM-5V-TurboとGLM-4.6Vは、個別のモデルIDを持つ個別のエンドポイントであり、これらを使用するということは、画像トラフィックをテキストトラフィックとは別の場所にルーティングすることを意味しました。このモデルのより大きな兄弟であるGLM-5.3は、ビジョンをネイティブに処理するのではなく、アダプターを介してルーティングします。

GLM-5.3-Flashは、GLM-5シリーズで、画像が同じモデルへの第一級入力として、同じ呼び出しで、同じコンテキストを共有する最初のモデルです。

実用的に言えば、これは1つのモデルID、1つの請求行、1つのレート制限のセットを意味し、そして最も重要なことに、画像とテキストの両方を一度に保持する1つのコンテキストウィンドウを意味します。もし古いパスで何かを管理している場合は、GLM-5V-Turbo APIガイドGLM-4.6Vガイドがそれらのモデルについて説明しています。

ペイロード

画像入力は型付きコンテンツブロックを介して機能します。`content`が文字列である代わりに、配列になります。

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["ZAI_API_KEY"],
    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}"},
    }

複数の画像は複数のブロックを意味します。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はデザインです」というテキストは、モデルがその回答を固定するための何かを与えます。

基本的な設定と認証は、当社のAPIガイドで説明されています。

構築する価値のあるワークフロー

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

明白なものであり、Z.aiが依拠しているものです。その資料では、モデルが「インターフェース、レンダリング結果、インタラクションフィードバック」を観察すると記述されており、これは写真の説明というよりもコーディングエージェントのフレームワークです。

壊れたレンダリングとそれを生成したソースを同じリクエストで送信します。

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"```jsx\n{component_source}\n```"},
]

モデルは、あなたの説明ではなく、実際のレンダリングについて推論します。これにより、ほとんどのフロントエンドデバッグ会話で最も情報が失われるステップ、つまり人間が視覚的な問題を言葉に翻訳するというステップがなくなります。

デザイン比較

2つの画像と質問。CIで視覚的なリグレッションのソフトチェックとして役立ちます。差分ツールはピクセルが変更されたことを伝えますが、モデルはその変更が重要かどうかを教えてくれます。

ここでの信頼性については現実的になりましょう。スクリーンショットを比較するモデルは判断であり、断定ではありません。人間の目でどの差分を見るべきかをトリアージするために使用し、それ自体でデプロイをゲートするために使用すべきではありません。

ドキュメントと仕様の並列分析

ここに1Mコンテキストが活かされる場所があります。長い仕様をテキストとしてプロンプトに入れ、レンダリングされた成果物を画像として入れ、それらが一致するかどうかを尋ねます。

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"),
]

1つのプロンプトで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のドキュメントでは、画像と並んでビデオとファイル入力が、同じコンテンツブロックメカニズムを使用して記載されています。

これには注意が必要です。このモデルのビデオサポートは新しく、ドキュメントが薄く、多くの人がすでに実行している画像入力と比較して、一般に公開されているエクササイズが少ないです。プロバイダーのサポートも異なります。モデルの機能は、呼び出し元のゲートウェイで利用可能な機能と同じではありません。

ビデオがアプリケーションにとって重要である場合は、設計する前に、独自のメディアとプロバイダーに対して直接テストしてください。機能表の一行を動作する機能として扱わないでください。

限界

ネイティブなマルチモダリティは、信頼性の高いマルチモダリティと同じではありません。出荷する前に知っておくべき4つの障害モードがあります。

チャートからの確信的な数値。プロットされた線から値を読み取るタスクは、流暢で正確にフォーマットされた、しかし間違った答えを生み出す可能性が最も高いものです。スキーマ検証は不正な出力を捕捉しますが、もっともらしいが単に不正確な数値を捕捉することはできません。数値が重要である場合は、その画像からではなく、基礎となるデータから取得してください。

小さなテキスト。密度の高いUIスクリーンショット、低解像度でキャプチャされたテーブル、圧縮された画像内のコードはすべて劣化します。トークンを節約するためのダウンスケーリングはこれをさらに悪化させるため、コストレバーと精度との間には直接的な緊張関係があります。フレーム全体を縮小するのではなく、関心のある領域を切り取ってください。

空間的精度。モデルはレイアウトをうまく記述しますが、正確に測定することは苦手です。「ボタンが入力と重なっている」は通常正しいですが、「ボタンが左に12ピクセルずれている」は通常そうではありません。

順序と参照の混乱。1つのリクエストに複数の画像がある場合、モデルが詳細を間違った画像に帰属させる可能性があります。テキストブロックで明示的にラベルを付け、精度が重要な場合は数を少なくしてください。

これらはGLM-5.3-Flashに固有のものではありません。これらはビジョン言語モデルの標準的な限界であり、57の知能指数スコアもそれを免除しません。間違った答えが行動されるのではなく、捕捉されるようにワークフローを設計してください。

コスト

画像はコンテキストトークンを消費し、入力として課金されます。別途画像追加料金はありません。

リスト価格では100万入力トークンあたり0.15ドル、2026年9月9日までのローンチ割引期間中は0.075ドルです。高解像度画像はかなりの数のトークンを消費するため、解像度がコストレバーとなります。詳細がリクエストのポイントでない限り、送信前にダウンスケールしてください。

`reasoning_effort`はデフォルトで`max`であり、推論は出力トークンとして課金されます。画像からの簡単な抽出の場合、通常は`low`が適切な設定であり、大幅に安価です。当社の料金内訳は、両方のレバーについて説明しています。

画像コストを管理する

画像は入力トークンとして課金されるため、解像度が直接的なコストレバーであり、明白な最適化は上記の精度の注記と対立します。

実行可能な操作順序:

  1. スケーリングする前にトリミングする。関連する領域をフル解像度で送信する方が、画面全体を半分で送信するよりも優れています。モデルに不要なコンテキストを失い、必要な詳細を保持します。
  2. 質問に合わせて解像度を調整する。「レイアウトが壊れているか?」は積極的なダウンスケーリングに耐えますが、「このエラーメッセージは何と言っているか?」は耐えません。
  3. 変更されていない画像を再送信しない。マルチターンの会話では、一度送信された画像はすでにコンテキスト内にあります。ターンごとに再添付すると、ターンごとに料金がかかります。
  4. `reasoning_effort`を意図的に設定する。デフォルトは`max`であり、推論は出力として課金されます。簡単な抽出にはめったに必要ありません。

各応答の`usage`オブジェクトは、呼び出しごとの実際のトークン数を示します。これは、画像のファイルサイズから推測するのではなく、実際にいくらかかったかを知る唯一の方法です。

マルチモーダル呼び出しのテスト

マルチモーダルリクエストは手動でのテストが困難です。Base64データURLは何千もの文字で構成されており、curlコマンドを読みにくくし、編集して再実行することは事実上不可能です。応答は自由形式のテキストであるため、リグレッションを見落としやすいです。

2つの習慣が役立ちます。参照画像と期待される回答の小さな固定セットを保持することで、動作が変化したときにそれを判断できます。そして、構造化抽出は目視ではなく、スキーマに対して検証します。

Apidogはこれに適したツールです。シェルコマンドの代わりに保存されたリクエストに画像ペイロードを保存し、APIキーを環境変数として保持し、抽出プロンプトが返すJSONにアサーションを添付します。モデルを切り替えたり、プロバイダーが何かを更新したりした場合、スイートを再実行することで、ユーザーから知らされる前に、ビジョンパスがまだ機能しているかどうかを知ることができます。

FAQ

GLM-5.3も画像をサポートしていますか?ネイティブにはサポートしていません。GLM-5.3は、別のアダプターを介してビジョンをルーティングします。Flashはネイティブにマルチモーダルなモデルであり、当社の比較で説明されています。

1リクエストあたり何枚の画像が可能ですか?複数可能です。それぞれが独自の`image_url`ブロックとして扱われます。実用的な限界はコンテキスト予算によります。

URLとBase64のどちらですか?どちらも機能します。画像がすでにホストされていてアクセス可能であればパブリックURLを使用し、ローカルまたはプライベートな画像にはBase64を使用します。

ビデオを受け入れますか?Z.aiはビデオ入力を文書化していますが、新しく、使用例は少ないです。まず、独自のメディアとプロバイダーで検証してください。

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

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる