🤖 AI

Auditing Pay-Per-Token in Large Language Models

この論文は、大規模言語モデルのトークン課金における不正報告を検出するために、マルティンゲール理論に基づく監査フレームワークを提案し、その有効性を複数のモデルと戦略を用いた実験で実証したものである。

原著者： Ander Artola Velasco, Stratis Tsirtsis, Manuel Gomez-Rodriguez

公開日 2026-03-24

📖 1 分で読めます☕ さくっと読める

原著者： Ander Artola Velasco, Stratis Tsirtsis, Manuel Gomez-Rodriguez

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

この論文は、**「AI からの請求書が、実は『水増し』されていないか？」**という問題を解決するための、新しい「お会計の監査システム」を提案したものです。

まるで、レストランで料理を出された後、メニューの価格を勝手に書き換えて高い請求書を出されたような状況です。この論文は、その不正を見抜くための「魔法の会計士」の仕組みを説明しています。

以下に、難しい専門用語を排し、身近な例え話を使って解説します。

1. 問題：AI は「文字数」で請求するが、実はトリックがある

現在、多くの企業が AI（大規模言語モデル）をクラウド経由で使っています。その料金体系は**「使ったトークン（文字の断片）の数」×「単価」**というシンプルなものが多いです。

ユーザーの視点: 「AI に質問して、返ってきた文章を見て、その長さで払う」。
AI 業者の視点: 「実は、同じ文章でも、**『もっと細かく分割したトークン』**として報告すれば、文字数は増えるのに、ユーザーには同じ文章に見えるんだ！」

【例え話：レゴブロックのトリック】
想像してください。あなたが「赤い城」を注文しました。

正直な業者: 「城」を4 個の大きなブロックで組み立てて渡します。請求は「4 個分」。
ズルい業者: 同じ「赤い城」を、7 個の小さなブロックに細かく分解して渡します。
- 見た目（完成した城）は全く同じです。
- しかし、業者は「7 個のブロックを使いました」と報告し、7 個分の料金を請求します。

AI の世界では、同じ文章でも「どう分割するか（トークン化）」によって数が変わるため、業者は**「同じ文章なのに、あえて細かく分割して報告し、料金を水増しする」**という不正（ミスレポート）が可能になってしまいました。

2. 解決策：「魔法の会計士」による監査

この論文では、第三者の信頼できる「監査人（会計士）」が、AI 業者を監視する仕組みを作りました。

監査人の武器：「もしも、正直に作っていたら？」

監査人は、AI が「正直に（最も自然な形で）文章を作った場合、平均して何個のブロック（トークン）が必要か」を計算する能力を持っています。

質問をする: 監査人が AI 業者に「今日の天気は？」と質問します。
業者の回答: 業者は「晴れです」と答え、**「5 個のブロック」**で構成されたトークン列を報告します。
監査人の計算: 監査人は裏で AI をシミュレーションします。「『晴れです』という文章を、AI が正直に生成したら、平均して 3 個のブロックでできるはずだ」と計算します。
証拠の蓄積:
- 業者が「5 個」と報告し、監査人が「3 個」と計算した。差は「+2」。
- これを何十回も繰り返します。
- 正直な業者なら、計算結果と報告結果はバラついても「平均してゼロ」になります。
- しかし、ズルい業者なら、報告数が常に多くなるため、差（証拠）が右肩上がりに積み上がっていきます。

判定のルール：「賭けのゲーム」

このシステムは、**「賭け（ギャンブル）」**のような数学的な理論（マルティンゲール）を使っています。

正直な業者の場合: 監査人の「証拠の積み上がり」は、いつまで経っても一定の範囲で揺れ動くだけで、大きく増えません。
ズルい業者の場合: 証拠がどんどん積み上がり、ある一定のライン（閾値）を超えると、「バチッ！」と不正を宣告します。

この仕組みのすごいところは、「正直な業者を間違えて疑う確率（誤検知）」を、あらかじめ設定した低い値（例えば 5% 以下）に抑えながら、ズルい業者は必ず見抜けるという点です。

3. 実験結果：70 回も聞けばバレる

研究者たちは、実際に最新の AI モデル（Llama や Gemma など）を使って実験しました。

正直な業者: 100 回以上質問しても、監査システムは「不正あり」と判断しませんでした（安全です）。
ズルい業者: 不正な報告をする業者に対しては、たった 70 回程度の質問で、システムは「不正です！」と判定しました。

つまり、**「少しのサンプルで、すぐにズルを見抜ける」**ことが実証されました。

4. この研究の重要性

ユーザーの保護: これまで、ユーザーは「AI が使ったトークン数」を自分で確認する術がありませんでした。このシステムがあれば、「適正な価格で利用できているか」を検証できるようになります。
市場の健全化: 業者が「水増しして儲ける」インセンティブ（動機）がなくなるため、公平な競争環境が作られます。
規制への貢献: EU の AI 法などでは、第三者による監査が求められる動きがあります。この研究は、そのための具体的な「道具」を提供するものです。

まとめ

この論文は、**「AI 業者が、同じ文章でも『細かく分割』して請求額を水増しする手口」を、「数学的な統計テスト」**を使って見抜く方法を提案しました。

まるで、**「料理の味は同じなのに、器の数を勝手に増やして高く請求する店」を、「客が持ってきた『正味の器の数の平均』と照らし合わせることで、「70 回も注文すれば必ずバレる」**ようにしたようなものです。

これにより、AI サービスを利用する人々が、安心して適正な価格で利用できるようになることが期待されています。

論文「Auditing Pay-Per-Token in Large Language Models」の技術的サマリー

本論文は、大規模言語モデル（LLM）の「トークン課金（Pay-Per-Token）」モデルにおけるプロバイダによるトークン数の不正報告（Misreporting）を検出するための、第三者監査フレームワークを提案するものです。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

1. 問題定義：LLM 課金モデルにおける道徳的ハザード

背景: 多くの企業が LLM-as-a-Service を利用しており、利用料は生成された「トークン数」に基づいて課金されます。
情報の非対称性: プロバイダはモデルの生成プロセス全体（内部で生成された実際のトークン列）を観測できますが、ユーザーはプロバイダから提示された出力（文字列）と、それに対応する「報告されたトークン数」しか知りません。
トークン化の非一意性: 同一の文字列でも、トークン化の仕方は一意ではありません。例えば、"Morocco"という単語を 1 つのトークンとして扱うか、"Mor"と"oc"と"co"のように分割するかでトークン数が変わります。
不正のインセンティブ: プロバイダは、ユーザーに提示する文字列は変えずに、トークンを細かく分割して報告数を増やすことで、ユーザーから不当に多くの料金を徴収できます（Velasco et al., 2025 が指摘）。
課題: ユーザーはプロバイダが正直に報告しているか、あるいは過剰請求しているかを検証する手段を持っていません。

2. 提案手法：マルティンゲール理論に基づく逐次仮説検定

著者らは、この問題を**逐次仮説検定（Sequential Hypothesis Testing）**として定式化し、マルティンゲール（Martingale）理論とe-valueを用いた統計的検定フレームワークを構築しました。

2.1 基本的な枠組み

仮説:
- 帰無仮説 ( $H_0$ ): プロバイダは正直に報告している（報告トークン数 = 真のトークン数）。
- 対立仮説 ( $H_1$ ): プロバイダは不正に報告している（報告トークン数 > 真のトークン数）。
監査人の役割: 第三者の監査人が、プロバイダに対してランダムなプロンプトを順次送信し、応答と報告されたトークン数を取得します。
前提条件: 監査人は、プロバイダが使用するモデルの「次のトークンの確率分布（Next-token probability）」にアクセスできるものとします（オープンウェイトモデル、または規制によるアクセス権限）。

2.2 中核的な技術的貢献

A. 文字列をエンコードする平均トークン長の不偏推定量

プロバイダが報告した文字列 $s$ に対し、モデルが実際に生成したトークン列の平均長 $E[\text{len}(T) | \text{str}(T)=s]$ を推定する必要があります。

課題: 通常の生成プロセスでは、特定の文字列 $s$ になるようにトークンを生成することは困難です。
解決策: 著者らは、マスクされた次トークン確率を用いた修正生成プロセスを提案しました。
- 文字列 $s$ の接頭辞と一致しないトークンを確率 0 にマスクし、 $s$ に一致するトークンのみをサンプリングします。
- このサンプリング分布と元の分布の重み付け（重要度サンプリング）を行い、**ランダム化打ち切り（Randomized Truncation）を用いて、平均トークン長の不偏推定量（Unbiased Estimator）**を構築しました（アルゴリズム 1）。

B. マルティンゲールに基づく逐次検定

証拠の集積: 各ステップ $i$ で、報告されたトークン長と推定された平均トークン長の差 $E_i$ を計算します。
マルティンゲール過程 $M_i$ :
$M_i = M_{i-1} \cdot (1 + \lambda_i \cdot E_i)$
ここで、 $\lambda_i$ は証拠の重み付けパラメータです。
検定ルール: $M_i$ が閾値 $1/\alpha$ を超えた時点で、プロバイダを不正と判定します。
理論的保証:
- 偽陽性の制御: プロバイダが正直な場合、 $M_i$ はマルティンゲールとなり、Ville の不等式により、偽陽性率（正直なプロバイダを不正と誤判定する確率）が $\alpha$ 以下であることが保証されます（定理 3）。
- 検出の保証: プロバイダが不正を行っている場合（不正強度 $I(\pi) > 0$ ）、適切な $\lambda_i$ の設定により、有限ステップ内で必ず不正を検出できることが保証されます（定理 4）。

3. 実験結果

著者らは、Llama、Gemma、Ministral などの複数の LLM ファミリーと、LMSYS Chatbot Arena のプロンプトセットを用いて実験を行いました。

設定:
- 不正報告ポリシーとして、Velasco et al. (2025) で提案された「ランダム分割」と「ヒューリスティック分割」の 2 種類をシミュレーションしました。
- 誤検知率の上限 $\alpha$ を 0.05 に設定。
結果:
1. 正直なプロバイダの判定: 150 回の試行において、正直なプロバイダが誤って不正と判定されたケースは 0 でした。マルティンゲール過程 $M$ は初期値 1 の周辺で推移し、閾値を超えませんでした。
2. 不正なプロバイダの検出: 不正なプロバイダの場合、約 70 回以下の報告出力を観測するだけで、95% の確率で不正を検出できました。
3. 不正強度との関係: 不正の強度（報告されたトークン数の過剰分）が高いほど、検出に必要なステップ数は指数関数的に減少しました。
4. モデルへの近似アクセス: 監査人が使用しているモデルとプロバイダのモデルが異なる場合（例：量子化モデル）、フレームワークは頑健であり、依然として検出が可能でした。

4. 主要な貢献と意義

主要な貢献

初の監査フレームワーク: LLM-as-a-Service におけるトークン数の不正報告を検出するための、理論的に保証された初のフレームワークを提案。
不偏推定量の構築: 特定の文字列を生成する際の平均トークン長を推定する、効率的かつ不偏な推定量を開発。これは独立した関心を持つ技術的貢献です。
強力な理論的保証: 任意の不正報告ポリシーに対して、偽陽性を制御しつつ、不正を必ず検出できることを数学的に証明しました。

意義と将来展望

経済的インセンティブの是正: 現在の「トークン課金」モデルはプロバイダに不正のインセンティブを与えていますが、本フレームワークは第三者監査を通じてこのインセンティブを抑制し、ユーザーを保護します。
規制への対応: EU AI 法などの規制では、高リスク AI システムの監査のためにソースコードやモデルへのアクセスが認められる方向にあります。本手法は、そのような「信頼された第三者監査人」の役割を担うための具体的な技術的基盤を提供します。
実用性: 約 70 回のクエリで検出可能という結果は、実用的なコストで不正を検知できることを示しており、クラウド LLM サービスの透明性向上に寄与します。

結論

本論文は、LLM 市場の透明性を確保するための重要な一歩を踏み出しました。統計的検定理論（マルティンゲール）を応用することで、プロバイダの戦略的な不正報告を、高い確率で検出し、かつ誤判定を防ぐシステムを実現しました。今後は、より多様な不正ポリシーへの対応や、実社会でのプロバイダとの連携による実証が期待されます。