日付入力ひとつに、専用部品はいらない

AIにコードを書かせると、想像以上に手が早い。画面に日付入力を足してほしい、と頼めば、コンポーネントを作り、ライブラリを探し、CSSを書き、将来の拡張まで見越した構造を用意してくれる。

問題は、その多くが本当に必要とは限らないことだ。

日付を入力したいだけなら、ブラウザにはもともと <input type="date"> がある。色を選ばせたいだけなら <input type="color"> がある。ファイルを選ばせるだけなら <input type="file"> がある。それで十分な場面でも、AIはしばしば「立派な部品」を作りにいく。

この現象を、AIの賢さ不足だけで片付けると見誤る。むしろAIは、こちらが止めなければ、頼まれたことを広げて解こうとする。だからAI開発で本当に必要になるのは、より強いモデルを使うことだけではない。何を作らないかを決める判断基準である。

「短いコード」は目的ではない

GitHubに公開されている Ponytail というプロジェクトがある。AIエージェントに対して、過剰な実装を避けるためのルールを与えるプラグインだ。作者は、Claude Code を使った実験で、Ponytailを入れた場合にコード量、トークン、コスト、時間が下がったと報告している。

ただし、この数字はそのまま一般法則として受け取るべきではない。検証は公開されているが、作者側のベンチマークであり、モデル、タスク、実行環境も限られている。重要なのは削減率そのものではなく、Ponytailが示している判断順序だ。

Ponytailの考え方は、乱暴に言えばこうである。

まず、それは本当に必要か。すでにコードベースにあるものを使えないか。標準ライブラリで済まないか。ブラウザやOSの標準機能で済まないか。すでに入っている依存ライブラリで済まないか。どうしても必要なときだけ、最小限の実装を書く。

これは「とにかく短く書け」という話ではない。入力値の検証、エラー処理、セキュリティ、アクセシビリティは削ってはいけない。短くなるのは、必要なものだけを残した結果であって、短さそのものが目的ではない。

AIは「親切すぎる実装」をしやすい

人間の開発者であれば、日付入力を見て「ブラウザ標準でいい」と判断する場面がある。だがAIは、依頼を「ちゃんと作る」方向に解釈しやすい。特に、プロジェクトにReactやUIライブラリが入っていると、既存の道具を組み合わせて立派な部品を作ることが自然な選択に見える。

この親切さは、初期にはありがたい。何もないところから叩き台が出る。考慮漏れも補ってくれる。だが、業務システムや社内ツールでは、親切さがそのまま負債になることがある。

たとえば、単純な入力欄のために専用コンポーネントを作る。小さな表示変更のために状態管理を増やす。将来使うかもしれない設定を先回りして足す。ひとつひとつは悪く見えない。だが数が重なると、変更箇所が増え、読むべきコードが増え、誰も全体を把握しにくくなる。

AIが作ったコードは、動いた瞬間が完成ではない。半年後に直せるか。別の人が読めるか。業務の変更に合わせて安全に触れるか。そこまで含めて、初めて実装の価値が決まる。

必要なのは、AIに渡す「開発判断のはしご」

Ponytailから学べるのは、プラグインそのものより、判断の順番である。

第一に、作らないで済むなら作らない。これは怠慢ではない。不要なコードは、バグも保守も生まない。何もしないことが最もよい実装になる場面はある。

第二に、既存のものを使う。すでにコードベースにある部品や関数を再利用できるなら、同じようなものをもう一つ作らない。AIは新しく書くのが得意だが、現場に必要なのは、既存の流れに沿って変えることである。

第三に、標準機能を使う。ブラウザ、OS、言語、フレームワークには、地味だが枯れた機能がある。派手なライブラリより、標準機能の方が壊れにくく、次の担当者にも伝わりやすいことが多い。

第四に、それでも足りないときだけ作る。その場合も、作る範囲を絞る。将来の可能性をすべて受け止める抽象化ではなく、今の業務に必要な最小単位を置く。

このはしごは、AIだけでなく人間にも効く。むしろ人間側がこの順番を持っていないと、AIに対して良い指示もレビューもできない。

小さく作ることと、雑に作ることは違う

ここで注意したいのは、「小さく作る」を「確認を省く」と混同しないことだ。Ponytailのベンチマークでも、単に「YAGNIで一行を好め」とだけ指示した場合、安全性の確認が一部落ちたとされている。YAGNIとは、将来必要かもしれない機能を先回りして作らないという考え方である。

業務システムでは、この違いが大きい。個人情報、予約、決済、権限、外部送信、データ削除。こうした領域では、コードを短くすることより、確認すべき境界を残すことが優先される。

小さく作るとは、守るべきものを残したまま、余計なものを削ることだ。雑に作るとは、守るべきものまで削ることだ。この二つを分ける判断がなければ、AI開発は速くなるほど危うくなる。

経営と業務に効くのは「実装量の削減」だけではない

Ponytailのような考え方は、開発者だけの話に見えるかもしれない。だが、実際には経営や業務設計にも関係する。

AIを入れると、多くの会社で「できること」が急に増える。議事録を要約する。問い合わせに答える。資料を作る。コードを書く。業務フローを提案する。できることが増えるほど、現場は試したくなる。

しかし、できることを全部やると、仕組みはすぐに散らかる。似たような自動化が増え、どれが正本かわからなくなり、誰が責任を持つのかも曖昧になる。AI導入の初期に必要なのは、機能を増やすことより、判断の置き場所を決めることだ。

どの業務は自動化しないのか。どの判断は人間が握るのか。どの情報を正本にするのか。どこまでを標準機能で済ませ、どこから専用の仕組みにするのか。こうした問いを飛ばしてAIを使うと、便利さの量だけ運用が重くなる。

導入するなら、まずレビュー観点として使う

Ponytailはプラグインとして導入できる。ただし、ライフサイクルhookを使うため、エージェントの開始時やプロンプト送信時にNode.jsのスクリプトが動く。こうした仕組みは便利だが、導入前に中身と権限を確認する必要がある。

そのため、最初から常時ONのプラグインとして入れるより、まずはレビュー観点として取り入れるのがよい。

この実装は本当に必要か。既存コードで済まないか。標準機能で済まないか。依存ライブラリを増やす必要があるか。将来のためと言いながら、今いらない抽象化を作っていないか。逆に、短くしようとして入力検証や権限確認を削っていないか。

この問いを、AIに作らせた後のレビューに入れるだけでも効果はある。AIに任せる領域が増えるほど、レビューは「動くかどうか」だけでは足りない。「作りすぎていないか」「削りすぎていないか」を見る必要がある。

AI開発の成熟度は、作れる量ではなく、止められる力に出る

AIを使えば、以前より多くのコード、多くの資料、多くの自動化を作れる。だが、組織に残る価値は、作った量では決まらない。むしろ、不要なものを作らずに済ませた判断、標準機能で済ませた判断、危ない簡略化を止めた判断の方が、長く効く。

Ponytailが面白いのは、AI開発の生産性を「速くたくさん作る」方向ではなく、「必要なものだけを安全に作る」方向から捉えている点にある。

AIに任せるほど、人間の仕事は減るのではない。人間が握るべき仕事が変わる。手を動かす量は減っても、何を作らないか、どこを削ってはいけないか、どこまで標準で済ませるかを決める責任は残る。

AI開発の本当の成熟度は、作れる量ではなく、止められる力に出る。