skill-creatorとは｜スキルを「作って終わり」にしないツール

Claude Codeには「スキル」という拡張の仕組みがある。SKILL.mdファイルにClaude向けの手順書を書いておくと、特定のタスクに対してClaudeが専門的な振る舞いをするようになる。たとえば「PDFフォームに記入するスキル」「コードレビュースキル」のように、汎用AIを特定業務に特化させる仕組みだ。

skill-creatorは、Anthropic公式のClaude Code用プラグインで、このスキルを作成・テスト・改善・ベンチマークするためのメタスキルだ。つまり「スキルを作るためのスキル」である。

もともとはスキルを対話的に作成するだけのツールだったが、最近の大型アップデートで「スキルを育てる」エンジニアリング機能が追加された。このアップデートにより、スキル開発は「書いて試して直す」という手作業から、テスト・計測・比較を含むエンジニアリングプロセスに進化した。

最新アップデートで追加された5つの機能

1. Eval（テスト実行）

スキルの品質を検証するテスト機能。核となるアイデアは単純で、「スキルを使ったClaudeと、スキルなしのClaudeに、同じお題をやらせて、結果を比較する」というものだ。

2. Benchmark（ベンチマーク）

テストを複数回実行し、統計的に信頼性のあるパフォーマンス指標を計測する機能。合格率・実行時間・トークン使用量をmean ± stddevで出してくれる。

3. Blind Comparison（ブラインド比較）

2つのスキルバージョンの出力を、どちらが改善版か知らない状態で独立エージェントが品質判定するA/Bテスト機能。

4. Improve（自動改善）

フィードバックとベンチマーク結果に基づいて、SKILL.mdを反復的に改善するループ機能。

5. Description Optimization（トリガー精度の最適化）

スキルのdescriptionフィールド（いつスキルが発動するかを決める部分）を自動的に最適化する機能。

Evalの仕組み｜スキルの品質をテストする方法

新機能の中で最も重要なEval機能について、詳しく見ていこう。

テストプロンプトとは何か

テストプロンプトとは、実際のユーザーがそのスキルに対して投げそうなリアルな依頼文のこと。2〜3個程度の、自然な文を用意する。

たとえば「PDF記入スキル」をテストするなら、こんな感じだ。

{
  "skill_name": "pdf-filler",
  "evals": [
    {
      "id": 1,
      "prompt": "このPDFフォームに田中太郎の情報を記入して",
      "expected_output": "全フィールドが正しく記入されたPDF",
      "files": ["evals/files/sample_form.pdf"]
    },
    {
      "id": 2,
      "prompt": "取引先から来た申請書、山田花子の分を埋めて返して",
      "expected_output": "申請書が正しく完成",
      "files": ["evals/files/application.pdf"]
    }
  ]
}

重要なのは、このテストプロンプトは自分で手書きする必要がないということ。skill-creatorがスキルのドラフトを書いた後、「こんなテストケースでどうですか？」と提案してくれる。ユーザーは確認して「OK」か「これも追加して」と言うだけだ。

ただし、テスト用の入力ファイル（PDFなど）が必要なスキルの場合は、ファイル自体はユーザーが用意する必要がある。テキストだけで完結するスキルなら、全部skill-creatorが用意してくれる。

テスト実行の流れ｜スキルあり vs スキルなしの比較

各テストプロンプトに対して、2つのサブエージェント（別々のClaude）が同時に起動される。

  • with_skill（スキルあり）: スキルのSKILL.mdを読み込んだClaudeが同じお題を実行
  • without_skill（スキルなし）: スキルなしの素のClaudeが同じお題を実行

この2つの結果を比べることで、「スキルがあることで品質が上がるのか？」を検証する。

正解の決め方｜定量評価と定性評価の2段階

Evalには定量評価と定性評価の2段階がある。

定量評価: Assertion（アサーション）

アサーションとは、客観的に合否判定できる検証項目のこと。テスト実行中にskill-creatorがドラフトしてくれる。たとえばこんな項目だ。

  • 「出力がPDFファイルである」
  • 「名前フィールドに '田中太郎' が入っている」
  • 「電話番号フィールドが空でない」
  • 「スキルのOCRスクリプトを使用した」

これをGraderエージェント（採点AI）が自動判定する。Graderは実行ログと出力ファイルを実際に検査し、各アサーションに対してPASS/FAILと根拠を出す。

{
  "text": "名前フィールドに '田中太郎' が入っている",
  "passed": true,
  "evidence": "出力PDFの2ページ目、フィールド3に '田中太郎' を確認"
}

さらにGraderはアサーション自体の品質も批評する。「このアサーション、間違った出力でもPASSしちゃうので、電話番号とメールアドレスも一致するか確認した方がいい」といった指摘もしてくれる。弱いアサーションで合格しても意味がないからだ。

定性評価: 人間によるレビュー

ブラウザでEval Viewerが開き、テストケースごとにスキルありの出力、スキルなしの出力、自動採点結果を見比べて、人間がフィードバックを書く。

文章のスタイルやデザインの良し悪しなど、主観的な品質はアサーションにせず、この人間レビューで判断するのが推奨されている。

Eval Viewerの使い方

Eval Viewerには「Outputs」と「Benchmark」の2つのタブがある。

Outputsタブでは、テストケースを1つずつ見ていく。プロンプト、出力ファイル、自動採点結果が表示され、フィードバック欄に自由にコメントを書ける。

Benchmarkタブでは、統計情報が表示される。スキルあり/なしの合格率、実行時間、トークン使用量の比較だ。

お知らせ

私たちAI駆動開発協会は、法人向けの「AI駆動開発研修」を行っています。
実践スキルからリスク管理までを学び、エンジニアの生産性が劇的に向上します。
助成金活用で1名あたり実質14,900円〜。全額返金保証付き。まずは無料でお問い合わせください。

法人研修の詳細を見る

2つのテストモードの違い｜新規作成 vs 既存改善

Evalには「新規スキルの検証」と「既存スキルの改善」の2つの使い方がある。最大の違いは、何と比較するか（ベースライン）だ。

ケース テスト対象 ベースライン（比較対象）
新規スキル作成 スキルあり スキルなし（素のClaude）
既存スキル改善 改善版スキル 改善前のスキル（スナップショット）

モードの切り替え方

明示的な「モード切り替えコマンド」は存在しない。skill-creatorが文脈から自動で判断する仕組みだ。

具体的には、skill-creatorに渡す情報で決まる。

  • 「〇〇するスキルを作って」 → 新規スキルだと判断 → ベースラインは「スキルなし」
  • 「このスキルをテストして」（既存のSKILL.mdがある状態）→ 既存スキル改善だと判断 → ベースラインは「改善前のスキル」

既存スキルの改善モードでは以下の手順が自動で実行される。

  1. 編集前にスキルのコピーを取る（cp -r <skill-path> <workspace>/skill-snapshot/）
  2. SKILL.mdを改善する
  3. 改善版をスナップショット（旧版）と並行実行して比較する

つまり、「改善前 vs 改善後」の比較は、ユーザーが意識して切り替えるのではなく、既存スキルに対してEvalを実行すれば自動的にそうなる。

既存スキルを改善する具体的な手順

実際に既存スキルを改善したい場合、以下のように進める。

ステップ1: 既存スキルに対してEvalを依頼する

このスキルのテストを実行して

skill-creatorは既存のSKILL.mdを見つけると、まずスナップショットを保存してからテストを実行する。

ステップ2: テスト結果を確認する

Eval Viewerがブラウザで開く。ここでは「改善版の出力」と「旧版の出力」が並んで表示される。新規スキルのときは「スキルありの出力」と「スキルなしの出力」だったが、改善モードでは「old_skill」ディレクトリに旧版の結果が保存される。

ステップ3: フィードバックを書いて改善を繰り返す

ブラウザで各テストケースのフィードバックを書き、skill-creatorに「フィードバック書いたよ」と伝える。skill-creatorがSKILL.mdを改善し、新しいイテレーションで再テストする。

イテレーションループの全体像

改善前スキル（スナップショット保存）
    │
    ├── iteration-1/  改善版v1 vs 旧版
    │     → Eval Viewerで人間がレビュー → フィードバック
    │
    ├── iteration-2/  改善版v2 vs 旧版 or v1
    │     → Eval Viewerで人間がレビュー → フィードバック
    │
    └── iteration-3/  改善版v3 vs ...
          → 満足するまで繰り返し

ベースラインを「最初の旧版」にするか「前のイテレーション」にするかも選べる。新しいイテレーションが回るたびに、前回との差分も確認できる（Eval Viewerに「Previous Output」として前のイテレーションの出力が表示される）。

さらに厳密に比較したい場合｜Blind Comparison

通常のEvalでは、skill-creatorが「こちらが改善版、こちらが旧版」と知った状態で実行する。より厳密に比較したい場合はBlind Comparison（盲検比較）を使える。

「2つのバージョンをブラインド比較して」と依頼すると、Comparatorエージェントが2つの出力を「A」「B」としてラベルを隠した状態で受け取る。内容の正確性・構成・使いやすさなどを1〜5点で独立に採点し、どちらが優れているかを判定する。どちらが改善版かを知らないので、バイアスのない判定ができる。

さらにAnalyzerエージェントが「なぜ勝った方が良かったのか」を分析し、具体的な改善提案を出す。たとえば「勝った方は明確なステップバイステップの指示に従っていたが、負けた方は曖昧な指示のせいで3つの異なる方法を試して時間を浪費した」のように、原因と対策をセットで示してくれる。

スキルを育てる改善ループの設計思想

ここまでEvalの使い方を見てきた。ここからは、改善ループを回すときに知っておきたい設計思想を紹介する。

フィードバックから一般化する

テストケースは2〜3個しかないが、スキルは何百万回も使われる可能性がある。特定のテストケースにだけ合うような修正（過学習）ではなく、そこから一般化したルールを抽出することが重要だ。

プロンプトをスリムに保つ

効いていない指示は削除する。テスト実行のログを読んで、スキルのせいでClaudeが無駄な作業をしている部分があれば、その指示を取り除く。

「なぜ」を説明する

「ALWAYS」「NEVER」と大文字で書くより、なぜそうすべきかを説明した方が効果的だ。今のLLMは理由を理解できるので、理由を伝えれば柔軟に対応してくれる。

繰り返しパターンをスクリプト化する

テスト実行のログを見て、全テストケースで同じヘルパースクリプトを書いているなら、それはスキルにバンドルすべきスクリプトだ。毎回再発明させる必要はない。

skill-creatorの使い方｜対話的なセッションで回すループ

skill-creatorは、cronなどで自動実行するものではない。人間が対話的に回すループとして設計されている。

典型的な使い方はこうだ。

  1. 「このスキルをテストして」とskill-creatorに依頼
  2. skill-creatorがテストを実行（数分待つ）
  3. ブラウザにEval Viewerが開く
  4. 人間が出力を見てフィードバックを書く
  5. 「フィードバック書いたよ」と伝える
  6. skill-creatorがfeedback.jsonを読んでスキルを改善
  7. 再テスト → またViewerが開く → 人間が見る → ...
  8. 「OK、これで良い」で終了

1セッションで2〜3イテレーション回して、合計30分〜1時間程度で1つのスキルを仕上げる、というのが想定される使い方だ。

終了条件は3つ。

  • ユーザーが満足した
  • フィードバックが全部空（何も問題なし）
  • これ以上改善が進まない

よく使うコマンド一覧

やりたいこと プロンプト例
スキルを新規作成 /skill-creator または「〇〇するスキルを作って」
既存スキルをテスト 「このスキルのテストを実行して」
ベンチマーク実行 「このスキルを10回実行してバリアンス分析して」
A/Bテスト 「2つのバージョンをブラインド比較して」
Description最適化 「スキルのトリガー精度を最適化して」

ベンチマーク｜統計的に信頼できる数値で計測する

Evalの発展形がBenchmark機能だ。テストを複数回実行し、統計的に信頼性のある数値を出す。

計測される指標は以下の3つ。

指標 内容
pass_rate アサーション合格率（mean ± stddev）
time_seconds 実行時間
tokens トークン使用量

さらにAnalyzerエージェントが、集計では見えないパターンも分析する。

  • 両方で100%パスするアサーション（スキルの価値を示せていない）
  • 分散が高いeval（フレーキーな可能性あり）
  • スキルありで遅くなるが正確になるトレードオフ

Description Optimization｜スキルの発動精度を上げる

スキルが期待通りに発動するかどうかは、SKILL.mdのdescriptionフィールドにかかっている。この最適化を自動で行う機能もある。

最適化の流れ

  1. トリガー評価クエリの生成: 「発火すべきクエリ」8〜10個と「発火すべきでないクエリ」8〜10個を自動生成
  2. ユーザーレビュー: HTMLテンプレートでクエリを確認・編集
  3. 自動最適化ループ: 60%学習 / 40%テスト分割で、最大5イテレーション回して最適なdescriptionを選出

過学習を防ぐために、テストスコア（学習に使っていないデータ）で最良のdescriptionを選ぶ仕組みになっている。

重要なのは、単純すぎるクエリはテストにならないということ。「PDFを読んで」のような簡単な依頼はスキルなしでも処理できるため、スキルが発火しない。テストクエリは、Claudeがスキルの助けを必要とするような複雑で具体的なものにする必要がある。

skill-creatorを支える3つのサブエージェント

skill-creatorの裏側では、3つの専門エージェントが動いている。

Grader（採点エージェント）

アサーションの合否を判定するエージェント。実行ログと出力ファイルを読み、各アサーションにPASS/FAILと根拠を付ける。さらにアサーション自体の品質も批評する。「このアサーション、間違った出力でもPASSするから弱い」といった指摘をしてくれる。

Comparator（比較エージェント）

ブラインドA/B比較を行うエージェント。2つの出力を「A」「B」としてラベルを隠した状態で受け取り、内容の正確性・構成・ユーザビリティなどを独立に採点する。どちらがスキルありかを知らないので、バイアスのない判定ができる。

Analyzer（分析エージェント）

比較結果の勝因分析と改善提案を行うエージェント。「勝った方はステップバイステップで手順を踏んでいたが、負けた方は曖昧な指示に振り回されていた」のように、なぜ差が出たかを分析し、具体的な改善案を出す。

まとめ｜スキル開発が「感覚ベース」から「データ駆動」へ

skill-creatorのアップデートが意味するのは、スキル開発のパラダイムシフトだ。

これまでは「書いて、手で試して、なんとなく直す」しかなかった。今は「テストして、数値で比較して、フィードバックに基づいて改善する」ことができる。

ソフトウェアエンジニアリングでは当たり前のテスト駆動開発やCI/CDの考え方が、プロンプトエンジニアリングの世界にも本格的に入ってきた形だ。

スキルを作ったら、ぜひEvalを回してみてほしい。「なんとなく良さそう」を「数値的に良くなった」に変えられる。

この記事を書いた人
せお丸（田中淳介）
理事長

せお丸（田中淳介）

AI駆動開発協会 代表理事 サイバーフリークス株式会社 代表取締役

  • 著書：「AI駆動開発入門」 ※2026年出版予定
  • テック系Youtuber「せお丸」として活動（チャンネル登録者６万人）
  • システム開発会社 代表取締役
  • エンジニア歴20年以上
YouTubeYouTubeXX (Twitter)
← ブログ一覧に戻る