Skill(スキル)ってなに?Claudeに手順書を渡す仕組み

Skill は「Claudeに渡す手順書」

Claude Code を使っていると、毎回同じ説明を書いている自分に気づく瞬間があります。「この形式でリリースノートを書いて」「うちのプロジェクトのコミットメッセージはこのルールで」といった指示です。そういう繰り返しの説明を、あらかじめファイルにまとめて置いておき、必要なときにClaudeが自分で読みに来てくれるようにする仕組みが Skill(スキル) です。

例えるなら、新しく入ってきたアルバイトの人に渡す業務マニュアルに近いものです。レジの締め方、電話の取り次ぎ方、発注のルール。毎回口頭で説明するのは大変なので、棚にマニュアルを並べておいて「レジ締めのときはこの緑のファイルを見てね」と伝えておく。すると本人が必要なタイミングで棚から取り出して読んでくれます。Skill もこれと同じで、作業の種類ごとに手順書を用意しておくイメージです。

普通に毎回指示するのと何が違うの?

「それ、チャットに毎回貼り付ければいいのでは?」と思うかもしれません。実際、最初のうちはそれでも回ります。ただ、手順が長くなってくると事情が変わってきます。

もうひとつ地味に効いてくるのが、必要なときだけ読み込まれるという点です。全部の手順書を最初から全部読ませておくと、Claudeが処理する情報量がふくらんで、肝心の作業への集中がぼやけがちになります。Skill は「今回の作業に関係ありそうなもの」を選んで参照する形なので、無関係な手順書に引きずられにくくなります。

どんなものを Skill にすると嬉しいか

向いているのは、手順が決まっていて、しかも何度も発生する作業です。逆に、その場かぎりの一回きりの依頼をわざわざ Skill にする意味はあまりありません。

• プロジェクト独自のコーディング規約に沿ってコードを書く
• 決まったフォーマットのドキュメントや議事録を作る
• リリース前のチェック項目を順番に確認していく
• 特定のツールやライブラリの、社内でのお作法にそった使い方

逆に「このバグを調べて」のような、毎回内容が違う依頼は Skill 化しにくい部類です。ここの線引きは、実際に「またこれ書いてるな」と感じた回数で決めるのがいちばん確実だと思います。3回同じ説明をしたら Skill にする、くらいの基準でも十分です。

書き方のコツ:人間向けのマニュアルと同じ

Skill の中身は、特殊なプログラミング言語ではなく、基本的には普通の文章です。だからこそ、人間向けのマニュアルを書くときのコツがそのまま当てはまります。

いちばん大事なのは具体的に書くこと。「読みやすいコードを書く」ではなく「1つの関数は50行を超えないようにし、超えるなら分割する」のように、判断に迷わない書き方をします。抽象的な理念だけ書いてあるマニュアルが現場で役に立たないのと同じ理屈です。

それから、やってほしくないことも書いておくと精度が上がります。「既存のテストは書き換えない」「設定ファイルは勝手に追加しない」といった禁止事項は、あとから「そこ触ってほしくなかったのに」となるのを防いでくれます。

最初から完璧なものを目指す必要はありません。ざっくり書いて使ってみて、期待とズレたところがあったらその都度追記する。実際、運用しながら育てていくほうが結果的にいい手順書になります。

使い始めるときにつまずきやすいところ

よくあるのが、Skill を用意したのに使われている気がしない、というケースです。多くの場合、その Skill が「どういうときに使うものなのか」の説明が曖昧なことが原因になります。マニュアルの背表紙に何も書いていなければ、棚から取り出しようがないのと同じです。用途や適用場面をはっきり書いておくと、使われる確率が上がります。

もうひとつは、1つの Skill に何もかも詰め込んでしまうパターン。フロントの規約もインフラの手順もリリース作業も全部1ファイル、という状態だと、どの部分が今の作業に関係するのか判別しづらくなります。作業の単位ごとに分けておくほうが扱いやすいです。

まず何をすればいい?

いきなり体系立てて整備しようとすると挫折しがちなので、直近で2回以上同じ説明をした作業を1つだけ選んで、その手順を文章にしてみるところから始めるのがおすすめです。使ってみて手応えがあれば増やせばいいし、なければその作業は Skill 向きではなかった、というだけの話です。