AIの「武器」を手入れするのは誰か
少し前まで、AIへの指示は一回使い切りの「プロンプト」だった。しかし現在、Claude Codeをはじめとする自律型エージェントの台頭により、状況は一変した。彼らには再利用可能な「Skill（スキル）」という武器を持たせることができる。特定のタスクをこなすための手順書や、環境にアクセスするためのツール群だ。
当初は数個のSkillを書いて満足していた開発者たちも、その数が20、50と増えていくにつれ、ある奇妙な現実に直面することになる。AIが効率よく働くために、人間のプログラマーがひたすらマークダウン形式のSkillファイルを微調整し、デバッグを繰り返しているのだ。AIを自動化するために人間の手作業が爆発的に増えるという、皮肉な逆転現象である。
Karpathyの思想を「プロンプト」に持ち込む
この泥臭いメンテナンス作業に、システム工学的なメスを入れたのが「Darwin.skill」だ。名前の通り、エージェントのSkillを「進化」させるためのフレームワークである。
設計の根底にあるのは、Andrej Karpathyが提唱した「autoresearch」の思想だ。AIを用いてコードの変更案を自律的に生成し、評価指標が向上した場合のみその変更を保持する。Darwin.skillは、この自律的な実験ループを、モデルの学習やアプリケーションコードの最適化ではなく、「エージェントのSkill最適化」にそのまま持ち込んだ。
彼らが採用したアプローチは実に合理的だ。
| autoresearchの概念 | Darwin.skillにおける実装 | その意図 |
|---|---|---|
val_bpb (評価指標) |
8つの次元による加重スコア(100点満点) | 構造的な美しさだけでなく、実測による効果を定量化する |
git ratchet (ラチェット機構) |
スコア向上時のみコミット、他はリバート | 局所的な改悪を防ぎ、性能のベースラインを不可逆的に押し上げる |
構造と実測の「二重評価」がもたらすもの
従来のSkillレビューやプロンプトのLintツールは、フォーマットが正しいか、ステップに番号が振られているかといった「純粋な構造」しかチェックできなかった。しかし、文法的に完璧な指示書でも、エージェントが実行すると意図しない結果を招くことは往々にしてある。
Darwin.skillは、静的分析（60点）に加えて、実際にテストプロンプトを走らせての「実測評価（40点）」を組み込んでいる。いくら記述が美しくても、実戦で使えなければスコアは無慈悲に下がる。さらに、評価を行うのは改善案を作成したのとは別の「子エージェント」だ。自分で書いて自分で採点するという、AIにありがちな評価の甘さを構造的に排除している。
そしてスコアが下がれば、Gitの機能を使って即座に変更がリバートされる。この「歯車が前にしか進まない」ラチェット機構により、Skillの質は時間経過とともに必ず向上するか、少なくとも現状維持が保証されるのだ。
完全自律を拒む「Human-in-the-loop」の妙
技術的に見れば、このループを完全に自動化し、夜間に数百個のSkillを勝手に進化させることも可能だったはずだ。しかし、システムはあえて「人が介在する（Human-in-the-loop）」設計を選んでいる。1つのSkillの最適化が完了するごとに処理は一時停止し、差分とスコアの変化を提示して人間の承認を待つ。
これは妥協ではない。プロンプトやSkillの「良し悪し」は、機械学習のLoss関数のようには単純化できないからだ。最終的なアウトプットの手触りや、予期せぬ副作用の有無は、人間の直感によるジャッジが不可欠であることを、現場をよく知る開発者ならではのバランス感覚で見抜いている。
進化の仕組み自体を創る時代へ
AIの振る舞いを人間が手書きでチューニングする時代は、おそらくそう長くは続かない。「より良いSkill」を人間が作るのではなく、「Skillが勝手に良くなっていく仕組み」を作る。ダーウィンの名を冠したこの小さなリポジトリは、私たちが次に注力すべきエンジニアリングの主戦場を、静かに示唆している。
参考リポジトリ: alchaincyf/darwin-skill