はじめに
Claude Codeのスキルを自作して使っているのですが、「このスキル、本当に効いているのか？」というのが正直なところ気になっていました。体感では良さそうだけど、スキルなしの場合と比べてどう違うのか、定量的に測ったことはなかったので。
そんな中、skill-creatorプラグインに評価機構が追加されたらしいので、自作のブログ執筆スキルを対象に試してみました。
skill-creator の評価機構とは
2026年3月にskill-creatorへ追加された機能で、スキルの品質を定量的に測定できます。流れとしては以下のようになっています。
- テストケース（プロンプト）を用意する
- スキルあり／なしの両方でサブエージェントを並列実行する
- 定量アサーション（チェック項目）で自動採点する
- ブラウザのビューアーで出力を読み比べてフィードバックを書く
- フィードバックをもとにスキルを改善する
個人的に面白いなと思ったのは、スキルあり／なしの比較をベースラインとして自動で取ってくれるところです。「スキルを入れたことで本当に良くなったのか」を客観的に確認できます。
実際に試してみた
対象にしたのは自作のブログ執筆スキルです。このブログの記事を /blog [トピック] で書けるようにしたもので、文体ルールやセクション構成、校正手順などを定義しています。
テストケースの設計
以下の3つのトピックをテストケースとして用意しました。
- 「Bun のテストランナーを試してみた話」
- 「GitHub Actions の composite action で CI を整理した話」
- 「Zod でバリデーションを型安全にする話」
それぞれについてスキルあり／なしの2パターン、計6つのサブエージェントが並列で記事を生成します。6つが同時に走るので、待ち時間はだいたい2分弱でした。
定量アサーション
採点に使ったアサーションは以下の8項目です。
| # | チェック項目 | 内容 |
|---|---|---|
| 1 | フロントマター | title, description, emoji, pubDate が全て含まれているか |
| 2 | です/ます調 | 本文の文体が統一されているか |
| 3 | セクション構成 | 「はじめに」と「最後に」が存在するか |
| 4 | コードブロック | すべてのコードブロックに言語指定があるか |
| 5 | リンク | 主要な技術名に公式サイトへのリンクがあるか |
| 6 | 避けるべき表現 | 「させていただきます」「すべきです」等が使われていないか |
| 7 | スキル指定表現 | 「〜してみました」「印象」等の著者らしい表現が使われているか |
| 8 | 記事の長さ | 2000文字以上あるか |
これらをPythonスクリプトで自動チェックしています。7番（スキル指定表現）はスキルありの場合のみ適用される項目です。
ブラウザビューアーでのレビュー
採点後、ビューアーを生成するとブラウザが立ち上がります。
Outputsタブでは各テストケースの出力を1件ずつ確認でき、下部のテキストボックスにフィードバックを書けます。矢印キーで前後のテストケースに移動できるので、スキルあり／なしの出力を交互に見比べるのも簡単です。
正直この体験が良すぎました。ターミナルの中で完結させずブラウザに飛ばすという判断が上手い。Markdownの記事をターミナルで読み比べるのは厳しいですが、ブラウザなら自然にレビューできます。フィードバックを書いて「Submit All Reviews」を押すとJSONファイルとしてダウンロードされ、Claude Codeがそれを読み取って次のステップへ進む、という連携もスムーズでした。
ベンチマーク結果
3つのテストケースの結果をまとめると以下のとおりです。
| 指標 | スキルあり | スキルなし | 差分 |
|---|---|---|---|
| パス率 | 87.5% | 66.6% | +20.9% |
| 平均時間 | 102.2秒 | 82.7秒 | +19.5秒 |
| 平均トークン | 21,869 | 13,421 | +8,448 |
スキルありの方がパス率で約21ポイント高い結果になりました。特に差が出たのは以下の点です。
- セクション構成の遵守。スキルなしだと「最後に」の代わりに「おわりに」「まとめ」を使いがちだが、スキルありでは指定した構成が安定して守られている
- コードブロックの言語指定。スキルなしだと言語指定の漏れが発生する
- 文体の統一感。スキルありでは「〜してみました」「印象」「個人的には」等の著者らしい表現が安定して使われている
一方でトークン消費は約60%増、時間は約24%増です。スキルファイルの読み込みやルールへの準拠にコストがかかっているのでしょう。品質向上とのトレードオフとしては許容範囲な印象です。
評価をもとにスキルを改善した
評価結果とフィードバックをもとに、スキルに2つの改善を加えました。
構成インタビューの追加
もともとのスキルはトピックを渡すとセッションの内容をもとに記事を書き上げてくれる仕組みでしたが、完成品をレビューするのは負荷が高い。見出しレベルで何を書くかを事前に決めるステップを追加しました。
具体的には、調査後・執筆前にAskUserQuestionで見出し構成を提案し、ユーザーの確認を得てから書き始めるようにしています。ユーザーが言っていないことや思っていないことを記事に残さないための仕組みです。
Playwright によるスクショ自動撮影
記事の中でツールのUIを紹介する際、手動でスクショを撮るのは面倒です。構成インタビューの段階でスクショが必要な箇所も一緒に決めて、Playwrightで自動撮影するようにしました。この記事のビューアーのスクショも、実際にPlaywrightで撮影したものです。
最後に
skill-creatorの評価機構は、スキルの効果を客観的に測れるのがいい仕組みだなと感じています。体感で「良さそう」だったものが数値で裏付けられると安心感がありますし、どこが弱いのかも見えてくるので改善の方向が明確になります。
何よりも開発体験として楽しかったです。ターミナルでテストを走らせて、ブラウザでレビューして、フィードバックを書いたらまたターミナルに戻る。ツールごとの得意なところに任せる設計が上手いなと。今後もスキルの追加・改善で活用していきたいです。