AnthropicはAgent Skills（スキル）のサンプルとして、スキルの作成、評価、改善を支援するskill-creatorスキルを提供しています。本記事では、skill-creatorが提供する機能の一つであり、改善前後のスキルを比較評価するブラインド比較（Blind comparison）を試してみます。
目次
skill-creator
Anthropicがスキルサンプルを公開するanthropic/skillsリポジトリで公開されているサンプルスキルの一つです。スキルの新規作成、性能評価、改善案の提示などを支援するスキルです。前回は、このスキルを使ってスキルを使った場合とスキルを使わなかった場合の挙動を比較評価し、改善案の確認をしました。今回はその改善前後をブラインド比較で評価します。
ブラインド比較の紹介
ブラインド比較はskill-creatorで紹介されている機能の一つで、発展的（Advanced）な内容として扱われています。ブラインド比較の手順はagents/comparator.mdに記載されており、これをもとにサブエージェントを立ち上げて実行します。また、比較後に勝敗理由や改善点を分析する場合はagents/analyzer.mdを参照します。
手順概要
- 評価プロンプトを用意する
- 評価プロンプトを用いて、比較対象となる2つのスキルの出力を生成する
- 実行結果を保存する
- 実行結果を入力として、ブラインド比較エージェントをサブエージェントとして起動する
- 実行結果を読み込む
- 評価プロンプトを読み込む
- 評価用のルーブリックを作成する
- 実行結果とルーブリックをもとに評価する
- 実行結果がアサーションを満たすか評価する
- 評価結果をもとに勝者を決定する
- 結果をJSONファイルとして保存する
手順の詳細
ここから各ステップの詳細を説明します。
1. 評価プロンプトを用意する
スキルを実行するための評価プロンプトを用意します。ブラインド比較では、このプロンプトの実行結果をもとに評価します。
評価プロンプトは、skill-creatorでスキル作成時や改善提案時に使用したプロンプトが想定されていますが、新たに作成しても問題ありません。
2. 評価プロンプトを用いて、比較対象となる2つのスキルの出力を生成する
評価プロンプトを用いて、2つのスキルをサブエージェントを用いて並列実行します。評価プロンプトが3つある場合は、［ 3 (評価プロンプト) × 2 (スキル) ］= 6個のサブエージェントが起動されます。
評価プロンプトの実行は、agents/comparator.mdで定義されたブラインド比較の手順ではなく、その前段階となります。ブラインド比較エージェントは、事前に生成された2つの出力結果を読み込み、どちらの出力が評価プロンプトに対してより優れているかを判定します。
3. 実行結果を保存する
サブエージェントの実行結果を後の手順で参照できるように、ファイルに保存します。
4. 実行結果を入力として、ブラインド比較エージェントをサブエージェントとして起動する
ブラインド比較を実施するサブエージェントを起動します。サブエージェントには次のデータを渡します。この時点では、比較対象スキルの実行はすでに完了しており、ブラインド比較エージェントにはスキルそのものではなく、保存済みの実行結果を渡します。
- 1つめのスキルの実行結果
- 2つめのスキルの実行結果
- 評価プロンプト
- アサーション
実行結果は、どちらが改善前スキルであるか、改善後スキルであるかは匿名化しておきます。「この結果が改善後スキルである」といったバイアスを含まないようにするためです。
アサーションは実行結果後に満たしてほしい状態のリストです。評価プロンプトと同様に、スキル作成、改善時のものを再利用できます。ブラインド比較では、これは必須ではなくオプションとなります。
これ以降はブラインド比較サブエージェントの処理内容です。
a. 実行結果を読み込む
サブエージェントの入力として渡された2つのスキルの実行結果を読み込みます。実行結果本文だけでなく、中身の構造やファイルやディレクトリの種別・構造・内容を確認します。
b. 評価プロンプトを読み込む
その後、評価プロンプトをもとに「このタスクで何を評価すべきか」を検討します。agents/comparator.mdでは、タスクの目的を特定するうえで、3つの観点が定義されています。
-
What should be produced?
- 何が生成されるべきか
-
What qualities matter (accuracy, completeness, format)?
- 正確性・完全性・形式など何が重要か
-
What would distinguish a good output from a poor one?
- 良い出力と悪い出力を分ける要素は何か
これが次に作成する評価用ルーブリックを決定するための下準備となります。
c. 評価用のルーブリックを作成する
スキルの実行結果を評価するためのルーブリックを作成します。ルーブリックとは評価観点のことです。ブラインド比較では、ルーブリックとして2つ側面から評価します。
1つめがコンテンツルーブリックです。出力の中身をもとに妥当性、完全性、正確性を評価します。
| 評価基準 | 1（悪い） | 3（許容範囲） | 5（優れている） |
|---|---|---|---|
| 妥当性 | 重大な誤りがある | 軽微な誤りがある | 完全に正しい |
| 完全性 | 重要な要素が欠けている | おおむね網羅されている | すべての要素が含まれている |
| 正確性 | 不正確な記述が目立つ | 一部に不正確な記述がある | 全体を通して正確である |
2つ目が構造ルーブリックです。出力がどのように構成されているかを評価します。
| 評価観点 | 1（不十分） | 3（許容範囲） | 5（優れている） |
|---|---|---|---|
| 構成 | 整理されていない | ある程度整理されている | 明確で論理的に構成されている |
| 書式 | 一貫性がない、または崩れている | おおむね一貫している | 見やすく整った書式である |
| 使いやすさ | 利用しにくい | 工夫すれば利用できる | すぐに利用しやすい |
これらの評価観点は固定ではなく、ベースとして、タスクや成果物の種類に応じて調整する想定です。agents/comparator.mdでは、例として以下が挙げられています。
- PDFフォームの場合
- フィールドの配置
- 文字の読みやすさ
- ドキュメントの場合
- セクション構成
- 見出し階層
- データ出力の場合
- スキーマの正しさ
- データ型
d. 実行結果とルーブリックをもとに評価する
実行結果と作成したルーブリックを照らし合わせて、スコアを付けます。評価項目ごとにスコアを付けた後、コンテンツルーブリック、構造ルーブリックそれぞれで平均値を求めます。
e. 実行結果がアサーションを満たすか評価する
アサーションが渡されている場合、実行結果に対して、アサーションが満たされているかを確認します。実行結果がアサーションをどの程度満たしたかの割合を充足率として出力します。
アサーション評価で重要なのは、この充足率はブラインド比較において補助的に用いられるという点です。主な判定基準は、ルーブリックによる評価となります。
f. 評価結果をもとに勝者を決定する
2つのスキルのうち、どちらが優れているかを決定します。判定は以下の順に実施します。
- ルーブリックの評価スコア
- アサーションの充足率
- 1と2が同等なら引き分け
agents/comparator.md では、原則引き分けとせず、決断力をもって優劣をつけるように指示されています。比較することが目的のため、「同じような結果だから、とりあえず引き分け」となることを避けるようになっています。
g. 結果をJSONファイルとして保存する
比較結果を指定されたパスに保存します。パスが指定されていなければ、comparison.jsonとして保存します。出力フォーマットも厳密に定義されています。
{
"winner": "A",
"reasoning": "Output A provides a complete solution with proper formatting and all required fields. Output B is missing the date field and has formatting inconsistencies.",
"rubric": {
"A": {
"content": {
"correctness": 5,
"completeness": 5,
"accuracy": 4
},
"structure": {
"organization": 4,
"formatting": 5,
"usability": 4
},
"content_score": 4.7,
"structure_score": 4.3,
"overall_score": 9.0
},
"B": {
"content": {
"correctness": 3,
"completeness": 2,
"accuracy": 3
},
"structure": {
"organization": 3,
"formatting": 2,
"usability": 3
},
"content_score": 2.7,
"structure_score": 2.7,
"overall_score": 5.4
}
},
"output_quality": {
"A": {
"score": 9,
"strengths": ["Complete solution", "Well-formatted", "All fields present"],
"weaknesses": ["Minor style inconsistency in header"]
},
"B": {
"score": 5,
"strengths": ["Readable output", "Correct basic structure"],
"weaknesses": ["Missing date field", "Formatting inconsistencies", "Partial data extraction"]
}
},
"expectation_results": {
"A": {
"passed": 4,
"total": 5,
"pass_rate": 0.80,
"details": [
{"text": "Output includes name", "passed": true},
{"text": "Output includes date", "passed": true},
{"text": "Format is PDF", "passed": true},
{"text": "Contains signature", "passed": false},
{"text": "Readable text", "passed": true}
]
},
"B": {
"passed": 3,
"total": 5,
"pass_rate": 0.60,
"details": [
{"text": "Output includes name", "passed": true},
{"text": "Output includes date", "passed": false},
{"text": "Format is PDF", "passed": true},
{"text": "Contains signature", "passed": false},
{"text": "Readable text", "passed": true}
]
}
}
}
ブラインド比較をやってみる
実際にskill-creatorのブラインド比較を、Webの検索結果をレポートとしてまとめるスキル「web-research-report」スキルを対象に実施しました。このスキルは前回、skill-creatorで評価したもので、その際に用いた評価プロンプト、アサーション、改善案を利用します。
0.事前設定
比較対象スキル
改善前スキルは
- 検索回数や深さに制限がなく、調査に相当の時間を要することがあった
- レポート構成が未定義
といった課題があったため、以下を明文化し、これを改善しています。
- 1回の検索のみで、上位5件の検索を採用する
- ##Summaryや##Sourcesなどのテンプレートを強制
|
|
評価プロンプト
使用する評価プロンプトは以下の3つです。
| ケース | 評価プロンプト |
|---|---|
| eval-0 | 2026年に入ってからの量子コンピュータの実用化に関する最新動向を調べて、レポートにまとめてくれる？日本語でお願い |
| eval-1 | Rust製のwebフレームワークのAxumとActix、それとtokio-rsの最新リリースで何が変わったか調べてMarkdownでまとめて。後でハッシュ確認したいから一意のハッシュもつけて |
| eval-2 | テスラの自動運転に関する最新の規制動向（特にEUと米国）を調べて、ソースのURL付きでレポート出してください |
アサーション
アサーションは以下です。評価プロンプトごとに差分があります。
| アサーション | eval-0 | eval-1 | eval-2 |
|---|---|---|---|
| report.mdがoutputs ディレクトリに存在する | ✅ | ✅ | ✅ |
| "最終応答に64桁の16進SHA-256ハッシュが含まれる" | ✅ | ✅ | ✅ |
| "応答中のハッシュ値が、実ファイルのSHA-256と一致する" | ✅ | ✅ | ✅ |
| "レポートが300文字以上ある" | ✅ | ✅ | ✅ |
| "レポートに少なくとも1件のhttp(s) URLが含まれる" | ✅ | ✅ | ✅ |
| "レポートに日本語文字（ひらがな・カタカナ・漢字）が含まれる" | ✅ | - | - |
| "レポートにhttp(s) URLが2件以上含まれる" | - | - | ✅ |
1. 評価プロンプトの実行
3つの評価プロンプトを改善前後である2つのスキルに対して、実行します。計6つのテストケースをサブエージェントで並列に実行しました。
サブエージェントで実行する際も、位置バイアスを回避し、ブラインドを担保するためにA/BテストのAとBをシャッフルしています。
{
"eval-0": {"A": "before", "B": "after"},
"eval-1": {"A": "after", "B": "before"},
"eval-2": {"A": "after", "B": "before"}
}
評価結果のサマリ
結論から言うと勝者が「改善前スキル」となりました。つまりスキルの変更によって、ブラインド比較の観点では、内容が悪化したということです。まずは全体の評価結果を紹介します。
ルーブリック評価の結果は以下となりました。すべての評価プロンプトにおいて、改善前スキルが良い結果を記録しています。
| eval | 改善前スキルの評価 | 改善後スキルの評価 | 差 |
|---|---|---|---|
| eval-0 | 10.0 | 6.7 | -3.3 |
| eval-1 | 9.2 | 4.8 | -4.4 |
| eval-2 | 9.3 | 6.3 | -3.0 |
アサーションについては充足率がともに100%となっています。そのためアサーションが最終結果に影響していないことがわかります。
| before | after | |
|---|---|---|
| 充足率 | 17/17 (100%) | 17/17 (100%) |
ルーブリック評価の深堀り
3つのテストケースに対して、各評価指標の採点結果やその採点理由、差がついた理由を確認していきます。評価自体はLLMが実施しているので、採点理由などはLLMに直接確認して、その内容を記載しています。
ケース：eval-0
| 評価軸 | 改善前スキル | 改善後スキル | 差 |
|---|---|---|---|
| コンテンツルーブリック | |||
| 妥当性 | 5 | 4 | -1 |
| 完全性 | 5 | 2 | -3 |
| 正確性 | 5 | 4 | -1 |
| 構造ルーブリック | |||
| 構成 | 5 | 3 | -2 |
| 書式 | 5 | 4 | -1 |
| 使いやすさ | 5 | 3 | -2 |
次の表は採点理由と改善前後で差が出た理由です。こちらの表は生成AIに出力させたそのものとなっています。
| 軸 | 改善前スキルの採点理由 | 改善後スキルの採点理由 | 差がついた理由 |
|---|---|---|---|
| 妥当性 | 主要主張が2026/06のソースと整合、誤りなし | 主要事実は正しいが QRS 2025/12 ソースを含み「2026年に入ってから」のスコープから一部逸脱 | 改善後スキルはソース選別が浅く、設問の時間枠と噛み合わない情報が紛れた |
| 完全性 | 6章構成（HW / 資本市場 / 国家戦略 / 応用 / 人材育成 / 含意）で固有数値も豊富 | 5箇条書きのみ。国家戦略・人材育成・含意が完全に欠落 | 改善後スキルの「1回の検索・ページ取得禁止」が広いトピックの取りこぼしを誘発 |
| 正確性 | 9件のURLすべてが2026/06記事で本文と対応 | URLは有効だがスコープ外ソースの存在で軽い減点 | ”完全性”と同じ要因 |
| 構成 | サマリー→章立て→結論→参考文献→手法ディスクロージャーの階層 | フラットな Summary + Sources の2セクションのみ | 改善後スキルの「固定テンプレート」強制で階層化の余地がなかった |
| 書式 | 見出し階層が一貫、bold callout で強調 | Markdown自体はきれい、clickable link もある | 書式そのものは両者破綻なし。差は「書式の豊かさ」程度 |
| 使いやすさ | そのまま社内回覧できる情報密度 | ヘッドライン把握用、意思決定には情報不足 | ”構成”と連動。テンプレートの薄さが「使える形」を阻害 |
ケース：eval-1
こちらの評価プロンプトでは、skill-creatorで定義された評価ではなく、独自の評価指標を用いました。その理由は評価プロンプトやタスクの性質が「答えの質」よりも「そもそも答えに到達できたか」を問う形式だったので、コンパレータが評価指標を作り直しています。
| 評価軸 | 改善前スキル | 改善後スキル | 差 |
|---|---|---|---|
| タスク適合度（task_fit） | 5 | 2 | -3 |
| 正確性と根拠（accuracy_and_grounding） | 4 | 2 | -2 |
| 構造と可読性（structure_and_readability） | 5 | 3 | -2 |
| 網羅性（completeness） | 5 | 2 | -3 |
| 最終応答の質（final_response_quality） | 4 | 3 | -1 |
以下が採点理由です。
| 軸 | 改善前スキルの採点理由 | 改善後スキルの採点理由 | 差がついた理由 |
|---|---|---|---|
| タスク適合度 | Axum 0.8.9 / Actix Web 4.14.0 / Tokio 1.52.3 を具体的に提示し、3プロジェクト全てに回答 | Axum は曖昧な 0.12.6 のみ、Actix と Tokio はバージョン特定できずと自己申告 | 「最新リリースで何が変わったか」という事実検索タスクに対し、改善後スキルは3問中2問を未回答で終えた |
| 正確性と根拠 | プロジェクトごとに Releases / CHANGELOG への deep link、Tokio の WebFetch 失敗を明示開示 | スニペット由来でソースは medium.com や blog.rust-lang.org のルートURLのみ、Axum バージョンも実体系と不整合 |
改善後スキルの「ページ取得禁止」が一次ソースへの到達を阻害し、検索結果スニペット止まりの粒度しか出せなかった |
| 構造と可読性 | プロジェクト別セクション + Added/Changed/Fixed のグルーピング + 横断サマリー + Sources | フラットな箇条書きのみ | 改善後スキルの固定テンプレート（Summary 3-5 bullets）が変更ログ型コンテンツの構造化を不可能にした |
| 網羅性 | 3プロジェクトすべてを実質的にカバー | 3プロジェクト中2つを明示的に未完のまま終了 | 改善後スキルの「1回の検索だけ」が、複数対象を扱う比較系プロンプトに対して圧倒的に不足 |
| 最終応答の質 | レポート要旨を3行サマリーで提示 + パス + ハッシュ | 検索クエリは含むが、本文は findings より caveat（できなかった旨）が支配的 | 改善後スキルは「答えられなかった事実」を最終応答で目立たせる形になり、ユーザー体験として非回答に近い印象 |
ケース：eval-2
3つめの評価プロンプトは、1つめと同様にskill-creatorで定義された評価指標をそのまま用いています。
| 評価指標 | 改善前スキル | 改善後スキル | 差 |
|---|---|---|---|
| コンテンツルーブリック | |||
| 妥当性 | 4 | 4 | 0 |
| 完全性 | 5 | 2 | -3 |
| 正確性 | 4 | 4 | 0 |
| 構造ルーブリック | |||
| 構成 | 5 | 3 | -2 |
| 書式 | 5 | 3 | -2 |
| 使いやすさ | 5 | 3 | -2 |
評価理由は以下の通りです。
| 軸 | 改善前スキルの採点理由 | 改善後スキルの採点理由 | 差がついた理由 |
|---|---|---|---|
| 妥当性 | 主要事実は正確、Wikipedia等の二次資料中心だが捏造なし | 主要事実は正確、ソースは search 検証済み | 両者とも事実関係に重大なミスなし、僅差 |
| 完全性 | EUと米国を両方カバー（NHTSA調査467/13、テキサス州運行許可、SELF DRIVE Act、各国型式承認表、UN R157、GSR、ISA、ETSC懸念表明、EU vs US比較） | 「米国側の規制動向への直接的な言及は限定的」と自ら明言してEUのみ実質回答 | 改善後スキルの「1回の検索」がプロンプトの片側を取りこぼし、二地域対比という設問の根幹を半分しか満たせなかった |
| 正確性 | Wikipedia等の二次資料経由で一次ソースから一段離れる | スニペット由来でソースは検証済みURLのみ | 改善前スキルは二次資料経由、改善後スキルは粒度が浅い ― 別方向の弱みで打ち消し合い |
| 構成 | 章立て + 国別の型式承認テーブル（NL/LT/EE/DK/BE） + EU vs US比較セクション | フラットな箇条書き + リンク集のみ | 改善後スキルの固定テンプレートが、地域別構造や比較セクションを許容しない |
| 書式 | UN R157、GSR、ISA、Article 39 などの法令番号を明示、表組みも活用 | 見出しはあるが本文はスニペット相当の粒度 | 改善後スキルの浅い情報量だと、書式を駆使する余地もない |
| 使いやすさ | 法令番号で一次ソースに辿れる粒度、地域別の判断材料がそろう | 概要把握用、規制判断には情報不足 | organization と連動。テンプレートの薄さが読者にとっての実用性を阻害 |
2. ブラインド比較結果判定
今回はいずれのテストケースのルーブリック評価においても、改善前スキルが優位である結果が出ました。そのため勝者は改善前スキルとなっています。
結果からの考察
何故ルーブリック評価が悪化したのか？
結果として今回はスキル変更が悪影響を及ぼすことがわかりました。
今回の改善では、事前に実施したskill-creatorの評価/改善フローで得られた結果をもとに、スキルを修正しました。その際は、アサーションのPASS率、ユーザーフィードバック、実行時間やトークン量などの効率指標を参考にしています。
アサーションは前述のように、「～のファイルがある」や「～の記載がある」などのスキルが満たすべき必要条件となっています。アサーションが生成物の質を評価しきれず、その結果PASS率が高くなり、かつユーザーフィードバックが少ない場合、効率指標を改善する提案が主となります。その結果、コンテンツの中身を確認する今回のルーブリック評価では、評価が悪化したのではないか、と考えています。
改善するためのポイント
今回のタスクは、決められた手順でタスクを実行するだけでなく、生成物であるレポートも重要であり、それに対するルーブリック評価が主でした。これを改善するためにはタスクの目的に適したアサーションが必要となります。
ただこれはLLMがスキルを読み込んで推測するだけでは、今回のように不十分となることがあるため、やはり人が「このスキルで何を達成したいか」「このスキルの期待値は何か」を明確に伝えることが重要ではないかと思いました。
まとめ
本記事ではskill-creatorのブラインド比較機能で、改善前後のスキルを評価しました。結果として変更が良くない結果を生みましたが、スキル改善のポイントをつかむことができました。
skill-creator自体はリポジトリのREADMEにも記載されているように、あくまでスキルの可能性を示すものです。skill-creatorそのものについても改善の余地はあると思いますが、「まず試してみる」という観点では非常によいスキルであると思います。
