Claude Code向けのスキルとして特に人気の高いPonytailがバージョン5になりました。その中心となる主張は、独立した検証でもおおむね裏付けられています。スキルとは、ある種の作業の進め方をAIエージェントに教える指示をひとまとめにしたもので、Ponytailの指示はClaudeにできるだけ少ないコードを書かせることを狙っています。Claude Opus 5.5での検証では、スキルを入れていないClaude Codeと比べてコードは61%少なく、コストは24%低く、処理は35%速く終わり、コードの安全性が目立って下がることもありませんでした。ただし、依頼の自由度が高くなると弱点が表れます。Ponytailは頼まれたものだけを作り、それ以外はほとんど作らないため、ランディングページなどの画面は簡素な仕上がりになります。仕様が厳密に決まった作業には向く一方、自由度の高い作業で標準にする設定としては不向きです。
Ponytailの仕組み
Ponytailは、Claudeには冗長になりがちで、解決策を作り込みすぎる傾向があるという前提から出発しています。厳しいルールを与えればモデルは本当に必要なものに集中し、よりすっきりとして、安く、速い出力を生むという考え方です。このプロジェクトはGitHubで17万近くのスターを集めており、現在のリリースはv5.3.2です。
中核となるのは、エージェントがコードを書く前に順にたどる7段階の質問のはしごです。「そもそもこれは存在する必要があるか」から始まり、「1行で書けないか」で終わります。コードは、機能する最も低い段でだけ書かれ、小さなテストが添えられます。
違いがよく分かるのがデートピッカー（日付選択の部品）の例です。アプリのフロントエンドに追加するよう頼まれると、スキルなしのClaudeは外部ライブラリを持ち込むか、カレンダーを一から自作し、コードは335行になりました。Ponytail 5を使うと、モデルはブラウザに組み込まれた日付入力とアプリの既存のUIコンポーネントに気づき、10行で作業を終えました。
バージョン5についてプロジェクトが公式に示している数値は次の通りです。
| 指標 | Ponytail 5で主張されている変化 |
|---|---|
| コードの行数 | 53%減 |
| コスト | 26%減 |
| 出力トークン | 45%減 |
| 実行時間 | 41%短縮 |
| テスト付きで出荷されるリスクの高いロジック | 98%（スキルなしでは68%） |
バージョン5の五つの変更点
- ルールの短縮。 指示プロンプトは1,094語から592語に縮み、各セッションの実行コストはv4.13より約10%下がりました。
- まず変更範囲を洗い出す。 コードに手を付ける前に、Claudeは変更の全体像を把握しなければなりません。対象は呼び出し元、フィクスチャ（テストが前提とする保存済みデータ）、設定、そして影響範囲、つまりその編集が影響しうるすべての部分です。
- 省いた内容の開示。 モデルは、何を省いたか、何を確認しないことにしたか、どんなリスクが残るかを明示しなければなりません。バージョン4ではこれは任意でした。
- 監査範囲の拡大。 レビューの工程は以前、作り込みすぎだけを探していました。現在は、差分（変更される行の範囲）の外にあるバグ、セキュリティ脆弱性、不足しているテスト、性能上の問題も探します。
- リポジトリマップとリアルタイムのステータス表示。 各セッションの開始時にPonytailはリポジトリのマップを作り、エージェントが既存の関数を再利用するように促します。ターミナルのステータス表示には、セッションのコスト、トークン使用量、エージェントの作業時間、再利用したコードの割合、テストの合否が表示されます。
数値は本当か
ここで紹介する検証には、合計で約700のClaude Codeセッションが使われました。公式の主要な数値を確かめる検証では、Claude Opus 5.5で39のタスクを132セッションにわたって実行し、結果はプロジェクトの公表値に近いものでした。
| 指標 | 公表値 | 実測値 |
|---|---|---|
| コードの削減 | 53% | 61% |
| コストの削減 | 26% | 24% |
| 実行時間の短縮 | 41% | 35% |
| v4.13比のコスト削減 | 約11% | 10.5% |
公式の主要な数値からは六つのタスクが外されており、都合のよいタスクだけを選んだのではないかという疑いを招きかねません。その六つを別に実行したところコードは76%減っており、外したことで結果がよく見えていたわけではなさそうです。
7語で同じ仕事ができるか
XやRedditでよく見かける反論は、Ponytailは作り込みすぎで、YAGNIを持ち出す1行があれば同じ仕事ができるというものです。YAGNIは「You Aren’t Gonna Need It」の略で、実際に必要になるまで何も作らないというソフトウェア開発の原則です。この反論を確かめるため、コーディングエージェントが読む常設の指示ファイルであるAGENTS.mdに7語の指示「Follow YAGNI principles, and prefer one-liner solutions.」を置き、Ponytailと比べました。
30のタスクで単純な効率だけを見ると、短いプロンプトが勝ちました。コードを72%、コストを38%減らし、Ponytailの60%と24%を上回りました。
ところが、電卓、分析ダッシュボード、カレンダーアプリといった「アプリを作って」型の24のタスクをブラインド監査にかけ、どの設定が作った結果かをレビュー担当者に伏せて評価すると、形勢は逆転しました。
| 監査項目 | 7語のプロンプト | Ponytail |
|---|---|---|
| データを失うバグ | 2件 | 0件 |
| テスト付きで納品されたタスク | 24件中14件（58%） | 24件中24件（100%） |
| 必須機能の達成率 | 89% | 95% |
| 中核機能の達成率 | 97% | 100% |
| 省いた項目の開示率 | 49% | 78% |
Ponytailのルールにある約580語の上乗せ分は、無駄な肥大ではなく、ガードレールとして働いているようです。裏返せば注意点もあります。「短くして」と言うだけの指示は、コストのグラフ上では見栄えがよくても、知らないうちにテストを省き、データを壊すバグを本番のコードに招き入れかねません。
▲ ガードレールと短いだけのプロンプトの差
安全性は保たれた
Claudeをここまで締め付ければ、コードが壊れたり安全性が下がったりするのではないかと心配になるのはもっともです。Claude Opus 5.5で351件のコーディングジョブをブラインドで実行し、隠された検証テストで確かめたところ、342件が合格しました。145件のひっかけ入力を使った別のストレステストでは、合格率は次の通りでした。
| 設定 | ひっかけ入力の合格率 |
|---|---|
| 素のClaude | 100.0% |
| Ponytail 5 | 99.5% |
| 7語のプロンプト | 98.4% |
プライバシーに関わるタスクでは、ニュースレターの購読者全員に、誰のアドレスも明かさずにメールを送るよう各設定に求めました。これにはBCC（ブラインドカーボンコピー）が必要です。それぞれ3回ずつ試したところ、素のClaudeは2回、Ponytail 5は1回失敗し、旧バージョンのPonytailと7語のプロンプトは3回とも失敗しました。この結果を見る限り、Ponytail 5がコードを大きく壊したり、安全でないものにしたりすることはありません。
本当の代償は頼まれていない付加要素
トレードオフが表れるのは画面づくりの作業です。AからGまですべての仕様を書き込んだ詳細なPRD（製品要求仕様書）を渡せば、Ponytailは指示を簡潔かつきれいに実行します。一方、「ランディングページを作って」のような自由度の高いプロンプトでは、素のClaudeは意図をくみ取り、自ら暗黙の下調べをして、ユーザーが期待するUIの部品を補うOpus 5.5の能力に頼ります。Ponytailが抑え込むのは、まさにその能力です。
五つのランディングページ用プロンプトの結果をレビュー担当者がブラインドで採点すると、その差がはっきりしました。ここでいう付加要素とは、誰も明示的に頼んでいないものの、あると望ましい要素を指します。
| 設定 | 付加要素の実装率 | 見た目の評価（5点満点） | 5ページ分のコスト |
|---|---|---|---|
| 素のClaude | 82% | 4.3 | $1.83 |
| Ponytail 5 | 41% | 2.7 | $0.64 |
| 7語のプロンプト | 46% | 2.9 | $0.66 |
| Ponytail 5に「polish it」を追加 | 63% | 3.1 | $2.82 |
後からPonytailに「polish it」（仕上げて）と指示すると付加要素は63%に増えましたが、費用は$2.82に膨らんで素のClaudeを大きく上回り、それでも見た目は劣っていました。
Free、Pro、Teamの3プランを持つSaaS製品の料金ページでも、同じ結果になりました。
| 設定 | コードの行数 | コスト | 必須要素 | 付加要素 |
|---|---|---|---|---|
| 素のClaude | 388 | $0.32 | 100% | 89% |
| Ponytail 5 | 94 | $0.13 | 100% | 47% |
| 7語のプロンプト | 93 | $0.11 | 100% | 39% |
| Ponytail 5に「polish it」を追加 | 209 | $0.50 | 100% | 66% |
素のClaudeは、完全なナビゲーションバー、機能比較表、FAQのアコーディオンまで備えたページを作りました。Ponytail 5は必須要素をすべて満たしたものの、ナビゲーションバー、アニメーション、利用者の声のような社会的証明、FAQ、補助的なCTA（行動喚起）、比較表、請求の切り替えトグルを省きました。「polish it」の後でも、充実した表や機能ごとの詳しい説明は欠けたままでした。同じ傾向は、ストアの分析ダッシュボード、コーヒー焙煎店のページ、ウェイトリストのページ、ToDoアプリでも繰り返されました。
テスト全体をまとめると、傾向は一貫しています。
| 設定 | 依頼した機能の実装率 | 依頼していない付加要素の実装率 |
|---|---|---|
| 素のClaude | 100% | 98% |
| Ponytail 5 | 98% | 54% |
| 7語のプロンプト | 97% | 36% |
Ponytailは頼んだものは残し、頼んでいないものは削ります。削られたものの中には、検索、ページ送り、分かりやすいエラーメッセージ、元に戻す機能など、日々の使い勝手に関わるものもあります。その分野の専門家ではなく、機能や見た目の抜けをClaudeに埋めてもらうつもりの人には、出力が物足りなく感じられるかもしれません。
▲ 省かれた依頼外のページ付加要素
導入すべき場面、避けるべき場面
Ponytail 5は主張をおおむね裏付けており、重大なバグやセキュリティホールを生まずに、コードを61%減らし、コストを24%下げ、実行を35%速めたことが計測されています。その代償はClaudeの自主性です。Opus 5.5が最も得意とするとみられる、言葉にされていないニーズを察して妥当な初期設定で補う力こそ、このスキルが止めてしまうものです。もし一つのルールセットであらゆる分野のトークン効率が本当に解決するなら、AnthropicやCodexを擁するOpenAIをはじめとする最先端の研究所が、とうに組み込んでいるはずでしょう。
| 状況 | 判断 |
|---|---|
| 網羅的なPRDがあるバックエンドや設計の作業 | 試す価値あり |
| フロントエンドのデザイン、UIの試作、あいまいなプロンプト | 素のClaudeのままがよい |
| 1行の修正やピンポイントの修正 | 使わない。ルールの読み込みで節約分以上のトークンを使う |
| 「polish it」で直すつもりの簡素な出力 | 節約分が消える |
導入を考えているなら、次の手順が役立ちます。
- 全体に導入する前に、まず一つのプロジェクトでPonytailを試し、コストと出力の質を並べて比べます。
- 仕様を完全に書ける作業ではオンにし、Claudeのデザイン判断に任せたいときはオフにします。
- 簡素な結果を「polish it」のような追加のプロンプトで補おうとしないでください。やり取りが増えるほど節約分は消え、素のClaudeより高くつくこともあります。
- 本番のコードを「簡潔に」だけの極端に短い指示に任せないでください。テストを省きがちで、データを失うバグを招くおそれがあります。
- スキルを使わなくても、考え方は取り入れられます。編集の前に変更範囲を洗い出させ、省いたことや検証しなかったことを列挙させるルールをCLAUDE.mdやAGENTS.mdに書いておけば、何と引き換えにしているのかが見えるようになります。