画像のようなエンジニアっているよねー。
AI エージェントにコードを書かせると、頼んでいない抽象化や長いコメント、新しいライブラリまで付いてくることがあります。いわゆる過剰エンジニアリングです。Ponytail は、この過剰エンジニアリングを AI の側で抑えるプラグインです。
この記事では、Ponytail が何を抑えるのか、Claude Code と Codex への導入手順、実際のプルリクエストで約 100 行を削った結果までを解説します。
Ponytail とは何か
Ponytail は、「過剰な実装を嫌うベテランエンジニア」の思考ルールを AI エージェントに読み込ませる、プラグイン兼ルールセットです。
コンセプトは「最高のコードとは、書かずに済んだコードである」です。AI に任せると増えがちな、次のようなコードを抑えます。
- 必要以上に複雑なコード
- 不要で長いコメント
- 既存の機能で足りるのに追加される新しいライブラリ
ルールセットはエージェントのコンテキストに常駐します。プロンプトで毎回「シンプルに書いて」と伝え直す手間がなくなります。
コードを書く前に踏む 7 段のはしご
Ponytail を入れた AI は、コードを書き始める前に次を上から順に検討します。上の段で解決できれば、そこで止めて新しいコードを書きません。
- YAGNI：そもそも作る必要があるか。なければ作らない
- 既存コードの再利用：プロジェクト内に同じ処理がないか
- 標準ライブラリ：言語の標準機能で足りるか
- プラットフォーム標準機能：ブラウザや OS の標準機能で足りるか
- 導入済みライブラリ：すでに入っている依存パッケージで足りるか
- 1 行実装：1 行で書けるか
- 最小限の実装：どれにも当てはまらないときだけ、必要最小限を書く
この順番には理由があります。上の段ほど、リポジトリに増えるコードとメンテナンス対象が少ないためです。同じ機能でも、標準ライブラリの 1 行と自作の 30 行では、将来のバグの量が変わります。
手を抜く対象は解決策だけです。信頼境界の検証、データ欠損の処理、セキュリティ、アクセシビリティは削減の対象外だと README に明記されています。
Ponytail でできること
過剰な実装を自動で減らす
はしごの判断は、コード生成のたびに自動で走ります。こちらから指示しなくても、次のように動きます。
- 不要な機能の提案や実装を、そもそも出さない（YAGNI）
- 車輪の再発明を避け、HTML の標準要素（例:
<input type="date">）や既存コード、標準ライブラリを優先する - 安全性を損なわない範囲で、最小行数の解決策を選ぶ
専用のスラッシュコマンドを使う
導入すると、エージェント上で次のコマンドを実行できます。
| コマンド | できること |
|---|---|
/ponytail [lite | full | ultra | off] |
ルールの強度の切り替えと、現在の強度の表示 |
/ponytail-review |
現在の git diff をレビューし、過剰な箇所の削除候補リストを出力 |
/ponytail-audit |
差分ではなくリポジトリ全体を監査 |
/ponytail-debt |
ponytail: マーカーで後回しにした箇所を集めて台帳化 |
/ponytail-gain |
計測されたインパクト（コード削減率など）のスコアボードを表示 |
/ponytail-help |
利用できるコマンドのヘルプを表示 |
強度の既定値は full です。指摘が多すぎると感じたら /ponytail lite、もっと削りたいときは /ponytail ultra に切り替えます。一時的に止めるなら /ponytail off です。
/ponytail-debt は、コード中に <!-- ponytail: browser has one --> のように書いたメモを回収します。「あとで直す」を「そのまま」にしないための仕組みです。
前提条件
検証した環境は次のとおりです。
| 項目 | 内容 |
|---|---|
| OS | macOS |
| AI エージェント | Claude Code |
| Ponytail | DietrichGebert/ponytail の main ブランチ（導入時点の最新版） |
| 検証日 | 2026 年 9 月 |
Claude Code と Codex のプラグインは、Node.js 製のライフサイクルフックを 2 つ実行します。そのため node に PATH が通っている必要があります。nvm や Nix を使っている場合は、非対話シェルの PATH にも node が入っているか確認してください。
以降の Codex の手順は README の記載に沿ったもので、この記事では未検証です。
導入手順
導入方法は更新されやすいので、コマンドが通らないときは README の Install を確認してください。対応エージェントごとのコマンドが並んでいます。
Claude Code
次の 2 つを、1 回のプロンプトにまとめず、順に送信します。マーケットプレイスの登録が終わってからでないと、プラグイン名を解決できないためです。
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
Codex
ターミナルで次を実行します。
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail
そのあと codex を起動し、/hooks を開いて 2 つのライフサイクルフックを承認（trust）します。承認しないとフックが動かず、ルールセットが読み込まれません。承認したら、新しいスレッドを開始してください。
ここで一度動作確認する
レビュー用のコマンドを試す前に、導入できたかを確認します。ここで失敗していると、以降のコマンドも動きません。
/ponytail
現在の強度（初期状態では full）が返れば導入は成功です。
うまくいかないときは
コマンドが見つからない
まずセッションを開き直します。プラグインは起動時に読み込まれるためです。それでも認識されない場合は、/plugin marketplace add が成功していたかを確認します。
フックが動かない
node に PATH が通っていない可能性が高いです。エージェントを起動したシェルで which node を実行して確認します。
Codex でルールが効かない
/hooks での承認（trust）が済んでいないか、承認前に開いたスレッドをそのまま使っています。承認したうえで、新しいスレッドを開始してください。
一時的に止めたい
/ponytail off で停止します。完全に削除する場合は、アンインストールしたあとに node scripts/uninstall.js を実行し、設定や強度の状態ファイルも消します。
Cursor では、subagentStart がコンテキストを注入できないため、サブエージェントにはルールセットが効きません。クラウドエージェントでは、起動イベント自体が発火しません。
使ってみての感想
作成中のプルリクエストに対して /ponytail-review を実行しました。不要なコードやコメント、重複した処理が洗い出され、短く書き直すか削除しました。結果として、約 100 行の不要なコードを自分が追加していたと分かり、そのまま削減できました。
レビュー結果は削除候補のリストとして返るだけで、勝手に消えはしません。採用するかは自分で判断します。
将来的には、実装のたびに /ponytail-review を自動実行する Hooks を作りたいと考えています。
まとめ
- 書く前に止める仕組み：7 段のはしごを上から順に試し、最後まで残ったときだけコードを書く
-
導入コスト：Claude Code は 2 コマンド、Codex はフックの承認まで。前提は
nodeの PATH -
最初の一歩：既存のプルリクエストへの
/ponytail-review。削減量が数字で返る