Caveman：AIエージェントが「話さない」ことでトークンを節約する
AIエージェントは、プログラミング、リサーチ、業務自動化などで身近なツールになりつつあります。しかし、エージェントを長時間利用していると、ある問題が発生します。
AIはコードを書いたりタスクを実行したりするだけでなく、大量の説明、コメント、中間的な記述まで生成することがあります。
これらの情報が役立つ場合もありますが、context が膨らみ、レスポンスが遅くなり、使用するトークン量が増える原因にもなります。
Caveman が解決しようとしているのは、まさにこの問題です。重要な技術情報を維持しながら、AIエージェントの回答をより簡潔にします。
トークンはどこで消費されているのか？
AIエージェントを利用する際、トークンはユーザーの質問だけに使われるわけではありません。
1回のセッションには、次のような情報が含まれる場合があります。
- プロンプトの内容
- 会話履歴
- ファイルやログの内容
- Tool Schema
- ターミナルコマンドの実行結果
- エージェントによる説明
- コード、diff、エラーメッセージ
- 複数回の反復処理で再送されるcontext
この中でも、自然言語による説明には、最終的な結果に直接影響しない文章が多く含まれることがあります。
例
例えば、次のような回答の代わりに、
“The reason your React component is re-rendering is likely because you are creating a new object reference on each render cycle…”
より簡潔に、
“New object ref each render. Inline object prop = new ref = re-render. Use useMemo.”
と回答できます。
どちらも同じ技術的な内容を伝えていますが、2つ目の回答は大幅に短くなっています。
これがCavemanの基本的な考え方です。
不要な説明を減らしながら、必要なコード、コマンド、技術的なエラー情報は維持します。
長時間のセッションでAIの回答が長くなる問題
長い回答が必ずしも良い回答とは限りません。
多くの技術タスクでは、ユーザーが必要としているのは次のような情報だけです。
- 原因
- 解決方法
- 修正するファイル
- 実行するコマンド
- 検証結果
しかし、AIは次のような情報を追加することがあります。
- 長い導入
- 繰り返しの説明
- 必要のないコメント
- 要件の再説明
- 各ステップ間のつなぎの文章
- すでに説明した内容を繰り返す結論
1つの質問だけでセッションが終わるのであれば、この余分な出力はそれほど大きな問題ではありません。
しかし、エージェントが複数回のやり取りを通して作業する場合、こうした出力が積み重なり、context が徐々に大きくなります。
context が大きくなると、後続のターンでエージェントが処理しなければならない情報量も増えます。
その結果、次のような影響が考えられます。
- レスポンス速度
- context limit
- 状態を追跡する能力
- モデルの利用コスト
Cavemanとは？
Cavemanは、AIエージェントの回答をより簡潔にするためのAI skill/pluginです。
その基本的な考え方は、次のようにまとめられます。
必要な情報を残し、価値を追加しない説明を削除する。
Cavemanは主に自然言語によるoutputを短縮します。
一方で、重要な情報を失わないように、コード、コマンド、エラーメッセージなどは維持します。
Cavemanは、以下のような主要なcoding agentをサポートしています。
- Claude Code
- Codex
- Gemini CLI
- Cursor
- Windsurf
- Cline
- Copilot
Cavemanには、軽い簡潔化から強い簡潔化まで、回答の圧縮レベルを調整できるモードもあります。
短い回答が必要なときはskillを有効にし、詳細な分析が必要な場合は無効にするといった使い分けができます。
Before / After
例1：Reactのエラーを説明する
Caveman使用前：
The reason your React component is re-rendering is likely because you are creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I recommend using useMemo to memoize the object and preserve the same reference between renders.
Caveman使用後：
Inline object creates new reference each render → React re-renders. Use useMemo.
結果： 原因と解決方法は同じまま、説明だけを短くできます。
例2：コード変更を要約する
Caveman使用前：
I have reviewed the changes and found that the authentication middleware now correctly validates token expiration. The implementation checks the expiration timestamp before allowing the request to proceed. This should prevent expired tokens from being accepted by the API. No additional changes appear to be necessary.
Caveman使用後：
Auth middleware now checks token expiry. Expired tokens rejected. No further changes needed.
CavemanプロジェクトのBenchmark
Cavemanのrepositoryで公開されているbenchmarkによると、10個の技術系promptにおいて、skillを使用することでoutput tokenを平均約65%削減しています。
タスクによって削減率は**22%〜87%**の範囲となっています。
benchmarkでは、平均outputが1,214 tokenから294 tokenまで減少しています。
| Task | Normal | Caveman | 削減率 |
|---|---|---|---|
| Explain React re-render bug | 1,180 | 159 | 87% |
| Fix auth middleware token expiry | 704 | 121 | 83% |
| PostgreSQL connection pool | 2,347 | 380 | 84% |
| Explain Git rebase vs merge | 702 | 292 | 58% |
| Refactor callback to async/await | 387 | 301 | 22% |
| Review PR for security issues | 678 | 398 | 41% |
| Implement React error boundary | 3,454 | 456 | 87% |
| 平均 | 1,214 | 294 | 65% |
これらの数値から、Cavemanが説明的なoutputを大幅に削減できることが分かります。
ただし、この数値はあくまでプロジェクト独自のoutput token benchmarkにおける結果です。
すべてのセッションで総コストが65%削減されるという意味ではありません。
独立した検証結果
JetBrainsはSkillsBenchに含まれる86件の実際のcoding taskを対象に、A/B benchmarkを実施しました。
同じmodel、task、設定、budgetを使用し、この実験ではCavemanを強制的に有効化しています。
JetBrainsの結果では、次のことが確認されています。
- 実際のagentic taskにおけるoutput tokenが約8.5%削減
- 品質について大きな低下は確認されなかった
- 82 taskをpair comparisonに使用
- 64 taskは同等の結果
- 8 taskはskill使用時の方が良い結果
- 10 taskはskill使用時の方が悪い結果
- 期待されるコスト削減は約**10%**だが、特殊なtaskの影響を受ける可能性がある
この結果は、chat-style benchmarkの数値が、実際のcoding agent sessionで得られる削減率より大幅に高くなる理由を説明しています。
Coding workflowでは、tokenはエージェントの「発言」だけに使われるわけではありません。
以下のような情報にもtokenが使われます。
- Code
- Diff
- Tool call
- Log
- Context
「65%削減」という数字を正しく理解する
Cavemanはプロジェクトのbenchmarkにおいてoutput tokenを約65%削減できます。
しかし、これは次の意味ではありません。
「すべてのセッションでコストが65%削減される」
その理由はいくつかあります。
- Skillが主に短縮するのは自然言語によるoutput
- Codeやcommandは基本的に維持される
- Coding sessionではtool callやlogが大量のtokenを占める場合がある
- Input tokenやreasoning tokenは必ずしも減少しない
- Skill自体がinputに一定量のinstructionを追加する場合がある
- もともと回答が短いtaskでは削減効果が小さい
- セッションによっては総token数にほとんど効果がない場合もある
JetBrainsは、agentic coding taskにおける実際の削減率は、chat-style benchmarkで示される数値より大幅に低いと結論づけています。
そのため、JetBrainsの実験における約**8.5%**という数字は、より慎重な独立した参考値として捉えることができます。
また、別の分析では、多くのClaude Code sessionにおいてoutput tokenは総コストの一部に過ぎないことも指摘されています。
そのため、outputが大幅に減ったからといって、請求額も同じ割合で減るとは限りません。
Cavemanが向いているケース
Cavemanは、次のようなケースに適しています。
- Agentの回答が必要以上に長い
- 小さなtaskを連続して実行する
- Workflowに慣れていて、長い説明を必要としない
- Tool call間のnarrationを減らしたい
- 短く、明確で、すぐ実行できる回答が欲しい
- Contextやquotaの制限を頻繁に受ける
例えば、agentにファイルをチェックさせる場合、次の程度の回答だけで十分かもしれません。
Findings: - Missing auth check in update endpoint. - Duplicate request possible. - Add idempotency key.
ファイルを読み、ロジックを分析し、結論に至った過程を長く説明する必要はありません。
Cavemanを使わない方がよいケース
次のような状況では、高いレベルの簡潔化モードを使用しない方がよいでしょう。
- 新しいtechnologyを学んでいる
- 他の人にarchitectureを説明する必要がある
- 複雑なbugをdebugしている
- 完全なdecision logを残す必要がある
- Securityやcompliance reviewを行っている
- Agentにすべての前提条件やriskを説明してほしい
- Auditのために詳細な説明が必要
このようなケースでは、回答を短くすることで重要なcontextが失われる可能性があります。
Tokenの節約を、理解や結果の検証能力と引き換えにしてはいけません。
安全にCavemanを使う方法
Cavemanは、context optimizationそのものを完全に置き換えるものではなく、output styleを調整するためのツールとして考えるべきです。
実際の効果を評価するには、次のような方法が有効です。
- 同じtaskをCavemanあり／なしで実行する
- Input token、output token、total tokenを測定する
- Response timeを比較する
- 最終的なcodeや結果の品質を確認する
- 追加質問が必要になった回数を記録する
- 短いtaskと長いtaskを分けて評価する
- 1つの例ではなく、複数のsessionで評価する
Token Savingの計算式
Token saving = (Tokens without Caveman - Tokens with Caveman) ÷ Tokens without Caveman × 100
重要なのは、token数だけを測定しないことです。
以下についても評価する必要があります。
- Task完了までの時間
- 修正回数
- 発生したエラー数
- 読みやすさ
- Outputの品質
CavemanはToken問題のどの部分を解決するのか？
Cavemanが主に対象としているのは、Agentが出力する情報です。
しかし、tokenを総合的に最適化するためには、他にも多くの対策があります。
- 不要なcontextを削減する
- 不要なlogを減らす
- 関連するfileだけを読み込む
- 長すぎるconversation historyを再送しない
- Tool schemaを最適化する
- 大きなtaskを小さなstepに分割する
- Memoryを選択的に保存する
- すべてのデータをcontextに詰め込むのではなくretrievalを利用する
- Agentが関係のないdocumentを繰り返し読まないようにする
Cavemanのrepositoryでは、さらに次のような領域にも取り組んでいます。
- Input compression
- Log processing
- JSON
- Diff
- Search result
- Content typeに応じたcontext処理
Repositoryで公開されているbenchmarkの1つでは、特定のClaude Code設定において、Caveman proxyがprovider-reported input tokenを33.2%削減したと報告されています。
ただし、この結果は対象となる設定とbenchmarkに依存します。
まとめ
AIエージェントがtokenを消費するのは、推論を行うときだけではありません。
説明、繰り返し、contextの読み込み、logの処理、複数回のworkflowにおけるデータの受け渡しなどにもtokenが使われます。
Cavemanは、この問題の一部分にアプローチします。
Agentの発言を短くしながら、code、command、重要な技術情報を維持することが目的です。
プロジェクトのbenchmarkでは、技術系promptにおいて平均65%のoutput token削減が報告されています。一方、JetBrainsによる独立した検証では、実際のagentic coding taskにおける削減率は約**8.5%**でした。
したがって、最も適切な捉え方は次のとおりです。
CavemanはAI Agentをより簡潔で読みやすくし、場合によってはtoken効率を向上させることができます。しかし、その効果は単一のbenchmarkではなく、実際のworkflowで測定するべきです。
不要な説明を減らしたい場合にはCavemanが役立ちます。
一方、深い分析、audit、詳細な説明が必要なtaskでは、token節約よりも品質とtraceabilityを優先するべきです。