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

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

Claudeは画像を28×28ピクセルのパッチ単位でトークン化します。⌈幅/28⌉×⌈高さ/28⌉という計算式と、標準・高解像度2つのティアの違い、モデル別の概算コストをまとめます。

画像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スキャン、後述)

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

モデルごとに上限が違う — 標準ティアと高解像度ティア

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

解像度ティア対象モデル長辺の上限ビジュアルトークンの上限
高解像度対象モデルClaude 4.7以降のモデル長辺の上限2,576pxビジュアルトークンの上限4,784
標準対象モデルそれ以外のモデル長辺の上限1,568pxビジュアルトークンの上限1,568

Computer Useツールセットに対応するモデルはすべてこのティアに入ります。高解像度ティアは、ベータヘッダーやオプトインの指定なしに、対象モデルで自動的に適用されます。高解像度ティアのビジュアルトークン上限(4,784)は、標準ティア(1,568)のおよそ3倍です。高い精度が必要な画像認識ではこの差が効きますが、必要のない用途で高解像度ティアのモデルを使うと、想定より多くのトークンを消費することにもつながります。

画像サイズ別の実際のトークン数

具体的なサイズでどれだけ差が出るかは、次の早見表のとおりです。

画像サイズ標準ティア: 縮小後標準ティア: トークン数高解像度ティア: 縮小後高解像度ティア: トークン数
200×200px(0.04メガピクセル)標準ティア: 縮小後縮小なし標準ティア: トークン数64高解像度ティア: 縮小後縮小なし高解像度ティア: トークン数64
1000×1000px(1メガピクセル)標準ティア: 縮小後縮小なし標準ティア: トークン数1,296高解像度ティア: 縮小後縮小なし高解像度ティア: トークン数1,296
1092×1092px(1.19メガピクセル)標準ティア: 縮小後縮小なし標準ティア: トークン数1,521高解像度ティア: 縮小後縮小なし高解像度ティア: トークン数1,521
1920×1080px(2.07メガピクセル)標準ティア: 縮小後1456×819pxに縮小標準ティア: トークン数1,560高解像度ティア: 縮小後縮小なし高解像度ティア: トークン数2,691
2000×1500px(3メガピクセル)標準ティア: 縮小後1269×952pxに縮小標準ティア: トークン数1,564高解像度ティア: 縮小後縮小なし高解像度ティア: トークン数3,888
3840×2160px(8.29メガピクセル・4K)標準ティア: 縮小後1456×819pxに縮小標準ティア: トークン数1,560高解像度ティア: 縮小後2576×1449pxに縮小高解像度ティア: トークン数4,784

小さい画像ではティアによる差がほぼ出ません。差が開くのは、縮小が発生するかどうかの境界線付近です。1920×1080pxのフルHD画像は、標準ティアでは縮小されて1,560トークンに収まる一方、高解像度ティアでは縮小されずそのまま2,691トークンを消費します。同じ画像でも、モデルによって1.7倍以上コストが変わることになります。

画像が縮小されるときは、ティアの上限に収まる最大サイズまでアスペクト比を保ったまま縮められます。縮小後、Claudeはさらに画像を28の倍数まで右端・下端にパディングしますが、パディング部分には情報が無く、コストにも影響しません。

モデル別の概算コスト試算

トークン数に、使っているモデルの単価を掛ければ概算コストが出ます。具体例では、Claude Haiku 4.5(標準ティア、入力100万トークンあたり1ドル)の場合、1000×1000pxの画像は1,000枚あたり約1.30ドルです。Claude Opus 5(高解像度ティア、入力100万トークンあたり5ドル)の場合、同じ画像は1,000枚あたり約6.48ドル、4K画像(3840×2160px)なら1,000枚あたり約23.92ドルになります。

縮小の落とし穴 — 長辺が上限内でもトークン上限で縮まることがある

長辺の上限だけを見て「1568px以内だから縮小されない」と判断すると、実際には縮小されているケースを見落とします。ビジュアルトークンの上限は、長辺の上限とは独立にもう1つの制約として働くためです。

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

高解像度ティアのモデルであれば、同じ1075×1520pxのスキャンは縮小されません。2,145トークンは高解像度ティアの上限(4,784)に収まるためです。座標を扱うワークフローでは、この縮小がいつ起きるかによって、Claudeが返す座標の基準となる画像サイズが変わります。縮小後の座標をそのまま自分のアプリケーションの座標系へ当てはめると、原寸大の画像に対してズレが生じます。

リクエストに画像を20枚超入れると上限がさらに厳しくなる

トークン計算式そのものとは別に、1リクエストに含める画像の枚数によっても制約が変わります。1つのAPIリクエストに20枚を超える画像を含めると、そのリクエスト内のすべての画像に、より厳しいピクセル制限が一律で適用されます。会話の以前のターンから再送信される画像や、tool_resultに含まれる画像(コンピュータ操作ツールが返すスクリーンショットなど)もこの枚数に数えられます。

この制限を超えると、画像は自動的に縮小されるのではなく、invalid_request_errorとしてリクエストごと拒否されます。エラーメッセージには許容される上限がピクセル単位で示されます。安全に運用するなら、各画像の長辺を2000px以下に抑えるか、1リクエストあたりの画像・文書ブロックを20個以下に保つかのどちらかです。長時間のエージェントループでスクリーンショットを蓄積させる用途では、この枚数制限に途中から抵触することがあるため、古い画像を間引く設計が必要になります。実際にComputer Useツールでスクリーンショットを扱う場合の座標補正やキャッシュ設計は、Computer Useの座標ズレを直すスケーリング計算式で詳しく扱っています。

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

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

逆に言えば、同じ画像を毎ターン律儀に送り直すと、その分だけ余計なトークンを毎回課金されることになります。長い対話で同じ画像セットを参照し続けるアプリケーションほど、この重複送信のコストは見えにくく積み上がりやすいので、実装時に注意します。

コストを抑えたいときにまず見る場所

画像のトークンコストを抑える一番簡単な方法は、アップロード前の事前リサイズです。Claudeに送る前に画像を圧縮・リサイズしておけば、送信時点で不要な高解像度を避けられます。特に、テキストの視認性が重要でない写真や、コンピュータ操作の一般的な画面確認のような用途では、高解像度ティアの精度がそもそも要らないことも多く、画像を縮小してから送るだけでトークン数を大きく減らせます。

反対に、小さな文字やUI要素を正確に読み取らせたい用途では、解像度を無理に落とすとテキストが判読できなくなり、精度が落ちます。この場合は解像度を保ったまま、対象領域だけを切り出して送る(全体を高解像度で送るのではなく、必要な部分だけを拡大して送る)ほうが、コストと精度の両方で有利です。画像認識で何が得意で何が不得意かはClaude画像解析でできることにまとめているので、そもそも高解像度が必要なタスクかどうかの判断はそちらもあわせて確認してください。

圧縮も注意が要ります。JPEGやWebPのロッシー圧縮でファイルサイズを減らすとリクエストは軽くなりますが、圧縮を何度も重ねるとテキストが読みにくくなるノイズが乗り、精度が落ちることがあります。トークン数そのものは画像の解像度で決まり、ファイルサイズやフォーマットの圧縮率では変わらない点も押さえておくと、「軽くしたのにトークンが減らない」という誤解を避けられます。

画像1枚あたりのサイズにも上限があります。画像1枚あたりの最大寸法は8000×8000px、ファイルサイズはClaude API直接利用で10MB(base64エンコード後)、Amazon BedrockとGoogle Cloudでは5MBです。上限を超えるサイズの画像は、リクエストごと拒否されるかリサイズされるかが状況によって変わるため、大きな画像を扱う場合は事前のリサイズを組み込んでおくのが安全です。

PDFを送る場合も同じ計算式が適用されます。PDFの各ページは画像に変換されて処理されるため、ページ数が多い文書ほど、この画像トークンコストがそのまま積み上がります。ページごとのテキスト抽出コストは1ページあたりおおむね1,500〜3,000トークンが目安とされており、この画像トークンとは別枠で発生する費用なので、PDF全体のコストを見積もる際は両方を合算して考える必要があります。PDFの読み込み方法自体はClaudeのPDF読み込み・画像解析の使い方で扱っているので、アップロード手順から知りたい場合はそちらを先に確認してください。

まとめ

Claudeの画像トークンコストは⌈幅/28⌉×⌈高さ/28⌉という単純な式で決まりますが、実際の請求額はモデルの解像度ティア(標準1,568トークン・高解像度4,784トークン)によって大きく変わります。長辺の上限内に収まっていても、ビジュアルトークンの上限で縮小されることがあるため、A4スキャンのような一見小さい画像でも油断できません。1リクエストに20枚を超える画像を含める場合は、さらに厳しいピクセル制限が別枠でかかる点も見落としやすいところです。コストを抑えたいなら、精度が本当に必要な場面を見極めたうえで、アップロード前のリサイズを検討するのが確実です。

この記事を共有:XはてブLinkedIn