SSD Nodes Learn 🎉 VPS $4.99/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-13

PonytailでAIエージェントの実装を最小化する方法

PonytailはAIコーディングエージェントに最小限の変更を選ばせるルールセットです。独自ベンチマークでは日付選択機能を404行から23行に削減した実例と、導入方法を紹介します。

Ponytail とは

Ponytail は、AI コーディングエージェントが書くコード量を減らすルールセットです。プロジェクト自身は、次の 1 文で説明しています。「部屋にいる中で最も怠惰なシニア開発者のように AI エージェントを考えさせます。最良のコードとは、書かずに済んだコードです。」ライセンスは MIT です。独自のランタイムはなく、内部のコードが実行されることもありません。エージェントの指示に追加するテキストであり、スキルを読み込むホスト向けには 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 の中心にあるのは、判断の段階です。エージェントは何かを書く前にこの段階を順に確認し、最初に成立する段で止まります。

  1. そもそも存在する必要があるか。これは YAGNI(必要になるまで作らない)です。不要なら実装しません。
  2. このコードベースにすでに存在するか。既存のヘルパーやパターンを再利用します。
  3. 標準ライブラリで対応できるか。標準ライブラリを使います。
  4. ネイティブのプラットフォーム機能で対応できるか。プラットフォーム機能を使います。
  5. インストール済みの依存関係で解決できるか。それを使います。
  6. 1 行で書けるか。1 行にします。
  7. その後で初めて、動作する最小限のコードを書きます。

この順序自体が機能します。個々の段だけが重要なのではありません。日付選択機能を求められたエージェントは、指示されたとおり日付選択機能を書きます。この段階を適用すると、4 番目の段を先に確認し、ブラウザーにはすでに <input type="date"> があると判断します。プロジェクト独自のベンチマーク記録にも、この例がそのまま示されています。このルールがない場合は日付選択機能が 404 行になりましたが、ルールを適用すると 23 行になりました。エージェントがコンポーネントを構築せず、ネイティブの入力要素を使ったためです。カラーピッカーも同じ理由で 287 行から 23 行になりました。

ここでいう怠けるとは、注意を怠ることではありません。ルールセットにも明記されています。「決して手を抜かない」項目には、判断前の問題理解、信頼境界での入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティ、そして名前を指定して依頼された内容が含まれます。また、複雑なロジックごとに、実行可能な小さな確認を 1 つ用意することも求めています。このルールが抑えるのは、不要な発明です。正確性を削るものではありません。

実際にリポジトリから提供されるもの

  • AGENTS.md: 常時適用されるルールセットです。5 分で読める 1 ファイルに、基本方針がすべてまとまっています。
  • skills/ponytail/SKILL.md: スキル定義です。引数のヒントとして litefull、または 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.git

Claude Code では、代わりにプラグインのインストール方法が説明されています。次の 2 行は 1 August 2026 時点の説明どおりです。

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

プラグインのパスはタグではなくデフォルトブランチを参照します。そのため、エージェントへの指示がセッション間で予告なく変更される可能性があります。更新コマンドを使える利便性を得る代わりに受け入れるトレードオフです。

VPS では怠けるエージェントのほうが低コストな理由

エージェントが作成した差分は、会話から消えません。次のターンでは、差分を生成するために開いたすべてのファイルとともに、モデルが再び読み込むコンテキストになります。そのため、500 行の変更は、それを生成したターンだけでなく、セッション内の後続のすべてのターンに負荷をかけます。セッションが進むほど暴走したリファクタリングによってエージェントの応答が遅くなり、判断力も低下したように感じられるのは、このためです。ウィンドウがエージェント自身の出力で埋まり、実際のコードに使える余地が減るからです。これを制御することが、コーディングエージェントのコンテキストウィンドウを管理する方法の主題です。

トークンは入力時と出力時の両方で課金されます。そのため、差分が半分のサイズなら、作成時に 1 回、さらに差分を再読する各ターンで 1 回、合計 2 回分安くなります。この削減が実際の請求額に反映されるかどうかは、料金の支払い方法によって異なります。定額の Pro または Max サブスクリプションでは追加トークンの費用が料金に含まれますが、トークン単位の API 課金では 1 トークンごとに請求されます。self-hosted 環境で請求額を抑えたい場合、指示ファイルは無料で調整できる手段です。AI エージェントのコストを管理する方法は出力量の制御から始まり、コーディングエージェントがトークンを消費する仕組みでは、再読が予想以上に重要になる理由を説明しています。

人間も差分を読みます。本来 20 行で済むはずの変更が 400 行あると、レビュー担当者の注意力を消費します。そして、最初に尽きるリソースは注意力です。1 日のうち 4 回目の長い差分を、最初の差分と同じ注意深さでレビューする人はいません。そのため、過剰な実装は時間を無駄にするだけではありません。ミスを見つけるはずのレビューの品質も、気付かないうちに低下させます。

サーバーでは状況が変わります。エージェントは、監視する人がいない状態で実行されることが多いためです。tmux セッション内やタイマーで動作するエージェントは、問題のある判断をさらに積み重ねる時間を、あなたが確認するまで何時間も持つことがあります。これがVPS でコーディングエージェントを実行することの実際のリスクです。そのため、ループエンジニアリングを行う人は、個々のプロンプトよりも常設の指示に多くの注意を払います。常時読み込むファイルのルールは turn 200 にも適用されます。チャットに入力したルールは turn 3 に適用されるだけです。

新しい依存関係も、見えにくいコストになります。Rung 5 では、インストール済みのものを使うよう求めています。エージェントが独自の判断で追加するパッケージは、後でパッチを適用する対象になります。また、そのリポジトリからビルドするすべてのコンテナイメージにも含まれることになります。

Ponytail 自身のベンチマーク結果が示すこと

このプロジェクトは2組の結果を公開していますが、両者には大きな差があります。どちらもプロジェクト自身が公開した数値です。独立したテストではありません。

ChartPonytail's published reduction vs baseline, percent, Haiku
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 列は、少数のプロンプトに対してルールの有無を変えてベアモデルに回答させ、2026年6月13日と17日に実施した繰り返し実行の中央値を取った結果です。agentic 列は、ヘッドレスの 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 のベースラインは「複数の選択肢と説明を付けて回答する」ベアモデルであり、これを上回るのは容易です。実際の作業を行うエージェントと比較すると、改善幅は小さくなります。それでも結果は現実的であり、こちらのほうが有用な事実です。

注意点が1つあります。これはプロジェクト自身が示しているもので、導入効果を判断するうえで重要です。削減効果が最も大きいのは、過剰実装に陥りやすい状況です。すでに最小限のコードになっている場合、効果はほぼありません。1つの Python と TypeScript のリポジトリで実施した12件のチケットから、あなたのリポジトリの結果を予測することはできません。数値が重要なら、自分のチケットを使い、ルールの有無で比較を実行して、行数を自分で数えてください。

今日から何もインストールせずに利用できるパターン

ladder はテキストなので、この考え方を使うためにプラグインは必要ありません。エージェントがすでに読み込んでいる指示ファイルに、次のようなブロックを貼り付けます。対象は AGENTS.mdCLAUDE.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 行の作業で解消できます。簡単な実装を選択したことと、その選択が成立しなくなる条件を、次の読み手に伝えます。これがないと、レビュー担当者は、検討したうえでの近道なのか、エージェントが忘れたものなのかを判断できません。そのため、確認が必要になります。

ブロックを置く場所は、記述内容と同じくらい重要です。エージェントが毎回読み込むファイルは、監視していない実行も含め、すべての実行に影響します。この違いについては、エージェントが実際に従う AGENTS.md の書き方で説明します。このパターンを shell の履歴ではなく、コミット対象のファイルに置く理由もそこにあります。

ルールが当てはまらなくなる場合

この段階表は、すでに存在するコードベースで機能開発を行う場合に合わせて調整されています。そのような環境では、再利用できる実装があり、通常はそれが適切だからです。新規プロジェクトにはあまり適していません。2 番目の段階には再利用するものがなく、5 番目の段階にはインストール済みのものがないため、エージェントは毎回 7 番目の段階まで進んでしまいます。同じ抽象化を本当に導入したい場合にも、適用しにくくなります。同じコピー済みブロックを使う箇所が 4 つ目になろうとしているとき、「差分を最小にする」という方針では、5 つ目のコピーを作ることになります。

ultra の段階では、要件に疑問を投げかけます。それがこの段階の目的であり、すでに方針を決めて作業の実行を求めている場合には、実際のコストになります。通常の作業には full を使い、機能要求そのものに問題があると考えられる場合は ultra を選びます。

どのような指示ブロックでも、問題の読み違いを防ぐことはできません。ルールセットの最初の項目自体が、判断する前にコードを理解することを求めています。そこが最もコストのかかる部分であり、文章だけでは代わりに実行できない部分です。間違った関数に対する最小限の差分は、依然として誤った修正です。しかも、承認しやすい小さな誤修正になっています。

率直にまとめると、Ponytail は注意深く作成されたプロンプトであり、適切に配布され、数値による基準が付けられています。これを実行するためにプラグインは必要ありません。このプロジェクトが提供するのは、誰かが一覧を適切に作成し、実際のリポジトリで検証し、その方法を結果とともに公開したという点です。

FAQ

Ponytail は Claude Code 以外のエージェントでも動作しますか?

はい。Ponytail は skills を読み込むホスト向けの skill として提供されており、該当するホストには Claude Code、Codex、OpenCode、Gemini など、README に記載された複数の製品が含まれます。Cursor、Windsurf、Cline、Copilot など、rule ファイルは読み込むものの skills は読み込まないエディターでは、対応する rules ディレクトリの常時適用ルールセットが使用され、slash command は利用できません。どちらの場合もテキストは同じです。実際の違いは、ホストがそのテキストを毎回のターンでコンテキストに保持するか、skill が呼び出されたときだけ読み込むかです。

遅延型のエージェントはテスト、検証、セキュリティを省略しませんか?

いいえ。ルールセットにはこの点が明記されています。「never lazy about」の一覧には、信頼境界での入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティが含まれています。また、重要なロジックの各部分について、実行可能な小さなチェックを1つ用意するよう求めています。このルールが取り除くのは、要求されていない抽象化や、不要な依存関係といった作為的な構造です。インストール後にエージェントがテストを省略し始めた場合は、別の指示が自身の設定内でこのルールより上位にあることが原因です。エージェントが最後に読み込むファイルを確認してください。

公開されている速度とコストの数値は信頼できますか?

これらはプロジェクト独自の測定値であり、測定方法とともに公開されています。その前提で読む必要があります。single shot の数値は、選択肢と説明を返すだけの素のモデルと比較したものです。README 自身も、これを弱いベースラインとしています。agentic の数値は、1つの FastAPI と React のリポジトリを対象に、Haiku 4.5 を使ったヘッドレスの Claude Code セッションで測定されています。チケットは12件で、各4回実行しています。これらは、その構成における正直な数値です。ただし、あなたのコードベースの予測値ではありません。プロジェクト自身も、すでに最小限になっているコードでは削減効果がほぼゼロになると説明しています。

効果を得るために何かをインストールする必要がありますか?

いいえ。この段階的な仕組みはテキストで構成されています。エージェントがすでに読み込む指示ファイルに同等のブロックを貼り付ければ、効果の大部分を得られます。plugin は、保守された文面、強度レベル、レビュー用 command、更新手段を提供します。まずコピーしたブロックを試すことが、インストール自体が必要かどうかを確認する rung 1 の回答です。

無人のエージェントが夜間に過剰な実装を行うのを止めるにはどうすればよいですか?

ルールをチャットメッセージではなく常時適用の指示ファイルに記述してください。そうすれば、長時間の実行で turn 3 だけでなく turn 200 にも適用されます。次に、被害を別途制限します。唯一のコピーではなく、破壊されてもよい checkout をエージェントに渡し、変更を merge する前に人間が diff をレビューするよう求めてください。最小 diff のルールにより、読む必要のある量を減らせます。ただし、どの変更を取り込むかを決めるものではなく、決めるべきでもありません。