Anthropic 公式 skill－skill-creator から見たskills 設計のベストプラクティス

Transcript

1. 5 M I N L T A W S M e e t u p K a n s a i Anthropic 公式 skill－skill-creator から見た skills 設計のベストプラクティス Skills は書いた。なのに思った通りに動かない。 その理由を、公式 skill の実装と評価フローから読み解きます。 株式会社サーバーワークス所属 ロー タッヘイ（Law Tak Hei） 2026.05.25
2. 自己紹介 ロー タッヘイ（Law Tak Hei） 香港出身で愛猫リンゴちゃん大好きの AWS エンジニア AWS 認定資格 2026年5月時点 写真撮られるの嫌そうな顔しているリンゴちゃん
3. /skill-creator について 本資料で言及する /skill-creator については下記 Github リポジトリを ベースに参照しております。 https://github.com/anthropics/skills/tree/main/skills/skill-creator 直近のコミット（https://github.com/anthropics/skills/commit/b9e19e6f44773509fbdd7001d77ff41a49a486c1）
4. 0 2 ／ そ も そ も S k i l l と は 何 か 段階的開示（Progressive Disclosure） — 必要な情報だけを、必要なときに LAYER 01 フロントマター（Frontmatter） 常時ロード ／ およそ 100 words ↓ Skill が呼ばれたとき LAYER 02 SKILL.md 本体 およそ 500 行が目安 ↓ 実行中、必要に応じて LAYER 03 references / scripts / assets 無制限・オンデマンド 05 / 08 **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. 判断基準の一つとして、テスト実行した複数ケースが独立して同じヘルパースクリプトを書いたら scripts/などでバンドルすべきサイン。 — skill-creator ／ SKILL.md #304行目
5. 0 2 ／ そ も そ も S k i l l と は 何 か Skill = AI への "仕事の渡し方" の設計図 Skill の良し悪しは、独立した 3 つの軸で決まる。 01 トリガー精度 正しいタイミングで呼ばれるか。 Description の設計 02 実行品質 指示どおりに動くか。 アサーションの設計 03 出力一貫性 毎回同じ形式で返るか。 アウトプットの設計 POINT この 3 軸は独立したレイヤーで、組み合わせて Skill の品質が決まる。 02 / 08
6. 0 3 ／ よ く あ る 失 敗 パ タ ー ン なぜ Skill は動かないのか # 症状 原因 対応軸 01 呼ばれない description が曖昧 トリガー精度 02 呼ばれすぎる scope の境界が不明 トリガー精度 03 結果がブレる 出力テンプレートが未定義 出力一貫性 04 テストは通るが品質が低い 評価基準が甘い（偽陽性） 実行品質 A passing grade on a weak assertion is worse than useless — it creates false confidence. 「弱いアサーションでテストが通ることは、通らないより悪い。偽の自信を生む。」 — skill-creator ／ grader.md #9行目 03 / 08
7. 0 4 ／ B E S T P R A C T I C E 0 1 ─ ト リ ガ ー 設 計 Description は Skill の "入口" であり、最後に磨くもの 01 具体フレーズを列挙する キーワードでなく "ユーザーが実際に打ちそうな言葉" で書く。 02 Non-Trigger を明記する "Do NOT use for ◦◦" でスコープの境界を守る。 03 あえて "強めに" 書く（Pushy） Claude は構造的に Skill を使わない方向にバイアスがある。「必ずこのスキルを使うこと」くらいで丁度いい。 順序 トリガー最適化は 最後 に実施する。 中身（ワークフロー・出力）が固まる前に description を磨いても無意味 ─ content first, triggers last。 04 / 08
8. 0 5 ／ B E S T P R A C T I C E 0 2 ─ ワ ー ク フ ロ ー MUST と ALWAYS より、なぜそうするかを書く × 硬い命令型 【ALWAYS】出力を返す前に検証してください 【NEVER】確認ステップをスキップしないでください ◦ 理由型（推奨） 下流ツールがパースに失敗する可能性があるため、 出力を返す前に検証してください。 現状の LLM は推論能力が優れており、理由（Why）を与えると想定外の状況でも適切に判断できる。 剛直な MUST は「条件を満たした」と判断され、そのまま素通りすることがある。 If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag ALWAYS ／ NEVER を 全大文字 で書きたくなったら 黄色信号 となる。 — skill-creator ／ SKILL.md #302行目 06 / 08
9. 0 6 ／ B E S T P R A C T I C E 0 3 ─ 評 価 正しい問いは「動くか？」ではなく「差があるか？」 同じタスク Skill あり → 実行 → 出力 A Skill なし → 実行 → 出力 B ↑ どれだけ差があるか ─ 差がなければ、その Skill に価値はない。 レイヤー 何を見るか 担当エージェント Assertion 期待値の Pass / Fail Grader Blind 比較 出力品質の優劣 Comparator（盲検） 原因分析 なぜ勝ったか Analyzer Draft → Test (with / without) → Grade → Blind 比較 → 原因分析 → SKILL.md 改善 07 / 08
10. 0 7 ／ T A K E - A W A Y Skill 設計 5 原則 # 原則 核心メッセージ 01 トリガーは "フレーズ" で キーワードでなく実際の発話を。Pushy に書く。 02 3 層で文脈をコントロール Frontmatter → SKILL.md → references。繰り返しは scripts/ へ。 03 MUST より WHY 理由で書く。LLM はルールより文脈で動く。 04 "With vs Without" で評価 差がなければ Skill に価値はない。 05 トリガー最適化は最後 中身が固まるまで description を磨いても無意味。 08 / 08
11. 0 7 ／ T A K E - A W A Y Skill 設計 5 原則 # 原則 核心メッセージ 01 トリガーは "フレーズ" で キーワードでなく実際の発話を。Pushy に書く。 02 3 層で文脈をコントロール Metadata → SKILL.md → references。繰り返しは scripts/ へ。 03 MUST より WHY 理由で書く。LLM はルールより文脈で動く。 04 "With vs Without" で評価 差がなければ Skill に価値はない。 05 トリガー最適化は最後 中身が固まるまで description を磨いても無意味。 Skill を書くことは、仕事を言語化すること 。 そして、言語化した仕事を データで検証すること。 08 / 08 /skill-creator ではこれらの設計思想がすべて取り入れており、 /skill-creator で高品質なスキルを量産していきましょう