pxpipeは、ひとことで言うと「LLMに渡す長文を、必要に応じて画像に圧縮してしまうローカルProxy」です。Proxyというのは、アプリとAPIのあいだに入って通信を中継する仕組みのこと。ブラウザの世界でいう“中継サーバー”みたいなものだと思えば大きく外れていません。
普通、LLMにたくさんの文章を読ませると、そのぶんトークンが増えます。トークンは、AIが文章を扱うときの細かい単位で、課金やコンテキスト長の計算に使われます。つまり、長文を入れるほどお金も容量も食う。これは避けようがない、と思われがちです。
でも pxpipe はそこに逆張りをします。大量のテキストをPNG画像にして渡すと、モデル側の画像トークンとして扱われる。しかも記事の説明では、画像のトークンコストは「中身の文字量」ではなく「画像サイズ」で決まるとのこと。ここがキモです。びっしり文字が詰まった内容なら、テキストのまま送るより画像にしたほうが安い。かなり乱暴に言えば、「文字を読むAIに、文字じゃなくて写真を見せる」わけです。普通はやらない。でも、やる理由はちゃんとある。
この手法が効きやすいのは、コード、JSON、ツール出力、ログのような“密度の高いテキスト”です。文字がぎっしり詰まっていて、改行や余白が少ないものですね。こういうデータは、人間には読みにくいけれど、AIにとってもトークン効率が悪いことがある。pxpipeはそこを狙って、詰め込み方のうまい画像として再パッケージする。
READMEでは、約48k文字の system prompt と tool docs が、テキストなら約25k tokens、画像なら約2.7k image tokens になった例が出ています。かなり差があります。実際、Fable 5 では 59〜70% 程度の end-to-end bill 削減が見込める、と書かれていました。もちろん「常にこの数字」という話ではなく、ワークロード次第です。それでも、これだけ大きな差が出るなら、刺さる現場ではかなり刺さるはずです。
個人的には、この発想はかなり好きです。AIの周辺って、どうしても「モデルをもっと賢くする」方向に話が寄りがちですが、pxpipeは“入力の見せ方を変える”ことで勝とうとしている。発想が地味に見えて、実はかなりエンジニアリングっぽい。好き嫌いは分かれそうですが、私はこういう実務臭のある工夫にグッときます。
面白いのは、作者がこの仕組みの弱点もかなり正直に書いているところです。pxpipeは便利ですが、lossy、つまり情報を少し落とす前提です。ここは重要です。
たとえば、12文字の16進数みたいな、1文字違うと全然別物になる値は危険です。READMEでは、denseな画像化コンテンツの中の 12-char hex 文字列の再現で、Fable 5 では 13/15、Opus 4.8 では 0/15 という結果が出ていました。しかも、読み違えてもエラーにはならず、モデルがそれっぽく補完してしまう「silent confabulation」が起こる。これはかなり怖いです。
要するに、こういうものは画像化してはいけない。ID、ハッシュ、秘密鍵、正確な文字列が命のデータは、テキストのまま扱うべきです。pxpipe側もその点をはっきり認めていて、最近の会話内容や byte-exact が必要な部分はテキストに残す設計になっています。
この潔さは好感が持てます。何でも画像化すればいい、という雑な夢物語ではない。むしろ「どこまでなら画像化してよくて、どこから危険か」をかなりシビアに見ている。こういう誠実さがないツールは、だいたい現場で痛い目を見るので。
動きはシンプルです。pxpipeは /v1/messages へのリクエストを横取りして、条件に合う長いテキストを画像に変換し、それを含んだ形でAnthropic系のAPIに渡します。画像化されたコンテンツは、幅1928pxの列としてレンダリングされ、1枚におよそ92,000文字を詰め込めると説明されています。
ここでおもしろいのは、全部を機械的に画像化するわけではないことです。pxpipeは、どのリクエストなら得をするかを推定して、損しそうなものはテキストのまま通す。つまり「画像化すれば常に節約」ではなく、「節約できる場面だけ賢く使う」設計です。かなり実務的です。
しかも、レスポンス自体はそのままストリームされます。圧縮しているのは入力側だけで、出力をいじるわけではない。この割り切りもいい。変なことをしない。やることが絞られている。
READMEにはベンチマークがいくつか載っています。新規のランダム数値問題では、Fable 5 で text と image の両方が 100% だったり、Opus 4.8 でも 93% を維持したりしています。gist recall、state tracking、confabulation などのテストでも、かなりちゃんと機能している様子です。
ただし、ここで注意したいのは、すべてのモデル・すべてのタスクで同じ結果ではないことです。たとえば Opus 系では、画像化した細かい文字列の読み取りが弱い。だから Opus は opt-in、つまりデフォルトでは使わない扱いになっています。ここはかなり現実的で、無理に“一枚岩の成功”にしていないのがいい。
SWE-bench の結果も出ていますが、これは小規模なパイロットです。10/10 や 14/19 といった数字は魅力的ではあるものの、サンプル数はまだ小さい。だから「すごい!」で終わるより、「実案件で再現したら本当に効くのか」を見たほうがいい。私はこの手のツールを見ると、ベンチマークの見栄えよりも、現場での安定性が気になります。
README上では、npx pxpipe-proxy を起動して、Claude Code の接続先をローカルのProxyに向けるだけ、という導入になっています。Dashboard もあり、どのテキストが画像化されたか、どれだけ節約できたかを確認できるそうです。
この「まずは30秒で試せる」感じは好印象です。こういう尖ったアイデアは、説明だけ読むと怪しく見えるものですが、実際に触れる導線があると一気に説得力が増す。しかも、何が画像化されたかを見えるようにしているのが大事です。ブラックボックスだと、節約できても怖くて使えませんから。
pxpipeは、AIのコスト構造に対するちょっとしたハックです。正攻法というより、制度の隙間を見つけて上手に使うタイプの工夫。こういうのは、きれいに聞こえなくても現場では効くことがある。
ただし、ズルっぽい仕組みは、だいたい境界条件で事故ります。pxpipeもまさにそこを自覚していて、危険なデータは通さない、モデルごとに挙動を分ける、画像化の有無を可視化する、といった防御を入れている。ここがただの思いつきツールと違うところだと思います。
もしあなたが、長大な system prompt やツール出力、コード断片を毎回大量に投げていて、しかもトークン代がじわじわ痛いなら、かなり気になるはずです。一方で、数字の正確さが最優先の処理には向きません。万能ではない。でも、刺さる場所ではかなり刺さる。そういう道具です。
参考: GitHub - teamchong/pxpipe: cut Fable 5 token usage by rendering text context as images
