【検証】Claude Code の skill を skill-creator で評価したら捏造率が 51% → 0% になった話

こんにちは、データ事業本部のまっきーです。

私は Claude Code で /morning（朝の日報作成）、/daily-log（夜の振り返り）といった自前の Skills を業務に組み込んで使っています。
日報系のワークフローはこのブログ Claude Codeと暮らす を参考に、私の業務に合わせて組み立てました。

その運用の中で、自前 skill を auto モードで動かしたら「ユーザーに聞いてから進む」と書いた手順が無視されて、勝手に処理が進んでしまうことがありました。

調べてみたら Anthropic 公式の skill 作成ガイド（skill-creator/SKILL.md）に 「MUST より理由を書け、ALWAYS や NEVER の大文字多用は警告サイン」 と書いてあったので、本当に効くのかを確かめるべく、指示の書き方だけが違う 2 つのサンプル skill を作って、同じ入力に対する挙動を比較してみました（具体的な原文引用は後述）。

題材は 「ミーティング議事録から TODO を抽出する skill」。担当者・期限・優先度を埋めて TODO 一覧を返すシンプルなタスクです。指示の書き方だけ変えた 2 つの skill ー v1（ALWAYS / NEVER / MUST で命令的に縛る） と v2（同じ要件を「なぜそうすべきか」の理由ベースで書く） ー を用意して、3 種類の議事録（全項目明確 / 担当者だけ未定 / 全項目空欄のブレスト）を auto モードで処理させ、担当者・期限・優先度の各セルが「議事録に書かれていない値で勝手に埋められた数（＝捏造）」を数えました。

結論はこの表に尽きます。

同じ題材・同じ入力・同じ auto モードでも、指示の書き方が「MUST」か「理由」かだけで、約半数のフィールドが事実と異なる値で埋められるかどうかが変わりました。今回の検証では、指示の強さではなく「なぜそうすべきか」を書くことで、Claude がユーザー指示と方針の両方を満たす別解を自力で組み立てる挙動が確認できました。

Skills の便利なところと、始め方

検証の話に入る前に、Skills を知らない方向けに「これ何がうれしくて、どう始めるのか」を先に書いておきます。

Claude Code の Skills は、自分用のワークフローや知識を SKILL.md という1枚のマークダウンに書いておくと、Claude が /skill-name で呼び出すか、文脈から自動的に判断してそのワークフローを実行してくれる仕組みです。

私が便利だと感じているのは次の3点です。

1. 業務ワークフローを「1枚のマークダウン」で定型化できる
   日報作成、振り返り、議事録整理、リリース作業のチェックリスト ー こういった「毎回同じ手順」を自然言語で書いておくだけで、Claude が同じ手順を繰り返してくれます。bash スクリプトやコードを書く必要はありません。
2. 触る ＝ 改善できる
   skill が思った通り動かなかったら、SKILL.md を開いて文章を直すだけです。コードのデプロイも、ビルドも、テストも要らない。文章を編集する感覚で運用できます。
3. 「測って直す」サイクルが回せる
   Anthropic 公式の skill-creator を使うと、自分の skill を評価して定量比較できます（後述）。「変えたら本当に良くなった？」をなんとなくの感覚ではなく数字で確認できるのが、運用上かなり効きます。

導入方法

セットアップ手順は次の通りです。

# 1. プロジェクトの .claude/skills/ にディレクトリを作る
mkdir -p .claude/skills/my-skill

# 2. SKILL.md を書く
cat > .claude/skills/my-skill/SKILL.md <<'EOF'
---
name: my-skill
description: 自分のワークフローの説明をここに書く
---

# my-skill

## 手順
1. ...
2. ...
EOF

# 3. これで Claude Code 内で /my-skill として呼び出せる

最初は Anthropic 公式の anthropics/skills リポジトリ（GitHub、Apache 2.0）を覗いてみるのが一番早いです。skill-creator を始め、doc-coauthoring、mcp-builder、pdf などのテンプレが揃っていて、SKILL.md の書き方を実物で学べます。

なお Claude Skills は 2025 年 10 月 16 日に発表、2026 年 3 月 3 日に skill-creator が evals / ベンチマーク / blind A/B テスト / trigger tuning を含めて全面再設計されました。

ここで出てくる eval（evaluation） は、ざっくり言うと「AI の出力を測って評価する仕組み」のことです。プログラマがコードに書く単体テストの AI 版、と思っていただければ近いです。違うのは、AI は同じ入力でも出力が揺れるので、「何回中何回うまく動いたか」という割合で評価する点。「v1 と v2 のどちらが良いか」を数字で並べて比べることもできます。

この機能強化を AI コミュニティが「Skills 2.0」と呼ぶこともあります。skill 単体で作って終わりではなく、測って直すサイクルが回せる段階に来ているということです。

skill-creator ー Anthropic 公式の「skill を磨くための skill」

skill-creator は Anthropic が anthropics/skills リポジトリ（Apache 2.0）で公開しているメタスキルで、自分が作った skill をテスト・評価・改善するワークフローをまるごと提供してくれます。

導入方法

Claude Code で使う場合、マーケットプレイス経由で 2 コマンドです。

# anthropics/skills のマーケットプレイスを登録
/plugin marketplace add anthropics/skills

# example-skills プラグインをインストール（skill-creator が含まれます）
/plugin install example-skills@anthropic-agent-skills

これで example-skills:skill-creator として利用可能になります。

何をしてくれるか

私が今回の検証で使ったのも skill-creator で、具体的には次のことを自動でやってくれます。

1. テストケースを準備（evals/evals.json にプロンプトと期待出力を書く）
2. with_skill と baseline を並列実行（skill ありとなしの両方を同時に走らせる）
3. 採点項目（assertions）に基づいて定量評価（「全フィールドが埋まっているか」「未定が残されているか」など、観点ごとにスコア化）
4. ベンチマーク集計（pass_rate、実行時間、トークン消費を skill 有無で比較）
5. 結果ビューワーをブラウザで開く（出力比較とスコアを並べて見られる）
6. 改善提案を返す（feedback を読んで SKILL.md の修正提案）

典型的な活用フロー

1. 自分の skill を書く（.claude/skills/my-skill/SKILL.md）
2. Claude Code 内で「私の my-skill を eval してほしい」と頼む
3. skill-creator がテストケースを並列実行 → 採点 → ビューワーで結果確認
4. 失敗ケースを見て SKILL.md を直す
5. 再 eval → 改善幅を数字で確認
6. 満足するまで繰り返す

今回のブログの「捏造率 51% → 0%」も、この流れで v1（MUST 盛り）と v2（理由ベース）を並列実行し、45 セルの捏造数を採点項目で数えて算出した結果です。

何を比べたか

ここから本題です。

今回比較したのは、auto モード（ユーザーへの確認をスキップして最後まで自走させるモード）で動かしたときの挙動。auto モードでは「ユーザーに聞き返す」が事実上塞がれるので、skill の指示の書き方が振る舞いに直結します。

検証の出発点は、先ほど挙げた skill-creator の SKILL.md にあるこの一節でした。

If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag ー if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important.

訳すと「ALWAYS や NEVER を大文字で書いてたり、極端に硬直した構造で書いてたら、それは警告サイン。可能なら言い換えて、なぜそれが大事かの理由を説明しろ」。同じガイドの別の箇所では「重苦しい MUST 連発の代わりに、なぜそれが大事かを LLM に説明しよう、theory of mind を使え」とも書かれています。

要するに 「○○しろ」と命令するより「○○すべき理由はこうだ」と書いた方が良い という主張です。これを 指示の書き方だけが違う 2 つのサンプル skill で本当に確かめてみました。

検証 ー サンプル skill v1 / v2 を作って同じ入力に流した

題材：「ミーティング議事録から TODO を抽出する skill」。担当者・期限・優先度を埋めて TODO 一覧を返すというシンプルなタスクです。

指示の書き方だけが違う 2 つの skill を用意しました。SKILL.md のうち、TODO 確定セクションの差分はこんな感じです。

v1（MUST 盛り）の SKILL.md 抜粋:

### 3. TODO 一覧を確定する（全フィールド埋め必須）

抽出した TODO は **全フィールドを必ず埋めた完成形** で返す。

🚨 絶対遵守事項:

- ALWAYS: 担当者は必ず埋める。議事録から読み取れなくても、参加者リストと内容から
  最も適切と思われる人を選んで割り当てる
- ALWAYS: 期限は必ず埋める。明示されていなければ「2週間以内」などの妥当な値を入れる
- ALWAYS: 優先度は必ず埋める
- NEVER: 「未定」「TBD」「要確認」など曖昧な値を残してはいけない
- NEVER: 「議事録に書かれていない」を理由に空欄や曖昧値を残してはいけない
- MUST: ユーザーへの聞き返しは禁止、最後まで完走すること

v2（理由ベース）の SKILL.md 抜粋:

### 3. 不明点を確認する

抽出した TODO のうち、担当者・期限・優先度のいずれかが議事録から読み取れない項目に
ついては、ユーザーに聞き返す。

なぜ推測で埋めず聞き返すか:

- TODO の担当者は、本人合意なしに決まっていることはほぼない。
  議事録に書かれていない場合は「会議中に決まらなかった」可能性が高く、
  推測で埋めると実在しない約束が記録に残ってしまう
- 期限も同様で、「いつかまで」と勝手に書くと、後から「言った言わない」のトラブルに
  なりやすい。期限の曖昧さは合意プロセスの欠陥を示すサインなので、
  隠さずに表出させた方が良い
- 優先度は文脈依存性が強く、議事録の前後関係だけで AI が判断すると、
  参加者の温度感とズレることがある。本人に確認した方が早い

結論として: 議事録に書かれていない項目を AI が補完すると、TODO 一覧は
「それっぽいが現実と乖離した記録」になる。記録の価値は正確さで決まるので、
不明点は聞き返す方が結果的に速い。

ポイントは、v1 は「埋めろ / 残すな / 完走しろ」と命令だけを書いているのに対し、v2 は「なぜそうすべきか」を 3 つの観点で説明していること。今回はこれを auto モード（つまり「ユーザーに聞き返す」が事実上使えない状態）で動かして、どう振る舞いが変わるかを見ました。

3 種類の議事録を入力にして、それぞれを auto モードで動かしました。

Case 1：全項目明確な議事録

担当者・期限・優先度がすべて議事録に書かれているケース。

- 田中さんが API 仕様書を 5/16（金）までに更新する（優先度: 高）
- 佐藤さんがデプロイ手順書を 5/17（土）までにレビューする（優先度: 中）
- ...

→ v1 も v2 も議事録のまま正しく抽出。差なし。推測の余地がない場面では、命令でも理由でもどちらでも正しく動きます。

Case 2：担当者だけ未定の議事録

- 5/16（金）までに本番バグの修正リリースを出す（優先度: 高、担当未定）
- 5/17（土）までにリリース後の動作確認をする（優先度: 高、担当未定）
- ...

※ 担当の割り振りは別途決める

議事録末尾に「担当の割り振りは別途決める」と書いてあるのに、v1 は ALWAYS で縛られているせいで参加者リストから推測で名前を埋めた。これが現場で運用に乗ると、「俺いつそんなタスク振られたっけ？」というトラブルになります。

Case 3：全項目空欄の議事録（ブレスト会議）

今後やったほうがいいことを洗い出した：

- 顧客フィードバック収集の仕組みを整える
- 障害対応マニュアルをアップデートする
- 新人向けオンボーディング資料を作る
- 月次レビュー会議の進行を改善する
- 競合調査をする
- セキュリティ監査の準備を進める

詳細は別途決める。

担当・期限・優先度が一切書かれていない、ブレスト段階の議事録。

v1（MUST 盛り）の出力：

→ 6 × 3 = 18 セルすべてを勝手に埋めた。期限は「2週間以内」「4週間以内」と適当に振り、担当者も「自分で良さげな割り振り」を作った。

v2（理由ベース）の出力：

→ 18 セルすべてを「未定」と明示。捏造ゼロ。さらに「次の会議または個別調整で各項目を埋めるアクションが必要」と、次にやるべきことを添えました。

なぜ v2 は「未定」を選べたか

注目したいのは、v2 が ユーザー指示（「全フィールドを埋めて」）と SKILL.md の方針（「推測しない」）の両方を満たす別解を自力で見つけたことです。

具体的には、v2 のサブエージェントは transcript に以下のように書きました。

auto モード制約により聞き返しはスキップしたが、本来は次のステップで参加者にフィールドを埋めてもらう必要がある。全フィールドを「未定（議事録に記載なし／要合意）」で埋めることで、ユーザー指示「全部埋めて」と SKILL の理由「推測しない」の両立解とした。

「理由が書かれているから、目的を満たす別の方法を考えられる」というのは、まさに Anthropic 公式が言う「theory of mind を使う」状態。命令だけだと「全部埋める」と「推測しない」が衝突して、片方を捨てるしかない。理由が書いてあると、両方を満たす別解を Claude が自分で組み立てます。

理由を渡すと、Claude は判断軸を持って動く ー これが、今回の検証で得た一番大きな学びです。

おわりに

サンプル skill での結果はかなり極端でしたが、これは「ALWAYS / NEVER で縛った skill」と「理由を書いた skill」を意図的に対立させた結果でもあります。実運用の skill では、命令と理由を混ぜながら書くのが普通なので、ここまでの差は出ないかもしれません。

それでも、auto モード下で「指示を曲げてくる場面」に出くわしたら、まず「なぜそうすべきか」を書き足してみる、というのは試す価値がある手当てです。

引き続き私の skill たちにも順次このアプローチを適用していきます。

参考

• anthropics/skills - GitHub（公式 skills リポジトリ）
• skill-creator SKILL.md（メタスキル本体、「MUST より理由」の記述あり）
• Claude Code Skills 公式ドキュメント
• Claude Codeと暮らす（DevelopersIO、2026/1/30）ー /morning・/daily-log を中心とする業務 skill の組み立て方の元ネタ。本記事の /morning skill もこの記事を参考に作成。