🤖 出力トークンを53.9%削るEdgeeの実験、p値まで見せてくれた

2026年7月2日、Edgee AIというチームが「Compressor V2」というブログ記事を出した。 LLMエージェントのコストを50%削るという、よくある煽り文句のタイトル。 また盛った数字だろうと思いながら開いた。でも中身は違った。p値が書いてあったのだ。

3枚のレイヤーを、正直に重ねる

Compressor V2は3つの戦略を直交レイヤーとして重ねる構成になっている。 1枚目は Brevity。エージェントに「計画を語らず結果だけ出せ」と指示し、出力の冗長さそのものを削る。 2枚目は Tool Surface Reduction(TSR)。LinearやNotion、GitHubなど複数のMCPツール定義——JSON記述にして30〜40個分——をゲートウェイ側で単一の仮想ツールに畳み込み、意図をサーバーサイドで解決してからモデルに渡す。 3枚目は Tool Result Trimming。長時間セッションで溜まっていくツール実行結果の冗長な出力を掃除する。

MCPツール定義の圧縮自体は日本語圏にもすでに解説がある。Claude Codeの Tool Search で85%削減、CloudflareのCode Modeで99.9%削減といった数字を見た人も多いはずだ。 Compressor V2が違うのは、そこで終わらず「出力トークンをどう削るか」まで踏み込んで、しかもSWE-bench 6タスクで実測している点だった。

Brevityだけ、有意差が出た

Brevity戦略の実測はこうだ。SWE-bench の自動コーディング6タスクすべてでコスト優位が確認でき、出力トークンは中央値27.5%減、総トークン比率にすると0.70倍(95%信頼区間 [0.41倍, 0.84倍])。統計的検定はp=0.031。サンプルサイズ6でこの数字は正直ギリギリだが、通したのが誠実だと思う。

# before: 計画を逐一説明させる指示
"まず設計方針を説明し、次に実装方針を述べてから、コードを書いてください"

# after: Brevity戦略
"結果だけ出力してください。途中経過の説明は不要です"

たった1行の指示変更で、出力トークンが半分近く減る。これは体感としても納得できる。AIエージェントに「まず〜します」「次に〜します」と逐一喋らせると、その分だけ課金される。無駄な前置きを削れば、それがそのままコストになる。

TSRの数字も見ておきたい。MCP実装クエリ8タスクでトークン33%減、コスト約10%減、p=0.008。TSRの方が統計的有意性は強いのに、コスト削減率はBrevityより小さい。入力より出力のほうが単価が高いため、削れたトークンの内訳が入力寄りだとコストには跳ね返りにくい。記事はそう説明していた。

そして3枚目のTool Result Trimming。ここは著者が「有意性に届かなかった」とはっきり書いている。コスト5〜10%減という数字は出したが、n=6のsign testでは方向性しか見えず、統計的に胸を張れる結果ではない、と。

「効いた」だけを書かないブログ

ここに一番驚いた。コスト削減系のブログ記事は、たいてい3施策とも成功したことにして締める。Compressor V2は3つのうち1つを「有意差なし」で終わらせている。 これをそのまま社外に出す判断は、実はけっこう勇気がいる。効果が薄い施策を隠さず書くブログの方が、次に読むときの信頼度は上がる。

自分のプロダクトでもプロンプトの冗長さを削る余地はまだ残っている気がする。まずはBrevityから真似してみるつもりだ。 数字を盛らずに書けるだろうか。