powered by TechFeed
表示モード
ハウツー

Claude Codeへの画像貼り付けはピクセル数で課金される — ファイルサイズ削減が無意味な理由と本当に効くコスト削減4つの手法

11月4日、codenote.netが「Reducing Image Context Cost in Claude Code」と題した記事を公開した。JPEGの品質を下げても、グレースケールに変換しても、Claude Codeの画像コストはまったく変わらない——この逆説的な事実を起点に、本当に効くコスト削減手法を解説した記事だ。AIコーディングエージェントの普及でスクリーンショットをチャットに貼り付ける機会が日常化する中、トークンコストへの意識が高まっており、タイミングとして重要な内容といえる。

11月4日、codenote.netが「Reducing Image Context Cost in Claude Code」と題した記事を公開した。JPEGの品質を下げても、グレースケールに変換しても、Claude Codeの画像コストはまったく変わらない——この逆説的な事実を起点に、本当に効くコスト削減手法を解説した記事だ。AIコーディングエージェントの普及でスクリーンショットをチャットに貼り付ける機会が日常化する中、トークンコストへの意識が高まっており、タイミングとして重要な内容といえる。


「ファイルサイズ」ではなく「ピクセル数」が課金対象

まず押さえておくべき核心がここにある。Claudeの画像トークン数はピクセル寸法によって決まり、ファイルサイズや圧縮率は一切関係ない。

Anthropicのビジョンドキュメントによると、Claudeは画像を28×28ピクセルのパッチ単位で処理し、各パッチが1トークンに対応する。計算式は次の通りだ。

⌈width (px) ÷ 28⌉ × ⌈height (px) ÷ 28⌉ = 視覚トークン数

たとえば1920×1080の画像は2,691トークン、960×540(面積が1/4)では700トークンになる。JPEGの品質を下げても、グレースケールに変換しても、EXIFを削除しても、トークン数は変わらない。

また、モデルごとに長辺の上限が設定されており、超過した画像は処理前に自動でリサイズされる。元記事に記載されているティア区分と上限値は以下の通りだ(モデル名の正確な表記については元記事原文を参照されたい)。

ティア 対象モデルの目安 長辺の上限 最大視覚トークン
高解像度 比較的新しい上位モデル 2,576 px 4,784
標準 その他のモデル 1,568 px 3,116

Claude Codeで主に使われる上位モデルは高解像度ティアに属する。4K(3840×2160)のスクリーンショットをそのまま貼っても、2,576×1,449相当にリサイズされて4,784トークンを消費するだけで、細部の読み取り精度が上がるわけではない。開始サイズを大きくしてもトークンを余分に払うだけだ。


どの対策が効くか、効かないか

対策 効果 理由
解像度を下げる 大 トークンは面積に比例。縦横を半分にすると約1/4になる
必要な領域だけ切り抜く 大 処理される面積が直接減る
画像をテキスト・構造化データで代替する 大(内容による) 画像トークンが一切発生しない
会話履歴に画像を残さない 大 同じ画像がターンごとに再トークン化されるのを防ぐ
JPEG品質を下げる ほぼなし ファイルサイズは圧縮の対象外
グレースケールに変換 ほぼなし カラーチャネル数は計算式に含まれない
EXIFや他のメタデータを削除 なし ファイルが小さくなるが、寸法は変わらない

実践的な削減手法4つ

1. そもそも画像を送らない

開発作業において、伝えたい情報の多くは画像に依存しない。以下のように代替できる場合は積極的に使うべきだ。

  • UIの実装・編集 → HTML、CSS、またはDOM構造の抜粋
  • フローチャート・画面遷移図 → Mermaidソース
  • テーブル → CSVまたはMarkdownテーブル
  • チャート → 元の数値データ(CSVやJSON)
  • エラーダイアログ → スクリーンショットではなくエラーメッセージのテキスト
  • ロゴ・アイコン → SVGソース

ターミナルのエラーであれば、次のようなテキストで十分なことが多い。

Error: Cannot find module 'react'
File: src/main.tsx
Line: 12

一方、UI要素の配置、図中の関係性、色、余白、全体的な見た目のポリッシュはテキストでは表現できない。これらが重要な場合は画像と併用する。

2. 必要な領域だけ切り抜く

画面全体を送る前に、問題が発生している部分だけを切り抜くことを検討する。1920×1080のスクリーンショットから480×270の領域を切り出すと、面積は1/16になり、トークンは18×10=180トークン(元の約1/15)まで下がる。

縮小より先にクロップを試すのが基本の順序だ。ピクセル寸法が課金対象である以上、全体を縮小するよりも必要な部分をフル解像度で送る方が情報量あたりのコスパがよい。

3. 段階的に解像度を切り替える

全体構造の確認と細部の確認を分けて、解像度を使い分ける方法も有効だ。

  1. 全体レイアウトを確認する際は長辺約960px(約700トークン)に縮小して送る
  2. 細かいテキストや詳細が必要になったら、元画像から該当領域を切り抜いて改めて送る

4. ImageMagickで前処理を自動化する

ImageMagickを使えば、送信前の前処理をコマンド一発で自動化できる。

magick screenshot.png \
  -trim +repage \
  -resize '960x540>' \
  -strip \
  context.png
  • -trim +repage:余白を自動トリミング
  • -resize '960x540>':960×540に収まるよう縮小(すでに小さい場合は拡大しない)
  • -strip:メタデータを削除してファイルサイズを削減(トークン数には影響しない)

fswatchなどでスクリーンショットフォルダを監視し、新しいファイルが追加されるたびにこのパイプラインを走らせる構成にすると、「またリサイズを忘れた」というミスがなくなる。


会話履歴に画像を残さない

見落とされがちだがコスト削減に直結するポイントがここだ。Claude Codeでは送信した画像が会話履歴に残り、以降のすべてのターンのコンテキストに含まれる。1ターン目に2,691トークンの画像を貼ると、10ターンのセッション全体でその画像が繰り返しカウントされる。

画像から必要な情報を取り出したら、その内容をCLAUDE.mdや.claude/context/*.mdなどのテキストノートに書き出し、同じ画像を再送しないようにする。後から細部が必要になったら、その部分だけ切り抜いて再送すればよい。

なお、/compactや自動コンパクションで履歴がテキストサマリーに置き換えられると画像自体は消える。画像をスレッドに残しておいても、後から参照できる保証はない。


最適化の判断基準

記事は最後にこう締めくくっている。画像を切り詰めすぎると、追加質問や再送信が発生し、結果的に1タスクあたりのコンテキスト消費が増える逆効果になる場合がある。最小化すべきは「1枚の画像のトークン数」ではなく、「1タスクを完了するために使った総トークン数」だ。同じ画像・同じ質問をいくつかのサイズで試して、トークン数と回答精度を比較することが確実なチューニング方法だと述べられている。

詳細はReducing Image Context Cost in Claude Codeを参照していただきたい。