Fable 5のコスト削減術が話題に：画像ベースのコンテキストで請求額を最大70%削減

pxpipeは、Fable 5の入力コストを削減する巧妙な方法を示しています。トークンを大量に消費するコンテキストをコンパクトな画像としてレンダリングし、モデルの視覚機能でその画像を読み取らせるのです。高密度なコーディング作業では、これによりリクエスト側のトークン使用量を大幅に減らし、エンドツーエンドのコストを引き下げられる可能性があります。ただし、この方法には情報の欠落が伴います。多くのコーディングや状態追跡のワークフローでは十分な意味を保てますが、ID、ハッシュ、秘密情報、正確な数値などをバイト単位で厳密に再現する用途には信頼すべきではありません。より大きなポイントは、AIシステム内でテキストが常にテキストのままである必要はないということです。CLIPPO、DeepSeek-OCR、pxpipeはいずれも同じ方向性を示しています。つまり、ピクセルは長いコンテキストに対する実用的な圧縮レイヤーになり得るのです。 **最適なユースケースは明確です。大きくて低精度でもよいコンテキストは圧縮し、重要で厳密な値は通常のテキストのまま保持することです。**

发布于 2026年7月8日•general•GEO 评分: 0•12 次阅读

Fable 5のコスト削減pxpipeClaude Codeのトークン削減画像トークン圧縮Claude Codeプロキシコンテキスト圧縮テキストから画像へのコンテキスト画像トークンAnthropic Messages APIDeepSeek OCRCLIPPO視覚コンテキスト圧縮AIコーディングコスト最適化

选择语言

العربية Deutsch English Español Français Italiano 日本語 한국어 Português Русский 中文

Fable 5のコスト削減テクニックを紹介するビジュアル。背景は暗いグラデーションで、右側にオレンジ色の放射状パターンがあります。画像内の文字「Fable 5 Cost-Saving Trick」では、「Cost-Saving」の部分がオレンジと紫のグラデーションになっており、「Use pxpipe to Reduce Claude Code Token Bills by Up to 70%」は白文字で表示されています。下部には3つのアイコンがあり、左にファイルアイコン、中央にグリッド付きの円柱形アイコン、右にファイルアイコンが配置されています。この画像は、pxpipeがClaude CodeのコンテキストをコンパクトなPNG画像に変換してFable 5の入力トークン使用量を減らし、最大70%のコスト削減を実現するという本文の内容に対応しています。

Fable 5のコスト削減テクが話題に：画像ベースのコンテキストで請求額を最大70％削減

はじめに

意外なほど昔ながらの手法が、Fable 5コミュニティで注目を集め始めています。長いテキストのコンテキストを高密度な画像に変換し、その画像をモデルの視覚機能で再び読み取らせる、というものです。

まるで試験用の小さなカンニングペーパーを作るような話に聞こえるかもしれません。ただし、この場合の「カンニングペーパー」は人のためのものではありません。スクリーンショットを読めるマルチモーダルモデルのためのものです。ある開発者は、Claude Codeのコンテキストを高密度に詰めたPNG画像へ変換することで、テストしたワークロードにおいて入力トークン料金をおよそ59％から70％削減できたと報告しています。

シンプルな発想です。システムプロンプト、ツールドキュメント、コマンド出力、ログ、過去の会話履歴は、しばしば非常に多くのトークンを消費します。こうしたブロックを画像としてレンダリングすれば、画像トークンのコストは主に画像の寸法に依存し、画像内にどれだけ多くの文字が詰め込まれているかにはあまり左右されません。

本記事では、pxpipeが何をするのか、なぜこの方法でコストを削減できるのか、どこで限界があるのか、そしてCLIPPOのような先行研究や、DeepSeek-OCRのような新しい光学的コンテキスト圧縮の研究とどうつながるのかを見ていきます。

出典注記

本記事は、BAAI Hubに掲載された中国語の原文記事に基づいています。同記事によれば、情報源はWeChat上のQbitAIです。元の参照リンクには、pxpipeのGitHubリポジトリとCLIPPOの論文が含まれています。以下に残している画像は、記事に関連するスクリーンショット、デモ、図表、ソーシャル上の議論のスクリーンショットです。QRコード、フォローを促す宣伝、エンゲージメント目的のCTA、無関係なプラットフォーム装飾は削除しています。

コンテキストを「カンニングペーパー」に変えて請求額を削減

話題になった手法は pxpipe と呼ばれています。これは、リクエストがあなたのマシンを離れる前に、膨大なClaude Code入力コンテキストを書き換えるオープンソースのローカルプロキシです。

プロジェクトの説明によれば、pxpipeは大きなテキストブロックを画像としてレンダリングすることで、トークン使用量を削減します。同じシステムプロンプト、ツールドキュメント、ツール出力、過去の履歴でも、モデルが高密度に描画された文字を十分に読み取れるなら、はるかに小さなトークン量に収めることができます。

ある例では、約48,000文字のシステムプロンプトとツールドキュメントは、プレーンテキストのままだと約25,000トークンかかります。これを1573×1248の画像にレンダリングすると、同じ内容が約2,700画像トークンで済んだとされています。

この差こそが、コスト削減の源です。

おおまかな

考え方は次のとおりです。

テキストのトークンコストは、テキスト量に応じて増加する。
画像のトークンコストは、主にピクセル寸法によって決まる。
高密度なコード、JSON、ツール出力、システムプロンプト、ログには、1行あたり多くのトークンが含まれていることが多い。
モデルが圧縮された画像を引き続き確実に読み取れるのであれば、同じコンテキストでも送信コストを下げられる可能性がある。

一部の開発者は、これは文字どおり「百聞は一見にしかず」のケースだと冗談を言っていました。この場合、その冗談は技術的な現実にかなり近いものです。

画像には、Rishabh Poddar が投稿したツイートが表示されており、ユーザー名は @rishpoddar、投稿時刻は20時間前です。ツイート本文は “A picture is worth a thousand words. Literally 😂” および「一枚の画像は千の言葉に値する。文字どおり😂」で、笑顔の絵文字が添えられています。このツイートは文書で紹介されている pxpipe 技術に関連しており、pxpipe は大きなテキストブロックを画像としてレンダリングすることでトークン使用量を削減します。文書では、一部の開発者がこれを「百聞は一見にしかず」だと表現しており、このツイートはその見方をユーモラスに示したものです。

画像にはツイート画面が表示されています。上部には、青い認証バッジ付きのユーザー Roman、ユーザー名 @romxdev、投稿日 7月5日が表示されています。ツイート本文は “Don't show this to Dario 😅 これをダリオに見せないで 😅” で、笑顔の絵文字が2つ添えられています。下部には350件のコメントがあり、画面右上には虫眼鏡アイコンと三点アイコンがあります。この画像は文書で紹介されている pxpipe のコスト削減テクニックに関連しており、開発者が Twitter 上で pxpipe に関する小話やコメントを共有したものと思われます。

pxpipe が実際に行うこと

pxpipe は新しいモデルではなく、従来型の OCR エンジンでもありません。Claude Code とモデル API の間で動作するローカルプロキシです。

リクエストが送信される前に、pxpipe は圧縮に適した大きなブロックを探します。次に、それらのブロックをコンパクトな PNG ページにレンダリングし、画像入力としてリクエスト内に戻します。モデルは通常のビジョンチャネルを使ってそれらのページを読み取ります。

画像には pxpipe プロジェクトの紹介内容が表示されています。タイトルは「About」で、pxpipe がテキスト内容を画像として表現することで『Fable 5』におけるトークン使用量を削減することが説明されています。プロジェクトには Readme、MIT license、Activity などの情報があり、3k stars、15 watching、201 forks といったデータも表示されています。下部には「Report repository」オプションがあります。この画像は、上で説明された pxpipe のローカルプロキシとしての役割やテキストブロック圧縮の内容に対応しており、pxpipe プロジェクトの関連情報を視覚的に示しています。

画像には pxpipe プロジェクトの GitHub ページが表示されています。ページ左側にはプロジェクトのナビゲーションバーがあり、Code、Issues、Pull requests、Actions、Projects、Security & quality、Insights などの項目が含まれています。右側にはプロジェクトのコード一覧があり、gpt2、gpt2-1.5、gpt2-2.0 など複数のファイルやフォルダが表示され、一部には更新時刻も記されています。ページ右上には「Go to file」ボタン、右下には「Code」ボタンがあります。この画像は、Claude Code とモデル API の間のローカルプロキシとして pxpipe が長いコンテキストを処理するという前述の内容に関連しており、pxpipe プロジェクトの GitHub 画面を視覚的に示しています。

平たく言えば、pxpipe は長いコンテキストに対する自動マイクロプリンターのように振る舞います。厳密な工学的意味でモデルにテキストを「OCR」させているわけではありません。代わりに、スクリーンショットのような視覚入力を読み取るモデルの内蔵能力に依存しています。

pxpipe の README では、主に次のようなかさばる入力コンテキストを対象にしていると説明されています。

ファイル読み取り、コマンド出力、ログを含む大きな tool_result 本文
折りたたまれた古い会話履歴
静的なシステムプロンプトやツールドキュメント

意図的にすべてを変換するわけではありません。直近のターン、ユーザーメッセージ、正確な識別子、小さなブロック、疎な散文、モデル出力はテキストのまま残されます。

なぜこれほど大きく節約できるのか

価格設定における根本的なミスマッチは、画像入力とテキスト

入力は異なる形で計測されます。

テキスト量の多い開発者向けワークフローでは、元データはトークン密度が高いことがよくあります。コード、ログ、JSON、スタックトレース、ツールスキーマは、プレーンテキストとして送るとコストが高くなりがちです。pxpipe の作者によれば、実際の Claude Code のトラフィックでは、高密度なコンテンツは画像トークン 1 つあたりおよそ 3.1 文字を詰め込める一方、テキストトークン 1 つあたりは約 1 文字だと見積もられています。

この比率により、テキストの密度が十分に高い場合、pxpipe にはコストを削減する余地があります。

作者は比較デモも共有しています。元のテキスト版では、あるテスト実行の最終請求額が 42.21 ドルで、コンテキストウィンドウもほぼ満杯になったと報告されています。pxpipe 版では、同じタスクが 6.06 ドルで完了し、コンテキストにもはるかに多くの空きが残っていました。

画像は、Fable 5 で pxpipe 使用前後のコスト削減比較を示している。左側は元のテキスト版で、テスト実行終了時の請求額が 42.21 ドル、コンテキストウィンドウはほぼ満杯。右側は pxpipe 版で、同じタスクを 6.06 ドルで完了し、コンテキスト空間もかなり残っている。画像は文脈と密接に関連しており、pxpipe のコスト削減効果を直感的に示し、具体的な数値比較を通じて、テキスト密集型の開発ワークフローで費用を大幅に下げられることを説明している。

重要なのは、pxpipe が圧縮するのはリクエスト側だけだという点です。モデルの応答は引き続き通常どおりテキストとしてストリーミングで返ってきます。出力トークンは圧縮しません。

ベンチマーク結果と最大の注意点

この手法は印象的ですが、可逆ではありません。高密度な画像コンテキストは、モデルの視覚的な読み取り能力に大きく依存します。

pxpipe のベンチマークのスクリーンショットでは、Fable 5 が新規算術、要旨想起、状態追跡、そして一部の高密度レンダリング想起テストを含む複数の画像コンテキスト課題で良好な性能を示しています。しかし、正確な文字列の想起は弱点であり、特に高密度テキストの読み取りが得意でないモデルではその傾向が強くなります。

画像は、Fable 5 の各種テスト課題における性能データを示している。表には Test、N、Text、pxpipe（Image）、tokens などの列が含まれる。たとえば「novel arithmetic」テストでは、claude - fable - 5 と claude - opus - 4 - 8 の Text はどちらも 100%、pxpipe（Image）はそれぞれ 100% と 93%、tokens の変化はいずれも -38%。このほか、「gist recall A/B」「state tracking」などのテストデータもある。この図は文脈と密接に関連しており、Fable 5 の画像・テキスト課題における性能を直感的に示している。

報告されたベンチマーク表を簡略化すると、次のようになります。

Test	N	Text	pxpipe Image	Token Change
Novel arithmetic, `claude-fable-5`	100	100%	100%	-38%
Novel arithmetic, `claude-opus-4-8`	100	100%	93%	-38%
Gist recall A/B, Fable 5	各群 98	98/98	98/98	—
State tracking, Fable 5	各群 18	18/18	18/18	—
Confabulation on never-stated facts, Fable 5	各群 16	0/16	0/16	—
Verbatim 12-char hex recall, Opus	15	15/15	0/15	—
Verbatim 12-char hex recall, Fable 5	15	—	13/15	—

危険性は明らかです。画像ベースのコンテキストは、大まかな意味理解、状態追跡、多くのコーディング作業には十分有効な場合がありますが、正確な文字列を気づかないうちに誤読する可能性があります。

ID、ハッシュ、シークレット、固定された数値、その他のバイト単位で正確である必要のある値は、高密度画像に押し込むべきではありません。pxpipe 自身の注記もこの点を強調しています。つまり、このトレードオフは重大であり、失敗時には明白なエラーではなく、自信満々だが誤った回答になる可能性があるのです。

画像には 2 件の投稿が表示されている。上の投稿は @IntCyberDigest によるもので、pxpipe を使う際に、ID、hash、鍵などの正確な文字列を高密度画像へ押し込むことにはリスクがあり、データが転送中に失われたり、誤って解釈されたりする可能性があると注意を促している。

以下のツイートには、@sanixdarker が返信しており、このやり方は目新しいものではなく、『Opus』のリリース以来ずっとそうしてきたのであり、『Fable』シリーズとは直接関係がないと述べている。画像は文脈と密接に関係しており、特定のデータを高密度画像に押し込むことで生じうるリスクについての議論を直感的に示している。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/8d83ec15-fc8e-4019-8909-2d441f51f258-10-af6628e8-7211-4ee2-8a25-33b3a4e2a529.png)

pxpipe がテキストとして保持するもの

圧縮は非可逆であるため、pxpipe はすべての入力ブロックを無条件に画像としてレンダリングするわけではない。機密性が高い内容や、精度が重要な内容はテキスト形式のまま保持する。

通常のテキストとして残すべき例は次のとおり。

ID とハッシュ
シークレットとキー
正確な数値
直近でやり取りされた会話ターン
ユーザーメッセージ
トークン密度が十分でなく、恩恵を受けにくい疎な文章

このため、このプロジェクトでは節約効果をワークロード依存として位置づけている。リクエストの大半が長い自然言語の文章であれば、圧縮は採算に合わない可能性がある。一方、コード、JSON、ログ、ツール出力が多く詰め込まれている場合は、節約効果がはるかに大きくなることがある。

pxpipe を試す方法

作者は非常に簡潔な起動手順を示している。まずローカルでプロキシを起動し、その後 Claude Code からそのプロキシを参照する。

npx pxpipe-proxy                                  # 127.0.0.1:47821 でプロキシを起動
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # Claude Code からそのプロキシを使う

起動後、pxpipe はローカルダッシュボードも公開する。

http://127.0.0.1:47821/

このダッシュボードでは、トークン節約量、テキストから画像への変換の比較表示、キルスイッチ、ライブのモデルタグなどを確認できる。これにより、何が圧縮され、何がそのまま通過しているのかを正確に把握しやすくなる。

Google の 2022 年の CLIPPO 論文はすでにこの方向性を示していた

pxpipe が広まり始めた後、一部の研究者は、この中核的な発想は完全に新しいものではないと指摘した。

関連する研究の流れは、Google の 2022 年の論文 CLIPPO: Image-and-Language Understanding from Pixels Only にすでに見られる。CLIPPO の中心的なアイデアは、テキストを独立したトークン化済みテキスト列としてではなく、ピクセルとして扱うことにある。

画像には、Fable 5 のコスト削減テクニックに関する Lucas Beyer のツイートが示されている。彼は、最先端の研究所が突然コストを削減したり、「推論に必要なメモリを大幅に減らす方法を見つけた」と主張したりするとき、その秘訣は常に視覚が勝つことにあると述べている。画像には Google Research の CLIPPO 論文も示されており、その中心的なアイデアは、テキストを独立したテキスト列ではなくピクセルとして扱い、共有の Vision Transformer で画像とレンダリングされたテキストを処理することにある。従来の CLIP スタイルのモデルと比べて、CLIPPO は同じパラメータ数で画像、テキスト、マルチモーダルのタスクをこなし、学習時間も半分に短縮されている。

従来の CLIP スタイルのモデルは、画像用とテキスト用の 2 つのタワーを使うことが多い。CLIPPO はこの分離をなくし、テキストを RGB 画像としてレンダリングし、画像とレンダリング済みテキストの両方を共有の Vision Transformer に通す。

画像には、CLIP と CLIPPO のモデルアーキテクチャの比較が示されている。左側の CLIP モデルでは、画像は CONV 層を通って Vision Transformer に入り、テキストは WORD EMB と TOK を経て Text Transformer に入り、両者は Contrastive によって相互作用する。右側の CLIPPO モデルでは、画像とテキストの両方が CONV 層を通って Transformer に入り、画像とテキストの分離処理が取り除かれている。この図は文脈と密接に関係しており、CLIPPO がテキストを RGB 画像として扱い、共有の Vision Transformer を用いるという中核的なアイデアを直感的に示しているため、CLIPPO のモデルアーキテクチャを理解するうえで重要な例となっている。

重要なポイントはこうだ。テキストは必ずしも離散的なテキストトークンとしてモデルに入力される必要はない。ピクセルへ変換し、視覚系の経路を通して処理することもできる。

DeepSeek-OCR と Optical Context Compression

この議論はまた

DeepSeek-OCRにも言及しており、これは長いコンテキストに対する光学的圧縮に焦点を当てています。そのリポジトリでは、このプロジェクトを「Contexts Optical Compression」と説明しています。

画像には2件の投稿が表示されている。上の投稿はJQによるもので、約1年前にDeepseekがDeepseek OCRプロジェクトでテキストを画像として処理する技術を試しており、当時その圧縮可能性に人々が興奮していたことに触れている。下の投稿ではLucas Beyerが返信し、その件を何となく覚えていると述べている。これら2件の投稿は、文書内でpxpipeやDeepSeek-OCRなどの技術について論じている箇所に関連しており、pxpipeが単なる一時的なコスト削減の小技ではなく、光学的圧縮といった潮流ともつながっていることを示している。

画像はGitHubのページを示しており、ページタイトルは「deepseek - ai/DeepSeek - OCR: Contexts Optical Compression」。ページには、コントリビューター1人、Issue 248件、スター23k、fork 2kと表示されている。下部にはMatthew Campbellのコメントがあり、Deepseekは2025年10月にも似た内容を公開していたので、今回の新規性が何なのか分からないと述べている。この画像は文書内のpxpipeとDeepSeek-OCRに関する議論に対応しており、pxpipeとDeepSeek-OCRが光学的圧縮の面で類似点を持ち、両者の関係について考えさせるものであることを示している。

その意味で、pxpipeは単なる一発限りのコスト削減の小技ではありません。いくつかのトレンドを結びつけています。

CLIPPOは、テキストを画像として処理できることを示しました。
DeepSeek-OCRは、長文コンテキストの光学的圧縮を探究しました。
Fable 5は、高密度な視覚的読解に十分強力であり、これが実際のコーディングワークフローで有用になる段階に達しているように見えます。

ただし、依然として大きな制約があります。それは、文字列を厳密に一致させる信頼性です。一部のコメント投稿者は、この問題はより強力な視覚言語モデルを単純にスケールアップすることで改善する可能性があると示唆していました。

この画像には、pxpipe関連技術の問題について議論する2件のSNS投稿のやり取りが表示されている。Shardulの投稿では、この技術には情報損失という欠点があり、識別子やハッシュ値のように正確かつ完全である必要がある内容は誤って読み取られる可能性があると指摘している。一方、Lucas Beyerの投稿は簡潔に返信しており、モデル規模を拡大すればこの問題は解決できるという見方を示している。このやり取りは、文書で述べられているpxpipeの「厳密な文字列信頼性」に関する限界と、より強力な視覚言語モデルによる改善の必要性に対応している。

実践的なポイント

pxpipeが最も有用なのは、コンテキストが大きく、高密度で、かつ精密さが決定的ではない場合です。コーディングセッションは自然に適した用途です。というのも、エージェントは編集前にファイルを何度も読み返すことが多く、誤って読んだ画像ブロックに基づいて動作してしまうリスクを下げられるからです。

一方で、文字単位での正確な再現が重要なワークフローにはあまり向いていません。タスクが識別子、ハッシュ、認証情報、正確な法的文言、金融上の数値、あるいはそれに類する精度に敏感な内容に依存する場合、画像ベースの圧縮は慎重に扱うべきです。

pxpipeの賢明な使い方は、信頼境界ではなく最適化レイヤーとして位置づけることです。計算上メリットがある箇所では巨大なコンテキストを圧縮させつつ、重要な値はテキストのまま保持し、モデルの挙動がおかしいときにはダッシュボードを確認するようにします。

FAQ

pxpipeとは何ですか？

pxpipeは、かさばるClaude Codeの入力コンテキストをコンパクトなPNG画像にレンダリングすることで、トークン使用量を削減するローカルプロキシです。ツール出力、ログ、コード、システムプロンプト、古い会話履歴のような高密度なコンテキスト向けに設計されています。

pxpipeはどのようにFable 5のコストを削減するのですか？

これは、画像トークンのコストが主にピクセル寸法に依存する一方、テキストトークンのコストはテキスト量に応じて増えるという事実を利用しています。モデルが高密度にレンダリングされたテキストを信頼できる形で読めるなら、大きなブロックはプレーンテキストよりも画像のほうが安くなる場合があります。

pxpipeはモデルの出力も圧縮しますか？

いいえ。pxpipeが圧縮するのは、リクエスト送信前の選択された入力ブロックだけです。モデルの

レスポンスは通常どおりテキストとしてストリーミングされるため、出力トークンは削減されません。

画像ベースのコンテキスト圧縮はロスレスですか？

いいえ。これは非可逆圧縮です。広い文脈の把握、状態追跡、多くのコーディング作業ではうまく機能しますが、ID、ハッシュ、シークレット、正確な数値のような厳密な文字列は誤読される可能性があります。

pxpipe はどのモデルでも使えますか？

安全とはいえません。pxpipe 自身のドキュメントでも、モデル対応は限定的でワークロード依存であるとされています。高密度にレンダリングされたテキストを読む能力はモデルによって大きく異なるため、未対応または性能の弱いモデルでは、明示的に有効化しない限りテキストのまま通すべきです。

どのような種類のコンテンツはテキストのままにしておくべきですか？

ID、ハッシュ、シークレット、正確な数値、ユーザーメッセージ、直近のやり取り、およびその他の精度が重要なブロックは、テキストのままにしておくべきです。pxpipe は、ログ、ツールドキュメント、古い履歴のような、長く高密度で、バイト単位の正確さへの依存が比較的低い素材により適しています。

pxpipe をローカルで実行するにはどうすればよいですか？

npx pxpipe-proxy でプロキシを起動し、その後 ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude で Claude Code を実行します。ローカルダッシュボードは http://127.0.0.1:47821/ で利用できます。

要約

pxpipe は、Fable 5 の入力コストを削減する巧妙な方法を示しています。すなわち、トークンを多く消費するコンテキストをコンパクトな画像にレンダリングし、モデルの視覚機能を通じてそれらの画像を読ませるという方法です。高密度なコーディング作業では、これによりリクエスト側のコストを大幅に削減できる可能性があります。

トークン使用量とエンドツーエンドのコストを低減できます。

その代わり、この手法には情報の欠落があります。多くのコーディングや状態追跡のワークフローにおいては、十分な意味を保持できますが、ID、ハッシュ、シークレット、あるいは正確な数値をバイト単位で厳密に再現する用途には信頼すべきではありません。

より広い観点で言えば、AIシステムの内部では、テキストが常にテキストのままである必要はありません。CLIPPO、DeepSeek-OCR、pxpipeはいずれも同じ考え方を示しています。つまり、ピクセルは長いコンテキストのための実用的な圧縮レイヤーになり得るということです。

最も適したユースケースは明確です。かさばる低精度のコンテキストは圧縮し、重要な正確値は通常のテキストのまま保持することです。