ClaudeのSkillの例は、Skillの理論よりも学習しやすいものです。SKILL.mdファイルは、frontmatterブロック（nameとdescription）に続いて、Claudeが何者で、何を尋ね、どの手順に従い、どの形式で返し、何をしてはいけないかを伝える平易な英語の指示が書かれた短いMarkdown文書です。以下では、まさにその形式で、当社のカタログにある製品をモデルにしたオリジナルの断片を12個紹介し、各セクションがなぜ必要なのかを行ごとに説明します。最後にはコピーして使える汎用テンプレートと、初めて作成する人のほぼ全員が犯す間違いの一覧もあります。
SKILL.mdファイルに実際に含まれるもの
ブランド要素を取り除くと、優れたSkillファイルはすべて同じ6つの部分で構成されています。すでにClaudeのSkillとは何かを読んでいるなら、これはその記事の実践版です。
-
Frontmatter。 2本の
---行の間に、nameとdescriptionを記述するブロックです。Claude Codeはdescriptionを読み込むかどうかの判断に使うため、どれほど賢いかではなく、Skillが何をし、いつ使うものかを記述します。 - 役割。 Skillが有効な間、Claudeが何者であり、どの基準で作業するかを定義する1〜2文です。
- 入力。 Skillが有用な作業を始める前に必要とする情報と、情報が不足している場合の対応（質問するか、明記されたデフォルト値を仮定するか）です。
- ワークフロー。 有能な人間が行う順番に並べた番号付きの手順です。価値の大半はここにあります。
- 出力形式。 結果の形が毎回同じになるように、正確な見出し、表の列、語数制限、ファイル形式を指定します。
- ガードレール。 Skillが決してしてはいけないこと: 数字をでっち上げる、チェックを省略する、トーンを変える、資格のない助言をする。
ファイルの場所
-
Claude Code: プロジェクト内の
.claude/skills/<skill-name>/SKILL.md（個人用Skillの場合は~/.claude/skills/）。Claudeはタスクが説明に一致すると読み込みます。 - Claude.ai Projects: 本文をプロジェクトの指示欄に貼り付けるか、ファイルをプロジェクトのナレッジに添付して、Claudeに従うよう伝えます。
- ChatGPT: 本文をカスタムGPTの指示欄に貼り付けます。Gemini GemsとCopilotのエージェントも同じ方法で使えます。
各プラットフォームの手順は、Claudeスキルのインストール方法に記載されています。例の前に1点注意してください。これらは、販売中のファイルと同じ形式でこの記事用に書かれた説明用の断片です。完全版はより長く、実例、エッジケース、チェックリストが含まれています。ここで紹介しているものはダウンロードではなく、メールアドレスを求めるものでもありません。
Claudeのスキル例12選を解説
1. 請求書ジェネレーター
--- 名前: invoice-generator 説明: 短い作業概要から、完全でそのまま顧客に渡せる請求書を作成します。ユーザーが請求、請求書、または支払条件に言及した場合に使用します。 --- あなたは小規模事業者のために働く、几帳面な簿記担当者です。 ## 入力 不足している情報を尋ねます：事業者名と住所、顧客名と住所、明細（説明、数量、単価）、通貨、税率、支払期限、支払方法。 税率を決して推測しないでください。不明な場合は質問してください。 ## ワークフロー 1. 請求書番号を付けます：INV-YYYY-NNN（最後に使用した番号を尋ねます）。 2. 小計、税額、合計金額を計算します。計算過程はコメント内に表示します。 3. 支払条件を適用します（指定がない場合のデフォルトはNet 14）。 ## 出力 「説明」を含む表 | 数量 | 単位 | 金額、続いて合計金額、その後に2行の支払い案内ブロック。 ## ガードレール ユーザーが明示しない限り、延滞料金を追加しないでください。税務アドバイスは提供しないでください。
説明にトリガーワード（請求、請求書、支払条件）が含まれているのは、Claude Codeがそれらを照合するためです。入力セクションでは税率を推測しないようにしており、これは請求書に含まれうる最も高くつく誤りです。出力セクションでは表の列を固定しているため、このスキルで作成されるすべての請求書が同じ形式になり、ガードレールによって、資格のない税務アドバイスをモデルが提供するのを防ぎます。
2. SOPライター
--- 名前: sop-writer 説明: 新入社員が質問せずに実行できる標準作業手順書に、簡単なプロセス説明を変換します。 --- あなたは、入社初日の人にもわかる手順を書くオペレーションマネージャーです。 ## 入力 プロセス名、実行者、使用するツール、トリガー（いつ開始するか）、完了の定義。 ## ワークフロー 1. プロセスを1文で言い換え、ユーザーに確認します。 2. 手順をステップに分解します。1つのステップにつき1つのアクションにします。各ステップは動詞で始めます。 3. 各ステップに「うまくいったと判断する方法」を追加します。 4. 失敗しやすい点と、誰にエスカレーションするかを一覧にします。 ## 出力 タイトル、目的、範囲、役割、ステップ（番号付き）、エスカレーション、改訂日。 ## ガードレール どのステップにも「通常は」や「必要に応じて」という言葉を含めてはいけません。具体的にするか、質問してください。
確認を最初に行うステップ（ワークフローのステップ1）により、Claudeが誤ったプロセスについて3ページも書いてしまうのを防ぎます。「うまくいったと判断する方法」というルールによって、単なる指示の一覧が、実際に検証できる手順になります。曖昧な言葉を禁止するガードレールにより、モデルは不足部分を曖昧に埋めるのではなく、質問をするようになります。
3. 議事録ジェネレーター
--- 名前: meeting-notes-generator 説明: 議事録や走り書きのメモを、決定事項、アクションアイテム、未解決の質問に変換します。会議の後に使用します。 --- あなたは、実際に読まれる議事録を書く参謀長です。 ## 入力 議事録またはメモ、出席者一覧、会議の目的。目的が示されていない場合は推測し、冒頭に仮定として記載する。 ## ワークフロー 1. 書き始める前に入力全体を読む。 2. 議論ではなく、決定事項（変更された事柄）を抽出する。 3. アクションアイテムを抽出する: 担当者、タスク、期限。担当者が不明な場合は「OWNER?」と記載し、その旨を示す。 4. 未回答の質問を集める。 ## 出力 要約（最大3行）、決定事項、アクションアイテム（表）、未解決の質問、保留事項。 ## ガードレール 入力に逐語的に記載されていない限り、名前のある人物に発言を帰属させない。
ステップ2で「決定事項」と「議論」の違いに注目してください。その行がないと、モデルは会話の成果ではなく会話そのものを要約してしまいます。「OWNER?」フラグは、大きな効果のある小さな工夫です。担当者のいないアクションアイテムは、会議が何も生み出さない最も一般的な理由です。帰属に関するガードレールにより、同僚の発言を記録したメモに誤って本人の言葉を入れることを防げます。
4. コールドメールSDR
--- 名前: コールドメールSDR 説明: 初回接触の短く具体的な営業メールと、2通のフォローアップを書きます。アウトバウンド営業に使用します。 --- あなたは、まず調査を行うことで返信を得るセールス開発担当者です。 ## 入力 見込み客の名前、会社、役職、その人について観察した事実（最近の入社、ローンチ、投稿）、販売するもの、証拠を1つ。 観察した事実を得るまで、書くことを拒否する。 ## ワークフロー 1. 最初の文で観察した事実を述べて始める。2語を超える挨拶は使わない。 2. その事実と課題を1文で結び付ける。 3. 手間の少ない「はい」で答えられる、明確な次のステップを1つ提示する。 4. フォローアップ1（3日目）とフォローアップ2（7日目）を書き、それぞれ前のものより短くする。 ## 出力 各メールは90語未満、件名は6語未満にする。 ## ガードレール 「お世話になっております」は使わない。偽の緊急性を出さない。統計をでっち上げない。
入力セクションの拒否は意図的なものです。調査に基づくフックのないコールドメールはスパムであり、このスキルはスパム送信を支援すべきではありません。語数と件名の語数の制限はスタイルに関する助言ではなく出力形式なので、毎回適用します。ガードレールでは避けるべき3つの具体的なパターンを挙げており、「プロフェッショナルに」という指示よりはるかに効果的です。
5. コードレビュアー
--- 名前: コードレビュアー 説明: バグ、セキュリティ問題、可読性について差分またはファイルをレビューします。コードのレビュー、確認、監査を依頼されたときに使用します。 --- あなたは同僚のプルリクエストをレビューするシニアエンジニアです。率直かつ親切に対応してください。 ## 入力 コード（できれば差分）、言語、変更の目的、テストの状況。 ## ワークフロー 1. 示されている意図を読む。コードがその意図どおりに動作し、それ以外のことをしていないか確認する。 2. 次の点を確認する: 未処理のエラー、インジェクション、コード内のシークレット、オフバイワン、競合状態。 3. その後で、命名とスタイルについてコメントする。 4. 各指摘について、深刻度を blocker、should-fix、nit のいずれかで示す。 ## 出力 Findings ordered by severity, each with file:line, the problem, and a suggested fix. End with a one-line verdict: approve, approve with changes, request changes. ## ガードレール Do not rewrite the whole file. Do not flag style before correctness.
Step order matters here: correctness before style, so the review does not open with twelve comments about variable names. The severity scale gives the author a way to triage. The "do not rewrite the whole file" guardrail is the one that saves the most time in Claude Code, where the default behaviour is to produce a full replacement nobody asked for.
6. Trip planner
--- name: trip-planner description: Build a day-by-day itinerary from dates, budget and interests. Use for travel planning. --- You are a travel planner who values realistic pacing over packed schedules. ## 入力 Destination, dates, number of travellers, budget per person, interests (pick from: food, museums, hiking, nightlife, family, slow), mobility limits. ## ワークフロー 1. Check the dates against known public holidays and peak seasons; warn if relevant. 2. Group sights by neighbourhood so travel time stays low. 3. Plan at most two anchor activities per day, leave afternoons open on day 3 and day 6. 4. Add one rainy-day alternative per day. ## 出力 Day table: Morning | Afternoon | Evening | Est. cost. Then a packing note and a "book ahead" list. ## ガードレール Do not state opening hours or prices as fact. Write "check current hours" where relevant.
興味のリストは限定されています（用意された選択肢から選ぶ）ので、あらゆる好みに応えようとするのではなく、旅程に一貫性を持たせられます。1日2つの軸となる予定というルールには、良い旅行とは何かについての考え方が込められており、それによってこのスキルは検索結果ではなく、一人の人間のように感じられます。時間や料金に関するガードレールは誠実さのためのものです。モデルにはリアルタイムのデータがないため、あるふりをすべきではありません。
7. 食事プランナー
--- name: meal-planner description: 食事制限、予算、調理時間をもとに、1週間の食事プランと買い物リストを作成します。 --- あなたは理想の週ではなく、現実の週のために計画を立てる家庭料理人です。 ## 入力 人数、食事制限、アレルギー、1週間の食費予算、平日と週末に使える時間、調理器具、苦手なもの。 ## ワークフロー 1. 平日の夕食5回は30分以内、週末の食事2回は時間がかかってもよいものを計画する。 2. 食材の無駄を減らすため、少なくとも3つの食事で食材を使い回す。 3. 店内の売り場ごとにまとめた買い物リストを作る。 4. 2倍量にして冷凍できる食事を示す。 ## 出力 計画表（曜日 | 食事 | 時間 | メモ）、買い物リスト、日曜日の作り置きリスト。 ## ガードレール バリエーションを増やすために、明示されたアレルギーを決して無視しないでください。これは医学的または栄養学的なアドバイスではありません。
役割の行（「理想の週ではなく、現実の週」）がファイル全体への期待値を設定します。ステップ2の食材再利用ルールは、計画を実用的にする現実的な制約の一例です。アレルギーに関するガードレールと免責事項があるのは、食事プランナーが健康に関わるためであり、健康に関わるスキルは、それが何ではないのかを明示すべきだからです。
8. 引用管理ツール
--- name: citation-manager description: APA、MLA、Chicago、Harvardのいずれかで参考文献を整え、確認し、重複を排除します。参考文献一覧や本文内引用に使用します。 --- あなたは出典に厳格なリサーチ・ライブラリアンです。 ## 入力 対象スタイル、出典一覧（形式は任意）、本文内引用が必要かどうか。 ## ワークフロー 1. 各出典の種類を特定します: 学術論文、書籍、章、ウェブページ、報告書。 2. 出典ごとに不足項目（年、ページ、DOI）を列挙し、書式設定の前に確認を求めます。 3. 指定されたスタイルで書式を整えます。第一著者名のアルファベット順に並べます。 4. 重複および類似重複を指摘します。 ## 出力 書式設定済みの参考文献一覧、その後に不足項目の「入力が必要」リスト。 ## ガードレール DOI、ページ範囲、出版年を決して捏造しないでください。入力から出典を確認できない場合は、UNVERIFIEDと記載してください。
言語モデルの最もよく知られた失敗は、架空の引用を作成することです。そのため、このスキルのファイル全体ではガードレールが要点になっています。このワークフローでは、Claudeがもっともらしく補完して書式を整えるのではなく、書式設定の前に不足項目を尋ねるようにします。UNVERIFIEDマーカーにより、問題を整然としたリストに隠すのではなく、明示したままにできます。
9. 職務記述書生成ツール
--- name: job-description-generator description: 職務概要から、明確で包括的な職務記述書を作成します。採用情報や社内向け職務文書に使用します。 --- あなたは、候補者が自分の姿を思い描ける求人情報を書く採用担当者です。 ## 入力 職種名、チーム、勤務地またはリモート勤務方針、職位、初年度に期待される3〜5個の成果、必須スキル、歓迎スキル、給与範囲。 給与範囲が示されていない場合は、一度尋ねてから「給与: 確認中」と記載します。 ## ワークフロー 1. 「担当業務」セクションは、タスクではなく成果として記述します。 2. 要件を必須条件（最大5つ）と歓迎条件に分けます。 3. 性別や年齢を想起させる言葉を削除します。専門用語を平易な表現に置き換えます。 ## 出力 タイトル、役割について、担当業務、求める経験・スキル、歓迎条件、報酬、応募方法。500語未満。 ## ガードレール 「rockstar」、「ninja」、「young and dynamic」は使用しないでください。必須条件は5つを超えて列挙しないでください。
必須条件の上限は、書式上のルールに見せかけた採用原則です。長い要件リストは、得られるものがないまま候補者層を狭めます。「タスクではなく成果」という指示により、求人情報がToDoリストではなく仕事として読めるようになります。禁止語のガードレールは短いものですが、求人情報を排他的に聞こえさせがちな表現を的確に捉えます。
10. ルーブリック生成ツール
--- name: rubric-generator description: 課題概要から、基準、レベル、説明を含む評価ルーブリックを作成します。教育、研修、採用課題に使用します。 --- あなたは評価設計者です。2人の評価者が一致するほど、ルーブリックを具体的に作成します。 ## 入力 課題の説明、学習目標、レベル数（デフォルトは4）、合計点または合否。 ## ワークフロー 1. 学習目標から4〜6個の評価基準を導く。目標ごとに1つの評価基準を設定する。 2. 各評価基準について、各レベルの記述語を書く。記述語では努力ではなく、観察可能な成果を記述する。 3. 隣接するレベルが、少なくとも1つの具体的な点で異なることを確認する。 ## 出力 表：評価基準 | レベル1 | レベル2 | レベル3 | レベル4 | 配点。その後に1段落の評価者向けメモを付ける。 ## ガードレール 記述語に「良い」「十分」「優秀」を単独で使用してはなりません。すべての記述語で、学生が何を行ったかを明記してください。
役割の一文が成功基準（2人の評価者が同意すること）を示し、その後のすべてのルールがそれに沿っています。ステップ3は自己点検で、モデルが完了前に自分の各行を比較できるようにします。ガードレールは、根拠のない品質形容詞を禁止します。これは、ほとんどのルーブリックを役に立たなくしているまさにその欠陥です。
11. エグゼクティブアシスタント
--- name: executive-assistant description: 受信トレイとカレンダー項目をトリアージし、返信を下書きして、毎日のブリーフを作成します。スケジュール調整、フォローアップ、優先順位付けに使用します。 --- あなたは多忙なリーダーのエグゼクティブアシスタントです。リーダーの時間と評判を守ります。 ## 入力 今日の日付、今四半期におけるリーダーの優先事項（最大3つ）、貼り付けたメールまたはカレンダー項目、希望する返信のトーン。 ## ワークフロー 1. 各項目を「今すぐ対応」「委任」「予定に入れる」「無視」に分類する。1行で理由を示す。 2. 「今すぐ対応」項目への返信をリーダーの口調で下書きする。80語未満にする。 3. 朝のブリーフを作成する：上位3項目、競合、「断るべき1つのこと」。 ## 出力 トリアージ表、下書き、ブリーフ。それ以外は不要です。 ## ガードレール リーダーの代理で会議を承諾したり、約束をしたりしないでください。承認されるまでは、すべての下書きを下書きとして扱います。
優先順位の入力があるからこそ、トリアージが可能になります。それがなければ、すべてのメールが同じ緊急度になります。ブリーフ内の「断るべき1つのこと」の欄が、このスキルに明確な視点を与えます。ガードレールは、支援と意思決定の境界を示します。これは、委任されたAIに守らせたい境界です。
12. PRDジェネレーター
--- name: prd-generator description: 課題の記述とユーザー調査からプロダクト要件ドキュメントを作成します。機能のスコープを定める際に使用します。 --- あなたはシニアプロダクトマネージャーです。エンジニアが見積もりを出せるPRDを作成します。 ## 入力 課題の記述、対象ユーザー、根拠（調査メモ、サポートチケット、指標）、制約（期限、プラットフォーム、予算）、明確に対象外とする事項。 ## ワークフロー 1. 課題をユーザーの成果として書き直す。解決策を別の形で表現したものなら、そう明記する。 2. Given / When / Then形式の受け入れ基準を含むユーザーストーリーを一覧にする。 3. ベースラインと目標を含む成功指標を定義する。 4. 未解決の質問と、それぞれに回答すべき担当者を一覧にする。 ## 出力 課題、目標、対象外、ユーザーストーリー、要件（必須 / 望ましい / 可能なら）、指標、リスク、未解決の質問。 ## ガードレール UIデザインを提案しないでください。ベースラインの指標を推測せず、「ベースライン不明」と記載してください。
ステップ1では依頼内容にただ従うのではなく、依頼内容に異議を唱えています。それこそが優れたPMの仕事です。Given / When / Then形式にすると受け入れ基準をテスト可能にできます。出力に含める非目標のセクションは、PRDで最も役立つ部分になることが多く、ベースラインに関するガードレールは、誰も測定していない数値を文書に引用するのを防ぎます。
初心者が犯しがちな間違い
- 説明が案内ではなく売り文句になっている。「究極の生産性パワーハウス」では、いつSkillを読み込むべきかClaudeには何も伝わりません。何をするものか、必要なときにユーザーが言う言葉を記述します。
- 入力セクションがない。するとモデルは推測します。そしてエラーの原因は推測にあります。必要なものと、不足している場合の対応を列挙します。
- ワークフローが願望リストになっている。「徹底的かつ正確に」は手順ではありません。「書き始める前に入力全体を読む」は手順です。
- 出力形式がない。見出しや列を固定しないと、毎回異なる形になり、Skillを習慣として使うことができません。
- 曖昧なガードレール。「注意する」だけでは何も変わりません。「DOIを絶対に捏造しない」とすれば行動が変わります。実際に見た具体的な失敗を名前にします。
コピーして使えるテンプレート
--- name: your-skill-name description: 何を生成し、いつ使うものかを1文で説明します。ユーザーが入力する言葉を含めます。 --- あなたは[role]であり、[自分に課す基準]を満たします。 ## 入力 必要な情報をすべて列挙します。何かが不足している場合の対応（質問するか、名前を付けたデフォルト値を使うか）を明記します。 ## ワークフロー 1. 有能な人間が最初に行うこと。 2. 2つ目の項目。 3. 完了前のセルフチェック。 ## 出力 見出し、表の列、語数制限、ファイル形式を厳密に指定します。 ## ガードレール 絶対にしてはいけない具体的なこと。美徳ではなく失敗を名前にします。
次の名前で保存します .claude/skills/your-skill-name/SKILL.md Claude Codeで使うか、本文をProjectまたはカスタムGPTに貼り付けます。その後、実際の入力で3回実行し、最も悪い結果になったセクションを調整します。
断片ではなく完全なファイルが必要ですか？
上の断片は全体像を示したものです。カタログファイルが完全版で、各Skillの実例を複数収録し、エッジケースへの対応と、Claudeが作業を返す前に実行するチェックリストも含まれています。最も安く始める方法は次のいずれかです。
AI Meeting Notes Generator Skill（$9）：どんな文字起こしからでも、決定事項、アクションアイテム、未解決の質問を抽出。
AI Job Description Generator Skill（$9）：500語未満で、包括的かつ成果ベースの求人票。
AI Rubric Generator Skill（$9）：2人の採点者が合意できる基準、レベル、記述。
AI請求書ジェネレーターSkill（$9）：作業概要から、番号付きで合計額を計算した、クライアントにそのまま渡せる請求書を作成します。
すべてのSkillは買い切りで（.mdのSkillファイルとREADMEが含まれます）、ClaudeとClaude Code、ChatGPTのカスタムGPT、Gemini Gems、Copilotで利用でき、質問なしの30日間返金保証が付いています。開発者向けワークフローはClaude CodeのSkillコレクションを、その他すべてはClaudeのSkillコレクションをご覧ください。
よくある質問
SKILL.mdファイルとは何ですか？
frontmatterブロック（nameとdescription）に続いて、Claude向けの指示（役割、収集する入力、ワークフローの手順、出力形式、ガードレール）が記載されたMarkdownファイルです。タスクがdescriptionに一致すると、Claude Codeが自動的に読み込みます。
Claude CodeではSKILL.mdファイルをどこに配置しますか？
プロジェクト内の.claude/skills/your-skill-name/SKILL.md、またはすべてのプロジェクトで使いたいSkillの場合は~/.claude/skills/に配置します。フォルダー名はfrontmatterのnameフィールドと一致させてください。
ClaudeのSkillテンプレートをChatGPTやGeminiで使えますか？
はい。ファイルの本文（frontmatter以降のすべて）を、カスタムGPTの指示やGemini Gemに貼り付けてください。形式はプレーンMarkdownなので、Claude固有なのはClaude Codeでの自動読み込みだけです。
Skillファイルはどのくらいの長さにすべきですか？
推測に頼らずに済むほど十分な長さがあり、2分で読めるほど簡潔です。この記事の断片は15〜20行です。実運用向けのSkillは、記入例やチェックリストを含むため、通常60〜200行です。
この記事の12個の例は、実際の商品ファイルですか？
いいえ。同じ形式で構造を示すために書かれた、オリジナルの断片です。有料ファイルはより長く、例やエッジケースを含み、READMEと30日間の返金保証が付いています。
要点
役立つClaudeのSkillはすべて、丁寧に書かれた同じ6つの要素で構成されています。ルーティングを行う説明、役割、明示的な入力項目、番号付きのワークフロー、固定された出力形式、具体的なガードレールです。テンプレートをコピーし、自分の仕事に最も近い例を参考に作成して、実際の業務でテストしてください。完成済みのファイルから始めたい場合は、上記の$9のSkillが、完成版の内容を確認する最も安価な方法です。
KissMySkillsのマーケットプレイスにあるClaudeのSkillをすべて閲覧。
