caveman：Claude Code、Codex などの Agent から無駄な説明を減らす

JuliusBrussee/caveman は、Claude Code、Codex、Gemini、Cursor、Windsurf、Cline、Copilot などの Agent ツール向けの出力圧縮 skill / plugin です。目的は明確です。Agent の無駄な言葉を減らし、技術的な要点を残し、出力 token を減らすことです。

README のスローガンは “why use many token when few do trick” です。普通の技術文に言い換えると、丁寧な前置き、長い説明文、繰り返しの確認を削り、結論、原因、修正方法、必要なコードだけを残すということです。reasoning / thinking token は減らしませんし、モデルの能力を下げるものでもありません。主に最終的に見える回答の出力に作用します。

この種のツールは少し直感に反します。多くの人は「詳しい」ことを「信頼できる」と考えがちですが、プログラミング作業では、長すぎる回答が要点を薄めることも多いです。caveman の考え方は、技術判断は正確に、表現は短く、です。

caveman が解決する問題

Agent でコードを書くとき、問題はモデルが答えられないことではなく、答えが長すぎることです。

まず質問を繰り返す。
丁寧な前置きを入れる。
すでに分かっている背景を長く説明する。
最後にようやく必要なコマンド、ファイル、bug、修正案が出てくる。

こうした内容は出力 token を消費し、読む速度も落とします。長い会話では、低密度なテキストがコンテキストに増えていきます。

caveman は skill ルールで Agent に次を伝えます。

filler を削る。
技術的な実質を残す。
短い文と断片を使う。
コード、コマンド、パス、エラー文字列はそのまま保持する。
言語を切り替えるのではなく、現在の言語のまま表現を圧縮する。

つまり、Agent を愚かにするものではありません。同じ情報を短い文で渡すためのものです。

典型的な比較

README には React の再レンダリング例があります。通常の回答では、毎回の render で新しい object reference が作られ、React shallow comparison が prop の変化として扱うため再レンダリングが起きるので、useMemo を使うべきだ、と説明します。caveman では次のように圧縮されます。

1

New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`.

同じ結論ですが、前置きが少ない。すでに文脈を知っている開発者には、この密度のほうが使いやすいです。

また、言語を維持する点も強調されています。中国語で質問すれば中国語のまま圧縮し、ポルトガル語、スペイン語、フランス語でも同様です。圧縮するのは文体であって、英語に変換することではありません。コード、コマンド、エラー文字列は正確に保持されるべきです。

インストール方法

公式のインストーラーは 1 行で実行でき、利用可能な Agent を自動で探して対応する場所にインストールします。

macOS / Linux / WSL / Git Bash:

1

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

Windows PowerShell 5.1+:

1

irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

README によると、インストールは通常約 30 秒で、Node.js 18 以上が必要です。スクリプトはローカルにない Agent をスキップし、再実行しても安全です。

より詳しいインストール表は次を確認します。

1

INSTALL.md

起動と終了

インストール後は、通常セッション内で次を入力します。

1

/caveman

または直接こう伝えます。

1

talk like caveman

終了するときは次を使います。

1

normal mode

複数の圧縮レベルがあります。

1
2
3
4


/caveman lite
/caveman full
/caveman ultra
/caveman wenyan

おおまかには次の意味です。

lite：無駄な言葉と繰り返しを主に削る。
full：デフォルトの圧縮スタイル。
ultra：さらに電報風に短くする。
wenyan：文言文風にして中国語表現をさらに短くする。

実際には lite または full から始めるのがよいです。ultra は短いですが、複雑なタスクでは読みやすさが落ちる可能性があります。

何が使えるか

README にある主な機能は次のとおりです。

機能	用途
`/caveman [lite	full
`/caveman-commit`	Conventional Commit メッセージを生成し、subject を 50 文字以内にする
`/caveman-review`	`L42: bug: user null. Add guard.` のような 1 行 PR review コメントを生成
`/caveman-stats`	実セッションの token 使用量、累計節約、推定コストを集計
`/caveman-compress <file>`	`CLAUDE.md` やプロジェクトノートなどの記憶ファイルを圧縮し、コード、URL、パスを保持
`caveman-shrink`	MCP server の tool descriptions を圧縮する MCP middleware
`cavecrew-*`	圧縮スタイルの investigator / builder / reviewer subagents

特に /caveman-compress <file> は別に見る価値があります。Agent プロジェクトの長期コストは出力だけでなく、各セッション開始時に読み込まれる説明ファイル、好み、プロジェクトノートにもあります。それらを圧縮すると、毎回の会話で持ち込む低密度テキストを減らせます。

Benchmark の読み方

README では、Claude API の実 token 統計に基づき、10 個のプロンプトで平均 65% の出力削減、範囲は 22% から 87% とされています。例のタスクは次のとおりです。

React re-render bug の説明。
auth middleware token expiry の修正。
PostgreSQL connection pool の設定。
git rebase vs merge の説明。
PR security issues の review。
PostgreSQL race condition の debug。
React error boundary の実装。

README は eval harness が baseline、terse、skill の 3 群比較であるとも説明しています。つまり、単に冗長なデフォルト回答と比べているのではなく、Answer concisely. のような簡潔指示とも比べています。これは重要です。

ただし benchmark は慎重に読むべきです。出力が短いことは、すべてのタスクで良いとは限りません。単純な bug 特定、PR review、commit message、コマンド説明には向いています。一方で、要件整理、アーキテクチャ判断、チュートリアル、複雑な障害復盤では、より詳しい説明が必要なことがあります。

caveman-compress：長期コンテキストを圧縮する

README には claude-md-preferences.md、project-notes.md、claude-md-project.md、todo-list.md、mixed-with-code.md などの memory file 圧縮結果もあり、平均で約 46% の削減とされています。

これは単発の回答圧縮より意味がある場合があります。CLAUDE.md、プロジェクトルール、好みの説明は、毎回のセッションに入ることが多いからです。そこに冗長な表現が多いと、長期的な消費はかなり大きくなります。

ただし、ルールファイルを圧縮するときは慎重に扱います。

コード、URL、パス、コマンドは byte-for-byte で保持する。
安全制約、権限境界、テスト要件を削らない。
「必ずやる」手順を曖昧な提案に変えない。
圧縮後に人間が読み直し、意味が変わっていないか確認する。

チームプロジェクトでは、まず個人設定やノートから始め、重要な安全ポリシーをすぐに圧縮しないほうがよいです。

MCP middleware：caveman-shrink

caveman-shrink は、MCP server の tool descriptions を圧縮する MCP middleware です。MCP のツール説明はモデルに繰り返し注入されることが多いため、実用的です。ツールが多く、説明が長いと、入力 token が急速に膨らみます。

向いている場面：

MCP server が大量のツールを公開している。
ツール説明が重複している、または冗長。
Agent が完全な tool list を頻繁に読む。
元の MCP server を変更せずに説明 token を減らしたい。

向いていない場面：

ツール説明がすでに短い。
説明に厳密なパラメータ制約があり、圧縮できない。
圧縮後にモデルがツールを誤用しないか検証していない。

MCP ツール説明の圧縮は、通常の回答圧縮より注意が必要です。モデルがどのツールを選び、どう呼び出すかに影響するからです。

OpenClaw 連携

README では OpenClaw 連携も紹介されています。OpenClaw だけにインストールするには次を使います。

1

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash -s -- --only openclaw

Windows では次を使えます。

1

npx -y github:JuliusBrussee/caveman -- --only openclaw

インストール後は主に 2 つのことが行われます。

skill を次に配置する。

1

~/.openclaw/workspace/skills/caveman/SKILL.md

次のファイルに marker で囲まれた小さなブロックを追加する。

1

~/.openclaw/workspace/SOUL.md

これにより、OpenClaw が各ターンで簡潔な表現ルールを自動注入します。

カスタム workspace を使う場合：

1

OPENCLAW_WORKSPACE=/your/path

アンインストールは同じインストーラーに --uninstall を付けて実行します。skill フォルダを削除し、SOUL.md の marker block を消します。

向いている場面

caveman が特に向いているのは次のタスクです。

日常的なコード修正。
bug 特定。
commit message。
PR review。
短いコマンド説明。
すでに文脈が明確な共同作業セッション。
Agent の出力が冗長で、結論と修正だけが欲しい場面。

あまり向いていないのは次です。

チュートリアル作成。
初学者向けの説明。
プロダクトやアーキテクチャの長文ドキュメント。
完全な推論経路が必要な複雑な意思決定。
法務、医療、金融など、十分な条件整理が必要な高リスク助言。
問題自体がまだ曖昧で、多くの確認が必要なケース。

簡単に言うと、caveman は「背景は分かっているので、どこを直せばいいか教えて」に向いています。「初めて学ぶので、概念から説明して」には向いていません。

使い方のすすめ

試すなら、次の順番が安全です。

まず個人の Agent 環境に入れ、チームのデフォルトにはしない。
lite または full を数日使い、bug 修正、review、commit message の品質を見る。
複雑なタスクでは手動で normal mode に戻す。
その後で /caveman-compress <file> を試し、低リスクなノートファイルから始める。
MCP tool descriptions を圧縮する場合は、まず非本番環境でツール呼び出し精度を比較する。

理想は、すべての回答を極端に短くすることではありません。Agent が「短く、正確で、十分」と「文脈付きで説明する」を切り替えられることです。

まとめ

caveman は面白い小さなツールです。モデル能力そのものを強化するのではなく、表現密度を制御します。Claude Code、Codex、Gemini、Cursor などを毎日大量に使う人にとって、出力 token が少し減り、無駄な言葉が減り、結論が前に来るだけでも、作業フローは軽くなります。

ただし万能のデフォルトではありません。圧縮回答は実行型の開発タスクに向いていますが、教育、アーキテクチャ議論、高リスク判断には常に向くとは限りません。採用するなら、切り替え可能な作業モードとして扱うのがよいです。速さと密度が必要なときはオン、説明と文脈が必要なときはオフにする、という使い方です。