caveman：洞窟人の話し方で削るコーディングエージェントのトークン費用

背景と課題の所在

コーディングエージェントは、トークン単位で課金されます。トークンには費用がかかり、エージェントは二つの方向で支払っています。一つはモデルが書く応答、もう一つはモデルが読む道具の出力です。道具の出力とは、ログ、テスト結果、JSON、diff、検索結果などを指します。両方が請求書に積み上がります。 caveman は、この二つの方向を同時に狙うプロジェクトです。GitHub 上の JuliusBrussee が2026年4月に冗談として始め、READMEによれば Hacker News で1位になりました。リポジトリのスターは現在10万9千件を超えています。ただし人気は手法の有効性を示しません。示すのは測定です。本記事では、その測定を扱います。

課題は単純です。多くのエージェントは、志望動機書のように書き、消防ホースのように読みます。書く側は文体の問題です。前置き、言い換え、丁寧すぎる定型句が付きます。読む側は配管の問題です。道具の出力は生のままで冗長であり、目の前の質問に不要な情報が大半を占めます。 READMEの見出しは「トークンを65%削減する」と主張しています。この数字は宣伝文句から来ています。実際に存在する測定は、より狭い条件のものです。その一部はプロジェクト自身の手によるものです。本記事では、両者を分けて整理します。

コアアーキテクチャと技術原理

caveman は三つの構成要素からなり、それぞれ単独で導入できます。 一つ目は skill です。エージェントに、洞窟人の話し方で短く答えるよう指示する規則ファイルです。READMEによれば、Claude Code、Codex、Gemini CLI、Cursor、Windsurf を含む30以上のエージェントで動作します。導入コマンドは `npx skills add JuliusBrussee/caveman -g` です。skill が変えるのはモデル自身の文章だけで、道具の出力には触れません。

二つ目は proxy です。利用者のマシン上で動き、エージェントと提供事業者の間に置かれます。リクエストを送る前に、ログ、JSON、diff、テスト出力といった道具の結果を圧縮します。原本はバイト単位でローカルの SQLite に保存され、復元用の識別子が付きます。モデルが全文を必要とすれば、`caveman_retrieve` ツールを呼び出して取り出します。 三つ目は middleware です。自前のエージェントを作る開発者向けです。LangChain、Vercel AI SDK、OpenAI や Anthropic のクライアントで、一回の呼び出しを包みます。大きな道具の結果は、モデルが見る前に短い写しに置き換えられます。会話の履歴には、原本のバイトがすべて残ります。 三つに共通する原則は、圧縮が可逆でなければならないということです。短い文章は一つの見え方にすぎず、原本は識別子を通じていつでも開けます。これは重要です。ヒューリスティックが選んだ不可逆な要約は、モデルに必要だった一行を黙って消すことがあります。可逆にすれば、その沈黙の誤りは目に見える追加の呼び出しに変わります。

実用性と検証結果

数字は三つの系統に分かれます。測定対象が異なるため、合算してはいけません。 一つ目は JetBrains の検証です。実際のコーディング課題86件で、Claude Code 2.1.200 と skill のみを使い、対応のある A/B テストを行いました。proxy は含まれていません。出力トークンは8.5%減り、コストは約10%下がりました。結果が分かれた18件に対する符号検定の p 値は0.82です。課題ごとの平均スコアは基準の0.326から0.311へ変わり、差は0.015です。このデータでは品質の変化は測定されませんでしたが、削減幅は小さいと言えます。 二つ目は Adobe Research の CAVEWOMAN 論文です。READMEが引用しています。論文によれば、出力側の洞窟人風の文体は、モデルごとに実コストを1.4倍から2.4倍に下げ、最良の場合は3倍に達します。この数字は論文のものであり、本記事では再現していません。 三つ目はプロジェクト自身のベンチマークです。Claude Code で54回の実行を行い、proxy を使うと六つの作業群で入力トークンが33.2%減りました。回答の検査18件はすべて合格しています。95%信頼区間は14.6%から48.5%です。ただし README は、生のハーネス成果物がリポジトリに含まれていないと明記しています。したがって、公開された再現ではなく、固定された報告として扱うべきです。作者自身が実施したことも、読み手は考慮する必要があります。

さらに二点あります。第一はテレメトリです。コマンドラインツールは、ランダムなインストールIDとIPアドレスを含む利用統計を既定で送信します。`caveman telemetry off` で停止できます。データ規程のある組織は、導入前に確認してください。第二は Headroom と RTK との比較です。READMEは JetBrains のデータを引用し、低い推論強度では RTK が作業ごとの中央値コストを7.6%押し上げると述べています。これは競合についての主張であり、第三者の測定を引いたものです。 適しているのは、応答が定型的で道具の出力が大きい、大量のエージェント作業です。ログの仕分け、テストのデバッグ、リポジトリの探索が該当します。一方、表現に法務、安全、製品上の重みがある場面には向きません。READMEもそれを認めています。セキュリティ警告や確認の質問は、完全な文で返ってきます。短い応答が必ず安全だと考えてはいけません。 現実的な進め方は、導入前に測ることです。`caveman trial` コマンドは、caveman を使う場合と使わない場合の両方で一セッションを実行し、差を示します。他人のコードベースで得た割合は、あなたの作業についてほとんど語りません。

業界への影響と今後の展望

caveman が変えたのは、技術そのものより議論の焦点です。課金の仕組みを可視化しました。多くのチームは出力トークンを見ますが、それは自分たちが読む文章だからです。このプロジェクトは、読む側のほうが請求書の大きな部分を占めることが多く、proxy がそこを狙うのだと示しました。

冗談が真剣な工学的発想を運べることも示しました。文体は遊び心がありますが、その下の仕組みは、モデルと道具の間に置かれた可逆な圧縮層です。この仕組みは caveman 固有のものではありません。Headroom や RTK のような競合も、近い方向を探っています。 実務者への教訓は三つです。第一に、割合を信じる前に自分の作業量を測ること。第二に、圧縮を可逆に保つこと。元に戻せない切り捨ては、モデルの判断を恒久的な損失に変えます。第三に、コストと一緒に品質を追うこと。回答を悪くする節約は、節約とは言えません。 未解決の問いは、読む側の圧縮が、より長いセッション、より多くの道具、より大きなコードベースでも成り立つかどうかです。公開されている根拠は、短いコーディング課題と、プロジェクト自身のベンチマークに限られます。この問いにはまだ答えが出ていません。proxy の結果を第三者が再現することが、次に最も有益な一歩です。バージョン3.0.0以降、リポジトリ全体に適用される Apache-2.0 ライセンスにより、その再現は容易に行えます。