ハクソク

世界を動かす技術を、日本語で。

ユニバーサル Claude.md – Claudeの出力トークンをカットする

2026年3月31日原文(github.com)

概要

Claude の出力冗長性を約 63%削減 する CLAUDE.md ファイルについて解説 プロジェクト直下 に1ファイル配置するだけで、 コード変更不要 主な効果は 出力の簡素化 ・ 不要な定型文排除 高頻度自動化や大量出力 がある場面で効果大 入力トークン増加 と 出力トークン削減 のトレードオフ説明

Claude出力簡素化用CLAUDE.mdの概要

  • CLAUDE.md は、 Claude Code の出力冗長性・お世辞・不要装飾を削減する設定ファイル
  • プロジェクトルートに 1ファイル配置 するだけで即時有効、 コード修正不要
  • 出力トークンコスト 削減が主目的（入力トークン消費は増加）
  • ベンチマーク では平均 63%の出力削減 実績
  • モデル非依存 設計、Claude以外のモデル（llama.cpp, Mistral等）では未検証

主な問題点とCLAUDE.mdによる解決策

  • 冗長な冒頭挨拶 （例: "Sure!", "Great question!"）→ 即回答 開始
  • 不要な締めの挨拶 （例: "I hope this helps!"）→ 禁止
  • 質問の再掲 → 省略
  • 装飾文字やUnicode （emダッシュ、スマートクォート等）→ ASCII出力強制
  • AIとしての立場表明 や 不要な注意書き → 原則禁止
  • 未依頼の提案 や 過剰な抽象化 → リクエスト範囲内のみ
  • 誤情報への同意や曖昧な回答 → 「わからない」と明言
  • ユーザー修正指摘の反映 → セッション内で即反映
  • 冗長なファイル読み込み や スコープ逸脱 → 禁止

CLAUDE.mdが有効な場面・非推奨な場面

  • 有効な場面

    • 高頻度自動化パイプライン （例: レジュメボット・エージェントループ・コード生成）
    • 繰り返し構造化出力 が求められるケース
    • チームでの一貫した出力フォーマット 運用

  • 非推奨な場面

    • 単発・短文クエリ （毎回ファイル読込で入力トークン増加）
    • カジュアルな一時利用
    • 根本的な失敗（幻覚・設計逸脱） の修正（追加の制御が必要）
    • セッションごとに新規起動するパイプライン
    • 厳密な構造化出力 が必要な場合（APIのJSONモード等推奨）
    • 議論や多様な提案が重要な作業 （上書き指示で回避可能）

ベンチマーク結果とコスト削減例

  • 同一プロンプト での比較

    • async/await解説: 180→65語（64%削減）
    • コードレビュー: 120→30語（75%削減）
    • REST API解説: 110→55語（50%削減）
    • 幻覚訂正: 55→20語（64%削減）
    • 合計465→170語、約384トークン削減/4プロンプト

  • コスト試算例（Claude Sonnet）

    • 100プロンプト/日：約9,600トークン/日、約$0.86/月節約
    • 1,000プロンプト/日：約96,000トークン/日、約$8.64/月節約
    • 3プロジェクト合計：約288,000トークン/日、約$25.92/月節約

Before/After例

  • Without CLAUDE.md
    • 冗長な挨拶・提案・まとめ（120語）
  • With CLAUDE.md
    • バグ指摘と修正のみ （30語、75%削減）

CLAUDE.mdで防げる主な問題リスト

  • お世辞的な冒頭文
  • 無意味な締め文
  • 質問の再掲
  • Unicode装飾文字の混入
  • AIとしての立場表明
  • 不要な注意書き
  • 未依頼の追加提案
  • 過剰なコード抽象化
  • 不明点での曖昧な回答
  • ユーザー指摘の無視
  • 冗長なファイル読込
  • スコープ逸脱

運用・カスタマイズTips

  • 失敗事例ごとに具体的なルール追加 が有効（例: エラー時は即停止・トレースバック出力）
  • グローバル/プロジェクト/サブディレクトリ 単位でCLAUDE.mdを分割運用可能
    • グローバル: トーン・フォーマット
    • プロジェクト: 重要ファイルの編集制限
    • サブディレクトリ: タスク固有ルール

プロファイルと導入方法

  • プロファイル例

    • CLAUDE.md（汎用）
    • profiles/CLAUDE.coding.md（開発・コードレビュー向け）
    • profiles/CLAUDE.agents.md（自動化パイプライン向け）
    • profiles/CLAUDE.analysis.md（データ分析・レポート向け）

  • 導入手順

    • 汎用: curl -o CLAUDE.md https://raw.githubusercontent.com/drona23/claude-token-efficient/main/CLAUDE.md
    • プロファイル利用: git clone https://github.com/drona23/claude-token-efficient cp claude-token-efficient/profiles/CLAUDE.coding.md your-project/CLAUDE.md
    • 手動コピー: レポジトリからCLAUDE.md内容をプロジェクト直下に配置

上書きルールとコミュニティ貢献

  • ユーザー指示が最優先 （詳細説明や冗長出力を明示的に依頼した場合は従う）
  • 改善案・新ルール提案歓迎 （issueで挙動・プロンプト・修正案を報告）

参考・クレジット

  • Claudeコミュニティの実体験・要望 を元に構築
  • 主要なGitHub issue・技術ブログ・ドキュメントを参照
  • MITライセンス で自由利用・改変・配布可
  • Drona Gangarapu による開発、PRやプロファイル追加も歓迎

Hackerたちの意見

ここでのベンチマークは、エージェントループでコードが生成されるのではなく、単発の説明タスクに偏っているみたいだね。これってすごく重要な疑問を提起すると思う。ライブコードベースでプロジェクトを進めているとき、Claudeのデフォルトの冗長性、つまり大量のファイルを書いているときにその理由を詳しく説明することで、コンテキストサイズが大きくなってもセッションがより一貫性を持って集中できるのかな？ それによって、より良い、根拠のある決定を下すことで全体のトークンを節約できるのかな？ 元のリンクには「冗長なコンテキストは不要。セッション内で既に確立された情報を繰り返さないこと。」というルールがあるけど、私はもっとそういうのが欲しい。目標指向の準推論トークンを出して、視覚化して、使ってほしいんだ。それが「迷子にならない」ために役立つかもしれないから。出力トークンが高価な環境ではぜひこれを使ってほしいし、たくさんのデータを並行処理しているときにもね。でも、このアプローチがエージェントコーディングに効果的かどうかは、あまり良いデータがない気がする。

└

/handoffというスキルを書いたんだ。セッションが圧縮制限に近づいたり、役に立たなくなったときに、やったことや話したことを説明するマークダウンファイルを生成してコミットするんだ。圧縮の前にやるから/handoffって呼んでるよ。（「圧縮ってそういうものじゃないの？」そうだけど、それは消えちゃう。これは圧縮されたセッションの永久記録みたいなもの。）長期的な一貫性を保つのに役立つかは分からないけど、私のセッションは時々そのドキュメントを参照することがある。もっと言うと、これは「日報」タイプのシステムとして優れていて、マネージャー（や未来の自分）に何をしたか、なぜそうしたかを見せることができる。要するに、その長期的な一貫性を冗長なマークダウンファイルに凝縮した方が、あなたや未来のセッションが必要に応じて読めるかもしれない。多くのコンテキストは、試行錯誤や解決すべき問題を見つけることに関するもので、コンテキストウィンドウを埋めるためにそれを求めるよりも、もっと簡潔に文書化できるはずだ。 EDIT: 誰かがインストール手順を聞いたから、ここに投稿したよ： https://news.ycombinator.com/item?id=47581936

└

無駄な言葉を防ぐルールをすでに自分のシステムやプロジェクトのCLAUDE.mdに含めていない人がいるのが信じられない。冗長性に関しては…最近の研究によるとかなり有用みたいだよ。Gemini 3.1から引っ張ってきた「2つの主要なパラダイム：冗長な推論経路を生成する（自己整合性）と、冗長なモデルから出力を集約する（アンサンブル）」についての新しい論文が書かれている。

└

あと、推論時間のスケーリングもね。答えにたどり着くときにトークンをもっと生成することで、より良い答えが出せるんだ。余分なトークンが全て役立つわけじゃないけど、モデルがタスクパフォーマンスで強化学習されたときに最小の長さを最適化するのは逆効果みたい。

└

何をするか説明するな。ただやれ。 同じ理由でここに来た。正確にこのセクションの出力が間違ったことをしてるって教えてくれた回数を計算できないよ。だから中止してプロンプトを修正できたんだ。

ファイルは毎メッセージでコンテキストに読み込まれるから、出力が少ないやり取りではトークンが増えるだけだよ。 これってClaudeのパーソナライズ設定のためじゃないの？ グローバルにオンになってるし。私は簡潔さが好きだけど、それは文章を良くするためであって、トークンを節約するためじゃないはず。20%良い出力のために余分なトークンを犠牲にすることも厭わないし、簡潔さと質には相関関係があると思う。 他にも役立つことがあるかもしれないから、このRedditのコメントも見てみてね： https://www.reddit.com/r/vibecoding/s/UiOywQMOue > 重い使用でも[トークン制限]を下回るのに役立った2つのこと： > Headroom - あなたとClaudeの間のコンテキストを約34%圧縮するオープンソースのプロキシ。ローカルホストに置いて、動かすときは設定不要。 https://github.com/chopratejas/headroom > RTK - シェル出力（git、npm、ビルドログ）をコンテキストウィンドウに入る前に60-90%圧縮するRust CLIプロキシ。 > Headroomの上にスタックされる。 https://github.com/rtk-ai/rtk > MemStack - Claude Codeに持続的なメモリとプロジェクトコンテキストを与えて、毎回コードベースを再読み込みする無駄を省く。 > これがほとんどの人が気づかない最大のトークン消費だよ。 https://github.com/cwinvestments/memstack > これら3つは一緒にスタックできる。HeadroomがAPIトラフィックを圧縮し、RTKがCLI出力を圧縮し、MemStackが不要なファイル読み込みを防ぐ。まだ試してないけど、関連性があって面白そうだね。

ポール・キンランが数日前に面白いデータを含むブログ記事を公開したんだ [1]。出力トークンはトークン使用量のわずか4%しか占めていないって。かなり広範囲にわたる記事だから、関連する引用を紹介するね（強調は私のもの）： > OpenRouterのプログラミングカテゴリからの実データは、93.4%が入力トークン、2.5%が推論トークン、そしてわずか4.0%が出力トークンであることを示している。ほぼ全てが入力だね。[1]: https://aifoc.us/the-token-salary/

└

でも出力トークンは5〜10倍も高いから、結局は価格的にかなり変わってくるよね。

└

そうだけど、プロンプトキャッシングで入力コストが90%も下がるし、出力トークンはキャッシュされないから高くつく。これってどうなると思う？

└

自分の出力トークン比率は2%（高価なトークンで50%の節約、考えることも含めてるので、これがもっと多いこともある）。似たようなトーンと出力フォーマットのシステムプロンプト内容を持ってる。

こういう万能薬には警戒してる。主に、開発者がすぐに興味を失うだろうし、実際に機能するならCCに吸収されるだろうから。時間がかかるかもしれないけど、新しいものがMCP使用量を減らす、置き換える、圧縮するっていうたびにワークフローを数日ごとに変えるのは、かなりの混乱を招く。私は基本的なClaude Codeに満足してるし、今のところはほぼバニラなセットアップを運用するのがベストな選択だと思う。

└

同意。こういうプロジェクトは短期的な視点に見えることが多いよね。最近は、新しいものが流行を超えて続くと確信できるまでは、バニラの設定を保つ方向に傾いてる。AIラボに飲み込まれない限り、ニッチな用途だけのものにならないかどうかも考えちゃう。例えば、ワークツリーはまだ使ったことがないし、MCPもほとんど使ってない。でも、スキルは大好き。

Hacker Newsで議論の続きを見る