エージェントスキルの評価は、公開前に合否を一度だけ判定する試験ではない。 モデル、実行基盤、利用者の業務、周辺のスキルが変わり続けるため、変更を検知し、原因を切り分け、修正を検証し、不要になったスキルを退役させる運用周期として設計する。
Anthropic の skill-creator は、この周期を作る部品として、テスト用の依頼、期待する結果、基準版との比較、独立した実行、機械的な採点、人間による定性的な確認、合格率、所要時間、トークン使用量、反復ごとの結果保存を組み合わせている。 出力品質の評価とは別に、依頼に対してスキルが呼ばれるべきかを判定する発火評価も扱う。
https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills
スキルの種類によって評価目的が変わる
記事はスキルを、能力の底上げ型と作法の記述型に分類している。 この分類は、同じ評価手順を使いながら、何をもってスキルの価値とみなすかを分ける。
Capability uplift（能力の底上げ）型は、基本モデルだけでは実行できないか、安定して実行できない仕事を補う。 評価では、スキルありの成績がスキルなしを上回るかを測る。 モデルの更新後に基本モデルだけでも合格するようになったなら、そのスキルは壊れたのではなく、役割を終えた可能性がある。
Encoded preference（作法の記述）型は、基本モデルが個々の操作を実行できることを前提に、組織固有の順序、判断基準、成果物の形式を守らせる。 評価では、一般的な出来栄えよりも、現在の業務手順へ忠実かを測る。 基本モデルの能力が上がっても、組織固有の作法は自動的には取り込まれないため、業務の変更に追随して評価事例とスキルを更新する必要がある。
したがって、能力の底上げ型では基準版との差が消えたときに退役を検討し、作法の記述型では業務とのずれが生じたときに改訂する。 継続的な評価は、すべてのスキルを永久に改善し続ける仕組みではなく、種類に応じて改善と退役を選ぶ仕組みになる。
継続できる評価の最小単位
一つの評価事例には、現実的な依頼、必要な入力ファイル、期待する結果、客観的に検査できる判定条件、人間にしか判断しにくい観点を持たせる。 判定条件を出力を見てから作ると、その出力に都合のよい試験になるため、実行中までには固定する。
同じ依頼を、変更後のスキルと基準版の両方に与える。 新規スキルではスキルなしを基準版にし、既存スキルの改善では旧版または直前版を基準版にする。 これにより、単に合格したかではなく、スキルを使った効果と変更による差分を測れる。
各実行は独立した文脈で行う。 同じ会話の中で順番に試すと、前の事例の情報が次の事例へ混ざり、実運用では得られない手掛かりによって成績が上がることがあるためだ。
二つの評価面
実行評価は、スキルが呼ばれた後の成果物を測る。 合格率だけでなく、所要時間とトークン使用量も記録し、品質向上が過大な費用や遅延と引き換えになっていないかを見る。 機械判定に向かない文章の調子やデザイン品質は、無理に数値化せず人間が確認する。
発火評価は、どの依頼でスキルを呼ぶかを測る。 呼ぶべき事例だけでなく、語句は似ているが呼ぶべきでない紛らわしい事例を含める。 skill-creator は事例を学習用と保留用に分け、候補となる説明文を学習用で改善し、採用する説明文を保留用の成績で選ぶことで、事例への過剰適合を抑えている。
実行評価の進め方
人間は最初に、現実的な依頼、期待する結果、入力ファイル、検証可能な判定条件を定義する。 成果物を見てから判定条件を決めると都合のよい採点になるため、条件は実行中までに固定する。
評価基盤は、変更後のスキルと基準版を独立したエージェントへ同時に渡す。 基準版は、新規スキルならスキルなし、既存スキルの改善なら旧版または直前版になる。 各実行では、成果物、実行記録、所要時間、トークン使用量を保存する。
採点エージェントは、実行者の自己申告だけを信じず、実行記録と成果物を直接調べる。 判定条件ごとに合否と根拠を記録し、表面的には合格するが仕事の完了を識別できない条件や、検証不能な条件も指摘する。 ファイル形式やセルの値のようにプログラムで検査できる条件には、採点エージェントより検証スクリプトを使うほうが再現性を高められる。
集計スクリプトは、構成ごとに合格率、所要時間、トークン使用量の平均、標準偏差、最小値、最大値を計算し、変更版と基準版の差を出す。 分析エージェントは、両方で常に通る識別力のない条件、両方で常に落ちる条件、ばらつきの大きい事例、費用と品質の交換条件を探す。 必要なら、どちらのスキルが作ったかを隠した比較エージェントが二つの成果物を評価する。
人間は集計作業ではなく、数値化しにくい品質の確認と、評価基準そのものが業務上妥当かの判断を担う。 文章の調子、デザインの使いやすさ、組織の作法への忠実さは、最終的に人間の確認を残すほうがよい。
発火評価の進め方
人間は、スキルを呼ぶべき依頼と呼ぶべきでない依頼に正解ラベルを付ける。 否定事例には、まったく無関係な依頼ではなく、同じ語句を含むが別のスキルや通常機能を使うべき紛らわしい依頼を含める。
評価スクリプトは、候補となるスキル名と説明文を Claude Code から見える一時ファイルとして配置し、利用者の依頼を実際に実行する。 出力本文の内容ではなく、Claude が Skill または Read を使って対象スキルを読み込んだかを実行中の事象から検出する。
同じ依頼を既定で3回実行し、発火した回数から発火率を計算する。 呼ぶべき依頼は発火率がしきい値以上なら合格し、呼ぶべきでない依頼はしきい値未満なら合格する。 結果から適合率、再現率、正解率を計算できるため、人間が数える必要はない。
説明文の改善では、正解ラベル付きの依頼を学習用と保留用へ層化して分割する。 改善エージェントには学習用で起きた未発火と誤発火を見せ、候補の説明文を作らせるが、保留用の成績は見せない。 各候補を両方で再評価し、最後に保留用の成績が最も高い説明文を選ぶ。
人間は発火回数を集計する必要はない。 ただし、依頼の正解ラベル、事例の現実性、紛らわしい否定事例の十分さを確認する必要がある。 ここを自動生成だけに任せると、実際の利用分布とは異なる評価集合を高得点で解く説明文が選ばれる。
運用周期
flowchart LR
A[実運用の失敗と変化を収集] --> B[評価事例に固定]
B --> C[変更版と基準版を独立実行]
C --> D[機械判定と人間の確認]
D --> E[差分とばらつきを分析]
E --> F[原因を一つ選んで修正]
F --> C
E --> G[評価集合を拡張]
G --> B
E --> H[スキルの維持または退役]反復ごとに、スキルの版、モデル、依頼、入力、出力、判定結果、所要時間、トークン使用量を一緒に保存する。 平均値だけでは不安定さを隠すため、複数回実行し、平均とばらつきを見る。 変更後の平均が高くてもばらつきが大きいなら、日常利用で再現しない改善かもしれない。
評価集合は、固定した中核事例と、実運用の失敗から追加する事例に分ける。 中核事例は回帰を検知する物差しとしてむやみに書き換えず、追加事例は同じ失敗の再発防止に使う。 評価に合わせてスキルだけを細かく縛るのではなく、異なる依頼にも通じる失敗原因を命令や補助スクリプトへ反映する。
持続可能性を損なう兆候
スキルありと基準版が常に同じ判定条件を通るなら、その条件はスキルの価値を識別できていない。 事例ごとの成績が大きく揺れるなら、試験環境、採点基準、またはスキルの振る舞いが不安定である。 固定事例だけが改善し、新しい事例で改善しないなら、スキルは評価集合へ過剰適合している。 基本モデルだけで継続して合格するなら、能力の底上げ型のスキルは壊れたのではなく、役割を終えた可能性がある。
継続可能な枠組みは、試験数の多さでは決まらない。 実運用の失敗を小さな再現事例へ変え、基準版との差を独立に測り、結果と判断を版ごとに残し、その証拠から維持、修正、退役を選べることによって成立する。
tanteki は比較条件そのものを監査する
tanteki は、日本語の業務文書と技術文書を執筆、推敲するエージェントスキルである。 このスキルの評価は、同じ依頼をスキルなしとスキルありで実行する対照比較になっている。
https://github.com/iwasa-kosui/tanteki
現在の分離方式では、10課題を2回ずつ、両条件で実行する。 各試行は同じ Docker イメージから作った新しいコンテナで始まり、空の HOME と作業領域を使う。 両条件の差は tanteki 一式の有無に限定し、モデル、推論量、出力形式、制限時間、モデル呼び出し上限、利用者の入力を一致させる。 外部ネットワークを切り、利用者の設定、ほかのスキル、リポジトリ、採点基準を生成側へ渡さない。
https://github.com/iwasa-kosui/tanteki/blob/main/benchmarks/isolated/README.md
この評価の特徴は、設定値の比較だけで条件の一致を判断しないことにある。 実際の初回 API リクエストを保存し、スキル一覧やセッションの識別情報を除いて想定外の差がないかを調べる。 環境や入力が一致しないペアは品質比較から除外する。 生成後に採点結果を返して書き直させず、確定した出力を別コンテナで採点するため、採点用の情報が執筆へ漏れる経路も分けている。
課題は ADR、設計書、進捗報告、障害記録、情報不足の Runbook、部分修正などを扱う。 各課題には、出力を見る前に事実の保持、根拠への忠実さ、文書の役割、明確さ、簡潔さという五つの合否基準を定める。 採点モデルには原依頼、固定した基準、匿名化した二つの候補だけを渡し、条件名やスキルの利用記録は伏せる。 意味の採点とは別に、文書検査の合否、トークン使用量、モデル呼び出し回数、所要時間を機械的に記録する。
2026年9月21日の実測では、レート制限で欠けた四ペアを除く16ペアを採点し、五基準の合格数はスキルなしが60/80、スキルありが71/80だった。 文書検査の合格は8/16から15/16へ増えた一方、モデル呼び出しは22回から85回、報告された入力トークンは118,397から954,302へ増えた。 品質だけでなく、その改善に必要な費用も同じ結果に残している。
ただし、この数字をあらゆる用途における文章品質の優位と読むことはできない。 基準がスキルの方針に沿うこと自体は、そのスキルが実現しようとする作法への適合度を測るために必要である。 課題は作成者が選んだ10件、反復は2回、採点は単一モデルであり、測定対象は事前に定めた tanteki の作法に限られる。 採点モデルには本文外の注記も渡るため、完全な盲検でもない。 実際に、本文が同一なのに注記を理由として片側だけ不合格になった例や、資料にない補完を採点モデルが見逃した例を作者自身が記録している。
それでも、この試みは「LLM に点数を付けさせる」だけの評価とは異なる。 比較条件の一致、失敗の除外、入力と成果物のハッシュ、判定理由、採点の誤りまで保存し、数字が何を示せて何を示せないかを後から調べられる。 小規模な評価では、結論の強さよりも、疑わしい結果を捨てずに検証できる証拠の設計が価値を持つ。
tanteki の採点モデルは候補を独立した二値判定で評価する
tanteki の採点モデルは、二つの候補から好みの文章を一つ選ぶのではない。 各候補について、事実、根拠、文書の役割、明確さ、簡潔さの五項目をそれぞれ合格か不合格かで判定し、決め手となった記述または欠落を日本語で返す。 一項目の基準に複数の条件がある場合は、すべてを満たしたときだけ合格にする。
採点モデルへ渡す入力は、原依頼と資料、課題ごとに事前定義した五項目の基準、候補 A と候補 B の本文と本文外の注記である。 条件名、スキルの利用記録、文書検査の結果は渡さない。 A と B の対応は課題と反復によって入れ替え、片側が常に同じ位置になる偏りを避ける。 採点モデルには、候補を独立に評価すること、長さ、見出し、自信のある表現、整った文体を事実への忠実さの代わりに評価しないこと、候補にない情報を推論で補わないことを指示している。
https://github.com/iwasa-kosui/tanteki/blob/main/benchmarks/judge-instructions.txt
応答形式は構造化されている。 候補ごとに五項目を必須とし、各項目には真偽値の合否と空でない根拠を要求する。 採点モデルは道具や外部情報を使えず、一ペアにつきモデル呼び出しは一回だけである。 失敗した採点を望ましい判定が出るまで再試行する仕組みはない。 集計では五項目を等しく一件として数え、スキルありとなしの合格数の差をペアごとに計算する。
この方式は、曖昧な総合点や相対的な好みよりも判定理由を追いやすい。 一方で、評価の正しさは人間が書いた基準と単一の採点モデルに依存する。 一項目に複数条件を束ねているため、小さな欠落一つで項目全体が不合格になり、欠落の重大さは点数に反映されない。 五項目を等しく数えるため、事実の創作と見出しの多さが同じ一件の差になる場合もある。
候補 A と B を同じ入力で採点するため、採点モデルは条件名を知らなくても二つを比較できる。 指示上は独立評価だが、厳密に独立した二回の採点ではなく、一方の文章が他方の判定基準になる対照効果は残る。 本文外の注記も入力に含むため、文章の特徴からスキルありを推測できる可能性もある。
実測では、本文が完全に同じ部分修正の一ペアで、スキルあり側の注記だけを理由に簡潔さが不合格になった。 別の反復では同種の注記が合格しており、判定は一貫していない。 作者はこの誤りを修正せず、生の判定と人間による照合メモを併記した。
したがって、71/80という集計値は採点モデルが返した観測値であり、真の品質を直接表す測定値ではない。 この仕組みで信頼できるのは、個々の合否を根拠と本文まで戻って人間が検査できることにある。 改善効果を強く主張するには、複数の採点モデルまたは人間による盲検評価、採点の反復、基準項目ごとの重大度、作成者と独立した保留課題が必要になる。