skill-creator新版解説 - 評価パイプラインで変わるSkill開発¶

対象 / ポイント

対象: Claude Code / Claude.aiでSkillを開発・運用しているエンジニア。前回のskill-creator完全ガイドを読んだ読者を想定。

ポイント:

skill-creatorが「作成→評価→改善→ベンチマーク」のフルサイクルツールへ進化した
サブエージェント並列実行・ブラウザベースレビューア・トリガー最適化ループが追加された
背景には「未検証のコンテキストは無価値」という業界的な問題意識がある

何が変わったか：旧版と新版の構造比較¶

一言で言えば、旧版は「Skillを書く支援」が中心だった。新版は「Skillが本当に効いているかを検証しながら改善する支援」まで含む。

前回記事（2026年1月時点）で紹介したskill-creatorは、対話形式でSKILL.mdとディレクトリ構造を自動生成するツールだった。補助スクリプトはinit_skill.py（初期化）・quick_validate.py（検証）・package_skill.py（パッケージング）の3本¹。生成後の品質確認は、手動テストとユーザー自身の判断に委ねられていた。

新版では、この構造が根本から変わっている。skill-creatorの役割が「Skillを作る」から「Skillを作り、テストし、計測し、改善する」へ拡張された。

観点	旧版（2026年1月）	新版（2026年3月）
動作モード	作成のみ	Create / Eval / Improve / Benchmark の4モード
テスト実行	手動	サブエージェントで with-skill / baseline を並列実行
評価方法	ユーザーの主観	定量（アサーション自動判定）＋定性（ブラウザビューア）
専門エージェント	なし	Grader / Comparator / Analyzer の3種⁸
トリガー最適化	なし	Description Optimization（train/test分割、最大5イテレーション）
スクリプト数	3本	8本（`aggregate_benchmark.py`, `run_loop.py`, `run_eval.py` 等）
マルチ環境対応	Claude Codeのみ想定	Claude Code / Claude.ai / Cowork それぞれの分岐を明記

特に注目すべきは、eval-viewerの存在である。eval-viewer/generate_review.pyが生成するHTMLビューアでは、テストケースごとの出力をブラウザ上で確認し、フィードバックを入力できる。前イテレーションの出力との比較表示、ベンチマークタブでのpass rate・トークン消費量・実行時間の定量比較も統合されている。

なぜ変わったか：未検証コンテキスト問題¶

この進化には業界的な背景がある。

ETH Zurichの研究（2026年2月公開）²は、開発者が書いたコンテキストファイルがエージェントのタスク完了率をわずか4%しか改善しなかったと報告した。LLMが自動生成したコンテキストに至っては、逆に3%悪化させ、どちらもコストは20%以上増加した。

この結果から導かれる教訓は「コンテキストを書くな」ではない。「検証されていないコンテキストは役に立たない」という点にある。Skillも同じ構造の問題を抱えている。SKILL.mdを書いて「動いているように見える」だけでは、本当にSkillが価値を出しているのか分からない。

Anthropicがskill-creatorにevalパイプラインを組み込んだ動機は公式には明言されていない。ただし、Skillの数が増え、エコシステムが広がる中で、品質の計測手段がないままでは「Skillを使ったら逆に悪くなった」という事態が避けられない。この問題意識と、上記の研究が示した課題は整合的である。

新版の設計思想を読む¶

SKILL.md本文には、evalの手順だけでなく、Skill改善の考え方が詳しく書かれている。従来のskill-creatorにはなかった設計哲学が現れている。

「WHYを説明せよ」原則¶

新版では、SkillにALWAYSやNEVERを大文字で書き連ねることを明確に戒めている。代わりに推奨されるのは、なぜその指示が重要なのかを説明するアプローチである。理由が伝われば、LLMは指示を超えた適切な判断ができる。硬直的なルールの羅列は、想定外のケースで破綻する。

「汎化せよ、過学習するな」原則¶

テストケースは数例しか使わないが、Skillは何百万回も実行される可能性がある。テスト結果に過剰に最適化すると、特定のケースでしか動かないSkillになる。新版のSKILL.mdは、改善時に「そのフィードバックは一般化できるか？」を常に問うよう促している。

Description Optimizationの過学習防止¶

トリガー精度の最適化ループでも、eval setをtrain 60% / test 40%に分割し、testスコアで最良のdescriptionを選ぶ設計になっている。ソフトウェアテストにおけるtrain/test分割の考え方が、そのままSkill開発に輸入された形である。

これらは技術的な手順ではなく、Skillをソフトウェアとして扱うという思想の表明と言える。

evalが駆動する構造改善：scripts/の設計パターン¶

ここまでの3原則はSkillの「書き方」に関するものだった。もう1つ、新版が示している設計思想がある。evalループはSkillの品質を測るだけでなく、Skillの構造そのものを改善する装置でもあるという点である。

skill-creatorは、Skillのディレクトリ構造としてscripts/を第一級のリソースに位置づけている³。

skill-name/
├── SKILL.md          ← LLMが読んで判断する層
└── scripts/          ← コンテキストに載せず実行できる決定論的な層

このscripts/には重要な特性がある。コンテキストウィンドウに読み込まなくても実行できる⁴。つまりSKILL.mdの推奨上限（500行）を消費せずに、確実に同じ結果を返す処理を分離できる。LLMの判断ゆらぎをバイパスして「毎回必ず同じことをする」保証層として機能する。

では、何をscripts/に切り出すべきかをどう判断するのか。ここでevalループが効いてくる。

新版のSKILL.mdは、テスト実行後にトランスクリプト（実行ログ）を読むよう指示している。もし複数のテストケースで、サブエージェントが全員同じようなヘルパースクリプトを独自に書いていたら、それはSkillにバンドルすべきサインだと明記されている⁵。一度scripts/に入れれば、将来のすべての呼び出しで再発明が不要になる。

この設計が意味するのは、evalの役割が「Skillが動くかどうかの検証」にとどまらないということである。evalのトランスクリプトを観察することで「Skillの中で何を決定論的に保証すべきか」が浮かび上がる。品質検証と構造改善が同じループの中で回る仕組みになっている。

整理すると、Skillの信頼性は二層構造で設計される。

SKILL.md（LLM層）：文脈に応じた判断、柔軟な対応。WHYの理解に基づく適応的な振る舞い
scripts/（決定論層）：毎回同じ結果を返す処理。フォーマット変換、バリデーション、定型的なファイル操作など

evalパイプラインは、この二層の境界線をどこに引くべきかを、実データから発見するための仕組みでもある。

実務インパクト：誰に・どう効くか¶

新版の恩恵は、利用環境によって異なる。

Claude Code環境が最も恩恵を受ける。サブエージェントによる並列テスト、ブラウザビューア、Description Optimizationのすべてが利用可能。チームでSkillを開発・配布するケースでは、evalの仕組みがそのまま品質ゲートになる。

Claude.ai環境では制約がある。サブエージェントが使えないため、テストは逐次実行になり、ベースライン比較やブラインドA/B比較はスキップされる。ただし、テストケースの定義と定性レビューのフローは使えるので、手動テストよりは構造化された改善ループが回せる。

Cowork環境はサブエージェントが使えるが、ブラウザ表示ができない。eval-viewerはスタティックHTML出力（--staticオプション）で対応する。

環境	並列テスト	ブラウザビューア	Description最適化	ブラインド比較
Claude Code	対応	対応	対応	対応
Claude.ai	非対応	非対応	非対応	非対応
Cowork	対応	静的HTML	対応	対応

なお、新版は方向性として重要だが、実装面にはまだ荒さも残る。たとえばrun_eval.pyがclaude -p経由でSkillをトリガーできず評価が0%になる問題がGitHub Issueで報告されている⁶。一方、Description OptimizerがANTHROPIC_API_KEYを要求する問題はclaude -pサブプロセスへの移行で解消済み⁷であり、周辺ツールは活発に修正が進んでいる状況である。

既存Skillの更新にも対応している。skill-creatorに既存Skillを渡すと、スナップショットを取って旧版をベースラインとした比較テストが実行される。「前のバージョンより良くなったか？」を定量的に確認できる仕組みである。

まとめ¶

skill-creatorの新版は、Skill開発に「計測と改善のループ」を持ち込んだ。作るだけでなく、テストし、計測し、最適化する。

前回記事で紹介した基本構造（SKILL.md・ディレクトリ構成・Progressive Disclosure・設計原則）は変わっていない。新版が加えたのは、その上に乗る品質保証のレイヤーである。

Skillが「書いたら終わり」のプロンプトから、テスト可能なソフトウェア成果物へ——この転換は、AIエージェント開発全体のプラクティスにも波及する可能性がある。