◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-07-13上級

画像を原寸で送るか縮小するか — Opus 4.7 の高解像度ビジョンで1枚ごとに解像度を決めるコスト設計

Opus 4.7 の高解像度ビジョンで壁紙の細部分類は上がったのに、全部を原寸で送ったら週のトークンが跳ねました。1枚ごとに解像度と使うモデルを決める preflight を設計し、精度を保ったままコストを下げた実測を残します。

Claude API127Vision4コスト設計7個人開発130Opus 4.7

✦ プレミアム記事

Dolice で運営している壁紙アプリの自動タグ付けを、2026 年 7 月に一般提供となった Opus 4.7 の高解像度ビジョンへ切り替えたとき、和柄のグラデーションや浮世絵の細い線といった「微細な差」を拾えるようになった手応えがありました。

うれしくなって、パイプラインに流れる画像を全部そのまま原寸で送りました。翌週、入力トークンの請求を見て手が止まりました。分類精度は確かに上がっていたのに、画像入力のトークンだけで前週の約 2.4 倍に膨らんでいたのです。

縮小すればいい、という話ではありませんでした。風景か人物かを分けるだけなら 512px で十分ですが、近接した重複壁紙を見分けたり、UI サンプル画像の中の小さな文字を読んだりする場面では、縮小した瞬間に精度が崩れます。必要なのは「全部を縮小する」でも「全部を原寸で送る」でもなく、1 枚ごとに、その画像がどれだけの解像度を要求するかを決めるルールでした。

個人開発で複数の壁紙アプリを回している身として、精度を守りながらコストを削る線引きは切実でした。その decision rule をどう組んだか、そして週次でどれだけコストが下がったかを、実測とともに残します。

画像トークンは面積で決まる — 縮小は「コスト」ではなく「情報量」の調整

まず把握しておきたいのは、Claude が画像に課金するトークンは、ほぼ画素の面積で決まるという点です。ドキュメント上の概算式は次の通りです。

入力トークン ≈ (幅px × 高さpx) ÷ 750

そして長辺が 1568px を超える画像、または約 115 万画素を超える画像は、API 側で自動的に縮小されてから処理されます。つまり原寸で送っても、ある大きさから先はトークンが頭打ちになり、送信帯域だけを無駄に使うことになります。

私の壁紙パイプラインで count_tokens を使って実測した、解像度ティア別のおおよその入力トークンが下の表です。式はあくまで概算なので、本番運用では必ず count_tokens エンドポイントで実測することを強く推奨します。数十トークン単位でずれます。

送信時の長辺概算画素入力トークン(実測)1万枚あたり入力コスト(Sonnet 5 導入価格 $2/M 換算)
384px約 15 万約 200約 $4.0
512px約 26 万約 350約 $7.0
768px約 59 万約 790約 $15.8
1024px約 105 万約 1,400約 $28.0
上限付近(約 115 万画素)約 115 万約 1,540約 $30.8

表を作って初めて腑に落ちたのですが、384px と 1024px では 1 万枚あたり 7 倍のコスト差があります。全部を原寸で送っていた私は、風景の分類にまで一番高い列を払っていたわけです。縮小は画質を落とす後ろ向きな操作ではなく、その判断に必要な情報量まで解像度を落とすという前向きな設計だと捉え直しました。

なお、base64 文字列としてうっかりテキスト欄に画像を詰めると、この面積ベースの課金が効かず桁違いのトークンを食います。image ブロックで渡す前提の話です。この落とし穴はツール結果の画像ブロックでトークンを節約するで詳しく検証しています。

どこで縮小が効き、どこで壊れるか

解像度を落とせるかどうかは、「そのタスクが画像のどの粒度を見ているか」で決まります。私の 30 カテゴリの壁紙分類で、縮小に耐えるものと耐えないものを仕分けると、はっきり二層に分かれました。

縮小してよい(512px で精度が落ちない)判定は、画像全体の構図やテーマを見るものでした。風景・人物・抽象・季節といった大分類は、384〜512px でも Opus 4.7 は安定して当てます。むしろ縮小したほうがノイズが減って安定する場面すらありました。

原寸が要る判定は、細部の差が結論を分けるものでした。具体的には次の三つです。

判定の種類縮小すると起きること必要な長辺の目安
微細テクスチャ(和柄・グラデーション・ノイズ加工)模様が潰れて「無地」に誤分類1024px 以上
近接重複の判定(ほぼ同じ 2 枚の差分)差分が消えて別物を「同一」と判定1024px 以上
画像内の小さな文字(サンプルUI・ロゴ)文字が読めず内容を取り違える上限付近

Opus 4.7 の高解像度ビジョン強化が効くのは、まさにこの下の層です。前のモデルでは原寸で送っても微細テクスチャの読み取りが不安定でしたが、4.7 では原寸を渡せば安定して拾うようになりました。逆に言えば、高解像度ビジョンの恩恵を受けたい画像にだけ原寸を払えばよく、それ以外は縮小で十分ということです。この線引きが decision rule の骨格になります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦画像トークンは面積でほぼ決まる。長辺 1568px・約 115 万画素で頭打ちになる仕組みと、count_tokens で実測すべき理由
✦粗い分類は縮小で足りるが、微細テクスチャと小さな文字は原寸が要る。どこで縮小が精度を壊すかの線引き
✦縮小ティアでまず判定し、confidence と対象クラスで原寸+Opus 4.7 へ二段エスカレーションする Python コード(週次の実測付き)
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-09-17
画像は20枚ずつ送っています — 21枚目から全画像に別の上限がかかると知った日
素材フォルダの62枚を一度に送ったら invalid_request_error で落ちました。容量ではなく枚数が原因です。視覚トークンを28pxのパッチで数え直し、枚数・寸法・ペイロードの3つの上限を同時に見てバッチを組むまでの記録です。
⬡ API & SDK2026-05-15
壁紙アプリの一括カテゴリ分類を Claude Vision API で自動化した話 — 実運用で見えた精度と限界
個人開発の壁紙アプリで画像のカテゴリ分類をClaude Vision APIに任せた実体験の記録です。SonnetとHaikuのモデル選択、75枚の手動検証で確かめた分類精度、実運用で踏んだ落とし穴、途中で落ちても再開できるバッチ設計、そして実際にかかったコストの感覚まで正直に書きました。
⬡ API & SDK2026-09-06
訳文は自然なのに、実行時に落ちる翻訳がありました
多言語アプリの文言を Claude API で訳したとき、意味は正しいのに書式指定子だけが壊れることがあります。重大度で分けた受け入れ検査と、壊れた行だけを訳し直す修復ループを実装と実測でまとめました。