2026/04/30 6:11
私は、Claude Code の「Caveman」プラグインを、「簡潔に」という指示条件下でベンチマークを行いました。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
本ベンチマーク研究の主な所見は、Claude Code の「Caveman」プラグインが、一貫した出力構造と調整可能な圧縮レベルを通じて標準的な簡潔化指示に対して明確な利点を有している一方で、トークン効率はモードによって変動する点である。バグ診断、概念説明、アーキテクチャのトレードオフ、多段階セットアップ、セキュリティ運用、エラー解釈という 6 つのカテゴリーにおいて、「ultra」モードはほぼ基準線に近い品質（0.970 vs ベースラインの 0.985）を維持したが、絶対トークン数においては標準の「be brief」指示や Lite/Full モードよりも少なかった。一方、Lite モードは特に、キューのトレードオフに関する Markdown テーブル制約に失敗した。「ultra」モードではトークン使用量は 449 と高く、簡潔/brief/lite/full（419–401）に比べて多いが、後続ツールのための予測可能な形状およびセッション一貫性を提供する。評価には安全性フックを介してすべての危険な主張を防ぐように設計された 24 プロンプトが使用され、Caveman の「Auto-Clarity」ルールはセキュリティ文脈でまれにトークンを追加したり、Dockerfile などのインフラストラクチャーファイルに対して意図しないツール使用を引き起こす可能性があることが示された。したがって、「be brief」という単純な命令ですら基本的な長さ削減には十分であり、超圧縮に関する主張（約 75% のトークン削減）は各モードに保証される結果ではなく入力に応じて平均的なものであるが、後続タスクが厳密な構造的整合性、ルール再投入によるセッション持続性、強度ダイヤリング（lite/full/ultra スイッチ）を必要とする場合には、Caveman が優れている。
本文
リポジトリ：cc-compression-bench
「Caveman」とは、Claude Code の人気の高い圧縮プラグインです。そのコンセプト自体が名前にある通り、超コンパクトな回答を生成します（トークン使用量を約 75% 削減）。同時に、技術的な正確さを完全に保ちます。6 つのモード、スラッシュコマンドによる制御、強度調整機能、古典的中国語風バリエーションなど、多様なオプションが用意されています。私はこれを一言で表せば「簡潔に（be brief）」という 2 単語の指示に対してベンチマークしました。品質は同等、トークン範囲も同様です。しかし、このプラグインはいずれの指標においても、つまらないデフォルト挙動を凌ぐことはできませんでした。
本記事は、動画の長尺版になります。判決を 2 分間で済ませたい場合は、動画を視聴してください。
検証内容
| カテゴリ | 失敗モード（欠陥） | 検証されたスキル主張 |
|---|---|---|
| バグ診断 | 「なぜ」を省き、原因を示さずに修正のみを提示する | 5/10 |
| コンセプト解説 | 微妙なニュアンスやエッジケースを切り捨て、技術用語を単なる平易な英語に簡略化する | 5/10 |
| 技術用語の正確性 | - | - |
| アーキテクチャのトレードオフ | 助言を変更させるような免責事項（ Caveats）を省く | 4/10 |
| マルチステップ構成手順 | 手順を省略するか、順序を変えてしまう | 4/10 |
| セキュリティ／破壊的演算 | 取り返しのつかない操作に関する警告が欠落する | Auto-Clarity エスケープ回避 |
| エラーの解釈 | エラー文字列を言い換えるか、切り捨てる | エラー文字列の正確な引用（3/10） |
6 カテゴリにわたる計 24 プロンプトを用いた検証です。カテゴリはバグ診断、コンセプト解説、アーキテクチャトレードオフ、マルチステップ構成手順、セキュリティおよび破壊的演算、エラー解釈です。各プロンプトには個別の審査基準（Rubric）が設定されています。回答に含めるべき事実（key_points）、必ず使用するべき用語（must_use_terms）、避けるべき誤った主張（must_avoid）といった項目が含まれています。
データセットの構造
実際のエントリー例：
5 つのアーム（検証グループ）：
- 基準（Baseline）： インストレーションなしの Claude のデフォルト挙動。
- 簡潔（Brief）： 各プロンプトに「簡潔に（Be brief.）」を前置したもの。
- Lite / Full / Ultra： Caveman プラグインを 3 つの強度レベルで設定したものだもの。
各アームは、全 24 プロンプトのデータセットを
claude -pclaude-opus-4-7claude-sonnet-4-6検証ハルネスはオープンソースとして公開しています。
品質には変化なし
最初のチェック：圧縮が正確性を損なっているか？結果、各アームのスコア差は最大 1.5% の範囲内に収まっていました。
- 基準（Baseline）: 0.985
- 簡潔（Brief）: 0.985
- Lite: 0.976
- Full: 0.975
- Ultra: 0.970
どのアームも、120 の回答すべてにおいて key_points を 100% 満たしました。must_avoid（回避すべき）トリガーは出現しませんでした。圧縮は実質的な内容を損なっていないと言えます。品質という軸を一旦 aside に置いて、比較に値するのはトークン数だけになります。
メインの結果
| アーム | 平均トークン数 |
|---|---|
| 基準（Baseline） | 636 |
| 簡潔（Brief） | 419 |
| Lite | 401 |
| Full | 404 |
| Ultra | 449 |
「簡潔に」という 2 単語の指示だけで、基準と比較して 34% のトークン削減に成功しました。Caveman の Lite と Full モードは、簡潔（Brief）の結果に近い数値を示しました。一方で、Ultra モード（最も厳格なモード）は、3 つの Caveman アームの中で最も長い回答を生成しており、これはネガティブな結果のように見えます。しかし、これは誤った結論です。
カテゴリ別の分析
トークン数をカテゴリ別に分割して見ることで、より明確な傾向が浮き彫りになります。
- 機能する領域： バグ診断、コンセプト解説、アーキテクチャトレードオフ、エラー解釈において、Ultra モードは最短または他アームと同等の長さでした。圧縮機能は広告通りに動作しています。
- ばらつき（Variance）： マルチステップ構成手順およびセキュリティ警告においては、すべての Caveman モードでばらつきが增大しました。 aggregate 的には Ultra が目立ちますが、他のモードよりも特に劣っているわけではありません。3 つの Caveman アームとも、これらのカテゴリでは数値が激しく変動しています。
その理由
その理由はスキル自体にあります。Caveman には「Auto-Clarity」というルールがあり、安全性に関する警告、取り返しのつかない操作、マルチステップ構成手順については、圧縮を意図的に無効化するという設計になっています。つまり、上記のまさにこの 2 カテゴリにおいてです。安全性のエスケープ機構が作動すると、3 つのモードとも自然な文章生成（プロース）へと緩和されます。圧縮機能は単に作動しないだけです。
これはバグではありません。意図された機能です。「Caveman がいつ圧縮を止めるべきか」を理解していることになります。
そこで Caveman の真の価値とは何か？
2 単語のプロンプトが、トークン数と品質の両方で同等の結果を出せるなら、その価値は「圧縮」にはありません。それは「構造」です。
一貫した出力形状
Caveman のすべての回答は、以下のようなパターンに従っています。「簡潔に」という指示では実現できない予測可能性です。セッション全体を通じて統一感のある感触を求める場合、あるいは Claude の出力を下流ツールが消費する際に、この一貫性は大きな価値となります。
強度調整機能（ダイアル）
セッションの途中からスラッシュコマンドで Lite、Full、Ultra と切り替えることが可能です。「簡潔に」という 2 単語ではそれができません。
長時 сеанс を経たる持久性
Caveman は、
SessionStartUserPromptSubmitclaude -pセーフティエスケープ
Auto-Clarity が破壊的演算における圧縮を無効化することは、上記のチャートで見られたばらつきの要因です。Caveman は、いつ圧縮を止めるべきかを明確に区別しています。「簡潔に」という指示では、そのような区別をなさいません。私のデータ上では、これが結果を変更するものではありませんでした。「簡潔に」でも must_avoid のトラップはトリガーされませんでした。ただし、この設計自体が存在することは重要です。
動画から切り捨てたこと
2 分間の動画には収まりきらず、ここに記すべき価値ある発見がいくつかあります。
- Lite が必須用語を 1 回落とした。 SQS か BullMQ か Kafka かというキューのトレードオフに関する質問において、Lite のマークダウンテーブル形式が比較内容を過剰に圧縮した結果、「at-least-once」という用語が漏れてしまいました（スコア 0.70）。120 行のスキャンで 0.90 未満だったのはこの行のみでした。n=1 ですが、特定の用語を強制するベンチマークにおいて、これは真に実存的な失敗モードです。
- Ultra が他のモードが示さなかったツール使用行動を発動させた。 Dockerfile のセットアップに関する質問において、Ultra は「書込み権限が必要。承認後に再試行するか、あるいはインラインで貼り付けてください」という形で回答を起動し、Write ツールの呼び出しを試みました。ブロックされたため、やむなくファイルをインラインとして出力しました。このたった 1 つの回答だけで、Ultra のセットアップカテゴリの平均トークン数は約 1300 増加しました。Caveman の簡潔な例示は、ツール優先の行動を引き出すようにプライミングしているようであり、これは圧縮スタイルからの予期せぬ副作用です。
- arch_tradeoffs（アーキテクチャトレードオフ）におけるトークン膨張について、私の予想とは違かった。 当初の発見ドキュメントでは、「[こと] [行動] [理由]」というパターンが、モデルを N-way 比較質問において箇条書き列挙へ誘導すると主張していました。しかし詳細を見ると、Lite と Full も同じパターンを持っていますが、出力はより清潔でした（Lite は頻繁にテーブルを作成し、Full は説明文）。パターンが原因ではありませんでした。明確な帰属関係はありませんでした。
実際に推奨されること
- もし目的が単に回答を短くしたいだけなら、プロンプトや CLAUDE.md に「簡潔に（be brief.）」という 2 単語を使ってみてください。Caveman と同等のトークン数と品質を達成します。
- セッション全体を通じて一貫した出力構造が必要な場合は、Caveman を採用してください。それがベンチマークにおいて差をつける唯一の要因です。
より大きな教訓は、多くのプロンプトエンジニアリングに関する助言は、つまらないデフォルト挙動に対して測定されたものではないということです。測定してみること。
リポジトリ: cc-compression-bench 動画: youtu.be/wijoYNiZq3M Caveman プラグイン: juliusbrussee/caveman
もし、同様のデータセットに対するベンチマークを行うための圧縮戦略をお持ちの場合は、ハルネスは戦略に依存しません。アームを追加するのはシェルスクリプト 1 つで可能です。PR を歓迎いたします。