システムが既にテストを実行して合格率を計算してくれているなら、benchmark.jsonの数字を見るだけで十分で、自分で出力内容を見る必要はないのでは？
十分ではない。これはまさにこのシステムの設計で特に注意されている点だ——アナリストパスが存在する理由は、合格率の数字自体が幻想である可能性があるからだ：あるアサーションがSkillを使っても使わなくても常に合格するなら、その「100%合格」は見栄えが良いが、Skillが実際に差をもたらしたことを何も証明していない。なぜなら、そのアサーションは「Skillの有無」という差異に対して判別力がゼロだからだ。
本当に身につけるべき習慣は、benchmarkの数字を見る前に、アナリストパスが「判別力のない」アサーションや「変異が大きすぎる」テストをフラグ立てしていないかを確認することだ。フラグが立っていれば、それらのテストケースに対応する合格率の数字は大幅に割り引いて見るべきであり、テストケース自体を再設計すべき場合もある。数字は常にこの分析レイヤーと一緒に読む必要があり、単純な合格率のパーセンテージだけを見ると、設計の悪いアサーションに簡単に誤導されてしまう。
description最適化のプロセスで使われる60/40の訓練/テスト分割は、単に複数回実行して平均を取ることとどう違うのですか？
違いは、それぞれが防ごうとしている問題が異なることにある。単純に複数回実行して平均を取ることは「単発の結果の不安定さ」という問題を解決する。しかしdescription最適化が直面しているのは別のリスクだ——過学習（overfitting）。同じクエリのバッチをdescriptionの改善とそのdescriptionの良さを採点することの両方に使うと、そのバッチのクエリにはたまたま合格するが、新しいバッチに切り替えると不正確になるdescriptionができてしまいやすい。最適化プロセスがそのバッチ特有の言い回しに無意識に調整されてしまうからだ。
60%訓練、40%保留テストの分割は、まさにこの問題に対処している：description改善のプロセスは訓練セットしか見ることができず、最終的にどのバージョンがbest_descriptionとして選ばれるかは、「見たことのない」テストセットでのスコアに基づいており、訓練スコアには基づいていない。ドキュメントはこれを直接述べている：これは「過学習を避けるため」だ——訓練スコアだけに基づいて最終バージョンを選んだ場合、そのバッチの問題を「丸暗記」しただけで、実際のユーザーの言い回しが変わった瞬間に機能しなくなるdescriptionを選んでしまう可能性が高い。
公式ドキュメントは「『ファイルXを読む』のような単純なクエリは、完璧なdescriptionマッチでも確実にskillをトリガーしない」と述べていますが、これは何を意味しますか？
これは、トリガーメカニズム自体に隠れた閾値があることを意味する——十分に精密なdescriptionを書くことだけではトリガーを保証しない。そのリクエスト自体が「Skillに相談する価値があるほど複雑か」どうかも関わってくる。リクエストが数文で処理できるほど単純な場合、Claudeの判断メカニズムは、そのSkillのdescriptionがリクエストのキーワードと完全に一致していても、Skillを一切トリガーしないことを選択する可能性がある。
これは評価用クエリの設計に直接影響する：「ファイルXを読む」のような過度に単純なクエリを使ってSkillがトリガーされるべきかをテストすると、得られる結果は最初から信頼できない可能性がある——descriptionの書き方が悪いからではなく、そのクエリ自体が「Skillをトリガーする価値がある」ほどの重みを持っていないからだ。公式ドキュメントはこの因果関係を直接指摘している：「設計の悪い評価クエリは、設計の悪いdescriptionを生む」——最初に投入したテストケース自体が難易度を間違えて選んでいたら、その後どれだけ最適化ループを回しても、生成されるdescriptionは本当には信頼できるものにならない。
Claude.aiでskill-creatorを使っていますが、評価機能の一部が全く動きません。なぜですか？
Claude.ai環境自体が、一部の機能が依存する能力を持っていないからだ。公式ドキュメントは対応する制限を明確にリストしている：Claude.aiにはsubagentがないため、テストケースは直列実行しかできない（並列実行より厳密さが劣る）。またベースラインを実行する方法もない——定量的なベンチマークとブラインド比較は、どちらも独立したベースラインがあってこそ意味を持つため、両方が完全にスキップされる。description最適化にはclaude -pというコマンドラインインターフェースが必要で、これはClaude Codeにしか存在しないため、Claude.aiではこれもスキップされる。
言い換えれば、Claude.aiで使えるのは実質的に簡易版だ——テストケースを実行し、質的フィードバックを生成して、ブラウザベースのビューアーではなく対話内で直接提示する。完全な定量的ベンチマーク、ブラインドA/B比較、自動description最適化が必要なら、これらの機能は明示的にClaude Code環境とsubagent能力を要求している。これはskill-creatorの設定ミスではなく、環境そのものの能力的な境界線だ。
skill-creatorに評価機能が追加される前、あるSkillが本当にClaudeのパフォーマンスを向上させているかどうかを判断する手段は、基本的に試用と直感しかなかった。公式のskill-creator SKILL.mdには、今では評価ワークフロー全体が組み込まれている——テストケースの実行、定量指標の生成、ブラインドA/B比較の実行、さらにはSkillのdescriptionフィールドの自動最適化まで行う。この記事はこのシステムを実際に分解し、それが本当に何を教えてくれるのか、そしてどこで自分自身の判断を補う必要があるのかを見ていく。
核となるロジックは複雑ではない：同じタスクプロンプトに対して、2つのsubagentを同時に起動する——一つはあなたのSkillを使って実行し、もう一つは完全に使わずに実行する（既存のSkillを改善する場合は旧バージョンを実行する）。両側の出力はそれぞれ独立したフォルダに保存される。公式ドキュメントはその後、「実行が進行している間にアサーションを下書きする」ことを求めている——各テストケースについて、客観的に検証可能なチェック項目を事前に定義し、結果が出てから後付けで採点方法を考えるのではない。
ここで公式ドキュメントが特に強調している境界線がある：アサーションは「客観的に検証可能」でなければならない。文体やデザインの美しさといった主観的な出力は、質的評価で判断する方がよく、本質的に主観的な成果物に定量的なアサーションを無理に当てはめると、誤解を招くスコアが生まれてしまう。
テストが完了すると、scripts.aggregate_benchmarkが結果をbenchmark.jsonとbenchmark.mdにまとめ、各構成の合格率、所要時間、トークン使用量を平均、標準偏差、差分とともに一覧化する。本当に興味深いのはその後に続くアナリストパスだ——公式ドキュメントは、「Skillの有無にかかわらず常に合格する」アサーション（そのアサーションに判別力がなく、Skillが実際に差をもたらしたかどうかを示せないことを意味する）と、「異常に高い分散を持つ」評価（そのテスト自体が本質的に不安定で信頼できない可能性があることを意味する）を見つけ出す分析を要求している。このステップは、このシステム全体の中で最も誠実な部分だと言える。見栄えの良い合格率の数字の壁に惑わされるのではなく、「この指標は実は何も教えてくれていない」というケースを積極的にフラグ立てしてくれるのだ。
どちらのバージョンが本当に優れているかをより厳密に比較したい場合、システムはブラインド比較を提供する——独立したエージェントが、どちらがどちらのバージョンから来たかを知らされずに、品質だけで2つの出力を判断し、その後なぜ勝者が勝ったのかを分析する。この機能に対する公式ドキュメント自身の位置づけは、注目すべきほど控えめだ：「これはオプションであり、subagentを必要とし、ほとんどのユーザーには不要だ——人間によるレビューループで通常は十分である」。この誠実な自己評価は注目に値する——システムの設計者自身が、ほとんどのシナリオではこれほど重い検証プロセスは不要であり、単に人間が出力を見てフィードバックを与えるだけで十分だと結論づけているのだ。