Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images

技術要約：プログラムのためのピクセル？ ソースコードをテキストおよび画像として扱う際の入力トークン計上に関するプロバイダー横断的なケーススタディ

問題提起
長いソースコードのコンテキストは、言語モデルのトークン制限を超えることが多く、そのためコードをビジョン言語モデル（VLM）用の画像としてレンダリングする提案がなされている。近年の研究では、この変換後にモデルがコードタスクを解けるかどうかが調査されているが、重要なシステム上の問いが未解決のまま残されている。具体的には、コードが生のテキストとして送信される場合と、コンパクトにレンダリングされた画像として送信される場合とで、APIプロバイダーによる入力トークンの計上方法がどのように変化するのか？ この関係はソースの長さに応じてどのようにスケールするのか？ そして、「視覚的圧縮（visual compression）」は異なるプロバイダー間で報告されるトークン数の純減をもたらすのか？

手法
本研究では、Anthropic、OpenAI、Google Vertex AIの主要な3つのプロバイダーにおける入力トークン計上を比較するために、再現可能なブラックボックス測定プロトコルを採用している。

• コーパス: データセットは、著名なオープンソースプロジェクトから抽出した5つのリビジョン固定済みソースファイル（Python, JavaScript, Rust, Go, Java）で構成される。これらのファイルは、20行から2,000行までの9つの入れ子状のプレフィックスに分割されている。
• 処置（コンパクト画像）: 画像アームには2段階の変換を適用する：
  1. インデント圧縮: 先頭の空白をコンパクトなマーカー（例：4スペースのインデントに対して >、不規則な連続に対して ^N）に置き換える。
  2. レンダリング: 変換されたテキストをPNGページとしてレンダリングする。
• 実験設計: 各ソースサイズおよび言語について、15の利用可能なモデルエイリアス（Anthropic 4種、OpenAI 6種、Gemini 5種）に対してペアとなるリクエストを送信する。両方のアームには、同一の一文の要約指示（「このコードが何をしているか一文で要約してください」）を含める。
• 指標: 主要な指標は、プロバイダーが報告する画像入力トークン数（$I$）とテキスト入力トークン数（$T$）の比率である。本研究では、加重集計比率（データセット全体の全トークンを合算）と、サイズ層別化された比率を報告し、ブレークイーブンポイントを特定する。
• 制約: 本研究は、トークン計上を、意味論的な忠実度、タスクの正確性、レイテンシ、金銭的コスト、またはコーディングエージェントの効率性から明確に分離している。画像トークンがテキストトークンと計算的に等価であるとは主張していない。

主な貢献

1. 再現可能なアーティファクト: 1,350件の成功したAPIコールと、675組の完全なテキスト/画像ペア（生の使用記録、バリデーター、決定論的な分析スクリプトを含む）からなるデータセット。
2. サイズ層別化された測定: トークン削減が均一ではないことを示す実証的証拠：削減率はソースの長さやプロバイダーによって大きく異なる。
3. モダリティ監査: 画像の計上が非単調な挙動を示すこと、特にページ境界において発生することを明らかにするターゲットを絞った調査。
4. 妥当性の境界: トークン計数指標と情報保持の間の明確な区分けを行い、「より少ないトークン」と「より良いパフォーマンス」または「より低いコスト」の混同を防ぐ。

結果

• 集計による削減: フルベンチマーク全体を通じて、コンパクトな画像は生のテキストよりも報告される入力トークン数が大幅に少なくなる：
  • Anthropic: 0.135の比率（86.5%削減）。
  • OpenAI: 0.194の比率（80.6%削減）。
  • Gemini: 0.242の比率（75.8%削減）。
• ブレークイーブン挙動: 集計比率は重要な差異を覆い隠している：
  • AnthropicおよびOpenAI: 画像入力は、テストされたすべてのサイズ（20〜2,000行）において、テキストよりも低いトークン数を受け取る。
  • Gemini: Geminiは短いコンテキストにおいて膨大なオーバーヘッドが発生する。20行の場合、Geminiの画像はテキストよりも6.95倍多くのトークンを必要とする。画像アプローチが有利になる（パリティを下回る）のは、200行に達してからである。
• モデルエイリアス: プロバイダー内において、多くのモデルエイリアスは同一の計上シグネチャを共有している（例：研究対象となった6つのOpenAIモデルはすべて同一の集計比率を返した）。これは、独立したモデルの挙動ではなく、共有された内部の計上ルールを示唆している。
• 非単調性: Geminiを対象とした詳細な監査により、報告される画像トークン数がページ境界で非単調に変化する場合があることが判明した。例えば、ソースを800行から1,200行に増やした（第2ページを追加した）結果、あるモデルでは報告される画像トークン数が減少した。これは、トークン数がコンテンツに対して線形にスケールするという期待に反するものである。

意義と主張
本論文は、コンパクトな画像レンダリングは長いコンテキスト（特定のプロバイダー、特定のレジーム）において報告される入力トークンを劇的に削減できる一方で、その恩恵は極めて条件的であることを主張している：

1. プロバイダー固有性: 普遍的な「視覚的圧縮」の利点というものは存在しない。Geminiのようなプロバイダーは高い固定コストを持つため、短いコンテキストでは画像は逆効果となる。
2. ルーティングへの影響: コーディングハーネスは「コードを画像として送る」というグローバルなポリシーに依存することはできない。代わりに、ルーティングロジックはプロバイダーやソースサイズごとに較正される必要があり、短いコンテキストやページ境界が不連続性を導入する場合には、テキストへのフォールバックを検討する必要がある。
3. トークン数の限界: 本研究は、報告されるトークンの減少が、同等の情報量、低い金銭的コスト、または計算量の減少を意味するものではないことを強調している。インデントマーカーが誤読されたり、ラスタライズによって句読点や構造が不明瞭になったりする可能性がある。
4. 今後の展望: 著者らは本研究を、将来の研究が構築できる「測定面（measurement surface）」として位置づけている。次の必要なステップは、トークン節約が実際のコーディングの有用性に転換されるかどうかを判断するために、表現とタスク品質（例：正確な転写、欠陥の特定）をクロス参照することであると主張している。

本論文は、コンパクトにレンダリングされたコードは、特定の条件下（長いコンテキスト、特定のプロバイダー）においてトークン計上のための実行可能な戦略であるが、注意深いプロバイダーごとの較正と、情報の忠実性に関するさらなる検証が必要であると結論づけている。