Fable 5のスキル化術｜3サンプル法で作業を記憶させる
- 更新日: 2026年7月3日
- 読了目安: 約15分
- 作業時間: 約2〜4時間
Claude Codeのスキルとは、繰り返し作業の手順をSKILL.mdというファイルに書いてAIに記憶させる仕組みです。スキル化で一番大事なのは、1個作ってすぐスキル化しないこと。同じ作業のサンプルを3個以上全力で作り、共通パターンが見えてから、同じセッション中にSKILL.mdへ落とします。
この記事の4 STEPを進めれば、次回から一言の依頼で同じ品質の成果物を再現できる状態まで作れます。
この記事で分かること
「Claude Code スキル」「SKILL.md 作り方」で検索している人が知りたいことは、たぶんファイルの置き場所だけではありません。
スキルって結局何なのか。
なぜ作ったスキルが思った通りに動かないのか。
どのタイミングでスキル化すればいいのか。
descriptionには何を書けばいいのか。
そもそも自分の作業はスキル化に向いているのか。
この記事の通りに「サンプル3個→改善→同じセッション中にスキル化→description磨き」の4 STEPを進めれば、次回から一言で同じ品質の成果物を再現できる状態まで作れます。作業時間の目安は2〜4時間です。
最初に送るプロンプト
この記事の内容を、読みながらそのまま実践できるプロンプトです。
自分がスキル化したい作業に書き換えて、Claude Code（モデルはFable 5推奨）に貼ってください。[]の中だけ自分の内容に変えればOKです。
あなたと一緒に、繰り返し作業をスキル化したいです。
今日のセッションのゴールは、[LP制作 / SNS投稿設計 / レポート作成など、スキル化したい作業]のスキルを作ることです。
進め方:
1. まず同じ種類の成果物を、雰囲気の違う3パターンで全力で作ってください。
パターン1: [例: テック系スタートアップ向け]
パターン2: [例: 教育サービス向け]
パターン3: [例: シンプルな個人サービス向け]
2. 3個できたら、私が「もっと良くして」と改善指示を出すので、満足いくまで付き合ってください。
3. 私が「スキル化して」と言ったら、この3個の作業の共通パターンを抽出して、
./skills/[スキル名]/SKILL.md を作ってください。
SKILL.mdには、name/descriptionのfrontmatter、概要、必要な環境変数、
実行手順、プロンプトテンプレート、出力形式、カスタマイズできる点、
よくあるエラーと対処を必ず含めてください。
前提:
- 作業フォルダ: [プロジェクトのフォルダ]
- 秘密のキー（APIキーなど）が必要な場合は.envで管理し、SKILL.md本文には絶対に書かない
- 各サンプルは途中で手を抜かず、そのまま納品できる品質を目指す
エラーが出た場合は、エラー全文を私に見せて、原因の仮説と対処案を先に説明してください。このプロンプトの意味は、この後の本文で1つずつ分解して説明します。
スキルとは？Claude Codeに手順を記憶させる仕組み
スキルとは、Claude Codeに「この作業はこの手順でやる」と記憶させるためのSKILL.mdファイルのことです。
Claude Codeは賢いですが、セッションが終わると作業の記憶は消えます。今日3時間かけて「いい感じのLPの作り方」をすり合わせても、明日また最初から説明し直しになる。ここが繰り返し作業の一番のムダです。
スキルはこの問題を解決します。作業の手順、使うテンプレート、出力の形式、注意点をSKILL.mdという1つのファイルに書いておくと、Claude Codeは次回から「LP作って」の一言でそのファイルを読み込み、前回すり合わせた品質で作業を再現します。
例えるなら、優秀な新人に渡す業務マニュアルです。口頭で毎回教えるのではなく、マニュアルを1回ちゃんと作れば、誰に（どのセッションに）頼んでも同じ品質が出る。それをAI向けにやるのがスキル化です。
SKILL.mdの中身はただのMarkdownファイルなので、特別なツールは不要です。ファイルの先頭にfrontmatter（nameとdescriptionを書く数行の設定部分）を置き、その下に手順を書くだけです。
スキル化の成否は、SKILL.mdの書き方ではなく「いつ書くか」でほぼ決まります。
なぜ「1個作ってすぐスキル化」は失敗するのか
スキルを知った人が最初にやりがちな失敗が、「1個うまくいったから、すぐスキル化しよう」です。
気持ちは分かります。私も最初はそうでした。でも、1個のサンプルから作ったスキルは、高確率で「あの1個専用のメモ」になります。
理由はシンプルで、1個だけでは「たまたまうまくいった部分」と「毎回必要な本質部分」の区別がつかないからです。
たとえばLPを1個作ってスキル化すると、その案件特有の色使いやセクション構成までスキルに焼き付いてしまい、次の案件で使うと微妙にズレたものが出てきます。
同じスキルにしたい作業で、サンプルを3個以上、全力で作ってください。3個作ると共通パターンが見えます。共通パターンが見えてからスキル化すると、精度の高いスキルになります。
サンプル数によって見えるものは、はっきり変わります。
| サンプル数 | 見えてくるもの | スキル化した時の結果 |
|---|---|---|
| 1個 | その1個の作り方だけ | その案件専用のメモ。他で使うとズレる |
| 2個 | 違いは分かるが、どちらが本質か判断できない | 迷いが残ったままの中途半端なスキル |
| 3個以上 | 毎回共通する手順と、案件ごとに変える部分が分離できる | 「固定部分」と「カスタマイズ部分」が明確な、再現性の高いスキル |
3個は魔法の数字ではなく、「共通点と差分を比較できる最小の数」です。余裕があれば4〜5個作ってからスキル化すると、さらに精度が上がります。
スキル化ワークフローの全体像（STEP1〜4）
流れは4 STEPです。全部で2〜4時間を見ておけば十分です。
ポイントは、STEP1からSTEP3までを1つのセッションの中で終わらせることです。理由は後で表にして説明しますが、セッションをまたぐとスキルの質が確実に落ちます。
異なるパターンでサンプルを3個全力で作る
60〜120分最初のSTEPは、スキル化したい作業のサンプルを3個作ることです。ここで重要なルールが2つあります。
1つ目、3個は「違うパターン」で作ること。同じようなものを3個作っても、共通パターンは見えません。わざと条件を変えます。
2つ目、3個とも全力で作ること。「どうせサンプルだから」と雑に作ると、雑な手順がスキルに焼き付きます。1個1個を、そのまま納品できるレベルまで仕上げてください。
例1: LP制作をスキル化する場合
LPなら、業種とテイストを変えて3パターン作ります。実際にhashshの勉強会で使っている指示の型がこれです。
パターン1、テック系。
AIツールを提供するスタートアップのLPを作ってください。
サービス名: TechFlow AI
キャッチコピー: 開発チームの生産性を3倍にするAIアシスタント
説明: コードレビュー、テスト生成、ドキュメント作成を自動化するツール
CTA: 無料トライアルを始める
条件:
- index.html 1ファイルで完結させる
- レスポンシブ対応
- ファーストビュー、特徴3つ、CTAの3セクション構成
- ダークトーンで先進的な雰囲気パターン2、教育系。
子ども向けオンライン英会話のLPを作ってください。
サービス名: KidsTalk
キャッチコピー: 遊ぶように話せる、はじめての英会話
説明: 3〜10歳向け。ゲーム感覚のレッスンで英語に慣れるオンライン教室
CTA: 無料体験レッスンを予約する
条件:
- index.html 1ファイルで完結させる
- レスポンシブ対応
- ファーストビュー、特徴3つ、CTAの3セクション構成
- 明るくて親しみやすい、保護者が安心する雰囲気パターン3、シンプル系。
個人で活動するカメラマンのLPを作ってください。
サービス名: Yuta Photo Works
キャッチコピー: その日の空気ごと、残す。
説明: 家族写真・プロフィール撮影・イベント撮影を1件から受付
CTA: 撮影の相談をする
条件:
- index.html 1ファイルで完結させる
- レスポンシブ対応
- ファーストビュー、特徴3つ、CTAの3セクション構成
- 余白多めのミニマルな雰囲気3個並べると、気づくことがあります。「1ファイル完結」「レスポンシブ」「FV＋特徴＋CTAの3セクション」は毎回同じ。変わるのは「サービス情報」と「雰囲気の指定」だけ。この「毎回同じ部分」と「毎回変わる部分」の分離こそが、スキルの設計図です。
例2: バズリサーチをスキル化する場合
SNSリサーチのような調査系作業でも、やり方は同じです。テーマを変えて3回リサーチを回します。
SocialData.toolsのAPIを使って、Xのバズ投稿をリサーチしてください。
テーマ: AIツール
条件: 直近30日、いいね1,000以上、日本語、リプライと広告は除外
検索クエリ例: AI ツール min_faves:1000 lang:ja -filter:replies
出力:
- 投稿本文、いいね数、リポスト数、投稿日時、ユーザー名をMarkdownの表に
- いいね数の多い順に並べる
- 最後に「バズった理由の傾向」を3行でまとめる
APIキーは.envのSOCIALDATA_API_KEYを使ってください。これを「副業」「動画編集」などテーマを変えて3回実行すると、クエリの組み立て方、表の形式、傾向分析の粒度という共通パターンが固まります。これがそのままスキルの本体になります。
例3: note記事執筆をスキル化する場合（コードを書かない人向け）
コードを1行も書かないスキルも、まったく同じ手順で作れます。note記事の執筆なら、テーマを変えて「構成→下書き→リライト」の流れを3記事分回します。
noteに投稿する記事を作ってください。
テーマ: [例: AIツールを仕事に取り入れた体験談]
読者: [例: AIに興味はあるが、まだ触っていない会社員]
ゴール: [例: 最後まで読んで、フォローと「スキ」を押したくなる]
進め方:
1. 導入文の案を3パターン出す（私が1つ選びます）
2. 選んだ導入に合わせて、見出し構成を作る
3. 構成に沿って下書きを書く（2,000〜3,000字）
4. 下書きを自分でレビューして、リズムと言い回しをリライトする
条件:
- 1文は短く、スマホで読みやすい改行にする
- 誇張した断定（「必ず」「100%」など）は使わない
- 最後に、次の記事につながる一文を入れるこれを「体験談」「ノウハウ」「考察」とテーマを変えて3記事分回すと、「導入は3案から選ぶ」「下書きとリライトは分ける」「文字数と改行のルール」という共通パターンが見えてきます。SKILL.mdに書くのは日本語の手順だけで、コードは出てきません。執筆・要約・調査のような文章仕事のスキルも、この記事の手順そのままで作れます。
「もっと良くして」を満足いくまで粘る
30〜60分3個作って終わりではありません。STEP2では、出てきたサンプルを自分が本当に満足するレベルまで引き上げます。
なぜこれが必要かというと、スキルは「その時点の品質」を固定する仕組みだからです。70点の状態でスキル化すると、以後ずっと70点が量産されます。ここで粘って90点にしてからスキル化すれば、以後ずっと90点が出ます。
改善指示は、この4パターンを使い分けます。
全部やり直してほしい時。
方向性から変えたいです。3つとも、今の構成にとらわれずゼロから作り直してください。
特に[変えたい点]を重視してください。特定の部分だけ直したい時。
パターン2の[ファーストビュー]だけ直してください。
他の部分は今のままでOKです。[こうしたい]という意図です。比較対象を増やしたい時。
今の3つとは別の切り口で、あと2パターン追加で作ってください。
[例: もっと高級感のある方向と、もっとカジュアルな方向]全体の品質を一段上げたい時。
3つとも方向性はこのままで、全体の完成度を一段階上げてください。
細部の詰めの甘さ、余白、文言のキレを自分でレビューしてから直してください。私がブログ記事の型を固めた時は、この往復を7〜8回やりました。時間にして1時間弱。ここで妥協しなかったことが、後のスキルの品質にそのまま効いています。
- 条件を変えたサンプルが3個以上できている
- 3個とも「これなら納品できる」と思えるレベルまで仕上げた
- どのパターンにも共通して守られているルールを、口で説明できる
1つでも当てはまらない場合は、STEP2の改善指示に戻ってください。セッションはまだ閉じないでください。
同じセッション中にSKILL.mdへ落とす
15〜30分ここが本番です。サンプル作りに使った同じセッションの中で、そのままスキル化を指示します。
新しいセッションを開いてはいけません。理由は次の章で説明します。
スキル化のプロンプトはこれです。そのまま貼ってください。
今日このセッションで作った3個以上のサンプルの作業内容から、
共通パターンを抽出してスキル化してください。
作成先: ./skills/[スキル名]/SKILL.md
SKILL.mdに含める内容:
1. frontmatter（name と description）
2. 概要（このスキルは何をするものか）
3. 必要な環境変数（.envで管理。値は書かず変数名と取得方法だけ）
4. 実行手順（ステップごとに番号付きで）
5. プロンプトテンプレート（今日一番うまくいった指示の型。可変部分は[]で示す）
6. 出力形式（ファイル構成、命名、フォーマット）
7. カスタマイズできる点（案件ごとに変えていい場所の一覧）
8. よくあるエラーと対処（今日実際に起きたつまずきを含める）
注意:
- 今日のサンプル固有の情報（サービス名など）はテンプレートの例に格下げする
- 毎回共通だった指示は「固定ルール」として明記する
- 秘密のキーの値は絶対に書かないSKILL.mdの構成を理解する
生成されたSKILL.mdは、必ず自分の目で確認します。骨格はこうなっているはずです。
---
name: lp-builder
description: LP（ランディングページ）を1ファイルのHTMLで制作するスキル。
サービス名・キャッチコピー・説明・CTAを指定すると、レスポンシブ対応の
FV+特徴+CTA構成で生成する。LP制作、ランディングページ作成、
ペライチページの依頼で使う。
---
# lp-builder
## 概要
（何をするスキルか2〜3行）
## 環境変数
（必要なら。値は書かない）
## 実行手順
1. ヒアリング項目を確認する
2. ...
## プロンプトテンプレート
（[]で可変部分を示した指示の型）
## 出力形式
（index.html 1ファイル、など）
## カスタマイズできる点
（雰囲気、色、セクション追加など）
## よくあるエラーと対処
（実際に起きたことベース）frontmatterのdescriptionは、Claude Codeが「今の依頼にこのスキルを使うべきか」を判断する材料です。ここの書き方はSTEP4で徹底的に磨くので、この時点では仮でOKです。
確認する時の観点は3つだけです。
- 今日の3サンプルに共通していたルールが「固定ルール」として書かれているか
- 案件ごとに変えた部分が「カスタマイズできる点」に分離されているか
- 今日実際に起きたエラーやつまずきが「エラー対処」に残っているか
この3つが揃っていれば、そのスキルは次回もほぼ同じ品質を再現します。
なぜ「同じセッション中」なのか
STEP3を「また明日やろう」とすると、スキルの質は目に見えて落ちます。
セッションの中には、その日の作業の全記憶が残っています。どの指示がうまくいって、どの指示が失敗して、何回目の修正で化けたか。スキル化とは、この記憶からパターンを抽出する作業です。記憶が消えれば、抽出できるものも消えます。
| スキル化のタイミング | 残っている情報 | スキルの質 |
|---|---|---|
| サンプル作成直後（同じセッション中） | 全作業の経緯、失敗と修正の履歴、うまくいった指示の全文 | 何をやったか完全に把握した状態で抽出できる。最高品質 |
| 翌日（新しいセッション） | 成果物ファイルだけ。経緯の記憶はゼロ | 成果物から逆算するしかなく、途中の判断や失敗対処が抜け漏れる |
| 1週間後 | 成果物すら「なぜこうしたか」不明 | 人間側の記憶も消えていて、再現はほぼ無理 |
人間の勉強と同じです。授業の直後にノートをまとめるのと、1週間後に思い出しながらまとめるのでは、質がまったく違います。
サンプルを作った勢いのまま、同じセッションで「スキル化して」まで言い切る。
STEP4: descriptionを磨いて発動精度を上げる
SKILL.mdができても、まだ終わりではありません。最後のSTEPは、frontmatterのdescriptionを磨くことです。
descriptionは、スキルの「呼び出しボタンの名前」です。Claude Codeはユーザーの依頼文とdescriptionを照らし合わせて、スキルを使うかどうかを決めます。ここが曖昧だと、せっかく作ったスキルが発動しません。
磨き方は、テストと書き直しの往復です。
まず、新しいセッションを開いて、実際にありそうな依頼文を3件投げます。
（テスト1）新しいサービスのLPを作ってほしい
（テスト2）ペライチの紹介ページ作れる？
（テスト3）ランディングページの制作をお願いしたい3件ともスキルが発動すれば合格です。発動しなかった依頼文があれば、その言葉をdescriptionに足して書き直します。
書き直しのビフォーアフターはこんなイメージです。
書き直し前。
description: LPを作るスキルこれだと「ペライチ」「紹介ページ」「ランディングページ制作」という言い方の依頼で発動しないことがあります。
書き直し後。
description: LP（ランディングページ）を1ファイルのHTMLで制作するスキル。
サービス名・キャッチコピー・説明・CTAを指定すると、レスポンシブ対応の
FV+特徴+CTA構成で生成する。LP制作、ランディングページ作成、ペライチ、
紹介ページ、サービスページの依頼が来たら使う。コツは3つです。
- 「何をするか」だけでなく「どんな依頼が来たら使うか」を書く
- ユーザーが実際に使いそうな言い回しを複数入れる（LP、ランディングページ、ペライチ）
- 具体的な入力と出力を書く（何を渡すと何ができるか）
書き直したら、もう一度テスト3件。全部発動するまで繰り返します。私の経験では、2〜3回の書き直しでほぼ安定します。
- SKILL.mdが./skills/スキル名/に作られている
- 言い回しを変えた依頼文3件すべてでスキルが発動した
- descriptionに「何をするか」「どんな依頼で使うか」が入っている
1つでも当てはまらない場合は、この下のエラー対処へ進んでください。
hashshの実例｜このブログ自体がスキルで動いている
机上の話ではない証拠として、hashshの実運用を紹介します。
今読んでいるこのブログは、hashsh-howto-blogというスキルで運用されています。記事の構成、文字数の基準、見出しの作り方、エラー対処の書き方、FAQの件数、HTMLの共通クラス、用語集の付け方まで、全部このSKILL.mdに書かれています。だから「ブログ記事を書いて」の一言で、どのセッションでも同じ型の記事が出てきます。
このスキルも、最初の数記事を全力で作り、型が固まってからスキル化したものです。まさにこの記事の3サンプル法そのままです。
さらに、記事の品質チェックもスキルと自動チェック（lint）の二段構えにしています。文字数、見出しの数、FAQの件数、禁止表現、構造化データの有無といった機械的に確認できる項目はチェックスクリプトが検査し、エラーが1件でもあれば公開できないルールです。この記事自体も、公開前に同じチェックを通っています。
スキルに手順を記憶させ、チェックを自動化する。この2つが揃うと、記事作成は「毎回ゼロから頑張る仕事」から「型に沿って中身に集中する仕事」に変わります。
スキル化に向く作業・向かない作業
なんでもスキル化すればいいわけではありません。仕分けの基準はこうです。
◯ 月に2回以上繰り返す作業（LP制作、記事作成、レポート作成）
◯ 手順が毎回ほぼ同じで、入力だけが変わる作業
◯ 「品質の基準」を言葉にできる作業
◯ 複数のツールやコマンドをまたぐ、覚えるのが面倒な作業
◯ 人に引き継ぐならマニュアルを書くレベルの作業
× 一度きりの作業（スキル化する時間がムダ）
× 毎回やり方がまったく違う、探索的な作業
× 手順より判断が9割の作業（経営判断、デザインの方向性決めなど）
× まだ2〜3回しかやっておらず、型が固まっていない作業
迷ったら「この作業のマニュアルを新人に渡すか？」で考えてください。渡すならスキル化、渡さないならその都度依頼で十分です。
「型が固まっていない作業」は、スキル化を諦めるのではなく、この記事のSTEP1に戻ってサンプルを作るところから始めれば大丈夫です。
Fable 5がスキル化に向いている理由
このワークフローは、Claude Codeで使えるモデルならどれでも回せます。そのうえで、私がスキル化作業にClaude Fable 5を推す理由が2つあります。
1つ目は、サンプル3個を全力で作りきる体力です。3サンプル法の弱点は、サンプル作りに時間と集中力が要ることです。Fable 5はタスクが長く複雑なほど他モデルとの差が開くのが特徴で、長いセッションでも品質が垂れにくい。「3個目だから雑になる」が起きにくいので、スキルの元になるサンプルの質が揃います。
2つ目は、パターン抽出の精度です。スキル化の肝は、セッション全体を振り返って「共通していたもの」と「案件固有だったもの」を正しく分離することです。Fable 5は長い文脈の把握に強く、数時間分の作業履歴から固定ルールとカスタマイズ点を切り分ける精度が高い。ここがスキルの再現性に直結します。
使い方は簡単で、Claude Codeを2.1.170以降に更新して、/model でFable 5に切り替えるだけです。
Fable 5のAPI料金は入力100万トークンあたり10ドル、出力50ドルで、Opus 4.8の2倍、Sonnet 5の5倍です。
サブスクプラン（Pro/Max/Team）では、2026年7月1日〜7月7日は週間利用枠の50%までFable 5を使える期間限定プロモーション中で、7月8日以降はUsage Credits（従量クレジット）での利用になります。料金や提供条件は変わる可能性があるので、最新は公式料金ページで確認してください。
だからこそ、Fable 5は「毎回の作業」より「スキル化のような一度で長く効く作業」に使うのが割に合います。スキル化は1回頑張れば以後ずっと再現される投資型の作業なので、一番強いモデルを当てる価値があります。日常の繰り返し実行はSonnet 5やOpus 4.8で回す、という使い分けが現実的です。
スキルがうまく動かない時のエラー対処
スキル化でつまずくポイントは、だいたい次の4つに集約されます。どれも直せます。原因を切り分ける時、秘密のキーやパスワードはAIに貼らないでください。
スキルが発動しない
症状: スキルを作ったのに、依頼してもClaude Codeがスキルを使わず、ゼロから作業を始めてしまう。
原因: descriptionが曖昧で依頼文とマッチしていない。依頼で使った言葉（例:「ペライチ」）がdescriptionに入っていない。SKILL.mdの置き場所が、Claude Codeがスキルを読む場所とズレている。
確認すること: 依頼した時の自分の言い回しとdescriptionの文言を見比べる。SKILL.mdがスキル用フォルダ（例: .claude/skills/スキル名/SKILL.md）に置かれているか。frontmatterのnameとdescriptionが正しい形式か。
対処: 発動しなかった依頼文の言い回しをそのままdescriptionに追記する。「どんな依頼が来たら使うか」の一文を足す。新しいセッションで、言い回しを変えた依頼を3件投げて発動テストする。
手順どおりに再現されない
症状: スキルは発動するが、出てくる成果物の品質や形式が毎回バラつく。
原因: サンプル1個だけでスキル化していて固定ルールが曖昧なまま。SKILL.mdの手順が「いい感じに作る」レベルで抽象的。出力形式の指定（ファイル名、構成、フォーマット）が書かれていない。
確認すること: SKILL.mdに「固定ルール」と「カスタマイズできる点」が分けて書かれているか。出力形式のセクションに具体的なファイル構成があるか。
対処: この記事のSTEP1に戻り、あと2個サンプルを全力で作る。同じセッションで「既存のSKILL.mdを、今日の作業も踏まえて書き直して」と指示する。バラついた部分を「固定ルール」として明文化してもらう。
スキルの内容が古くなった
症状: 以前は動いていたスキルが、ツールの仕様変更やコマンドの変更でエラーを出すようになった。
原因: スキルに書いたコマンドや手順がツール側のアップデートで変わった。料金プランやAPIの仕様など、鮮度の短い情報をスキルに直書きしていた。
確認すること: エラーが出ている箇所のコマンドを、公式ドキュメントの最新の案内と見比べる。SKILL.md内に日付やバージョン前提の記述が残っていないか。
対処: 動かなくなった箇所を特定して、その場で作業を最後まで通す。通った直後の同じセッションで「今日の変更をSKILL.mdに反映して」と更新を指示する。スキルは作って終わりにせず、「実行してつまずいたら、その日のうちにスキルも直す」を運用ルールにする。
スキルが肥大化して逆に精度が落ちた
症状: 改善のたびにSKILL.mdへ追記し続けた結果、ファイルが長大になり、指示同士が矛盾したり、大事なルールが埋もれたりする。
原因: 削除せずに追記だけを繰り返している。1つのスキルに複数の仕事を詰め込んでいる（LP制作と記事作成が同居など）。例外対応のメモが本則と同じ扱いで並んでいる。
確認すること: SKILL.mdを上から読んで矛盾する指示がないか。「このスキルは何をするスキルか」を一文で言えるか。
対処: 「このSKILL.mdを、矛盾と重複を整理してスリムにして。消していい記述は理由付きで提案して」と依頼する。仕事が2つ以上混ざっていたらスキルを分割する。整理後、STEP4の発動テスト3件をやり直して精度を確認する。
AIに聞くためのプロンプト集
スキル化の途中で迷った時は、状況を整理してAIに渡すのが一番早いです。
秘密のキー、パスワード、顧客情報、決済情報は貼らないでください。何をスキル化すべきか迷った時
Claude Codeのスキル化を検討しています。
私がよくやる作業:
それぞれの頻度（週何回、月何回）:
毎回かかっている時間:
この中でスキル化の効果が大きい順に並べて、理由も教えてください。
月2回未満の作業や、毎回やり方が変わる作業は除外してください。サンプル3個のパターンを決めたい時
[LP制作]の作業をスキル化するために、まずサンプルを3個作ります。
想定している用途:
よくある依頼のバリエーション:
共通パターンを抽出しやすいように、条件をどう変えた3パターンで
作るべきか提案してください。スキル化の指示を出す時
今日このセッションで作ったサンプルの作業内容から、共通パターンを
抽出してスキル化してください。
作成先: ./skills/[スキル名]/SKILL.md
含める内容: frontmatter（name/description）、概要、環境変数、実行手順、
プロンプトテンプレート、出力形式、カスタマイズできる点、エラー対処
サンプル固有の情報は例に格下げし、秘密のキーの値は書かないでください。descriptionを磨きたい時
このスキルのdescriptionを、発動精度が上がるように書き直してください。
今のdescription:
発動してほしい依頼文の例（3件以上）:
発動しなかった依頼文:
「何をするか」「何を渡すと何ができるか」「どんな依頼が来たら使うか」の
3点が入った形に書き直し、書き直し前後を比較して見せてください。スキルが発動しなかった時
作ったスキルが発動しません。
スキルのファイルの場所:
frontmatterの内容:
発動しなかった時の依頼文:
その時Claude Codeがした動き:
原因の候補を可能性が高い順に挙げて、確認する手順を教えてください。古いスキルを整理したい時
使い続けてきたスキルが長くなってきたので整理したいです。
SKILL.mdの内容: （貼り付け）
最近うまくいかなくなった点:
矛盾している指示、重複している指示、古くなっている可能性のある記述を
洗い出して、スリム化した版を提案してください。消す場合は理由も添えてください。スキル化の実務活用事例12選
スキル化はエンジニアだけのものではありません。AI駆動倶楽部の考え方は「AIで作る / AIでバズる / AIで運営する」。運営はhashshnet（はしもとかずや）です。
実務でスキル化が効く場面を12個挙げます。
どれも共通するのは、「3回以上やった作業を、3個のサンプルから型に固めた」という順番です。最初からスキルを書いた事例は1つもありません。
よくある質問
スキルとは何ですか？
スキルとは、Claude Codeに作業手順を記憶させるためのSKILL.mdファイルのことです。手順、テンプレート、出力形式、注意点を1つのMarkdownファイルにまとめておくと、次回から一言の依頼で同じ品質の作業を再現できます。中身はただのテキストファイルなので、特別なツールは必要ありません。
なぜサンプルを3個も作る必要があるのですか？
サンプルが1個だけだと、「たまたまうまくいった部分」と「毎回必要な本質部分」の区別がつかないからです。条件を変えて3個作ると、毎回共通する固定ルールと、案件ごとに変えるカスタマイズ部分が分離でき、再現性の高いスキルになります。3個は共通点と差分を比較できる最小の数です。
スキル化はFable 5でないとできませんか？
スキル化はFable 5専用の機能ではなく、Claude Codeで使えるモデルならどれでも実践できます。ただしFable 5は、サンプル3個を高品質に作りきる持久力と、セッション全体から共通パターンを抽出する精度に優れているため、スキル化のような「一度で長く効く作業」には特に向いています。日常の実行はSonnet 5などに任せる使い分けが現実的です。
スキル化にはどれくらい時間がかかりますか？
サンプル3個の作成に60〜120分、改善に30〜60分、SKILL.md化に15〜30分、descriptionの調整に15〜30分で、合計2〜4時間が目安です。1回のセッションで完結させるのが理想です。かかった時間は投資で、次回以降は同じ作業が一言で再現されるため、月2回以上やる作業ならすぐ回収できます。
作ったスキルが発動しないのはなぜですか？
一番多い原因は、frontmatterのdescriptionが曖昧なことです。Claude Codeは依頼文とdescriptionを照らし合わせてスキルを使うか判断するため、「何をするか」「どんな依頼が来たら使うか」「実際に使われそうな言い回し」をdescriptionに入れる必要があります。発動しなかった依頼文の言葉をdescriptionに追記し、テスト3件で確認してください。
スキルは一度作れば永久に使えますか？
スキルは一度作れば終わりではなく、更新運用が必要です。ツールのコマンドや料金プランなど鮮度の短い情報は数週間で古くなることがあります。スキル実行中につまずいたら、その日のうちに同じセッションでSKILL.mdの該当箇所を直すのが一番確実です。追記だけを繰り返すと肥大化するので、定期的な整理も効きます。
プログラミングができなくてもスキル化できますか？
できます。SKILL.mdはコードではなく、日本語で手順を書くMarkdownファイルです。しかも、この記事の方法ならSKILL.md自体もClaude Codeに書かせるので、自分で書く必要すらありません。人間の仕事は、サンプル3個の出来に妥協しないことと、出てきたスキルの内容を読んで確認することです。
まとめ
スキル化の本質は、SKILL.mdの書き方ではなく「順番」です。
- 月2回以上繰り返している作業を1つ選ぶ
- Claude Codeを2.1.170以降に更新し、/model でFable 5に切り替える
- 条件を変えたサンプルを3個、全力で作る
- 満足いくまで「もっと良くして」を繰り返す
- 同じセッションのまま「スキル化して」と指示し、SKILL.mdを作らせる
- 新しいセッションで依頼文3件を投げて、descriptionを磨く
1個作ってすぐスキル化したくなる気持ちを、3個までこらえる。それだけで、あなたのスキルは「その場のメモ」から「毎回同じ品質を出す資産」に変わります。
詰まったら、そこで止まらなくて大丈夫です。
この記事を読んでも分からなかった人は、公式LINEまでお問い合わせください。30分無料で面談したり、一緒に画面を見ながら作業したりすることも可能です。
更新履歴
- 2026-07-02: 記事公開。
- 2026-07-03: 執筆・調査・生成系の事例を追加。note記事執筆スキルの例（例3）を追加。