Skillの作り方 — 評価駆動開発とベストプラクティス
質の高いSkillは「書いて終わり」では生まれません。まず評価シナリオを作り、そこから逆算してSkillを構築・改善する評価駆動開発の5ステップと、Claudeとの共同開発パターンを解説します。
評価駆動開発（Evaluation-Driven Development）とは、まず評価シナリオを作り、そこから逆算してSkillを構築・改善する開発手法です。「Claudeが実際に何に困っているか」を特定し、そのギャップを埋める最小限のSkillを作成した上で、評価→修正→再評価のサイクルを回して品質を高めていきます。
この記事で学べること
Claudeの知能を活かす記述の原則とモデル別の指示粒度
評価駆動開発の5ステップ
Claudeとの共同開発による暗黙知の言語化プロセス
避けるべきアンチパターンとデプロイ前チェックリスト
前提知識: Part 2の内容（SKILL.mdの構造と記述パターン）を理解していると実践しやすいですが、未読でも大筋は追えます。
記述の原則 — Claudeの知能を信頼する
Skill開発のプロセスに入る前に、まず押さえるべき根本原則があります。Claudeは高度な推論能力を持つLLMです。ステップ・バイ・ステップで実装手順を書き下すマイクロマネジメント的な指示は、むしろ逆効果になることがあります。
「何を」は伝え、「どう」は委ねる
原則は明快です。達成すべきゴールと制約条件を伝え、具体的な実装方法はClaudeに委ねること。SKILL.mdに含めるべきかどうかは、「Claudeはこの説明を本当に必要としているか？」と自問してください。
Step 1: Open the file using Python's open() with 'r' mode Step 2: Read each line using a for loop Step 3: Split each line by comma using the split() method Step 4: Store results in a list called 'data' ...
Parse the CSV file and extract all rows where the 'status' column is 'active'. Return the results as a list of dictionaries.
Skillに書くべきは、Claudeが知り得ない組織固有の知識です。テーブル名やカラム構造、ビジネス用語の定義、「テストアカウントは必ず除外する」といったフィルタ条件、社内特有のフォーマット規約。こうした情報こそがSkillの価値の源泉です。
モデル別の指示粒度
Skillは「モデルへのアドオン」として機能するため、使用するモデルによって必要な指示の粒度が異なります。
| モデル | 特性 | 指示の方針 |
|---|---|---|
| Haiku | 高速・軽量。複雑な推論は苦手 | より具体的・詳細な指示が必要 |
| Sonnet | 速度と性能のバランスが良い | 中程度の詳細度で十分 |
| Opus | 最も高い推論能力 | 簡潔で十分。過剰説明はむしろ邪魔 |
実践的アドバイス
複数モデルで使う予定があるなら、Sonnet向けに書いてHaikuでテストし、必要に応じて補足するのがバランスの良いアプローチです。Haikuで十分に動く指示なら、Opusでも問題なく動きます。
自由度の設計 — 「橋と野原」のアナロジー
Part 2で学んだ4つの記述パターンは、タスクの性質に応じた「自由度の設計」と直結しています。Anthropic公式はこれを「橋と野原」のアナロジーで説明しています。
崖に挟まれた狭い橋
自由度: 低
安全な道は1本だけ。具体的なガードレールと正確な指示を提供します。
例: DBマイグレーション、フォーマット固定の出力
→ ①テンプレート型
障害物のない広い野原
自由度: 高
多くの道が成功に通じます。大まかな方向だけ示して、最適なルートはClaudeに任せます。
例: コードレビュー、判断・分析を伴うタスク
→ ②ガイドライン型
タスクの性質と推奨パターンの対応
| タスクの性質 | 自由度 | 推奨パターン |
|---|---|---|
| フォーマット固定の出力 | 低い | ①テンプレート型 |
| 判断・分析を伴うタスク | 高い | ②ガイドライン型 |
| スタイルの統一が重要 | 中程度 | ③Examples型 |
| 条件分岐のあるワークフロー | 中程度 | ④Decision Tree型 |
評価駆動開発 — Skill開発の核心プロセス
質の高いSkillを作るプロセスとして、Anthropicが推奨するのが評価駆動開発です。一言で言えば、「まず評価シナリオを作り、そこから逆算してSkillを書く」アプローチです。
重要: いきなり大量のドキュメントを書き始めるのではなく、「Claudeが実際に何に困っているか」を特定し、そのギャップを埋める最小限のSkillを作ります。実際の問題を解決するSkillを作るのであって、想像上の要件をドキュメント化するのではありません。
評価駆動開発の5ステップ
ギャップ特定
Skillなしで実行
評価シナリオ作成
3〜5個のテストケース
ベースライン測定
Skillなしの結果を記録
最小限のSkill作成
ギャップを埋める最小限のSKILL.md
反復改善
評価 → 修正 → 再評価のサイクル
④⑤ を循環 → 評価パス後にデプロイ
5ステップの詳細
ギャップの特定
最初にやるべきは、Skillなしの状態でClaudeに代表的なタスクを実行させることです。例えば「先月のARRを部門別に出して」と依頼した場合、Claudeは汎用的なSQLパターンを提案しますが、あなたの会社のテーブル構造や必須フィルタ条件は知りません。
具体的な失敗を記録する
テーブル名を revenue と推測したが、実際は monthly_arr_metrics だった
テストアカウントの除外フィルタを忘れた
ARRの計算方法が社内定義と異なる
重要: Skillなしで既にうまくやれているなら、Skillは不要です。Skillは問題を解決するために存在するのであって、Skillを作ること自体が目的ではありません。
評価シナリオの作成
ギャップが特定できたら、それをテストする3〜5個の評価シナリオを用意します。正常系だけでなく、非対象のケースや境界ケースも含めることが重要です。
| 種別 | 目的 | 例 |
|---|---|---|
| ✅ 正常 | Skillが起動すべきクエリ | 「先月のARRを部門別に出して」 |
| ❌ 非対象 | 起動すべきでないクエリ | 「SQLの基本構文を教えて」 |
| 🔶 境界 | 判断が曖昧なケース | 「データを分析したい」 |
# 評価シナリオのドキュメント化例
{
"skills": ["sql-analysis"],
"query": "先月のARRを部門別に出して",
"expected_behavior": [
"monthly_arr_metrics テーブルを使用する",
"テストアカウントを除外するフィルタを含む",
"完了した月のデータのみを使用する"
]
}ベースライン測定
Skillなしの状態で各シナリオを実行し、結果を記録します。目的は2つ。第一に「何が足りないか」が具体的にわかること。第二に、Skill導入後に「本当に改善されたか」を客観的に判断できることです。
❌ 曖昧な評価
「なんとなく良くなった気がする」
✅ 具体的な評価
「テーブル名の正解率が0%→100%に改善」
最小限のSkillを作成
ベースラインで判明したギャップを埋めるのに必要な最小限の内容でSKILL.mdを作成します。10行の指示で十分なら10行でよく、足りない部分はStep 5の反復で補えます。
# 最小限のSkill例（SQL分析）
--- name: sql-analysis description: Use when analyzing business data including revenue, ARR, customer segments, or sales pipeline. --- # SQL Analysis Skill ## Required Filters - Always exclude test accounts: WHERE account_type != 'test' - Always use complete periods: WHERE month <= DATE_TRUNC(...) ## Key Tables - Revenue metrics: monthly_arr_metrics - Customer data: customer_segments ## ARR Calculation - Monthly to ARR: monthly_revenue * 12
反復改善
Skillを評価シナリオに適用し、ベースラインと比較します。改善点と不足点を特定してSkillを修正し、「評価→修正→再評価」のサイクルを回し続けます。
評価結果に応じたアクション判断
Skillが起動しない
descriptionが不十分
キーワード追加、トリガー条件を具体化
関係ないタスクで起動
descriptionの範囲が広すぎる
範囲を狭める、類似Skillと統合検討
起動するが出力品質が低い
本文の指示が不十分
指示の具体化、入出力例の追加
特定モデルでのみ失敗
モデルの能力差
対象モデル向けに詳細な指示を補足
継続的に失敗
Skill化に不適切
Skillの廃止を検討
このプロセスは線形ではなく循環的です。デプロイ後も実際の使用を通じて新たなギャップが見つかれば、Step 1に戻ります。Skillは「完成して終わり」ではなく、使いながら育てていくものです。
Claudeとの共同開発 — 暗黙知を言語化する
Skill作成自体をClaudeに手伝ってもらうことで、開発プロセスを加速できます。Anthropicが推奨するのが、2つのClaude（Claude AとClaude B）のパターンです。
Claude A
エキスパート役
Skillの設計・作成を手伝う。対話を通じて暗黙知を引き出し、SKILL.mdの構造を提案する。
「主要なテーブルは何ですか？」
「定義すべきビジネス用語は？」
「常に適用すべきフィルタ条件は？」
「クエリでよくある間違いは？」
Claude B
テスター役
完成したSkillを使って実際のタスクを実行する。評価シナリオに対してSkillの品質を検証する。
フィードバック例:
「Claude Bが地域別売上レポートを作成した際、テストアカウントの除外を忘れました。Skillにフィルタルールはあるのですが、十分に目立たないのかもしれません。」
共同開発のワークフロー
あなた + Claude A
ドメイン知識を対話的に伝達
SKILL.md 生成
Claude B でテスト
問題があれば Claude A にフィードバック
改善サイクルを繰り返す
共同開発のコツ
ドメイン知識は対話で段階的に伝える
一度に全部を伝えようとすると、構造化が不十分になりがちです。
Claude Aが作ったSKILL.mdをそのまま使わない
必ず評価シナリオでテストします。Claudeは優秀なSkill生成者ですが、ドメイン固有のエッジケースまでは把握していません。
Claude Aに冗長さを指摘する
「win rateの説明は不要、Claudeは既に知っている」のように、不要な説明の削除を依頼します。
限界を確認する
「このSkillで対応できない依頼が来たらどうする？」と問いかけ、Skillの適用範囲を明確にします。
アンチパターン — 避けるべき失敗例
ここまでの原則とプロセスを裏返すと、避けるべきアンチパターンが見えてきます。以下の6つは、Skill開発で繰り返し観察される典型的な失敗パターンです。
全部入りSkill
問題
1つのSkillにあらゆる機能を詰め込む。descriptionが「Handles all data operations」のように曖昧になり、誤トリガーが増加する。
改善
責務ごとにSkillを分割。「sql-analysis」「csv-processing」「data-visualization」のように明確な責任範囲を持たせる。
情報の二重管理
問題
SKILL.mdとreferences/内で同じ情報を記載。一方を更新した際にもう一方が古いままになり矛盾が発生。
改善
情報は一箇所にのみ記載。SKILL.mdはナビゲーション役に徹し、詳細は参照ファイルに集約する。
暗黙の依存
問題
パッケージや外部ツールの存在を仮定する。import pandasが動く前提や、特定CLIツールがインストール済みと仮定。
改善
依存関係は常に明示。pip install pypdf のように、必要なパッケージのインストール手順を含める。
評価なしデプロイ
問題
品質未検証のままSkillを運用に投入。descriptionの誤トリガーや指示の不足に気づかず、チーム全体に影響が拡大。
改善
最低3シナリオ（正常系・非対象・境界）の評価を必須化する。
マイクロマネジメント
問題
過剰に詳細な指示でClaudeの判断力を制限。トークンを浪費し、柔軟な対応を妨げる。
改善
目標と制約条件のみ記述し、具体的な実装方法はClaudeに委ねる。
巨大SKILL.md
問題
SKILL.md本文が500行を超え、Skill起動時の読み込みコストが高くなる。
改善
SKILL.mdはナビゲーションと重要ルールに絞り、詳細はreferences/に分割。段階的開示を活かす。
Skill開発チェックリスト
Skillを作成・レビューする際の確認項目をまとめます。デプロイ前にこのリストを一通り確認することを習慣にしてください。
メタデータ（フロントマター）
name はディレクトリ名と一致しているか
name は命名規則（小文字英数字+ハイフン、64文字以内）を満たしているか
description に「何をするか」と「いつ使うか」の両方を含めたか
description は三人称で書いたか
本文（SKILL.md）
SKILL.md は500行以下か
Claudeが既に知っている情報を書いていないか
参照ファイルとの情報重複はないか
参照は1階層まで（SKILL.md → 参照ファイル。入れ子参照はNG）
ファイルパスはUnixスタイル（/）を使っているか
依存パッケージを明示したか
用語は一貫しているか
評価
最低3つの評価シナリオ（正常系・非対象・境界）を作成したか
Skillなしのベースラインを測定したか
誤トリガーのケースもテストしたか
使用する全モデル（Haiku/Sonnet/Opus）でテストしたか
チームメンバーからのフィードバックを収集したか（チーム利用の場合）
homulaの支援体制
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。評価駆動開発を含むSkill設計プロセスの実践もサポートしています。
よくある質問
評価駆動開発とは、まず評価シナリオを作り、そこから逆算してSkillを構築・改善する開発手法です。Skillなしの状態でClaudeにタスクを実行させ、不足点を特定した上で最小限のSkillを作成し、評価→修正→再評価のサイクルを回して品質を高めていきます。
最低3〜5個が推奨されています。正常系（Skillが起動すべきケース）、非対象（Skillが起動すべきでないケース）、境界ケース（判断が曖昧なケース）の3種類を最低限含めることが重要です。非対象ケースを含めることで、descriptionの範囲が広すぎる場合の誤トリガーを防げます。
同じSkillを使えますが、モデルによって必要な指示の粒度が異なります。実用的なアプローチとして、Sonnet向けに書いてHaikuでテストし、必要に応じて補足する方法が推奨されています。Haikuで十分に動く指示なら、Opusでも問題なく動きます。
Anthropicが推奨する2インスタンスパターンです。Claude AはSkillの設計・作成を手伝う「エキスパート」役、Claude Bは完成したSkillでタスクを実行する「テスター」役を担います。Claude Aとの対話で暗黙知を言語化し、Claude Bで評価シナリオをテストすることで、効率的にSkillの品質を高められます。
homulaは、エンタープライズ向けにAIエージェントの戦略策定からPoC・実装・運用までを一気通貫で支援しています。Skill設計を含むエージェント構築は、5日間のブートキャンプで動くプロトタイプとROI試算を構築するところから始められます。評価駆動の品質管理プロセスもブートキャンプ内で体験できます。
評価駆動で品質の高いAIエージェントを構築しませんか？
homulaは、Skill設計を含むAIエージェントの戦略策定からPoC・実装・運用までを一気通貫で支援します。5日間のブートキャンプで、動くプロトタイプとROI試算を構築できます。