Claude Codeスキルの作り方。繰り返し業務を自作で任せる

Claude Codeのスキルとは、繰り返し使う手順や指示を「SKILL.md」というファイルに書いて保存し、必要な場面で呼び出せるようにする再利用部品です。一度作れば同じ指示を毎回書き直す必要がなくなり、繰り返し業務を決まった品質でAIに任せられます。

僕はAIVESTという会社を経営しながら、ブログの記事制作、Xの運用、広告リサーチ、経営管理までを数十本の自作スキルで動かしています。この記事では、その実運用で固まった作り方の最小手順、どの業務をスキル化するかの選定基準、誤発動を防ぐ書き方、そして数十本を育てる運用までを実物ベースで解説します。

Claude Codeのスキルとは？同じ指示を毎回書かない再利用部品

毎回プロンプトを書く運用との違い

スキルの正体は、決まったフォルダに置いた1枚のテキストファイル（SKILL.md）です。冒頭に「いつ使うスキルか」の説明文を書き、本文に手順を書いておくと、Claude Codeは関連する依頼が来たときに自動でそれを読み込み、手順どおりに動きます。スラッシュ記号にスキル名を続けて、手動で直接呼び出すこともできます。

毎回プロンプトを書く運用との最大の違いは、保存が効くことです。チャットに書いた優れた指示は、その場で消費されて終わります。スキルにすれば、同じ品質の指示が明日も来月も、誰が依頼しても同じように再現されます。

公式ドキュメントは、スキルを作るべきタイミングをこう書いています。

同じプレイブック、チェックリスト、または複数ステップの手順をチャットに何度も貼り付けるときや、CLAUDE.md のセクションが事実ではなく手順に成長したときにスキルを作成します。（Claude Code公式ドキュメント）

判断基準はシンプルで、「同じ指示を2回書いたか」。書いたなら、それはスキル化の候補です。

手順書が「読む文書」から「実行される部品」に変わる

経営の言葉に翻訳すると、スキル化は業務標準化の実行形です。ふつうのマニュアルは人が読んで実行する文書で、読まれなければ死にます。スキルは違います。手順書そのものが、AIによって毎回実行される部品になるんですよね。

経営者の頭の中にしかなかった「この作業はこう進める」という口頭指示がファイルとして会社に残り、毎回同じ品質で実行される。属人化の解消と業務の標準化が、文書整備ではなく日々の運用として実現します。

スキルの作り方。SKILL.mdを1枚置くだけの最小手順

作り方は拍子抜けするほど簡単で、決まった場所にフォルダを作り、SKILL.mdを1枚置くだけです。プログラミングは不要で、中身は日本語の指示文で構いません。

保存場所は主に2つあり、どこに置くかで使える範囲が決まります（2026年8月時点の公式仕様）。

大事なのは、最初から完成品を狙わないことです。僕の数十本のスキルも、ほぼ全部が10行前後の素朴なメモから始まり、実運用の失敗を吸収して今の形になっています。

どの業務をスキル化するか。選定の3基準

作り方より先に迷うのが「何をスキルにするか」です。僕は新しくスキルを作る前に、次の3つを必ず自分に問います。スキルを増やしすぎて在庫を腐らせた反省から固めた基準です。

基準は「頻度・判定・境界」の3つ

1. 週1回以上繰り返すか。月1回の作業なら、その都度指示を書いても大した損はありません。頻度が高い業務ほどスキル化の投資が早く回収できます。

2. 合否を機械的に判定できるか。「できた・できていない」の基準を言葉にできる業務は、AIが自分で検算しながら完了まで走れます。「いい感じにやって」としか言えない業務は、スキル化しても品質が安定しません。

3. やらない条件を言語化できるか。「この場合はこの作業をしない」「ここから先は人間が判断する」という境界を言葉にできるか。これが言えない業務をスキルにすると、次の章で書く誤発動の温床になります。

週1以上繰り返し、合否の基準を言葉にでき、やらない条件まで言語化できる業務。この3つが揃った業務は、スキル化するとほぼ確実に立ち上がります。

この3基準は、業務標準化の判定基準そのもの

気づいた方もいると思いますが、これはAI以前からある「マニュアル化できる業務の条件」と同じです。つまりスキル化の選定とは、自社の業務のどれが標準化可能かの棚卸しなんですよね。どの業務がAIに向くかという全体像は生成AIの社内活用の記事に譲りますが、スキル化はその中でも繰り返しの定型業務を狙い撃ちする手法です。

誤発動を防ぐ書き方。「使う条件」と「使わない条件」をセットで書く

スキルが数本のうちは問題になりませんが、10本を超えたあたりから必ず起きるのが誤発動です。似た用途のスキルが隣り合うと、Claude Codeが意図と違う方を選ぶことがあります。

僕の環境には執筆時点で70本のSKILL.mdがあり（外部配布のものを含む。自作は数十本）、そのうち41本には「使う条件」だけでなく、「このときは使うな」という否定条件を明記しています。

実例を挙げます。僕の環境には、社内の会議録画を検索するスキルと、外部の記事や講座資料を検索するスキルが同居しています。以前は外部資料を探す場面で会議録画側の検索が走り、「そこにその資料は無い」という空振りが起きていました。対策として、スキルの説明文に「外部資料はこちらのモードを使う。会議録画専用の検索先には無い」と、探す先の境界そのものを書き込みました。YouTube動画の文字起こしスキルとZoom録画の処理スキルのような近縁ペアも同様に、互いの説明文へ「その場合はあちらのスキルを使う」と相互参照を書いています。

誤発動対策の本質は、「いつ使うか」と同じ熱量で「いつ使わないか」を書くことです。世に出ている作例やテンプレートは発動させる側の書き方に集中しがちですが、本数が増えた実運用で効くのは使わない条件の方です。人間の組織でいえば、部署の分掌規程に「この案件は隣の部署へ回す」と書くのと同じ発想です。

数十本を運用して分かった育て方。作る→評価する→直すのライフサイクル

スキルは作って終わりではなく、育てるものです。数十本規模になった僕の運用は、「作る・評価する・直す」の3工程を回すことに尽きます。そして、この3工程そのものもスキルにできます。

スキルを作るスキル、評価するスキル、診断するスキル

僕の環境には、スキルの新規作成を担当するスキルがあります。「こういうスキルを作りたい」と伝えると、目的と発動条件のヒアリング、既存スキルとの重複確認、SKILL.mdの生成、検証までを定型手順で進めてくれる、いわばスキル工場です。同様に、できたスキルの構造や発動精度を採点する評価用スキルと、運用中に不調が出たスキルを診る診断用スキルも用意しています。

スキルでスキルを作ると聞くと大げさですが、理屈は単純です。スキルを作ること自体が週1以上繰り返す定型業務になったからスキル化した、というだけ。前章の3基準を「スキル作成」という業務に適用した結果です。

直す前に、失敗をテストに固定する

育て方でいちばん効いているのは、僕の診断用スキルの冒頭に書いてある、この運用原則です。

想像で直さない（実際の失敗を見てから直す）。直す前に、その失敗を合否テストに固定する（同じ事故を二度と通さない）。

スキルが変な動きをしたとき、思いつきで手順を書き換えるのではなく、まず失敗の実例を記録し、「この入力でこの失敗が再現しないこと」という機械的なチェック項目にしてから直す。こうすると直しが積み上がり、同じ失敗が戻ってこなくなります。

この「作る→評価する→直す」の環に定時実行を組み合わせると、無人運転に届きます。僕のブログの毎朝の自動リサーチはスキルと定時実行の仕組みの組み合わせですし、繰り返し全体をどう設計するかはループ設計の記事に書いています。

関連記事Claude Codeに毎朝のリサーチを任せる仕組みの作り方毎朝9時にClaude Codeが追跡リストを巡回し、「今日の動き」を1枚に合成して通知する——2026年6月から無人で回り続けている僕の実運用をもとに、リサーチ自動化を組む5ステップと続けるための設計を解説します。→

スキル運用でつまずいた失敗と対策

僕が実際に踏んだ失敗を、対策とセットで置いておきます。いずれも前章までの基準や書き方に反映済みのものです。

失敗1: 外部サービスを呼ぶスキルに上限を入れず、残高を1朝で使い切った。 検索用の外部サービスを並列で何度も呼ぶ改良を入れた初日の朝、回数上限を設けていなかったために有料枠の残高が尽き、その日の自動処理が止まりました。以来、外部サービスを呼ぶスキルには回数上限と停止条件を先に書くことを必須にしています。

失敗2: 一度しかやらない作業までスキル化した。 作るのが楽しくなると、単発の作業までスキルにしてしまいます。二度と発動しないスキルは在庫として邪魔なだけでなく、誤発動の候補を増やします。選定3基準の「週1以上」に立ち返り、単発作業はその場の指示で済ませます。

失敗3: 学びを追記し続けてSKILL.mdが肥大化した。 失敗のたびに注意書きを足していくと、ファイルが膨らんで肝心の手順が埋もれます。僕は診断用スキルの点検項目に「文書の肥大化」を入れて機械的に検出し、本体は手順だけに保ち、長い参考資料は同じフォルダ内の別ファイルへ逃がしています。

3つとも根っこは同じで、「作るときの熱量のまま、運用を設計していない」ことが原因でした。スキルは作った瞬間ではなく、10回使った後の姿で評価するのがおすすめです。

よくある質問

まとめ。スキル化は業務標準化の実行形

• スキルはSKILL.md1枚の再利用部品。同じ指示を2回書いたらスキル化の候補

• 作り方より選定が先。週1以上・合否判定できる・やらない条件を言語化できる業務から

• 「使う条件」と「使わない条件」をセットで書けば、本数が増えても誤発動しない

• 作って終わりにせず、失敗をテストに固定しながら育てる。作成・評価・診断そのものもスキル化できる

同じ指示を毎回書き直しているなら、それは指示の上手さの問題ではなく、保存する仕組みが無いだけです。まずは1本、今週も繰り返したあの業務をSKILL.mdにしてみてください。

出典

本記事のうち、スキルの保存場所やファイル形式などの公式仕様と引用文は、執筆時点（2026年8月）で以下の公式ドキュメントを確認したものです。選定基準・境界設計・ライフサイクル運用・失敗談は、すべて僕自身の実運用に基づいています。

• Claude Code公式ドキュメント「スキルで Claude を拡張する」