ポニーテールチュートリアル - AIプログラミングエージェント:簡潔なコード練習の解説
今日は、コーディングに適した内容をご紹介します。プロジェクトを開始する際、コードは通常非常に簡潔です。2ページ、3つのインターフェース、いくつかのユーティリティ関数で構成され、目次も一目で理解できるようになっています。
今日は、コードを書く際に役立つ情報を共有します。
プロジェクトを作成する際、初期段階ではコードは非常に簡潔です。2ページ、3つのインターフェース、いくつかのユーティリティ関数で構成され、ディレクトリ構造も一目で理解できます。
機能を追加した後も、ラッパーやオプションを追加し続けたが、機能の数はあまり増えず、コードの量は何倍にも増えた。
ただし、GitHub のこの Ponytail プロジェクトを使用する限り、AI コードの記述が突然非常に簡潔になる。
ポニーテールはオープンソースの AI エージェントのルールセットとプラグインシステムをプログラミングする。
プロジェクトのアドレス:https://github.com/DietrichGebert/ponytail
このプロジェクトは、 Claude 法典、コーデックスなど AI コーディングエージェントは、コードを書く際に、最小限で分かりやすく、保守負債を残しにくい実装を優先します。
ポニーテールは AI コードを記述する前に、エージェントは一連の固定された条件を実行します。
- この機能は本当に必要でしょうか?必要ないなら、省略してください。
- 標準ライブラリには既にこの機能が備わっていますか?もしそうであれば、標準ライブラリを使用してください。
- ブラウザ、データベース、オペレーティングシステム、フレームワークは、それぞれのネイティブ機能を使ってこの問題を解決できるでしょうか?もしできるのであれば、それらのネイティブ機能を活用してください。
- プロジェクトに既に依存関係が存在する場合、問題は解決可能でしょうか?もし可能であれば、既存の依存関係を再利用してください。
- 1行のコードで実現できますか?できるなら、1行で書いてください。
- 上記の方法がどれもうまくいかない場合は、最小限の動作実装を記述してください。
Ponytailは、コードの複雑さの問題に対処するために特に使用される、よく使われるコマンドもいくつか提供しています。
`/ponytail-review` は、過剰設計をレビューする役割を担います。Ponytail は、削除、インライン化、または標準ライブラリやプラットフォームのネイティブ機能で置き換えることができるコードを指摘します。
`/ponytail-audit` はリポジトリ全体をスキャンする役割を担います。Ponytail は、過剰な抽象化、重い依存関係、過剰な設定、過度に断片化されたファイルなどを特定します。
/ponytail-debt は技術的負債の管理を担当します。Ponytail は、コード内の ponytail: コメント(簡素化が選択された理由やアップグレードが必要な時期を説明するもの)を収集し、リストにまとめます。
`/ponytail-help` コマンドを実行すると、クイックリファレンス情報が表示されます。Ponytail は、利用可能なコマンド、モード切り替え方法、および基本的な使用方法を一覧表示します。
Ponytailはコードの簡潔性を確保する一方で、一定の制約も設けています。コードサイズを削減するために入力検証を削除したり、データ損失を防ぐためのエラー処理、セキュリティ対策、アクセシビリティ要件、ユーザーから明示的に要求された機能を削除したりすることはありません。
ポニーテールを取り付けた後、自動効果的Claude CodeとCodexは、新しいセッションが開始されるたびに、ライフサイクルフックを介してコンテキストにルールを挿入します。このプロジェクトには、`/ponytail`コマンドで切り替え可能な4つのモード(lite、full、ultra、off)があります。デフォルトはfullです。
ケース1:コード内のテストを減らす
ポニーテールなし:
プロンプトワード:
【テストグループ】ベースライン
動作環境
編集が許可されているのは以下の項目のみです。
D:\360MoveData\Users\win\Desktop\distillation\full-stack-fastapi-template-baseline
ディレクトリが存在しない場合は、https://github.com/fastapi/full-stack-fastapi-template からクローンして、cd83fc1 をチェックアウトしてください。
開始する前に、HEADがcd83fc1であり、git status --shortが空であることを確認してください。
これは、まったく新しいスレッド、独立したnode_modules、独立したPython仮想環境、および独立したビルドキャッシュを使用します。
Ponytailプラグイン、フック、スキル、およびPonytailルールがロードされていないことを確認してください。環境分離の代替として`@ponytail off`を使用しないでください。
full-stack-fastapi-template-ponytail のコードを読んだりコピーしたりしてはいけません。
いずれかの条件を満たせない場合は、実行を停止し、コードを変更せず、「ベースライン環境が無効です」と報告します。
【開発課題】
full-stack-fastapi-templateに、オプションのdue_date日付フィールドを追加します。
- frontend/src/components/Items/AddItem.tsx のアイテム作成フォームに、due_date 日付選択コントロールを追加します。
- frontend/src/components/Items/EditItem.tsx のアイテム編集フォームに、due_date 日付選択コントロールを追加します。
- backend/app/models.py の ItemBase、ItemCreate、ItemUpdate、および ItemPublic に due_date を追加します。
- backend/app/alembic/versions/ に新しいデータベースマイグレーションを追加して、item テーブルに null 許容の due_date 日付列を追加します。
- full-stack-fastapi-template の既存のビルドプロセスを使用して、frontend/src/client/ 内のアイテムタイプを更新します。
- frontend/tests/items.spec.ts でのテスト日付の選択、変更、およびクリア。
- backend/tests/api/routes/test_items.py で due_date の作成、読み取り、更新、およびクリアをテストします。
- due_dateはYYYY-MM-DD形式を使用し、時刻やタイムゾーンは含まれません。
- full-stack-fastapi-template の既存のコードスタイルに従い、関連するテストを実行してください。
によると AI コーディングエージェントは、Ponytailを参照したり、「コード量を減らす」や「最初に1行で実装する」といった追加要件を追加したりすることなく、デフォルトの方法で要件を完了します。
【成績記録】
完了後、`git diff –numstat`、`git diff –stat`、および`git status –short`を実行してください。
統計情報には、新規行数、削除行数、変更されたファイル数、新規依存関係数、テスト結果、テスト時間、トークン消費量などが含まれます。
所要時間またはトークンを取得できない場合は、「利用不可」と入力してください。
テストレポートは full-stack-fastapi-template-baseline に書き込んではなりません。
テストレポートを次の場所に保存してください。
D:\360MoveData\Users\win\Desktop\Distillation\ponytail-ab-results\baseline.md
ポニーテールなし:
プロンプトワード:
@ponytail full
【テストグループ】ポニーテールフル
動作環境
編集が許可されているのは以下の項目のみです。
D:\360MoveData\Users\win\Desktop\distillation\full-stack-fastapi-template-ponytail
ディレクトリが存在しない場合は、https://github.com/fastapi/full-stack-fastapi-template からクローンして、cd83fc1 をチェックアウトしてください。
開始する前に、HEADがcd83fc1であり、git status --shortが空であることを確認してください。
これは、まったく新しいスレッド、独立したnode_modules、独立したPython仮想環境、および独立したビルドキャッシュを使用します。
Ponytailプラグインとライフサイクルフックが有効になっており、Ponytailが現在フルモードで動作していることを確認してください。
Claude Codeでは`/ponytail full`を使用しますが、Codexでは`@ponytail full`を使用します。
full-stack-fastapi-template-baseline のコードを読んだりコピーしたりしてはいけません。
いずれかの条件を満たせない場合は、実行を停止し、コードを変更せず、「Ponytail環境が無効です」と報告します。
【開発課題】
full-stack-fastapi-templateに、オプションのdue_date日付フィールドを追加します。
- frontend/src/components/Items/AddItem.tsx のアイテム作成フォームに、due_date 日付ピッカーを追加します。
- frontend/src/components/Items/EditItem.tsx のアイテム編集フォームに、due_date 日付選択コントロールを追加します。
- backend/app/models.py の ItemBase、ItemCreate、ItemUpdate、および ItemPublic に due_date を追加します。
- backend/app/alembic/versions/ に新しいデータベースマイグレーションを追加して、item テーブルに null 許容の due_date 日付列を追加します。
- full-stack-fastapi-template の既存のビルドプロセスを使用して、frontend/src/client/ 内のアイテムタイプを更新します。
- frontend/tests/items.spec.ts でのテスト日付の選択、変更、およびクリア。
- backend/tests/api/routes/test_items.py で due_date の作成、読み取り、更新、およびクリアをテストします。
- due_dateはYYYY-MM-DD形式を使用し、時刻やタイムゾーンは含まれません。
- full-stack-fastapi-template の既存のコードスタイルに従い、関連するテストを実行してください。
Ponytail Fullが既に読み込んでいるルールのみを適用し、その他のYAGNIルール、1行実装、または簡略化された提案を追加しないでください。
【成績記録】
完了後、`git diff –numstat`、`git diff –stat`、および`git status –short`を実行してください。
統計情報には、新規行数、削除行数、変更されたファイル数、新規依存関係数、テスト結果、テスト時間、トークン消費量などが含まれます。
所要時間またはトークンを取得できない場合は、「利用不可」と入力してください。
テストレポートは full-stack-fastapi-template-ponytail に書き込んではなりません。
テストレポートを次の場所に保存してください。
D:\360MoveData\Users\win\Desktop\Distillation\ponytail-ab-results\ponytail.md
今回の比較では、ベースライングループが225行のコードを追加したのに対し、ポニーテールフルグループは149行を追加しました。ポニーテールは新規コードの総量を約34%削減し、変更されたファイルの数を10個から8個に減らしました。これは、ポニーテールが意図しない機能、冗長な検証、不要な変更を削減できることを示しています。
ケース2 プロジェクトレビュー
プロンプトワード:
/ponytail-review
過剰設計されているコードのみをレビューしてください。書き換えはしないでください。削除、インライン化、または標準ライブラリやブラウザのネイティブ機能で置き換え可能な箇所を特定することに重点を置いてください。
このReactコードを確認してください。
import { useState } from "react";
import dayjs from "dayjs";
class DateInputAdapter {
constructor(formatter) {
this.formatter = formatter;
}
normalize(value) {
return this.formatter(value);
}
}
const createDateFormatter = () => {
return (value) => dayjs(value).format("YYYY-MM-DD");
};
export function BirthdayPicker() {
const [date, setDate] = useState("");
const adapter = new DateInputAdapter(createDateFormatter());
function handleChange(event) {
const normalized = adapter.normalize(event.target.value);
setDate(normalized);
}
return (
type="text"
placeholder="YYYY-MM-DD"
value={date}
onChange={handleChange}
/>
);
}
Ponytailは、過剰設計の事例を4つ正確に特定し、行番号、問題の種類、修正方向をマークしました。命名規則、コードスタイル、例外処理については議論せず、過剰設計のみをレビューするという/ponytail-reviewの目的に合致していました。
事例3:倉庫検査
このケースでは、リポジトリに意図的に単一実装のインターフェース、ファクトリ、アダプタ、マネージャ、ファサード、冗長な構成、および置換可能な依存関係を含めて、それらが検出可能かどうかを確認しました。
プロンプトワード:
/ponytail-audit
リポジトリ /D:/360MoveData/Users/win/Desktop/distillation/ponytail-case2-audit をスキャンし、非効率なプロセスのみを探してください。出力には、ファイルごとに問題点を一覧表示し、それぞれの問題点の複雑さを軽減する方法を説明してください。
以下の点を確認することに重点を置いてください。
- 単一の実装に対して、インターフェース、ファクトリ、マネージャー、およびアダプターを作成します。
- のために単純データ変換は、サードパーティへの依存関係を生み出す。
- 将来のニーズに備えて、構成を予備として確保しておく。
- 複数のファイル間で転送が行われるのは1層のみで、特に論理的な仕組みはありません。
- 標準ライブラリ、フレームワークの機能、データベースの機能を使えば実現できたはずなのに、代わりに一連のロジックを手作業で記述した。
ビジネス機能のレビューは行わず、コードスタイルのチェックも行わず、Ponytailが重視する過剰設計にのみ集中してください。
Ponytailの13の調査結果は、基本的にケース3に事前に組み込まれていた学位に関する問題を網羅しており、CSVエスケープ、JSON読み取り、および...の偶発的な削除の事例はなかった。自動テスト結果。結果は包括的で、提案内容も非常に具体的です。
ケース4:技術的負債の回収
プロンプトワード:
/ponytail-debt
リポジトリ /D:/360MoveData/Users/win/Desktop/distillation/ponytail-case3-debt から ponytail: コメントを収集し、それらを技術的負債リストにまとめてください。
以下の形式で出力してください。
- ファイルパス
– 注釈
―当時、簡素化を選択した理由
– 今後のアップグレードのトリガー条件
今すぐ処理する必要がありますか?
以下の種類の注釈には特に注意してください。
// ponytail: keep native date input until timezone support is required
// ponytail: inline this mapper until a second provider appears
// ponytail: use in-memory cache until requests exceed 1000/min
// ponytail: avoid queue dependency until retry semantics are needed
コードに含まれていない技術的負債を追加しないでください。
Ponytailは、ファイル名と行番号を正確に特定し、5件のポニーテールに関するコメントをすべて見つけました。各レコードは、簡素化の理由、アップグレードの条件、および現在のステータスに分類されました。
Claude コードとコーデックスは、ますます包括的な開発業務を担うようになっている。
コード生成速度が向上する一方で、変更内容のレビュー、検証、保守にかかるコストも上昇します。DORA 2025の調査によると、回答者の90%が既に業務で[コード生成手法]を使用しています。 AIこれは2024年と比較して14.1%の増加を意味するが、…AI 利用頻度の増加は、ソフトウェア配信の不安定性の増大と関連している。
Ponytailは、MVPの開発および修正時間を短縮し、コードレビューの負担を軽減するだけでなく、固定ツールセットとしても機能します。 AI コーディング規則は、無意味な依存関係、抽象化、およびファイルサイズの増大を制限します。
34%という数値はローカルテストの結果に過ぎず、すべてのコードベースに直接適用できるものではありません。元の実装が既に十分に効率化されている場合、Ponytailでさらにコードを削減することは困難です。Ponytailが顕著な効果を発揮するのは、ネイティブ機能、冗長なカプセル化、または過剰設計といった要件がある場合に限られます。
ポニーテールの価値は、その後のメンテナンス、レビュー、および再作業のコストを削減できる点にある。