Claude CodeのSkillsとは｜作り方・一覧・活用テンプレート

2026年7月11日2026年7月21日

この記事でわかること

「Claude Codeは入れたけれど、毎回同じプロンプトを書いていて、思ったほど時短になっていない」――あなたがそう感じているなら、次に見るべき機能がClaude Code Skillsです。

この記事では、claude code skillsの全体像から、あなたの会社で使うSkillsの作り方、業務別の一覧、サブエージェントとの分担までを実務目線で整理します。すでにClaude Codeを導入している担当者向けに、テンプレートとしてそのまま調整できる形まで落とし込みます。

まだインストールや料金支払い、基本的なClaude Codeのやり方が曖昧な場合は、先にClaude Codeの導入と基本操作を確認してから戻ると理解しやすくなります。この記事はA27の応用編として、あなたの会社のワークフローを「毎回の会話」から「再利用できる仕組み」に変えるための内容です。

全体像はシンプルです。毎回使う指示や判断基準はSkillsにまとめ、複数の役割で分担したい作業はサブエージェントに任せ、外部APIやツール連携が必要な処理はMCPやスクリプトを検討します。

AI活用の現在地をチェックしたい方へ。AI戦略診断（無料・登録不要・約3分）が、そのまま自社のチェックリストとして使えます。もっと具体的に相談したい方は、お問い合わせからどうぞ。

「毎回同じ指示を書いている」非効率

あなたがClaude Codeを使い始めると、最初は「プロンプトを打てばコードや資料が生成される」という便利さを感じるはずです。一方で、実務に入るほど「会社の文体」「チェック観点」「ファイル構造」「出力形式」を毎回説明する場面が増えてきます。

たとえば、あなたの会社でホームページ作成をClaude Codeに手伝わせる場合を考えてみます。毎回「中小企業向けに、煽らず、サービス導線を意識して、見出しはこの順番で、デザインは既存CSSに合わせて」と書いているなら、それはすでにSkills化の候補です。

「また同じ前提説明から始めるのか」と感じる作業は、AI活用の失敗ではありません。むしろ、あなたの会社の業務に固有のルールが見えてきたサインです。

Claude Codeの特徴は、単なるチャットではなく、プロジェクトやリポジトリのファイルを参照しながら、コード、ドキュメント、コマンド実行をまたいで作業できる点にあります。Claude Codeの何がすごいのかと聞かれれば、あなたの会社の作業環境の中で、文脈を持ったままタスクを進められることだと言えます。

ただし、その強みは「指示が整理されているほど」活きます。プロンプトが担当者の頭の中にだけある状態では、同じタスクでも出力が揺れ、管理もしづらくなります。

結論：繰り返し業務はSkills化・分担はサブエージェント

結論から言うと、あなたの会社で繰り返し発生する作業はSkills化し、役割を分けたい作業はサブエージェントに分担させるのが基本です。Claude Code Skills、サブエージェント、MCPを一度に覚えようとすると混乱しやすいので、まずは役割で分けて考えます。

Skillsは、毎回使う指示・知識・ファイル・テンプレートをひとまとまりにした「再利用できる業務手順」です。Claude Skillsとは何なのか、クロードコードのSKILLとは何ですか、と聞かれたら、あなたの会社専用の作業マニュアルをClaudeが必要に応じて参照できる形にしたもの、と捉えると腹落ちしやすいです。

サブエージェントは、調査担当、レビュー担当、実装担当のように、タスクを役割で分けるための機能です。Skillsが「手順や判断基準のパッケージ」だとすれば、サブエージェントは「その役割を持つAI担当者」に近い位置づけです。

使い分け	向いている場面	あなたの会社での例
CLAUDE.md	プロジェクトで常に守らせたいルール	命名規則、ディレクトリ構成、禁止事項、レビュー基準
Skills	同じ指示、同じ形式、同じチェック観点を何度も使う	記事構成、議事録整形、提案書レビュー、デザインチェック
スラッシュコマンド	短い定型操作をその場で呼び出したい	「/deploy」「/review」のような1行操作
サブエージェント	複数の役割で作業を分けたい	調査担当、編集担当、コードレビュー担当、品質確認担当
MCP・外部ツール	外部サービスやAPI、データベースと接続したい	CRM参照、スプレッドシート連携、社内DB検索
スクリプト	定型処理を機械的に実行したい	ファイル名整理、リンクチェック、CSV変換

判断軸はシンプルです。常時守らせたいプロジェクトのルールはCLAUDE.md、必要なときに呼び出す手順はSkills、外部接続はMCP、役割分担はサブエージェント、短い定型操作はコマンドに置きます。

ここで大切なのは、Skillsに何でも詰め込まないことです。あなたの会社の固有ルールをSkillsに置き、判断や分担が必要なところはサブエージェント、外部処理はツールやAPIに逃がすと、ワークフロー全体が管理しやすくなります。

なお、AIの出力には誤りが混ざりうるため、法務・会計・採用・契約などの個別判断は、社内責任者や専門家の確認を前提にしてください。

なぜ必要なときだけSkillが呼ばれるのか（3段階）

Skillsが必要なときにだけ効いてくる理由は、読み込みのタイミングが3段階に分かれている点にあります。あなたの会社で運用設計をするときも、この3段階を押さえておくと判断しやすくなります。

第1段階は、Skill名とdescription（説明）です。通常のセッションでは、登録されているSkillのdescriptionがコンテキストに読み込まれ、Claudeが「いま何が使えるか」を把握して利用候補を判断します。各Skillのdescriptionとwhen_to_useは、合わせて1,536文字を上限として一覧に載ります。さらに一覧全体にもコンテキスト予算があり、既定ではモデルのコンテキストウィンドウの1%です。予算を超えると、利用頻度の低いSkillのdescriptionから名前だけの表示に縮約されます。超過しているかは/doctorで確認できます。コンテキスト使用量を抑えるための仕様です。

第2段階は、SKILL.md本体です。本体の全文が読み込まれるのは、そのSkillが呼び出されたときだけです。

ただし、一度読み込まれた本体は、その後のやり取りでもコンテキストに残ります。だからこそ、SKILL.md本体は簡潔に書くのが基本です。

第3段階は、references、templates、scriptsなどの追加ファイルです。これらはSKILL.mdの指示に従って、必要なものだけを読み込む・実行する形になります。

つまり、大きな参照資料をSkillに同梱しても、毎回そのすべてが読み込まれるわけではありません。

「Skillは何個作ってもタダ」ではない

コストの捉え方には注意が必要です。SKILL.mdの全文は呼び出されるまで読み込まれないため、同じ内容を常時読み込ませておくより効率的なのは確かです。

一方で、Skill名とdescriptionの一覧にはコンテキストコストがあり、Skillが増えるほど一覧のコストも増えます。前述のとおり、一覧のテキストは1,536文字で切り詰められる仕様になっています。

あなたの会社で運用するなら、使わなくなったSkillを放置せず、一覧を整理し続ける前提で設計してください。

Skillの置き場所とカスタムコマンド

Skillの置き場所は2種類あります。プロジェクト用は「.claude/skills/〈スキル名〉/SKILL.md」、個人用は「~/.claude/skills/」です。

プロジェクト用はそのリポジトリで作業する人が共通で使えるのに対し、個人用はあなたの環境だけで使えます。まず個人用で試し、社内で共有したいものだけプロジェクト用に移す流れが現実的です。

カスタムコマンドはSkillsに統合されており、「.claude/commands/deploy.md」と「.claude/skills/deploy/SKILL.md」は、どちらも「/deploy」を作ります。すでにcommandsに置いているファイルは、そのまま動きます。

なお、Claude CodeのSkillsは、Agent Skillsというオープン標準に準拠しています。仕様は更新されるため、実装前にClaude Code Skills 公式ドキュメントで最新の記載を確認してください。

Skillsの作り方（実物テンプレート）

あなたの会社でClaude Code Skillsを作るときは、いきなり大きな自動化を狙わず、「毎週使っている定型プロンプト」を1つ選ぶのが始めやすいです。Skillsの作り方で迷う人の多くは、最初から万能スキルを作ろうとして手が止まります。

基本手順は、次の5段階です。あなたが普段書いているプロンプトを、Claudeが読みやすいファイル構造に移すイメージで進めます。

対象タスクを1つに絞る
起動条件をdescriptionに書く
SKILL.mdに手順と判断基準を記述する
参照資料、テンプレート、スクリプトを追加する
実際のプロジェクトでテストし、説明文を調整する

Claude Code Skills 公式ドキュメントの考え方に沿うと、Skillはディレクトリ単位で管理し、その中にSKILL.mdと必要なファイルを置く構造で考えると扱いやすくなります。あなたの会社で共有する場合は、プロジェクト単位のリポジトリに置くか、個人環境で試してから共通化する流れが現実的です。

社内向けSkills一覧の例

おすすめのSkillsの一覧を探す前に、あなたの会社の繰り返し業務を棚卸しすると、導入効果を判断しやすくなります。中小企業で使いやすいのは、自社固有の文体・判断基準・出力形式を含むSkillsだからです。

参考にするなら、まずは公式ドキュメントに記載されている例に絞るのが安全です。第三者がまとめた一覧サイトからSkillを入手する場合は、後述する配布元・指示内容・同梱スクリプト・要求権限の確認とセットで進めてください。

Skill名の例	用途	向いている担当
article-brief-to-draft	記事構成案から本文ドラフトを作成	広報、マーケティング
company-homepage-section	ホームページ作成時のセクション文案生成	Web担当、経営企画
proposal-review	提案書の抜け漏れ確認	営業、社長室
meeting-minutes-to-actions	議事録からタスクと期限を整理	総務、PM
design-tone-check	デザインや文体がブランドに合うか確認	Web、制作
competitor-research-summary	調査結果を3C視点で整理	企画、営業

おすすめのClaude SKILLは、あなたの会社で「判断基準がある程度決まっている」「週1回以上使う」「出力形式が決まっている」作業です。逆に、毎回条件が大きく変わる新規事業判断のようなタスクは、Skillsよりも通常の会話やサブエージェント分担の方が向く場合があります。

Skillディレクトリの実物テンプレート

以下は、Claude Codeでホームページを作成する場面を想定したSkillsテンプレートです。あなたの会社のホームページ改善、サービスページ追加、採用ページ作成などに合わせて調整できます。

company-homepage-section/
  SKILL.md
  references/
    brand-tone.md
    service-summary.md
    ng-expressions.md
  templates/
    section-outline.md
    cta-patterns.md
  scripts/
    check-links.py

SKILL.mdは、Claudeが「いつ使うべきか」を判断するdescriptionと、実際の作業手順で構成します。descriptionが曖昧だとSkillsが起動しにくくなり、広すぎると関係ないタスクでも呼ばれやすくなります。

descriptionの良い例・悪い例

descriptionは、あなたの会社でSkillsが安定して動くかを左右する部分です。広すぎても狭すぎても、意図した場面で呼ばれなくなります。

書き方	descriptionの例	何が起きるか
広すぎる	文章を作成するときに使う	議事録でも提案書でも呼ばれ、他のSkillと競合して出力が安定しない
狭すぎる	2026年4月の採用ページ改訂で使う	条件がわずかにずれると呼ばれず、結局手作業に戻る
適切	中小企業向け日本語ホームページのセクション（サービスページ、トップページ、CTA）を新規作成・改訂するときに使う	対象と作業が具体的で、必要な場面だけ起動しやすい

要点は、機能の説明ではなく「何をするときに使うか」を具体的に書くことです。対象物（ホームページのセクション）、作業（新規作成・改訂）、条件（中小企業向け・日本語）の3点が入っていると、判断がぶれにくくなります。

---
name: company-homepage-section
description: Use this skill when creating or revising Japanese homepage sections for a small or mid-sized company, including service pages, top page blocks, CTA sections, and design-aware copy.
---

# 目的
あなたの会社のホームページ作成・改善において、既存のブランドトーン、サービス情報、導線設計に沿ったセクション案を作成する。

# 入力として確認すること
- 対象ページ
- 読者
- 伝えたいサービス
- CTAの種類
- 既存デザインやCSS上の制約
- 使用してよい社内資料

# 作業手順
1. references/service-summary.mdを参照し、サービス内容を要約する
2. references/brand-tone.mdを参照し、文体を合わせる
3. templates/section-outline.mdに沿って構成を作る
4. 見出し、本文、CTA前文、補足要素を生成する
5. references/ng-expressions.mdに照らして表現を確認する
6. 必要に応じてscripts/check-links.pyでリンク候補を確認する

# 出力形式
- セクション名
- 目的
- 見出し案
- 本文案
- CTA前文
- デザイン上の注意
- 確認すべき未確定事項

このテンプレートのポイントは、プロンプトを長くすることではなく、あなたの会社の判断基準をファイルとして分けることです。文体はbrand-tone.md、サービス情報はservice-summary.md、禁止表現はng-expressions.mdに分けると、後から更新しやすくなります。

ここで、私が本サイトの運営で実際に使っているSkillの例を一つ紹介します。私は、Webサイトの記事を書く手順そのものをSkillにして、AIエージェントに実行させています。具体的には、テーマに関する情報を幅広く集める、必要に応じて競合サイトを調べる、キーワードのSEO情報を取得して狙うキーワードを決める、という一連のリサーチ業務です。

ポイントは、思いつきの指示を自動化したのではないことです。AIが登場する前、私はすべての記事を自分の手で書いていました。Webコンサルタントとして、お客さまにもGoogleにも評価される記事の書き方を熟知しているつもりです。その私が「まさに自分が記事をリサーチして書く手順」を、そのままSkillに落とし込みました。Skillの品質は、元になる手順の品質で決まります。

最初のテスト手順

Skillを作成したら、あなたの会社の実案件に近い入力でテストします。テストでは「うまく出たか」だけでなく、「なぜそのSkillが呼ばれたか」「呼ばれてほしくない場面で起動していないか」を見ます。

たとえば、次のようなClaude Code プロンプトで確認します。

このプロジェクトの既存ファイルを参照し、サービスページに追加する
「導入後のサポート」セクション案を作成してください。
文体は既存ページに合わせ、CTA前の不安解消も入れてください。

期待する出力とズレる場合は、本文よりもdescriptionを先に調整します。Claude Code Skillsを実務で使う場面では、スキル本文を作り込むより、起動条件を短く具体的にする方が安定しやすい場面があります。

サブエージェントの使いどころと注意

あなたの会社でClaude Code活用を進めると、1つのタスクの中に「調べる」「作る」「直す」「確認する」が混ざってきます。このとき、すべてを1つのSkillsに入れると、指示が重くなり、作業の責任範囲も見えにくくなります。

サブエージェントは、こうした複数の役割を分けるときに使います。たとえば、調査エージェント、編集エージェント、コードレビューエージェント、デザインチェックエージェントのように分けると、あなたが最終判断しやすくなります。

Skillsとサブエージェントの違いは、3Cで考えると整理しやすいです。Company、つまりあなたの会社の固有ルールはSkillsに置き、CustomerやCompetitorの調査は調査エージェントに任せ、最後にCompany視点で統合する流れです。

役割	向いている機能	例
自社ルールの参照	Skills	文体、商品説明、NG表現、提案書構成
専門担当としての作業	サブエージェント	調査、レビュー、テスト、編集
外部データ取得	MCP・API	CRM、分析ツール、外部ドキュメント
定型処理	スクリプト	整形、変換、リンク確認

注意点は、サブエージェントにも権限と範囲を持たせすぎないことです。あなたの会社の重要ファイルに関わる場合は、利用できるツール、参照してよいディレクトリ、実行してよいコマンドを絞る設計が安全です。

また、descriptionが広すぎるエージェントは、関係の薄いタスクでも呼ばれやすくなります。「調査全般」よりも「競合ページを比較し、差別化観点を箇条書きにする」のように、作業内容と出力を狭めた方が管理しやすくなります。

エージェントへの任せ方について、私の実感も一つ添えます。「AIで記事を自動実行」と聞くと、手抜きや低品質をイメージする方もいるかもしれません。しかし、自動実行には悪い自動実行と良い自動実行があります。そして後者の実体は、ほとんどの場合「よい”半”自動実行」です。

どういうことか。私はAIエージェントに記事を書かせた後、必ずその執筆過程を追いかけます。どのようなWeb情報・SEO情報・競合情報を調べ、どのように記事構成を組み立てたのか。任せっぱなしにせず、過程まで検証する。ここまでやって初めて、品質を保証できる記事が作れます。Skillで手順を渡し、エージェントに実行させ、人が過程と結果を監督する——この分担が「半自動」と呼ばれるゆえんです。

業務別の活用例（資料・調査・定型文書）

あなたの会社で最初にClaude Code Skillsを試すなら、資料作成、調査整理、定型文書の3つが現実的です。いきなり全社導入するより、既存ファイルとプロンプトが多い部署から小さく始める方が、改善点も見つけやすくなります。

資料作成：提案書・社内説明資料

提案書や社内説明資料では、あなたの会社の強み、価格帯、導入事例、言い回しをSkillsに入れておくと便利です。営業担当が毎回ゼロから構成を考えるのではなく、型に沿って初稿を作り、人が顧客事情に合わせて直す流れにできます。

活用テンプレートは次のように組めます。

proposal-draft/
  SKILL.md
  references/
    company-strength.md
    service-menu.md
    case-studies.md
  templates/
    proposal-outline.md
    executive-summary.md

プロンプト例は、「この顧客メモをもとに、proposal-draft Skillの方針に沿って提案書の骨子を作成してください。3CのうちCustomerの課題を先に整理し、当社の提案は後半にまとめてください」のようにします。

調査：競合比較・市場メモ

調査業務では、Skillsだけで完結させず、サブエージェントと組み合わせるのが向いています。あなたが調査観点をSkillsに置き、競合ページの読み取りや比較表作成を調査エージェントに分担させるイメージです。

SWOTで整理するなら、StrengthとWeaknessはあなたの会社の内部情報なのでSkillsや社内ドキュメントに置きます。OpportunityとThreatは外部環境なので、調査エージェントや外部ツールを使って更新する方が自然です。

プロンプト例は、「競合3社のサービスページを比較し、価格ではなく導入支援、サポート、表現トーンの違いを整理してください。最後に当社ページへ反映する見出し案を5つ出してください」です。

定型文書：議事録・報告書・メール

議事録、月次報告、顧客向けメールは、Claude Code Skillsの例として取り組みやすい領域です。あなたの会社のフォーマット、敬語レベル、上長確認の観点をSKILL.mdやテンプレートにしておくと、担当者によるばらつきを減らしやすくなります。

たとえば、meeting-minutes-to-actions Skillでは、議事録から「決定事項」「未決事項」「担当者」「期限」「社長確認が必要な論点」に分けて出力するよう指定します。中小企業では社長や役員への確認事項が埋もれやすいため、このような分類は実務上の価値があります。

Claude Codeのテンプレートとして使う場合は、文面そのものよりも「何を確認してから出すか」を明記します。あなたの会社の承認フローや顧客対応ルールが入ることで、単なる文章生成ではなく、業務に沿った支援になります。

オウンドメディア運用での具体的な分担は、Claude Codeでオウンドメディア運用を管理する方法でも整理しています。記事制作、内部リンク、品質確認のような複数工程を扱う場合は、Skillsとエージェント分担の相性がよくなります。

失敗パターン（作り込みすぎ・丸投げ）

あなたの会社でClaude Code Skillsを導入するとき、よくある失敗は大きく2つです。1つ目は作り込みすぎ、2つ目は丸投げです。

作り込みすぎのパターンでは、最初から巨大なSKILL.mdを作り、あらゆる業務を1つのスキルに詰め込んでしまいます。結果として、どのタスクで使うべきかが曖昧になり、Claudeが必要な知識を参照しにくくなります。

避けるには、あなたの会社のSkills一覧を「1スキル1目的」で管理します。たとえば、記事作成、デザインチェック、提案書レビュー、議事録整理は分けておき、共通の文体ルールだけreferencesとして共有する方が更新しやすいです。

丸投げのパターンでは、「良い感じに作って」とだけ依頼し、確認観点を人間側で持たないまま進めてしまいます。Claude Codeは作業を進める力がありますが、経営判断、顧客との約束、法的な表現、ブランド毀損リスクまで自動で管理してくれるわけではありません。

あなたの会社で運用するなら、最低限のレビュー観点をチェックリストにします。たとえば、事実関係、顧客名、価格表現、成果表現、社内承認、デザイン崩れ、リンク先、トーンの8項目を確認するだけでも、運用の安定度は変わります。

もう1つの失敗は、公式ドキュメントや公開された一覧のSkillを見て、そのまま自社に当てはめようとすることです。公開スキルは参考になりますが、あなたの会社の商材、顧客、承認フロー、禁止表現が入っていなければ、実務では修正が多くなります。

もう1つ、外部から入手したSkillの扱いにも注意が必要です。Skillには手順書だけでなく、参照ファイルやスクリプトが同梱されることがあります。

第三者が配布するSkillを使う場合は、配布元、SKILL.mdに書かれた指示内容、同梱スクリプトの中身、要求される権限の4点を必ず確認してください。

中身を確認していないSkillを、そのままあなたの会社の業務環境で実行するのは避けます。まず個人の検証用プロジェクトで動かし、問題がないと確認できてから共有する流れが安全です。

仕様や配置方法は更新されるため、判断に迷う点はClaude Code Skills 公式ドキュメントで確認するのが確実です。

最後に、Skillsは作って終わりではなく、業務変更に合わせて管理する対象です。新サービスが増えた、ホームページのデザインが変わった、営業資料の構成が変わったときは、関連するファイルやdescriptionも見直します。

この記事を書いた人

西俊明（トシゾー）中小企業診断士／AI実践戦略士／IT講師・著者

中小企業診断士／AI実践戦略士（商標出願中）／IT講師・著者。富士通で17年間、IT製品の営業・マーケティングに従事した後、独立。中小企業を中心に270社超を支援し、研修・セミナーへの登壇は250回を超える。現在は、生成AI・ITを経営や業務に生かす実践的な方法と、ITパスポート、情報セキュリティマネジメント、基本情報技術者試験などの学習法・過去問解説を発信している。著書に『改訂7版 ITパスポート最速合格術』など。