著者 PonytailでAIエージェントの実装を最小化する方法
PonytailはAIコーディングエージェントに最小限の変更を選ばせるルールセットです。date pickerの実装が404行から23行になったベンチマークや導入方法を紹介します。
Ponytail とは
Ponytail は、AI コーディングエージェントが書くコード量を減らすためのルールセットです。プロジェクトでは、これを次の 1 行で説明しています。「部屋で最も怠惰なシニア開発者のように AI エージェントを思考させる。最良のコードとは、書かなかったコードです。」MIT ライセンスで提供されています。独自のランタイムはなく、内部で実行されるものもありません。エージェントの指示に追加するテキストであり、skill を読み込むホスト向けには skill として、skill に対応しないホスト向けには通常のルールファイルとしてパッケージ化されています。
リポジトリは DietrichGebert/ponytail です。2026 年 6 月 12 日に作成され、2026 年 8 月 1 日までに 90,000 stars を獲得しました。2026 年 8 月 1 日時点の最新のタグ付きリリースは v4.8.4 です。2026 年 6 月 29 日に公開され、releases ページには 6 月 14 日から 29 日までの間だけで 10 個のタグが掲載されています。この速度で変化するプロジェクトは、この記事を読む時点ですでに変更されている可能性があります。そのため、このプロジェクトを基盤に何かを構築する前に、タグを固定してください。
ツールの前に考えること: 適用できる最初の段階で止める
Ponytail の中核は、判断の段階を順に確認することです。エージェントはコードを書く前にこの段階をたどり、適用できる最初の段階で止まります。
- そもそも存在する必要があるか。これは YAGNI（You Aren't Going to Need It）です。不要なら、実装しません。
- このコードベースにすでに存在するか。既存のヘルパーまたはパターンを再利用します。
- 標準ライブラリで実現できるか。標準ライブラリを使います。
- ネイティブのプラットフォーム機能で対応できるか。それを使います。
- すでにインストールされている依存関係で解決できるか。それを使います。
- 1 行で書けるか。1 行にします。
- それでも必要な場合に限り、動作する最小限のコードを書きます。
効果を生むのは、個々の段階ではなく、この順序です。エージェントに date picker を求めると、指示されたとおり date picker を実装します。しかし、この段階を使うと、まず第 4 段階を確認します。そして第 4 段階は、ブラウザーにすでに <input type="date"> があることを示します。プロジェクト独自のベンチマークにも、まさにこの例が記録されています。このルールがない場合に 404 行になった date picker が、ルールを適用すると 23 行になりました。エージェントがコンポーネントを構築せず、ネイティブの input を使ったためです。colour picker も同じ理由で 287 行から 23 行になりました。静かに失敗するのは第 2 段階です。エージェントが既存のヘルパーを見つけられないと、ためらわずに 2 つ目を実装します。これを防ぐために、コードベースを検索可能なマップが用意されています。
ここでいう「怠ける」は、注意を怠るという意味ではありません。ルールセットにも、その点が明記されています。「決して怠けてはならない」項目には、判断する前に問題を理解すること、信頼境界での入力検証、データ損失を防ぐエラー処理、セキュリティ、アクセシビリティ、そして名前を指定して依頼された内容が含まれます。また、複雑なロジックごとに、実行可能な小さなチェックを 1 つ用意することも求めています。このルールが抑えるのは、独自実装です。正しさを犠牲にするものではありません。
リポジトリが実際に提供するもの
AGENTS.md。常時適用されるルールセットで、5 分で読める 1 ファイルに基本方針をまとめています。skills/ponytail/SKILL.md。スキル定義で、引数の指定例はlite、fullまたはultraです。.cursor/rules/や.windsurf/rules/など、エディター固有のディレクトリにあるルールファイル。ルールは読み込むものの、スキルは読み込まないホスト向けです。hooks/、benchmarks/、examples/、scripts/。
強度引数によって、ルールの適用の強さが変わります。lite は要求されたものを構築し、より簡素な選択肢を 1 行で示します。full がデフォルトで、段階的な基準を適用します。ultra は YAGNI を徹底する設定です。追加より削除を優先し、要件そのものにも異議を唱えます。
スキルに対応するホストでは、スラッシュコマンドも使用できます。/ponytail はレベルを設定し、/ponytail-review は差分の過剰設計を確認し、/ponytail-audit はリポジトリ全体を確認し、/ponytail-debt は先送りしたショートカットを収集し、/ponytail-gain はベンチマークのスコアカードを表示します。ルールファイルだけを読み込むホストでは、コマンドなしでルールセットだけが適用されます。
信頼する前にソースを確認するには、ブランチではなくタグを clone します。
git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.gitClaude Code では、代わりにプラグインのインストール方法が案内されています。次の 2 行は 2026 年 8 月 1 日時点のドキュメントに記載された内容です。
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytailプラグインのパスはタグではなくデフォルトブランチを参照します。そのため、エージェントへの指示がセッション間で変更される可能性があります。更新コマンドを使える利便性の代わりに、この点を受け入れる必要があります。
VPS では怠惰なエージェントのほうが安価な理由
エージェントが作成した差分は、会話の外には出ません。次のターンでは、その差分に加えて、作成時に開いたすべてのファイルもモデルが再びコンテキストとして読み込みます。そのため、500 行の変更は、それを作成したターンだけでなく、そのセッションの後続ターンすべてに負荷をかけます。セッションが進むにつれて暴走したリファクタリングによってエージェントの応答が遅くなり、判断力も落ちたように感じられるのはこのためです。コンテキストウィンドウがエージェント自身の出力で埋まり、実際のコードに使える余地が減るからです。これを制御することが、コーディングエージェントのコンテキストウィンドウを管理することの中心です。
トークンは入力と出力の両方で課金されます。そのため、差分が半分のサイズなら、作成時と、その後に再読み込みされる各ターンの両方で安くなります。ただし、その節約が実際の請求額に反映されるかどうかは、料金体系によって異なります。定額の Pro または Max サブスクリプションでは追加トークンの料金が吸収されますが、トークン単位の API 課金では 1 トークンごとに料金が発生します。セルフホスト環境の費用を監視しているなら、指示ファイルは追加費用なしで効果を得られる手段です。AI エージェントの費用を制御するには出力量の管理から始めます。コーディングエージェントがトークンを消費する仕組みでは、再読み込みの影響が想定以上に大きい理由を説明しています。
差分は人間も確認します。本来 20 行で済む変更が 400 行になっていれば、レビュー担当者の注意力を消費します。注意力は最初に尽きるリソースです。そのため、1 日のうち 4 回目の長い差分を、最初の差分と同じ注意深さで確認する人はいません。過剰な実装は時間を浪費するだけでなく、ミスを見つけるはずのレビューの品質も気付かないうちに低下させます。
サーバーでは状況が変わります。エージェントが誰にも監視されずに実行されることが多いためです。tmux セッションやタイマーで動作するエージェントには、問題のある判断を積み重ねる時間が、あなたが確認するまで何時間もあります。これが VPS 上でコーディングエージェントを実行する際の実際のリスクです。そのため、ループエンジニアリングに取り組む人は、個々のプロンプトよりも常時適用する指示に多くの注意を払います。常時適用ファイルのルールは turn 200 にも適用されます。チャットに入力したルールは turn 3 に適用されるだけです。また、同じサーバーで開始した 2 つ目のセッションにも適用されます。2 つ目のセッションはコミット済みファイルを読み込みますが、1 つ目のセッションに入力した内容は、2 つのセッションが相互にメッセージを送信できる場合でも引き継ぎません。
新しい依存関係も、気付きにくいコストになります。Rung 5 では、インストール済みのものを使うよう定めています。エージェントが独自の判断で追加するパッケージは、後でパッチを適用する対象になります。また、そのリポジトリから作成するすべてのコンテナイメージに含まれることになります。
Ponytail 自身のベンチマーク結果が示すこと
このプロジェクトは、結果を 2 種類公開しています。しかし、両者には大きな差があります。どちらもプロジェクト自身が公開した数値です。独立したテストではありません。
The data behind this chart
[
{
"label": "Lines of code",
"single_shot_pct": 93,
"agentic_pct": 54
},
{
"label": "Cost per run",
"single_shot_pct": 63,
"agentic_pct": 20
},
{
"label": "Wall clock time",
"single_shot_pct": 74,
"agentic_pct": 27
}
]single shot 列は、ルールありとルールなしで少数のプロンプトに回答する bare model の結果です。2026 年 6 月 13 日と 17 日に実施した複数回の実行について、中央値を示しています。agentic 列は、headless Claude Code セッションで tiangolo の full-stack-fastapi-template を編集した結果です。これは実際の FastAPI および React リポジトリで、Haiku 4.5 を使って 12 件の機能チケットを処理し、各チケットを 4 回実行しています。評価対象は、最後に残った git diff です。
2 列目を見てください。agentic の結果では、コード行数が 54 パーセント少なく、コストが 20 パーセント低く、実時間が 27 パーセント短くなっています。single shot 構成では、同じ指標について 93 パーセントと 74 パーセントです。README では、その理由を率直に説明しています。single shot のベースラインは、単純な model が「複数の選択肢と解説を添えて回答する」ものです。これは簡単に上回れます。実際の agent が実際の作業を行う条件で比較すると、差は小さくなります。それでも効果はあり、その点がより重要です。
注意点が 1 つあります。これはプロジェクト自身も指摘しており、この手法が役立つかどうかを左右します。削減効果が最大になるのは、過剰実装に陥りやすい明確な状況です。もともと最小限のコードには、ほとんど効果がありません。1 つの Python および TypeScript リポジトリで実施した 12 件のチケットから、あなたのリポジトリの結果を予測することはできません。数値が重要なら、自分のチケットを使い、ルールありとルールなしで比較を実行してください。そのうえで、自分で行数を数えてください。
今日すぐ使える、何もインストールしないパターン
この手順はテキストで構成されているため、この考え方を使うためにプラグインを導入する必要はありません。AGENTS.md、CLAUDE.md、またはエディターのルールファイルなど、エージェントがすでに読み込む指示ファイルに、次のようなブロックを貼り付けます。
## Before you write code
Climb this list in order. Stop at the first line that applies.
1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.
Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.
Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.
Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.最後のルールは、それだけで取り上げる価値があります。Ponytail では、ツール名を付けたコメントを使用します。
# ponytail: global lock, per-account locks if throughput mattersこのコメントにより、2 行分の作業で、レビューに 1 回必要になり得る判断が確定します。簡単な実装を意図的に選んだことと、その判断が成立しなくなる条件を次の読者に伝えられます。これがなければ、レビュー担当者は、検討したうえでの簡略化なのか、エージェントが忘れたものなのかを判断できず、確認を求めることになります。
ブロックを置く場所は、内容と同じくらい重要です。エージェントが実行のたびに読み込むファイルは、監視していない実行も含め、すべての実行に影響します。この違いについては、エージェントが実際に従う AGENTS.md の書き方で説明します。そのため、このパターンは shell の履歴ではなく、コミットするファイルに記述します。monorepo では、コミットするファイルを複数配置する必要があります。パッケージごとに AGENTS.md を配置することで、エージェントが実行のたびにツリー全体の規約を読むのではなく、各ディレクトリのルールだけを短く保てるためです。ただし、配置したからといって確実に適用されるわけではありません。ラダーにさらに強い表現が必要だと判断する前に、エージェントが読み込んだルールを無視して先へ進む理由を理解しておくとよいでしょう。
ルールが当てはまらなくなる場面
この段階表は、既存のコードベースで機能を実装する作業向けに調整されています。通常は再利用でき、再利用するのが適切なコードがあることを前提としています。そのため、greenfield プロジェクトには適していません。2 段目には再利用するものがなく、5 段目にはインストール済みのものがないため、エージェントは毎回 7 段目まで進んでしまいます。本当に抽象化が必要になった時点でも、適用しにくくなります。同じコピー済みブロックを使う 4 番目の呼び出し元を追加しようとしている場合、「差分を最小にする」という方針では 5 つ目のコピーが作られます。
ultra のレベルでは、要件に疑問を投げかけます。それがこのレベルの目的です。ただし、すでに判断を下して作業の実施を求めている場合は、実際のコストになります。通常の作業には full を使い、機能リクエスト自体に問題があると考えられる場合に ultra を選びます。
どれほど詳しい指示ブロックでも、問題の読み違いを防ぐことはできません。このルールセット自体も、判断する前にコードを理解することを最初の項目にしています。そこが最もコストの高い部分であり、本文が代わりに実行できない部分です。間違った関数に対する最小の差分は、依然として間違った修正です。しかも、承認しやすい小さな誤修正になっています。
正直にまとめると、Ponytail は慎重に書かれたプロンプトを適切に配布し、そこに数値を付けたものです。プラグインを必要とする要素はありません。このプロジェクトが提供するのは、誰かがリストを正しく作成し、実際のリポジトリでテストし、その手法を結果とともに公開したことです。
FAQ
Ponytail は Claude Code 以外のエージェントでも動作しますか？
はい。Ponytail はスキルを読み込むホスト向けの skill として提供されており、Claude Code、Codex、OpenCode、Gemini、および README に記載されたその他の複数のホストが含まれます。Cursor、Windsurf、Cline、Copilot など、ルールファイルは読み込むもののスキルを読み込まないエディターは、対応する rules directory から常時適用されるルールセットを取得しますが、slash command は利用できません。どちらの場合もテキストは同じです。実際の違いは、ホストがそのテキストを毎ターンコンテキストに保持するか、skill が起動したときだけ読み込むかです。
遅延するエージェントはテスト、検証、セキュリティ対策を省略しませんか？
いいえ。ルールセットにはこの点が明記されています。「never lazy about」の一覧には、信頼境界での入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティが含まれています。また、重要なロジックの各部分について、実行可能な小さなチェックを 1 つ用意するよう求めています。ルールが取り除くのは、要求されていない抽象化や、不要な依存関係といった、作られた構造です。インストール後にエージェントがテストを省略し始めた場合は、独自の設定にある別の指示がこのルールより優先されていることが原因です。そのため、エージェントが最後に読み込むファイルを確認してください。
公開されている速度とコストの数値は信頼できますか？
これらはプロジェクト独自の測定結果で、測定方法とともに公開されています。その前提で読む必要があります。single shot の数値は、選択肢と補足説明を返すだけの素のモデルと比較しています。README 自体も、この比較対象は弱いベースラインだと説明しています。agentic の数値は、1 つの FastAPI と React のリポジトリで、12 件のチケットを対象に、Haiku 4.5 を使った headless Claude Code session を 4 回ずつ実行して得たものです。この構成に対する数値としては妥当です。ただし、あなたのコードベースに対する予測ではありません。プロジェクト自身も、もともと最小限のコードでは削減効果がほぼ 0 になると説明しています。
効果を得るために何かをインストールする必要がありますか？
いいえ。ladder はテキストです。エージェントがすでに読み込む instruction file に同等のブロックを貼り付ければ、効果の大部分を得られます。plugin には、保守されている文面、intensity level、review command、更新手順が含まれます。まずコピーしたブロックを試すことが、インストール自体が必要かという問いに対する rung 1 の答えです。
無人のエージェントが一晩で過剰に実装するのを防ぐにはどうすればよいですか？
ルールを chat message ではなく常時適用される instruction file に記述してください。そうすれば、長時間の実行で turn 3 に限らず turn 200 にも適用されます。次に、被害の範囲を別途制限します。唯一のコピーではなく、壊してもよい checkout をエージェントに渡し、マージ前に人間が diff をレビューするよう求めてください。minimal diff rule により、読む必要のある量は減ります。ただし、何を取り込むかを決めるものではなく、決めるべきでもありません。