はじめに
Claude Code には「スキル(skill)」という仕組みがあります。/daily-planner や /commit のようなスラッシュコマンドを自分で定義して、Claude に繰り返しの業務フローを覚えさせる機能です。
「スキルを作るのが面倒」と感じたことはないでしょうか。要件のヒアリング、SKILL.md の執筆、テストケースの設計、品質の評価……。これを手動で回していると、スキルの改善よりも管理コストが勝ってしまいがちです。
そこで登場するのが skill-creator です。Anthropic が公式に公開したこのスキルは、「スキルを作るためのスキル」——いわばメタスキルです。今回はその仕組みと使い方を紹介します。
Claude Code のスキルとは
まず前提を整理します。Claude Code のスキルとは、Markdown で書いた指示書(SKILL.md)で Claude の動作を定義したものです。
my-skill/ ├── SKILL.md ← 指示書(必須) ├── scripts/ ← 再利用スクリプト ├── references/ ← 参照ドキュメント
SKILL.md の先頭には YAML フロントマターを書きます。
--- name: my-skill description: "ユーザーが〜と言ったときに使うスキル。〜を実行する。" ---
description フィールドが重要で、ここに書いた内容を Claude が読み、「このスキルを呼ぶべきか」を判断します。つまり トリガー精度はこの一文で決まります。
スキルは3階層の読み込み方式(Progressive Disclosure)を採用しています。
| 階層 | 内容 | 読み込みタイミング |
|---|---|---|
| メタデータ(name + description) | 常に文脈内にある(〜100語) | 常時 |
| SKILL.md 本文 | スキルがトリガーされたとき | スキル起動時 |
| 付属リソース(scripts/references) | 必要に応じて参照 | スキル内の指示で明示 |
SKILL.md 本文は 500 行以内を目安にし、詳細は references/ に分離してリンクするのがベストプラクティスです。
skill-creator でできること
skill-creator は、スキル開発の以下のサイクルを Claude と協力して回せます。
スキル設計 → 下書き作成 → テスト実行 → 品質評価 → 改善 → トリガー最適化
大きく5つの機能があります。
1. スキル設計ヒアリング
「〇〇なスキルを作りたい」と伝えるだけで、Claude が次の4点を確認します。
- このスキルで何を実現するか
- どんな発話でトリガーするか
- 期待する出力フォーマット
- テストケースを作るか
過去の会話からワークフローを抽出して自動的にスキル化することもできます。たとえば「さっきの操作手順をスキルにして」と言えば、使ったツールや手順を Claude が拾い上げて SKILL.md の下書きを作ります。
2. SKILL.md の自動生成
ヒアリング内容をもとに SKILL.md を生成します。description の書き方には工夫があり、トリガーしすぎるくらい少し強めに書くのがコツです。
「ダッシュボードを作るスキル」ではなく「ダッシュボード・データ可視化・社内メトリクス表示に関連する言及があれば必ずこのスキルを使う」
Claude は「十分自分でできる」と判断するとスキルを呼ばない傾向があるため、description に明示的なトリガー条件を書くことで精度が上がります。
3. テストケース実行と定量評価
スキルの品質を測るため、テストケースを evals/evals.json に保存して実行します。
{ "skill_name": "my-skill", "evals": [ { "id": 1, "prompt": "実際のユーザー発話に近いテスト文", "expected_output": "期待する出力の説明" } ] }
ここがポイントで、スキルありの実行とベースライン(スキルなし)を同時に並列で走らせます。「スキルを使ったほうが本当に良いか」を定量的に比較できます。
各テストケースには assertion(合格条件)を設定でき、結果は自動集計されます。
{ "assertions": [ { "text": "出力に会社名が含まれている", "type": "contains" }, { "text": "Markdown の見出し構造が正しい", "type": "qualitative" } ] }
4. ビジュアルレビュー(eval-viewer)
テスト実行後、eval-viewer/generate_review.py でブラウザ上のレビュー画面を自動生成します。

画面は2タブ構成です。
- Outputs タブ:テストケースごとに「スキルあり」と「スキルなし」の出力を並べて確認し、テキストでフィードバックを入力
- Benchmark タブ:パス率・実行時間・トークン数の統計を表示。前回イテレーションとの比較も可能
フィードバックを入力して「Submit All Reviews」を押すと feedback.json が保存されます。Claude がこれを読み込んで次のイテレーションに反映します。
5. Description 最適化(トリガー精度チューニング)
スキルが完成に近づいたら、description のトリガー精度を自動チューニングできます。
python -m scripts.run_loop \ --eval-set trigger-eval.json \ --skill-path path/to/skill \ --model claude-sonnet-4-6 \ --max-iterations 5 \ --verbose
20件のトリガー判定テスト(should-trigger / should-not-trigger)を使って、eval セットを train 60% / test 40% に分割してチューニングします。オーバーフィットを防ぐため、最終的には test スコアで best description を選びます。
実際に使ってみた
個人では Claude Code を活用した業務自動化に取り組んでいます。/daily-planner、/daily-review(朝のタスクプランニングと終業時の日次振り返り)や /timesheet-logger(工数登録)など、個人の業務自動化スキルを複数運用しています。
これらのスキルを開発する際、以前は以下のような手順を手動で踏んでいました。
- ノートに要件を書き出す
- 試行錯誤しながら SKILL.md を書く
- 実際に動かして「なんか違う」と感じたら書き直す
- description のトリガー漏れに気づいて慌てて修正する
skill-creator を使うと、このサイクルを Claude と対話しながら進められます。特に効果的だったのは テストケースと baseline の並列実行 です。「スキルを使ったほうが本当に良いのか」を定量的に確認できるため、「なんとなく良くなった気がする」の勘頼りから脱却できました。
つまずきやすいポイント
SKILL.md が長くなりすぎる
500 行を超えてきたら、詳細ロジックを references/ に分離して SKILL.md からリンクする構造に切り替えましょう。
assertion をすべてのケースに書こうとする 文章のクオリティや文体など主観的な評価には assertion は向きません。定性的なものはビジュアルレビューで人間が判断するほうが確実です。
description を短くしすぎる Claude はシンプルな一文でこなせるタスクではスキルを呼ばない傾向があります。複雑なフロー・多段階の操作・固有のフォーマットが必要なタスクは積極的にスキル化し、description に複数のトリガー例を書き込んでおくと精度が上がります。
おわりに
skill-creator は「スキルを作るための設計・テスト・評価・改善」のサイクルをまるごと Claude と共に回せるメタスキルです。定量ベンチマークとビジュアルレビューを組み合わせた評価フローは、プロンプトエンジニアリングの「なんとなく動いてる」から脱却するうえで非常に有効です。
スキルの仕組み自体は Markdown だけで書けるので、コードを書けない方でも始められます。業務ルーティンの自動化を考えているチームは、まず1つスキルを作ってみることをおすすめします。
skill-creator は以下の GitHub リポジトリで公開されています。
筆者紹介 サーバーワークスのエンジニアとして AWS インフラ設計・構築と生成 AI 活用推進に従事。Claude Code を用いた業務自動化スキルの開発・社内展開を行っています。
ロータッヘイ(執筆記事の一覧)
24卒入社の香港人です。
2025 Japan All AWS Certifications Engineers
リンゴちゃん(デボンレックス)にいつも癒されています。
