第35回: 実用スキルの開発とテスト — より良いスキルの作り方

この回で学ぶこと

より実用的なスキルの作り方
スキルのテスト方法と、うまくいかないときの直し方
スキル開発で守るべき3つのルール

前回のおさらい

SKILL.mdにスキルの定義をMarkdownで書くだけで、秘書に新しい能力を追加できることを学んだ。翻訳スキルを自作し、description（スキルの説明）がスキル発動のカギであること、YAMLの書き方の注意点も学んだ。今回はより実用的なスキルを作り、テストと修正の方法も学ぶ。

メール下書きスキルを作る

今回作るのは、件名と要点を伝えると丁寧なメール文面を自動生成するスキル。ビジネスとカジュアルの2つのトーン（文体）を使い分けられるようにする。

ステップ1: スキルフォルダを作る

mkdir -p ~/.openclaw/skills/email-draft

ステップ2: SKILL.mdを作成する

~/.openclaw/skills/email-draft/SKILL.md に以下を書く:

---
name: email-draft
description: "Draft an email from a subject and key points. Use when the user asks to write, draft, or compose an email, メール作成, メール下書き."
version: 1.0.0
---

# メール下書きスキル

件名と要点を受け取り、指定されたトーンでメール文面を生成する。

## ルール
- トーンの指定がなければ「ビジネス」をデフォルトにする
- ビジネストーン: 敬語、丁寧な挨拶文、締めの定型文（「何卒よろしくお願いいたします」等）
- カジュアルトーン: 親しみやすい口調、簡潔な文面
- 件名・本文・署名を含む完成形で返す
- 署名は「[あなたの名前]」のプレースホルダーを入れる

## 使い方の例

入力: 「件名: 会議の日程変更、要点: 来週水曜→木曜に変更」
出力:
件名: 会議の日程変更のご連絡
本文:
お疲れ様です。
会議の日程について、来週水曜日から木曜日への変更をお願いしたく、ご連絡いたします。
ご調整のほど、何卒よろしくお願いいたします。
[あなたの名前]

入力: 「カジュアルで、件名: 飲み会のお誘い、要点: 今週金曜19時渋谷」
出力:
件名: 金曜飲みに行かない？
本文:
今週の金曜、19時から渋谷でどう？
都合よかったら教えて！
[あなたの名前]

前回の翻訳スキルとの違いに注目してほしい。今回は「使い方の例」に入力と出力の具体例をセットで書いている。こうすると、秘書が「この入力にはこういう出力を返せばいいんだな」と理解しやすくなり、期待通りの結果が出やすくなる。

description を英語で書いている理由: 前回学んだ通り、description は秘書がスキルを選ぶときの判断材料。英語で書く方がマッチング精度が高い。ただし日本語のキーワード（「メール作成」「メール下書き」）も含めておくと、日本語の指示でも発動しやすくなる。

スキルのテスト

スキルを作ったら、いくつかのパターンで試して、期待通りに動くか確認する。

テスト1: 基本パターン

「件名: お礼、要点: 先日はありがとうございました」と送る。ビジネストーンのメールが返ってくるはず。

テスト2: トーン切り替え

「カジュアルで、件名: ランチのお誘い、要点: 明日12時どう？」と送る。ビジネスとは違うくだけた文面が返ってくるはず。

テスト3: 短い入力

「件名: 確認、要点: OK」のように極端に短い入力でも、メールとして成立する文面が返ってくるか。

テスト4: 長い入力

要点を5〜10個並べた長い入力でも、読みやすくまとまったメールが返ってくるか。

うまくいかないときの直し方

テストで期待通りの結果が出なかった場合、直し方は2つある。

直し方1: SKILL.mdの指示を書き直す

プログラミングのように複雑なデバッグは不要。日本語の指示を書き直すだけ。

例えば「メールが長すぎる」と感じたら、ルールセクションに以下を追記する:

- 本文は5行以内に収める
- 箇条書きは使わず、文章で書く

SKILL.mdを保存すると、次に秘書に話しかけたときから変更が反映される（デフォルトでファイルの変更を自動検知する設定になっている）。

変更が反映されない場合: まれに同じ会話の中では反映されないことがある。その場合は新しいセッション（新しい会話）を開始すれば確実に反映される。

直し方2: スキルが発動しているか確認する

そもそもスキルが認識されていない可能性もある。以下のコマンドで確認できる:

openclaw skills list --eligible

このコマンドは、現在使える状態にあるスキルの一覧を表示する。ここに自分のスキル名（email-draft）が表示されていなければ、スキルが読み込まれていない。

読み込まれていない場合のチェック:

ファイルの配置場所が正しいか（~/.openclaw/skills/email-draft/SKILL.md）
フロントマターの -- が正しく開始・終了しているか
description にコロン+スペース（: ）が含まれる場合、ダブルクォートで囲んであるか（前回学んだ注意点）
name が英語小文字とハイフンのみで書かれているか

さらに詳しく調べるには:

openclaw skills info email-draft

このコマンドで、スキルの詳細情報（名前・説明・読み込み元・不足している設定）を確認できる。

スキル開発で守るべき3つのルール

自作スキルの品質を高めるためのルールを紹介する。

ルール1: 1つのスキルに1つの機能

1つのスキルに「翻訳もメール作成もやる」と複数の機能を詰め込まない。翻訳スキルとメール作成スキルを別々に作る。

理由は2つある。まず、秘書がスキルを選ぶとき、description の説明が1つの機能に絞られている方がマッチング精度が高い。複数機能が書いてあると、どの場面で使うべきか秘書が迷う。次に、1つの機能に特化したスキルの方が指示がシンプルになり、安定して動く。

ルール2: 入力→出力の具体例を入れる

SKILL.mdの「使い方の例」に「この入力にはこう返す」という具体例を書いておくと、秘書の出力精度が格段に上がる。

今回のメール下書きスキルでは、ビジネストーンとカジュアルトーンの両方の具体例を入れた。これにより秘書は「ビジネスならこのレベルの丁寧さ」「カジュアルならこのレベルのくだけ具合」を理解できる。

ルール3: SKILL.mdは30〜50行に収める

SKILL.mdが長すぎると、秘書が読み込むときのトークン（処理量）が増え、コストが上がる。目安は30〜50行。最大でも80行程度。

もっと詳しい情報（参考資料や詳細なルール）を入れたい場合は、スキルフォルダの中に別ファイルを作り、SKILL.mdからそのファイルを参照する方法がある:

## 詳細なルール
詳しくは `{baseDir}/references/email-rules.md` を参照すること。

{baseDir} はスキルフォルダのパスに自動で置き換わる特別な書き方。こうすることでSKILL.md本体はコンパクトに保ちつつ、必要なときだけ詳細情報を読み込むことができる。

ここまでのスキル開発まとめ

第34回〜第35回で学んだスキル開発の全体像を整理する:

フォルダを作る: ~/.openclaw/skills/スキル名/
SKILL.mdを書く: フロントマター（name + description）+ 指示書（ルール・例・手順）
テストする: 基本パターン、トーン切り替え、短い入力、長い入力
直す: 指示の書き直し or openclaw skills list --eligible で読み込み確認
育てる: 使いながら指示を改善していく

スキルは「一度作ったら完成」ではなく、使いながら指示を磨いていくもの。最初は簡単な指示で始めて、期待と違う出力が出たら指示を追記・修正する。この繰り返しでスキルの精度が上がっていく。

ゴール状態

メール下書きスキルを自作して動かせた
テストの4パターン（基本・トーン切替・短い入力・長い入力）を実行できた
うまくいかないときの直し方（指示書の修正 + openclaw skills list --eligible で確認）を知っている
3つのルール（1スキル1機能・具体例を入れる・30〜50行に収める）を理解している