Claude Codeのスキル（Skills）の作り方｜47本を回してわかった書き方と、古くなる手順書【2026年版】

Claude Codeで同じ作業を何度も頼んでいると、毎回同じ説明を打ち直すことになります。「商談前のリサーチは、まず会社の公開情報、次に最近のニュース、最後に質問を3つ」。昨日も書いた。先週も書いた。しかも書くたびに少しずつ言い方が変わるので、出来上がりもぶれます。

この「毎回の説明」を1つのファイルにまとめて、名前で呼べるようにしたものがスキル（Skills）です。当社は営業・マーケの定型業務をClaude Codeで回していて、2026年10月25日時点でスキルを47本持っています。

この記事は、その47本を作って直してきた記録です。書き方の骨格だけでなく、書いたのに呼ばれなかった、書いたのに守られなかった、書いた手順が古くなって事故になった、という失敗まで含めて書きます。

この記事の要点

• スキルは「呼ばれたときだけ本文が読まれる手順書」。説明文は毎回読まれ、本文は呼ばれたときだけ読まれる、という差がいちばん大事
• スキルにするのは「同じ順番で」「繰り返し」「合格ラインが言える」作業。1回きりの作業や、判断が毎回変わる作業は向かない
• 当社47本の説明文は合計18,461字、最長1,592字。使っていないスキルの説明文を約1,400字から285字に削った
• 手順書は古くなる。当社は存在しないスクリプトを3回続けて呼ぶ手順を放置し、別の古い手順で10記事の画像を崩した
• 最初の1本は、手で3回やってから書く。書いたあと1週間は、結果を人が見る

スキルとは｜呼ばれたときだけ読まれる「手順書」

スキルは、フォルダの中に `SKILL.md` というファイルを1つ置いたものです。 ファイルの先頭に「名前」と「説明文」を書き、その下に手順を書きます。置き場所は、全プロジェクトで使う個人用（ホームフォルダの `.claude/skills/`）と、特定のプロジェクトだけで使うもの（プロジェクトの `.claude/skills/`）の2つです（仕様の正本はAnthropicの公式ドキュメント［Agent Skills］https://docs.claude.com/en/docs/claude-code/skills ）。

呼び方は2通りあります。人が `/スキル名` で直接呼ぶ方法と、AIが説明文を読んで「今の依頼はこのスキルの出番だ」と判断して呼ぶ方法です。後者があるので、説明文の書き方が出来を左右します。

ここで押さえておきたいのが、読まれるタイミングの違いです。

CLAUDE.mdやフックとの分担も整理しておきます。CLAUDE.mdは「いつも守ってほしい判断の基準」、スキルは「決まった作業の順番」、フックは「破られたら実害が出る禁止」です。CLAUDE.mdの書き方はClaude CodeのCLAUDE.md書き方、フックはClaude Codeのフック（hooks）の使い方にまとめています。

何をスキルにするか｜3つの条件

結論：「同じ順番で」「繰り返し」「合格ラインが言える」の3つがそろった作業だけをスキルにします。

営業の仕事で当てはまりやすいのは、商談前のリサーチ、提案書の下書き、商談後のお礼メールのような、前後の工程が決まっている作業です。当社のサービスページで公開している実測では、商談準備は30分から1分になりました。

ただ、時間が減ったこと自体はゴールではありません。スキルにして効いたのは、準備の中身が毎回そろうことでした。誰が担当しても、初回の商談で相手に聞く質問が同じ水準で出てくる。準備の抜けで「それ、前にお伝えしましたよね」と顧客に言われる場面が減る。営業にとっての価値はこちらです。

反対に、向かないものもはっきりしています。1回きりの作業はスキルにしないでください。書く手間のほうが大きいうえ、使われないスキルが増えるほど、後で説明する「説明文の渋滞」が起きます。

書き方の骨格｜説明文・手順・止まる条件・終わり方

スキルの本文は、4つの部品で組みます。 当社の47本も、長さはばらばらですが骨格はこれです。

たとえば「商談後のお礼メール」なら、骨格はこのくらいで足ります。

説明文：商談の議事録や録画のメモを渡されて「お礼メールを作って」「フォローメールを書いて」と頼まれたときに使う。

>

手順：1. 議事録から相手の課題と、次に決めることを1つずつ抜き出す　2. 結論3行の本文を書く　3. 宛名・社名・日付を議事録と突き合わせる

>

止まる条件：議事録に相手の社名か次の約束が書かれていなければ、本文を作らずに「何が足りないか」を報告する

>

終わり方：下書きの保存場所と、突き合わせの結果を1行で報告する

見落とされやすいのが止まる条件です。AIは頼まれると最後まで作ろうとします。材料が足りないときに「足りません」と止まる指示が無いと、それらしい推測で埋めた文面ができあがります。当社でも、記事を公開するスキルには「品質の条件を満たせない日は公開を見送って報告する」と書いています。出さない判断を、手順の中に先に書いておくのがコツです。

説明文は「呼ばれる条件」だけを書く｜当社47本の実測

説明文は、会話を始めるたびに全スキル分が読まれます。 だから説明文は「何をするスキルか」の解説ではなく、「どんな依頼のときに呼ぶか」だけを書きます。

2026年10月25日時点で、当社の47本の説明文を数えると、合計で18,461字ありました。いちばん長いものは1,592字、短いものは151字です。長いものほど「こういう言い方をされたら呼ぶ」という依頼の例を何十個も並べていて、呼ばれる精度を上げようとして膨らんだものでした。

ここで1つ、当社で起きたことがあります。事業を縮小してもう使わなくなったスキルの説明文が、約1,400字のまま残っていました。使わないのに、会話のたびに1,400字ぶん読まれ続ける。他のスキルを選ぶときの判断材料に、関係のない文章が混ざっている状態です。2026年8月19日に、この説明文を「停止中。名前を明示されたときだけ動かす」という趣旨の285字に削りました。

説明文で効いた書き方は、次の3つです。

• 依頼の言い方で書く：「提案書を作って」「商談準備して」など、実際に頼むときの言葉を入れる
• 似たスキルとの境目を書く：「記事ファイルのパスを渡されたときは下書き保存だけ」のように、どこまでがこのスキルかを書く
• 止めているスキルは短くする：使わないスキルは削除するか、説明文を数行にする

本文は長くなる｜「書いたのに守られない」を順番で防ぐ

本文は、運用するほど長くなります。 当社の47本の本文（SKILL.md）は、中央値が約8,200字、いちばん長いものは約13万字ありました。失敗が起きるたびに「次からこうする」を書き足していくと、こうなります。

長くなった本文で起きやすいのが、書いてあるのに守られないことです。当社の記事公開スキルでは、「画像の生成から先は安いモデルに任せる」と書き足したのに、実際の記録を数えると任せた回数は0回でした。この件はClaude Codeのモデル使い分けで詳しく書いています。

直し方は、文章を強くすることではありませんでした。「執筆が終わった直後の最初の1手は、必ず任せる呼び出しにする」と、手順の中の位置で固定したことです。「なるべく」「原則として」と書いた指示は、長い本文の中で他の指示に負けます。守らせたい指示は、どの手順の直後にやるかまで書きます。

それでも守られない種類の指示は、スキルではなくフックで止める側に移します。スキルは「頼む」仕組みで、必ず守らせる仕組みではありません。

スキルは古くなる｜存在しないスクリプトを3回呼んだ

スキルでいちばん怖いのは、書いた手順が静かに古くなることです。 手順書の中で名前を出していたスクリプトや仕組みは、作業を改善していくうちに名前が変わったり、消えたりします。手順書のほうは誰も書き換えません。

当社では、記事公開のスキルがすでにリポジトリから消えた画像生成スクリプトを呼ぶ手順のまま残っていました。この食い違いが実行結果の申し送りに9月2日・3日・5日と3回続けて載ってから、ようやく手順書を実体に合わせて直しています。作業そのものが止まる種類の失敗ではなかったので、読む人が拾うまで表に出ませんでした。

もう1件は、もっと実害が大きいものでした。同じスキルの「SNSで共有されたときの画像（OG画像）を作る」手順が、本文用の図解スクリプトを使う書き方になっていました。9月2日に点検すると、8月21日以降に公開した10記事のOG画像が、スマホのカード表示で残る中央の安全域からはみ出していました。手順書が間違っていたので、AIは手順どおりに10回、同じ崩れ方を繰り返していたわけです。

この2件から決めたことは2つです。

1. 仕組みを変えたら、その仕組みを呼んでいるスキルを同じ日に検索して直す。スクリプト名でスキルのフォルダを検索すれば、数秒で分かります
2. 複数のスキルで使う手順は、1か所の共通ファイルに置いて参照する。当社ではブラウザの選び方の手順を共通ファイルにまとめ、スキル7本と定時タスク20本がそこを読みます。直すのは1か所で済みます

反論：「プロンプトをその都度書けば十分では？」

この反論はもっともです。 上で書いたとおり、スキルは古くなりますし、本文は長くなり、説明文の管理も必要になります。その都度書くプロンプトなら、少なくとも古くなることはありません。

当社の答えは、「週1回以上くり返すものだけはスキルにする。それ以外はその都度でいい」です。その都度書くプロンプトは、書く人と日によって中身が変わります。営業の仕事で困るのは、作業の速さより品質のばらつきです。先週の担当者は相手の最近のニュースまで調べたのに、今週の担当者は会社概要だけ、という差は顧客から見えます。

逆に、「全部スキルにすれば楽になる」という方向も勧めません。使われないスキルは説明文として毎回読まれ、似たスキル同士で呼び間違いも起きます。当社でも提案資料を作るスキルが用途違いで4本あり、それぞれの説明文に「どの場面の資料か」の境目を書いて選び分けています。数を増やす前に、今あるスキルが本当に呼ばれているかを見るほうが先です。

最初の1本の作り方｜手で3回やってから書く

結論：いきなりスキルを書かず、まず手で3回やります。

1. 手で3回やる：同じ作業を、Claude Codeとの普通の会話で3回やる。うまくいった回の指示を残しておく
2. 毎回同じだった部分を書き出す：3回のうち毎回言ったこと＝手順、毎回直したこと＝合格ラインと止まる条件になる
3. スキルにして、呼び方を決める：説明文には、自分が実際に頼んだときの言い方を入れる
4. 1週間は結果を人が見る：「手順どおりに動いたか」「止まるべきところで止まったか」を確かめ、ずれた分を手順に足す

手で3回やる前に書いたスキルは、たいてい手順の粒度が合いません。細かすぎる手順は状況が少し変わると守れなくなり、粗すぎる手順は書かなかった部分でぶれます。3回やると、どこが毎回同じで、どこが毎回違うかが見えてから書けます。

スキルを毎朝決まった時刻に動かしたくなったら、次は定時実行です。落ちたことに気づく仕組みまで含めてClaude Codeのスケジュール実行に書いています。営業・マーケの業務でどこからスキル化すると効くかを一緒に決めたい場合は、当社のClaude Code導入支援でもご相談を受けています。

よくある質問

Q. スキルとカスタムのスラッシュコマンドは何が違いますか？

どちらも `/名前` で呼べますが、スキルはAIが説明文を読んで自分から呼ぶこともできる点が違います。また、スキルはフォルダ単位なので、テンプレートや参照資料、スクリプトを同じフォルダにまとめて置けます。人が毎回自分で呼ぶ短い定型文ならコマンドでも足ります。

Q. スキルが呼ばれないときは、どこを直せばいいですか？

まず説明文を見ます。実際に頼むときの言い方が入っているか、似たスキルとの境目が書かれているか、の2点です。それでも呼ばれないときは、`/スキル名` で直接呼んで本文が正しく動くかを切り分けます。本文が動くなら、直すのは説明文だけです。

Q. スキルの本文はどのくらいの長さが適切ですか？

決まった上限はありませんが、長い参照資料は付属ファイルに分けて、本文には「いつそれを読むか」だけを書くのがおすすめです。本文は呼ばれるたびに全部読まれるので、毎回必要ない資料まで入れると、肝心の手順が埋もれます。当社の本文は中央値が約8,200字ですが、長いものは約13万字まで膨らんでおり、ここは当社自身もまだ分けきれていません。

Q. 社内でスキルを共有するときの注意点はありますか？

プロジェクト用のスキルはリポジトリに入れて共有できます。注意したいのは、スキルの中に個人のアカウント情報や社外秘の数字を書かないことです。手順書は読まれる前提の文書なので、共有の範囲を超えて広がっても困らない内容にしておきます。

Q. スキルは誰が直すべきですか？

その作業の結果に責任を持つ人が直すのがいちばんずれません。当社では、スキルの実行結果に「何が足りなかったか」を申し送りとして残し、それを読んだ人が手順に足しています。ただ、上で書いたとおり申し送りが3回続くまで直さなかったこともあります。同じ申し送りが2回出たら直す、と決めておくと放置を防げます。

---

執筆・監修：佐々木 優希（上場企業 営業統括 兼 AI責任者）