Claude Codeの請求を6割削る。pxpipeの手口と代償

岬徹

2026年7月5日 20:4200

AIコーディングエージェントのコスト問題に、正攻法ではない解が出た。テキストを画像に変えてからAPIに送る。たった2行のコマンドで、同じ作業の請求額が42ドルから6ドルに落ちる。読み間違えることがある、という条件つきで。

テキストと画像の「値段のつけ方」が違う

Claude Codeを長時間使うと請求が膨らむ原因は、リクエストのたびにシステムプロンプト、ツールの定義、過去の会話履歴がまるごと再送される構造にある。作業が進むほど文脈が長くなり、毎回のリクエストに含まれるトークン数が増えていく。

ここに目をつけたのがpxpipeだ。カナダ在住のソフトウェア開発者スティーブン・チョン（Steven Chong）氏が2026年5月に公開したオープンソースのローカルプロキシで、7月3日にHacker Newsの「Show HN」（自作プロジェクトの発表）に投稿されて注目を集めた。

pxpipeが利用するのは、テキストトークンと画像トークンの料金差だ。Claude Codeが扱うコードやJSONは、テキストとして送ると概ね1文字あたり1トークンを消費する。一方、画像はピクセル寸法に応じた固定のトークン数で課金され、画像の中にどれだけ文字が詰まっていても料金は変わらない。

この密度の高いコンテンツを画像化すると、画像トークン1つあたり約3.1文字を詰め込める。テキストトークンの約3倍の効率になる。

pxpipeはローカルマシン上でプロキシとして動作し、Claude Codeから/v1/messagesへ送られるリクエストを傍受する。システムプロンプト、ツールドキュメント、古い会話履歴といった嵩張る部分をPNG画像にレンダリングし、画像ブロックとして差し替えてからAnthropicのサーバーに転送する。

モデルはビジョン機能を使ってその画像を読み取る。直近の会話ターンとモデルの出力はテキストのまま通過するため、応答のストリーミングには影響しない。

具体的な数字がREADMEに記載されている。約4万8000文字のシステムプロンプトとツールドキュメントは、テキストで送ると約2万5000トークンになる。pxpipeがPNG1枚にレンダリングすると、約2700トークンで済む。

請求額はどこまで下がるか

チョン氏が公開している1万3709リクエストのプロダクションログでは、pxpipeを通さなければ100ドルになるはずの請求が約41ドルに収まった。59%の削減だ。別のログ（8904リクエスト分）では約70%の削減を記録している。同一セッションのデモでは、テキスト送信で42.21ドルかかった作業がpxpipe経由で6.06ドルまで下がった。

この数字の出し方にも工夫がある。多くの圧縮ツールは「圧縮したリクエストだけ」を分母にして節約率を算出するが、pxpipeは全リクエスト（圧縮しなかった小さなリクエスト、キャッシュの書き込みと読み込み、出力トークンを含む）を分母にしている。

毎回のリクエストで、圧縮前の原文に対して無料のcount_tokensプローブを並列で実行し、実際に課金された使用量と同じ行に記録する。比較対象と実測値が同時刻の同一リクエストから取得される設計だ。

Fable 5でしか成立しない理由

pxpipeがデフォルトで対応するモデルはClaude Fable 5とGPT-5.6に限られる。Opus 4.7/4.8では画像化されたテキストの約7%を誤読することが確認されており、オプトインでの利用となっている。

ベンチマーク結果を見ると、Fable 5の画像読解能力がこの手法を成立させている。モデルが暗記していない新規の乱数を使った算術テストで100問中100問正解。1万5000〜4万5000文字のセッションを対象にしたgist recallテスト（意思決定、値、パス、名称、否定表現の再現を問う）でも98問中98問正解だった。

SWE-bench Lite（10インスタンス）では、pxpipeのオン・オフ両方で10問中10問を解決し、リクエストサイズは65%減少した。

pxpipe画像化の精度（モデル別ベンチマーク）

テスト	N	テキスト	pxpipe（画像）
Fable 5
算術	100	100%	100%
gist recall	98/arm	98/98	98/98
16進数読み戻し	15	—	13/15
Opus 4.8
算術	710	100%	93%
16進数読み戻し	15	15/15	0/15

※READMEのベンチマーク表に基づく。gist recallはFable 5のみ実施。Opus算術のN=710はREADME記載値

より難度の高いSWE-bench Pro（19ペア）では、pxpipeオンで14/19、オフで15/19を解決した。19ペア中18ペアで判定が一致し、唯一の不一致は3回の追試で全て解決に至った。失敗は圧縮ではなくエージェントの実行ごとのばらつきだった。

読み間違える。しかも黙って

READMEには「The honest part（正直に言うと）」と題されたセクションがある。

画像化された密度の高いコンテンツ内で12文字の16進数文字列を正確に読み戻すテストでは、Fable 5が15問中13問正解、Opusは15問中0問正解だった。間違えたときの挙動が厄介で、エラーを返すのではなく、もっともらしい別の値を自信を持って返す。ハッシュ値、ID、シークレットなど、1文字でも違えば意味が変わるデータは画像化してはならない。

開発者自身も数週間の日常利用中に1件の実被害を報告している。画像化された会話履歴から人名を呼び出した際、モデルが自信を持って間違った名前を返した。エラーではなく、もっともらしい別の名前だった。コーディングセッションではエージェントがファイルを編集前に再読み込みするため被害が緩和されるが、会話履歴を画像経由で参照する用途では自己修正が働かない。

pxpipeは損失ありの圧縮であり、全コンテンツの忠実な再現を保証しない。READMEはこの制約を冒頭近くに明記している。

発想の系譜と、この手法の位置づけ

テキストを画像に変換してモデルに読ませるという発想自体は新しくない。ディープシークは2025年10月にDeepSeek-OCRを発表し、光学2Dマッピングによるコンテキスト圧縮を研究した。テキストトークンの10倍の圧縮率で97%のOCR精度を達成している。

両者のアプローチは根本的に異なる。ディープシークはモデルのアーキテクチャ側から取り組み、専用のビジョンエンコーダ（DeepEncoder）を構築した。pxpipeはフロンティアモデルがすでに持つ画像読解能力を前提に、インフラ層のプロキシとして料金構造の非対称性を突く。研究ではなく、実用上の最適化だ。

直近ではネットフリックスのエンジニアが開発したProject Headroom（コンテキスト圧縮ツール）が、トークン圧縮の別の道筋を示している。こちらはLLMに送るコンテキストの冗長なメタデータを可逆圧縮で除去するアプローチで、情報の欠損がない。pxpipeの不可逆な画像変換とは性質が異なり、正確性が求められる場面にはHeadroomの方が適する。

トークン圧縮アプローチの比較

	pxpipe	DeepSeek-OCR	Project Headroom
手法	テキストを PNG画像に変換	光学2D マッピング	メタデータの可逆圧縮
損失性	損失あり	損失あり	損失なし
圧縮率	59〜70%削減	10倍圧縮	最大90%削減
対象	Fable 5 GPT-5.6	専用モデル	モデル非依存
性質	料金差の利用	アーキテクチャ研究	コンテキスト最適化

※pxpipeの圧縮率はプロダクションログからのend-to-end実測値。DeepSeek-OCRの圧縮率は論文値。Project Headroomの削減率は開発元の報告値

この「穴」はいつまで開いているか

pxpipeに対するSNS上の反応は、称賛と懐疑に分かれている。「テキストのスクリーンショットを送った方がテキストそのものより安いなんて」という驚きの一方で、「料金設定のバグを突いているだけで、すぐ塞がれる」という指摘が複数ある。

この懸念には根拠がある。画像トークンの料金がピクセル寸法だけで決まる現在の体系が維持される限りpxpipeは機能するが、Anthropicが画像の情報密度に応じた課金を導入すれば、コスト優位性は消える。READMEも「prices move and workloads differ（価格は変動し、ワークロードも異なる）」と書いており、永続的な節約を約束していない。

もうひとつの不確実性は、画像リクエストに対する優先度のスケジューリングだ。Anthropicが画像ベースのリクエストに低い優先度を割り当てた場合、ドルの節約は維持されてもレイテンシが増大する可能性がある。現時点でAnthropicはこの手法についてコメントしていない。

Fable 5の入力トークン料金は100万トークンあたり10ドルとOpus 4.8の2倍にあたり、長時間のエージェントセッションでは入力コストの圧力がとくに大きい。Claude Codeの利用が広がるほど請求額も増える。

導入はnpx pxpipe-proxyの1コマンドで完了し、ANTHROPIC_BASE_URLをhttp://127.0.0.1:47821に向けるだけでClaude Codeが経由するようになる。ダッシュボードで変換の前後を確認でき、テスト環境での検証コストはほぼゼロだ。

損失ありの圧縮をプロダクションのワークフローに組み込む判断は慎重にならざるをえない。ハッシュ値やIDのサイレントな誤読は、テストスイートを通過した後に本番で表面化するタイプの障害を生む。pxpipeが正直に書いている制約を、導入する側も正直に受け止める必要がある。