商品写真の自動タグ付けや検品写真の判定にClaudeの画像解析を組み込みたいが、「画像1枚でどれだけトークンを食うのか」が分からず見積もりが立てられない——という相談は多い。実際には画像コストは解像度から機械的に計算でき、設計次第で大きく圧縮できる。
画像1枚のコストはどう決まるか
Claudeは画像を28×28ピクセルの「視覚トークン」単位で見るため、コストは幅÷28と高さ÷28の積（切り上げ）で決まります。
公式ドキュメントが示す計算式は⌈幅/28⌉ × ⌈高さ/28⌉視覚トークンです。モデルには2段階の解像度上限があり、Claude 4.7以降の「高解像度」モデルは長辺2576px・最大4,784トークンまで処理し、それ以外のモデルは長辺1568px・最大1,568トークンが上限です。上限を超える画像はアスペクト比を保ったまま自動縮小されます。
具体例として、1000×1000px（約100万画素）の画像はどちらの階層でも縮小されず1,296トークン消費します。これをHaiku 4.5（入力$1/MTok）で処理すると1,000枚あたり約1.3ドル、Opus 5（入力$5/MTok）の高解像度処理でも1,000枚あたり6.48ドルです。一方、3840×2160pxの4K画像は高解像度帯で4,784トークンまで積み上がり、Opus 5では1,000枚あたり約23.9ドルになります。モデルと解像度の組み合わせで10倍近いコスト差が出る計算です。
画像枚数が増えるとどう変わるか
1リクエストに21枚以上の画像を含めると、全画像に長辺2000px以下という厳しい制限が自動適用されます。
APIの上限は200Kコンテキストモデルで1リクエスト最大100枚、それ以外は600枚です。ただし20枚を超えた瞬間に、会話履歴で再送される過去の画像やtool_result内のスクリーンショットも含めた全画像に、より厳しい寸法制限がかかります。超過するとinvalid_request_errorで拒否されるため、複数画像を扱うバッチ処理では事前リサイズが前提になります。
さらに重要なのが再送コストです。Base64で画像を埋め込むと、マルチターンの会話では過去の画像も毎リクエスト再送され、ペイロードと処理トークンが膨張します。繰り返し参照する画像はFiles APIで一度アップロードし、以降はfile_idで参照する設計にすると、リクエストサイズを会話の長さに依存させずに抑えられます。
低解像度で十分なケースはどこにあるか
検品の合否判定や商品カテゴリ分類など文字を読まない用途では、解像度を上げても精度は上がらずコストだけ増えます。
高解像度帯は本来、密な文書や画面内の小さな文字を読み取る用途向けです。色・形状・有無の判定が目的の検品チェックや商品分類タスクでは、200×200px程度の軽量な画像でも十分なケースが多く、無駄に高解像度画像を送るとコストだけが増加します。逆に、手書きメモや細かい仕様表を読ませる用途では圧縮しすぎると文字が潰れて誤読を招くため、JPEG圧縮は多重適用を避け、実際にAPIへ送る画像を目視確認することが推奨されています。
SMBが始めるべき設計の順序
まず自社のユースケースを「判定系（色・形状・有無）」と「読み取り系(文字・数値)」に分類し、判定系は積極的に縮小、読み取り系のみ高解像度を許容する方針を決める。次に、同じ画像を複数ターンで参照する設計ならFiles API化を先に実装し、Base64再送によるコスト膨張を防ぐ。最後に、usageレスポンスの画像トークン数を本番投入前に実測し、見積もりとのズレを確認する。この3手順だけで、画像解析機能の運用コストはおおむね予測可能な範囲に収まる。
画像解析を含むAIエージェントの運用設計は、Kuuのエージェント運用管理サービスで設計支援を行っている。
参考
まとめ
Claude Vision APIのコストは「解像度」「枚数」「再送方式」という3つの変数で機械的に決まる。用途を判定系と読み取り系に分けて解像度を使い分け、繰り返し参照する画像はFiles API化するだけで、見積もり精度とコスト効率の両方が改善する。自社での設計に不安がある場合は、Kuuのエージェント運用管理サービスへの相談も検討してほしい。