9月18日、Leilei Chenらが「The More It Says, the More You Pay: A Black-Box Audit of Provider-Side Token Inflation in LLM Services」と題した論文をarXivで公開した。LLMサービスのプロバイダーが出力トークン数を意図的に水増しして課金額を膨らませる攻撃手法を定式化し、ブラックボックス環境でも機能する検出手法を提案している。
「話すほど儲かる」構造的インセンティブ
LLM APIのほぼすべては従量課金（pay-per-token）モデルをとっている。出力トークン数を増やせば、回答品質をほぼ維持したまま課金額だけを引き上げられる。LLM API市場が急拡大し、大規模に利用する企業にとって月次のAPI費用がビジネス上の重要コストになりつつある今、この構造的インセンティブをプロバイダー側が悪用できるかどうかは、開発者にとって無視できないリスクだ。
本論文はその問題を「Provider-Side Token Inflation Attack（PTIA）」として初めて体系的に定式化した。PTIAとは、プロバイダーが制御するパイプライン内でひそかに生成を操作し、出力を水増しする行為だ。
PTIAは5種類のレイヤーで実行できる
論文では、PTIAを攻撃が仕掛けられるレイヤー別に5種類に整理している：
- クエリレベル：受け取ったユーザープロンプトを書き換えて長い回答を引き出す
- プロンプトレベル：システムプロンプトに「詳しく答えよ」などの指示を挿入する
- 表現レベル：プロバイダーがサーバー側でモデルの内部表現（隠れ状態）を操作し、冗長な生成を誘導する（ユーザーからは完全に不可視）
- モデルレベル：ファインチューニングで冗長な出力を出すようにモデル自体を改変する
- デコードレベル：サンプリングパラメータ等を操作して生成を引き延ばす
実験では、いずれの攻撃も平均出力長をクリーンなベースラインの10.2倍以上に引き上げることが確認された。財務的な動機と技術的な実現可能性の両面が揃っているという点が問題の核心だ。
なぜユーザー側からの検出が難しいのか
APIのブラックボックス性が検出を困難にする。ユーザーは出力テキストしか見えず、モデルの内部状態にアクセスできない。また、「この回答は長すぎる」という判断はタスクの性質によって大きく変わるため、単純な長さ統計だけでは偽陽性が多発する。
検出の鍵：「PTIA飽和」という現象
論文の最も重要な観察が「PTIA飽和（PTIA saturation）」だ。
PTIAを一度適用すると出力長は急増するが、さらに攻撃を強化したり複数の攻撃を組み合わせたりしても、長さの増加はほとんど頭打ちになる。原因はモデルの停止挙動にある。最初のPTIAがEOS（end-of-sequence）トークンの生成確率を急激に下げることで出力が長くなるが、確率がいったん十分低くなると、追加の介入を加えてもさらに下げる余地がほぼなくなる。その結果、追加介入による長さへの影響はごく小さくなる。
この飽和現象を逆手に取ったのが、論文が提案する軽量な単一プローブ監査（single-probe audit）だ。仕組みはシンプルだ：
- 通常のリクエストを送る（オリジナルリクエスト）
- 同じ内容に「長く答えてください」という制御された延長介入を加えたプローブリクエストを別途送る
- 2つの出力長の差（追加トークン数）を比較する
PTIAが行われているサービスでは、すでに出力が飽和しているため、プローブを送っても追加トークンがほとんど増えない。正常なサービスなら介入に素直に反応して出力が伸びる。この差が検出シグナルになる。
検出精度と実APIへの適用結果
この手法の強みは実装コストの低さにある：
- ローカルの参照モデル不要
- 過去のクリーンなレスポンスの蓄積不要
- オリジナルとプローブの2リクエストは通常のトラフィックと見分けがつかないため、プロバイダー側が検出・回避しにくい
4つのオープンウェイトモデル上での実験では、平均検出率85.1%、偽陽性率2%未満を達成した。
さらに、公開されているLLM API 15サービスに対してこの監査を適用したところ、7サービスがPTIA一致挙動として統計的にフラグ付けされた。論文内では具体的なサービス名は公開されていない。あくまで論文が提案する統計的手法によるフラグ付けであり、当該サービスが実際にPTIAを意図的に実施しているかどうかは確定していない点には留意が必要だ。ただし、現時点で市場の相当割合のAPIが同手法の基準で統計的に異常な出力長を示しているという結果は、開発者が無視しにくいデータだ。
開発者が参考にできる監査アプローチ
論文が示す監査アプローチをもとに、LLM APIに一定のコストをかけているエンジニアやチームは以下のような自主的な確認が可能だ（以下は論文の手法から導かれる一般的な応用であり、論文が直接推奨する対策リストではない）：
- 出力トークン数のログを継続的に取得し、同じプロンプトに対する回答長の分布を定期的に確認する
- 論文が提案するプローブ監査のアプローチを自前で実装する（原理上、数十行のスクリプトで実現できる水準）
- 複数のAPIプロバイダー間でコストと出力長の比較を定期的に実施する
LLM APIのコスト透明性への関心が高まる中、プロバイダー選定の判断材料として出力長の統計的な安定性を加えることは、今後の実践的な選択肢の一つになりうる。
詳細はThe More It Says, the More You Pay: A Black-Box Audit of Provider-Side Token Inflation in LLM Servicesを参照していただきたい。
