Claude Codeのトークン節約をPonytailの横着ラダーで実測してみた

はじめに

前回の記事でsuperpowersとECCを組んでハーネスを設計した話を書きましたが、あの記事で触れなかった課題が一つあります。トークン消費とコード生成量が多いことです。整備した直後は満足度が高かったのですが、しばらく使っていると出力トークンの量が気になるようになってきました。週の利用上限に早めに到達することも増えてきて、さすがに一度立ち止まって調べてみることにしました。

そんな時にXで話題になっていたのがPonytail(GitHub)という、AIコーディングエージェントに「書くコードを最小化する」規律を注入するツールです。この記事では、Ponytailを調べて、自分のハーネスに合う形で取り入れて、実際に自分のタスクで前後を測ってみた記録を書いていきます。得られるのは、バズった数字をそのまま信じるとどれくらいズレるかという話と、自分の実測でタスクの型によって効き方がはっきり割れたという結果です。

Ponytailとは

Ponytailは「怠惰なシニアエンジニア」を演じさせる規律で、中身は横着ラダー(Laziness Ladder)と呼ばれる優先順位です。公式サイトの原文はこうなっています。

1. Does this need to exist? Speculative need = skip it. (YAGNI) 2. Already in this codebase? Reuse the helper, util, or pattern that already lives here. 3. Does the standard library do it? Use it. 4. Native platform feature covers it? <input type="date"> over a picker lib. 5. Already-installed dependency solves it? Use it. Don't add a new one. 6. Can it be one line? One line. 7. Only then: the minimum code that works.

日本語にすると、①そもそも要るか(YAGNI、投機的な機能は切る) ②既存コードにあるものを再利用 ③標準ライブラリで足りないか ④プラットフォーム標準機能で足りないか ⑤すでに入っている依存で足りないか(新規追加しない) ⑥1行で書けないか ⑦ここまで潰して初めて最小実装、という7段階です。

Claude Code向けにはプラグインとして配布されていて、/ponytail lite|full|ultra|off で強度を切り替えられます。/ponytail-audit(リポジトリの肥大スキャン)や/ponytail-gain(効果比較表)といったサブコマンドも一式揃っていました。

バズ数字と独立検証が一桁違った

調べ始めてまず驚いたのが、数字の出どころによって効果が大きく違うことでした。

元のバズツイートは「コード量−80〜94%、コスト−47〜77%」という強烈な数字でした。公式サイトの中央値だと「コード−54%、コスト−20%」まで落ち着きます。そしてJetBrainsが80ペアのA/Bで独立検証した記事を見つけたのですが、そこでは「コスト−10.3%(p=0.004で有意)、コード−15.4%」でした。

効果は本物だけど、バズの数字は最も過激なベストケースだけを見せている、というのが率直な感想です。それとJetBrainsの記事でもう一つ気になったのが、「普通に入れると10セッション中0回しか自己発火しなかった」という記述でした。ルールを強制的に注入しないと、モデルは自分からラダーを使ってくれないようです。

導入方針: プラグインを丸ごと入れず、1文に蒸留する

自分のハーネスへの取り込み方として、2つの選択肢を比べました。

• (A) プラグインを入れて、ECCのhookで活性化を自分で担保する
• (B) 横着ラダーの考え方だけを1文に蒸留して、既存のCLAUDE.mdに焼き込む

選んだのは(B)です。理由は、自分のハーネス設計がもともと「棲み分けは列挙じゃなく原則1文で固定する」という思想でできていて、この案が一番素直に合ったからです。プラグイン一式を追加すると管理対象が増えますが、1文なら追加コストはほぼゼロ。JetBrainsが指摘していた自己発火0回問題も、CLAUDE.md常駐なら回避できます。

実際に足したのはこの1行です。

実装前に順に潰す: ①本当に要るか(YAGNI) ②既存コードで賄えないか ③標準ライブラリ/言語機能 ④プラットフォーム/FW機能 ⑤既存依存 ⑥1行で済むか — それでも要るなら最小実装だけ書く。

実測プロトコル

「効くと思う」で終わらせず、前後で実測することにしました。設計はこうです。

• 対象タスク: 自分のプロダクト(joifup)のタスクから2本選定。1本はusePinStatusフックへのリファクタ抽出(抽象度に判断の余地があるタイプ)、もう1本はvisible_propertiesの空配列の扱いを直すバグ修正(最小修正がほぼ一意に決まるタイプ)。この2つは意図的に性質を変えています。
• アーム: ラダーを外したbaselineと、ラダーを足したtreatment
• 反復: 各アーム2回、毎回まっさらなセッションで中央値を見る
• 初期状態: 同一コミットからgit worktreeを生やして、両アーム同じスタート地点から実装
• 指標: 出力トークン、コスト、生成コード量(git diff --stat)、品質(ビルド・テスト・レビューゲート通過)。トークンだけで勝敗をつけると「劣化して勝った」を見逃すので、必ず品質も一緒に見ています

worktreeとPRは8ラン分すべて保持したまま、baseline→treatmentの順で一気通貫で回しました。アーム間の交絡を避けるため、同日中に順番通り進めています。

結果: リファクタでは効いた、バグ修正では効かなかった

8ラン完走した結果がこちらです。

リファクタタスクの方は、baselineが327k〜369k、treatmentが199k〜218kと、両repとも範囲が重ならずクリーンに減っていました。一方バグ修正タスクは、treatmentの範囲が179k〜297kとばらつきが大きく、平均だけ見ると悪化してますが実質ノイズの中に埋もれている感じです。事前の予想通り「最小修正がほぼ一意に決まる小さいタスクには、そもそも削る余地がない」という結果でした。

品質面では、8ラン全てでレビュー・テストが通過していて、劣化は見られませんでした。あとで自分でコードレビューも回してみましたが、リファクタタスクの方は4パターンとも競合状態のガードロジックが1バイト単位で同じで、削れた分は本当に「タダ」でした。バグ修正タスクの方も4パターンともundefinedと空配列の両方のケースをちゃんと処理できていて、回帰は見つかりませんでした。

ハマったポイント

「活性化した」の確認方法を間違えかけた

ラダーがちゃんとモデルに届いているかを確認するのに、最初はセッションのログファイルをgrepしようとしました。でもこれが効きません。CLAUDE.mdの内容はシステムプロンプトとして注入される仕組みで、セッションのログには残らないからです。baselineでもtreatmentでも「ラダー原則」というキーワードが0件になって、一瞬「あれ、両方とも届いてない?」と焦りました。

正しい確認方法は、稼働中のセッションに直接「今CLAUDE.mdにラダーの原則は書かれてる?」と聞くことでした。地道ですが、これなら逐語で確認できます。「ログを見れば分かるはず」という思い込みが一番の落とし穴でした。

「効いた」の中身を聞いたら、思ったより頼りなかった

リファクタタスクの1回目の実測が終わった直後、43%のトークン削減という結果を見てちょっと興奮したのですが、念のため同じセッションに「ラダーのどの段階が実際に効いた?」と聞いてみました。返ってきたのは「①だけ、しかも事後的に」という答えでした。①〜⑥を順番に検討したわけではなく、「ラダーを見て決めたというより、決めた結論に手元の語彙を当てた感覚です」とのこと。

思っていたより地に足の着いた答えでした。ただこのおかげで、1回の実測結果に飛びつかず2回目を待つ判断ができました。結果的に2回目もほぼ同じ水準で減っていたので、少なくともノイズではないと確認できましたが、「ラダーの手順そのものが意思決定を駆動した」とまでは言い切れない、という留保付きの結果になりました。

所感

実測中に感じたことを3つ書いておきます。

同じハーネス・同じプロンプトでも、結構ブレる。 特にバグ修正タスクのtreatment側は179k〜297kまで開きがあって、非決定性の体感が数字にそのまま出た形でした。同じ入力を渡しても毎回同じ量のコードが出てくるわけではない、というのは頭では分かっていたつもりでしたが、実際に数字で見ると改めて驚きます。

API課金の生々しさ。 この検証の途中で週の使用上限を使い切ってしまい、API課金に切り替えて実測を続けたのですが、実装1タスクで$20〜30飛んで普通にビビりました。8ラン全体をもしAPIで回していたら合計$210超えです。これを見ると、$200のMax(20x)プランの方が結局安いんじゃないかという気がしてきます。まだ実際に切り替えてはいませんが、トークン節約施策を施しても週の上限が足りない週が続くようなら本気で検討しようと思っています。

ラダーの代わりにCLAUDE.mdへ開発原則そのものを書く、という手もあるのでは。 今回「①(YAGNI)だけが事後的に効いた」という自己申告を聞いて、いっそSOLID・KISS・YAGNI・DRYのような開発原則をCLAUDE.mdに直接明記してしまう方が近道なんじゃないか、という気づきがありました。ラダーは横着の手順を1文にしたものですが、原則をそのまま書く方が回りくどくない可能性があります。これはまだ試していないので、次にやってみたいことの一つです。

まとめ

• Ponytailの効果はバズの数字ほど劇的ではなく、自分の実測でも「リファクタ系は明確に効くが、最小修正が一意なバグ修正には効かない」というタスク型依存の結果になりました
• 横着ラダーは1文に蒸留してCLAUDE.mdに常駐させる形で導入コストをほぼゼロにでき、8ラン全てでレビュー・テストが通り品質劣化もありませんでした
• 「効いた」の自己申告は思ったより頼りなく、活性化の確認方法にも罠があったので、測る側の手順自体を疑ってかかる必要がありました

次は別の節約策として、小さいタスクをいちいちフルコースで回さない『軽量モード』を実装ワークフローに入れてみようと思っています。