「CLAUDE.mdは書いたけれど、結局は毎回同じ指示を貼り付けている」。そんな非エンジニアは少なくありません。じつはClaude Codeには、手順をまとめて呼び出せる「スキル」という仕組みがあります。ただしスキルは万能ではなく、向く業務と向かない業務があります。公式ドキュメントでは繰り返しのワークフローに強みがあるとされており、GOROの社内でもSlack発言のレビューや評価作業をスキル化した実例があります。非エンジニアが今日からスキルを作りたいなら、まずSKILL.mdの最小構成を知りましょう。ここでは、スキルの基本からCLAUDE.mdとの違い、作り方、安全に使うための注意点までを実例つきで解説します。
Claude Codeの「スキル」とは？CLAUDE.mdとの違いを整理
Claude Codeの「スキル」とは、同じ指示を毎回貼り付けなくて済むように、手順やチェックリストをひとつのファイルにまとめたものです。CLAUDE.mdが常に読み込まれる基本情報なのに対し、スキルは必要な場面だけ呼び出される点が異なります。繰り返し業務を仕組み化したい場合、この違いを理解しておくと設計の判断がしやすくなります。
スキルの定義（Anthropic公式の説明）
公式ドキュメントでは、スキルは指示書・スクリプト・資料をまとめたフォルダで、Claudeが場面に応じて自動的に見つけて読み込める仕組みと説明されています。作成する基準として挙げられているのは、同じ指示やチェックリストをチャットに貼り付け続けている状態です。
Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat （Extend Claude with skills）
スキルを作る作業は、新入社員向けのオンボーディング資料を用意する作業にたとえられています。
Building a skill for an agent is like putting together an onboarding guide for a new hire. （Equipping agents for the real world with Agent Skills）
手順書の中にPythonなどのコードを組み込むと、作業の結果が毎回ぶれない形になるとも説明されています。非エンジニアがコードを書く必要はありませんが、Claudeに「このスクリプトを使って」と指示すれば、同じ処理を再現できる仕組みです。
CLAUDE.mdとスキルの役割分担
CLAUDE.mdとスキルは、どちらも「同じ指示を繰り返し出す手間を減らす」ための仕組みですが、載せる情報の性質が異なります。
| 項目 | CLAUDE.md | スキル |
|---|---|---|
| 読み込まれるタイミング | 会話のたびに常時 | 使われるときだけ |
| 向いている内容 | 会社・業務全体の前提情報 | 特定の繰り返し作業の手順 |
| 分量の目安 | 短く保つ必要がある | 長い手順を書いても負担が小さい |
CLAUDE.mdは会話のたびに読み込まれる基本情報だとされています。内容を増やせば、その分読み込まれる分量も増えていくと考えられます（最新の仕様は公式ドキュメントでご確認ください）。一方でスキルの本体は呼び出されたときだけ読み込まれるため、長い参考資料を入れてもコストはほとんどかからないと説明されています。
a skill’s body loads only when it’s used, so long reference material costs almost nothing until you need it. （Extend Claude with skills）
CLAUDE.mdの書き方そのものを見直したい場合は、CLAUDE.mdの書き方と最初に書くべき内容もあわせて確認してください。
スキルが読み込まれるタイミング（段階的開示の仕組み）
スキルは一度にすべて読み込まれるわけではなく、3段階に分けて必要な分だけ読み込まれます。この仕組みは段階的開示（progressive disclosure）と呼ばれています。
- 第1段階：スキルの名前と説明文。常に軽く読み込まれ、Claudeが「どの場面で使うか」を判断する材料になる
- 第2段階：SKILL.md本文。該当するスキルが呼ばれたときに読み込まれる
- 第3段階：SKILL.mdに同梱したファイルやスクリプト。本文の中で必要になった時点で読み込まれる
This filesystem-based architecture enables progressive disclosure: Claude loads information in stages as needed, rather than consuming context upfront. （Agent Skills - Claude Platform Docs）
この仕組みのおかげで、同じ指示を会話のたびに書き直す必要がなくなります。
Skills load on demand, so you don’t have to repeat the same guidance across conversations. （Agent Skills - Claude Platform Docs）
CLAUDE.mdで書いていた細かい手順を、必要な場面だけで読み込まれるスキルに切り出す。これが、繰り返し業務を仕組み化する最初の整理になります。
スキルは何に向いている？繰り返し業務を見極めるポイント
スキルは、同じ指示を繰り返し出す手間を減らす仕組みです。では、どんな業務ならスキル化の効果が大きいのでしょうか。公式資料が挙げる基準と、実際にたまった本数から見ていきます。
同じ指示を毎回貼り付けている業務はスキル向き
公式の資料によると、繰り返し行うワークフローでスキルは強みを発揮します。例として、スタイルガイドに沿った文書作成や、一貫した手法のリサーチが挙げられています。
documents that follow your team’s style guide （The Complete Guide to Building Skills for Claude）
言い換えると、判断が毎回変わる業務より、手順が固定された業務のほうが向いています。たとえば次のような業務です。
- 月次レポートの作成と体裁統一
- 提案書・議事録のフォーマット整形
- SNS投稿文の下書き作成
- 定型チェックリストに沿った確認作業
これらはいずれも「毎回同じ型で繰り返す」という共通点を持っています。
スタイルガイドや品質チェックリストを埋め込む
同じ資料では、文書作成スキルの鍵となる手法が示されています。スタイルガイドやブランド基準の埋め込み、仕上げ前の品質チェックリストです。
Embedded style guides and brand standards （The Complete Guide to Building Skills for Claude）
表記ルールやトーン、チェック項目をスキルに書いておけば、担当者が変わっても同じ基準で仕上がります。成功の目安として、セッションをまたいでも結果が一貫しているかが挙げられています。誰が作っても同じ品質になる状態を、スキルが支える形です。
使い始めて1か月で40本以上たまった実例
GOROの研修を受けたある事業会社の運営担当者は、Claude Codeを使い始めて1か月で、手順書とスキルが40本を超えたと話しています。
実録支援先の声
使い始めて1か月で40本以上たまった手順書とスキル
「月次業務を手順書と自動化に置き換える、やりたいことを伝えるだけで動くスプレッドシートを丸ごと作る、コードで業務を自動化する、そもそもどこを改善すべきかを一緒に考える。使い始めて1か月で、こうした作業の手順書とスキルが40本以上たまりました。」
出典：研修を受けた支援先の運営担当者のコメント（GOROの社内の記録）
月次業務の自動化だけでなく、スプレッドシートの作成や改善点の洗い出しまで対象になっています。繰り返し業務という基準に当てはまれば、対象は定型文書に限りません。非エンジニアの業務でどこまで応用できるかは、Claude Codeの活用事例10選でも具体的に紹介しています。
【実録】Slack発言レビューと評価の下書きをスキル化してみた
ここからは、実際に運用している2つのスキルを紹介します。どちらも「同じ手順を毎回繰り返す」という条件に当てはまる業務です。
月末に自動で届く、自分のSlackレビュー
ひとつは、月末に自動で起動してSlackの発言をレビューするスキルです。
実録代表・旭の一次体験
月末に自動で起動するSlackレビュー
仕組みはClaude CodeのSkill（手順書のようなもの）で作りました。月末の夜に自動で起動し、その月の私の発言をSlackから集めてレビューします。結果は社内のBotから、私宛てのDMで届きます。
8月分は、あとから同じ手順でレビューしました。
出典：Slackでの自分のコミュニケーションを、Claude Codeに毎月レビューしてもらっています（代表・旭俊成のnote）
7月から運用を始め、すでに3か月分の結果が出ています。手が空いたときではなく、月末の夜という決まったタイミングに自動で起動する点が特徴です。毎月「発言を見返す」という作業を、自分で思い出して始める必要がなくなりました。
一次評価の叩き台を同じ手順で全員分作る
もうひとつは、評価の一次対応をスキル化した例です。
実録代表・旭の一次体験
一次評価の手順をSkillにまとめる
1人分の一次評価がうまく回ったので、手順をClaude CodeのSkill（再利用できる手順書のようなものです）にまとめました。他のメンバーも、同じ型で回せるようになりました。
出典：Claude Codeに評価の叩き台を作らせたら、空欄が返ってきた（代表・旭俊成のnote）
最初は1人分の評価で手順を確認し、そのやり方をそのままスキルに書き起こしました。同じ手順を他のメンバーの評価にも当てはめられるようになり、全員分の叩き台を同じ型で作れる状態になっています。
効率化より大きかった『公平性』という効果
このスキルがもたらした効果は、作業時間の短縮だけではありませんでした。
実録代表・旭の一次体験
公平性という効果
効率化はもちろんですが、いちばんの恩恵は「公平性」でした。
同じ手順・同じ定義で全員分を作れば、少なくとも一次評価では、全員に同じ物差しが当たります。
出典：Claude Codeに評価の叩き台を作らせたら、空欄が返ってきた（代表・旭俊成のnote）
評価する人の調子や忙しさによって基準がぶれる状況は、属人化した業務でよく起こります。手順をスキルにまとめておけば、誰が一次対応をしても同じ定義で評価が作られます。根拠となる手順が共通しているため、本人への説明にも使いやすい形が残ります。
Claude Codeのフォルダ構成とは？非エンジニアが業務記録を活かす置き方を解説で紹介している置き場所の工夫と組み合わせると、スキルとその実行結果を後から見返しやすくなります。
スキルの作り方の基本（SKILL.mdの最小構成と呼び出し方）
ここまで紹介した2つのスキルは、どちらもSKILL.mdというひとつのファイルで動いています。実際にはどんな内容を書き、どう呼び出すのか、最小構成から確認します。
SKILL.mdに書く内容と呼び出し方（/スキル名）
公式ドキュメントでは、SKILL.mdファイルを作成するとClaudeがそれをツールキットに追加し、関連する場面で自動的に使うか「/スキル名」で直接呼び出せると説明されています。
Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat. …it’s addressable with “/skill-name”. （Extend Claude with skills）
SKILL.mdに書く内容は、次のような要素で構成します。
- スキルの名前と、どんな場面で使うかの説明文
- 作業の手順（ステップに分けて番号をふる）
- 入力として受け取る情報と、出力の形式
- 守ってほしいルール（やってはいけないことを含む）
呼び出し方は難しくありません。チャット欄に「/スキル名」と打ち込めば、その手順がそのまま実行されます。名前を覚えていなくても、該当する作業を頼めばClaudeが自動的に選んで使う場合もあります。
実際に作られたスキルの構成を覗いてみる
社内の作業記録には、毎朝のSlack投稿文を作るスキルの中身が残っています。
このスキルは90行・3ステップです。「/morning」と打つと、カレンダーの今日の予定とNotionの今週のタスクを並べて取得し、見出しを「作業／会議／ひとこと」の3つに固定して整え、Slackの自分のチャンネルに下書きとして出力します。
実録GOROの作業記録
朝の投稿文を作るスキルの決めごと
「仮テキストで固定（毎回考えない）：
今日もよろしくお願いします！」「ユーザーが確認・編集して自分で送る（自動送信しない）」
出典：GOROの社内の作業記録
90行という分量は、決して短くありません。それでも実際に動くスキルとして運用できています。見出しの数を固定し、ひとことを定型文にしておくことで、判断を挟まず同じ形で仕上がる設計になっています。
長い手順書を入れてもコンテキストを圧迫しない理由
スキルの本体は、呼び出されたときだけ読み込まれます。先ほどの朝の投稿文作成スキルのように90行の手順を書いても、使わない日はこの内容が会話に乗ることはありません。CLAUDE.mdに同じ分量の手順を書き足すと、会話のたびに読み込まれる基本情報が重くなっていきます。業務ごとに手順書を増やしても負担が積み上がらない点が、スキルという仕組みの扱いやすさにつながっています。
公開されているスキルをそのまま使うときに確認すべきこと
SKILL.mdの最小構成がわかると、次は配布されているスキルをそのまま使いたくなります。ただし、人が書いた手順をそのまま取り入れる前に、確認しておきたい点があります。
公開スキルを使う前に中身を確認する
配布されているスキルは、SKILL.mdと同梱ファイルをひとまとめにしたフォルダです。中身はただのテキストとスクリプトなので、使う前に開いて読めます。手順に何が書かれているか、同梱されているファイルが何かを、実行前に確認しておく作業です。
社内では、推敲の確認に使うスキルをこの手順で作っています。
実録GOROの作業記録
公開されている規則をベースにスキルを作る
推敲の確認には
/natural-japaneseスキル（~/.claude/skills/natural-japanese/）を使う。nanaism/yomiyasu v1.0.7 の規則と検査スクリプト（lint・diff）を同梱し、旭の好みを足したもの（2026-10-06作成）。出典：GOROの社内の作業記録
公開されている規則と検査スクリプトをそのまま使わず、一度中身を確認してから取り込んだ例です。
同梱スクリプトが何をするか（読み取り専用かどうか）
手順の文章だけでなく、同梱されているスクリプトが何をするかも確認の対象です。特に見ておきたいのは、ファイルを書き換える処理があるか、外部のライブラリに依存していないか、という点です。
先ほどのスキルでは、この確認を済ませたうえで実行する判断をしています。
実録GOROの作業記録
実行前に確認した内容
スクリプトは標準ライブラリのみ・読み取りのみと確認済みなので、そのまま実行してよい。
出典：GOROの社内の作業記録
標準ライブラリだけで動いていて、ファイルを読み取るだけの処理であることを確かめてから実行に進んでいます。同梱スクリプトの中身を見ずに実行する場合と比べて、手間はかかりますが、何が起きるかわからないまま動かすよりは安全です。
好みや社内ルールを足して調整する
公開されているスキルは、そのまま使わなくてもかまいません。土台として取り込み、自分たちの基準を足して調整する使い方もできます。
先ほどの推敲用スキルも、公開されている規則をそのまま採用したわけではありません。規則と検査スクリプトに「旭の好みを足したもの」として作られています。ルールの一部を社内の表記基準に合わせて書き換えたり、チェック項目を増やしたりする調整が、公開スキルの活用では現実的な選択肢になります。
公開されているスキルは、中身を確認し、安全なスクリプトかを見極め、必要に応じて調整する。この3つの手順を踏めば、配布元のスキルも業務に取り込みやすくなります。
サブエージェントと組み合わせて、処理を任せながらコストを抑える
公開スキルを調整して使えるようになると、次に気になるのは実行のさせ方です。スキルに書いた手順を、誰にどのモデルで動かすかという設計の話です。
判断を伴わない作業はHaikuのサブエージェントに任せる
公式ドキュメントでは、サブエージェントは独立したコンテキスト（会話の記憶領域）で動作し、探索や実装の作業をメインの会話から切り離して温存できると説明されています。言い換えると、サブエージェントはメインの会話とは別の場所で作業を進める「下請け役」のようなAIです。あわせて、Haikuのような高速・低コストなモデルに作業を振り分けてコストを抑えられるとも書かれています。
by routing tasks to faster, lower-cost models like Haiku （Use subagents）
モデルの振り分けを朝の投稿文作成スキルに当てはめた例があります。
実録GOROの作業記録
判断を伴わない作業をHaikuに委譲する
「このスキルは事実の回収＋定型フォーマット整形のみで、判断や創作を伴わない。そのため Step 1〜3 の一連の作業は haiku サブエージェント（
model: haiku）に委譲して実行する。」出典：GOROの社内の作業記録
ここでの「model: haiku」とは、軽くて低コストな処理に向いたモデル（Haiku）を使うという設定です。スキルの中身をすべて同じモデルで動かす必要はありません。工程ごとに「判断が要るか」を分けて考えると、どこをサブエージェントに任せられるかが見えてきます。
朝の投稿文を自動で作り、下書きに置くまでの流れ
このスキルの中でサブエージェントが担うのは、Step1からStep3までの一連の処理です。予定とタスクを集め、決まった見出しに整形し、下書きとして出力するところまでを任せています。作業の内容はここまで見てきたとおりですが、この一連をメインの会話ではなくサブエージェントで動かしている点が設計の要になっています。
メイン側が行うのは、サブエージェントから戻ってきた結果を受け取って見せるだけです。入力の取得から整形までをまるごと渡しているため、メインの会話には途中経過の情報が積み上がりません。判断の要らない作業を切り離すほど、メインの会話は本来の仕事に使える余地が残ります。
| 工程 | 担当 | 内容 |
|---|---|---|
| Step1〜3（取得・整形・下書き出力） | Haikuのサブエージェント | 事実の回収と定型フォーマットへの整形 |
| 受け取り・表示 | メイン | サブエージェントの結果をそのまま見せる |
自動送信はさせない、という運用上の線引き
サブエージェントに任せているのは下書きを作るところまでです。Slackへの投稿文自体を自動で送信する設計にはしていません。下書きを作るツールと、実際に送信するツールは別物として扱われています。
この区切りを設けているのは、文面を最終的に見る人がいなくなる状態を避けるためです。守らせているルールのひとつに、見出しの装飾や文言を勝手に変えないという項目もあります。サブエージェントに作業を委譲しても、出力の形式そのものは固定したまま変えさせない設計です。
判断を伴わない部分はモデルに任せ、最後の確認と送信だけは人の手に残す。この組み合わせが、コストを抑えながら安心して運用を続けられる形になっています。 \1
- CLAUDE.mdの書き方とは？非エンジニアが最初に書くべき内容と注意点を解説 — スキルと役割がよく混同されるCLAUDE.mdについて、書き方や注意点を詳しく知りたくなるため
- Claude Codeのフォルダ構成とは？非エンジニアが業務記録を活かす置き方を解説 — スキルファイルの置き場所や業務記録のフォルダ構成を具体的にどう整理すればよいか知りたくなるため
- Claude Codeの活用事例10選｜非エンジニアの業務が変わる使い方を実例で解説 — スキル以外にもClaude Codeを業務でどう使えるか、幅広い活用事例を知りたくなるため
Claude Codeを業務で使いたい方へ
自分の業務を題材に試したい方には、1対1で進めるClaude Code マンツーマン講座があります（オンライン・回数制）。部署やチームで導入する場合は、業務に合わせて内容を設計するClaude Code法人研修をご覧ください。
