Caveman解説｜Claude Codeの出力トークンを最大87%圧縮するスキルと誇張しない実測条件

「なぜ多くのトークンで話す？　少ないトークンで十分」——このひと言のスキルがGitHubで87,768スターを集めた。

cavemanは、Claude CodeをはじめとするAIコーディングエージェントに1コマンドで導入できる出力トークン圧縮スキルだ。Claudeの返答から前置き・礼儀表現・埋め草を削り、「原始人語（Caveman speak）」に変換することで、出力トークンを平均65%削減する。削るのは装飾語だけ。コードブロックと技術的な中身は一切変えない。

ただし——この「65%」という数字は、条件を外して受け取ると簡単に誇張になる。cavemanが削るのは出力トークンだけで、スキル自体は毎ターン入力トークンを増やす。本記事は、仕組み・使い分け・競合比較を押さえつつ、この誇張しない実測条件を正面から扱う。派手なミームの裏で、どこまでが本当なのかを日本語で検証する。

この記事は、2026年4月に公開した初版解説を、★43,556→87,768への伸び・付属コマンドの拡充・誇張しない実測条件（README の “Honest number” 追記）を反映して全面刷新したものだ。

cavemanとは——「出力を削る」トークン削減スキルの正体

cavemanはJuliusBrussee氏が開発したAIコーディングエージェント向けスキルだ。ひとことで言えば「Claudeが返すテキストから余分な言葉を取り除くルールセット」だが、その効果は見た目のミームらしさに反して実用的だ。

AIコーディングエージェントのコストは、出力トークンの単価が入力より高いことが多い。同じ情報量でも長々と返すエージェントは、それだけで費用と待ち時間を膨らませる。cavemanはこの非対称性に着目し、最終的な言語化の段階だけを短くする。

削除するのは次の要素だ。

・「喜んでお手伝いします！」「もちろんです！」などの前置き
・just / really / basically / essentially などの埋め草（フィラー）
・説明に不要な冠詞・定型のヘッジ表現
・「何かご不明点があれば…」のような誘導的な締め
・繰り返しの確認・過剰な要約

一方、絶対に削らない要素がある。

・コードブロックの中身
・URL・ファイルパス・コマンド
・バージョン番号・日付
・技術的に意味のある固有名詞

README の設計哲学を借りれば、狙いは「同じ修正、言葉は少なく、脳はそのまま大きい」だ。cavemanは推論プロセスに介入しない。変えるのは、考え終わったあとの言い方だけである。

このスキルはClaude Skillsの仕組み——必要なときだけロードされる「コンテキストの単位」——の上に成り立っている。cavemanは、その仕組みを「毎ターンの言い方を上書きする常駐ルール」として使い倒した例だ。

内部で何が起きているのか

cavemanの実体は、複雑なプログラムではなくプロンプトとフックの組み合わせだ。README とリポジトリ構成から読み取れる動作は次の通り。

・プロンプト注入：Caveman構文のルールをエージェントのシステム文脈に差し込む
・ローカルフック：Claude Code / Codex / Gemini CLI ではセッション開始フックがモードを自動で有効化する
・セッションフラグ：現在の強度（full/ultra など）をディスク上のフラグとして保持する
・ログ解析：/caveman-stats はセッションログを読んでトークン使用量と累計の節約を集計する

主要言語はJavaScript（約69%）で、Python・シェルスクリプトが補助する。ランタイム要件はNode.js 18以上。ライセンスはMIT——READMEの言葉を借りれば「開けた平原のマンモスのように自由」だ。

Before/Afterで見るcaveman——同じ答え、言葉は72%減

抽象的な説明より、実際の応答を並べたほうが早い。公式READMEのBefore/Afterを見てみよう。

Reactコンポーネントの不要な再レンダリングについて質問した場合の応答を比較する。

通常のClaude（69トークン）

“The reason your React component is re-rendering is likely because you’re 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’d recommend using useMemo to memoize the object.”

caveman（19トークン）

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

削減率は72%。診断（新しい参照が毎回作られる）と修正方針（useMemoで包む）という中身は完全に一致している。減ったのは説明の骨格ではなく、その周りの装飾だけだ。

もうひとつ、認証ミドルウェアのデバッグの例を見る。

通常のClaude

“Sure! I’d be happy to help you with that. The issue you’re experiencing is most likely caused by your authentication middleware not properly validating the token expiry. Let me take a look and suggest a fix.”

caveman

“Bug in auth middleware. Token expiry check use < not <=. Fix:”

通常版が「お手伝いします」で始まって本質に触れないまま前置きを重ねるのに対し、caveman版は1行で「どこに」「何の」バグがあって「どう直す」かを言い切っている。読む側の認知コストも下がる。

これがcavemanの体験だ。派手な技術ではなく、「言い方の癖」をルールで矯正しているだけ。だからこそ、モデルのバージョンが変わっても壊れない。

「65%削減」の正しい読み方——誇張しない実測条件

ここが本記事の核心だ。cavemanの魅力は自己申告でなくClaude APIの実測トークン数で示されている点にある。だが、その「65%」は条件を外すと簡単に誇張になる。順を追って正確に読む。

まず実測ベンチマークを見る

READMEには10タスクの実測が載っている。「通常の冗長な応答」と「caveman適用後」を同じ質問でAPIに投げ、出力トークンを比較したものだ。

平均65%、範囲は22〜87%。削減率が低いタスク（22%、30%）は設計相談や抽象的な説明で、元々情報密度が高く削れる装飾語が少ない。逆に、長文になりがちなエラー説明・セットアップ手順では80%超が出ている。「長く喋りがちな場面ほどよく効く」のが素直な読み方だ。

3つの但し書き——ここを外すと誇張になる

READMEには “Honest number”（正直な数字）としてはっきり但し書きが添えられている。要点は3つ。

言い換えると、セッション全体（入力＋出力）の節約率は、この65%より必ず小さい。cavemanは「出力トークンを平均65%削る」ツールであって、「APIコストを65%削る」ツールではない。READMEがこの区別を自分から書いているのは誠実だが、紹介記事やSNSでは②③が落ちて「65%コスト削減」と一人歩きしやすい。本記事はその落とし穴を明示しておく。

「Cavemanは口を小さくするが、脳は小さくしない」——推論の質は変えず、言語化だけを短くする。この一点を理解すれば、どんなワークロードで効くか／効かないかを自分で判断できる。

自分のワークロードで再現する

cavemanの benchmarks/ にはハーネスが同梱されており、自分で再現できる。最小構成なら、通常プロンプトとcavemanプロンプトを同じ質問で投げて出力トークンを比べるだけだ。

import anthropic

client = anthropic.Anthropic()
QUESTION = "Explain why a React component re-renders and how to fix it"

# 通常モード
normal = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": QUESTION}],
)

# caveman ルールを system に付与
caveman = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=(
        "Terse like caveman. Technical substance exact. Only fluff die. "
        "Drop: articles, filler (just/really/basically), pleasantries, hedging. "
        "Fragments OK. Short synonyms. Code unchanged."
    ),
    messages=[{"role": "user", "content": QUESTION}],
)

no = normal.usage.output_tokens
cv = caveman.usage.output_tokens
print(f"normal={no}  caveman={cv}  output_reduction={(1 - cv / no) * 100:.0f}%")

# 但し書き②を可視化：入力側の増加も見る
print(f"input: normal={normal.usage.input_tokens}  caveman={caveman.usage.input_tokens}")

ここで出力の削減率だけでなく入力トークンの差も必ず見るのが、誇張しない検証のコツだ。出力が60%減っても、入力が1.5k増えていれば、短い応答では総コストが相殺されることがある。数字は自分のタスク分布で測るのが唯一の正解だ。

セッション単位で試算する——出力65%は総コスト何%か

出力トークンの削減率と、リクエスト全体（入力＋出力）のコスト削減率は別物だ。ここを混同しないために、単純な試算をしておく。前提は次の通り（数字は説明用の例で、実際は自分のモデル・料金で計算する）。

・入力単価と出力単価が仮に 1:5（出力のほうが高い料金体系を想定）
・1リクエストあたり、通常は入力500トークン・出力1,214トークン（ベンチマーク平均）
・caveman適用後は、出力が294トークンに減るが、入力はスキル注入で+1,200されて1,700トークンになる

コストを「入力×1＋出力×5」の重み付き合計で見ると、通常は 500 + 1214×5 = 6,570、caveman適用後は 1,700 + 294×5 = 3,170。総コストの削減は約52%で、出力だけ見た65%より小さい。これがベンチマークの長文タスク（元々出力が多い）でのイメージだ。

逆に、元の出力が短いタスク——たとえば通常が入力500・出力200トークンの一問一答——では、通常 500 + 200×5 = 1,500、caveman適用後は出力を仮に120まで削れても 1,700 + 120×5 = 2,300 となり、入力の増加分が勝って総コストが増える。READMEが警告する net-negative はこの状況だ。

なお、この入力増加は caveman-compress でメモリファイル側を削れば一部相殺できる。cavemanは出力を、compressは入力を攻めるので、両輪で回すと総コストのバランスが取りやすい。これは小手先のプロンプトエンジニアリングというより、「どの層のトークンをどれだけ使っているか」を把握したうえでの設計判断だ。

4つの強度モードと付属コマンド

cavemanには4段階の強度がある。用途に応じてセッション内で切り替える。

同じ「Reactの再レンダリング」への応答が、モードでどう変わるかを見る。

lite

“Your component re-renders because you create a new object reference each render. Inline object props fail shallow comparison every time. Wrap it in useMemo.”

full

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

ultra

“Inline obj prop → new ref → re-render. useMemo.”

文言文

“物出新參照，致重繪。useMemo Wrap之。”

選んだモードはセッション終了か明示的な変更（normal mode で解除）まで維持される。ビジネス文書のように読みやすさが要る場面ではlite、技術的な議論を高速に回したいときはfull/ultra、というのが実務的な使い分けだ。文言文はロマンだが、日本語話者の多くには読みにくいので、読み返さない中間メモ向きと割り切るとよい。

日本語出力での挙動と注意

cavemanのルールは英語で書かれているが、日本語の出力にも適用される。具体的には、次のような「日本語の装飾」が削られる。

・「〜でございます」「〜させていただきます」などの過剰敬語
・「まず最初に」「ということで」などのつなぎのフィラー
・「なるほど、それは良い質問ですね」といった前置き

技術的な議論では効率的だが、日本語特有の丁寧さまで削れてしまうため、社外向けの文章やレビューコメントをそのまま貼る用途ではliteモードのほうが無難だ。チームで /caveman-review の1行フォーマット（L42: 🔴 …）を使うなら、事前に記法を共有しておかないと「素っ気ない」と受け取られかねない。一人開発や個人プロジェクトなら即日で恩恵が出る。

なお、長時間セッションでは、まれにモードが通常に戻る「フィラードリフト」が報告されている。READMEは “ACTIVE EVERY RESPONSE”（毎応答で有効）という明示ルールで対策しているが、ultraで長く回すときは折を見て /caveman full などで貼り直すと安定する。

付属コマンド——出力圧縮の外側

cavemanは単一のモード切り替えにとどまらない。実務で効く付属コマンドが揃っている。

・/caveman-commit——Conventional Commits形式で件名50文字以内の簡潔なコミットメッセージを生成。WhatではなくWhyを書く
・/caveman-review——PRコメントを1行に圧縮。L42: 🔴 bug: user null. Add guard. の形式で場所・重要度・修正方針を一息で伝える
・/caveman-stats——セッションのトークン使用量と累計節約を集計。但し書き②③を自分の実データで確認する場所
・/caveman-compress <file>——CLAUDE.mdなどメモリファイルをCaveman構文に書き換え、入力トークンを削る（公式実測で約46%減）

/caveman-compress は cavemanのモード切り替えと役割が対になっている点が重要だ。

さらに新しめの機能として、MCPツールの説明文を圧縮する caveman-shrink（MCPミドルウェア）や、役割分担したサブエージェント群 cavecrew-*（investigator / builder / reviewer）も追加されている。エコシステムは「出力圧縮」から「エージェント全体のトークン最適化」へ広がりつつある。

/caveman-compress を使うと、圧縮後の CLAUDE.md と人間可読のバックアップ CLAUDE.original.md が生成される。日々の編集は後者で行い、Claudeが読むのは前者、という運用になる。

# メモリファイルを圧縮（バックアップ自動生成）
/caveman-compress CLAUDE.md

# 生成物:
#   CLAUDE.md          … 圧縮済み（Claudeが毎回読む）
#   CLAUDE.original.md … 人間可読のバックアップ（自分が編集する）

インストール——Claude Codeから30以上のエージェントまで

cavemanは主要なAIコーディングエージェントに横断対応している。最も確実なのは公式インストーラだ。

1コマンドインストール（推奨）

# macOS / Linux / WSL / Git Bash（Node.js 18以上が必要）
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

# Windows PowerShell 5.1+
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

インストーラは環境にあるエージェントを自動検出し、スキルとフックを配置する。Claude Code / Codex / Gemini CLI ではセッション開始フックが設定され、次の起動から自動でCavemanモードが有効になる。

安全確認の注意：curl … | bash 形式のインストールは、実行前に必ずスクリプトの中身を読む習慣をつけたい。cavemanはMITの公開リポジトリなので、install.sh をブラウザで開いて内容を確認してから実行するのが安全だ。組織のポリシーによっては、パイプ実行を避けて手元にダウンロードしてから実行する方針が望ましい。

Claude Codeのプラグイン経由

Claude Codeでは、プラグインマーケットプレイス経由でも導入できる。

claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman

プラグインインストールは、スキル本体の配置・SessionStart フックの設定・ステータスライン（[CAVEMAN] バッジ）の提案までを行う。既存のステータスライン設定があればそれを壊さない。

常時有効にする最小の方法

フックを使わないエージェントや、プロジェクト単位で常時オンにしたい場合は、ルールファイル（CLAUDE.md など）に次のスニペットを置くだけでも動く。

# コミュニケーションスタイル（CLAUDE.md に追記）
caveman mode. no filler. fragments ok. code exact.
drop: pleasantries, hedging, articles, "I'd be happy to".
pattern: [thing] [problem] [fix]. short. direct.
off: "stop caveman" / "normal mode".

これはインストール不要で、プロジェクトにコミットすればチーム全体へ展開できる。Claude Codeのベストプラクティスでも、繰り返すワークフローの規範はメモリファイルに固定するのが定石とされている。アンインストールはインストーラの案内、またはプラグインなら claude plugin uninstall で戻せる。

caveman vs ponytail vs superpowers——同じ「スキル」でも攻める層が違う

2026年のClaude Codeエコシステムでは、cavemanと並んで「トークンを減らすスキル」「開発をよくするスキル」が相次いでバズった。混同されがちだが、攻めている層がまったく違う。ここを整理すると、cavemanを何と併用すべきかが見える。

それぞれ何を減らす／整えるのか

・caveman（出力を削る）：Claudeの返答から装飾語を除き、出力トークンを減らす。効果は「話す場面」に比例する
・ponytail（コードを削る）：「一番怠けたシニア開発者」のように、書く前にYAGNIのはしごを上る——「そもそも要る？→既にある？→標準ライブラリで足りる？」。書くコード自体を減らすことでトークンと保守負債の両方を圧縮する
・superpowers（工程を整える）：トークンには直接触れない。ブレスト・仕様確定・TDD・コードレビュー・ブランチ完了という開発プロセスそのものを規律化する方法論スキル群だ

同じ「Claude Codeスキル」でも、cavemanとponytailはトークン削減系、superpowersは方法論系。前者2つは出力とコードという別の蛇口を締めるので併用でき、superpowersはその上で進め方を整える。役割が重ならないから、3つ同時に入れても衝突しない。

トークンコスト削減の4層で位置づける

AIエージェントのトークン最適化という文脈では、コスト削減は大きく4層に分けられる。cavemanはこのうち「出力層」の即効薬だ。

実務での組み合わせの勘所はこうだ。説明・レビュー・デバッグ相談が多い使い方ならcaveman、機能実装が多いならponytailが効きやすい。両方多いなら両方入れて、Claude API料金のダッシュボードで実測しながらチューニングする。ここでも「自分のタスク分布で測る」が原則だ。

導入の順番に迷うなら、次のように考えるとよい。まずcavemanを単体で1〜2週間回し、/caveman-stats で自分のセッションの入出力比率と実際の節約を把握する。ここで「出力が支配的で効いている」と確認できたら、入力側を締める caveman-compress を足す。コードの書きすぎが気になってきたら、層の違うponytailを追加する。superpowersのような方法論スキルは、トークン最適化とは独立に「進め方を直したい」と感じたタイミングで入れればよい。一度に全部入れると、どれが効いているのか切り分けられなくなる——これはツール導入全般に言える鉄則だ。

cavemanエコシステムの広がり

cavemanは単独ツールではなく、同じ開発者による一連のプロジェクトの中核だ。設計思想は「推測しない・忘れない・喋りすぎない」で一貫している。

出力（caveman）・記憶（cavemem）・ビルド（cavekit）・モデル（cavegemma）と、トークン最適化を別の層でそれぞれ攻める布陣になっている。まず試すなら、導入コストが最も低いcaveman単体から始めるのが素直だ。

まとめ——「話す量」を削る一点特化ツールとして使う

cavemanは「削る」ことで価値を出すスキルだ。前置き・礼儀・埋め草を取り除き、技術情報だけを残す。1コマンドで30以上のエージェントに入り、元に戻すのも一言。試すコストが限りなく低い。

ただし、その効果は条件付きで理解してこそ活きる。

・出力トークンを平均65%削減（10タスク・範囲22〜87%、Claude API実測）
・削るのは出力だけ。入力・推論トークンは対象外で、スキル自体が毎ターン+1〜1.5kの入力を足す
・セッション全体の節約は65%より小さく、元々短い応答中心のワークロードでは差し引きマイナスになりうる
・長い説明・セットアップ・デバッグ相談ほどよく効き、短い一問一答では効きにくい
・出力を削るcaveman、コードを削るponytail、工程を整えるsuperpowersは層が違うので併用できる

出力の言葉を減らすcavemanは、トークン最適化の最初の一手として、導入コストと効果のバランスが最も良い選択肢のひとつだ。ただし魔法ではない——「口を小さくする道具であって、脳を小さくする道具ではない」ことを忘れなければ、期待値を外さずに使える。

参照ソース

• JuliusBrussee/caveman — GitHub公式リポジトリ（README・ベンチマーク・Honest number）
• caveman — releases（バージョン・変更履歴）
• DietrichGebert/ponytail — 比較対象（コード量を減らすスキル）
• obra/superpowers — 比較対象（開発方法論スキル群）
• JuliusBrussee/cavemem — クロスセッションのメモリ圧縮
• JuliusBrussee/cavekit — スペック駆動ビルドループ