AIスキルの評価データはもう手元にあります｜自分の判断との差分を3つに分ける

自分の判断のクセをAIに覚えさせるスキルを作ると、最初の出力はたいてい薄いものになります。評価軸は並んでいるのに一般論に見える、頼んでいない前置きが勝手に入る、自分がいつも見ている厳しい観点だけが抜ける。間違ってはいないけれど、自分ならこうは言わない。この状態を「なんか違う」を頼りに直そうとすると、直すたびに別の方向へブレます。

ここで多くの人が止まるのは、測ろうとした瞬間に評価用のデータセットを作る作業が立ちはだかるからです。この記事はその前提を外します。判断を伴う仕事をしている人は、正解データをすでに持っています。過去に書いたレビューコメント、返した赤入れ、却下した提案。どれも「ある入力に対して自分がこう判断した」という組で、正解データの定義を満たしています。新しく作るのではなく回収する、という順序の逆転が出発点です。

この逆転には理論的な裏づけがあります。実務者9名の作業を観察した研究は、評価基準は採点する行為を通じてしか外在化されず、人間が実際に判定する前に基準を決めきることは不可能であると結論しました。だとすれば、すでに判定を終えている履歴から逆算するのが最短経路になります。Anthropicの公式ドキュメントも「評価を実行する組み込みの手段は現時点ではない、ユーザーが自分の評価システムを作れる」と明記していて、乗るべき既製の基盤は用意されていません。

手順は5つです。過去の実例を用意し、自分の判断は見せずに同じ入力をスキルへ通し、並べて差分を取り、差分を戻し、別の実例で繰り返す。2番目の順序だけは守ってください。自分で書いたスキルを自分で評価する利益相反を、手順そのもので潰せます。公式ドキュメントも「新しいセッションが重要です。スキルの作成から残っているコンテキストは、書かれた指示のギャップをマスクするためです」と、この落とし穴を名指ししています。

記事の中核は、出てきた差分を3つに分ける判定フローです。観点の欠落なら軸を追加する。強度のズレならトーンと優先順位を明記する。文脈の欠落だけは軸の追加では直らず、スキルの分割か実行前の確認に切り替える必要があります。あわせて、評価をLLMに採点させるのがこの用途では割に合わない理由を、査読論文の実測（僅差の比較ほど外す、引き分け判定の正答率は3割を切る、中身を増やさず長さだけ倍にすると9割が誤判定する）で示します。

最後に、原則不要と言い切ったうえで仕組み化する価値が出る3条件と、退行テストの考え方の転用、そして「差分が出なくなること」という完成の指標に着地します。

作った直後のスキルは、間違ってはいないけれど自分ならこうは言わない出力を返します

自分の判断のクセをAIに覚えさせるスキルを1本作ったとします。手順はClaudeでフィードバックスキルを作るで書いたとおりで、過去に自分が返したフィードバックを10ペアほど並べて、そこから共通する型を書き起こしてもらう。SKILL.mdができて、呼び出したら動く。ここまでは順調です。

問題はその次に来ます。実際の案件を流してみると、返ってくる出力がどうにも薄いのです。

「間違ってはいない」がいちばん厄介です

出てくるものを具体的に書くと、だいたいこの3つが同時に起きます。

ひとつ目は、評価軸は並んでいるのに、どれも一般論に見えることです。「論理の飛躍がないか確認しましょう」「読み手にとっての利点が明示されていません」。書いてあること自体は正しいのですが、その資料でなくても言える内容になっています。

ふたつ目は、頼んでいない配慮が勝手に入ることです。指摘の前に必ず良かった点が並ぶ。「全体の構成は明快で、読みやすくまとまっています。一方で以下の点は検討の余地があります」。自分はそんな前置きを書いた覚えがないのに、なぜか入っています。この現象がなぜ起きるのかはAIが人を気持ちよくさせる構造で扱ったので、背景を知りたい方はそちらへどうぞ。ここでは症状として挙げるだけにします。

みっつ目は、自分がいつも見ている厳しい観点が、そっくり抜け落ちることです。私の場合だと「その数字の出所はどこか」「その比較は条件が揃っているか」あたりが定番なのですが、初期版のスキルはここを言いません。

3つを足すと、「間違ってはいないけれど、自分ならこうは言わない」という状態になります。対処に困るのはここではないでしょうか。明確に間違っていれば直せますが、正しいけれど物足りないものは、どこをどう直せばいいのか分からないからです。

そして多くの場合、ここで「まあこんなものか」と受け入れてしまいます。以後ずっと薄い出力を読み続ける羽目になります。

「なんか違う」を頼りに直すと、直すたびにブレます

では受け入れずに直そう、となったときに次の落とし穴があります。

出力を読んで「厳しさが足りない」と感じたので、SKILL.mdに「遠慮せず率直に指摘する」と書き足す。翌週に別の案件を流すと、今度は細かい指摘が延々と並んで読む気が失せる。そこで「重要でない指摘は省く」と書き足す。すると今度は指摘が2つしか出てこなくなる。

これを何度か繰り返して、最初のバージョンより悪くなっていることに気づく、という展開はわりとよく起きます。

なぜブレるのか。どうやら、基準が自分の頭の中にあって外に出ていないことが原因のようです。書かれていない基準は、その日の気分と区別がつきません。今日「厳しさが足りない」と思ったのが本当に出力の問題なのか、自分がたまたま厳しい気分だったのか、判定する手立てがない状態で直しているわけです。

そもそも1回の出力では判定できません

もうひとつ、直す前に知っておいたほうがいい事実があります。同じ入力を同じスキルに通しても、出てくるものは毎回同じではありません。

Anthropicの公式ドキュメントは、API（プログラムから直接Claudeを呼び出す仕組み）のtemperatureというパラメータの説明にこう書いています。

Note that even with temperature of 0.0, the results will not be fully deterministic.

温度を0.0にしても結果は完全に決定的にはならない、という注記です（Anthropic Messages API リファレンス、執筆時点の2026年7月に確認）。temperatureは出力のランダムさを調整する数値で、0に近いほど毎回同じ答えを返しやすくなります。それを最小にしてもなお、完全には揃わないとベンダー自身が明記しているわけです。

どれくらい揃わないのかを実測した資料もあります。Thinking Machines Labが2025年に公開したLLM推論の非決定性を打ち負かすという記事で、同じプロンプトをtemperature 0で1000回走らせた結果が載っています。

出力は1000回で80通りに割れました。しかも分岐が始まるのは103トークン目からです。冒頭だけ読んでいたら全部同じに見える位置で、静かに枝分かれしています。

この記事が面白いのは、原因の通説を否定しているところです。「GPUの並列計算で浮動小数点の足し算の順序が変わるから」という説明がよく使われますが、著者らは同じ行列積を同じデータで繰り返せばビット単位で同じ結果になると実測したうえで、真犯人はバッチサイズの変動だと結論しています。

the primary reason nearly all LLM inference endpoints are nondeterministic is that the load (and thus batch-size) nondeterministically varies!

ほぼすべてのLLM推論エンドポイントが非決定的である主な理由は、負荷（つまりバッチサイズ）が非決定的に変動するからだ、という指摘です。同じ時間帯に他のユーザーが何件リクエストを投げているかで、自分の出力の数値がわずかに変わる。利用する側からは原理的に固定できません。

複数のモデルとタスクで測った学術研究もあります。Berk Atilらの「決定的」なLLM設定の非決定性（arXivプレプリント、2024年投稿・2025年改訂）は、5つのモデルを8つのタスクで10回ずつ走らせて、同じ設定の実行間で正解率が最大15%変動し、最良ケースと最悪ケースの差が最大70%に達したと報告しています。

つまり、1回流して「なんか違う」と判断したとき、それがスキルの実力なのか、たまたま悪い引きだったのかは分かりません。逆もまた同じで、1回良い出力が出たからといって安心もできません。

測る必要があります。ただし重い準備は要りません

ここまでをまとめると、初期版のスキルを主観で直すのは、外に出ていない基準を、ばらつく出力に対して当てる作業になります。うまくいかないのは当然です。

だから測る必要があるのですが、「測る」と聞いた瞬間に多くの人が想像するのは、評価用のデータセットを用意して、採点基準を決めて、スコアを集計する仕組みを作る作業でしょう。スキル1本を直すためにそこまでやるのか、と手が止まります。

そこは安心してください。判断を伴う仕事をしている人なら、必要なデータはもう手元にあります。

評価用のデータを新しく作る必要はありません

スキルの評価について書かれた記事を読むと、入り口はだいたい同じです。テストケースを作るところから始まります。サンプルの入力を用意する、ツールに候補を提案させる、機能と場面と読者像の組み合わせでケースを設計する。方法は違っても、共通しているのは評価用のデータを新しく作っていることです。

私はここが最大の脱落ポイントだと思っています。スキルを1本書き上げた直後の人にとって、「では評価用に20件のケースを用意しましょう」という提案は、スキル作成と同じくらいの作業量に見えます。だから測らずに使い始めて、なんとなく直して、なんとなくブレる。前のセクションで書いた状態に戻ってきます。

あなたが下してきた判断が、そのまま正解データです

ですが、判断を伴う仕事をしている人は、評価用のデータをすでに大量に持っています。

過去に書いたレビューコメント。返した赤入れ。却下した提案と、そのときに伝えた理由。直した見積もり。契約書に入れた修正指示。差し戻した実験計画。どれも「ある入力に対して、自分がこう判断した」という組になっています。

これは機械学習の分野で言うgolden data（正解データ）の定義そのものです。入力があって、それに対する正解の出力があって、その正解を信頼できる誰かが決めている。3つとも揃っています。

Anthropicの公式ドキュメントが示す正解データの作り方も、実は全部この形です。評価の作り方を説明したページには、タスク別の実例が並んでいます。文章の分類なら人手でラベルを付けたツイート1,000件、要約の評価なら参照用の要約を付けた記事200本、といった具合です。手法はそれぞれ違いますが、いずれも人間が事前に下した判断を正解として固定するという構造は共通しています。

違いは件数と、誰が判断したかだけです。企業が評価基盤を組むときは何百件を人手でラベル付けします。個人が自分のスキルを測るなら、自分がすでに判断した数件で足ります。作る必要はなくて、回収すればいいわけです。

「基準を先に決める」は原理的に無理があります

新しく作るのではなく回収する、という順序の逆転には理論的な裏づけがあります。

カリフォルニア大学バークレー校などの研究者によるWho Validates the Validators?という論文（2024年、arXivプレプリント）が、LLMの出力を評価する実務者9名の作業を観察しています。そこで見つかったのが criteria drift（基準のドリフト）と名付けられた現象です。

to grade outputs, people need to externalize and define their evaluation criteria; however, the process of grading outputs helps them to define that very criteria. We dub this phenomenon criteria drift, and it implies that it is impossible to completely determine evaluation criteria prior to human judging of LLM outputs.

出力を採点するには評価基準を外に出して定義する必要がある。ところが、その基準を定義する助けになるのが、採点するという行為そのものである。だから人間が実際に出力を判定する前に、評価基準を完全に決めきることは不可能である、という主張です。

論文は追加でこうも書いています。先に基準を決めてから採点を始めた参加者ですら、採点を続けるうちに基準を書き換え、過去に付けた採点を遡って変更していた、と。

これは実感と合うのではないでしょうか。「良いレビューとは何か」を先に言葉にしようとすると手が止まりますが、実際のレビュー対象を目の前に置けば、すぐに「ここは違う」と言えます。判定は具体物があって初めて動き出すものです。

だとすれば、評価の順序はこうなります。基準を先に書くのではなく、すでに判定を終えている履歴から逆算する。これが最短経路です。あなたが過去に返した赤入れには、言葉になっていない基準がすでに埋まっています。

公式の評価ツールに乗ればいい、という選択肢は今のところありません

念のため、既製の仕組みに乗る道も確認しておきます。

Anthropicのスキル作成のベストプラクティスには、評価と反復について専用のセクションがあります。そこにこう書かれています。

There is not currently a built-in way to run these evaluations. Users can create their own evaluation system. Evaluations are your source of truth for measuring Skill effectiveness.

これらの評価を実行する組み込みの手段は現時点ではない。ユーザーは自分自身の評価システムを作ることができる。評価はスキルの有効性を測るうえでの拠り所である、という記述です。

実際に確認してみると、以前あったConsoleの評価ツールの解説ページは、執筆時点（2026年7月31日）ではリダイレクトのみになっていて、評価の作り方を説明する一般的なページに統合されています。サイトマップを見ても該当ページは残っていません。つまり「公式のGUIツールに乗れば済む」という道は、現時点では用意されていないことになります。

自分で組むしかない。だとすれば、手元にあるデータから始めるのがいちばん速い、という結論になります。

同じベストプラクティスのページには、もうひとつ効く一文があります。

Create evaluations BEFORE writing extensive documentation. This ensures your Skill solves real problems rather than documenting imagined ones.

大量のドキュメントを書く前に評価を作れ。そうすることで、そのスキルが想像上の問題を記述するのではなく、実際の問題を解決するものになる。SKILL.mdを厚くしていく前に、測る手段を先に持てという話です。手元の実例なら、その日のうちに用意できます。

どの案件を選ぶか

回収する実例の選び方には、少しだけコツがあります。

まず、判断の質が分かれた案件を選ぶことです。読んですぐ「これは問題ない」で終わった案件ばかり集めると、スキルも「問題ありません」と返すだけになって差分が出ません。指摘が複数あった案件、判断に迷った案件、後から見返して考えを変えた案件のほうが情報量があります。

次に、自分の判断が記録として残っているものを選ぶことです。頭の中で判断して口頭で伝えただけの案件は、後から「自分はこう言ったはず」と再構成することになるので、そこにすでに補正が入ります。メールでもコメントでも赤入れでも、当時の言葉が残っているものを使ってください。

件数は3件から10件で十分に始められます。この数字の根拠は後で扱いますが、最初から20件を揃えようとして着手が遅れるくらいなら、3件で回し始めたほうがいいです。

材料が揃ったら、次は通し方です。ここに1つだけ、守るべき順序があります。

自分の判断を見せずに通す、5つの手順

やることは5つです。先に並べておきます。

1. 過去に自分が判断を下した実例を用意する
2. 自分の判断は見せずに、同じ入力をスキルに通す
3. 並べて差分を取る
4. 差分をスキルに戻す
5. 別の実例で繰り返す

このうち2番目だけは順序を守ってください。ここが評価全体の成否を分けます。

「見せない」を守らないと、差分は消えます

自分の判断を先に渡してからスキルを走らせると、出力はそれをなぞるだけになります。「私はこの資料についてこう指摘しました。あなたならどう見ますか」と聞けば、返ってくるのは私の指摘の言い換えです。差分はほぼ出ません。出ないので「うまく動いている」と誤解します。

だから順序はこうです。先に実例だけを渡してスキルを走らせ、出力が確定してから、自分の判断を横に置いて比べます。

これは自分で書いたスキルを自分で評価するときの構造的な問題への対処でもあります。書き手と評価者が同じ人間だと、自分が意図したとおりに出力を読んでしまいますし、自分が書いた制約に有利な入力を無意識に選んでしまいます。順序を固定することで、後付けの正当化が入る余地を物理的に消せます。

同じ発想は公式ドキュメントにもあります。Claude Code の日本語公式ドキュメントには「スキルを評価して反復する」というセクションがあり、次のように書かれています（執筆時点の2026年7月に確認）。

新しいセッションが重要です。スキルの作成から残っているコンテキストは、書かれた指示のギャップをマスクするためです。

スキルを書いた直後の同じ会話の中で試すと、SKILL.mdに書いていないことをClaudeが会話の流れから覚えている状態で動きます。だから指示の穴が見えません。書けていないのに、書けているように見える。これは自己評価の落とし穴を公式が名指ししている、なかなか貴重な一文です。

同じページには、測るべきものを2つに分けろという指示もあります。

スキルが機能していることを知るには、2 つのことを別々に測定します。Claude がそれを呼び出すべきプロンプトでそれを呼び出すかどうか、および実行するときの出力が期待と一致するかどうか。

そして、こう釘を刺しています。

スキルがトリガーされるのを見ることは、Claude がそれを見つけたことを示しており、意図したことをしたことを示していません。

呼び出されたことと、意図どおり動いたことは別だという話です。本記事が扱うのは後者ですが、「使ってほしい場面で発火しない」という問題も別に存在することは頭に置いておいてください。

Anthropic公式のスキル作成用スキル（skill-creator）の実装でも、同じ順序が明確に要求されています。テストケースごとにスキルありとスキルなしの2つを同じターンで同時に起動しろ、と書いたうえで、これは重要だと念を押し、スキルありを先に走らせて後からベースラインを取りに戻るなと明記しています（anthropics/skills）。比較対象を後から用意すると、先に見た結果に引っ張られるからです。

差分の取り方は、両方向で拾います

出力が出たら、自分の判断と並べます。拾うのは2方向です。

自分が指摘していて、AIが指摘しなかった点。 これがいちばん分かりやすい差分で、スキルに足りないものが直接見えます。

AIだけが言った点。 こちらも必ず拾ってください。中身は2種類に分かれます。ひとつはスキルが余計な観点を持っている場合で、削る対象になります。もうひとつは、自分が見落としていた場合です。後者は素直に受け取っていいと思います。スキルを作った目的は自分のコピーを作ることですが、途中で自分の穴が見つかるのは副産物として悪くありません。

指摘の内容が同じでも、言い方の強さが違う場合は別枠で記録しておきます。ここは次のセクションで扱う分類に効いてきます。

記録する形を決めておきます

差分は必ず書き出してください。頭の中で「だいたい合っていた」と処理すると、2回目以降との比較ができなくなります。列は5つあれば足ります。

入力（案件）	自分の指摘	AIの指摘	分類	対処
B社向け提案書レビュー	市場規模の出典が二次情報のまま	（言及なし）	観点の欠落	出典の一次性を確認する軸を追加
B社向け提案書レビュー	導入効果の試算が楽観的すぎる	導入効果の記載を確認すべき	強度のズレ	「試算は下振れケースも併記させる」と明記
C社向け提案書レビュー	（言及なし）	competitor分析の記載が薄い	自分の見落とし	軸として追加
D社（創業2年）向け	中期計画の整合は今は問わない	中期計画との整合性が不明	文脈の欠落	相手のフェーズを実行前に確認する

この表は使い回します。2回目、3回目と実例を通すたびに行を足していってください。ここに蓄積された行が、後で「この観点は繰り返し抜けている」を教えてくれます。

1件で結論を出さない理由

5番目の「別の実例で繰り返す」は、面倒に見えて省きたくなる工程です。ですが、ここには前のセクションで触れた非決定性の話が効いてきます。

同じ入力でも出力は毎回同じではない。temperature 0でも1000回で80通りに割れた、という実測がありました。正解率が実行間で最大15%変動するという報告もありました。

つまり1件だけ通して差分が出たとき、それがスキルの構造的な欠落なのか、その回のばらつきなのかは区別できません。3件通して同じ観点が3回とも抜けていれば、それは構造です。1件だけなら判断を保留したほうが安全です。

逆に、スキルを直した後に1件だけ通して「良くなった」と判断するのも危ういです。改善幅がばらつきの幅より小さければ、それは改善の証拠になりません。

とはいえ、個人がスキルを1本育てるのに統計処理をする必要はありません。同じ観点が複数の実例で繰り返し抜けているかどうかを見る、という運用でじゅうぶんです。3件で足りなければ5件にする、それだけです。

新人に仕事を渡すのと同じことをしています

この5つの手順は、新しく入ってきた人に仕事を渡すときの流れとほぼ同じです。

最初は自分の判断を都度渡して補正します。「ここはこう見るんだよ」「その指摘は優先度が低い」。回数を重ねると渡す量が減っていきます。ある時点から、自分が言おうとしていたことを先に言うようになります。

大事なのは、新人教育で「評価シートを先に作ってから育てる」ことはしない、という点です。実際の仕事を渡して、出てきたものに赤を入れる。赤を入れているうちに、自分が何を見ていたのかが自分でも言葉になっていきます。前のセクションで見た criteria drift は、まさにこれを研究の言葉で言い直したものです。

なお、この手順は判断業務に限りません。図解を作るスキルでも文書を整形するスキルでも、「過去に自分が作った成果物」があれば同じ形で回せます。別ドメインの例としてはClaude FableでSVG図解を量産するで作ったスキルがありますが、あれも評価は「以前に自分が手で作った図と並べる」でやっています。

さて、差分が取れたとします。ここからが本題で、差分は全部同じように扱ってはいけません。

差分を3つに分けると、打ち手が変わります

差分が出たとき、いちばんやりがちなのは全部まとめて「SKILL.mdに書き足す」で処理することです。抜けていた観点を追加し、強すぎた表現を弱め、例外を書き添える。3回もやるとSKILL.mdが膨れ上がり、どの指示も効かなくなります。

差分は3種類あります。分類してから打ち手を変えてください。先に一覧を置いておきます。

分類	どういう状態か	見分け方	打ち手
観点の欠落	自分が見ている軸がスキルに入っていない	その観点がSKILL.mdに書かれていない	軸を追加する（判定の仕方まで書く）
強度のズレ	軸は合っているが指摘の厳しさ・優先度が違う	書いてあるが、相手が誰でも正解は同じ	トーンと優先順位を明記する
文脈の欠落	相手の属性で正解が変わるのに一律の答えを返す	書いてあるが、相手によって正解が変わる	スキルを分割するか、実行前に確認を挟む

3つ目だけは軸の追加で直りません。ここを取り違えると、直すほど悪くなります。

1. 観点の欠落

自分が見ている軸が、スキルにそもそも入っていない状態です。

さきほどの表でいえば「市場規模の出典が二次情報のまま」がこれにあたります。私は出典の一次性を毎回見ているのに、SKILL.mdにはその軸が書かれていなかった。だから出力に出てこない。

対処は素直です。軸を追加する。ただし追加するときは、判定の仕方まで書いてください。「出典を確認する」だけでは弱くて、「引用元が一次資料か、他の記事の孫引きかを区別し、孫引きなら元の資料に当たれと指摘する」くらいまで書くと再現します。

観点の欠落は3種類のなかで最も多く出ます。そして最も直しやすい。差分の大半がこれで処理できるなら、そのスキルは健全な状態にあります。

2. 強度のズレ

軸は合っているのに、指摘の厳しさや優先度が違う状態です。

表の2行目がこれです。私は「導入効果の試算が楽観的すぎる」と踏み込んだのに、スキルは「導入効果の記載を確認すべき」と柔らかく流している。見ている場所は同じで、踏み込みの深さが違います。

このタイプは見逃されやすいので注意してください。出力を読むと「一応その話には触れている」ので、抜けとして認識されないのです。ですが実務では、この差が「使える指摘」と「読み飛ばす指摘」を分けます。

対処は、トーンと優先順位を言葉で明記することです。

• 指摘は重要度順に並べる。判断を変えさせるべき指摘を先頭に置く
• 数値の妥当性に疑いがある場合は「確認してください」ではなく「この前提だと成立しません」と書く
• 表現の好みに関する指摘は、末尾にまとめて1行で済ませる

前のセクションで「厳しさが足りない」と書き足してブレた話をしましたが、あれが失敗するのは強度を抽象語で指定しているからです。「率直に」「遠慮せず」は解釈の幅が広すぎます。どの種類の指摘をどこに置くか、という形に落とすと安定します。

3. 文脈の欠落

3つ目の文脈の欠落は、対処を取り違えやすいところです。

表の4行目を見てください。創業2年の会社向けの提案で、スキルは「中期計画との整合性が不明」と指摘してきました。一般論としては正しい指摘です。ですが相手が創業2年なら、そもそも中期計画は無いか、あっても実質的な意味を持ちません。私はそこを問いませんでした。

つまり、相手の規模やフェーズや業種によって正解が変わるべきなのに、スキルが一律の答えを返している状態です。

ここで絶対にやってはいけないのが、軸の追加で対処することです。「ただし相手が創業3年以内の場合は中期計画を問わない」と書き足す。次は業種が違う案件でズレるので「ただし製造業の場合は」と足す。規模でもズレるので「ただし従業員50名未満の場合は」と足す。

半年後には、例外条項が本文より長いSKILL.mdができあがります。そしてClaudeは、どの条件を優先すべきか判断できなくなります。

文脈の欠落は、指示の不足ではなく設計の問題です。 打ち手は2つあります。

ひとつは、スキルを分割すること。スタートアップ向けと大企業向けで見るべき観点が根本的に違うなら、1本にまとめるより2本に分けたほうが両方とも精度が上がります。

もうひとつは、実行前に確認を挟むこと。SKILL.mdの冒頭に「作業を始める前に、相手の企業規模と事業フェーズを確認する」と書いておけば、Claudeは1行質問してから動きます。これで一律の答えを返す問題は消えます。

どちらを選ぶかの判断や、スキルを層に分けて積む考え方についてはClaudeのスキル設計をメダリオンアーキテクチャで整理するで扱いました。文脈の欠落が繰り返し出るようになったら、そちらを読んでみてください。

判定フロー

3分類の見分け方を手順にしておきます。差分が1件出るたびに、これを通してください。

差分が出た
  │
  ├─ 自分が指摘した観点は、SKILL.md に書いてあるか?
  │
  ├─ 書いていない ────────────────→ 【観点の欠落】
  │                                    軸を追加する（判定の仕方まで書く）
  │
  └─ 書いてある
       │
       └─ 同じ入力に対して、常に同じ答えが正解か?
            │
            ├─ Yes（相手が誰でも同じ）───→ 【強度のズレ】
            │                                トーンと優先順位を明記する
            │
            └─ No（相手による）─────────→ 【文脈の欠落】
                                             スキルを分割 or 実行前に確認を挟む

分岐は2つだけです。「書いてあるか」と「相手によるか」。この2問で3分類に振り分けられます。

判定に迷ったときは、同じ差分が別の案件でも出るかどうかを見てください。相手が変わっても同じ差分が出るなら観点か強度の問題で、相手によって出たり出なかったりするなら文脈の問題です。

全部を訓練に使わないでください

最後にひとつ、差分を戻すときの注意があります。

用意した実例のうち、2〜3件は手をつけずに残しておいてください。差分を戻す作業には使わず、直した後の確認だけに使う。いわゆるホールドアウト（取り置き）です。

なぜかというと、使った実例に対しては必ず出力が良くなるからです。その実例の差分を見ながら直しているので当たり前です。ですが、そのスキルが他の案件でも動くかどうかは、それでは分かりません。

同じ考え方はAnthropic公式のskill-creatorにも実装されています。スキルの説明文を最適化するループでは、評価セットを訓練用60%とテスト用40%に分割し、訓練スコアではなくテストスコアが最も良かった説明文を選ぶ設計になっています。理由は過学習（手元のデータにだけ合わせ込んでしまうこと）を避けるためだと明記されています。

同じドキュメントには、こうも書かれています。

But if the skill you and the user are codeveloping works only for those examples, it’s useless.

一緒に開発しているそのスキルが、それらの例でしか動かないなら、それは無価値である。手厳しいですが、そのとおりだと思います。

10件用意したなら7件で直して3件で確認する。3件しか用意できなかったなら、2件で直して1件で確認する。それでも「取り置きがある」という事実が、直しすぎを止めてくれます。

さて、ここまで来ると次の欲が出てきます。この差分の判定自体を自動化できないか、という話です。

評価のためのスキルを別に作ると、たいてい遠回りになります

差分を何度か取っていると、この作業自体を自動化したくなります。評価軸を書いたスキルをもう1本作って、出力に点数を付けさせて、スコアが上がったかどうかで判定する。手作業で並べて見比べるより、ずっと効率的に見えます。

結論から言うと、多くの場合これは労力に見合いません。理由は4つあり、どれもLLMに採点させることの構造的な性質から来ています。私も一度は評価用のスキルを立てようとして、途中で手を止めました。

理由1. 僅差の比較でこそ外します

LLMに評価させる手法は LLM-as-a-judge（LLMを判定役に立てる方式）と呼ばれていて、学術的にもよく調べられています。以下では、この採点役として使われるLLMを「judge」と表記します。

参照数の多いMT-Benchの論文（Zheng ら、NeurIPS 2023 で査読を経て採択）に、見落とされがちな観察があります。MT-Benchは、複数のモデルの回答の優劣を判定させて、その判定が人間の判断とどれくらい一致するかを測るために作られた評価用の問題集です。

the agreement between GPT-4 and human progressively increases in line with the performance disparity of the model pairs, from 70% to nearly 100%.

GPT-4と人間の一致率は、比較対象となる2つのモデルの性能差が開くほど上がっていき、70%からほぼ100%まで変化する、という報告です。

裏を返せば、比べる2つが拮抗しているときほど当てにならないということです。そしてスキルの改善は、v3とv4のどちらがマシかという僅差の比較の連続です。判定してほしい場面が、judgeが最も苦手とする条件そのものになっています。

理由2. 「引き分け」を引けません

さらに厳しい数字があります。LLM-as-a-judgeの研究を網羅したサーベイ論文（Gu ら、2024年投稿・2025年改訂。査読前のプレプリントなので、その前提で読んでください）が、独自の実測を載せています。

人間が「引き分け」と判定したケースについて、各モデルの正答率がこうなっています。

評価者となったモデル	人間が「引き分け」と判定したケースの正答率
GPT-4-turbo	29.73%
o3-mini	42.31%
o1-mini	23.57%
gemini-2.0-thinking	13.20%

同じ表で、人間が明確にどちらかを選んだケースの正答率は65〜78%あります。差がはっきりしている問題は解けるのに、差がない問題は解けない。

スキル改善で最も頻出する判定が何かというと、「この2つは実質的に同じ」です。直したけれど変わっていない、という判定ができないと、無駄な変更を積み上げ続けることになります。

理由3. 長さと具体性に引っ張られます

MT-Benchの論文には、意地の悪い実験が載っています。番号付きリストを含む回答を選び、そのリストを「新しい情報を一切加えずに言い換えろ」と指示して複製し、元のリストの前に挿入したものを作りました。5項目が10項目になりますが、増えた5項目は元の言い換えです。中身は1文字も増えていません。

冗長版のほうが良いと誤判定した割合は次のとおりです。

評価者となったモデル	誤判定率
Claude-v1	91.3%
GPT-3.5	91.3%
GPT-4	8.7%

同じ論文が、完全に同一の2つの回答を渡した場合には常に引き分けを返すことを確認しています。つまりこれは判定能力の欠如ではなく、長さそのものへの選好です。

サーベイ論文はもうひとつ、具体性への偏りを挙げています。出典の引用や数値や専門用語を含む回答を高く評価する傾向があり、しかもその内容が事実として正しいかを確認しないため、もっともらしい嘘を助長する方向に働くと指摘されています。

ここが実務上いちばん困ります。スキルの改善は、しばしば余計な指示を削る方向に進みます。長い説明を短くする、曖昧な語を消す、重複した軸を統合する。judgeの選好軸は、その逆を向いています。削って良くしたのに点数が下がる採点者を、信じて使えるでしょうか。

理由4. 定番の対策が実測で効いていません

「では判定の精度を上げればいい」と考えて、よく採られる手当てが2つあります。理由も一緒に書かせる、自己検証させる。サーベイ論文はこれを実測しています。

手法	人間との一致率	提示位置を入れ替えたときの一貫性
そのまま判定	54.72%	68.78%
理由を併記させる	52.47%	48.97%
自己検証させる	54.86%	69.31%
5回のうち最良を採る	51.95%	58.72%

理由を書かせると、一致率も一貫性も下がっています。論文は、自己説明がより深いバイアスを持ち込んだのではないかと推測しています。自己検証はほぼ無変化で、原因をモデルの過信に帰しています。

効果が確認できたのは、選択肢の提示位置を入れ替えることと、複数回走らせて多数決を取ることだけでした。どちらも判定能力に頼らない機械的な処置です。

「一致率85%」を引用するときの条件

LLM-as-a-judgeを勧める文脈でよく出てくるのが「GPT-4と人間の一致率は85%で、人間同士の81%より高い」という数字です。これはMT-Benchの実測で、事実です。ただし条件があります。

この85%は引き分け票を除外した集計（論文でS2と呼ばれる条件、ランダムに答えた場合のベースラインが50%）でのみ成立します。引き分けを含めた集計（S1、ベースライン33%）では、GPT-4と人間の一致率は66%まで落ちます。

別の査読論文の数字も見ておきます。北京大学らによるLarge Language Models are not Fair Evaluators（ACL 2024 採択）は、勝ち・引き分け・負けの3値で人手正解と突き合わせています。素のGPT-4は精度52.7%、カッパ係数0.24でした。人間の平均は精度71.7%、カッパ係数0.54です。カッパ係数は偶然の一致を差し引いた一致度の指標で、0.24は「弱い一致」の水準にあたります。

同じ論文は、位置を入れ替えたりサンプリングを工夫したりして人間並みに近づけることもできると示していますが、その構成では上位20%を人間が見直す必要があり、コストが$0.10から$18.3に跳ね上がっています。「LLMに任せれば安い」という前提が、そこで崩れます。

採点役そのものが、偏ったりずれたりします

もうひとつ、個人開発で最も自然な構図が、最も避けるべき構図でもあります。

Claudeで書いたスキルをClaudeに採点させる。GPTで書いたプロンプトをGPTに採点させる。ここに self-preference（自己選好）が直撃します。

LLM Evaluators Recognize and Favor Their Own Generations（Panickssery ら、NeurIPS 2024 採択）は統制実験でこれを実証しました。GPT-4は73.5%の精度で自分の出力を他のモデルや人間の文章から見分けられ、自分の出力を不均衡に高く評価します。しかも3モデルとも、人間が書いた文章に対して最も強い自己選好を示したと報告されています。

ICLR 2025 で採択されたJustice or Prejudice?は、回答の出所を伏せてもこの偏りが残ることを実測し、生成と判定には別のモデルを使えと勧告しています。

時間の経過による問題もあります。サーベイ論文が evaluation drift（評価のずれ）として挙げているものです。モデルの更新や文脈の変化によって、judgeの判定基準そのものが時間とともにずれていく。論文は「3月版のモデルでは許容と判定された回答が、6月版では新しい安全性チューニングによりペナルティを受ける」という例を挙げています。

個人が数か月かけてスキルを育てる場合、スコアが上がったのが自分の改善のおかげなのか、モデルが更新されたせいなのかを切り分ける手段がありません。手作業で差分を見ていれば「前より自分の判断に近くなった」は自分の目で確認できますが、スコアだけを見ていると根拠を失います。

実務家の側からも同じ結論が出ています

学術の話ばかりになったので、現場の声も挙げておきます。

30社以上のAI製品開発を支援してきた Hamel Husain がLLM-as-a-Judgeの実践ガイドで、judgeを作る手順を一通り説明したうえで、こう書いています。

The real value of this process is looking at your data and doing careful analysis. … I would go as far as saying that creating a LLM judge is a nice “hack” I use to trick people into carefully looking at their data!

このプロセスの本当の価値は、自分のデータを見て注意深く分析することにある。LLMのjudgeを作るというのは、人々にデータを注意深く見させるために自分が使っている便利な「口実」だと言ってもいいくらいだ、と。

さらに念を押しています。

However, you can never completely eliminate looking at your data! This is precisely the step that most people skip. Don’t be that person.

データを見る工程を完全になくすことは決してできない。そしてここが、ほとんどの人が飛ばす工程だ。そういう人になるな。

judgeを作ること自体が悪いわけではありません。ただ、その価値の大半は作る過程で人間がデータを直視することにあって、完成したjudgeが自動で回ることにはない、という指摘です。

だとすれば、個人が自分のスキルを1本育てるだけなら、判定の自動化を飛ばして直視の部分だけ残せば足ります。実データにスキルを走らせて、差分を見て、そのままスキルに戻す。これで回ります。

評価の仕組みを先に整備しようとして、本体のスキルが進まなくなるのは、よくある遠回りです。

とはいえ、仕組み化したほうがいい場面もあります。その境界を最後に示します。

仕組み化する価値が出る3条件と、完成の指標

原則として評価スキルは要らない、と書きました。ただし例外はあります。次の3つのどれかに当てはまるなら、仕組み化に投資する価値が出てきます。

条件1. 同じスキルを複数人が使っている

自分ひとりで使っている間は、差分を見るのは自分です。判断の正解も自分の中にあります。だから手作業で足ります。

ところが同じスキルをチームで使い始めると、話が変わります。誰の判断を基準にするのかが決まりません。Aさんは「この指摘は必要」と思い、Bさんは「余計」と思う。両方の差分を戻すと、スキルは矛盾した指示を抱えることになります。

このとき必要なのは評価の自動化というより、判断の基準を誰が持つかを決めることではないでしょうか。そのうえで、基準を持つ人が全部を見なくても済むように、機械的にチェックできる部分だけを切り出す。順番を逆にすると、誰の基準か決まらないまま仕組みだけができあがります。

個人のスキルを組織に広げるときの摩擦については作った人以外が使わないAIスキルで扱いました。品質のばらつきが問題になる前に読んでおくと、順番を間違えずに済むと思います。

条件2. 更新のたびに退行が起きる

スキルを頻繁に直していると、こういうことが起きます。新しい観点を足したら、前は出せていた指摘が出なくなった。表現を調整したら、別の場面での挙動が変わった。

ソフトウェア開発では、これを退行（regression）と呼びます。国際規格のISO/IEC/IEEE 29119-1:2013は、退行テストをこう定義しています。

testing following modifications to a test item or to its operational environment, to identify whether regression failures occur

テスト対象またはその動作環境への変更のあとに、退行による不具合が発生していないかを特定するために行うテスト、という意味です。同じ規格の本文はもう少し踏み込んで、目的をこう書いています。

The intent of regression testing is to ascertain that modifications have not caused defects in unchanged parts of the system.

退行テストの意図は、変更が変更していない部分に欠陥を生んでいないことを確かめることにある。ここが重要で、見るべきは直した箇所ではなく、直していない箇所です。

プロンプトでも同じことが起きるのは、実測で示されています。カーネギーメロン大学らのプロンプト書式への感度を定量化した研究は、意味を変えない書式の変更だけで最大76ポイントの性能差が出たと報告しています（LLaMA-2-13Bでの測定、320種類の書式×53タスク）。より新しい区切り文字に関する研究は、例と例を区切る文字を1文字変えるだけでMMLUというベンチマークのスコアが±23%動き、モデルの順位すら入れ替えられると報告しています。

SKILL.mdを1行いじった影響は、直した箇所の外側に飛び火する。そう考えて測るのが安全です。

ただし、ここには非決定性の壁があります。同じテストが通ったり落ちたりする状態を放置すると、退行テストは死にます。Martin Fowler が2011年の記事Eradicating Non-Determinism in Testsでこう警告しています。

Once you start ignoring a regression test failure, then that test is useless and you might as well throw it away.

退行テストの失敗を無視し始めた時点で、そのテストは無価値になり、捨てたほうがマシになる。

LLMを相手にする以上、非決定性は消せません。だから合否ではなく合格率で扱います。同じケースを3回走らせて2回通れば「だいたい通る」、5回走らせて1回しか通らなければ「まだ不安定」。この粒度で十分です。

条件3. 判断できる人がボトルネックになっている

出力の良し悪しを判断できる人が組織に1人か2人しかいなくて、その人が全部を見ないと先に進まない。よくある状況です。

このとき仕組み化の目的は精度向上ではなく、その人が見る量を減らすことになります。明らかに問題ないケースと明らかに駄目なケースを機械的に振り分けて、判断が割れそうなものだけ人に回す。前のセクションで見た論文も、人手を上位20%に絞ることで人間並みの精度に届かせていました。

チェックリスト

3条件を並べておきます。

• 同じスキルを自分以外の人が日常的に使っている
• スキルを月に何度も更新していて、更新のたびに前の挙動が変わっている
• 出力の良し悪しを判断できる人が限られていて、その人の時間が詰まっている

どれにも当てはまらないなら、差分を戻すループだけで足ります。当てはまるものが出てきたら、そのとき考えれば間に合います。先に仕組みを作ると、たいてい使われないまま残ります。

完成の指標は「差分が出なくなること」

最後に、いつまで続けるのかという話をします。

個人が作ったスキルには、ベンチマークがありません。精度95%と言われても、何に対しての95%なのか意味が定まりません。スコアを置いても、そのスコアが上がったから良くなったとは言えない。前のセクションで見たとおり、判定する側にも偏りがあります。

だから、指標は数字ではなく状態で置きます。

使うたびに差分をスキルへ戻していって、差分が出なくなったら、そのスキルは自分の判断を再現できている。

これがもっとも分かりやすい停止条件だと思っています。1回目は差分が10個出る。3回目は4個。6回目は1個で、それも「まあどちらでもいい」レベル。そこまで来たら、そのスキルは自分の代わりに一次判断を返せる状態になっています。

同じ形の停止条件は、実務家の側からも出ています。Hamel Husain は評価用の件数について、こう書いています。

My heuristic is that I start with around 30 examples and keep going until I do not see any new failure modes. From there, I keep going until I’m not learning anything new.

30件くらいから始めて、新しい失敗パターンが見えなくなるまで続ける。そこからさらに、自分が新しいことを何も学ばなくなるまで続ける、という経験則です。

件数を固定しないところが大事です。判定軸が多いスキルほど収束は遅くなります。NAACL 2025 で採択された長文脈での実例学習に関する研究は、性能が最大値の95%に達する実例数を「飽和点」と定義して測っていますが、ラベルが6種類のタスクでは20件、150種類のタスクでは750件から1000件と、50倍の開きがありました。自分のスキルが何件で収束するかは、やってみないと分かりません。

なお、最初に3件から10件で始めていいと書いた根拠もここにあります。EMNLP 2022 で採択された実例の役割を検証した研究は、分類系のタスクについて「実例数が8以上になると性能はあまり上がらない」と報告しています。少数の領域は伸びが急で、そこを過ぎると緩やかになる。だから最初の数件が最も効きます。

ただし混同しないでほしいのは、この件数は基準を言葉にするための材料の数であって、統計的にどちらが良いかを判定するための標本数ではないということです。EMNLP 2020 の検定力に関する研究は、自然言語処理の論文で一般的な「3人が100件を評価する」設計ですら、効果量が0.2未満だと検出できないと報告しています。10件で「v3よりv4のほうが3%良い」と言うことはできません。「この観点が繰り返し抜けている」と言うことはできます。目的が違えば必要な件数も違う、というだけの話です。

差分は、貯めておかないと意味が薄れます

ここまでの手順で、いちばん効いてくるのに見落とされやすいのが、差分の記録です。

1回目の差分だけを見ても分かることは限られています。価値が出るのは、3回目と6回目を並べたときです。「この観点は毎回抜けている」「強度のズレは減ったが文脈の欠落は増えた」といった傾向は、蓄積があって初めて見えます。

ところが差分をどこに置くかを決めていないと、その日のチャット履歴に流れて消えます。翌週に同じ差分を見つけて「これ前にもあったような」と思うのに、確認できない。この状態だと、何度回しても学習が積み上がりません。

判断の記録と、その判断の根拠になった資料が、同じ場所に貯まっていく状態を作っておくと、この問題が消えます。リサーチAIのSnorbeは完全記憶型のナレッジグラフを持っていて、投げた問いと調べた結果、そこから導いた判断が関係ごと蓄積されていきます。

検索用のクエリを組み立てる必要はなく、普段の日本語のまま投げられるので、記録を残す作業そのものの手間がほとんどかかりません。判断の根拠として使った一次資料も、特許（JPO・EPO・Google Patents）や学術（arXiv・PubMed・Semantic Scholar）まで横断して同じ場所に紐づきます。

評価用に新しい基盤を立てるのではなく、判断が貯まる場所を1つ持っておく。差分を毎回戻す運用は、記録が増えるほど効いてきます。

よくある質問

Q1. 自作したAIスキルが効いているかは、どうやって測ればいいですか

過去に自分が判断を下した実例を用意し、自分の判断を見せない状態で同じ入力をスキルに通して、出てきた出力と自分の判断を並べて差分を取ります。差分をスキルへ戻し、別の実例で繰り返します。評価用のデータセットを新しく作る必要はありません。レビューコメントや赤入れなど、すでに手元にある判断の記録が正解データとして使えます。Anthropicのスキル作成のベストプラクティスも、評価を実行する組み込みの手段は現時点ではなくユーザーが自分の評価システムを作れる、と明記しています。

Q2. 評価用の実例は何件必要ですか

3件から10件で始められます。EMNLP 2022 で採択された実例の役割を検証した研究は、分類系のタスクについて実例数が8以上になると性能があまり上がらないと報告していて、少数の領域ほど伸びが急です。

ただしこの件数は判定基準を言葉にするための材料の数であって、統計的にどちらのバージョンが良いかを判定するための標本数ではありません。EMNLP 2020 の検定力に関する研究は、3人が100件を評価する設計でも効果量0.2未満は検出できないと報告しています。10件で「3%良くなった」とは言えませんが、「この観点が繰り返し抜けている」とは言えます。

Q3. 自分で作ったスキルを自分で評価しても意味がありますか

手順に順序を入れれば成立します。自分の判断を先に見せてからスキルを走らせると、出力がそれをなぞるだけになって差分が消えます。逆に、実例だけを渡して出力を確定させてから比べれば、後付けの正当化が入る余地がなくなります。Claude Code の日本語公式ドキュメントも「新しいセッションが重要です。スキルの作成から残っているコンテキストは、書かれた指示のギャップをマスクするためです」と、同じ会話の中で試すことの危険を指摘しています。Anthropic公式のskill-creatorも、スキルありとスキルなしを同じターンで同時に起動し、スキルありを先に走らせて後からベースラインを取ることを禁止しています。

Q4. LLMに採点させて自動化したほうが効率的ではないですか

この用途では割に合いません。MT-Benchの論文（NeurIPS 2023 採択）は、比較対象の性能差が開くほど人間との一致率が上がり70%からほぼ100%まで変化すると報告しています。裏を返せば拮抗した比較ほど外れるということで、スキル改善は僅差の比較の連続です。

同じ論文の実験では、中身を増やさずリストを言い換えて長さだけ倍にした回答を、Claude-v1とGPT-3.5が91.3%の確率で「良くなった」と誤判定しました。さらにLLM-as-a-judgeのサーベイ論文（査読前のプレプリント）の実測では、理由を併記させると人間との一致率が54.72%から52.47%へ下がり、自己検証もほぼ無効でした。

Q5. 「GPT-4と人間の一致率は85%」という数字は使えますか

条件を書き添える必要があります。この85%はMT-Benchの論文の実測ですが、引き分け票を除外した集計（ランダムに答えた場合のベースラインが50%）でのみ成立する数字です。引き分けを含めた集計（ベースライン33%）では66%まで落ちます。勝ち・引き分け・負けの3値で人手正解と突き合わせたACL 2024の別の査読論文では、素のGPT-4は精度52.7%、カッパ係数0.24でした。人間の平均は精度71.7%、カッパ係数0.54です。

Q6. 差分が出たとき、どう直し分ければいいですか

3つに分類してから打ち手を変えます。自分が見ている軸がスキルに書かれていないなら観点の欠落で、軸を追加します。軸は書いてあるのに指摘の厳しさや優先度が違うなら強度のズレで、トーンと優先順位を明記します。相手の規模やフェーズや業種によって正解が変わるべきなのに一律の答えを返しているなら文脈の欠落で、これは軸の追加では直りません。例外条項を積み上げるとSKILL.mdが膨れて全部の指示が効かなくなるため、スキルを分割するか、実行前に相手の属性を確認する設計に切り替えます。見分け方は「SKILL.mdに書いてあるか」「相手によって答えが変わるか」の2問です。

Q7. 評価を仕組み化したほうがいいのはどんなときですか

3つの条件のどれかに当てはまったときです。第一に、同じスキルを複数人が使っていて品質のばらつきが問題になっている場合。第二に、更新頻度が高く更新のたびに退行（前は出来ていたことが出来なくなる現象）が起きる場合。第三に、出力の良し悪しを判断できる人が限られていて、その人の時間がボトルネックになっている場合です。

第二の条件については、ISO/IEC/IEEE 29119-1:2013が退行テストの意図を「変更が変更していない部分に欠陥を生んでいないことを確かめること」と定義しており、そのまま転用できます。ただしLLMは同じ入力でも出力が揺れるため、合否ではなく合格率で扱ってください。

Q8. スキルはいつ完成したと判断できますか

差分が出なくなったときです。個人が作ったスキルにはベンチマークがないので、精度やスコアを置いても基準になりません。使うたびに差分をスキルへ戻していって、出てくる差分が減り、残るものが「まあどちらでもいい」レベルになったら、そのスキルは自分の判断を再現できています。実務家のHamel Husainも、30件くらいから始めて新しい失敗パターンが見えなくなるまで続ける、という停止条件を挙げています。収束に必要な件数はスキルの複雑さで変わり、NAACL 2025 採択の研究では判定軸の数によって20件から1000件まで50倍の開きがありました。