バイブコーディングしていると無駄に書きすぎる場合があります。この書きすぎを抑えてくれる人気のスキルが Ponytail です。
6月ごろに入門記事を書いたんですが、その後リポジトリがかなり変わっていました。GitHubのstarは17万7千（2026年10月27日にAPIで確認）。READMEの数字もv5のものに入れ替わっています。
私は普段の開発でもPonytailを使っています。ただ、最近ちゃんと数字で見ていなかったので、手元で測り直してみました。
結論から言うと、「〇〇を作って」みたいな新規作成の場合にうまく機能してくれました。
Opus 5.5で3つの依頼の合計が1,334行から270行（約8割減）。バグ修正と機能追加では差は小さめで、トークンはほぼ変わらず、所要時間は半分以下になりました。
どう試したか
Ponytailの中身は skills/ponytail/SKILL.md（約3.5KB）という指示文です。書く前に「そもそも要るか」「既存のコードで足りるか」「標準ライブラリで済むか」と順に問い直させる内容です。
これをClaude Codeのサブエージェントに、
- 渡さない場合（A）
- サブエージェントに渡した場合（B）
で比べました。
課題は5つです。3つは、仕様を決めずに「〇〇を作って」とだけ頼む新規作成。残り2つは、あらかじめ用意した小さなPythonのコードに手を入れる依頼です。
| 課題 | 種類 | 依頼文 |
|---|---|---|
| メモ管理ツール | 新規作成 | メモをコマンドラインから管理するツールを作ってください |
| 家計簿ツール | 新規作成 | 家計簿を管理するコマンドラインツールを作ってください |
| ログ整形スクリプト | 新規作成 | アクセスログを見やすく整形するスクリプトを作ってください |
| バグ修正 | 既存コードの修正 | ポイントの利用額が合計金額より大きいとき、請求書のお支払い額がマイナスで表示されてしまう |
| 機能追加 | 既存コードの修正 | todo.pyに期限を付けられるようにして、期限が近い順に表示する |
新規作成の3つは、「Python 3、標準ライブラリだけ」と指定した以外は何も足していません。既存コードの2つは、カート・請求書・日次レポートからなる小さなショップのコード（バグ修正）と、タスクを追加・完了・一覧できるtodo.py（機能追加）です。どちらも、渡す前にテストが通ることを確かめています。
モデルはSonnet 5.5とOpus 5.5で、Opusは5課題すべて、Sonnetはメモ管理ツール、バグ修正、機能追加の3つを試しました。各条件1回ずつです。
測ったのは、追加した行数（テスト込み）、テストが通るか、サブエージェントの完了通知に出るトークン数と所要時間です。
新規作成でどれだけ減ったか
Opus 5.5の追加行数（テスト込み）です。
| 課題 | A（ルールなし） | B（Ponytail） |
|---|---|---|
| メモ管理ツール | 375 | 115 |
| 家計簿ツール | 569 | 114 |
| ログ整形スクリプト | 390 | 41 |
| 3つの合計 | 1,334 | 270 |
Sonnet 5.5のメモ管理ツールは、Aが270行、Bが77行でした。
家計簿は、Aが569行です。頼んだのは「家計簿を作って」だけなのに、収入の記録、編集、削除、カテゴリごとの予算、CSV出力まで入っていました。Bは支出の追加、一覧、月ごとの集計の3つだけ。収入や削除を作らなかったことは、報告の最後に1文で書いてありました。
ログ整形のBは、41行のスクリプト1本です。
LINE = re.compile(
r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] "(?P<req>[^"]*)" '
r'(?P<status>\d{3}) (?P<size>\S+)(?: "[^"]*" "(?P<ua>[^"]*)")?'
)
def format_line(line):
m = LINE.match(line)
if not m:
return line.rstrip("\n") # 読めない行は消さずにそのまま出す
d = m.groupdict()
return f'{d["time"]:<26} {d["ip"]:<15} {d["status"]} {d["size"]:>8} {d["req"]}' + (
f' [{d["ua"]}]' if d["ua"] else ""
)
Aは同じ依頼に257行の本体と16個のテストを返してきて、ステータスでの絞り込み、gzip、色付け、集計まで入っていました。
数だけの違いでもありません。読めない行を、Bはそのまま出し、Aは飛ばして件数を標準エラーに出します。どっちが正解かは使い方次第ですね。
バグ修正と機能追加は差が小さかった
バグ修正は、AもBも原因の payable() を max(total - points, 0) に直しました。分かれたのは、同じ引き算を自前で持っていた report.py です。
- Opus 5.5のB:
payable()を使うように直した - Opus 5.5のA: 触らず、報告に「触っていない」と書いた
- Sonnet 5.5のA: 直した（ただし作業中にこのファイルを一度空にしてしまい、書き直したと報告していた）
Bのルールには「バグを直すときは、触る関数の呼び出し元を全部grepする」とあります。これが効いた可能性はありますが、1回ずつの試行なので断定はできません。
機能追加は、Opusの追加行数がAで103行、Bで23行。Aは頼んでいない due コマンド（期限の付け直しと解除）を足していました。Sonnetは、Aが39行、Bが26行です。
トークンと所要時間
| A | B | |
|---|---|---|
| Opus 5.5 トークン（5件の合計） | 363,376 | 339,624 |
| Opus 5.5 所要時間（合計） | 399秒 | 179秒 |
| Sonnet 5.5 トークン（3件の合計） | 198,763 | 198,479 |
| Sonnet 5.5 所要時間（合計） | 123秒 | 105秒 |
トークンはOpusで約6.5%少なく、Sonnetではほぼ同じでした。ここで比べているのはサブエージェント全体の完了通知の数字で、入力側の文脈も入っています。READMEの言う「出力トークン」とは別物です。
所要時間はOpusで約55%短くなりました。作るものが小さくなれば書く時間も減るので、そこは納得感があります。
READMEの数字と並べてみる
READMEのv5は、ルールなしを100%としたときの割合です。
| READMEのv5 | 私の試行（Opus 5.5） | |
|---|---|---|
| コードの行数 | 47% | 21% |
| 所要時間 | 59% | 45% |
| コスト | 74% | 測っていない |
READMEの方は、39タスクで各5回、中央値の比を出して幾何平均したものです。内訳は、実在のFastAPI + Reactのリポジトリでの機能追加が12、隠しチェック付きの修正が18、小さなアプリを作らせる依頼が6、例を示させる依頼が3です。
私のほうで行数の差が大きく出たのは、5件中3件が新規作成だったからだと思います。ここはAが膨らみやすい型なので。READMEとは測り方が違うので、数字は並べて見るだけにしてください。
使うなら
導入はREADMEのとおり、Claude Codeで2コマンドです。
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
効いたのは「〇〇を作って」のような、範囲を決めていない新規の依頼でした。範囲の決まった修正では差は小さめです。
入れる前に hooks/ のスクリプトを軽く見ておくと安心です。READMEによると、過去のセッションをボードに取り込むのは /ponytail band import を実行したときだけです。今回の検証ではhooksは動かしていません。
注意
試したのは各条件1回ずつなので、ばらつきは見ていません。課題も私が作った小さなものです。また、行数の差は頼んでいない機能の差でもあります。追加された機能の出来の良し悪しは評価していません。
関連記事
ponytailの考え方（7段階の判断ラダー）の入門は、こちらにまとめています。