Claudeの画像のトークンコスト計算式 — 28×28パッチと高解像度ティア

画像1枚のトークンコストはどう決まるか

Claudeは画像をピクセルの集まりとしてではなく、28×28ピクセルのパッチ単位で処理します。このパッチ1つが「ビジュアルトークン」1個に相当し、画像のトークンコストは次の式で決まります。

トークン数 = ⌈幅 / 28⌉ × ⌈高さ / 28⌉

幅・高さをそれぞれ28で割り、余りが出れば切り上げて掛け合わせます。1000×1000pxの画像なら⌈1000/28⌉ × ⌈1000/28⌉ = 36 × 36 = 1296トークンです。式はコードにすると次のようになります。

import math
 
def visual_tokens(width, height):
    """28x28ピクセルのパッチ1つが1ビジュアルトークン"""
    return math.ceil(width / 28) * math.ceil(height / 28)
 
visual_tokens(1000, 1000)  # 1296
visual_tokens(1075, 1520)  # 2145(A4スキャン、後述)

切り上げがあるので、28の倍数をわずかに超えただけでコストは跳ねます。28×28pxなら1トークンですが、29×29pxは2 × 2 = 4トークンです。280×280pxなら10 × 10 = 100トークンで、281×281pxになると11 × 11 = 121トークンです。1ピクセルの違いで21%増えるので、小さなサムネイルを大量に送るときは、端数の切り上げが無視できなくなります。

対応形式はJPEG・PNG・GIF・WebPの4種類です。アニメーションGIFやWebPを送っても最初の1フレームだけが使われ、動きの情報は失われます。

同じ画像でもモデルで請求が変わる — 標準ティアと高解像度ティア

式がそのまま使えるのは、画像が縮小されないときだけです。各モデルには「長辺の上限ピクセル数」と「ビジュアルトークンの上限」の2つの制約があり、どちらかを超える画像は処理前に縮小されます。

高解像度ティアは、ベータヘッダーやクライアント側のオプトインなしに、対象モデルで自動的に適用されます。

上限そのものは3倍ほど違います(4,784対1,568)が、実際の差は画像の大きさ次第です。小さな画像ではティアによる差が出ません。差が出始めるのは、標準ティアで縮小が起きる大きさからです。画像が大きいほど差は開き、4Kでは1,560対4,784と約3倍になります。

サイズ別のトークン数 — 公式の例と実務でよくある画像

まず公式ドキュメントの早見表です。

公式のリファレンス実装で2000×1500pxを計算すると1270×952pxになり、表の1269×952pxと1px異なります。トークン数はどちらも1,564で変わりません。座標を換算するときは、実装の値を使います。

例はどれも横長の画像です。スマートフォンのスクリーンショットや正方形に近い写真は載っていないので、同じ縮小ルールを公式のリファレンス実装(後述)で動かし、手元で計算した結果を並べます。

読み取れるのは3点です。縦長のスマホ画面は、標準ティアでは1,456トークンに頭打ちになる一方、高解像度ティアでは原寸のまま3,000トークン台に乗ります。パノラマのような極端に細長い画像は、トークン上限ではなく長辺の上限で縮小されるため、どちらのティアでも上限よりはるかに少ないトークンで済みます。公式の説明でも、ほとんどの写真やスクリーンショットではトークン上限が縮小後のサイズを決め、長辺の上限が効くのはパノラマや縦長のスマホ画面のような細長い画像に限られます。

縮小の計算は手計算に向きません。1920×1080pxを「長辺1,568pxに合わせて1568×882px」と見積もると外れ、実際の縮小後は1456×819pxです。縮小後のサイズは、リファレンス実装(二分探索で、両方の上限に収まる最大のサイズを探します)で求めるのが確実です。

縮小はどう決まるか — 判定の順序

長辺が上限内でも縮小される — A4スキャンの座標ズレ

長辺の上限だけを見て「1568px以内だから縮小されない」と判断すると、実際には縮小されているケースを見落とします。座標ズレの原因として、もっとも多いパターンです。

A4サイズの書類を130DPIでスキャンすると、1075×1520pxになります。どちらの辺も標準ティアの長辺上限(1568px)を下回っていますが、トークン数は⌈1075/28⌉ × ⌈1520/28⌉ = 39 × 55 = 2,145で、標準ティアの上限(1,568)を超えます。このためClaudeは924×1307pxまで画像を縮小します。縮小後のトークン数は33 × 47 = 1,551で、上限に収まります。

高解像度ティアのモデルなら、同じスキャンは縮小されません。2,145トークンが上限の4,784に収まるためです。モデルを標準ティアから高解像度ティアへ切り替えると、返ってくる座標の基準が縮小後の924×1307pxから原寸の1075×1520pxへ変わります。切り替え前に補正を組み込んでいたアプリケーションは、そのままだと座標がずれます。

縮小後の座標を原寸大の画像に当てはめるとズレが出るので、対策は2つあります。1つはAPIに送る前に自分で縮小しておくことで、こうすれば座標が送った画像とそのまま対応します。もう1つは、縮小後のサイズを同じ式で求めて、返ってきた座標を原寸へ換算する方法です。換算するときは、パディング後のサイズ(924×1316px)ではなく縮小後のサイズ(924×1307px)で割ります。パディング後のサイズで割ると、すべての座標がわずかに縮みます。

oversized_imageはtransformationsフィールドに置く設定で、画像ブロックごとに指定します。Token countingエンドポイントでも同じ検査が効くので、推論を走らせる前に「縮小されずに通るか」を確認できます。ただし、URLやファイルIDで渡した画像は、Token countingでは取得されずに拒否されます。そうした画像はMessagesのリクエスト時にだけ検査されます。

画像の枚数と大きさの上限

トークン計算とは別に、1リクエストに入れられる画像の枚数にも上限があります。

画像1枚あたりの最大寸法は8000×8000pxです。ファイルサイズの上限は、Claude APIの直接利用とclaude.aiで10MB(APIではbase64エンコード後)、Amazon BedrockとGoogle Cloudでは5MB(base64エンコード後)です。600枚まで入れられる場合でも、リクエスト全体の上限(標準のエンドポイントで32MB)に先に達することがあります。枚数が多いときは、Files APIでアップロードしてfile_idで参照すると、リクエストを小さく保てます。

20枚を超えると1枚あたりの寸法制限が厳しくなる

1つのAPIリクエストに20枚を超える画像を含めると、そのリクエスト内のすべての画像に、より厳しい寸法制限が一律で適用されます。会話の以前のターンから再送信される画像や、tool_resultに含まれる画像(コンピュータ操作ツールが返すスクリーンショットなど)も、この枚数に数えられます。Amazon BedrockとGoogle Cloudでは、PDFなどのドキュメントブロックも同じ枚数に数えます。

制限を超えた画像は自動で縮小されず、invalid_request_errorとしてリクエストごと拒否されます。エラーメッセージには"many-image requests"という語句と、現在の上限(ピクセル単位)が入ります。回避策は、各画像の両辺を2000px以下にするか、画像とドキュメントのブロックを20個以下に保つかのどちらかです。

コンピュータ操作やブラウザ操作のツールが返すスクリーンショットには、別の規則があります。これらのツールにtool_resultで返すスクリーンショットやズーム画像がモデルの上限を超えていると、縮小されず検証エラーで拒否されます。ツールの結果として返す前に、アプリケーション側で縮小しておく必要があります。Computer Useでスクリーンショットを扱う場合の座標補正は、Computer Useの座標ズレを直すスケーリング計算式で詳しく扱っています。

複数ターンの会話で画像を送り直す必要はない

APIでは、以前のターンの画像も会話履歴として毎回送られます。履歴に残っている画像も、リクエストごとに入力トークンとして数えられます。会話が長いほど、画像のコストは積み上がります。

マルチターンの会話で画像について質問を続けるとき、新しいターンのcontentに同じ画像をもう一度入れる必要はありません。Claudeは以前のターンの画像すべてにアクセスできるので、「最初の2枚と似ていますか」のようなフォローアップ質問は、画像を含めずテキストだけで送れます。

逆に、同じ画像を新しいターンに重ねて入れると、履歴の分と合わせて二重に数えられます。前述のとおり画像の枚数も増えるため、20枚の境界を超えやすくなる点にも注意が必要です。

コストを抑えたいときの選択肢

トークン数は画像の解像度で決まります。ファイルサイズやフォーマットの圧縮率では変わりません。「JPEGを軽くしたのにトークンが減らない」のは、このためです。

トークン数を減らす方法は、送る前に画像を縮小することです。縮小の効果は、高解像度ティアのモデルで大きく出ます。画面の読み取りや高密度の文書で高解像度の精度が要らないなら、送る前に縮小するとコストを抑えられます。たとえば、4K画像を高解像度ティアで原寸のまま送ると4,784トークンですが、1920×1080pxに縮小して送れば2,691トークンです。

一方で、小さな文字が読み取れなくなるほど縮めると精度が落ちます。ガイダンスには「文字を大きく見せるためだけに、重要な周囲の文脈まで切り落とさない」ともあります。縮小と切り抜きは、読ませたい対象に応じて選びます。JPEGやWebPなどのロッシー圧縮は、リクエストを軽くしてレイテンシを下げる一方、圧縮を重ねるとノイズが乗り、モデルの性能が落ちることがあります。実際にAPIへ送る画像を目で確認して、圧縮設定が用途に合っているかを確かめます。画像認識の得意・不得意はClaude画像解析でできることにまとめています。

料金に換算する

トークン数に、使うモデルの入力単価を掛ければ、概算コストになります。

計算は「トークン数 × 入力単価 ÷ 100万 × 1,000」です。1,296トークンなら、Haiku 4.5で1,296 × $1 ÷ 1,000,000 × 1,000 = $1.296、Opus 5で1,296 × $5 ÷ 1,000,000 × 1,000 = $6.48になります。最新の単価は料金ページで確認してください。

PDFの場合

PDFにも同じ計算が適用されます。各ページは画像に変換され、そのページから抽出したテキストと並べて処理されます。1ページあたりのテキストトークンは、内容の密度によりおよそ1,500〜3,000トークンです。画像トークンはこれとは別に発生するので、PDFのコストは両方の合計で見積もります。ページ数の上限は、コンテキストウィンドウが1Mトークン未満のリクエストで100ページ、それ以外で600ページです。PDFの読み込み方法はClaudeのPDF読み込み・画像解析の使い方で扱っています。

まとめ

見積もりで確認する順番は、①画像の縦横から⌈幅/28⌉×⌈高さ/28⌉を出す、②使うモデルのティアの上限(1,568か4,784)を超えたら縮小後のサイズで数え直す、③その結果に単価を掛ける、の3つです。座標を使う用途では、モデルを切り替えるたびに縮小の有無が変わる点も確認します。