Claude Codeのスキルの使い方｜SKILL.mdの作成から呼び出しまで

Claude Codeで同じ確認手順を何度も入力しているなら、スキルとして保存すると、短い呼び出しで再利用できます。基本は、専用フォルダに置く SKILL.md というテキストファイルです。用途と作業手順を書き、実際の入力で結果を確かめるところから始めます。

最初の一つには、文章の表記確認や変更点の整理など、結果を自分で判断できる作業が向いています。機能を大量に追加するより、何を渡せば何が返るかが分かる手順を作るほうが、日々の仕事に組み込みやすくなります。

以下では、パソコン上のClaude Codeで使う文章チェックの例を軸に、保存先、書き方、呼び出し、配布スキルの選び方を説明します。設定名や提供条件は2026年10月28日に確認した公式資料に基づきます。掲載する文章チェックは学習用の設計例であり、実行結果や性能を保証するものではありません。

Claude Codeのスキルで何ができるか

毎回の指示を作業手順として保存する

スキルは、特定の仕事に必要な指示や資料をひとまとめにする仕組みです。たとえば「資料を読み、表記ゆれを探し、元の文と修正案を表にする」という一連の手順を保存できます。通常の会話で毎回説明していた条件を、作業のたびに組み立て直す手間が減ります。

単に長いプロンプトを保管するだけでなく、参考にする表記ルールや出力の見本も一緒に置けます。Anthropicは、指示に加えてテンプレートやスクリプトなどを含められる仕組みとしてAgent Skillsを説明しています。[1]

使い道を決めるときは、直近の作業で二度以上繰り返した説明を探すと具体的になります。「丁寧に書く」といった好みだけでなく、確認する順番や成果物の形が繰り返されていれば、スキルにまとめる候補です。毎回内容が違う仕事でも、確認の観点が共通なら再利用できます。

CLAUDE.md・MCP・サブエージェントと使い分ける

周辺機能は、どれもClaude Codeを仕事に合わせる方法ですが、主な役割が違います。CLAUDE.mdにはプロジェクトの前提や共通ルールを、スキルには特定の作業手順を置くと整理しやすくなります。たとえば社名の正式表記は共通ルール、記事の校正手順はスキルという分担です。[2]

MCPは外部のデータやツールに接続する仕組みで、サブエージェントは別のコンテキストで担当作業を進める仕組みです。スキルに外部サービスの操作手順を書いても、それだけで接続や認証が済むわけではありません。[3][4]

やりたいこと	まず検討する機能	具体例
プロジェクト共通の前提を伝える	CLAUDE.md	使う言語、表記、作業の約束
繰り返す仕事の進め方を残す	スキル	文章チェック、資料の整理
外部の情報や機能を使う	MCP	接続済みサービスから情報を読む
調査などの担当を分ける	サブエージェント	別の担当で調べ、要点を返す
特定の処理を契機に動作させる	Hooks	編集後の整形など

Hooksは実行のタイミングに処理を結び付ける機能です。会話から必要な手順を選ぶスキルとは使いどころが異なるため、最初からすべてを組み合わせる必要はありません。[5]

最初は一つの確認作業に絞る

最初のスキルは、入力も出力も一つに絞ると確認しやすくなります。「商品紹介文を渡すと、表記の不一致と説明不足の候補が返る」くらいの範囲です。調査、執筆、画像作成、公開までをまとめると、期待と違ったときに原因を探す場所が増えます。

文章チェックなら、最初は誤字、表記ゆれ、文のつながりの三項目だけでも十分です。売上を伸ばす文章に直す、法的な問題を判定する、といった広い目的を同時に加えると、何をもって成功とするかが曖昧になります。

候補を選んだら、作業前に困っていることを一文で書きます。「表記の確認漏れを減らしたい」と決まれば、結果を見る基準も表記の指摘に絞れます。自動化の範囲を広げるのは、その小さな作業が安定してからで構いません。

スキルを入れただけでは品質は保証されない

スキルは指示を再利用する仕組みなので、書いた手順が曖昧なら、返ってくる結果も揺れます。「分かりやすくする」だけでは、短くするのか、専門語を説明するのか、見出しを加えるのかが決まりません。確認する観点を具体化し、判断できない場合の扱いまで書いておきます。

AIが出した修正案には、原文の意味を変えてしまうものも混ざり得ます。文章が自然になったかだけでなく、数字、日付、商品名、条件が保持されているかも確認します。事実確認に必要な資料を渡していない場合、正誤の判定まで任せない設計にします。

公開リポジトリの人気や投稿の反応数は、探すきっかけにはなりますが、自分の仕事での精度を示す値ではありません。Anthropicもスキルの評価を重視しています。導入数よりも、試した入力と期待する結果を残すことが運用の基礎になります。[6]

スキルを作る前に環境と利用料金を確認する

日本語で使う環境と対象範囲

Claudeの日本語公式ヘルプでは、日本がアクセス可能な地域に含まれています。Claude Codeについても、日本語の公式ドキュメントでターミナル、IDE、デスクトップなどの利用方法が案内されています。ここでは、ローカルのファイルを扱うターミナル版を中心に説明します。[7][8]

スキルの説明や手順は、日本語の文章で設計できます。一方で、ファイル名の SKILL.md や設定項目の name、description などは定められた表記を使います。自然言語で書く部分と、決まった文字列の部分を分けると、書式の間違いを減らせます。

すでにClaude Codeを使っている場合は、いま作業しているフォルダと利用環境を確認します。ブラウザのClaudeで文章を送れる状態と、ローカルのClaude Codeでファイルを読める状態は同じではありません。保存先の例は、実際にClaude Codeを動かしているパソコンの中に作ります。

Claude Codeの利用料と外部サービス料金を分ける

2026年10月28日に確認した日本語料金ページでは、個人向けProは月払い20米ドル、年払いは年間200米ドルです。Maxは月額100米ドルからと案内され、表示価格には該当する税金が含まれていません。ProとMaxにはClaude Codeの利用が含まれますが、使用量の上限はあります。[9]

無料で配布されたスキルでも、Claude Codeを動かす利用枠が無制限になるわけではありません。さらに、手順の中で画像生成や外部APIを呼ぶ場合、そのサービス側の料金や契約が関係します。ファイルの入手価格、AIの利用料、外部ツールの料金を別々に確認します。

確認する費用	見る場所	確認したいこと
スキルの配布条件	配布元の案内	無料配布か、別契約があるか
Claude Codeの利用	ログイン先と契約プラン	利用枠と上限、追加利用の設定
連携サービスの利用	接続先の料金ページ	別料金やクレジットが必要か

サブスクリプションで使うつもりでも、APIキーによる認証が有効なら請求経路が変わる場合があります。公式ヘルプの認証・請求の説明を確認し、上限に達したときに追加料金へ切り替えるかは事前に決めておきます。[10]

個人用とプロジェクト用の保存先を選ぶ

複数の仕事で自分だけが使う手順は個人用、そのプロジェクトの資料やルールと一緒に使う手順はプロジェクト用に置くと管理しやすくなります。たとえば個人の文章整理には個人用、特定サイトの記事チェックにはプロジェクト用が適しています。

ローカルでの基本的な配置は、個人用が ~/.claude/skills/<名前>/SKILL.md、プロジェクト用が .claude/skills/<名前>/SKILL.md です。チルダの ~ はホームディレクトリを表し、.claude はプロジェクトのルートに作る設定フォルダです。先頭に / や ~ のないパスは、そのプロジェクトを起点として読みます。[11]

保存先を決める前に、誰が使い、誰が更新するのかを考えます。共有フォルダに置いたつもりでも、個人用の設定だけに保存していれば、同僚の環境には反映されません。反対に、個人的な好みをプロジェクト共通の手順に混ぜると、他の利用者の仕事に影響します。

練習用のファイルと期待する結果を用意する

本番の資料を直す前に、短い練習用の文章を一つ用意します。たとえば架空の商品の紹介文に、同じ商品の名前が二通りで書かれている箇所を入れます。その文章を渡したときに、二つの表記を並べて指摘することを期待する結果にします。

入力だけでなく、何をしてほしくないかも具体化します。この例では原文のファイルを上書きせず、指摘と修正候補を返すところまでにします。手順を試すために、外部への送信、公開、追加サービスの契約を組み込む必要はありません。

練習用の資料には、顧客名や実際の問い合わせ内容を使わず、用途が分かる架空の文章を使えます。資料を短くしておけば、AIが読んだ範囲と指摘箇所を人が照合しやすくなります。まずは少量で手順の形を確かめ、扱う量を増やしてから再確認します。

SKILL.mdを作成する手順

フォルダとSKILL.mdを作る

文章チェック用なら、check-copy のように用途を連想できる名前のフォルダを用意します。プロジェクト用の場合は、その中に SKILL.md を保存します。名前の似た別ファイルを作らないよう、拡張子まで表示した状態で確認すると確実です。

次の構成は、手順ファイル一つから始める最小限の例です。エディターのファイル作成機能で作れます。普段ターミナルを使っている場合は、プロジェクトのルートで mkdir -p .claude/skills/check-copy を実行してフォルダを用意する方法もあります。

プロジェクト/
└── .claude/
    └── skills/
        └── check-copy/
            └── SKILL.md

Agent Skillsの仕様では、スキルは最低限SKILL.mdを持つディレクトリとして定義されています。スクリプトや参考資料のフォルダは必要に応じて追加するものなので、最初から空のフォルダを大量に作る必要はありません。[12]

名前とdescriptionに用途を明記する

ファイルの冒頭には、ハイフン三つで囲んだ設定欄を置きます。ここにスキルの名前と、何をするためのものかを書きます。名前は check-copy のように短くし、説明は「日本語の商品紹介文を読み、表記ゆれと説明不足の候補を整理する」のように対象と作業が分かる文にします。

description に「高品質な成果を出す万能アシスタント」とだけ書いても、使う場面を区別しにくくなります。「記事」「問い合わせ返信」「議事録」などの対象と、「確認する」「要約する」「分類する」などの動作を組み合わせると、他のスキルとの違いが表れます。

公開仕様に合わせて名前を付けるなら、小文字の英字、数字、ハイフンを使う形が基本です。人が入力するときにも区別できる名前にして、似た用途のスキルが増えたら説明を比較します。名前と説明の設計が重複していれば、手順を統合するか、対象を絞る余地があります。[12]

入力・確認手順・出力形式を本文に書く

設定欄の後には、実際に進める作業を書きます。「対象を読む」「確認観点に沿って探す」「結果を決めた形式で返す」のように、最初と最後が分かる順番にします。途中で資料が足りない場合の扱いも入れると、想像で埋めた結果を減らすための指示になります。

文章チェックなら、入力は対象ファイル、観点は表記ゆれと説明不足、出力は原文・理由・修正候補の表と決められます。修正理由が書かれていれば、利用者は採用するかを判断できます。単に修正版だけを返す手順より、変更の意味をたどりやすくなります。

重要なのは、理想の性格を長く説明するより、判断に必要な条件を書くことです。「厳しく丁寧に正確に」と重ねる代わりに、「元の数字は変えない」「判断材料がない箇所は確認が必要と記す」と書きます。これらは文章チェックという用途に合わせた設計例であり、他の仕事では観点を置き換えます。

コピーして試せる文章チェックの例

次の内容を .claude/skills/check-copy/SKILL.md に保存すると、文章の指摘を整理するスキルの例になります。手動で呼び出して試すため、disable-model-invocation: true を指定しています。原文を直す作業と指摘を出す作業を分け、初回の結果を確認しやすくした構成です。[11]

---
name: check-copy
description: 日本語の商品紹介文や記事を読み、表記ゆれと説明不足の候補を整理する。
disable-model-invocation: true
---

# 対象
指定されたファイル: $ARGUMENTS

# 手順
1. 指定された文章を読む。対象が未指定、存在しない、読めない場合は、その状況を伝えて終了する。
2. 同じ名称の表記ゆれ、意味のつながりが分かりにくい箇所、説明が足りない箇所を確認する。
3. 原文の数字・日付・固有名詞を勝手に補わない。事実確認の資料がない場合は正誤を断定しない。
4. 原文は上書きせず、指摘と修正候補を返す。

# 出力
- 対象のファイル名と、確認できた範囲
- 表: 原文の箇所 / 気になる理由 / 修正候補
- 指摘がなければ、その旨を記す
- 追加確認が必要な事実は、修正候補と分けて記す

この例は特定のサービスを呼ばず、文章を確認するための指示に絞っています。練習用の sample.md には、架空の商品名を二通りで書いた短文を保存し、どの表記が違うかを報告できるか確かめます。入力が長い場合やファイル形式が違う場合には、実際に読めた範囲を結果で確かめます。保存しただけで、すべての文章を漏れなく確認できると判断しないことが大切です。

参考資料を別ファイルに分ける

自社の表記ルールが増えたら、SKILL.mdの中に全部貼り込む代わりに、参考ファイルとして分ける方法があります。たとえば references/style-guide.md に商品名の正式表記を置き、手順側に「表記確認時はこの資料を参照する」と記します。

資料を分ける目的は、ファイルを細かくすることではなく、更新箇所を分かりやすくすることです。手順を変えたいときはSKILL.mdを、名称が変わったときは表記資料を直せます。担当者が違う場合も、確認すべき範囲を分担しやすくなります。

ただし、ファイルを置いただけで常に参照されるとは考えません。どの場面で何を読むかを手順に書き、実際の出力で参照されたかを確認します。参照先を何段にも重ねず、主要な資料に直接たどり着ける形にすると、手順を人が見直すときにも役立ちます。

スキルを呼び出して結果を確かめる

スラッシュコマンドで手動実行する

スキルを保存したら、そのプロジェクトをClaude Codeで開き、入力欄の先頭に /check-copy を入力します。ターミナルのシェルに打つコマンドではなく、Claude Codeの会話へ送る指定です。最初は自動判定に任せず、名前を指定して呼び出せるかを確かめると、配置の問題を切り分けやすくなります。[11]

まだ対象を渡していない場合、先ほどの例は対象の指定が必要だと伝えて終了する設計です。ここで別のファイルを探し始めるなら、入力がない場合の手順が十分に伝わっていない可能性があります。望ましい動作を一つずつ確認してから、実際の対象を渡します。

初回の結果では、出力の見た目よりも、どの手順が使われたかを見ます。対象を読まずに一般論だけを返したり、原文の上書きを始めたりしたら、そのまま次の仕事へ進めません。対象、作業、出力を短く指定した理由は、こうした違いを早い段階で見つけるためです。

引数で対象ファイルを渡す

同じ手順で別の資料を扱いたいときは、スキル名の後ろに対象を書きます。たとえばプロジェクト内の sample.md を確認するなら、Claude Codeの会話で次のように指定します。先ほどの例の $ARGUMENTS は、この後ろに書いた内容を受け取るための記述です。[11]

/check-copy sample.md

ファイルの場所が曖昧にならないよう、最初の練習ではプロジェクト内に置き、短い名前を使うと確認しやすくなります。複数の同名ファイルがある場合は、drafts/sample.md のようにフォルダも含めます。呼び出しのたびに対象を明示すれば、前の会話で扱った資料との混同を見つけやすくなります。

対象を渡したら、結果に表示されたファイル名と確認範囲を照合します。「ファイル全体を確認した」という説明があっても、重要な後半部分に触れていない場合は、その箇所を指定して確認を求めます。引数は入力を渡すための手段であり、内容が最後まで正しく読まれた証拠とは分けて扱います。

自動呼び出しを使う場面を選ぶ

手動実行で意図した結果が得られるようになってから、自動で使わせるかを考えます。スキルは説明と依頼内容が合うときにClaudeが選ぶ使い方もできますが、先ほどの例は自動呼び出しを抑える設定です。毎回自分で実行のタイミングを選びたい仕事なら、そのまま使う形で構いません。[11]

自動呼び出しを試す場合は、設定を見直したうえで、「この商品紹介文の表記を確認して」のような普段の依頼を使います。手動で名前を呼べることと、自然な依頼から適切なスキルが選ばれることは、別の確認項目です。両方を試すことで、手順の内容と説明の問題を分けられます。

共有先への送信や公開のように、結果を確認してから実行したい仕事では、呼び出す条件を広くしすぎないほうが扱いやすくなります。便利さを評価するときも、単に確認の回数が減ったかではなく、必要な判断を利用者が行えるかを見ます。

正常・不足・対象外の三つを試す

検証には、うまく進む入力だけでなく、情報が欠けた入力と、対象外の入力も用意します。文章チェックなら、表記ゆれのある短文、存在しないファイル名、文章以外の資料という三種類から始められます。処理できないときに状況を伝えて止まることも、手順の大切な成果です。

試す入力	期待する動作	確認する点
表記ゆれを含む短文	該当箇所と理由を返す	原文にない問題を作っていないか
対象ファイルの指定なし	対象の指定を求める	無関係なファイルを選ばないか
読めない形式や対象外の資料	扱えない範囲を伝える	読んだふりをしていないか
問題を入れていない文章	指摘なし、または確認範囲を返す	無理に修正案を増やさないか

この表は検証の設計例です。初回からすべて満たすと保証するものではありません。期待と違った箇所を記録して、説明文、本文の手順、入力資料のどこを直すべきかを考えます。

結果から指示を一つずつ直す

結果が期待と違ったら、気になる点をまとめて書き足すより、一つの原因から直します。たとえば商品名を一般名詞に置き換えてしまったなら、「固有名詞は、参照資料と不一致がある場合だけ修正候補を出す」と条件を具体化します。その変更後に、同じ入力をもう一度試します。

同じ入力を残しておくのは、改善したかを比較するためです。毎回別の文章を使うと、手順の改善なのか、入力が簡単だっただけなのかが分かりません。確認項目を表にしておくと、以前できていたことができなくなった場合にも気付けます。

修正を重ねると禁止事項ばかり長くなることがあります。そのときは、禁止の羅列を増やす前に、望ましい出力を一例示します。「直してはいけないもの」を説明するだけでなく、「どう報告すればよいか」を見せると、人が手順を読む場合にも判断がそろいやすくなります。

公開されているスキルを選んで導入する

配布元のREADMEとスキル本体を読む

公開スキルを探す場合は、紹介投稿から配布元へ進み、作者が説明している用途と必要な環境を確認します。2026年10月25日の日本語投稿では、Claude Code向けの複数のリポジトリが紹介されていました。その中のclaude-code-best-practiceは、作者のREADMEでもスキルや周辺機能の使い分けを扱っています。[13]

ただし、紹介者の「入れるべき」という評価と、公式に確かめられる機能は分けます。人気の一覧に載っていても、自分の作業に必要な機能が含まれるとは限りません。READMEを読んだ後、実際のSKILL.mdにどの作業が書かれているかまで確認します。

配布物を選ぶときは、「自分の資料を入力にできるか」「欲しい出力があるか」「結果を確認する方法があるか」の三点で比較すると実務に結び付きます。使い道が決まっていないまま導入数を増やすと、似た手順の違いを把握する時間が増えてしまいます。

依存ツール・外部送信・ライセンスを確認する

スキルの文章だけで完結するものもあれば、プログラムを動かすもの、外部サービスに接続するものもあります。導入前に、同梱ファイルと参照先を読み、必要なツールが何かを確かめます。手順に書かれた準備が済んでいなければ、SKILL.mdを置くだけでは動作しません。

Anthropicの公式リポジトリでも、資料作成などを含むAgent Skillsが公開されています。公式の配布物という出所と、手元の用途に適しているかという判断は別です。個別の説明や利用条件を読み、業務資料を渡す場合は接続先と処理内容を確認します。[14]

確認する項目は、次のように一枚にまとめられます。ここで不明点が残る場合は、導入後に試行錯誤する前に、配布元の説明で解消します。

確認項目	見る対象	残しておく内容
配布元	作者・組織・公開ページ	取得したURL
処理内容	SKILL.mdと同梱プログラム	入力と出力、実行する処理
依存関係	READMEや設定例	必要なソフトと対応環境
外部接続	API・MCP・送信先の記述	どこへ何を渡すか
利用条件	ライセンスや契約条件	利用・改変・再配布の条件

個別フォルダとプラグインの導入を分ける

配布物が単独のスキルフォルダなら、内容を確認して、選んだ保存先にフォルダごと置く方法があります。SKILL.mdだけを抜き出すと、参照資料やスクリプトが不足する場合があります。配布元が示す構成を保ち、読み込めた後に必要なファイルを照合します。

プラグインは、スキルに加えてエージェント、Hooks、MCPなどをまとめて配布する仕組みです。単独のスキルの配置と、プラグインのインストールは同じ作業ではありません。目的のスキル以外に何が追加されるかも確認する必要があります。[15]

Claude Codeのターミナルでは、/plugin から候補を見て、詳細と導入範囲を確認できます。公式の案内には、自分のすべてのプロジェクト、このリポジトリの共同作業者、自分だけがこのリポジトリで使う範囲の違いが説明されています。使う人と場所を決めてから導入します。[16]

自社の資料や表記に合わせて調整する

公開スキルを利用する場合も、会社ごとの名称や資料の構成までは一致しないことがあります。たとえば一般的な記事チェックに、自社では使わない見出し形式が含まれているかもしれません。採用したい手順と、自社の事情に合わせる部分を分けて読みます。

調整は、目的の変わらない範囲から始めます。出力する表の列名を業務で使う言葉にする、参照する表記資料を指定する、確認が必要な箇所を別欄にする、といった変更です。手順の中心を大きく変えた場合は、配布元の動作説明をそのまま自分の環境の保証として扱えません。

元の配布物を更新すると、自分で加えた条件と食い違う場合があります。変更点を短く記録し、更新前後に同じ練習用ファイルを試します。「便利だった」という感想だけでなく、どの入力でどの出力が得られたかを残すと、引き継ぐ人も判断できます。

動画やアバター制作へ用途を広げる

文章チェックのような小さな手順で仕組みを理解すると、複数のツールを使う制作にも応用しやすくなります。たとえば動画では、台本、素材、映像、音声、書き出し後の確認という段階があります。それぞれの入力と成果物を分けておくと、どこで止まったかが分かります。

具体的な組み合わせは、Claudeで動画を作る方法の比較で整理しています。コードで映像を組み立てる例を知りたい場合は、Claude CodeとHyperFramesを組み合わせる仕組みも参考になります。ツールの役割を理解したうえで、繰り返す手順をスキルにまとめます。

3Dアバターを目的にするなら、きゃらくるをClaude CodeやCodexで使う準備と手順のように、制作対象が明確な例から確認できます。どの用途でも、スキル自体が映像や3Dデータを直接作る能力を保証するわけではなく、使う道具と確認工程が必要です。

スキルが動かないときの確認と運用

一覧に出ない場合は配置と名前を見る

動かないときは、まず「見つかっていない」のか「見つかったが実行できない」のかを分けます。スキルの一覧に出ないなら、プロジェクトの場所、フォルダ名、SKILL.mdの名前を先に確認します。別のプロジェクトに置いたファイルを、いま開いている作業で探していないかも見直します。

ファイルの拡張子が非表示の場合、見た目はSKILL.mdでも、実際には末尾に .txt が付いていることがあります。エディターやファイル一覧で本当の名前を確認します。また、設定欄の前に説明文や空白行を入れず、ファイルの先頭から書式をそろえます。

公式資料では、利用可能なスキルを尋ねることや、名前で直接呼び出すことが確認方法として示されています。配置を直しても認識されない場合は、利用している環境に合う公式のトラブルシューティングを参照します。本文を書き直す前に、対象のスキルが見つかる状態かを確かめます。[11]

自動で選ばれない場合は説明を見直す

名前で呼び出せるのに自然な依頼で選ばれないなら、配置よりも説明や呼び出し設定を確認します。先ほどの文章チェック例は手動実行を前提にしているため、自動で選ばれないこと自体は異常ではありません。試したい動作と設定が一致しているかを先に見ます。

自動で使わせる設計なら、依頼で使う言葉が説明に含まれているかを確認します。「文章を確認して」という依頼に対し、説明が「商品紹介文の名称と説明不足を確認する」となっていれば、対象を明示して依頼するほうが意図を伝えやすくなります。

ただし、選ばれるようにするために対象を広げすぎると、関係のない仕事でも使われる可能性を考える必要があります。説明は広告文ではなく、使う場面を区別するための情報です。似たスキルが複数ある場合は、どちらの説明も並べて読み、対象の違いが分かるようにします。

呼び出されても結果が違う場合は入力を確認する

スキルが実行されたのに結果が合わない場合、手順だけでなく入力も確認します。対象ファイルの指定が違う、必要な資料が足りない、前提にしていた表記ルールが古い、といった原因があります。期待する結果を決めたときの入力と、実際に渡したものを比べます。

たとえば「商品名を統一する」という手順に対して、正式名称がどこにも書かれていなければ、どちらへそろえるかは決まりません。この場合は指示を強くするより、正式名称を示す資料を渡すほうが問題に直接対応できます。判断できない場合に確認を求める手順も残します。

出力が毎回違うときは、まず表の列や必須項目など、形の違いと内容の違いを分けます。形が違うなら出力例、内容が違うなら観点や参照資料を見直します。一つの原因に絞って試すと、手順を直した理由を後から説明できます。

権限エラーをスキルの文章だけで解決しない

ファイルへのアクセスやツールの実行が拒否された場合、それは文章の説明不足とは別の問題です。スキル本文に「必ず実行する」と加えても、環境の権限設定や組織の制約を置き換えることはできません。エラーに書かれた対象と、必要な作業の範囲を確認します。[17]

読み取りだけの仕事なのに不要な外部接続を要求するなら、その接続が本当に必要かを手順から見直します。逆に、外部サービスから情報を取る仕事なら、正しい接続先で認証されているかを確認します。目的に必要な操作を具体化することで、権限の問題を分けて考えられます。

権限をまとめて広げる前に、読みたいファイル、実行したい処理、接続したい先を確認します。業務で共有するスキルでは、使えない場合の連絡先や確認項目も書いておくと、利用者ごとに異なる回避策を加える状況を減らせます。

更新担当と検証例を残す

スキルを日常業務に組み込んだら、作った人だけが分かる状態を避けます。保存場所、目的、入力例、期待する結果、最終確認日を短いメモに残します。手順の変更を判断する担当者も決めておくと、誰が修正してよいかが明確になります。

変更のきっかけは、Claude Codeの更新だけではありません。商品名、記事の表記ルール、出力先の形式が変わったときも見直しが必要です。使わなくなった作業のスキルが残っていると、利用者が古い手順を選ぶ原因になるため、定期的に一覧を確認します。

運用記録は大掛かりな台帳でなくても構いません。次のように、同じ入力を再確認できる程度の項目があると、更新前後の違いを追いやすくなります。

記録する項目	文章チェックの場合の例
目的	商品紹介文の表記確認
対象	公開前の日本語Markdown原稿
検証例	表記ゆれあり・なし・対象未指定
更新理由	商品名の表記ルール変更
確認結果	期待した指摘が出るかを確認
担当と日付	確認した人と最終確認日

よくある質問

日本語だけでスキルを書けますか

説明や作業手順は日本語で書けます。ただし、ファイル名や設定項目は定められた表記を使います。文章チェックの例なら、name や description のキーはそのままにし、説明の値や手順を日本語にする形です。

日本語だから曖昧になるのではなく、対象や成果物を省略すると判断が分かれます。「文章を良くする」よりも、「表記ゆれを原文・理由・修正候補の表にする」と書くと、期待する作業が伝わります。

無料で使えますか

スキルファイルが無料で公開されていても、Claude Codeの利用条件は別です。2026年10月28日に確認した個人向け料金表では、Claude CodeはProとMaxに含まれ、Freeには含まれていません。外部サービスを呼ぶスキルでは、その料金も確認します。[9]

「無料スキル」と「費用なしで最後まで実行できる」は同じ意味ではありません。新しい手順を導入する際は、配布条件と利用するサービスを分けて見ると、想定外の費用を避けやすくなります。

ClaudeとClaude Codeでそのまま共有できますか

共通のスキル形式を利用していても、読み込む場所や利用できるツールは環境によって違います。ローカルのClaude Codeで使うファイルパスやコマンドが、別の環境でもそのまま通るとは限りません。移す場合は、その環境の導入方法と依存関係を確認します。[1][12]

たとえばパソコン内のファイルを読む手順は、別の環境から同じ場所を参照できるかを確かめる必要があります。文章だけの確認手順と、ローカルのプログラムを動かす手順では、持ち運ぶときの条件が異なります。

スキルはいくつ入れればよいですか

必要な数は仕事内容で変わりますが、最初は一つの繰り返し作業から試すと管理しやすくなります。同じ用途のスキルを複数入れる前に、違いを説明できるかを確認します。使い分けが曖昧なら、増やすより説明や手順を整理する余地があります。

判断の基準は数ではなく、いつ使い、何が返り、結果をどう確認するかが分かることです。日常業務で繰り返し使えた手順から残し、使わないものは整理すると、一覧も選びやすくなります。

まとめ：一つの作業を保存して確かめる

Claude Codeのスキルは、繰り返す指示を、用途・手順・出力形式の分かるファイルとして保存する方法です。最初は文章チェックのように結果を確認しやすい仕事を選び、SKILL.mdを作って、名前を指定して呼び出します。

その後、正常な入力だけでなく、不足や対象外の入力も試します。配布スキルを使う場合は、作者の説明と中身を読み、依存ツールや利用条件を確認します。日々の仕事で使う手順が一つ安定してから、必要な用途へ広げていくと運用しやすくなります。