「母病速帰」型 AI:トークン削減率 65% と謳うが実測はわずか 8.5%
ある開発者が「母病速帰」方式の AI テクノロジーがトークン削減率を 65% と主張していたものの、実際の検証ではわずか 8.5% の削減しか達成できず、技術の実用性とベンダーの主張に疑問を投げかけた。
キーポイント
主張と実測値の乖離
開発者が「母病速帰」方式によりトークン使用量を 65% 削減できると主張していたが、独立した検証では実際の削減率は 8.5% に留まった。
技術の信頼性への疑問
発表された数値と実測結果の大きな差は、同様の効率化手法に関する業界全体の信頼性やベンダーの主張に対する慎重な検証の必要性を示唆している。
コスト削減効果の実態
LLM の運用コスト削減が期待される中、この技術は実用レベルでの劇的な改善には至っておらず、現場適用における期待値管理の重要性を浮き彫りにした。
重要な引用
「母病速归」式 AI:号称省 65% Token,实测只有 8.5%
影響分析・編集コメントを表示
影響分析
この記事は、AI エコシステムにおいて「効率化」を謳う新技術に対する市場の過熱した期待に警鐘を鳴らすものであり、開発者や企業に対し、ベンダーの主張を盲信せず実証データを重視する姿勢の重要性を再認識させた。特にトークンコストが重要な経営課題となる中、過度な楽観視を防ぎ、現実的な技術評価基準を確立する一助となった。
編集コメント
技術のポテンシャルを語る際、実証データの透明性が欠如しているケースが散見される中、この検証記事は業界にとって極めて重要な「現実チェック」となっています。
AI のスキルにおいて「Token を削減する」「AI に最小限の発言を促す」手法を、私は「電報体スキル」と呼んでいます。
私たちが子供の頃、国語の授業で電报文の書き方を学びましたね。先生が題材を出します。「母親が病気になったので、遠くで働いている兄に急いで帰ってきてほしい」という内容です。そしてクラス全員で、いかに少ない文字数で用件を伝えるか競争しました。
最終的に4 文字まで絞り込むことができました。
**
母病速归。**
これ以上減らすことはできません。
「母病」だけでは、受け取った人が何をすべきか分かりません。「速帰」だけでも、家庭に何事があったのか伝わりません。
当時は文字を惜しむ必要がありました。電報は文字数で課金されるため、1 文字ごとに費用がかかるからです。
現在、この話し方が AI の世界で「スキル」として復活しています。
AI を原始人のように話させるスキル
GitHub には Caveman というプロジェクトがあります。その内容は極めてシンプルです。Claude Code や Codex などの AI プログラミングツールに特定のプロンプトを追加し、エージェントが原始人のように話すように仕向けるものです。
冠詞を削除し、挨拶やクッション言葉を削ぎ落とし、接続詞も省きます。残るのは技術的な要素だけ。
通常の回答は以下のようになります。
**
The issue is caused by a new object reference being created on every render...
Caveman を適用すると、こうなります。
New object ref each render. Wrap in useMemo.
このプロジェクトを開発したのは、オランダ・ライデン大学の 19 歳学生である Julius Brussee 氏です。リポジトリは 2026 年 4 月初旬に公開され、数日で GitHub Trending の首位に躍り出ました。7 月 12 日時点でのスター数は約 8.85 万に達しています。
README には出力トークンの大幅な圧縮が可能と記載されており、プロジェクト紹介で最も頻繁に登場する数字は65%です。
一見すると素晴らしいように聞こえます。
しかし、電報体と同じく、これは特定の価格帯や製品フェーズにおける過渡的な解決策である可能性が高いです。そして、実際のエージェントワークフローで節約できるコストは、宣伝されている数字ほど多くはありません。
65% の削減を謳うが、実測値は 8.5%
JetBrains は最近、この手法の真価を検証するテストを実施しました。記事タイトルは「Caveman のように AI エージェントに話しかけることは、本当にトークンの 65% を節約できるのか?検証してみた」です。
Claude Code を使用し、SkillsBench に収録された 86 の実際のプログラミングタスクを実行しました。Caveman をインストールした場合としない場合の両方でテストを行い、タスク、モデル、設定、予算はすべて同一に保ちました。
実験は全 3 ラウンドで行われ、約 240 回の課金テストが実施され、総費用は約 106 ドルでした。
Caveman の効果を最大限引き出すため、テストではすべての回答で強制的にこのスキルを適用させました。つまり、これは日常使用における平均値ではなく、ベストケースでの結果です。
その結果は以下の通りです。
- 宣伝されている削減率:出力トークンの 65%
- 大規模サンプルの実測値:出力トークンの 8.5%
- 出力トークン数:約 59.2 万から 54.2 万へ減少
- 有効なタスクペア:82 組

毎回レスポンスが強制的に圧縮されるため、この 8.5% という数字はすでに天井に近い値です。日常利用では、Skill がトリガーされるかどうかを自分で判断する必要があり、実際の節約効果はこの数値よりもさらに小さくなるでしょう。
Caveman について一言付け加えておきます。JetBrains のテスト結果では、タスクの品質に顕著な低下は見られませんでした。
82 ペアの比較タスクにおいて、64 で結果が同一でした。Caveman 版の方が優れていたケースが 8、劣っていたケースが 10 です。この差は統計的に有意ではありません。Caveman の問題点は「Agent を賢くなくしている」ことではなく、節約効果の大きさを過大評価していた点にあります。
Agent が消費する Token の大半は、チャットではない
なぜ 65% という数字が 8.5% に縮小したのか?
その理由は、65% の節約効果が主に「チャットシーン」から生まれたからです。
AI に質問すると、AI は長い文章で回答します。「もちろん」「ご要望にお応えして」「以下に詳しく説明します」といったお世辞や前置きをすべて削ぎ落とせば、確かにトークンの大半を節約できます。
しかし、プログラミング用の Agent はチャットボートではありません。
その Token 消費の大部分は、以下の要素によって占められています:
- システムプロンプトと蓄積し続けるコンテキスト
- コードやファイルの内容、検索結果
- ツール呼び出しとその返却結果
- 各種 Skill や MCP ツールの説明
- diff 情報、エラーメッセージ、テストログ
- モデルが複数回のタスクで繰り返し参照する内容
Caveman が主に圧縮するのは、ツール呼び出しの間の数行に及ぶ自然言語の説明です。コードを安易に変更したり、コマンドを省略したり、エラー情報をそのまま残さなかったり、ツールのパラメータを原始人風の文法に書き換えたりすることはできません。
つまり、Caveman が最適化している部分は、請求書全体から見ればごく一部に過ぎません。

これは、ある会社が旅費を削減しようとして、飛行機代やホテル代、タクシー代には手を付けず、従業員が毎日 2 円使うミネラルウォーターの支給を中止するのと似ています。
節約は確かにできますが、それで財務諸表を救済できると期待するのは無理があります。
文章が短くなるほど、暗黙の了解への依存度が高まる
電報体にも代償がないわけではありません。
例えば、Agent の最終レスポンスが以下のような一文だけになったとしましょう:
**
Fixed auth. Tests pass.
**
非常に簡潔で、トークンも節約されていますね。
しかし、これでは以下の情報が伝わりません:
- 修正したのはログインの有効期限切れ、権限チェック、リフレッシュトークンのどれか?
- 実行されたのは単一のユニットテストなのか、それともフルテストスイートなのか?
- データベースの構造変更は行われたのか?
- 互換性のリスクは残されていないか?
これらの情報は、毎回小論文のように詳細に記述する必要はありません。しかし、「穴居人(Caveman)のような簡潔さ」を理由に、安易に削除してはいけません。
開発者が Agent の行動内容を理解できないため、追加で質問せざるを得なくなります。Agent は再度ファイルを読み込み、テストを再実行し、説明を繰り返します。最初に節約した数十トークンは、すぐに次のツール呼び出しによって帳消しになってしまいます。
これは Caveman のベンチマークテストが、より多くの手戻りを引き起こすことを証明したわけではありません。JetBrains のテストではそのような品質低下は見られませんでした。問題は、「タスクが最終的に正しく完了すること」と「プロセスが人間にとって十分透明であること」は異なる指標だということです。
電報体が機能するのは、双方が膨大な背景情報を共有しているからです。
「母病速帰」の 4 文字には、誰の母親なのか、実家はどこか、なぜ戻らなければならないのかという情報が含まれていません。しかし、受け取る側はそれらをすべて知っています。
一方、プログラミング Agent は常に変化するコードや未知のリポジトリ、一時的なタスクに直面します。共有できる背景情報はそれほど信頼できません。表現が短くなるほど、暗黙の了解(默契)への依存度が高まります。そして、その默契が不足している場合、余分な一言一句こそが、通信プロトコルにおける誤り訂正符号として機能するのです。
**
冗長であることは、必ずしも無駄ではありません。次回のより高価な誤解を防ぐための手段だからです。**
電報体が淘汰されたわけではなく、存在意義を失っただけ
その後、電報体はどうなったのでしょうか?
誰かが「廃止する」と宣言したわけではありません。
長距離通信のコストが無視できるほど安価になった結果、「母病速帰」は自然と以下のような表現に戻りました:
**
妈住院了,你买最早的票回来,到了给我打电话。
(お母さんが入院しました。一番早い切符を買って戻ってきて、着いたら電話してください。)**
省文字化は、一文字ごとに課金される時代に向けた最適化です。しかし価格が下がれば、情報の完全性とコミュニケーションの体験が再び重要視され、こうした最適化も自然と役目を終えることになります。
トークンについても同様の道筋をたどるでしょう。
モデル単価は長期的に低下し続けており、キャッシュ技術によって重複するコンテキストのコストも下がっています。Anthropic の現在のプロンプトキャッシュ価格を見ても、キャッシュがヒットした入力トークンの読み取り料金は、通常の入力トークンの 0.1 倍**つまり約 9 割安価です。
「繰り返し読み込み」にすでに 9 割引の恩恵がある中で、無理して普通の文章を電報のように圧縮しても、得られる効果は限定的になります。
本当はここを削るべき:コンテキストと手戻り
もし本当に Agent のコストを下げるなら、あえて文字数を減らすことに固執するのではなく、以下の点に注力すべきです。
- 不要なコンテキストの読み込みを減らす
いきなりリポジトリ全体や全ドキュメント、過去の会話履歴をモデルに読み込ませるのは避けてください。
- 必要のない MCP やスキルを接続しない
ツール記述自体もコンテキストを消費します。接続する数が多いほど性能が上がるわけではありません。
- キャッシュ命中率を高める
安定したシステムプロンプト、ツールの定義、プロジェクトルールなどは、再利用可能なプレフィックスとして配置しましょう。
- 無効なツール呼び出しを減らす
まずは問題の特定を行い、その後にファイルを読み込みます。範囲を確定させてからテストを実行します。
- 適切なモデルを選ぶ
単純なタスクには安価なモデルを、複雑なタスクには信頼性の高いモデルを使います。手戻りを一つ減らすことが、数行の説明を省くよりもはるかに価値があります。

「Caveman」スタイルも使えます。簡潔な返信を好む場合や、Agent のお世辞に飽きた場合に、面白いかつ無害なスタイルプラグインとして機能します。
ただし、スタイルの最適化をコスト革命と誤解してはいけません。
本当に高価なのは、Agent が余計なことを言ったことではなく、不要な情報を大量に読み込み、同じ作業を二度やってしまったことです。
原文を表示
我把那种号称能省 Token、要求 AI 尽量少说话的 Skill,叫做“电报体 Skill”。
我们小时候上语文课,学过怎么写电报文。
老师先给出一件事:母亲生病了,要让在外地工作的哥哥赶紧回家。然后全班比赛拟电文,看谁能用最少的字把事情说清楚。
最后可以精简成四个字:
母病速归。
再少就不行了。
只写“母病”,收到的人不知道该做什么;只写“速归”,又不知道家里出了什么事。
那时候必须惜字如金,因为电报按字收费,每一个字都是钱。
现在,这种说话方式在 AI 圈子里借着 Skill 复活了。
一个让 AI 像原始人说话的 Skill
GitHub 上有个叫 Caveman 的项目,做的事情极其简单:给 Claude Code、Codex 等 AI 编程工具加一段提示词,让 Agent 像原始人一样说话。
删掉冠词,删掉客套,删掉连接词,只保留技术要素。
正常回复可能是:
The issue is caused by a new object reference being created on every render...
换成 Caveman 之后,就变成:
New object ref each render. Wrap in useMemo.
项目由荷兰莱顿大学一名 19 岁学生 Julius Brussee 做出来。仓库 2026 年 4 月初上线,几天内冲上 GitHub Trending 第一。截至 7 月 12 日,已经攒下约 8.85 万颗 Star。
它的 README 声称能大幅压缩输出 Token,项目介绍里最常出现的数字是 65%。
听起来很厉害。
但跟电报体一样,这很可能是一个特定价格和产品阶段里的过渡方案。而且它在真实 Agent 工作流里省下的钱,远没有宣传数字看起来那么多。
号称省 65%,实测只有 8.5%
JetBrains 最近专门做了一次测试,文章标题就叫:《Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? We Test》。
他们用 Claude Code 跑 SkillsBench 里的 86 个真实编程任务,安装 Caveman 和不安装各跑一遍。两边使用相同任务、相同模型、相同配置和相同预算。
整个实验分 3 轮,做了大约 240 次计费试验,总共花了约 106 美元。
为了给 Caveman 最大的发挥空间,测试还强制它在每一次回复里生效。也就是说,这不是日常使用的平均情况,而是它能拿到的最佳情况。
结果是:
- 宣传节省:65% 输出 Token
- 大样本实测:8.5% 输出 Token
- 输出 Token:从约 59.2 万降到 54.2 万
- 有效配对任务:82 组

因为每次回复都被强制压缩,这个 8.5% 已经接近天花板。日常使用时,Skill 还要自己判断是否触发,实际节省通常只会更少。
有一点也要替 Caveman 说清楚:JetBrains 没有测出显著的任务质量下降。
82 组配对任务里,64 个结果相同,Caveman 版本有 8 个更好、10 个更差,差异在统计上不显著。它的问题不是“让 Agent 变笨”,而是把省钱效果说得太大了。
Agent 的 Token,大头根本不在聊天
为什么 65% 会缩水成 8.5%?
因为 65% 主要来自聊天场景。
你问 AI 一个问题,它回你一大段话。把“当然可以”“很高兴帮你”“下面我来详细解释”这些客套和铺垫全部砍掉,确实可能省下一大半。
但编程 Agent 不是聊天机器人。
它的 Token 消耗大头通常包括:
- 系统提示词和不断累积的上下文
- 代码、文件内容和搜索结果
- 工具调用及返回结果
- 各种 Skills 和 MCP 工具描述
- diff、报错信息和测试日志
- 模型在多轮任务里反复读取的内容
Caveman 主要压缩的是工具调用之间那几句自然语言说明。代码不能乱改,命令不能缩写,错误信息要原样保留,工具参数更不能写成原始人语法。
它优化的那部分,在整张账单里本来就是零头。

这就像一家公司要压缩差旅费,机票、酒店和打车一项没动,先把员工每天 2 块钱的矿泉水取消了。
省是省了,但别指望靠这个拯救财报。
语言越短,对默契的要求越高
电报体也不是完全没有代价。
比如 Agent 最后只回复一句:
Fixed auth. Tests pass.
看起来非常干练,也很省 Token。
但它没有告诉你:
- 修的是登录过期、权限校验,还是刷新令牌?
- 跑的是一个单元测试,还是完整测试套件?
- 有没有改数据库结构?
- 有没有留下兼容性风险?
这些信息不一定每次都要展开成小论文,但也不能因为“说话像穴居人”就固定删掉。
开发者看不懂 Agent 做了什么,只好继续追问。Agent 再读一遍文件,再跑一遍测试,再解释一次。前面省下的几十个 Token,很快就会被新一轮工具调用吃回去。
这不代表 Caveman 的基准测试已经证明会导致更多返工。JetBrains 的测试没有发现这种质量损失。问题在于,“任务最终做对了”和“过程对人足够透明”不是同一个指标。
电报体能工作,靠的是双方共享大量背景。
“母病速归”只有四个字,收报人却知道母亲是谁、家在哪里、为什么要回去。
编程 Agent 面对的是不断变化的代码、陌生仓库和临时任务,共享背景没有那么可靠。表达越短,越依赖默契;而默契不足时,多说的那几句就是通信协议里的纠错码。
啰嗦有时不是浪费,而是为了避免下一轮更昂贵的误解。
电报体没有被淘汰,只是失去了存在的理由
电报体后来怎么样了?
没有人宣布废除它。
只是长途通信的价格降到可以忽略不计之后,“母病速归”自然变回了:
妈住院了,你买最早的票回来,到了给我打电话。
省字数,是给按字计费时代做的优化。当价格降下去,信息完整和沟通体验重新变得更重要,这种优化也就自然退场了。
Token 很可能也会走同一条路。
模型单价长期在下降,缓存技术也在把重复上下文变便宜。以 Anthropic 当前的提示词缓存价格为例,缓存命中的输入 Token 读取价格只有普通输入 Token 的 0.1 倍,也就是便宜约九成。
当“重复读”已经可以打九折中的一折,再费很大力气把一句正常的话压成电报文,收益就更有限了。
真正该省的,是上下文和返工
如果真想降低 Agent 成本,更值得做的不是逼它少说几个字,而是:
- 少加载无关上下文。 不要一上来就把整个仓库、所有文档和历史对话塞给模型。
- 少挂没必要的 MCP 和 Skills。 工具描述本身也占上下文,装得越多不等于干得越好。
- 提高缓存命中率。 把稳定的系统提示词、工具定义和项目规则放在可复用的前缀里。
- 减少无效工具调用。 先定位问题再读文件,先确定范围再跑测试。
- 选择合适的模型。 简单任务用便宜模型,复杂任务用更可靠的模型,少一次返工往往比省几句说明更值钱。

Caveman 当然可以用。你喜欢简洁的回复,或者受够了 Agent 的客套话,它是个有趣而且基本无害的风格插件。
但别把风格优化误当成成本革命。
真正昂贵的从来不是 Agent 多说了几句话,而是它读了太多没用的东西,又把同一件事做了两遍。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み