「母病速帰」型 AI：トークン削減率 65% と謳うが実測はわずか 8.5%

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 が余計なことを言ったことではなく、不要な情報を大量に読み込み、同じ作業を二度やってしまったことです。