CLAUDE.mdとskillsの違い——長い手順書を「いつ使うか」で分けてみる
CLAUDE.mdが長くなってきたので、半分をskillsへ移したい。そんなとき、文字数だけで切り分けようとしていませんか。
先に考えたいのは、その指示は、どの仕事のときに必要なのかです。
CLAUDE.mdとskillsの違いを、社内FAQの下書きを作る架空の業務で整理します。「共通の約束」「特定作業の手順」「今回だけ渡す資料」を分けると、移す内容だけでなく、残す内容も見えてきます。
CLAUDE.mdとskillsの違いは、読むタイミングに表れる
CLAUDE.mdは、プロジェクトについて継続的に伝える指示の置き場所です。対してskillsは、特定の知識や仕事の手順を、必要なときに使うための仕組みとして用意されています。
公式の説明では、スキルの概要が呼び出し判断に使われ、本文全体はスキルが使われるときに読み込まれます。手順の全文を、常にCLAUDE.mdへ置いておく必要はありません。
出典はAnthropic公式「Extend Claude with skills」と、CLAUDE.mdの公式説明です。2026年9月8日に本文を確認しました。
ただし、「長い文章なら何でもskillsへ移せばよい」という単純な話でもありません。必要な場面でそのスキルが選ばれなければ、移した内容は期待した形で届かないからです。
分ける基準は長さだけでなく、必要になる条件。
全ての仕事で必要なルールなのか、FAQの下書きを作るときだけ必要なのか。最初にこの質問へ答えると、ファイルの名前を考える前に構成を決められます。
架空のFAQ作成で、CLAUDE.mdとskillsを分けてみる
ここでは、担当者が元資料を渡し、Claude Codeに社内FAQの下書きを頼む例を使います。実際の社内導入や改善効果を報告するものではありません。
元の指示書には、表記ルール、FAQの作り方、今月の製品情報、公開する際の注意まで、一続きで書いてあったとしましょう。
まず、その内容に三つの札を付けます。
共通の約束：他の成果物でも守る表記や、不明点の扱い。
作業の手順：FAQを作るときに必要な、抽出・整理・照合の流れ。
今回の入力：対象製品、対象期間、読む資料、作成する件数など。
これは本記事の整理法です。共通・手順・入力を分けてから、置き場所を決める順にします。
たとえば、「元資料にない仕様を補わない」は共通の約束にできます。「質問の候補を抽出し、似た質問をまとめ、回答に出典を付ける」はFAQ固有の手順です。
今月の製品名やキャンペーン期間は、毎回変わる入力に当たります。これをスキル本体へ埋め込むと、次の依頼で古い条件を使わないよう保守が必要になるでしょう。
分割のために、全文を複数の場所へ複写する必要はありません。同じ条件を残すなら、どちらが正しいかを更新のたびに確認する負担も生まれます。
共通の約束を残し、作業の手順を切り出す。
この例では、それを最初の編集方針にします。
CLAUDE.mdには、FAQ以外でも守る約束を残す
CLAUDE.md側に残す内容は、FAQの下書きに限らず必要になるものから考えます。
「確認できない内容は未確認と書く」「出典を示すときは元資料を特定できる形にする」。こうした約束は、案内文や比較メモにも必要でしょうか。
一方、「質問を利用場面別に並べる」「回答の後に補足を置く」は、FAQという成果物の設計です。他の仕事まで毎回その型にする必要があるかを考えてみてください。
全ての仕事へ配る条件だけを、共通部分へ残す。
公式のCLAUDE.md説明も、毎回必要なプロジェクト情報と、タスク固有の複数段階の手順を分ける考え方を案内しています。出典は公式のCLAUDE.md文書です。
この切り分けでは、共通部分から削った文が全て不要になるわけではありません。必要な仕事に届く場所へ移すことが目的です。
もし「この約束はFAQだけか、全体か」が決まらなければ、いきなり移さず、担当者間で使い道を確認する余地があります。文章の担当と業務の担当が違う場合ほど、この確認が大切です。
また、送信の権限や操作の制限まで、文章の分割だけで解決したとは考えません。指示文を読みやすくすることと、実際の操作範囲を制御することは別に扱います。
skillsには「入力と成果物」を定める
FAQ用のスキルを作るなら、見出しだけの短い手順にする前に、入口と出口を言葉にします。
入口は、担当者が指定した元資料と対象範囲。出口は、出典をたどれるFAQの下書きです。公開や配信は、この例の仕事には含めません。
入力と完成条件を先に決めると、手順の不足を見つけやすくなります。
たとえば、説明用の手順は次のように組めます。
指定資料を確認し、対象の製品と期間が分かるかを確かめる。
資料から答えられる質問候補を作り、重複を整理する。
回答の下書きに出典を添え、資料だけでは答えられない質問を分ける。
完成した下書きと未確認の点を返す。公開はしない。
これは業務を説明するための手順案で、実行済みのスキルや、検証済みの完成コードではありません。
順番の理由もあります。資料の対象が不明なまま質問を作ると、違う時期の内容を混ぜる可能性があるため、先に入力を確認する。答えが見つからない質問は、文章で埋めずに別枠へ出す設計です。
答えを作る手順だけでなく、作れない場合の出口も用意する。
担当者は、未確認の一覧を見て追加資料を渡すか、FAQの対象から外すかを判断できます。手順を細かくするより、判断が必要になる場所を見えるようにすることが狙いです。
CLAUDE.mdとskillsの違いを、呼び出す人でも確かめる
スキルには、Claudeが関連性を判断して使う方法と、人が名前を指定して使う方法があります。どちらを想定するかも、手順を分けるときの設計項目です。
公式は、スキルのdescriptionに、何をするかと、いつ使うかを書くよう案内しています。「便利な作業」という広い言葉から、対象の仕事を読み取れる説明へ絞る。
説明文は、手順の要約であると同時に、選ぶための入口。
FAQの例なら、「指定資料から社内FAQの下書きを作る。質問候補の整理や回答の出典確認を依頼されたときに使う」といった説明が考えられます。これは本記事の作例です。
一方、担当者が開始を明示したい仕事には、手動で呼び出す設計もあります。公式ではdisable-model-invocation: trueを設定すると、Claudeによる自動呼び出しを止め、人が/名前で呼び出す用途にできます。
出典は公式skills文書の呼び出し制御です。この設定を、処理中の全ての操作に対する承認や、外部送信の遮断と同じ意味にはしません。
誰が開始するかと、開始後に何ができるかは別の設計です。
最初の試行で担当者が入力を確認してから依頼したいなら、手動呼び出しを選ぶ理由になります。自動で使う場合でも、対象外の仕事まで呼び出されないかを点検する余地があります。
分けた後は「呼ばれたか」と「使えるか」を別々に見る
ファイルを分割しただけでは、確認は終わりません。必要な場面で使われることと、使った結果が役立つことを分けて見ます。
まず、スキルを使うつもりの依頼を試す。続いて、似ているけれど対象外の依頼も考えてみる方法があります。FAQを作る依頼と、既存FAQの一文だけを校正する依頼は、必要な手順が同じとは限りません。
対象の例と、対象外の例を一つずつ持つ。
これなら、「いつ使うか」という説明が広過ぎないかを点検できます。ただし、一度の試行だけで、その後の全ての呼び出しが保証されるとは考えません。
次に、出力を見ます。元資料を示せているか、質問の重複を整理できているか、分からないことが分けられているか。長い手順を読んだことと、使える下書きができたことは同じではありません。
結果が合わない場合も、CLAUDE.mdへ手順を戻すと即決する必要はありません。入力が足りないのか、スキルの説明が曖昧なのか、本文の完成条件が足りないのかを一つずつ見る方法があります。
分割の合否は、短くなった字数だけでは測らない。
必要な仕事へ必要な指示が届き、担当者が成果物を照合できることを確認しましょう。移した後に更新する担当も決めておけば、手順が古くなったときの直し先も明確になります。
レビューを頼むときは、分割前の全文だけでなく、移した見出しと残した理由も短く添える方法があります。読み手にとって重要なのは、文章が減ったことより、必要な条件が失われていないこと。目的に沿った分割かを、その観点で確かめます。
CLAUDE.mdとskillsは、置き換えではなく役割分担
CLAUDE.mdには、多くの仕事で共通して必要な前提を残す。skillsには、特定の仕事で使う手順を置く。今回だけの資料や条件は、依頼の入力として扱う。
この分け方なら、長い指示書を機械的に切るのではなく、読むタイミングと使う目的を整えられます。
「どこへ移すか」の前に、「いつ必要か」を決める。
手元の指示書から、一つの仕事の手順だけを選んで考えるところから始めてみてください。
▶ 関連記事: CLAUDE.mdの使い方は「置き場所」で半分決まる——読み込まれる順番から逆算する
Claude Codeの実務活用に向けた6大特典
指示や手順を仕事で使える形に整理したい方へ、導入・運用のための6大特典をご用意しています。
