コードを画像に変換し、モデルにOCRさせることでFableのコストを60%削減

2026年7月4日原文(github.com)

概要

pxpipe はClaude CodeやGPTのリクエスト文脈（システムプロンプト、ツールドキュメント、履歴）を 画像化してトークン数を削減 するローカルプロキシ。 画像トークンはピクセル数で固定 され、テキスト密度が高い場合に 大幅なコスト削減 が可能。 Fable 5モデルで最高の精度、Opus対応も可能だが制限あり。 バイト単位での正確な情報が必要な場合は非推奨、リスクと回避策あり。 ダッシュボードや柔軟なモデル切替機能 も搭載。

pxpipeによるClaude Code/GPT入力トークン削減の仕組み

pxpipe は、 システムプロンプト・ツールドキュメント・履歴 などの大容量テキストを PNG画像に変換 し、リクエスト転送前に圧縮
画像のトークンコストはピクセル数依存 で、 テキスト密度が高いほど圧縮効果が大きい
- 例：コード/JSON/ログなどは 約3.1文字/画像トークン、通常テキストは 約1文字/テキストトークン
リクエスト内容に応じて動的に圧縮 （密度が低い場合や小さいリクエストはそのまま転送）
Fable 5 での読取精度は 100/100、 Opus はやや劣るが選択可能

トークン削減・コスト削減効果

入力トークン削減率 ：例では 約25,000テキストトークン→約2,700画像トークン
コスト削減率 ：Fableリストプライスで 約59～70%削減 （圧縮リクエストのみなら 72～74%）
ダッシュボード で トークン削減量・セッション統計・変換履歴 をリアルタイム表示
出力トークンには影響なし （レスポンスは圧縮しない）

仕組み・利用方法

ローカルプロキシ として動作し、 /v1/messages リクエストをフックして画像化
システムプロンプト・ツールドキュメント・古い履歴 のみ画像化、 直近のやりとり・出力は常にテキスト
モデルごとに画像化ON/OFF を柔軟に切替可能（PXPIPE_MODELS環境変数やダッシュボードから）
ツール定義はGPTの場合JSONのまま 保持、ツールコールの信頼性維持
ダッシュボード で ライブ統計・モデル切替・グローバルキルスイッチ を提供

実行例

npx pxpipe-proxy でプロキシ起動
ANTHROPIC_BASE_URL を http://localhost:47821 に設定しClaude Codeを利用
ダッシュボード （http://127.0.0.1:47821/）で トークン削減状況や変換内容を確認

制約・リスク・回避策

画像化はロス有り ：バイト単位での正確な値（ID/ハッシュ/シークレット/厳密な数値）は 必ずテキストで送信
- 必要な場合はモデル切替や明示的な設定で回避
画像化された履歴からの値取得は誤読リスク有り
- Fable 5は高精度だが、OpusやGPTでは一部失敗例有り
圧縮対象は「利益が出る」場合のみ自動判定 （N=391実測データで調整）
失敗例 ：過去に人名誤読（エラーではなく「それらしい誤答」）、精度保証が必要な用途には注意

ベンチマーク・実測データ

SWE-bench Lite/Pro で 品質・コストともに良好 （Lite: 10/10正解、Pro: 14/19正解、コスト-60%）
GSM8K 等の既知データセットでも高い圧縮率だが、学習済みデータのため参考値
トークン削減率 は リクエスト内容依存、英語プローズのような疎なテキストでは圧縮効果低下
/v1/messages POSTごとに元のトークン数と圧縮後を同時記録 （~/.pxpipe/events.jsonl）

圧縮対象・非対象

画像化されるもの
- 大きなtool_result（ファイル読込・コマンド出力・ログ）
- 古い履歴（直近以外）
- システムプロンプト・ツールドキュメント
画像化されないもの
- 直近のやりとりや小規模リクエスト
- モデル出力
- 疎な英語プローズや小さいテキスト
- 非Fableモデルのリクエスト

まとめ・推奨用途

コード・JSON・ログなどトークン密度が高い作業で大幅なコスト削減
バイト単位での厳密な値が不要な用途で推奨
柔軟なモデル切替・詳細なダッシュボード・再現性あるログ記録
リスク（ロス・誤読）を理解した上での活用が前提

Hackerたちの意見

これはリソースを無駄にする価格のハックみたいだね。抜け道が塞がれたら、OCRの価格が上がることになるんじゃない？

└

抜け道じゃないよ。ただ、情報を光トークンとしてエンコードする方がテキストよりずっと効率的ってだけ。

└

そうでもないよ。実際には、これでリソースを余計に使ってるわけでもないし。これは根本的な非効率性が解消されてるのかも。なんとなく納得できるよね。人はコードを一言一句読むけど、実際には「ざっと見る」ことが多いし、何をするかを大体パターン認識で把握してる。特定の質問に答える必要があるときだけ、詳しく見る感じ。人間って、こういう使い方を自然にしてると思う。

ああ、目がチカチカする、雰囲気のあるコードされたREADMEだね。

└

え、正直なところ、注意点が嫌なの？

└

LLM圧縮の説明を読むのが本当に辛い。何が原因かははっきりしないけど、すぐにわかるし、理解するのに倍の労力がかかる。例えば：> 「正直な注意点、クリップに見える：pxpipeアームは最初にカウントを答えて、リクエストされた一行形式で元帳の残高を印刷するために一度のフォローアップが必要だった。プレーンアームは最初の試みでその形式に従った。可読性はFableで解決されてるけど、単一返信形式の遵守が残る粗い部分。」これを4回読み直せば、何が起こったのかなんとなく推測できるけど、ほとんど無意味で混乱する情報だよ。私の経験では、すべてのモデルがある程度こうなるけど、Claudeが一番ひどい気がする。GPT 5.5はちょっと簡潔だけど、より価値のある情報を圧縮してる感じ。

└

何かを作って共有したい人がいるとき、その人が自分の作ったものをちゃんと理解してないってのが一目瞭然だね。AIを使って本当に役立つものを作れる人もいるし、特にその分野の専門家なら、彼らがAIを使ったことを説明するだけでも大きな意味がある。自分の言葉で、何を作ったのか、AIの限界についても話せると、彼の作ったものが試す価値があるって示せるから。今は99%のものが、全く理解してない領域で動いてる人たちが多いから、そういうのを見るとタブを閉じちゃうよ。あの雰囲気のコードされたREADMEを見るとね。

昨年同じことを試してみたんだけど（OpenAIのモデルで）、その時はプロンプトトークンを減らすのに成功したけど、完成トークンがもっと必要で、結局は高くついて遅くなったよ。https://pagewatch.ai/blog/post/llm-text-as-image-tokens/

ジェミニの場合、PDFの処理方法を見ると、OCRを行ってからテキストと画像をモデルに渡してるみたいで、テキストトークンの料金は取られないと思う。だから、クラウドのバックエンドも同じことをしてるんじゃないかな。だから、このハックはトークンの計算における抜け道って感じで、クラウドがジェミニと同じことをしてるなら、閉じられるかもしれないね。

└

これ、めっちゃ興味深い！この記事を読んで、最初は君に同意してたんだ。「要するに、裏ではテキストトークンに変換されてるはずだから、Claudeが実行するのが実際に安くなるわけがない」ってね。でも、下にDeepSeekがビジュアルトークンを使って圧縮の大幅な改善を得たってコメントがあって、ちょっと考えさせられた。技術的な詳細は完全には理解してないから、OCRの道を行くことで本当に電力や計算の節約になるのか、まだ混乱してる。

└

Claude ScienceにはPDFを抽出するツールがあるけど、OCRしてるかはわからないな。

└

必ずしもそうとは限らないよ。論文を見てみて、「DeepSeek-OCR: Contexts Optical Compression」[1]。画像がLLMに入力されるときの一つのオプションは、それをタイルに分けて、そのタイルを「ビジョンエンコーダー」ニューラルネットワークを通して「ビジョントークン」を作り、それをテキストトークンのようにLLMに入力することなんだ。もちろん、ビジョンエンコーダーとLLMをお互いに理解できるように訓練する必要がある。これが「エンドツーエンドOCRモデル」として知られている。モデルをこう訓練すると、ドキュメントの画像を拡大したり縮小したりすることで、与えられたテキストドキュメントを表すために使う「ビジョントークン」の数を変えることができて、どうなるかを見ることができる。パッチサイズやビジョンエンコーダーの複雑さなど、他にもたくさんのパラメータがある。実際、これがうまく機能することがわかっていて、あるテストでは90%少ない入力トークンを使っても、97%の出力性能を得られたんだ。[1] https://arxiv.org/abs/2510.18234

Hacker Newsで議論の続きを見る

ハクソク