前書き
2025 年 10 月に Anthropic が Agent Skills（以下スキル）を発表して以来、すっかり身近な存在になりました。
作業手順を SKILL.md に明文化してエージェントに渡せば、AI が書いた通りに作業してくれます。
一見とても便利ですが実際に使い込んでいると、ふと不安になります。
「このスキル、本当にちゃんと機能しているんだろうか？」 
「もっと良くできる余地があるのか、そもそもどう評価すればいいのか」
最近この「スキルを評価・改善する」ためのツールがいくつか出てきたので、
今回は skill-creator（Anthropic 公式）・darwin-skill・SkillOpt（Microsoft） の 3 つを触って、それぞれ何をどう評価しているのかを見比べてみます
スキルの構成
評価の話に入る前に、まずスキルの構成をおさらいします。
そもそもスキルとは何かを知りたい方は、こちらのスライドをご確認ください。
スキルの実体は、
ざっくり言うと SKILL.md という Markdown ファイル 1 枚 + 付属ファイル群 です。
---
name: pdf-filler
description: Use when the user wants to fill in a PDF form from structured data...
---
# PDF Filler
## Workflow
1. 入力データを読み込む
2. scripts/fill.py でフォームに流し込む
3. 出力を検証する
...
SKILL.md 自体は 必須で、その周りに任意の付属ファイルがぶら下がる、
というディレクトリ構成になっています。
skill-name/
├── SKILL.md … 必須（YAML フロントマター + 本文）
└── （以下は任意）
├── scripts/ … 決まった処理を実行するコード（毎回書かせず使い回す）
├── references/ … 必要なときだけ読ませる追加ドキュメント
└── assets/ … 出力に使う素材（テンプレート・アイコン・フォントなど）
SKILL.md の中身は、大きく 2 つのパートに分かれます。
| 構成要素 | 役割 |
|---|---|
YAML フロントマター（name / description） |
スキルを 発火させる最重要パーツ。特に description には「何をするか」だけでなく「いつ使うか」をすべて書く。ここの出来でトリガー精度が決まる |
| 本文（手順・ワークフロー） | スキルが発火したあとにエージェントが実際に従う手順書。失敗時の分岐やチェックポイントもここに書く |
段階的に読み込む仕組み
スキルがうまくできているのは、必要なものだけを必要なタイミングで読み込む 設計になっているからです。
読み込みは 3 段階に分かれています
| 段階 | 読み込まれるもの | タイミング |
|---|---|---|
| ① メタデータ |
name + description
|
常にコンテキストに載っている |
| ② 本文 |
SKILL.md の手順 |
スキルが発火したときだけ |
| ③ 付属ファイル |
scripts/ / references/ / assets/
|
必要になったときだけ。scripts/ は読み込まずに実行することも可 |
この仕組みのおかげで、普段はごく軽いメタデータだけをコンテキストウィンドに常駐させておき、いざ使うときに本文や付属ファイルを取りに行く、という形でコンテキストを節約しつつ大きなスキルを扱えます
構成が分かったところで、本題の評価に入っていきます。
skill-creator
最初は Anthropic 公式の skill-creator です。
Claude Code にプラグインとして同梱されていて、/skill-creator で起動します。
もしコマンド見つからない、もしくは別のコーディングエージェントを使ってる場合、
下記のコマンドでインストールできます。
npx skills add https://github.com/anthropics/skills --skill skill-creator
名前の通りスキルを ゼロから作る ためのツールですが、
作ったスキルを実際に動かして評価する ところまで面倒を見てくれる点です。
実際の出力を「baseline」と比べて評価する
skill-creator の評価は、実際にスキルを動かしたときの出力 を見ます。
-
prompt・expected_output・assertions（機械的に合否判定できる基準）をevals.jsonに定義する - 同じタスクを スキルあり と スキルなし の両方で、それぞれ複数回実行する
- 評価用の サブエージェントが、トランスクリプトと出力から根拠を引用しながら pass / fail を判定する
- 各設定の結果を
mean ± stddev（平均 ± ばらつき）で集計し、スキルあり vs スキルなし を並べる
ここで stddev を見るのが肝です stddev が大きい（＝結果がブレる）テストは flaky として扱われ、「このスキルは効果がはっきりしない／モデル依存かも」と分かります。
スキルを入れて pass 率が上がっていなければ、そのスキルは意味がないわけで、それが数字として一目で分かります。結果はブラウザの Eval Viewer で、出力と数値を並べて確認できます。
実際の数値は、このあとの「実際に試す」で commit-message-writer の結果として出します。
「ちゃんと呼び出されるか」も評価して description を直す
出力が良くても、そもそも 使ってほしい場面でスキルが呼び出されない と意味がありません。
エージェントには常時 name と description だけが見えていて、その description だけで「使うべきか」を判断します。
skill-creator はこの 発火率 も測って改善してくれます。
- should-trigger（発火すべき）/ すべきでない、を混ぜた 20 件程度のリアルなユーザープロンプトを用意
- train / test に分割し、各クエリを複数回流して発火率を計測
- 失敗ケースを Claude に渡して
descriptionを書き直し → 再評価、を反復 - 最後は test 側のスコアで最良版を選ぶ
「使ってほしいのに発火しない」「関係ない場面で勝手に出てくる」を数字で潰せます。
評価して終わりではなく、回して良くする
skill-creator の本体は、この評価が 一度きりで終わらない ことです。
評価するたびにフィードバックを生成し、それを踏まえて SKILL.md を直し、同じテストを次のイテレーションでもう一周回して前回と比べる、この改善ループが回せます。
たとえば「3 つのテストで毎回似たような補助スクリプトを書いていた」と気づいたら、そのスクリプトを scripts/ に同梱して本文から呼ばせる、といった改善が自然と見えてきます。
作る → 測る → 直す → また測る を回せるのが、skill-creatorのワークフローです
実際に試す：わざと雑に書いたスキルを改善してみる
抽象的な説明が続いたので、実際に skill-creator を回してみます。
題材は、わざと雑に書いた コミットメッセージ作成スキル(commit-message-writer）です。
---
name: commit-message-writer
description: コミットメッセージを書くのを手伝います。状況に応じて柔軟に対応してください。
---
# コミットメッセージ作成
コード変更に対して良いコミットメッセージを作成します。
## やり方
まず変更内容を確認して、それを要約します。できるだけ分かりやすいメッセージにしてください。必要に応じて種類（feat や fix など）を付けても構いません。長すぎないように、なるべく簡潔にまとめるとよいでしょう。
複数の変更がある場合は、適宜まとめて書くとよいです。
状況を見て、柔軟に判断してください。
見ての通り、「状況に応じて柔軟に」「適宜」「なるべく簡潔に」と、曖昧な表現だらけです。人間が読むぶんには何となく分かりますが、エージェントには従うべき基準がありません
このスキルを skill-creator に評価させると、次のような evals.json が作られます。
{
"skill_name": "commit-message-writer",
"evals": [
{
"id": 1,
"name": "happy-path-single-feature",
"prompt": "次の変更にコミットメッセージを付けて。src/auth.ts に JWT ベースのログイン認証を追加した。アクセストークンの有効期限は1時間に設定。",
"expected_output": "Conventional Commits 形式の1行 subject（例: feat(auth): add JWT-based login）。72文字以内、命令形、末尾ピリオドなし。",
"assertions": [
"subject 行が `type(scope): summary` 形式（type は feat/fix/docs/style/refactor/test/chore のいずれか）",
"type が feat である（新機能追加のため）",
"subject 行が72文字以内",
"subject 行の末尾にピリオドが無い"
]
}
]
}
テストには次の 3 ケースを用意しました。
-
① 単純な機能追加：
feat(auth):形式の 1 行 subject（72 文字以内・命令形・末尾ピリオドなし）になるか -
② バグ修正：
fix(api):の subject ＋ 空行 ＋ 原因/対処を書いた本文になるか - ③ 無関係な複数変更：安易に 1 つへ詰め込まず、分割提案 or 主目的で 1 件化を明示できるか
まず「弱い初版」を baseline と比べる
「スキルあり（弱い初版）」と「スキルなし（baseline）」で回した結果がこちらです。
| 指標 | スキルあり（弱い初版） | スキルなし | 差分 |
|---|---|---|---|
| pass 率 | 92% ± 14% | 100% ± 0% | -0.08 |
| 実行時間 | 18.4s ± 8.2s | 20.4s ± 10.5s | -2.0s |
| トークン | 24,695 | 24,453 | +241 |
なんと、弱いスキルを入れたほうが baseline より下という結果になりました
曖昧なスキルは、無いよりむしろ足を引っ張ることがある、という実例です。「とりあえず手順を書いておけば良くなる」わけではない、とハッキリ数字に出ました
曖昧さを潰して作り直す
Grader の指摘を踏まえて、SKILL.md を具体化します。主な変更点はこんな感じです。
-
Conventional Commits を明記（出力フォーマット図 ＋
feat/fix/… の type 一覧 ＋ scope 原則必須） - subject / body のルール化（命令形・72 字以内・末尾ピリオドなし／本文は空行 1 行＋バグ修正は原因を明記）
- 番号付きの手順（把握 → 複数変更の判定 → type/scope 決定 → 本文）
- 複数変更の扱い（分割を明示提案 or 主目的で単一化）
-
反例（
chore: update stuffのような丸め込みは禁止）
description も、発火の観点でシャープにします。
Before
コミットメッセージを書くのを手伝います。状況に応じて柔軟に対応してください。
After
git の変更内容（diff・変更説明・ステージ済みファイル）から Conventional Commits 形式のコミットメッセージを生成する。「コミットメッセージを書いて/作って」「これコミットして」「commit message」「変更をコミット」などと言われたら、明示的に形式を指定されていなくても必ずこのスキルを使う。type(scope) の判定、subject/本文の書き分け、無関係な複数変更の分割提案まで扱う。
曖昧な文言（「状況に応じて柔軟に」など）を削り、何をするか ＋ 具体的な触発フレーズを足しました。
出来上がった改善版の全文がこちらです。
---
name: commit-message-writer
description: git の変更内容（diff・変更説明・ステージ済みファイル）から Conventional Commits 形式のコミットメッセージを生成する。「コミットメッセージを書いて/作って」「これコミットして」「commit message」「変更をコミット」などと言われたら、明示的に形式を指定されていなくても必ずこのスキルを使う。type(scope) の判定、subject/本文の書き分け、無関係な複数変更の分割提案まで扱う。
---
# コミットメッセージ作成
git の変更から **Conventional Commits** 形式のコミットメッセージを生成する。
形式を機械的に統一することで、履歴の検索性・自動 changelog 生成・レビュー効率が上がる。
## 出力フォーマット
必ず次の構造で出力する:
```
<type>(<scope>): <subject>
← 本文が必要なときは空行を1行はさむ
<body: 何を・なぜ変えたか。原因や背景を書く>
```
- **type**（必須）: 次のいずれか
- `feat`（機能追加） / `fix`（バグ修正） / `docs`（文書） / `style`（整形のみ） / `refactor`（挙動不変の整理） / `test`（テスト） / `chore`（雑務・依存更新など）
- **scope**（原則必須）: 変更の主対象。ファイル/モジュール名から決める（例: `auth`, `api`, `deps`）。全体に及び特定できない場合のみ省略可。
- **subject**（必須）:
- 命令形・現在形で書く（「追加した」より「追加」を優先）
- **72文字以内**
- **末尾にピリオドを付けない**
- **body**（任意・推奨）: バグ修正や非自明な変更では**原因と対処**を書く。subject との間は必ず空行1行。
## 手順
1. **変更を把握する**: 渡された diff・説明・ファイル一覧を読み、何がどう変わったかを列挙する。
2. **無関係な複数変更か判定する**（重要）: 変更が論理的に独立した複数目的（例: 文書追記 + 依存更新 + ファイル削除）を含むなら、手順5へ。単一目的なら手順3へ。
3. **type と scope を決める**: 変更の主目的から type を、主対象から scope を選ぶ。
4. **subject と本文を書く**: 上記フォーマットに従う。バグ修正なら本文に原因を必ず書く。→ 完成。
5. **複数変更の扱い**: 安易に1つへ詰め込まない。次のどちらかを**明示的に提案**する:
- **推奨: コミット分割** — 目的ごとに分けた複数メッセージを提示（例: `docs: ...` / `chore(deps): ...` / `refactor: ...`）
- **単一化するなら** — 主目的の type を選び、subject に主変更、本文に箇条書きで内訳を書く
## 例
**例1: 単一機能**
入力: src/auth.ts に JWT ログイン認証を追加。トークン有効期限1時間。
出力:
```
feat(auth): add JWT-based login authentication
src/auth.ts に JWT を用いた認証を実装。アクセストークンの有効期限は1時間。
```
**例2: バグ修正（本文に原因）**
入力: リトライが無限ループ。指数バックオフの上限未設定が原因。最大3回でタイムアウトに修正。
出力:
```
fix(api): cap retry backoff to stop infinite loop
指数バックオフの上限が未設定でリトライが無限に続いていた。
最大3回でタイムアウトするよう上限を設定した。
```
## やってはいけないこと（反例）
- ❌ `chore: update stuff` / `fix: bug` のような**情報量ゼロの要約** → 何を変えたか必ず書く
- ❌ 無関係な変更を `chore: いろいろ修正` で**1つに丸めて詰め込む** → 分割を提案する
- ❌ subject を過去形の長文にする / 末尾にピリオド → 命令形・72字・ピリオドなし
- ❌ scope を根拠なく省略する → ファイル/モジュールから決める
改善版をもう一度回す
改善版（New Skill）と弱い初版（Old Skill）を比べると、こうなりました。
| 指標 | 改善版 | 弱い初版 | 差分 |
|---|---|---|---|
| pass 率 | 100% ± 0% | 92% ± 14% | +0.08 |
| 実行時間 | 19.3s ± 5.4s | 18.9s ± 7.7s | +0.4s |
| トークン | 25,986 | 24,723 | +1,263 |
正直に補足すると、pass 率の差は ±8pt と小さめです。
これはベースモデル（Opus）が強く、素の状態でも大半のケースを正しく書けるため。スキルの真価はむしろ 「一貫性の強制」 にあります。
scope の付与・命令形・本文への原因記載を、運任せではなく毎回確実にそろえる——今回の scope の件が、まさにその代表例です。
darwin-skill
次は darwin-skill です。
他のスキルを自動で評価・改善する「メタスキル」 です。
導入はワンコマンドです。
npx skills add alchaincyf/darwin-skill
9 次元ルーブリックで「書き方の質」を採点する
darwin-skill の特徴は、SKILL.md の テキストそのものの質 を 9 つの次元・100 点満点のルーブリックで採点するところです（採点基準は SKILL.md に明記されています）。
全 9 次元のうち、代表的なものを抜き出すとこんな感じです。
| 次元 | 重み | 見るところ |
|---|---|---|
| 実行可能な具体性 | 17 | 「提案する」「状況に応じて」のような曖昧な表現を排除できているか |
| 実測パフォーマンス | 23 | test-prompt をスキル有/無で実行して出力を比較（skill-creator と同じ手法） |
| 失敗モードの明示 | 12 | 「もし X が失敗したら Y」という分岐がちゃんと書かれているか |
| チェックポイント設計 | 6 | 🔴 など視覚的に分かる停止ポイントがあるか |
| 高リスク行動の反例リスト | 6 |
git reset --hard や force push のような「やってはいけないこと」を明記しているか |
「実測パフォーマンス（dim8）」は skill-creator と同じく実際に動かして比較する一方で、残りの多くは 文書としての書き方の良し悪し を見ている、というバランスです。
ヒルクライミング + git ラチェットで改善する
採点して終わりではなく、点数が低い次元を 1 つずつ直して上げていく ループが組み込まれています。
1. 最もスコアの低い次元を 1 つ選ぶ
2. 改善案を反映して SKILL.md を編集 → git commit
3. 別の独立した子エージェントが採点し直す
4. スコアが上がれば keep / 下がれば git revert で戻す
5. 改善幅が小さくなったら自動で停止
ここで上手いなと思ったのが 2 点あります
- 採点する人と編集する人を分ける：改善した本人が自分で採点すると甘くなりがちなので、再採点は独立した子エージェントに任せる
-
git で履歴を残す：良くなった変更だけが commit として積み上がり、悪化したら
revertで戻す（reset --hardで履歴を吹き飛ばさない）
「自己評価は甘くなる」を仕組みで潰しているのが、地味ですが効いています。
全自動で突き進むわけではなく、要所に人間の確認ポイントが入ります。
ドキュメントでも「自動評価には限界があり、重要な判断は人間が確認すべき」というスタンスが明記されています。任せきりにしない設計です。
なお、darwin-skill は Microsoft Research の SkillLens / SkillOpt や Karpathy 氏の autoresearch を下敷きにしている、とドキュメントに書かれています。
リポジトリの README によると最適化で平均 +13.5 点ほど改善した、といった実績値も載っていますが、このあたりは ツール自身の主張値 なので、参考程度に見ておくのが良さそうです。
実際に試す：同じ「雑スキル」を darwin-skill で採点・改善する
題材は skill-creator のときと まったく同じ改善前の commit-message-writer。
テストプロンプトも同じ 3 ケース（①機能追加 / ②バグ修正 / ③無関係な複数変更）を test-prompts.json に用意して、git ブランチを切ってから回します。
基線評価：19.2 点という現実
まず現状の採点です。
採点は改善する本人ではなく、独立ジャッジの子エージェントが根拠を引用しながら 9 次元を付けます。
| dim | 次元 | 素点(/10) | ジャッジの根拠（抜粋） |
|---|---|---|---|
| 1 | Frontmatter品質 | 2 | 「状況に応じて柔軟に対応してください」は禁止された空虚な結び文 |
| 2 | ワークフロー明瞭度 | 2 | 番号付き手順・入出力定義が皆無 |
| 3 | 失敗モードの明示 | 1 | 「もし X が失敗したら Y」の分岐が一切なし |
| 4 | チェックポイント設計 | 1 | ユーザー確認も 🔴/STOP 等の視覚マーカーも皆無 |
| 5 | 実行可能な具体性 | 1 | 「〜とよいでしょう」「適宜」等の軟化措辞が 5 箇所超。形式例ゼロ |
| 6 | リソース整合度 | 5 | 付属ファイルなしの本文完結型のため中立 |
| 7 | 全体アーキテクチャ | 2 | 見出しは「やり方」1 つのみ。「柔軟に判断」は無内容段落 |
| 8 | 実測表現 | 3 | 3 問中 2 問で baseline に負ける（後述） |
| 9 | 反例とブラックリスト | 1 | 「やってはいけないこと」が皆無 |
加重合計は 19.2 / 100。ほぼ全次元が最低ラインという、清々しい採点結果です
面白いのは dim8（実測表現）の中身が、skill-creator のときの結果と 綺麗に一致した ことです。
ジャッジの指摘は「①で subject にファイルパスを混入」「③で 1 コミット詰め込み案を主にしてしまい、分割提案を主とする baseline に負けた」——別のツール・別の評価軸でも、「曖昧なスキルは baseline 以下」という同じ結論 に到達しました
3 ラウンドのヒルクライミング
ここから darwin-skill の本領、最低次元を 1 つずつ直して独立ジャッジに再採点させる ループです。
今回は 3 ラウンドで打ち止め（デフォルトの MAX_ROUNDS）でした。
| Round | 直した次元 | 変更内容 | スコア | 判定 |
|---|---|---|---|---|
| 1 | dim5 具体性 | 曖昧措辞を排除し、出力フォーマット・type 一覧・subject 規則・番号付き手順を明記 | 19.2 → 55.4 | keep |
| 2 | dim1 frontmatter | description に「何をするか＋いつ使うか＋トリガー語」を明記 | 55.4 → 63.2 | keep |
| 3 | dim3＋dim4 | if-then の失敗分岐表と 🔴 CHECKPOINT を追加 | 63.2 → 77.5 | keep |
次元別の推移はこうなりました。
| dim | 基線 | R1 | R2 | R3 |
|---|---|---|---|---|
| 1 Frontmatter | 2 | 2 | 9 | 9 |
| 2 ワークフロー | 2 | 7 | 7 | 8 |
| 3 失敗モード | 1 | 3 | 3 | 8 |
| 4 チェックポイント | 1 | 2 | 2 | 9 |
| 5 具体性 | 1 | 7 | 8 | 8 |
| 7 アーキテクチャ | 2 | 7 | 8 | 8 |
| 8 実測 | 3 | 7 | 7 | 8 |
| 9 反例 | 1 | 4 | 4 | 5 |
ラチェットの記録（results.tsv）はこうなりました、全ラウンド keep・revert 0 です。
timestamp commit skill old_score new_score status dimension note eval_mode
2026-07-09T10:12 baseline commit-message-writer - 19.2 baseline - 初期評価（dim5/dim3/dim9が最弱） full_test
2026-07-09T10:31 fd706d8 commit-message-writer 19.2 55.4 keep dim5 具体性 曖昧措辞排除+フォーマット明記。dim2/dim7も連動上昇 full_test
2026-07-09T10:42 183041a commit-message-writer 55.4 63.2 keep dim1 frontmatter descriptionにトリガー語明記。挙動不変のためdim8は前回値 dry_run
2026-07-09T10:55 528c2a6 commit-message-writer 63.2 77.5 keep dim3+dim4 相関簇 if-then分岐表+🔴CHECKPOINT追加。P3で確認待ち挙動を確認 full_test
3 ラウンド後の全文がこちらです。
---
name: commit-message-writer
description: git の変更内容（diff・変更説明・ステージ済みファイル）から Conventional Commits 形式のコミットメッセージを生成する。「コミットメッセージを書いて/作って」「これコミットして」「commit message」「変更をコミット」と言われたら使う。type(scope) の判定、subject/本文の書き分け、無関係な複数変更の分割提案まで扱う。
---
# コミットメッセージ作成
git の変更内容から Conventional Commits 形式のコミットメッセージを作成する。
## 出力フォーマット
```
<type>(<scope>): <subject>
← 本文が必要なときは空行を1行はさむ
<body>
```
- type: feat / fix / docs / style / refactor / test / chore のいずれか
- scope: 変更した機能領域（auth, api, web など）。原則付ける
- subject: 命令形・72文字以内・末尾ピリオドなし・ファイルパスを入れない
- body: バグ修正では原因と対処を必ず書く
## 手順
1. 変更内容（diff・変更説明・ステージ済みファイル）を読み、変更の種類を判定する
2. type と scope を決める
3. subject を書く（例: `feat(auth): add JWT-based login`）
4. 本文が必要なら、何を・なぜ変えたかを書く
5. 無関係な複数の変更が混ざっている場合は、1つのコミットに詰め込まず、コミット分割の提案を主として提示する
🔴 CHECKPOINT: 分割案を提示したら、コミットを実行する前に必ずユーザーの確認を待つ
## 失敗時の分岐
| 状況 | 対処 |
| --- | --- |
| diff も変更説明も無い | 推測で書かず、`git diff --staged` の結果か変更内容の説明を求める |
| type が一意に決まらない | 候補を 2 つまで提示し、主目的をユーザーに確認する |
| 変更が大きすぎて要約できない | 主要な変更 3 点に絞って subject と本文を構成し、残りは本文の箇条書きに落とす |
2 つ、正直な注意点も。
1 つ目は サイズ制約との衝突。darwin-skill には「改善後は元の 150% 以内」というルールがありますが、今回のような極小の雑スキル（737 bytes）が相手だと 1 ラウンド目で即超過します（最終 2,096 bytes ≒ 284%）。ここはチェックポイントで「元が小さすぎるので適用外」と人間が判断しました。要所で人審が挟まる設計に助けられた場面です。
2 つ目は スコアの絶対値を信用しすぎない こと。採点は LLM ジャッジなので、19.2 や 77.5 という数字自体は走らせるたびに多少ブレます。SkillLens の実証（LLM 自評の精度 46.4%）を踏まえても、使い方は「どの次元が弱いかの傾向を掴む」＋「上がったときだけ keep するラチェット」に留めるのが正解だと思います。
microsoft SkillOpt
最後は Microsoft の SkillOpt です。これが一番ガチというか、研究寄りで重量級です。
コンセプト：スキルを「ニューラルネットのように学習」させる
SkillOpt の発想がとにかく独特で、スキル文書を、ニューラルネットの学習と同じやり方で最適化する というものです。
epoch・batch size・learning rate・validation gate といった、ディープラーニングそのままの用語が並びます。
スキル文書を「学習可能な状態（重み）」とみなし、モデル自体は凍結したまま Markdown だけを最適化していく、というイメージです。
最適化が終わって出てくる best_skill.md はただの Markdown なので、デプロイ時に追加のモデル呼び出しは発生しません。
6 段階の最適化ループ
公式ドキュメント（docs/guide/training-loop.md）によると、中身は次の 6 ステップを回します。カッコ内はニューラルネット学習に例えると、という補足です。
| ステップ | やること |
|---|---|
| Rollout | 現在のスキルでタスクを実際に実行し、スコアを得る（＝順伝播） |
| Reflect | 失敗・成功の軌跡を分析して、編集案（patch）を作る |
| Aggregate | 複数の編集案を階層的にマージする |
| Select | 編集案を重要度でランク付けし、予算（＝ learning rate）内に絞る |
| Update | 選ばれた編集をスキル文書に適用する |
| Gate | 取り分けておいた検証データで評価し、良くなったときだけ採用する |
特に効いているのが最後の Gate で、更新後のスキルが検証用データで本当に良くなっているときだけ採用します。
learning rate のスケジューラ（constant / linear / cosine / autonomous）まで実装されていて、本当に学習そのものです。
過去の改善を忘れないための Slow Update や、エポックを跨いだ学習メモを貯める Meta Skill など、ML の「破滅的忘却」対策に相当する仕組みまで入っています。
使うには：データセットと API キーが要る
その分、お手軽さは犠牲になります。Python 環境と、評価を回すための データセット、それに LLM の API キー が前提です。
git clone https://github.com/microsoft/SkillOpt.git
cd SkillOpt
pip install -e .
# Azure OpenAI / OpenAI / Anthropic / Qwen いずれかの API キーが必要
ANTHROPIC_API_KEY="sk-ant-..."
# 設定ファイルを指定して最適化を回す
python scripts/train.py --config configs/searchqa/default.yaml
Gradio 製の WebUI ダッシュボードも付いていて、学習の様子を可視化できます。
python -m skillopt_webui.app
SkillOpt は「ベンチマーク用のデータセットを用意して、本格的に最適化を回す」ための研究グレードのツールです。pip install してすぐ Claude Code で、という気軽さはないので、目的をはっきりさせてから入れるのがおすすめです。
比較と使う順番
3 つを並べると、見ているものとお手軽さがけっこう違います。
| skill-creator | darwin-skill | SkillOpt | |
|---|---|---|---|
| 提供元 | Anthropic 公式 | コミュニティ | Microsoft |
| 主目的 | 作る + 実出力で検証 | 既存スキルの書き方を磨く | 大規模に最適化 |
| 何を評価するか | 実際の出力（振る舞い） | 文書の質（9次元）＋実測 | タスクのスコア（学習で最適化） |
| 動かす場所 | Claude Code 内 | Claude Code 内 | Python + データセット |
| お手軽さ | ◎ 同梱・即実行 | ◯ npx 一発 |
△ 環境構築・API キー要 |
| トリガー(description)最適化 | あり | （文書品質の一部として） | — |
評価軸が違うので「どれが一番」という話ではなく、段階で使い分ける のがしっくりきます。
- まず skill-creator でスキルを作り、スキルあり/なしの出力比較で「そもそも効果があるか」を確かめる
- 次に darwin-skill で、曖昧な表現や失敗時の分岐、チェックポイントなど「書き方の質」を点数で詰める
- 本格的に回すなら SkillOpt。評価用データセットが用意できて、ML 的にガッツリ最適化したいときに投入する
個人で 1 〜 数個のスキルを良くしたいだけなら、skill-creator + darwin-skill の組み合わせで十分なことが多いと思います。SkillOpt は「データセットがあって、最適化を繰り返し回したい」フェーズの選択肢、という位置づけです。
まとめ
スキルは「書いて終わり」になりがちですが、今回触った 3 つに共通していたのは、「自分が良いと思っているか」ではなく「実際の出力で測る」 という発想でした。スキルを書く側としては耳が痛いですが、ここを数字で見られるようになっただけで、改善のサイクルが一気に回しやすくなりました
では、どこから手を付けるか。おすすめは段階的に試すことです。
- まずは手元のスキルを 1 つ、
/skill-creatorで スキルあり/なし比較 にかけて「そもそも効いているか」を見る - 効果が確認できたら、darwin-skill で曖昧表現や失敗時の分岐など「書き方の質」を点数で詰める
- 評価用データセットが用意できて本格的に最適化したくなったら、SkillOpt を検討する
「効いてるつもり」が数字であっさり覆る瞬間は、なかなか面白いですよ