AIエージェントに何かを渡すとき、トークンを減らせば良くなる、という感覚があります。私も店長の右腕というMCPサーバーを作ったとき、渡す道具を15個で打ち止めにして、「何でも聞けるツール」を消しました。減らしたほうが結果が良かったからです。
ところが Hacker News で見かけた3本の記事を並べると、減らすと精度が上がる場所と、減らすと精度が落ちる場所があることが見えてきます。同じ「減らす」でも、削っている対象が違います。
密な言語なら有利、という直感
コーディングエージェントは、書いたコードの量だけトークンを使います。だとすれば、同じ処理を短く書ける言語のほうが安く速いはずです。
この直感には裏づけもありました。danluu の記事が引いている先行研究では、小さい課題を解かせたときの平均トークン数が Clojure で109、J で70。J は Clojure のほぼ半分で、C はいちばん効率が悪い、という結果です。
素直に読むと「密な言語を選べばいい」になります。実際、エージェント向けに簡潔な言語を使う話はよく出てきます。
大きい問題では逆転する
danluu はこれを大きい課題で測り直しています。渡すのは zstd の RFC で、デコーダを丸ごと実装させます。
結果は単純ではありませんでした。モデルに使わせる推論の深さ（原文では effort。高くするほど考えてから書く）が中くらいのうちは、動的言語がやや有利。ところが深さを上げると静的言語が上位に来る場面が出てきて、全体としては「most popular languages end up with more correct as well as cheaper solutions」——主流の言語のほうが、正解率もコストも良いという結果に落ち着きます。
danluu の記事の核は、本人のこの一文です。
very strong relationships that held in the trivial evals don't generalize to this larger case
小さい課題で出た強い相関が、大きい課題では成り立たない。トークン密度で節約できるぶんより、その言語が学習データに少ないことのほうが大きく響くからです。珍しい言語は書ける人が少なく、書かれたコードも少ない。学習データに少ないものを生成させると、密度で節約したトークンを、間違いの修正で払い直すことになります。
なお danluu は、この結論の弱さも自分で認めています。課題ごとのばらつきが大きく、もっと多くのタスクで試す必要がある。個別の言語について言えることは「unwarranted」（根拠不足）で、言語の種類についての示唆にとどまる。弱い結論の記事から強い結論を作らないほうがいいので、ここで言えるのは「密度の直感は、規模が上がると当てにならない」まで、にしておきます。
圧縮で減るのは、繰り返しの部分だけ
同じ日に、逆向きの例も出ていました。mcptoon という MCP クライアントです。
問題設定はこうです。MCPサーバーを5本つなぐと、ツール一覧の読み込みだけで1万トークン以上が消えます。まだ何も仕事をしていない段階での消費です。mcptoon は TOON という独自形式でこれを圧縮します。JSONの括弧・クォート・コロンをパイプや空白に置き換え、真偽値を T/F に、null を ∅ にする。{"a":{"b":[1,2]}} が a:b:1_2 になります。
mcptoon が掲げる削減率の内訳が、いちばんの学びどころです。
- ツール一覧: 97%削減（約2,000トークン → 60トークン）
- 構造化データの結果: 56%削減（800 → 350）
- HTMLやテキストの結果: 10%削減（1,000 → 900）
同じ圧縮なのに、97%と10%の差が出ています。理由は中身の性質です。ツール一覧は同じ形の繰り返しで、括弧とクォートと属性名が何度も現れます。繰り返しは削れます。一方、HTMLやテキストの本文は繰り返しではないので、記法を変えても減りません。
ここから引ける線は1本で、圧縮は構造にかかるのであって、中身にはかからない。エージェントへの入力でトークンを削りたいなら、まず見るべきは「同じ形が何度も出ているか」です。出ていないなら、形式を変えても骨折り損になります。
そしてもう1つ。danluu の話と mcptoon の話は矛盾していません。danluu が測ったのはモデルに書かせる側の言語で、mcptoon が圧縮したのはモデルに読ませる側のデータです。見慣れない記法で生成させると間違いが増えますが、機械的に変換されたものを読ませるだけなら、生成ほどの負荷はかかりません。
渡す量が極端に少ないとどうなるか
3本目の Needle2 は、45Mパラメータ・14MB・セッションRAM 28MB のエージェント向けモデルで、Raspberry Pi 5 やウェアラブル、200ドル以下のスマートフォンで動きます。用途はツール呼び出しとデバイス制御と構造化抽出に絞られていて、チャットも一般知識も持っていません。コンテキストは256トークンのスライディングウィンドウです。
この極端な条件でどこまでできるかは、公開されている精度に出ています。評価データセット Mobile Actions の961行に対して、ツール名を当てる精度は98.3%、1回の呼び出し全体では71.3%、2回の呼び出しでは48.4%。
呼び出しが1回から2回になると、正解率が23ポイント落ちます。どのツールを呼ぶかを当てるのは得意でも、呼んだ結果を受けて次を決めるのは別の能力です。制作側も「No small model covers everything」と書いています。
これは私がMCPサーバーで踏んだことと同じ形をしています。道具を増やすほどAIは選び間違えるので、渡す道具は15個で打ち止めにしました。複数の道具を組み合わせる段取りは自作のサーバー側に持たせず、呼び出す側のAI（クライアントのモデル）に任せています。組み合わせは、道具の数とは別の難しさです。小さいモデルではその差が数字に出る、というだけで、大きいモデルでも方向は同じです。
減らすなら、どちらを減らすか
3本を並べると、「減らす」が2種類あることが分かります。
- 選択肢を減らす — 道具の数、呼び出しの段数、扱う範囲。これは精度を上げる。選ぶ対象が少ないほど、選び間違いは減る
- 表現を圧縮する — 密な言語、短い記法。これは条件つき。繰り返しの構造があるところでは減り、モデルに生成させる場面では正解率を下げうる
判断の順番はこうなります。まず選択肢を減らせないかを見る。道具が20個あるなら、使われていないものを消す。1回で済む仕事を2回の呼び出しに分けているなら、1回にまとめる。ここは削るほど正解率が上がります。
そのうえでまだトークンが重いなら、繰り返しの構造を探す。ツール定義やスキーマのような、同じ形が何度も出るところは圧縮で減ります。本文や自然言語は圧縮しても減りません。
モデルに生成させるものの記法は、最後まで触らない。ここを密にしても、トークンの節約より間違いの増加のほうが大きくなります。
この線引きは、MCPサーバーを書くときも、エージェントに渡すプロンプトを削るときも、そのまま使えます。私が15個で止めたのは前者で、いま振り返ると、結果を良くしたのは「少ないから安い」ではなく「少ないから選び間違えない」のほうでした。