自分で書いた Agent Skill の中に、規格の定義が正反対で書かれているのを見つけました。
しかもそれを、スキルの品質を採点するツールにかけても、点数はほとんど動きませんでした。
この記事は、その実験の記録です。
検証環境: Windows 10 / Claude Code 2.1.243
何が間違っていたか
境界値分析（Boundary Value Analysis）を扱うスキルです。ISTQB の教科書どおりに書いたつもりでした。
| 2-point | 境界値そのもの + 隣接 1 値 | min, min+1, max-1, max の 4 点 |
これが逆です。 ISTQB Foundation Level Syllabus v4.0.1 §4.2.2 の原文はこうです。
In 2-value BVA (Craig 2002, Myers 2011), for each boundary value there are two coverage items: this boundary value and its closest neighbor belonging to the adjacent partition.
（2-value BVA では、各境界値につき2つのカバレッジ項目がある。その境界値と、隣接パーティションに属する最も近い隣接値である）
「隣接パーティション」は範囲の外側です。[min, max] なら min-1 と max+1。私が書いた min+1 と max-1 は内側で、まったく別のものを指していました。
さらに悪いことに、同じ文書の中で矛盾していました。
（説明文）境界値そのものと、境界を1だけ越えた値の組を取る
（結論） (min, min+1) と (max-1, max) の 4 点セットが正しい
「越えた値」と書きながら、越えていない値を挙げています。 書いた本人が読み返しても気づきませんでした。
採点ツールにかけてみた
いま Agent Skills を評価するツールがいくつかあります。その1つ、darwin-skill は9次元のルーブリックで100点満点の採点をします。
| # | 次元 | 重み |
|---|---|---|
| 1 | Frontmatter Quality | 7 |
| 2 | Workflow Clarity | 12 |
| 3 | Failure Mode Encoding | 12 |
| 4 | Checkpoint Design | 6 |
| 5 | Actionable Specificity（具体的なパラメータ・形式・例） | 18 |
| 6 | Resource Integration | 4 |
| 7 | Overall Architecture | 12 |
| 8 | Measured Performance | 23 |
| 9 | Anti-patterns / Blacklist | 6 |
定義が逆だった版と、修正後の版を用意して、独立したエージェントに採点させました。 互いの存在は知らせていません。
定義が逆の版 : 38.8 / 100
修正後の版 : 54.6 / 100
（2026-08-25 時点の採点。LLM の採点なので、同じ入力でも実行のたびに数点は動きます。）
15.8点の差がつきました。 ただしこの比較には大きな穴があります。 別々のエージェントが片方ずつ採点したので、採点者の甘辛が混ざっています。darwin-skill 本来の設計は「1人が両方を1回で読む」ペア評価なので、そこは再現できていません。
点数は動いたが、そこではない
見るべきは合計ではなく、どの次元が動いたかです。
定義の誤りが直接関わる次元5（Actionable Specificity、重み18）は、6点から7点。1点しか動いていません。
理由を考えると、当たり前でした。次元5が評価するのは「具体的なパラメータ、形式、例があるか」です。
| 2-point | 境界値そのもの + 隣接 1 値 | min, min+1, max-1, max の 4 点 |
これは極めて具体的です。 パラメータも点数も明示されています。内容が逆であることは、この軸では減点になりません。
具体的に書かれた誤りは、むしろ高得点になります。
darwin-skill のルーブリックを読み直すと、9次元のどこにも「引用した事実が正しいか」がありません。 次元6（Resource Integration）は「参照先のパスが辿れるか」を見ますが、中身の正しさは見ません。
自作の評価スキルも同じだった
スキルそのものを監査する自作のスキルもあります。念のため、同じ観点で調べました。
規格 : 0 件
引用 : 0 件
出典 : 0 件
事実 : 0 件
正確 : 0 件
1件もヒットしません。 見ているのは description の書き方、行数、frontmatter の記法、スキル同士の競合でした。
「スキルとしての品質」と「書いてある事実の正しさ」は、別の軸です。 私は前者しか測っていませんでした。
聞いたら、気づいた
ここからが本題です。
採点を頼むとき、ルーブリックとは別にこう書き添えていました。
このドキュメントに問題があると感じた箇所があれば、次元に関係なく指摘してください
2人とも、矛盾を見つけました。
最重要：同一セクション内の直接矛盾
表：2-point=min, min+1, max-1, max（内側寄せ）
本文：2-value =(min-1, min)と(max, max+1)
正しいのは本文側で、表が誤りです。
点数には出ないが、聞けば分かる。 これが実験でいちばん意外だった点です。
しかも、私が見落としていた誤りまで拾ってきました。
-
ISO/IEC 29119-4 §6.2— 29119-4 は Clause 5 が仕様ベース技法、Clause 6 は構造ベース。BVA が §6.2 に来るのは考えにくい -
ISTQB ATA v3.1.2 §1.3.2— ATA の第1章は risk-based testing で、技法は別章 -
BS 7925-2:1998 §5.1.2— 本文から一度も引かれていない孤立参照
どれも有料規格で、私には裏が取れません。 そこで条番号を伴う参照そのものをやめました。 規格名は残し、番号だけ落とす。29箇所ありました。
無料で公開されている ISTQB Foundation Level Syllabus を一次の根拠にする、という方針に切り替えています。
ただし、1件は誤りだった
2人が一致して指摘した項目が6件ありました。そのうち1件は外れです。
prompt_injection_detectedが飾りになっている。出力JSONにあるのに、検出手順が本文に一切ない
手順は存在しました。 別のファイル（共通プロンプトのテンプレート）にあり、しかも良く書けていました。
PII 候補そのものを引用してはならない。「phone-like 11 digits in line 234」のような汎用表現で記録する（本 skill 自体が PII を漏らさないため）
2人とも、渡されたファイル1本しか見ていませんでした。 そのファイル単体では確かに欠落に見えます。
一致は信頼の材料にはなりますが、正しさの保証ではありません。 指摘をそのまま受け入れていたら、既にある手順を二重に書くところでした。
指摘を鵜呑みにしないのは、AI の指摘でも同じです。
何をどう直したか
結局、今日の作業はこうなりました。
| 直したもの | 箇所 |
|---|---|
| 2-point の定義（正反対だった） | 41 |
| 参照している節番号の誤り | 11 |
| 裏の取れない条番号の削除 | 29 |
| 存在しない論文引用の差し替え | 1 |
41箇所と29箇所という数字が、この問題の性質を表しています。 定義を1つ間違えると、それを参照する側に全部伝播します。採点ツールを何度回しても、この41箇所は減りません。
まとめ
- スキルの採点ツールは、構造を測る。 手順の明確さ、具体性、失敗時の分岐、チェックポイント
- 書いてある事実が正しいかは、どの次元にも入っていない（darwin-skill の9次元、自作の監査スキルとも）
- 具体的に書かれた誤りほど、具体性の次元では高得点になる
- ルーブリックとは別に「問題があれば指摘して」と頼むと、LLM は矛盾に気づく。 点数には出ない
- AI の指摘も鵜呑みにしない。 2人が一致した指摘のうち1件は誤りだった
- 有料規格の条番号は書かない。 裏が取れないものは、規格名だけ残して番号を落とす
点数が上がることと、中身が正しいことは別です。 採点ツールを使うなら、点数とは別に「おかしいところはないか」を聞く工程を足しておくと、拾えるものが変わります。
参考
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1 — §4.2.2 Boundary Value Analysis
- alchaincyf/darwin-skill — 9次元ルーブリックによるスキル最適化
- microsoft/SkillOpt
- 検証環境: Windows 10 / Claude Code 2.1.243
※ 引用は原文と日本語訳を併記しています。訳は読みやすさを優先しているので、正確な表現は原典をご確認ください。
関連記事
- AIにテストを書かせると、決まって同じ場所が抜ける — この記事で直したスキルを使って、AIが書いたテストを監査した話
- CLAUDE.md を厚くしても意味がなかった話 — 指示ではなく仕組みで縛るという話
JQITのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
エンジニア採用も行っています。もしご興味あれば覗いてみてください。
▶ 採用サイト