CLAUDE.mdからMarkdownの書式をすべて削ぎ落とせば、トークンを大幅に節約できる。
そんな仮説を信じている人は少なくないでしょう。
見出し、太字、空白行。
これらを取り除けば60〜70%のトークン削減になるという主張もあります。
理屈としては筋が通っている気がしますよね。
でも、この仮説には盲点がありました。
入力側しか見ていなかったのです。
肝心の出力、つまりコードの品質がどう変わるかは誰も検証していませんでした。
ある開発者がこの問題に正面から取り組みました。
Phase 1で540回、Phase 2で648回。合計1,188回のベンチマークを実施しています。
使用モデルはHaiku、Sonnet、Opus。
12種類のコーディングタスクに対して、10種類の異なるインストラクションプロファイルでテストを行いました。
結果は、多くの人の予想を裏切るものだったのです。
空のCLAUDE.mdが最高スコアを出した
最も衝撃的な発見がこれです。
CLAUDE.mdに何も書かない状態が、総合スコアで最も高い成績を記録しました。
さらに驚くべきことがあります。
「圧縮版」のインストラクションは「読みやすい通常版」よりも一貫してスコアが低かったのです。
つまり、トークン節約のために書式を削った結果、かえって性能が落ちていました。
皮肉な話です。
ただし、重要な前提があります。
テストに使われたのは汎用的なコーディングタスクでした。
そのため、プロジェクト固有のルールや制約を含むCLAUDE.mdでは、結果が異なる可能性も十分にあります。
インストラクションは天井ではなく床を上げる
インストラクションは天井ではなく床を上げる
そう考えるのは自然なことです。
しかし、ベンチマークが示した実態は少し違いました。
インストラクションは平均スコアを大きく引き上げるわけではありません。
その代わり、出力の一貫性を高めてくれます。
最高得点を伸ばすのではなく、最低得点を底上げする。
そういう役割なのです。
具体的な数字も出ています。
Opusモデルでワークフローチェックリストを使った場合、インストラクション順守タスクで平均+5.8ポイントのスコア向上が見られました。
加えて、最悪ケースのスコアが20ポイント以上も改善されています。
この知見は実務的に大きな意味を持ちます。
自動化パイプラインで「たまに変な出力が出る」問題に悩んでいるなら、CLAUDE.mdにワークフローチェックリストを追加してみてください。
改善が期待できるはずです。
トークン削減の「60〜70%」は幻想だった
圧縮版のCLAUDE.mdで60〜70%のトークン節約になるという主張。
これも検証されました。
結果はどうだったか。
実際にAPI呼び出し全体で見ると、削減効果は5〜13%にとどまっていたのです。
理由は単純です。
CLAUDE.mdは会話全体のトークンのうち、ごく小さな割合しか占めていません。
CLAUDE.md単体ではトークン数が減っても、システムプロンプトやユーザーメッセージ、コンテキスト全体を含めると、その削減幅は薄まります。
木を見て森を見ず、というやつですね。
実務で使えるインストラクション設計のヒント
ベンチマーク結果とコミュニティの知見を合わせると、いくつかの実践的な指針が見えてきます。
まず、汎用的なスタイルルールは効果が薄いという点。
「簡潔に書け」「コメントを多めに」といった指示です。
Claudeのデフォルト出力は既にそれなりに高品質なので、こうした指示では上乗せ効果がほとんど生まれません。
一方で、ワークフローや手順の指定は効果があります。
例えば以下のような指示です。
- テストを書く前にまずインターフェースを定義せよ
- 変更後は必ずリントを実行せよ
こうした具体的な手順が、出力のばらつきを抑えるアンカーとして機能します。
ツール呼び出しの設定も見逃せないポイントです。
自動化パイプラインでは tool_choice: “required” を指定してください。
デフォルトでは、Claudeがツールを呼ぶかどうかを自分で判断します。
そのため、テキストで返答してツール呼び出しをスキップすることがあるのです。
チャットでは問題になりにくいものの、自動化では致命的なバグになりかねません。
temperatureの設定も重要です。
データ抽出のような正確性が求められるタスクには0を。
コード生成のような創造性が必要なタスクには0.3程度を。
この使い分けで、信頼性が大きく変わってきます。
何を学ぶべきか
このベンチマーク結果が教えてくれる最大の教訓。
それは「入力の見た目」と「出力の品質」は別物だということです。
トークンを減らせばコストが下がる。
それは事実です。
しかし、トークン削減が出力品質にどう影響するかは、実際に計測しなければわかりません。
直感だけで判断すると、間違った方向に進む危険があります。
もうひとつ大切なのは、インストラクションの役割を正しく理解すること。
CLAUDE.mdはClaudeを「賢くする」ためのものではありません。
「安定させる」ためのものだと捉えるべきでしょう。
まとめ
CLAUDE.mdの書式を圧縮しても、API全体での節約効果は限定的です。
むしろ、コード品質が低下するリスクがあります。
空のCLAUDE.mdが最高スコアを出した事実は、汎用的な指示がモデルのデフォルト性能を超えられないことを示唆しています。
ただし、ワークフローチェックリストのような具体的な指示は別です。
特に自動化パイプラインにおいて、出力の一貫性を高めたい場面で力を発揮するでしょう。
大切なのは、思い込みではなく計測に基づいて判断すること。
あなたのプロジェクト固有のCLAUDE.mdが本当に機能しているかどうかは、自分の環境でテストして初めてわかるのです。
ベンチマークツールはオープンソースで公開されています。自分のセットアップで試してみる価値は、十分にあるはずです。
