メインコンテンツまでスキップ

光学的コンテキスト圧縮:テキストを画像として送る

上級

ここ 2 年の長コンテキストの工夫はどれも、トークナイザを安くしようとしてきました:より良いチャンク分割、より良い検索、よりスパースなアテンション。別の流れの研究は、もっと奇妙な問いを立てます — テキストをトークン化するのをやめて絵にレンダリングし、圧縮はビジョンエンコーダに任せたらどうなるのか?

冗談のように聞こえます。冗談ではありません。Apple の LensVLM が今週まさにこれで Hacker News のトップページに載り、それは 1 年分の結果 — DeepSeek-OCR、清華大学/Zhipu の Glyph — の上に立っています。いずれも、1 ページのテキストは文字としてよりピクセルとしてのほうがはるかに少ないトークンで済むことを示しています。ただし、突然そうでなくなる点までは、ですが。

このページでは、その仕組み(思っているより単純です)、Claude・GPT・Gemini をまたいだ数値(激しく食い違います)、誰もがぶつかる精度の崖、そして自分のドキュメントでその崖がどこにあるかを見つける 15 分の実験を扱います。

What you'll learn
  • レンダリング解像度が連続的な圧縮ダイヤルである一方、テキストトークナイザにはダイヤルがまったくない理由を説明する
  • プロバイダごとの画像トークン計算式を読む — Claude の 28x28 パッチ、OpenAI の 32x32 パッチ、Gemini の 258 トークンタイル — そして与えられた入力がどちらに転ぶか予測する
  • 実測されたプロバイダ横断の比率を引用できるようにする:Anthropic 0.135、OpenAI 0.194、Google 0.242 — そして Gemini が 6.95 倍請求するケース
  • 崖に名前をつける:グリフがビジョンエンコーダの実効解像度を下回ると精度が崩壊し、しかもプロバイダは黙ってあなたをそこへダウンスケールする
  • 光学的圧縮が割に合う場面(長く静的な参照資料)と、それが医療過誤級の誤りになる場面(モデルが編集したり正確に引用したりしなければならないもの)を判断する

仕組み:解像度は、トークナイザが決して持たなかったダイヤル​

テキストトークナイザが与えるのは、ほぼ固定の交換レートです。英語の散文はトークンあたり 4 文字前後、ソースコードはやや悪く、そしてそれを変える設定は存在しません。テキストを削るか、代金を払うかです。

ビジョンエンコーダはその逆に働きます。ある大きさの画像を、そのピクセルにどれだけの情報を詰め込んだかに関係なく、固定数のビジュアルトークンに写像します。40 行のテキストを 1000x1000 の画像にレンダリングすれば、1000x1000 の画像の分だけ払います。フォントサイズを 10 分の 1 にして 400 行を同じ 1000x1000 の画像にレンダリングしても、支払いはまったく同じです。

これがアイデアのすべてです。レンダリング解像度が連続的な圧縮ノブになる — しかもチャンク分割や要約と違って、これは視覚的な意味でロッシーです:何も取り除かれず、すべてがただ小さくなるだけです。

各プロバイダはピクセルをトークンに変える方法が異なり、その違いはマーケティングよりも重要です:

プロバイダ画像のカウント方法実務上の帰結
Claude28x28 ピクセルのパッチ:画像のコストは ceil(width/28) x ceil(height/28) ビジュアルトークンピクセルあたりは安く、しかもハード上限あり(後述)
OpenAI32x32 ピクセルのパッチにモデルごとの乗数を掛ける。高詳細モードでは最大 2500 パッチまで許容1024x1024 の画像は 1024 パッチで、乗数 1.2 のモデルでは ceil(1024 x 1.2) = 1229 トークンとして課金される
Gemini縦横とも 384 px 以下の画像は一律 258 トークン。それより大きい画像は 768x768 のタイルに分割され、1 タイルあたり 258 トークンハードな下限が存在する。3 行のコードを写した切手サイズの画像でも 258 トークンかかる
What you'll learn
  • テキストトークナイザの交換レートは固定です。ビジョンエンコーダにはノブがあります:同じ画像サイズなら、どれだけテキストを注ぎ込んでも同じ価格です。
  • Claude は 28x28 パッチ単位、OpenAI は 32x32 パッチ × モデル乗数、Gemini は 258 トークンのタイル単位で、258 トークンの下限があります。
  • Gemini の下限こそ、短い入力が画像にすると逆に高くつく理由です — 安い小さな画像というものは存在しません。

実測された数値、そして逆方向に振れたひとつ​

2026年7月、プロバイダ横断の研究(arXiv 2607.21672)が地味で必要な作業をやりました:実際のソースコード — 5 言語、20 行から 2,000 行までの 9 段階の長さ、15 のモデルエイリアス、675 組のテキスト/画像ペア — を用意し、各プロバイダ自身の API に、テキストとして、そしてレンダリングされた画像として、入力トークンがいくつカウントされるかを尋ねたのです。

画像/テキストのトークン比の集計:

プロバイダ画像 / テキストのトークン比削減率
Anthropic0.135カウントされるトークンが 86.5% 少ない
OpenAI0.19480.6% 少ない
Google (Vertex AI)0.24275.8% 少ない

ここまでは一様に良い話です。興味深い結果は平均ではなく形のほうにあります。Anthropic と OpenAI では、テストしたすべてのサイズで画像のほうがカウントが低くなりました — 20 行でさえそうです。Gemini では、20 行のコードの画像はテキストの 6.95 倍のトークンがかかり、画像がテキストを下回るのは 200 行前後からでした。

これは 258 トークンの下限が仕事をしているということです。およそ 200 行を下回る領域では、ひとにぎりのグリフを載せるためにタイル 1 枚まるごと買っていることになります。

Watch out
  • あの研究が測ったのはトークンの会計だけです。著者は明言しています:意味的忠実度、タスク精度、レイテンシ、金銭的コスト、コーディングエージェントの効率は測っていません。
  • トークン数が 7 分の 1 でも質問の 40% に誤答するなら、それは 7 倍の節約ではありません。トークン数はこの判断の簡単なほうの半分にすぎません。
  • プロバイダ間で比率は移植できません。Claude で 86% 節約する同じパイプラインが、短い入力では Gemini で 7 倍かかることがあります。

自明でない部分:仕事の大半をしているのは上限のほう​

長いファイルであの集計比率がこれほど華々しく見える理由、そしてそれが罠である理由は次のとおりです。

Claude は任意に大きな画像を買わせてくれません。各モデルは長辺の上限とビジュアルトークンの上限を持つ解像度ティアに属し、それより大きいものは処理前にダウンスケールされます:

ティアモデル長辺の上限ビジュアルトークンの上限
高解像度Claude 4.7 以降2576 px4784
標準それ以外のすべてのモデル1568 px1568

これは価格の天井だと読んでください。標準ティアのモデルでは、1 枚の画像のコストは最大でも 1568 ビジュアルトークンです — その中身が 200 行のコードでも 2,000 行でも同じです。テキストをさらに注ぎ込んでも請求額は動きません。

ピクセル予算も動きません。ただグリフが小さくなるだけです。

これはまさに LensVLM の著者が名指しした失敗モードです:精度は*「圧縮が進むにつれて急速に劣化する:文字がビジョンエンコーダの実効解像度を下回り、判別不能になる」*。ダウンスケールは無言です — エラーも警告もなく、トークン数は素晴らしく見えたまま、気づけばモデルがぼやけたテキストを自信満々に読んでいる地点に達します。

What you'll learn
  • Claude における 1 枚の画像は定額のコンテナです:標準で 1568 ビジュアルトークン以下、高解像度ティア(Claude 4.7+)で 4784 以下。
  • 大きなファイルでの華々しい圧縮率は、その多くがプロバイダによるその上限へのダウンスケールであって、エンコーダが賢いわけではありません。
  • トークンカウンタは可読性を見られません。あなたの eval が見なければなりません。だから下の実験は省略可能ではないのです。

研究が示す本当の上限​

3 本の論文が使える範囲を挟み込んでいます。どれも無限に圧縮できるとは主張していません。

DeepSeek-OCR(arXiv 2510.18234、MIT ライセンス、~23.9k スター)はこのアイデア全体を「contexts optical compression」と名づけ、劣化に数値を与えました:テキストトークンがビジョントークンの 10 倍以内であれば、OCR 精度は 97% 前後を保ちます。20 倍まで圧縮すると精度はおよそ 60% に落ちます。そのエンコーダは固定モードを提供します — 512x512 で 64 ビジョントークン、640x640 で 100、1024x1024 で 256、1280x1280 で 400 — そしてページあたり 100 ビジョントークンで、ページあたり 256 トークンで動く GOT-OCR2.0 を OmniDocBench で上回り、800 トークン未満で MinerU2.0 の 6,000 超を上回りました。

Glyph(arXiv 2510.17800、清華大学 + Zhipu AI)は OCR ではなくコンテキストウィンドウを攻めました:長いテキストを画像にレンダリングし、VLM に食わせ、長コンテキストベンチマークで Qwen3-8B に匹敵する精度のまま 3〜4 倍のトークン圧縮を得ます — さらにプリフィルとデコードがおよそ 4 倍高速、SFT トレーニングが約 2 倍高速になります。積極的な圧縮のもとでは、128K コンテキストの VLM が 1M トークン級のテキストタスクに到達すると報告しています。注目すべきは、レンダリングを手作業でチューニングしていない点です:LLM 駆動の遺伝的探索が、精度と圧縮のバランスをとるフォント・レイアウト・解像度を探しました。レンダリング設定は細部ではなくハイパーパラメータです。

LensVLM(arXiv 2605.07019、Apple、2026年5月)は欠けていたピース — 崖からの出口 — を加えました。Qwen3.5-9B-Base の上に構築され、5 倍・10 倍・15 倍の圧縮レベルを備え、モデルに read_page ツールを与えます:すべてを圧縮した状態でスキャンし、実際に必要なページだけをフル解像度に戻して展開する。4.3 倍の実効圧縮でフルテキストの上限に匹敵する精度を保ち、7 つのテキスト QA ベンチマークにわたって 10.1 倍まで、検索ベース・テキスト圧縮・視覚圧縮のベースラインを上回ります。重みは Hugging Face に apple/LensVLM-9B として Apple の研究モデルライセンスで公開され、コードは apple-aiml-research/ml-lensvlm にあります。

What you'll learn
  • 公開された証拠が快適でなくなるのはおおよそ 10 倍あたりです:10 倍未満で 97% の精度、20 倍で ~60%(DeepSeek-OCR)。
  • Glyph の 3-4 倍は保守的で精度を保つ設定です — しかもプリフィルが ~4 倍速くなるおまけつきです。
  • LensVLM の貢献は非常口です:選択的な再展開により、1 ページの失敗が答え全体を沈めずに済みます。

なぜ選択的展開は検索に勝るのか(そして勝たない場合)​

紙の上では、これは手順が増えただけの RAG に見えます。違います。その違いは理解しておく価値があります。

検索は質問が存在する前にコーパス全体をあらかじめインデックス化します。チャンクに分け、埋め込み、保存する — そして下流のすべての答えは、あなたのチャンク境界が破壊したものを引き継ぎます:2 つのチャンクに割れたテーブル、主張から切り離された脚注、インポートから切り離された関数。

光学的なスキャン&展開はそれを反転させます。ドキュメント全体が圧縮されたビジュアルトークンとして、レイアウトごと無傷でコンテキストに入ります。モデルは低解像度版を読み、この質問にとってどのページが重要かを判断し、そのページだけに満額を払います。事前インデックス化も、チャンク境界も、コーパスと同期させ続ける埋め込みモデルも不要です。

LensVLM の分析は有用な補足を加えています:テキスト展開はレンダリングされたテキストに最も適し、高解像度の画像展開はレイアウトがタスクに関係する情報を担うネイティブなドキュメントに向く。 レンダリングされたページを文字に戻す展開は安く綺麗ですが、スキャンした請求書をフル解像度に展開するほうは、そもそも必要だった空間構造を保てます。

検索がなお勝つ場面:どんなコンテキストウィンドウよりはるかに大きいコーパス、正確な出典と文字オフセットが必要なもの、どのソースがどの文を生んだかを証明しなければならないパイプライン。

15 分で自分のドキュメントで試す​

誰かの集計比率を根拠にこれを採用しないでください — このページの数値も含めてです。結果を決める変数はあなたのものです:あなたのフォント、あなたの行長、あなたのプロバイダ、あなたの質問。

Guided walkthrough1 of 5
  1. 実際にモデルに食わせているドキュメントを 1 本用意します。等幅フォントと手元にあるレンダラ(Pillow、ヘッドレス Chrome、wkhtmltoimage)を使って、PNG に 3 回レンダリングします — 快適サイズ、半分、4 分の 1。3 つすべてでテキストは同一に保ち、変えるのはピクセル寸法だけです。JPEG ではなく PNG を使ってください:Anthropic 自身のビジョンガイダンスは、非可逆圧縮のアーティファクトが小さな文字を読みにくくすると警告しており、まさにこれがその噛みつくケースです。

Claude で同じ内容を両方の方法でカウントする

# 1. Render text to PNG at a chosen width (Pillow)
python - <<'PY'
from PIL import Image, ImageDraw, ImageFont
text = open("document.txt").read()
font = ImageFont.truetype("DejaVuSansMono.ttf", 14)   # try 14, 9, 6
lines = text.splitlines()
img = Image.new("RGB", (1400, 18 * len(lines) + 20), "white")
d = ImageDraw.Draw(img)
for i, line in enumerate(lines):
  d.text((10, 10 + 18 * i), line, font=font, fill="black")
img.save("document.png")   # split into page-sized images if it is tall
PY

# 2. Ask Claude what each version actually costs
curl https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
  "model": "claude-opus-5-5",
  "messages": [{"role":"user","content":[
    {"type":"image","source":{"type":"base64","media_type":"image/png","data":"'"$(base64 -i document.png)"'"}},
    {"type":"text","text":"Answer only from this document."}
  ]}]
}'

割に合う場面 — そして過誤になる場面​

光学的圧縮に手を伸ばすべきとき:

  • 資料が長く、静的で、読み取り専用のとき — ポリシーマニュアル、標準規格、API リファレンス、繰り返しクエリするが編集はしない法務コーパス。
  • ソースがすでに視覚的なとき — スキャンした PDF、フォーム、請求書、スライドデッキ。どのみち画像トークンを払うことになっていたので、レンダリングは無料です。
  • レイアウトが意味を担うとき — 表、多段組のドキュメント、Markdown にシリアライズすると必要な関係が壊れるもの全般。
  • 多数のページを一度に視野に入れる必要があり、検索が答えを切り刻んでしまうとき。

テキスト経路を残すべきとき:

  • モデルが内容を編集・差分・パッチしなければならないとき。コーディングエージェントには行番号、正確な空白、バイト単位で正確な引用が必要で、そのどれもピクセルを往復して生き残りません。
  • 1 文字の誤りも許されないとき — 口座番号、投薬量、法的引用、設定値。解像度の崖が最初に現れるのがここです。
  • 入力が短いとき。Gemini では高くつきますし、どのプロバイダでも、コストの端数のために実際の精度を差し出すことになります。
  • ソースへの正確な引用オフセットが必要なとき。
Watch out
  • Claude では、明示的にエラーを返すよう指定しない限り、大きすぎる画像は黙ってダウンスケールされます — レスポンスに何の signal もないまま可読性が劣化し得ます。
  • 1 回の Claude リクエストで 20 を超える画像ブロックを送ると、そのリクエスト内のすべての画像により厳しい寸法制限がかかります。各辺 2000 px 未満に抑えるか、リクエストを 20 ブロックまでに抑えてください。
  • リクエストあたりの画像上限は 200k コンテキストのモデルで 100、それ以外で 600 ですが、たいていは 32 MB のリクエストサイズ上限のほうが先に噛みつきます — Files API を使い、画像は file_id で参照してください。
  • プロンプトキャッシュはユーザーターン内の画像コンテンツブロックにも適用されますが、キャッシュ可能な最小プロンプト長は依然として適用されます。仮定せず、レスポンスの cache_read_input_tokens で確認してください。
光学的圧縮の用語
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 8

クイズ​

Check yourself

0/5
  1. プロバイダ横断の研究は、画像/テキストのトークン比を 0.135(Anthropic)、0.194(OpenAI)、0.242(Google)と報告しました。これらの数値に基づいて動く前に、最も重要な注意点は何ですか?
  2. 20 行のコードを画像としてレンダリングすると、Gemini ではテキストより 6.95 倍高くつくのに、Claude と OpenAI では安くなるのはなぜですか?
  3. 標準ティアの Claude モデルで、200 行を 1 枚の画像にレンダリングし、次に同じ寸法の画像に 2,000 行をレンダリングしました。トークン数はどうなりますか?
  4. LensVLM の read_page ツールは、素の視覚圧縮に何を加えていますか?
  5. 光学的コンテキスト圧縮に最も適さないワークロードはどれですか?

出典と参考資料​

次に読む​