- Skillが便利と聞いたけど、何を書けばいいのか分からない
- 作り方の解説を読むと、ファイルの名前や書き方の決まりが出てきて手が止まる
- 作ってみたのに、記事を頼んでも使われている気配がない
Skillの解説を読むと、「フォルダを作って、決まった名前のファイルに、決まった形で書く」と出てきます。ここで手が止まる人は多いと思います。
でも、そのファイルは自分で書かなくていいんです。
僕も、記事を書く作業とキーワードを調べる作業は、それぞれSkillにして使っています。
Skillは「その作業のときだけ開く手順書」
最初に、Skillが何なのかを、1つのたとえで押さえておきます。
本棚に並んだ手順書を思い浮かべる
Claude Codeの横に、本棚があると思ってください。
棚には手順書が並んでいて、背表紙（名前と説明文）だけはいつも見えている。「記事の下書きを書いて」と頼まれると、AIは背表紙を見て「これだ」と思った1冊を開き、中の手順どおりに作業します。
毎回読む決まりのファイル（CLAUDE.md）との違いは、開くタイミングです。
| 決まりのファイル | Skill | |
|---|---|---|
| 読まれるとき | 作業のたびに、毎回全部 | 背表紙はいつも。中身は使うときだけ |
| 向いている中身 | どの作業でも守ること（「一人称は僕」など） | その作業でしか使わない手順と見本 |
| 長くなると | 毎回読む量が増えて重くなる | 使わない日は開かれないので、気にならない |
だから、記事を書く手順が何十行あっても、Skillなら困りません。リンクの点検を頼んだ日には、開かれもしないので。
呼び方は2つ
Skillの呼び方は2つあります。
1つは、頼んだ内容に合わせてAIが自分で開く形。もう1つは、自分で「/名前」と打って呼ぶ形です。「/recipe-draft」と打てば、その手順書が必ず開かれる。
AIに勝手に開かせたくない手順（たとえば入稿の手順）は、「/名前で呼んだときだけ動く」設定にしておくこともできます。
Skillは、自分で書かずに「頼んで作る」
ここがこの記事の本題です。Skillは、次の4つの手順で作れます。
1. まず1本、会話の中で一緒に仕上げる
いきなりSkillを作ろうとしないでください。
最初は、ふだんどおり会話で記事を1本仕上げます。見出しを出させて直して、本文を書かせて直して、点検させて。この「直した」ところが、あとでSkillの中身になります。
頭の中で考えただけの手順をSkillにすると、たいてい穴があります。僕も、よさそうだと思った構成の手順をそのままSkillにして、1本目で見出しが多すぎて何度も止まる羽目になりました。
2. 「今やった手順をSkillにして」と頼む
1本仕上がったら、同じ会話のまま、こう頼みます。
今この会話でやった記事の書き方を、Skillにして。名前は「blog-draft」。説明文には「記事の下書きを書いて」「新しい記事を作って」と頼まれたときに使う、と書いて。見出しを出したところで一度止まる手順にして。途中で直した点も、守ることとして入れて。
これで、Skillのフォルダとファイルが作られます。置き場所も、ファイルの形も、AIが整えてくれる。
ポイントは2つ。説明文に自分がふだん頼むときの言葉を入れてもらうこと。それと、どこで止まるかを指定すること。この2つが抜けると、あとで「開かれない」「止まらずに最後まで書く」が起きます。
3. できた中身を読んで、3つだけ確かめる
作られたファイルは、一度だけ自分で読みます。全部を細かく見なくていいので、ここだけ確かめてください。
- 説明文に、自分がふだん使う頼み方の言葉が入っているか
- 見出しのところで止まって見せる、と書いてあるか
- その記事だけの事情（特定の商品名など）が混ざっていないか
3つ目は見落としがちです。1本の記事から作ったので、その記事の話が手順に入り込んでいることがある。見つけたら「Skillから〇〇の話を消して」と頼めば直ります。
4. 次の記事で試して、直したいところをその場で言う
次の記事は「/blog-draft」と打ってから頼みます。
手順どおりに進まないところがあったら、その場で「Skillの手順3を、〇〇するように直して」。Skillのファイルを直すと、Claude Codeは会話の途中でも読み込み直してくれます。
ただ、直す前の手順をすでに読んでいた会話だと、古い手順も会話に残っています。直したあとは、会話を新しくしてから試すほうが確実です。
Skillは「作って終わり」ではなく、記事を書くたびに1行ずつ育てるもの。直したい点に気づいたら、その場で頼んで直すのが一番早いです。
作るとこうなる：作り置きレシピのブログの例
この4つで作ると、どんなSkillになるのか。架空のブログで組んだ、公開用の例です。
| 欄 | 中身 |
|---|---|
| 名前 | recipe-draft |
| 説明文 | 作り置きレシピの記事の下書きを書くときに使う。「下書きを書いて」「レシピの記事を作って」と頼まれたとき、材料フォルダのメモから記事を作る |
| 手順1 | 材料フォルダのメモを読み、実際に作った料理・かかった時間・保存した日数を書き出す。メモにないことは書き出さない |
| 手順2 | 読者が作る前に迷うこと（何日もつか、冷凍できるか）に答える見出しを出す。ここで止まって見せる |
| 手順3 | OKが出たら本文を書く。書き方は「見本.md」の段落に合わせる |
| 手順4 | 保存日数と冷凍できるかが、メモと一致しているかを1つずつ照らす |
| 手順5 | 「下書き」フォルダに「日付_料理名」で保存し、メモになかったので書けなかったことを報告する |
| 付属のファイル | 見本.md（自分で書いた段落3つと、AIの文を直す前・直した後の組） |
「見本」のファイルが効きます。書き方は言葉で説明するより、見せたほうが早いので。AIが書いてきて自分が直した文を、直す前と後で並べておけば、それがそのまま見本になります。
ブログで最初に作るSkillは3つ
Skillは何個でも作れますが、増やすほどいいわけではありません。背表紙が増えるほど、AIが選び間違えやすくなります。
ブログなら、最初はこの3つで十分です。
| Skillにする作業 | なぜSkillに向いているか |
|---|---|
| 記事の下書き | 材料を読む→見出し→本文→点検、の順が毎回同じ。見出しで止まってほしい |
| 図や画像づくり | 色・大きさ・ファイル名の決まりが細かく、図を作るときにしか使わない |
| キーワードの候補集め | 調べる場所と、候補を並べる表の形が毎回同じ |
逆に、Skillにしなくていいものもあります。
| Skillにしない作業 | なぜか |
|---|---|
| リンク切れの点検 | 「リンクを確かめて」の一言で済む |
| 何の記事を書くか決める | 決めるのは自分の仕事。手順書にすると、AIが手順どおりに「決めて」しまう |
| 月に1回しかやらない作業 | 手順をメモに置いて、そのつど貼るほうが早い |
見分け方は1つ。同じ指示を、毎回コピーして貼っているかどうか。貼っているなら、それはもうSkillにしていい手順です。
決まりのファイルとSkill、どっちに書く？
迷ったら、1行で言い切れるかどうかで分けます。
| 中身 | 置く場所 | なぜ |
|---|---|---|
| 一人称は「僕」、です・ます調 | 決まりのファイル | 作業の報告にも出るので、毎回要る |
| 公開済みの記事は書き換えない | 決まりのファイル | どの作業の途中でも破られたら困る |
| 書く順番、見出しの立て方 | Skill | 記事を書くときにしか使わない |
| 自分の記事の見本 | Skillの付属のファイル | 長くて、記事を書くときにしか読まない |
言い切れるなら決まりのファイル、番号を振りたくなるならSkill。決まりのファイルの中身は、こちらで。
Skillがうまく動かないときの直し方
作ったSkillが思ったように動かないとき、原因はだいたいこの4つでした。
| 困ったこと | 原因 | 直し方 |
|---|---|---|
| 頼んでも開かれない | 説明文に、ふだんの頼み方の言葉が入っていない | 説明文に「下書きを書いて」などの言葉を足す。急ぎなら「/名前」で呼ぶ |
| 似たSkillの、違う方が開かれる | 説明文がどちらも「記事」の話で区別がつかない | 説明文に「使わない場面」も書く（「新しく書くときは使わない」など） |
| 開かれたのに、最後の点検が飛ばされる | 長い作業の終わりほど抜けやすい | 「終わったら、点検した項目と結果を報告に書く」と手順に入れる |
| 直したのに、前の手順のまま動く | 直す前の手順が、会話の中に残っている | 会話を新しくしてから試す |
1つ目は、僕が最初にはまったところです。最初の説明文は「記事の品質を上げるための手順」。中身の要約としては合っているのに、「下書きを書いて」という頼み方と、言葉が1つも重なっていなかった。
確かめたいときは、頼む前に「今使えるSkillを挙げて」と聞いてみてください。名前が出てこなければ置き場所の問題、出てくるのに使われなければ説明文の問題です。
3つ目の点検は、何度言っても守られないなら、点検そのものを小さなプログラムにしてSkillに付けるのも手です。僕は「同じ文末が続いていないか」を数えるプログラムを、Claude Codeに作ってもらって付けています。数えるのはプログラムなので、見落としがありません。
ブログ用のSkillでよくある質問
プログラミングの知識は要る？
要りません。中身はふつうの日本語の文章で、ファイルの形はClaude Codeが整えてくれる。
さらに手を抜きたいなら、Anthropicが出している「Skill作りを手伝う追加機能」（skill-creator）もあります。作ったSkillがちゃんと動くかを試す機能まで付いているので、Skillが増えてきたら入れてみる価値はあります。
人が配っているSkillを、そのまま使っていい？
形の参考にするのはあり。説明文の書き方や手順の区切り方は、かなり勉強になる。
ただ、書き方のSkillは、そのまま使っても自分の声にはなりません。見本の文章が、作った人の記事なので。それと、プログラムが入っているSkillは、入れる前に「このSkillが何をするか説明して」とClaude Codeに読ませてください。Skillの中のプログラムは、自分のパソコンの上で、自分のファイルに対して動くので。
Codexでも同じSkillが使える？
Codexにも、同じ形（SKILL.md）のSkillの仕組みがあります。中身の書き方は同じなので、置く場所さえ合わせれば使い回せる。置き場所が分からなければ、Codexに「このSkillを使えるように置いて」と頼めば済みます。
Skillは、書き方を覚えた人が作るものではなく、1本仕上げるたびに育っていくものです。最初の1本は、次の記事を書くついでに作ってみてください。
毎回守ってほしい側の決まりは、こちらの記事で。
