わかる。Agent Skillsで「属人化」がやっと解消できる時代になった。 今まで優秀なエンジニアの頭の中にしかなかったノウハウ。ドキュメント化しても読まれない。読まれても伝わらない。結局その人に聞くしかない。 Skillsはこれを変えている。手順書ではなく、エージェントが実行できる形式で専門知識を記述する。書いた瞬間から組織の資産になる。 Cursor、Claude Code、GitHub Copilot、Codexが既に採用。標準フォーマットになった。 今後、業務知識の大半はSkillsとして記述されるようになる。 ただし、Skillsの書き方はまだ発展途上にある。 Anthropicの公式ベストプラクティスを見ると、テスト方法について「2つのClaude Codeインスタンスを用意して、最低3つのシナリオで検証する」と書いてある。 考え方としては正しい。Evalsを先に作れ、というのも正しい。 でも具体的な評価基準や自動化の方法は提示されていない。Skillが期待通りに動いているかどうか、定量的に測る仕組みがまだ確立されていない。 組織の資産として蓄積するなら、品質保証の仕組みが必要になる。 ここで注目すべき研究が2つある。GEPAとCAPE。 GEPAはGenetic-Paretoの略。DSPyの公式オプティマイザーとして統合されている。 従来のプロンプト最適化は試行錯誤の繰り返しだった。GEPAは自然言語によるリフレクションを使う。エージェントの実行ログ、ツール出力、エラーメッセージをテキストとして分析し、何が問題だったかを言語化してから改善案を生成する。 結果として、強化学習ベースの手法と比較して35分の1のロールアウトで10から20パーセント高い性能を達成する。 Skillsの指示文を自動で進化させる仕組みとして使える。 CAPEはCapability Achievement via Policy Execution。Superficial Labsが発表した研究で、アプローチが根本的に異なる。 GEPAがプロンプトレイヤーで最適化するのに対し、CAPEは一段深いレイヤーで動く。 核心は「検証可能な述語」という概念。Skillの曖昧な指示を、機械的にチェック可能な条件に変換する。 例えばPDF処理のSkillを考える。「pdfplumberでテキストを抽出する」という指示は人間には分かるが、成功したかどうかをどう判定する。 CAPEはこれを述語に変換する。PDFヘッダーで始まるか。パーサーが成功するか。フォームフィールドの不一致がゼロか。 全て推論時に自動でチェックできる。違反があれば検出され、修正され、その修正結果が次の学習データになる。 面白いのは、主観的に見える要件もCAPEで扱えること。 「AIっぽいデザインを避ける」という指示は曖昧に聞こえる。でも文脈を固定すれば客観的な条件に分解できる。 border-radiusのバリエーションが3種類以上あるか。色数が4から12の範囲か。フォントファミリーが3つ以下か。コントラスト比が4.5以上か。 CAPEの研究では、デプロイ時の問題の89パーセントが客観的に検証可能だったと報告されている。 Superficial LabsはAnthropicの公式16 Skillsを全てCAPE仕様に変換して公開している。どのSkillがどの述語に対応するか、仮定は何か、全て文書化されている。 重要なのは、GEPAとCAPEが競合ではなく補完関係にあること。 GEPAはプロンプトを進化させる。でも進化の良し悪しを判定する関数が必要になる。 CAPEのポリシーをGEPAの検証関数として使えば、プロンプト最適化を客観的な基準で評価できる。 レイヤーが違うだけで、同じ問題を解いている。 実装の選択肢も整いつつある。 GEPAはDSPy経由でPythonから直接使える。dspy.GEPAとして公式サポートされている。 TypeScript派にはAxという選択肢もある。 Claude Code特化ならmodaicがDSPyスキャフォールドを公開している。MCPサーバー連携、ツール実行、フックまでフル機能をDSPyのシグネチャインターフェースで扱える。 Skillsは属人化を解消する最良の手段になりつつある。 でも資産として蓄積するなら、品質を担保する仕組みが要る。テストのないコードが負債になるように、Evalsのないスキルも負債になりうる。 GEPAでSkillsを自動改善する。CAPEで検証可能な仕様に変換する。 書き方の標準化はこれから。今のうちにEvalsの設計パターンを押さえておくと、後で差がつく。 Skillsを書いている人、Evalsどうしていますか？