Codex に画像を渡すときのコンテキスト消費を減らす — GPT-6.1 / GPT-6 / GPT-5.6 系の 32×32 px パッチと detail: low / high / original でトークンを削る

Codex や OpenAI API のビジョン対応モデルに画像を渡すと、会話のコンテキストが想像以上に減っていくことがあります。消費されるのは画像のファイルサイズ（KB や MiB）ではなく、ピクセル寸法とモデル別の patch budget に基づく画像トークンです。したがって、JPEG を強く圧縮して容量を半分にしても、縦横のピクセル数と detail 設定が変わらなければトークン数は変わりません。本稿では、OpenAI の公式ドキュメントに記載された現行の画像トークン計算方法を整理し、Codex で運用するときに効く対策と効かない対策を分けて記述します。

Claude Code 側の最適化は別記事の Claude Code に画像を渡すときのコンテキスト消費を減らす — ピクセル寸法で考えて縮小・クロップ・テキスト化で絞る にまとめてあります。

2026 年 11 月時点で Codex が選べるモデル

Codex CLI の /model 相当のピッカーで現在選べるのは、2026-11-07 時点で次の 8 モデルです。

• GPT-6.1-Sol（最新の workhorse、コーディング・日常用途）
• GPT-6-Astra（最難タスク向け frontier モデル）
• GPT-6.1-Terra（文章作成・画像理解・computer use 向けの高速で効率的なモデル）
• GPT-6-Sol（前世代の workhorse）
• GPT-6-Luna（高速・低コスト、簡単なタスク向け）
• GPT-5.6-Sol / GPT-5.6-Terra / GPT-5.6-Luna（旧世代、いずれも現役）

かつて推奨選択肢だった GPT-4o 系と GPT-4.1 系は、API 自体が 2027-01-14 で廃止予定で、Codex のピッカーからは既に外されています。gpt-4o-2024-05-13 と gpt-4.1-nano は 2026-10-23 で廃止済みです。本稿では、Codex で実際に選べる GPT-6.1 / GPT-6 / GPT-5.6 系に絞って整理します。

画像トークンは 32×32 px パッチで決まる

OpenAI の Images and Vision ガイド によれば、掲載されているモデル（GPT-6-Astra と GPT-5.6 系）のビジョン処理は共通して 32×32 px のパッチ方式を使います。画像 1 枚の消費トークンは次の式で計算されます。

ceil(幅 ÷ 32) × ceil(高さ ÷ 32) × モデル別マルチプライヤ = 画像トークン数

掲載されているモデルのマルチプライヤはいずれも 1.2 です。モデル別の detail ごとの挙動は次のとおりです。

GPT-6.1 系と GPT-6-Sol / GPT-6-Luna は 2026-11 時点で公式のモデル別一覧には未掲載ですが、Codex の説明文からは GPT-6-Astra と同じパッチ方式の系譜に属するモデルだと読めます。正確な patch budget が気になる場合は、公式ドキュメントの最新版を確認してください。

また、ピクセル寸法とは別に、全モデル共通で 1 枚あたり 30,000 パッチが絶対上限です。処理後にこの上限を超える画像は縮小ではなく拒否されます。1 リクエストあたり画像 1,500 枚、ペイロード 512 MB の上限もあります。

計算例として、GPT-6-Astra に detail: auto で画像を渡した場合のトークン数を挙げます。

• 512×512 の画像: ceil(512/32) × ceil(512/32) × 1.2 = 16 × 16 × 1.2 = 308 トークン
• 960×540 の画像: ceil(960/32) × ceil(540/32) × 1.2 = 30 × 17 × 1.2 = 612 トークン
• 1920×1080 の画像: ceil(1920/32) × ceil(1080/32) × 1.2 = 60 × 34 × 1.2 = 2,448 トークン
• 4K（3840×2160）を detail: high に渡すと、2,500 パッチ budget を超えるので縮小されてから課金されます

detail: low の 512×512 縮小が最も強い抑制手段で、入力寸法が大きい画像ほど節約効果が大きくなります。たとえば 1920×1080 を detail: low に落とすと、アスペクト比を保って 512×288 相当に縮小されるので、ceil(512/32) × ceil(288/32) × 1.2 = 16 × 9 × 1.2 = 173 トークンまで下がります。ただし低解像度への補間縮小になるため、小さな文字は読みにくくなります。

旧 GPT-4o 系のような「detail: low なら解像度に関係なく 85 トークン固定」という挙動は、現行の GPT-6 / GPT-5.6 系では採用されていません。低解像度化によってトークンが減るという仕組み自体は同じですが、固定トークンではなく縮小後のパッチ数で課金される点が異なります。

効く対策・効かない対策

効果の大きい順に対策する

用途が許すなら detail: low にする

GPT-6.1 / GPT-6 / GPT-5.6 系の detail: low は、画像を 512×512 に収まるようアスペクト比を保って縮小します。縮小後のパッチ数 × 1.2 で課金されるため、最大でも 16 × 16 × 1.2 = 308 トークン、長方形の画像ならさらに下がります。細かい文字は読めなくなる代わりに、原画像の寸法に関係なくほぼ一定のコストに収まります。

• レイアウト・配色・構図の確認
• 画像のカテゴリ分け（写真かスクリーンショットか、など）
• UI の大まかな状態確認（ログイン済みか未ログインか、など）

こうした用途なら、detail: low に固定するのが一番安く済みます。OpenAI Python SDK なら次のように指定します。

from openai import OpenAI
 
client = OpenAI()
response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": "このスクリーンショットは何の画面ですか？"},
                {
                    "type": "input_image",
                    "image_url": "https://example.com/screenshot.png",
                    "detail": "low",
                },
            ],
        }
    ],
)

逆に、小さな文字の OCR・スクリーン上の細部確認・computer use では detail: original が適しています。auto（既定）は、GPT-6-Astra と GPT-5.6 系では original と同じ挙動なので、何も指定しなければネイティブ寸法で課金されます。コストを抑えたいときは detail: low を明示します。

なお、Codex CLI には、ユーザーがメッセージ単位で detail: low や detail: high を指定する手段は 2026-11 時点でありません。あるのは、~/.codex/config.toml の [features] で image_detail_original = true を有効にすると、モデルが view_image ツールで detail: original を要求できるようになる仕組み（openai/codex PR #14175）だけです。Codex セッション内で detail を細かく制御したい場合は、OpenAI API を直接呼ぶ薄いラッパーを 1 層挟む運用になります。それ以外の節約手段としては、Codex に渡す前に画像をあらかじめ縮小・クロップする前処理が有効です。

画像を渡さずに済ませる

Codex での開発用途では、そもそも画像を必要としない情報が多く含まれています。この場合、テキストや構造化データで渡すほうが少ないトークンで済みます。

• UI の実装・修正が目的なら、該当箇所の HTML・CSS・DOM の抜粋を渡す
• フローチャートや画面遷移図は Mermaid のコードを渡す
• 表は CSV や Markdown の表で渡す
• グラフは元の数値データを渡す（CSV・JSON）
• エラーダイアログは、画面の画像ではなくエラーメッセージのテキストを貼る
• ロゴ・アイコンは SVG ソースを渡す

たとえば、ターミナルに表示されたエラーは次のテキストだけで十分なことが多いです。

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

画像内の文字だけが必要な場合は、OCR で文字を抽出するか、元のログを取得します。反対に、グラフの形状・UI の配置・図解の関係性は文字だけでは失われるため、必要に応じて画像と併用します。

必要な領域だけクロップする

画面全体ではなく、問題が起きている箇所だけを切り出します。パッチ方式では、面積がそのままパッチ数に反映されるため、クロップは最も確実な節約手段です。1920×1080 のスクリーンショットから 480×270 の領域を切り出すと、ceil(480/32) × ceil(270/32) × 1.2 = 15 × 9 × 1.2 = 162 トークンで、元画像の 2,448 トークンの約 7% まで下がります。

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

全体の構造を確認する段階と、細部を確認する段階で解像度・detail を分けると、トークンをまとめて抑えやすくなります。

1. 全体像を確認するため、detail: low（原寸に関わらず最大 308 トークン）か長辺 960 px 程度への事前縮小を使う
2. 小さな文字や細部が必要になったら、原画像から該当領域だけを切り出して追加で渡す

複数画像をタイル結合する

GPT-4o 系では 1 枚ごとに 85 トークンの固定オーバーヘッドがあり、小さな画像を 1 枚に結合することでまとめて節約できました。GPT-6 / GPT-5.6 系のパッチ方式では per-image の固定オーバーヘッドは小さく、節約効果は ceil() の端数程度に留まります。

• 10 枚の 200×200 を個別に渡す場合: ceil(ceil(200/32)² × 1.2) × 10 = ceil(49 × 1.2) × 10 = 59 × 10 = 590 トークン
• 10 枚を 2×5 のグリッドに結合（1,000×400 を想定）して 1 枚で渡す場合: ceil(ceil(1000/32) × ceil(400/32) × 1.2) = ceil(32 × 13 × 1.2) = 500 トークン

タイル結合は、画像数が多い用途（アイコンの一覧、複数回のスクリーンショット比較など）では今も有効ですが、効果は旧 tile 方式ほど劇的ではありません。結合によって画像全体のパッチ数が増えすぎると 30,000 パッチ上限に引っかかる点にも注意します。

前処理をコマンドで自動化する

ImageMagick を使うと、画像を渡す前に自動で処理できます。ImageMagick 7 では magick コマンドを使います。ImageMagick 6 では convert を使います。

# 余白を削除
magick input.png -trim +repage output.png
 
# 960x540 以内に縮小（それより小さい画像は拡大しない）
magick input.png -resize '960x540>' output.png
 
# 複数画像を縦に結合
magick a.png b.png c.png -append combined.png
 
# 複数画像を 2x2 にタイル結合
magick a.png b.png c.png d.png -tile 2x2 -geometry +4+4 tiled.png

複数の処理を組み合わせる場合は、次のように書けます。

magick screenshot.png \
  -trim +repage \
  -resize '960x540>' \
  -strip \
  context.png

-trim は画像の端の色を基準に余白を判定します。背景が単色でない場合、必要な部分まで削除されることがあるため、結果を確認してから使ってください。

画像を履歴に残し続けない

Codex のセッションでは、一度渡した画像が会話の履歴に残り続け、以降のターンでも繰り返しコンテキストに乗ります。10 ターン続くセッションの 1 ターン目に 2,448 トークンの画像を貼ると、以降のターンでもその画像がコンテキストに含まれます。

したがって、画像から必要な情報を読み取ったら、結果をテキストのメモ（AGENTS.md・.codex/notes/*.md など）に書き出し、以降は同じ画像を再送しないようにします。細部が後から必要になった場合は、該当領域だけをクロップして再度渡します。

Playwright などで自動スクリーンショットを撮る Codex 連携では、差分画像の生成までを前処理に組み込んでおくと、ターンごとの画像トークンを一定に抑えられます。

用途別の最初の一手

Codex から GPT-6.1 / GPT-6 / GPT-5.6 系を呼び出すときに、入力の種類ごとに最初に試す対策をまとめました。

OpenAI API を直接呼び出すときの追加設定

Codex CLI ではなく、OpenAI API（Responses API や Chat Completions API）を直接呼ぶ場合は、detail パラメータ以外にも次の選択肢があります。

• service_tier によるレイテンシ・料金の調整（flex processing など）
• Batch API による 50% 割引（即時性を犠牲にできる場合）
• 画像の file_id を使い回す（同じ画像をアップロード済みなら、URL ではなく ID で参照する。転送量は減るが、画像トークンは毎回同じだけ課金される）

これらは Codex CLI から直接制御できるとは限らないため、Codex を使ったワークフローで細かくチューニングしたい場合は、OpenAI API を直接呼ぶラッパーを 1 層挟む設計のほうが融通が利きます。

実務では、「用途に合わせて detail: low / high / original を使い分ける」「不要な領域はクロップする」「テキストや構造化データに置き換えられるものは置き換える」「同じ画像を再送しない」の 4 つを押さえるだけで、大半の無駄を減らせます。

一方で、画像を減らしすぎると再質問や再送が増えて、結果的にコンテキストを多く使ってしまうこともあります。同じ画像と同じ質問で、入力トークン数と回答の正確さを比べながら、過剰にならない範囲で調整するのが確実です。最終的な評価基準はトークン削減量ではなく、1 タスクを完了するまでに使った総トークン数です。

以上、Codex の現行選択肢である GPT-6.1 / GPT-6 / GPT-5.6 系が 32×32 px パッチ方式で画像を課金することと、detail: low / high / original の挙動と 30,000 パッチ上限を踏まえて Codex のコンテキストを抑える方法を整理した、現場からお送りしました。

参考情報

• OpenAI Images and Vision ガイド
• OpenAI Responses API リファレンス
• OpenAI deprecations ページ
• Codex
• ImageMagick 公式サイト
• Mermaid 公式サイト
• Claude Code に画像を渡すときのコンテキスト消費を減らす — ピクセル寸法で考えて縮小・クロップ・テキスト化で絞る