Claude skill-creatorの評価パイプライン：発火と出力を改善する¶

対象 / ポイント

対象: ClaudeのカスタムSkillを作成・改善する利用者、開発者

ポイント:

公式skill-creatorは作成だけでなく、テスト、レビュー、改善までを反復する
「発火したか」と「正しい成果物を出したか」は別の評価として扱う
description最適化では、発火すべき例と紛らわしい非対象例を分ける

Skillは SKILL.md を書いただけでは完成しない。必要な依頼で発火し、対象外では発火せず、発火後に期待する成果物を作れることを確かめる必要がある。

Anthropic公式のskill-creatorは、この作成から評価、改善までを反復するSkillとして公開されている。¹

評価対象を3層に分ける¶

層	問い	主な修正先
発火	必要な依頼で選ばれ、不要な依頼では選ばれないか	frontmatterのdescription
実行	手順、分岐、ツール利用が意図どおりか	`SKILL.md`、references、scripts
成果物	必須項目、形式、正確性、使いやすさを満たすか	完了条件、テンプレート、検証コード

この3つを混ぜると、出力の欠落をdescriptionの言い換えで直そうとしたり、発火失敗に本文を追加したりする。本文は発火後にしか読まれないため、層ごとに原因を切り分ける。

現在のskill-creatorの流れ¶

公式Skillは、概ね次のループで動く。¹

目的と対象を定義
→ Skillの構造とSKILL.mdを作成
→ 実際にありそうなテスト依頼を用意
→ Skillを使った実行結果を確認
→ 人間がHTMLレビュー画面でフィードバック
→ 指示、資料、スクリプトを改善
→ 必要ならdescriptionの発火評価を実行
→ 再テスト

最初にテスト文を大量生成するのではなく、Skillの責任範囲を固めてから評価ケースを作る。曖昧な仕様を高精度で評価しても、何を改善すべきか決められない。

出力評価を作る¶

1. 実際の依頼文を使う¶

Skill名を含む人工的な依頼だけでは発火を検証できない。

弱い例: pdf-review Skillを使ってこのPDFをレビューして
良い例: この契約書PDFから当事者、更新日、解約条件を抜き出し、欠落項目を一覧にして

2. 検査可能なアサーションを置く¶

「良いレポート」のような主観だけでなく、結果から判定できる条件を持つ。

必須見出しが3つある
元データの行数と処理件数が一致する
不明値を推測せず 要確認 と表示する
外部送信や元ファイル変更を行わない
検証スクリプトが終了コード0を返す

3. 人間のレビューを残す¶

構文検査に合格しても、読みやすさ、優先順位、判断材料としての有用性は自動評価だけでは足りない。 skill-creatorのレビュー画面では、テスト結果を見ながらケースごとにフィードバックを残し、次の改善へ渡す。¹

descriptionの発火評価¶

descriptionはSkillの主要な発見手段である。最適化用のケースは、should-triggerとshould-not-triggerへ分ける。¹

should-trigger¶

Skill名を言わない典型的な依頼
専門用語を使わない言い換え
入力形式だけを示す依頼
他のSkillと競合しやすい境界ケース

should-not-trigger¶

無関係な例ではなく、キーワードが似た「近いが別の仕事」を置く。

対象Skill: PDFから契約条件を抽出する

発火すべき: 契約書PDFから自動更新と解約通知期限を一覧化して
発火しない: このPDFを1つに結合してファイルサイズを小さくして

後者はPDFという語を共有するが、必要なのは文書操作であり契約分析ではない。この近接負例が、単純なキーワード過適合を検出する。

公式skill-creatorには、テスト集合を学習用と保持用に分け、複数回の発火結果からdescription候補を比較する最適化ループがある。実行にはClaude CLIなど環境側の要件があるため、使えない場合は同じshould／should-not集合を手動レビューへ使う。¹

改善の優先順位¶

評価で失敗したら、次の順に小さく直す。

責任範囲: Skillが担う仕事が広すぎないか
description: 発火場面と対象外が識別できるか
手順: 順序、分岐、停止条件が明確か
資料: 必要な定義や例へ正しく誘導しているか
スクリプト: 反復処理と検証を決定的にできるか
完了条件: Claudeが「終わった」と判断する基準があるか

1件のテストに合わせて具体例を増やし続けると過適合する。複数ケースに共通する失敗だけをSkill本体へ反映し、特殊事情は参照資料か個別入力へ残す。

最小の運用セット¶

Skillと同じリポジトリに、次を置くと変更レビューしやすい。

my-skill/
├── SKILL.md
├── references/
├── scripts/
└── evals/
    ├── trigger-cases.json
    ├── task-cases.json
    └── regression-cases.json

変更時は、構文検査、発火ケース、出力アサーション、過去の回帰ケースを順に実行する。新しい失敗を直したら、その入力を回帰ケースへ追加する。

まとめ¶

Skill評価を発火、実行、成果物の3層へ分ける
実際の依頼文と検査可能な完了条件を使う
should-not-triggerには無関係な例ではなく近接負例を置く
人間のレビューと機械検査を組み合わせる
失敗ケースを回帰評価へ残し、改善を反復する

skill-creatorの価値はSkillを自動生成することだけではない。「動いているように見える手順」を、発火と成果物の両面から検証可能な運用単位へ変える点にある。