Transcript
00:00:00彼を知っていますよね。長いポニーテールに楕円形のメガネ、バージョン管理よりも長く会社にいるあの人です。
00:00:0650行のコードを見せると、何も言わずに眺めて、たった1行に書き換えてしまう。
00:00:11それが「Ponytail」という新しいライブラリの壮大な説明なのですが、なんだか
00:00:17共感できますよね。誰の周りにも一人くらい、そんな伝説的な10倍エンジニアがいるはずです。しかし「Ponytail」
00:00:23は、実は本当にクールなツールなんです。AIコーディングエージェントに、部屋の中で一番
00:00:29怠け者のシニアエンジニアのような考え方をさせるんです。しかもそれは褒め言葉です。今回の動画では「Ponytail」
00:00:35がどのように機能するのかを見ていき、いくつかの楽しいデモを通して、このツールが本物かどうか検証します。
00:00:41とても楽しい内容になるはずです。それでは早速見ていきましょう。
00:00:48Ponytailの目的はシンプルです。すべてを極限まで簡潔にし、AIエージェントが生成しがちな
00:00:55無駄を排除して、問題に対して考え得る限り最も効率的な解決策を導き出すこと。
00:01:00AIコーディングエージェントの無駄口を減らす「Caveman」というライブラリと似ています。
00:01:06トークン消費を抑えることができるツールで、Jamesも素晴らしい紹介動画を上げていました。根本的な
00:01:12アイデアは、YAGNI原則を受け入れること。これは「You Ain't Gonna Need It（必要になることはない）」の略で、
00:01:1890年代からのソフトウェア工学の概念です。その核心は、本当に必要になるまで何も作るなということ。
00:01:25抽象化レイヤーを加えたり、ライブラリをインストールしたり、クラスを書いたりしてはいけません。
00:01:31それなしで解決できるなら、そのまま解決すればいいのです。Ponytailはそれをエージェントに
00:01:37直接組み込みます。コードを書く前に登らなければならない「決定の階段」を設けているのです。
00:01:43それは本当に必要なのか？標準ライブラリで対応できないか？プラットフォーム固有の機能はないか？
00:01:50すでにインストール済みの依存関係でできるか？1行で書けないか？これらすべての質問に対して
00:01:57答えがノーである場合のみ、新しいコードを書きます。しかも、動作に必要な最小限のコードしか書きません。
00:02:04それだけです。
00:02:05彼らの例、特にモーダルダイアログの例を見ると、この手法がよく分かります。
00:02:11通常のエージェントは、削除確認用のモーダルダイアログを求められると、すぐにRadix UIのような
00:02:18Reactダイアログライブラリをインストールしようとします。その結果、依存関係が増え、ポータル、オーバーレイ、
00:02:25ルート、トリガー、コンテントラッパーなど、たった2つのボタンがあるボックスを表示するためだけに、余計なものが増えます。
00:02:34でもPonytailはこう考えます。ブラウザにはすでにdialog要素がある。これならフォーカスを
00:02:41自動的にトラップできるし、Escキーで閉じられる。CSSセレクター1つで背景もレンダリングできる。
00:02:492022年以降の主要ブラウザならどこでもサポートされています。だからNPMパッケージで30行書く代わりに、
00:02:588行で、依存関係ゼロで済むのです。そして、この「Ponytail」のコメントが、
00:03:04何が省略され、なぜそうしたのかを教えてくれます。だから将来的にRadix版などの豪華なものに
00:03:11アップグレードしたくなっても、どこを変えるべきかが明確です。
00:03:16怠け者ですが、無責任ではありません。この怠惰さを採用することで、Ponytailは
00:03:22コストを47%から77%削減できると主張しています。実際、ベンチマークデータもあります。見てみましょう。
00:03:293つの手法があります：スキルなし、Caveman使用、そしてPonytail使用。
00:03:363つのモデルと5つの日常的なタスク。各セルで10回実行し、その中央値を算出しています。
00:03:43重要なのは「正当性」も確認している点です。コード行数は少ないが動作しないものは失敗とみなされます。
00:03:50ただ少なく書けばいいわけではなく、実際に機能しなければなりません。また興味深い
00:03:56注意点もあります。コストは毎回スキルを送信するシングルショット呼び出しを反映しています。つまり、
00:04:03ベンチマークは、各テストごとに新鮮なAPI呼び出しを送信して動作しています。毎回、
00:04:10プロンプトに完全なPonytailルールセットが含まれているのです。つまり、ベンチマークでは、
00:04:16Ponytailは毎回命令セットを送るコストのペナルティを受けているのです。実生活では、
00:04:22これらの命令はセッションごとに一度支払うだけで済み、その後はキャッシュされます。つまり、47〜77%安いという
00:04:29数字は実際には過小評価です。実際の作業セッションでは、コストの利点はさらに大きくなります。
00:04:36なぜならスキル注入のコストが会話全体を通して償却されるからです。とは言え、
00:04:42最近発表されたColin Eberhardtのブログ投稿には、正当な批判もあります。
00:04:48Ponytailを「YAGNI原則に従え」という3つの単語に置き換えるだけで、
00:04:55結果はPonytailのベンチマークスコアとほぼ完全に一致したというのです。7単語で「YAGNI原則と1行解決策に従え」
00:05:03とすれば、ベンチマークスコアを超えたそうです。ではPonytailは魔法なのか、それともよくパッケージ化された
00:05:11プロンプトに過ぎないのか？正直なところ、それはもっともな疑問です。しかし、私はパッケージングこそが製品だと考えます。
00:05:18正しいルールがコマンド、監査ツール、深層台帳とともに、異なるエージェントに自動的に注入されるのです。それに、
00:05:25Ponytailには他のクールな機能もあります。「YAGNIに従え」をシステムプロンプトに入れるだけでは、
00:05:31Ponytailの監査機能やレビュー機能は使えません。では実際に単純な例でテストしてみましょう。
00:05:37ここに2つのCloud Codeインスタンスを開いています。一方にはPonytailプラグインを
00:05:44ローカルスコープのみにインストールし、もう一方はプラグインを有効にしていないデフォルトのインスタンスです。
00:05:49両方に同じプロンプトを与えます。ユーザーの位置情報を検出し、現在の天気状況や
00:05:56その他の機能を表示する天気ダッシュボードアプリを作れ、という内容です。両方のインスタンスで同じ
00:06:02プロンプトを実行します。唯一の違いは、Ponytailインスタンスでは
00:06:08Ponytailスキルを使うように指示することです。自動で拾ってくれないこともあるので。さて、数分後、
00:06:12Ponytailバージョンは1分以内にタスクを完了しましたが、デフォルトの方はまだ処理中です。
00:06:18また、構築内容の非常に簡潔な概要と、効率化のためにPonytailが何をやらなかったかが表示されています。
00:06:25ご覧の通り、すべてを1つのHTMLファイルにまとめることを選択しています。
00:06:34一方でデフォルトのウィンドウでは、タスク完了に2分30秒かかりました。すでに
00:06:41こちらのバージョンの方が肥大化しているのが分かります。3つの独立したファイルがあり、Pythonサーバーで実行されています。
00:06:48これが悪いというわけではありませんが、最初のバージョンより過剰に設計されています。
00:06:54では動作を見てみましょう。まず、これがPonytailなしのバージョンです。
00:07:00見た目は素晴らしく、UIもきれいで、APIも期待通り情報を取得しています。
00:07:07しかし、求めていた通りに自動で現在地を取得してくれなかったのは少しがっかりです。
00:07:12代わりにデフォルトとしてロンドンを表示しています。次にPonytailバージョンを見てみましょう。
00:07:19開いた瞬間に、現在地の取得を求めてきて、その場所に一致する天気を表示しています。
00:07:25UIはそれほど華やかではなく、アプリも質素ですが、
00:07:33指示に忠実でした。デフォルトバージョンより優れていたのは正直驚きです。
00:07:39最後に、使用量を見てみましょう。確かに、Ponytailバージョンは
00:07:45デフォルトよりも50%安く済みました。コード行数もはるかに少なくなっています。
00:07:52そして今見たように、機能性においてもデフォルトより優れていました。
00:07:58これでPonytailが期待通りに動作し、より簡潔なコードを作成することが証明されました。
00:08:04テストがうまくいったので、さらに興味深い試みをしてみます。
00:08:09効率を最大化するためにCavemanとPonytailを組み合わせたらどうなるでしょうか？
00:08:17新しいディレクトリで両方のプラグインを有効にして、再度同じプロンプトを実行しました。
00:08:22今回も1分以内にタスクが完了し、出力結果もかなり似ていました。
00:08:28機能も同じでした。期待通りです。
00:08:32しかし出力を見ると、Ponytail単体バージョンとそれほど変わりません。Caveman
00:08:37とPonytailの組み合わせは、Ponytail単体よりわずかに高コストになりました。
00:08:44つまり、組み合わせても大きな改善はないということです。
00:08:49ですからCavemanだけで済ませるか、より良い選択肢としてPonytailを使うのがいいでしょう。
00:08:54Cavemanよりも優れているという彼らのベンチマークを信じるなら。
00:08:58というわけで、これがPonytailの概要です。
00:09:02Ponytailスキルを使用してClaudeが出力できた結果には心から感銘を受けました。
00:09:07無駄を削ぎ落としつつ、品質を維持できています。
00:09:13私たちの書くコードの多くは過剰に設計されているのかもしれません。
00:09:19正しく使えば「Less is more（少ないことは、より豊かなこと）」は真実です。
00:09:23今後もClaude Codeの設定にPonytailプラグインを残しておこうと思います。
00:09:29将来のプロジェクトでも使うことになるでしょう。
00:09:31みなさんはPonytailについてどう思いますか？試してみましたか？
00:09:34使ってみたいですか？下のコメント欄で教えてください。
00:09:37このような技術解説が好きなら、
00:09:40動画下のいいねボタンを押して教えてください。
00:09:44チャンネル登録もお忘れなく。
00:09:47BetterStackのAndrusでした。次の動画でお会いしましょう。