Skill CreatorでClaudeのコードスキルを自動作成する方法

要約

Claude Code Skillsは、特定のワークフローに合わせてClaudeの機能を拡張するカスタム機能です。スキル作成システムは、構造化されたプロセスを通じてスキルの作成を自動化します。スキルの目的を定義し、SKILL.mdファイルを作成し、テストケースを作成し、定量的なベンチマークで評価を実行し、フィードバックに基づいて反復的に改善します。

はじめに

あなたはClaude Codeを毎日使っています。プロジェクト構造の設定、特定のテストコマンドの実行、特定の形式での出力といった同じ手順を繰り返していることに気づきます。毎回、ワークフローを最初から説明しています。もしClaudeがそれを覚えていたらどうでしょう？そのワークフローを一度だけキャプチャして、いつでも利用できるようにできたらどうでしょう？それがClaude Code Skillsです。これらは、特定のワークフローに合わせてClaudeの機能を拡張するために作成するカスタム機能です。そして、Skill Creatorを使えば、そのプロセスは自動化され、体系的になります。

このガイドでは、プロセス全体を順を追って説明します。スキルの構成、作成ワークフロー、評価システム、信頼性の高いトリガーを実現するための最適化方法について学びます。Anthropicの公式スキルリポジトリからの実例も紹介します。

💡

API関連のスキルを構築している場合、Apidogは自然に統合されます。APIエンドポイントのテスト、レスポンスの検証、ドキュメントの生成をすべて単一のスキルワークフロー内で実行できます。

ボタン

Claude Code Skillsとは？

Claude Code Skillsは、特定のドメインやワークフローに合わせてClaudeの機能を拡張する特殊な命令セットです。これらをマークダウンファイルに存在するカスタムプラグインと考えてください。

スキルシステムアーキテクチャ

スキルは3レベルの読み込みシステムを使用します。

メタデータ（約100語）- 名前と説明、常にコンテキスト内に存在
SKILL.md本体（500行未満）- コア命令、スキルがトリガーされたときに読み込み
バンドルされたリソース（無制限）- スクリプト、参照、必要に応じて読み込まれるアセット

skill-name/
├── SKILL.md (必須)
│   ├── YAMLフロントマター (名前、説明)
│   └── マークダウン命令
└── Bundled Resources (オプション)
    ├── scripts/    - 繰り返しのタスクのための実行可能コード
    ├── references/ - 必要に応じて読み込まれるドキュメント
    └── assets/     - テンプレート、アイコン、フォント

スキルがトリガーされるタイミング

スキルはClaudeのavailable_skillsリストに名前と説明とともに表示されます。Claudeはその説明に基づいてスキルを参照するかどうかを決定します。

重要: スキルはClaudeが直接処理できないタスクに対してのみトリガーされます。「このファイルを読んで」のような単純なクエリは、一致する説明があってもスキルをトリガーしません。複雑で多段階のワークフローは、説明が一致する場合に確実にトリガーされます。

Anthropicのリポジトリからの実例

スキル	目的	主な機能
skill-creator	新しいスキルを作成	テストケース生成、ベンチマーク評価、説明の最適化
mcp-builder	MCPサーバーを構築	Python/Nodeテンプレート、評価フレームワーク、ベストプラクティス
docx	Wordドキュメントを生成	python-docxスクリプト、テンプレートシステム、スタイルガイド
pdf	PDFを抽出および操作	フォーム処理、テキスト抽出、参照ドキュメント
frontend-design	ウェブインターフェースを構築	コンポーネントライブラリ、Tailwindパターン、アクセシビリティチェック

スキル作成ワークフロー

スキル作成プロセスは、体系的なループに従います。

意図を把握 - スキルは何をすべきか？
下書きを作成 - SKILL.mdファイルを作成
テストケースを作成 - 現実的なプロンプトを定義
評価を実行 - スキルありとなしで実行
結果をレビュー - 定性的なフィードバック + 定量的なメトリクス
反復 - 結果に基づいて改善
説明を最適化 - トリガーの精度を最大化
パッケージ化 - .skillファイルとして配布

各ステップを順に見ていきましょう。

ステップ1：意図を把握する

スキルに何を達成させたいかを理解することから始めます。もし、すでに実行しているワークフローをキャプチャするのであれば、会話履歴からパターンを抽出します。

次の4つの質問を自問自答してください。

このスキルはClaudeに何を可能にすべきか？ 結果について具体的に述べます。
このスキルはいつトリガーされるべきか？ どのようなユーザーのフレーズやコンテキストか？
期待される出力形式は？ ファイル、コード、レポートか？
テストケースを設定すべきか？ 検証可能な出力（コード生成、データ抽出、ファイル変換）を持つスキルはテストケースの恩恵を受けます。主観的な出力（文章スタイル、デザイン）を持つスキルは、しばしば必要ありません。

例：APIテストスキル

意図: 開発者がREST APIを体系的にテストするのを支援する
トリガー: ユーザーがAPIテスト、エンドポイント、REST、GraphQLに言及したり、レスポンスを検証したいとき
出力: 合否ステータス、curlコマンド、レスポンス比較を含むテストレポート
テストケース: はい - 出力は客観的に検証可能

ステップ2：SKILL.mdファイルを作成する

すべてのスキルは、YAMLフロントマターとマークダウン命令を含むSKILL.mdファイルから始まります。

スキルの構成

---
name: api-tester
description: REST APIを体系的にテストする方法。ユーザーがAPIテスト、エンドポイント、REST、GraphQLに言及したり、APIレスポンスを検証したいときに使用してください。テストが関わる場合は、常にこのスキルを提案するようにしてください。
compatibility: curlまたはHTTPクライアントツールが必要です
---

# APIテスター スキル

## コアワークフロー

APIをテストする際は、以下の手順に従ってください。

1. **エンドポイントを理解する** - 仕様を読むか、スキーマを尋ねる
2. **テストケースを設計する** - ハッピーパス、エッジケース、エラー条件
3. **テストを実行する** - リクエストにはcurlまたはApidogを使用する
4. **レスポンスを検証する** - ステータスコード、ヘッダー、ボディ構造をチェックする
5. **結果を報告する** - 証拠とともに合否を要約する

## テストケーステンプレート

各エンドポイントについて、以下をテストします。

- 正しいペイロードでの有効な認証
- 必須フィールドが欠落している場合の有効な認証
- 無効な認証（401が期待される）
- レート制限の挙動
- 負荷下での応答時間

## 出力形式

レポートは常に次のように構成してください。

# APIテストレポート

## 要約
- 実行されたテスト数: X
- 合格: Y
- 不合格: Z

## 不合格のテスト

### テスト名
**期待される結果:** 200 OK
**実際の結果:** 400 Bad Request
**レスポンス:** {...}

## 推奨事項
...

記述のベストプラクティス

段階的開示を使用する: SKILL.mdは500行未満に保ちます。詳細な参照は別のファイルに移動します。

api-tester/
├── SKILL.md (ワークフロー概要)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

理由を説明する: ルールをリストするだけでなく、なぜそれらが重要なのかを説明します。

## なぜエラーケースを最初にテストするのか

ハッピーパスの前にエラー条件をテストすることで、80%の問題がより速く捕捉されます。
認証がサイレントに失敗すると、ハッピーパスのテストは無意味になります。
401チェックから始めましょう。

命令形を使用する: 「常に最初にステータスコードを検証する」であり、「ステータスコードを検証すべきです」ではない。

例を含める: 入力と期待される出力を示します。

## コミットメッセージ形式

**例:**
入力: JWTトークンによるユーザー認証を追加しました
出力: feat(auth): implement JWT-based authentication

ステップ3：テストケースを作成する

スキルを下書きした後、2〜3個の現実的なテストプロンプトを作成します。これらは、実際のユーザーが行うであろう種類の要求です。

テストケースの形式

テストケースはevals/evals.jsonに保存します。

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "api.example.com上の/usersエンドポイントをテストしてください。Bearerトークンが必要で、id、name、emailフィールドを持つユーザーのリストを返します。",
      "expected_output": "認証失敗、成功、ページネーションテストを含む少なくとも5つのテストケースを持つテストレポート",
      "files": []
    },
    {
      "id": 2,
      "prompt": "新しいPOST /ordersエンドポイントが無効な数量を正しく処理するか検証する必要があります。",
      "expected_output": "負の数、ゼロ、非数値の数量を送信し、適切なエラー応答を伴うテストケース",
      "files": ["openapi.yaml"]
    }
  ]
}

良いテストプロンプトとは？

悪い例: 「このAPIをテストしてください」

良い例: 「うちのチームが新しい決済エンドポイントをhttps://api.stripe.com/v1/chargesにデプロイしたんだけど、エッジケースを検証する必要があるんだ。特に、負の金額や存在しない通貨コードを送信したときにどうなるか。ドキュメントには400を返すはずだと書いてあるけど、実際のエラーメッセージを確認したいんだ」

良いテストプロンプトには以下が含まれます。

特定のURL
具体的なシナリオ
期待される挙動
現実世界でのコンテキスト

実行する前にユーザーとテストケースを共有します。「いくつかのテストシナリオを試したいのですが、これでよろしいでしょうか、それとも追加したいものがありますか？」

ステップ4：評価を実行する

ここでSkill Creatorが威力を発揮します。各テストケースを2回実行します。1回はスキルありで、もう1回はスキルなしで（または既存のスキルを改善する場合は古いバージョンで）。

ワークスペースの構造

結果はスキルディレクトリの隣に<skill-name>-workspace/として保存されます。

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

並行実行の開始

各テストケースについて、同じターンに2つのサブエージェントを起動します。

スキルあり実行:

このタスクを実行してください:
- スキルパス: /path/to/api-tester
- タスク: api.example.com上の/usersエンドポイントをテストしてください
- 入力ファイル: なし
- 出力保存先: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

ベースライン実行:

このタスクを実行してください:
- スキルパス: (なし)
- タスク: api.example.com上の/usersエンドポイントをテストしてください
- 入力ファイル: なし
- 出力保存先: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

タイミングデータのキャプチャ

各サブエージェントが完了すると、total_tokensとduration_msが返されます。すぐにtiming.jsonに保存します。

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

このデータはタスク通知を通じてのみ届きます。到着次第、それぞれを処理します。

ステップ5：実行完了中にアサーションを下書きする

実行の完了をただ待つだけではありません。その時間を有効活用して、定量的なアサーションを下書きしましょう。

良いアサーションとは？

良いアサーションは以下の通りです。

客観的に検証可能 - 合否が曖昧でない
記述的な名前 - 何をチェックしているか明確
再利用可能 - 繰り返しにわたって機能する

APIテストスキルのアサーション例:

{
  "assertions": [
    {
      "name": "認証失敗テストが含まれる",
      "description": "テストレポートに少なくとも1つの認証失敗テストケースが含まれている",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "成功テストが含まれる",
      "description": "テストレポートに少なくとも1つの成功リクエストテストが含まれている",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "curlコマンドが含まれる",
      "description": "各テストケースに実行可能なcurlコマンドが含まれている",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "レスポンス検証が含まれる",
      "description": "レポートがスキーマに対してレスポンス構造を検証している",
      "type": "contains",
      "value": "schema"
    }
  ]
}

アサーションを下書きしたら、eval_metadata.jsonとevals/evals.jsonを更新します。

ステップ6：採点と集計

すべての実行が完了したら、以下を実行します。

各実行の採点

agents/grader.mdを読み込み、各アサーションを出力に対して評価するグレーダーサブエージェントを起動します。結果は各実行ディレクトリのgrading.jsonに保存します。

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "テストケース3で401ステータスコードが検出されました"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "テストケース1で'curl -X POST'が検出されました"
    }
  ]
}

重要: grading.jsonの期待値配列は、text、passed、evidenceのフィールド名を使用する必要があります。ビューアはこれらの正確な名前に依存します。

ベンチマークへの集計

skill-creatorディレクトリから集計スクリプトを実行します。

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

これにより、benchmark.jsonとbenchmark.mdが生成され、各設定のpass_rate、時間、トークン、平均±標準偏差、デルタが含まれます。

アナリストによるパス

ベンチマークデータを読み込み、パターンを浮き彫りにします。

非識別アサーション - スキルに関係なく常に合格（有用ではない）
高分散評価 - フルーキーである可能性があり、調査が必要
時間/トークンのトレードオフ - スキルは妥当なコストで品質を向上させるか？

詳細なガイダンスはagents/analyzer.mdを参照してください。

ステップ7：評価ビューアを起動する

評価ビューアは、定性的な出力と定量的なメトリクスの両方をブラウザインターフェースで表示します。

ビューアを生成する

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

イテレーション2以降では、--previous-workspaceも渡します。

--previous-workspace api-tester-workspace/iteration-1

ユーザーが見るもの

出力タブは一度に1つのテストケースを表示します。

プロンプト - 与えられたタスク
出力 - 生成されたファイル、インラインでレンダリング
以前の出力（イテレーション2以降） - 前回のイテレーションの出力を折りたたんだセクション
正式な評価 - 折りたたまれたアサーションの合否
フィードバック - 入力中に自動保存されるテキストボックス
以前のフィードバック（イテレーション2以降） - 前回のイテレーションからのコメント

ベンチマークタブは以下を表示します。

各設定の合格率
タイミングの比較
トークン使用量
評価ごとの内訳
アナリストの所見

ユーザーに伝えてください：「結果をブラウザで開きました。『出力』タブでは各テストケースをクリックしてフィードバックを残すことができ、『ベンチマーク』タブでは定量的な比較が表示されます。完了したら、ここに戻ってお知らせください。」

Cowork / ヘッドレス環境

webbrowser.open()が利用できない場合は、--staticを使用してスタンドアロンのHTMLファイルを書き出します。

--static /path/to/output/review.html

ユーザーが「すべてのレビューを送信」をクリックすると、フィードバックはfeedback.jsonとしてダウンロードされます。

ステップ8：フィードバックを読み、反復する

ユーザーが完了したら、feedback.jsonを読み取ります。

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "グラフに軸ラベルがありません",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "完璧です、気に入りました",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

空のフィードバックは、ユーザーが問題ないと考えていることを意味します。具体的な不満のあるテストケースに改善の焦点を当てます。

改善をどのように考えるか

フィードバックから一般化する: あなたは多くのプロンプトで何千回も使用されるスキルを作成しています。特定のテストケースに過度に適合させないでください。頑固な問題がある場合は、制約的なMUSTステートメントではなく、異なる比喩やパターンを試してください。

プロンプトを簡潔に保つ: 不要なものを削除します。最終出力だけでなく、トランスクリプトも読みます。スキルがモデルに非生産的なステップで時間を無駄にさせる場合、それらの部分を削除します。

理由を説明する: LLMは優れた心の理論を持っています。適切なハーネスが与えられると、彼らは丸暗記の指示を超えていきます。各要件がなぜ重要なのかを説明します。すべて大文字でALWAYSやNEVERと書いていることに気づいたら、代わりに言い換えたり理由を説明したりしてください。

繰り返される作業を探す: すべてのテストケースが個別に似たようなヘルパースクリプトを作成しましたか？それはスキルがそのスクリプトをバンドルすべきだという兆候です。一度作成し、scripts/に置き、スキルに使用するように指示します。

反復ループ

スキルに改善を適用する
すべてのテストケースをiteration-<N+1>/に、ベースライン実行とともに再実行する
前のイテレーションを指す--previous-workspaceでビューアを起動する
ユーザーレビューを待つ
新しいフィードバックを読み、再度改善し、繰り返す

以下のようになるまで続けます。

ユーザーが満足したと言う
フィードバックがすべて空（すべて問題ない）
意味のある進捗がない

完了したらビューアを終了します。

kill $VIEWER_PID 2>/dev/null

ステップ9：スキル説明の最適化

SKILL.mdのフロントマターにあるdescriptionフィールドは、主要なトリガーメカニズムです。スキルの作成または改善後、トリガーの精度を高めるために最適化します。

トリガー評価クエリを生成する

20個の評価クエリ（トリガーすべきものとすべきでないものを混ぜて）を作成します。

[
  {
    "query": "うちの上司がxlsxファイルを送ってきたんだけど（ダウンロードフォルダにある 'Q4 sales final FINAL v2.xlsx'みたいな名前のやつ）、利益率をパーセンテージで表示する列を追加してほしいって。収益はC列、コストはD列だと思うんだけど。",
    "should_trigger": true
  },
  {
    "query": "このCSVからピボットテーブルを作成してチームにメールで送る必要があります。",
    "should_trigger": false
  }
]

トリガーすべきクエリ（8-10個）の場合：

同じ意図の異なる表現
フォーマルな言葉とカジュアルな言葉
ユーザーがスキル名を明示的に言及していなくても、明らかにそのスキルが必要なケース
エッジケースや珍しい使用例

トリガーすべきでないクエリ（8-10個）の場合：

キーワードは共通しているが、異なるものが必要なニアミスケース
別のツールがより適切な隣接ドメイン
素朴なキーワードマッチングでは誤ってトリガーされる可能性のある曖昧な表現

悪いネガティブテストの例: PDFスキルに対するネガティブテストとして「フィボナッチ関数を書く」は簡単すぎます。ネガティブケースは本当にトリッキーであるべきです。

ユーザーとのレビュー

HTMLテンプレートを使用して評価セットを提示します。

assets/eval_review.htmlを読み込む
プレースホルダーを評価データ、スキル名、説明で置き換える
一時ファイルに書き込み、開く: open /tmp/eval_review_api-tester.html
ユーザーはクエリの編集、should-triggerの切り替え、エントリの追加/削除が可能
ユーザーは「評価セットをエクスポート」をクリックする
ファイルが~/Downloads/eval_set.jsonにダウンロードされる

このステップは重要です。悪い評価クエリは悪い説明につながります。

最適化ループを実行する

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

トリガーテストがユーザーエクスペリエンスと一致するように、現在のセッションを動かすモデルIDを使用します。

スクリプトは以下のことを行います。

評価セットを60%の訓練セットと40%の保留テストセットに分割する
現在の説明を評価する（信頼性のためそれぞれ3回実行）
失敗に基づいて改善案を提案するようClaudeを呼び出す
訓練セットとテストセットで再評価する
最大5回反復する
テストスコア（過学習を避けるため訓練スコアではない）によって選択されたbest_descriptionを返す

結果を適用する

JSON出力からbest_descriptionを取得し、スキルのSKILL.mdフロントマターを更新します。スコアとともにユーザーにビフォーアフターを示します。

変更前:

description: REST APIを体系的にテストする方法

変更後:

description: REST APIを体系的にテストする方法。ユーザーがAPIテスト、エンドポイント、REST、GraphQLに言及したり、APIレスポンスを検証したいときに使用してください。たとえ明示的に「テスト」と言及していなくても、テストが関わる場合は常にこのスキルを提案するようにしてください。

ステップ10：パッケージ化と配布

スキルが完成したら、配布用にパッケージ化します。

python -m scripts.package_skill /path/to/api-tester

これにより、ユーザーがインストールできる.skillファイルが作成されます。ユーザーを生成されたファイルのパスに誘導します。

インストール

ユーザーは.skillファイルをスキルのディレクトリに配置するか、Claude Codeのスキルインストールコマンドを使用してスキルをインストールします。

よくあるスキル作成の誤り

誤り1：曖昧な説明

悪い例:

description: APIを操作するためのスキル

良い例:

description: REST APIを体系的にテストする方法。ユーザーがAPIテスト、エンドポイント、REST、GraphQLに言及したり、APIレスポンスを検証したいときに使用してください。たとえ明示的に「テスト」と言及していなくても、テストが関わる場合は常にこのスキルを提案するようにしてください。

誤り2：過度に制限的な指示

悪い例:

常にこの正確なフォーマットを使用してください。決して逸脱しないでください。これらのセクションを必ず含めてください。

良い例:

このフォーマットを使用してください。なぜなら、関係者が必要な情報を迅速に見つけられるようになるからです。もしあなたの対象者が異なるニーズを持っている場合は、それに応じて構造を適応させてください。

誤り3：テストケースの省略

テストケースは、ユーザーが問題に遭遇する前に問題を検出します。主観的なスキルであっても、出力の品質を検証するために2〜3個の例を実行してください。

誤り4：タイミングデータの無視

10倍の時間がかかるスキルは持続可能ではありません。タイミングデータをキャプチャし、品質と並行して効率を最適化してください。

誤り5：繰り返されるスクリプトをバンドルしない

もしすべてのテスト実行が個別にgenerate_report.pyを作成している場合、それをスキルにバンドルしてください。時間を節約し、一貫性を確保します。

実世界でのスキル例

MCPビルダースキル

AnthropicによってMCP（Model Context Protocol）サーバーを構築するために作成されました。

主な機能:

PythonおよびNode.jsテンプレート
MCPサーバーの評価フレームワーク
ベストプラクティス参照ドキュメント

構造:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Docxスキル

プログラム的にWordドキュメントを生成します。

主な機能:

バンドルされたpython-docxスクリプト
一般的なドキュメント用のテンプレートシステム
一貫した書式設定のためのスタイリングガイド

ワークフロー:

ドキュメント要件を理解する
テンプレートを選択または作成する
python-docxスクリプトを介して生成する
出力構造を検証する

フロントエンドデザインスキル

モダンなパターンでウェブインターフェースを構築します。

主な機能:

コンポーネントライブラリ
Tailwind CSSパターン
アクセシビリティチェック

段階的開示: コアワークフローはSKILL.mdに、コンポーネントのドキュメントはreferences/に。

Apidogでスキルをテストする

API関連のスキルを構築している場合、Apidogはワークフローに自然に統合されます。

例：APIテストスキル統合

## APIテストの実行

体系的なテストにはApidogを使用します。

1. OpenAPI仕様をApidogにインポートする
2. 仕様からテストケースを生成する
3. テストを実行し、結果をJSONとしてエクスポートする
4. 期待されるスキーマに対してレスポンスを検証する

カスタムアサーションには、Apidogのスクリプト機能を使用してください。

Apidogスクリプトをバンドルする

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

これにより、今後のすべての呼び出しで車輪の再発明をする必要がなくなります。

結論

Claude Code Skillsは、Claudeの機能を特定のワークフローに合わせて拡張します。Skill Creatorシステムは、体系的なプロセスを提供します。

意図を把握 - スキルが何をすべきかを定義する
SKILL.mdを下書き - 例を交えて明確な指示を記述する
テストケースを作成 - ユーザーが実際に行うであろう現実的なプロンプト
評価を実行 - スキルありとなしで並行実行
結果をレビュー - 定性的なフィードバック + 定量的なベンチマーク
反復 - 結果に基づいて改善する
説明を最適化 - トリガーの精度を最大化する
パッケージ化 - .skillファイルとして配布する

ボタン

よくある質問

スキル作成にはどのくらい時間がかかりますか？

簡単なスキルは15〜30分かかります。複数の参照ファイルやバンドルされたスクリプトを含む複雑なスキルは、評価の反復を含めて2〜3時間かかることがあります。

すべてのスキルにテストケースを作成する必要がありますか？

いいえ。客観的に検証可能な出力（コード生成、ファイル変換、データ抽出）を持つスキルはテストケースの恩恵を受けます。主観的な出力（文章スタイル、デザイン品質）を持つスキルは、定性的に評価する方が適切です。

スキルが reliably にトリガーされない場合はどうすればよいですか？

descriptionフィールドを最適化してください。特定のトリガーフレーズとコンテキストを含めます。少し「強引に」する – いつスキルを使用すべきかを明示的に述べます。20個の評価クエリでdescription最適化ループを実行します。

チームとスキルを共有するにはどうすればよいですか？

python -m scripts.package_skill <path>でスキルをパッケージ化し、.skillファイルを配布します。チームメンバーはそれをスキルのディレクトリに配置します。

スキルは外部APIを呼び出せますか？

はい。API呼び出しを行うスクリプトをバンドルしてください。スキルの指示は、Claudeにいつ、どのようにそれらを使用するかを伝えます。APIキーはスキル自体ではなく、環境変数に保存してください。

スキルのファイルサイズ制限はありますか？

厳密な制限はありませんが、SKILL.mdは500行未満に保ってください。詳細な参照は別のファイルに移動します。スクリプトやアセットは、オンデマンドで読み込まれるため、行数制限にはカウントされません。

既存のスキルを更新するにはどうすればよいですか？

インストールされているスキルを書き込み可能な場所にコピーし、そこで編集してから再パッケージ化します。元の名前を保持してください。個別のバリアントを作成する場合を除き、バージョンサフィックスを追加しないでください。

要約

はじめに

Claude Code Skillsとは？

スキルシステムアーキテクチャ

スキルがトリガーされるタイミング

Anthropicのリポジトリからの実例

スキル作成ワークフロー

ステップ1：意図を把握する

例：APIテストスキル

ステップ2：SKILL.mdファイルを作成する

スキルの構成

記述のベストプラクティス

ステップ3：テストケースを作成する

テストケースの形式

良いテストプロンプトとは？

ステップ4：評価を実行する

ワークスペースの構造

並行実行の開始

タイミングデータのキャプチャ

ステップ5：実行完了中にアサーションを下書きする

良いアサーションとは？

ステップ6：採点と集計

各実行の採点

ベンチマークへの集計

アナリストによるパス

ステップ7：評価ビューアを起動する

ビューアを生成する

ユーザーが見るもの

Cowork / ヘッドレス環境

ステップ8：フィードバックを読み、反復する

改善をどのように考えるか

反復ループ

ステップ9：スキル説明の最適化

トリガー評価クエリを生成する

ユーザーとのレビュー

最適化ループを実行する

結果を適用する

ステップ10：パッケージ化と配布

インストール

よくあるスキル作成の誤り

誤り1：曖昧な説明

誤り2：過度に制限的な指示

誤り3：テストケースの省略

誤り4：タイミングデータの無視

誤り5：繰り返されるスクリプトをバンドルしない

実世界でのスキル例

MCPビルダー スキル

Docxスキル

フロントエンドデザインスキル

Apidogでスキルをテストする

例：APIテストスキル統合

Apidogスクリプトをバンドルする

結論

よくある質問

スキル作成にはどのくらい時間がかかりますか？

すべてのスキルにテストケースを作成する必要がありますか？

スキルが reliably にトリガーされない場合はどうすればよいですか？

チームとスキルを共有するにはどうすればよいですか？

スキルは外部APIを呼び出せますか？

スキルのファイルサイズ制限はありますか？

既存のスキルを更新するにはどうすればよいですか？

MCPビルダースキル