powered by TechFeed
表示モード
ハウツー

Claude Codeのトークン消費を23%削減 — Postmanが19スキルを監査して見つけた3つの共通問題

7月22日、Postmanが「How DevRel saves thousands of tokens per Claude Code run」と題した記事を公開した。この記事では、Claude Codeプラグインの19スキルを体系的に監査し、トークン消費を合計13,300件削減した実測レポートについて詳しく紹介されている。

7月22日、Postmanが「How DevRel saves thousands of tokens per Claude Code run」と題した記事を公開した。この記事では、Claude Codeプラグインの19スキルを体系的に監査し、トークン消費を合計13,300件削減した実測レポートについて詳しく紹介されている。


「誰も測っていなかった」から始まった話

PostmanのDeveloper Relationsチームは、Claude Codeプラグイン上で日常業務を回している。ブログ記事の執筆、WordPressへのコンテンツ登録、Redditの競合調査、ニュースレター生成、カンファレンスCFP(登壇募集)の収集など、19のスキルがパイプラインを支えている。

プラグインは数ヶ月間、正常に動き続けていた。問題なし——ただしトークンコストを誰も測っていなかった。

ある日、体系的なベンチマークを実施したところ、3つの共通問題が全19スキルに存在することが判明した。最悪のスキルは1回の呼び出しで11,400トークンを消費しており、修正後の合計削減量は13,300トークン(全体比23%削減)に達した。


まず知るべき:トークンはどこに消えるか

Claude Codeプラグインのトークンコストは3層に分かれる。

Always-on cost(常時コスト):各スキルのYAML descriptionフィールドは、そのスキルが呼び出されるかどうかに関係なく、すべてのセッションのシステムプロンプトに読み込まれる。冗長な説明文は「全ユーザーが毎セッション払う税金」になる。

Per-trigger cost(起動時コスト):Claudeがスキルを必要と判断した時点で、SKILL.md本文の全体がコンテキストに読み込まれる。19KBのスキル本文なら約4,760トークン、使うのが全体の20%であっても全部払う。

Runtime cost(実行時コスト):ツール出力、非同期ポーリング、ワークフロー実行中の中間出力が積み上がる。


監査方法:19エージェントを並列実行

監査にはskillit(Anthropic公式のClaude Code向けスキル品質監査ツール)を使用した。元記事に記載のskillitリポジトリURLを参照されたい。各SKILL.mdを6次元、0〜2点のスケールで採点し、最大12点を算出する。

評価軸 内容
Description quality always-on説明文が簡潔・具体的か
Body size and focus 本文が肥大化していないか
Progressive disclosure 参照ファイルを必要時のみ読み込む設計か
Tool scoping allowed-toolsが明示されているか
Frontmatter validity フロントマターが正しく記述されているか
Prompting craft 指示が明確・命令形で曖昧さがないか

コマンド1本で19スキルを並列監査できる:

/skillit:skill-audit

結果は2分以内に返ってきた。


発見1:全19スキルにallowed-toolsが未設定

最も広範な問題がこれだった。ツールスコープを宣言するallowed-toolsフィールドが、全スキルで0点(未設定)だった。

allowed-toolsがないと、モデルはセッション内の全ツールにアクセスできる。WebSearchWriteだけ使えばよいスキルが、誤ってBashやMCPツールを呼び出す可能性がある。セキュリティ上の問題であり、予期しない動作の温床でもある。

監査を通じて3件の潜在的なパーミッションバグも発覚した。blog-copyeditorスキルはファイルへの書き込みを指示しているのにWrite権限の宣言がなく、blog-wordpress-stageBashなしでPythonスクリプトを実行しようとしていた。

修正自体はスキルごとに1行の変更で済む:

# cfp-hunter: 検索と書き込みのみ
allowed-tools: ["WebSearch", "Write"]

# blog-wordpress-stage: 複数ステップのステージングワークフロー
allowed-tools: ["Bash", "Read", "Write", "Edit"]

発見2:説明文の肥大化——毎セッション払うコスト

19スキルのdescriptionフィールド合計は最適化前で5,090文字。問題のあったスキルを抜粋すると:

スキル 最適化前(文字数) 問題
sentiment-apitools 637文字・7文 ツール名・使用推奨・注意書きなどボディに書くべき内容が混在
blog-wordpress-scheduler 342文字・3文 スケジューリングルール(火木優先ロジック)を説明文に記述
meetup-calendar 314文字・4文 3つの動作モードを個別の文で列挙

説明文を各スキル1〜2文(機能と出力アーティファクトのみ)に削り込んだ結果、合計文字数は4,071文字に減少。約255トークン/セッションの削減で、これはスキルを呼び出さないユーザーにも恩恵がある。


発見3(最大の問題):インラインPythonスクリプトが11,400トークンを食っていた

最もインパクトが大きかったのが、SKILL.md本文に完全なPythonスクリプトを直接埋め込んでいたケースだ。

meetup-calendarが最大の問題スキルだった:1,177行・45.6KB、Google Sheets JWT認証・グリッドデータ解析・Lumaイベント取得・曖昧一致・統計同期の5本のPythonスクリプトをすべてインラインで保持。推定消費トークン:11,400/回

**blog-wordpress-stage**は611行にわたり9つのPythonコードブロックを含んでいた。

修正:references/ディレクトリへの分離

解決策はシンプルで、実装詳細をreferences/サブディレクトリに移し、本文はオーケストレーション(手順の番号付きステップとファイルへのポインタ)だけにする。

修正前(luma-statsより):

### Step 2: Write and run the data-fetch script
Write the following Python script to /tmp/luma-stats.py, then run it.
[200行のPythonスクリプト]

修正後:

# references/luma-stats.py を /tmp/luma-stats.py に書き込んで実行する:
python3 /tmp/luma-stats.py [filter-arg]

スクリプトはreferences/luma-stats.pyに移動。Claudeはそのステップに到達したときだけ読み込む。luma-statsのスキル本文は346行から131行へ、62%削減

9スキルから15本のリファレンスファイルを抽出した結果、本文から合計1,566行が除去された。


全19スキルの数字

スキル グレード 最適化前(〜トークン) 最適化後(〜トークン) 削減
blog-wordpress-stage 6→11 6,050 3,400 44%
meetup-calendar 3→7 11,400 8,775 23%
blog-wordpress-scheduler 6→11 5,975 3,900 35%
luma-stats 7→11 2,810 1,165 59%
sentiment-apitools 5→9 6,200 4,930 20%
blog-write 8→10 8,175 7,305 11%
event-sponsorships 8→11 1,765 1,100 38%
cfp-hunter 6→10 1,210 650 46%

19スキル合計削減:13,300トークン(23%)
セッション常時削減:255トークン/セッション
平均グレード:6.5/12 → 9.5/12

金銭換算すると、元記事執筆時点で参照されているClaude Sonnetの標準入力レート($3/100万トークン)で、19スキル全体の1回の実行あたり約4セントの削減に相当する(※モデル名・料金は元記事公開時点のもの。最新の料金はAnthropic公式の料金ページを確認されたい)。1日複数回、複数ユーザーで実行し続ければ、塵も積もる水準になる。


まとめ:3つの修正パターン

  1. allowed-toolsを全スキルに宣言する——1行の変更だが、セキュリティと予期しないツール呼び出しの防止に直結する。
  2. descriptionフィールドを1〜2文に絞る——ここはすべてのセッションで払うコスト。ボディに書くべき内容を説明文に書かない。
  3. 実装詳細はreferences/に分離する——スクリプトや長い参照資料を本文に埋め込まず、必要なステップで初めて読み込む設計にする。

詳細はHow DevRel saves thousands of tokens per Claude Code runを参照していただきたい。