長文をPNG化するとLLM入力コストは下がるのか?

長いテキストを PNG 画像に圧縮して LLM に渡すと、入力コストは下がるのか。

結論は、使用するモデルの tier（ティア）によって異なります。

こんにちは。Algomatic でソフトウェアエンジニアをしている Go（@53able）です。

今回は、ローカル環境でコードや JSON 風のテキストを 1928×1928px の PNG に詰め込み、Anthropic の画像トークン計算式、claude-sonnet-4-6 の count_tokens（トークン数カウント機能）の実測、実際の画像読解を試みました。

結果を短く言うと、こうです。

• 高解像度 tier 相当の公式パッチ式で見ると、読みやすい 10px はテキストよりも高く見えた

• claude-sonnet-4-6 の標準 tier 実測では、1928×1928px の PNG は 1,531 input tokens（入力トークン）として数えられた

• この条件では画像の方が安く見えたが、downscale（解像度低下）により読解品質は落ちる

• 10px・8px ではコード構造を追えたが、hash や URL の逐字精度には不安が残る

• pxpipe 本体に強制適用した小規模検証では、token 削減は見られた一方でタスク品質は損なわれた

つまり、PNG 化は単純な節約手段ではありません。モデルの tier、読みやすさ、用途を総合的に見て判断する圧縮手法です。

imagePNG 化は「tier × 読解品質 × 用途」で決める

**注意

この記事の実測は、ローカルの Node/Puppeteer で「1 枚の PNG にどれだけ文字を詰められるか」を測定し、Anthropic/Claude 向けのビジュアルトークン計算式と claude-sonnet-4-6 の count_tokens（トークン数カウント機能）実測で比較したものです。画像トークン数と採算性は、モデルの tier によって変わります。Codex や Cursor で同じ結果になるとは限りません。また、単体 PNG・テキストトークン測定の raw request/response ログや、PNG 生成時の元テキスト全文は公開・保存できていないため、再現可能なベンチマークではなく手元測定として扱ってください。

• まず結論

• なぜテキストを画像にしたくなるのか

• 画像トークンはどう数えられるのか

• claude-sonnet-4-6 では、同じ PNG が 1,531 input tokens（入力トークン）になった

• どう測ったか

• 測定結果

高解像度 tier 相当の参考比較では、10px は高くつく

• claude-sonnet-4-6 実測では、画像の方が安く見えた

• 実際に読ませると、どこまで読めたか

10px: 構造は読めるが、hash（ハッシュ）は不安

• 8px: 構造は追えるが、逐字精度は落ちる

• 6px: 画像入力では読めたが、元解像度の読解は未検証

• 5px: 輪郭は見えるが、内容は取り出せない

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

• 画像化してよい情報、しないほうがよい情報

画像化してもよさそうな情報

• テキストのまま残す情報

• まとめ：背景情報だけ画像に逃がす

• エンジニアを募集しています！

• 参考資料

まず結論

実務上は、次の順で考えるのが安全です。

• まず /clear、prompt caching（プロンプトキャッシュ）、ログ要約、不要な MCP サーバーの無効化を試す

• PNG 化するなら、直近の判断に使わない背景情報だけに絞る

• URL、hash、ID、diff、JSON schema など、1 文字単位の正確さが必要な情報はテキストに残す

• 採用前に、対象モデルで count_tokens（トークン数カウント） と読解品質を測る

今回の測定では、標準 tier の claude-sonnet-4-6 では画像のほうが安く見える条件がありました。一方で、高解像度 tier 相当の公式 patch 式で見ると、読みやすい 10px はテキストより高く見えます。

ただし、高解像度 tier 側の比較は、画像側を公式 patch 式、テキスト側を claude-sonnet-4-6 の count_tokens（トークン数カウント）実測で置いた参考比較です。Fable 5 等で直接測った比率ではありません。

まず確認すべきなのは、自分が使うモデルの tier**です。ここを飛ばすと、同じ PNG でも結論が逆になります。

なぜテキストを画像にしたくなるのか

Claude Code のような AI コーディングツールでは、入力コストのかなりの部分が「いま書いた指示」ではなく、周辺コンテキストに使われます。

たとえば、次のようなものです。

• システムプロンプト

• tool 定義（ツール定義）

• 長い tool result（ツール結果）

• 過去の会話履歴

• ファイル読み取り結果

• テストログ

こうした情報が毎回の入力に入ると、コンテキストはすぐに大きくなります。

一方で、画像入力はテキストとは別の単位で数えられます。そこから、

**文字を画像として詰めれば、長いテキストより安くなるのでは?

という発想が出てきます。

image長い背景コンテキストを PNG 化して LLM（大規模言語モデル）へ渡す流れ

Anthropic の Claude Code ドキュメント (Claude Code costs) も、コストはコンテキストサイズに比例すると説明しています。

docs.anthropic.com

AI コーディングの運用では、モデル選びだけでなく、何をコンテキストに入れるかもコスト設計になります。

この発想は、単なる小技というより、最近は「optical context compression」（光学的情報圧縮）や「visual memory」（視覚的記憶）に近い研究テーマとしても扱われています。

DeepSeek-OCR: Contexts Optical Compressionは、長いテキストコンテキストを画像上の 2 次元配置として扱い、vision tokens で圧縮できるかを調べた研究です。

arxiv.org

論文では、text tokens が vision tokens の 10 倍以内の圧縮率なら OCR precision（OCR 精度）97%、20 倍圧縮でも約 60% と報告されています。つまり、「文字を画像にして安く持つ」という発想には、研究上の背景があります。

少し遡ると、情報圧縮そのものを主目的にした研究ではありませんが、「テキストを token ではなく pixel として扱う」流れもあります。たとえば、Language Modelling with Pixels の PIXEL は、テキストを画像としてレンダリングし、masked patch の pixel 再構成で言語表現を学習します。

arxiv.org

Image-and-Language Understanding from Pixels Only の CLIPPO は、通常の画像と、画像として描画したテキストを単一の Transformer encoder で扱います。

arxiv.org

また、OCR-free Document Understanding Transformer の Donut は、文書画像を外部 OCR に渡さず、画像から直接文書理解タスクを解く方向の研究です。

arxiv.org

この記事の PNG 化実験はこれらの再現ではありませんが、「文字情報を視覚入力として扱えるのか」という前史としては近い位置にあります。

image 前史：テキストを pixel として読む研究

もう一つ近いのが、OCR-Memory: Optical Context Retrieval for Long-Horizon Agent Memory です。

arxiv.org

こちらは、長いエージェント履歴を画像として保存し、必要な箇所を visual anchor で探してから、対応する原文を取り出す仕組みです。ポイントは、画像から自由に文章を生成させるのではなく、locate-and-transcribe（位置特定と転写）で場所を特定し、外部ログから原文を回収するところにあります。byte-exact な情報を画像だけに任せない、というこの記事の結論とも近いです。

ただし、この記事で行っていることは、DeepSeek-OCR や OCR-Memory の再現ではありません。専用モデルを訓練したわけでも、visual anchor（視覚的アンカー）付きの外部メモリを作ったわけでもありません。あくまで、既存の Claude の画像入力に対して「長いテキストを PNG に詰めると、コストと読解品質はどう見えるか」を小さく試したものです。

この発想を Claude Code 向けに実装したツールとして、pxpipe があります。

github.com

pxpipe は、Claude Code へのリクエストをローカルプロキシで受け、巨大な入力ブロックを PNG 画像へ変換してから Anthropic API へ送ります。README では、約 48k 文字の system prompt（システムプロンプト） + tool docs が、テキストなら約 25k tokens、画像なら約 2.7k image tokens（画像トークン）になる例を示しています。エンドツーエンドの請求額は約 59〜70% 下がったと説明されています。

そこで、ローカルに pxpipe-proxy@0.8.0 を入れ、claude-sonnet-4-6 で Claude Code の小さな A/B 検証も行いました。

条件

タスク

結果

Claude Code 表示コスト

pxpipe event log 上の概算 token 削減

備考

passthrough

final facts（最終事実）の抽出

○

$0.1566

0.1%

正しく抽出

pxpipe 強制 ON

final facts の抽出

✕

$0.0998

68.0%

最終回答でプロンプトを見失った

passthrough

意味的な要約

○

$0.1122

0.1%

正しく回答

pxpipe 強制 ON

意味的な要約

✕

$0.1094

62.7%

imaged tool result（画像化されたツール結果）末尾の重要情報を見落とした

この表のコスト差は、タスク成功時の純粋な節約額としては読めません。pxpipe 側は途中から挙動が分岐しており、出力 token 数や turn 数も変わったからです。ここで見るべきなのは、pxpipe event log 上では token 削減が出た一方で、同じタスクの回答品質が崩れた、という点です。

検証条件は、242,587 bytes の CONTEXT_BULK.txt を Claude Code の Read tool で読ませ、末尾の事実を答えさせるものです。control は PXPIPE_MODELS=off、圧縮側は PXPIPE_MODELS=claude-sonnet-4-6 として、標準 tier（基本層）の claude-sonnet-4-6 に pxpipe 圧縮を強制しました。結果サマリ、event log、PNG dump は手元に保存していますが、この記事では要点だけを載せます。

この結果からは、少なくとも今回の条件では「token は減ったが、タスク品質は壊れた」**と見るべきです。pxpipe README のデフォルト対象は高解像度読解に強い Fable 5 等であり、claude-sonnet-4-6 標準 tier に強制するのは別問題です。この記事の結論である「byte-exact な情報や意思決定に必要な事実はテキストに残す」という注意は、むしろ強まりました。

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

圧縮応用とこの記事の検証は分けて見る

ここまでで、発想の背景と注意点を整理しました。次に、今回の実験で前提にした画像 token の数え方を確認します。

画像 token はどう数えられるのか

Anthropic 公式ドキュメント (Images and vision) では、Claude は画像を 28×28px の patch、つまり視覚トークン（visual token）として見る、と説明されています。

docs.anthropic.com

視覚トーク数 = ceil(幅 / 28) × ceil(高さ / 28)

ただし、実際の画像トークン数はモデルの解像度ティアにも依存します。Anthropic のドキュメントでは、高解像度ティアと標準ティアで最大視覚トーク数が異なります。上限を超える画像は、処理前にダウンスケール（downscale）されます。この記事では、公式式による理論値と、count_tokens API で返る実測値を分けて扱います。

最初の比較では、1928×1928px の PNG が高解像度ティア相当で処理される前提にしました。

この場合、計算は次の通りです。

ceil(1928 / 28) × ceil(1928 / 28)

= 69 × 69

= 4,761 視覚トーク数

claude-sonnet-4-6 では、同じ PNG が 1,531 input tokens になった

今回、claude-sonnet-4-6 に対して count_tokens API を使い、複数の画像サイズの入力トークン数を測りました。その結果、1928×1928px の PNG は 4,761 トークンではなく、1,531 input tokensとして数えられました。

Anthropic 公式ドキュメント (Images and vision) およびリサイズ/パディングの説明によれば、API は画像を「ロングエッジ ≤1568px かつ最大視覚トーク数」の双方に収まるようダウンスケールしてから処理します。今回の claude-sonnet-4-6 実測では、1928×1928px(3.72 MP) の PNG は標準ティアの上限に収められ、1,531 input tokens として数えられました。内部の実リサイズ後寸法を直接観察したわけではありませんが、公式仕様と pxpipe audit の近傍比較データから、ダウンスケールが入っていると解釈できます。

画像サイズ

理論値 (本記事 patch 式計算)

count_tokens 実測値 (claude-sonnet-4-6)

読み方

1928×1928 px

4,761

1,531

標準ティア上限に収められる

1568×1568 px

3,136

1,531

標準tier上限に収められる

1092×1092 px

1,521

1,531

cap付近。count_tokens上は1,531

1568×728 px

1,456

1,466

理論値に近い。WYSIWYG寄り

注: 理論値は本記事のpatch式(ceil(width/28) × ceil(height/28))計算。実測値は手元で claude-sonnet-4-6 に対して count_tokens API を実行した結果です。1928×1928pxは実験で生成したfont10 PNGを使い、他のサイズは白背景PNGで寸法だけを合わせて測りました。Anthropicの画像token計算は寸法ベースで説明されているため、この表では寸法差を見る目的に限定して白背景PNGを使っています。内容が読めるかどうかの評価には、別途font10〜font5の実画像を使っています。raw request/responseログは公開していません。

比較参考: pxpipe LEGIBILITY-AUDIT-2026-07-01.md。

github.com

ただし、これは本記事と同一モデル・同一画像・同一条件の再現ではなく、標準tierのdownscale挙動を見るための近傍比較データです。

この結果はclaude-sonnet-4-6での測定です。高解像度tierモデル（Claude Fable 5等）では、1928×1928pxは公式patch式通り 4,761 visual tokens 相当と見積もれますが、テキスト側token数や実際の採算は対象モデルで再測定が必要です。まず、自分が使うモデルがどちらのtierかを確認する必要があります。

image画像tokenはtierによって理論値と実測値がずれる

どう測ったか

実験はローカルのNode.js/Puppeteer環境で行いました。

手順は次の通りです。

• コード/JSON風のテキストを用意する

• Chrome headlessで1928×1928pxのPNGへレンダリングする

• フォントサイズごとに、1枚に入る最大文字数を二分探索する

• 同じ文字数帯のコード/JSON風テキストを claude-sonnet-4-6 の count_tokens で測る

• 画像側はAnthropic公式のpatch式でvisual token数を計算する

• 生成したPNGをClaudeに読ませ、実読解を確認する

必ずJSON形式で返してください。translation フィールドのみ。他のフィールド(technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

テキスト側のトークン数も、画像側と同じく claude-sonnet-4-6 の count_tokens API で測定しました。これにより、text 版と image 版を同じモデル上の入力トークンとして比較しています。

ただし、これはあくまで count_tokens による入力トークン数の比較です。また、元の PNG 生成時の文字列ファイルは残っていないため、テキスト側は同じ文字数帯のコード/JSON 風テキストを再生成して測定しています。raw request/response ログも公開していません。実際の請求やキャッシュ、ツール呼び出しを含む運用コストはワークロードによって変わります。

加えて、pxpipe 本体を通した Claude Code 検証では、claude-sonnet-4-6 に圧縮を強制するとトークン削減は見えた一方で、末尾の重要情報を見落としました。したがって、以降の表は「PNG 単体としてのトークン見積もり」であり、「Claude Code の実運用で安全に使える」ことを意味しません。

image今回の実験手順

測定結果

高解像度 tier 相当の参考比較では、10px は高くつく

以下は、画像側を 1928×1928px = 4,761 visual tokens という公式パッチ式で置き、テキスト側を claude-sonnet-4-6 の count_tokens 実測で置いた参考比較です。Fable 5 等の高解像度 tier モデルで同じテキストを直接測定した比率ではありません。

variant

1 枚あたり文字数

text input tokens (実測)

visual tokens

image/text ratio

削減率

Claude Vision

font10-readable

7,621

3,233

4,761

1.473

-47.3%

○ 構造・変数名可、hash△

font8-dense

10,290

4,398

4,761

1.083

-8.3%

△ 構造・変数名可、hash 誤読リスク

font6-ultra

14,090

5,937

4,761

0.802

+19.8%

△ 画像入力では構造可、元解像度未検証

font5-extreme

17,032

7,193

4,761

0.662

+33.8%

✕ hash/URL 精度低

image/text ratio は、画像の visual tokens を同じ文字数帯の text input tokens で割った値です。1.0 より大きいと PNG 化が高く、1.0 より小さいと安いです。

この参考比較では、10px はテキストより高く、8px もまだ少し高くなります。6px まで詰めて、ようやく画像のほうが安くなります。ただし、対象の高解像度 tier モデルでテキスト側トークン数が同じになるとは限らないため、ここは採算の目安であり、実測比率ではありません。

claude-sonnet-4-6 実測では、画像のほうが安く見えた

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

同じ文字数帯のテキストを、claude-sonnet-4-6 の count_tokens 実測値で比較すると、次のようになります。画像側は1928×1928pxの実測値である1,531 input tokensを使います。

variant | 1枚あたり文字数 | text input tokens (実測) | image input tokens (実測) | image/text ratio | 削減率 | 実効フォントサイズ

---|---|---|---|---|---|---

font10-readable | 7,621 | 3,233 | 1,531 | 0.474 | +52.6% | ~5.6px相当(参考値)

font8-dense | 10,290 | 4,398 | 1,531 | 0.348 | +65.2% | ~4.4px相当(参考値)

font6-ultra | 14,090 | 5,937 | 1,531 | 0.258 | +74.2% | ~3.3px相当(参考値)

font5-extreme | 17,032 | 7,193 | 1,531 | 0.213 | +78.7% | ~2.8px相当(参考値)

少なくとも今回試した4サイズでは、テキスト側の claude-sonnet-4-6 count_tokens 実測と比べて画像のほうが安くなりました。ただし、これはrawログ未公開の手元測定です。また、「実効フォントサイズ」は、pxpipe auditの近傍比較データにある0.555×報告を参考にした近似です。内部リサイズ後の実寸を今回直接観察したわけではありません。標準tierでは、大きな画像がそのまま高解像度で読まれるわけではありません。コスト比率が良く見えても、読解品質まで同じように良くなるわけではない、という点に注意が必要です。

実際に読ませると、どこまで読めたか

読解品質は、現環境の claude-sonnet-4-6 に本記事の実験で生成した4枚のPNG(font10〜font5)を直接渡して確認しました。

10px: 構造は読めるが、hashは不安

コード構造(import文、関数定義、for文)、変数名、関数名を正確に読めました。fetchPackage(name, version) の引数名も追えます。

ただし、sha512 integrity文字列のような長いbase64文字列では、1/l/I・0/Oの区別が困難で、逐字転記の精度は保証できません。

8px: 構造は追えるが、逐字精度は落ちる

コード構造、関数名、変数名は読めます。インデント構造や制御フローも追えました。

ただし、sha512 integrity文字列では1/l/Iの混同リスクが高く、逐字精度は保証できません。また、console.logのタグ付きテンプレートか通常呼び出しかの区別が困難になる場合があります。

6px: 画像入力では読めたが、元解像度の読解は未検証

claude-sonnet-4-6 に画像入力として渡した状態では、コード構造・変数名・関数名を読めました。name(4文字)と pkgName(7文字)の区別も、文字幅の差から判別できました。

必ずJSON形式で返してください。translation フィールドのみ。他のフィールド(technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

ただし、claude-sonnet-4-6 に渡した時点で標準 tier の downscale（解像度低下）を含むため、元解像度の PNG そのものをモデルが読めたことは確認していません。6px の文字は変数名の混同リスクが高く、sha512 整合性文字列はキャンバス幅を超えるため、後半が途切れており転記は不可能です。

5px: 輪郭は見えるが、内容は取り出せない

コードが存在すること、import 文や関数定義のブロック形状はかろうじて見えます。

ただし、変数名・関数名の逐字読み取りは困難です。"resolved": "https://registry.npmjs.org/..." のような長い URL や integrity hash（整合性ハッシュ）の転記も不可能でした。コードの「輪郭」は見えても、内容は取り出せません。

claude-sonnet-4-6 は小さい文字でもコード構造を読めました。とはいえ、いずれのフォントサイズでも、URL や hash などの byte-exact（バイト単位で完全一致する）情報を任せるには不安が残ります。

imageフォントサイズと読解品質のトレードオフ

画像化してよい情報、しないほうがよい情報

PNG 化を検討するなら、まず対象を分ける必要があります。

image画像化してよい情報とテキストに残す情報

画像化してもよさそうな情報

• 直近の判断には使わない過去の会話ログ

• 長いドキュメントの背景説明

• 大量のテストログのうち、流れを読む部分

• 厳密な JSON schema（スキーマ）ではない説明的な tool docs（ツールドキュメント）

• 直近では編集しないコードや設計メモの背景情報

テキストのまま残す情報

• 現在のユーザー指示

• 直近の会話

• ファイルパス

• hash / token / secret / ID

• diff（差分）

• JSON schema

• API request body（リクエスト本文）

• テストの expected output（期待される出力）

• バージョン番号

• 金額や数量

• コピペして使うコマンド

PNG 化は、意味がある程度保たれればよい文脈には使えます。

一方で、1 文字単位の正確さが必要な場所には向きません。標準 tier では大きな画像が downscale されるため、細かい文字ほど不利になります。sha512 hash はいずれのフォントサイズでも逐字保証ができません。

まとめ：背景情報だけ画像に逃がす

Claude Code のコンテキスト削減で、最初にやるべきことは PNG 化ではありません。まずは /clear（クリアコマンド）、prompt caching（プロンプトキャッシュ）、ログの要約、不要な MCP サーバーの無効化を試すほうが安全です。

それでも巨大な背景コンテキストが残る場合だけ、PNG 化を検討します。対象は、過去ログ、背景説明、流れだけ分かればよいテストログ、厳密な schema ではない tool docs のような「意味が残ればよい情報」です。

pxpipe の利用価値も、ここにあると思います。価値があるのは「何でも画像化して安くするツール」としてではなく、巨大な背景コンテキストを圧縮する実装と、event log（イベントログ）で効果を見られる検証装置としてです。対象モデル、圧縮対象、読解品質を測りながら使えるなら選択肢になります。一方で、byte-exact な作業や、標準 tier モデルへの強制適用を無条件に任せる使い方は避けたほうがいいです。

逆に、現在の指示、diff（差分）、ファイルパス、コマンド、expected output（期待される出力）、バージョン番号、URL、hash、token、secret、ID、JSON schema、API request body はテキストのまま残すべきです。

理由は単純です。claude-sonnet-4-6 は小さい文字でもコード構造を読めますが、sha512 hash のような byte-exact 情報は 10px でも保証できません。コスト削減のために画像化して、あとで 1 文字違いの誤読を拾うなら、本末転倒です。

実運用で見るべき順番は、次の通りです。

• モデル tier を確認する

• byte-exact 不要の背景情報に絞る

• 対象モデルで count_tokens（トークン数計測）を測る

• pxpipe のような実プロキシでは、token 削減とタスク品質を分けて見る

• 実タスクで読解テストする

• downscale を避けるページサイズを設計する

PNG 化は「最大削減率」を狙う技ではなく、背景情報を安く残すための限定的な圧縮手法です。

判断基準はシンプルです。

byte-exact な情報はテキストに残す。背景情報だけ画像に逃がす。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI 革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

参考資料

• Anthropic, "Images and vision"

https://docs.anthropic.com/en/docs/build-with-claude/vision

• Anthropic, "Models & pricing"

https://docs.anthropic.com/en/docs/about-claude/pricing

• Anthropic, "Claude Code costs"

https://docs.anthropic.com/en/docs/claude-code/costs

• Anthropic, "Vision coordinates" (resize and padding)

https://platform.claude.com/docs/en/build-with-claude/vision-coordinates#how-claude-resizes-and-pads-images

• pxpipe

https://github.com/teamchong/pxpipe

• pxpipe LEGIBILITY-AUDIT-2026-07-01 (近傍比較として参照した count_tokens 実測データ)

https://github.com/teamchong/pxpipe/blob/main/docs/LEGIBILITY-AUDIT-2026-07-01.md

• DeepSeek-OCR: Contexts Optical Compression（文脈光学圧縮）

https://arxiv.org/abs/2510.18234

• DeepSeek-OCR GitHub リポジトリ / 論文 PDF

https://github.com/deepseek-ai/DeepSeek-OCR

• Phillip Rust 他、「Language Modelling with Pixels」（ICLR 2023 / arXiv:2207.06991）

https://arxiv.org/abs/2207.06991

• Michael Tschannen 他、「Image-and-Language Understanding from Pixels Only」（CVPR 2023 / arXiv:2212.08045）

https://arxiv.org/abs/2212.08045

• Geewook Kim 他、「OCR-free Document Understanding Transformer」（ECCV 2022 / arXiv:2111.15664）

https://arxiv.org/abs/2111.15664

• OCR-Memory: Optical Context Retrieval for Long-Horizon Agent Memory（長期ホライズンエージェントの記憶のための光学文脈検索）

https://arxiv.org/abs/2604.26622