Agent Skillsはどこまで分けるべき?Skillの粒度と分割タイミング
Agent Skillsを作るときは、どこまでを1つのSkillに含めるかが問題になります。記事作成なら、調査、構成、執筆、レビューを別々のSkillにするか、記事完成までを1つにまとめるかで迷います。
初版では、最適な粒度を探すより、実際に動かせる範囲を決めることが先です。 まず「これは1つの仕事・工程だ」と思う範囲でSkillを作り、実際に使ってください。使う中で手順や判断基準が大きく分かれた部分は、分割した方がよいか検討してください。
記事作成全体を一続きの仕事と考えているなら、調査からレビューまでを1つにまとめられます。記事レビューだけを繰り返したいなら、レビューを1つのSkillとして作れます。仕事の捉え方に応じて、初版の範囲は変わります。
この記事では、最初のSkillをどの範囲で作るか、使った後に何をきっかけとして分けるか、別Skillとreferences/・scripts/をどう使い分けるかを説明しています。Skill化する仕事をまだ選んでいない場合は、先にAgent Skillsはどんな仕事に使える?Skill化しやすい仕事と、作り込みが必要な仕事を参照してください。
この記事のまとめ
- 最初は、自分が1つの仕事・工程だと思う範囲でSkillを作る
- 工程数やファイルの長さだけで、Skillを細かく分けない
- モードや条件分岐が増え、それぞれで手順や判断基準が変わるなら分割を検討する
- 単独で使う仕事になった部分や、複数のSkillから同じ方法で使う部分も分割候補になる
- 詳しい知識は
references/、決まった処理はscripts/、テンプレートや素材はassets/へ分ける
1. 最初は「1つの仕事・工程」と思う範囲でSkillを作る
Skillの粒度を考えるときは、最初から正しい境界を探すより、現在1件の仕事として扱っている範囲をSkillにし、実際に使うことを優先してください。
Agent Skills公式のBest Practicesでは、Skillは他のSkillと組み合わせやすい「まとまりのある仕事」として設計する考え方が示されています。範囲が狭すぎると、1つの仕事を進めるために複数のSkillを読み込むことになり、指示が競合する可能性があります。反対に、範囲が広すぎると、どの依頼で使うSkillなのかを正確に判定しにくくなります。
複数工程を1つにまとめた公開Skillもあります。Anthropicの文書共同作成Skillは、情報収集、構成・執筆、読者テストという3段階を、「文書を共同作成する」という1つの仕事にまとめています。
1つの仕事に複数の工程が含まれてもよい
1つのSkillに目的を1つだけ持たせる場合でも、その目的を達成するために複数の工程を含められます。
たとえば記事作成では、次の工程がつながっています。
テーマ整理
↓
調査
↓
記事方針と構成の作成
↓
内容の確認
↓
執筆
↓
レビューと修正
「このテーマで記事を完成させて」という依頼から始まり、調査結果を構成へ引き継ぎ、確認済みの構成から本文を書くなら、全体を1つのSkillとして扱えます。
一方、普段から「完成した記事を受け取り、媒体のルールと編集者の観点でレビューする」という仕事を独立して行っているなら、記事レビューだけで1つのSkillを作れます。
つまり、調査やレビューという工程名だけでは粒度は決まりません。 工程名だけで分けず、1件の仕事としてつながっているかを見てください。
実際に動かすと、分ける場所が見えてくる
机上では一続きに見えた仕事でも、実際に使うと、依頼によって手順の大部分が変わる箇所や、一部だけを単独で使う箇所が見つかります。 作成前に分割箇所を考え続けるより、実際の依頼で使い方が分かれた部分を見直してください。
2. まとめすぎるとモードが増え、分けすぎると同じSkillを順番に使う手間が増える
Skillの範囲が大きすぎる場合も、小さすぎる場合も、実際の依頼で使うと不便さが表れます。 使っていて起きた問題を、粒度を見直す材料にしてください。
まとめすぎると、Skillの中に複数のモードが増える
1つのSkillへ異なる仕事を追加すると、「新規作成」「改善」など仕事を切り替えるためのモードや条件分岐が増えます。
たとえばarticle-workというSkillの中に、次の仕事を入れたとします。
- 新しい記事を企画して執筆する
- 既存記事の検索順位低下を分析して改善する
- 外注記事を媒体ルールに沿ってレビューする
- 記事からSNS投稿を作る
すべて記事に関係する仕事ですが、依頼内容や入力、途中の手順、完成形が異なります。SKILL.mdには「新規記事の場合」「既存記事の場合」「レビューのみの場合」といった分岐が増え、各モードで使わない指示まで同じSkillに含まれます。
Skillのdescriptionには、何をするSkillか、いつ使うかを書いてください。仕事を詰め込むほど説明が広くなり、AIが依頼に合うSkillを選びにくくなります。Agent Skills公式のOverviewでは、nameとdescriptionから関連するSkillを見つけ、依頼に合うSkillのSKILL.mdを読み込む仕組みが説明されています。対象範囲を短く説明できる状態に保つと、使う場面を判断しやすくなります。
「WordPressへ入稿する場合だけ見出し記法を変える」といった小さな条件分岐は、同じ仕事の中で扱えます。 モードごとに別の手順や判断基準が増え、Skillの主要部分が2つ以上に分かれてきたら、分割を考えるサインです。
分けすぎると、いつも同じSkillを順番に使うことになる
反対に、最初から工程ごとにSkillを分けると、1件の仕事を進めるための操作が増えます。
記事作成を次の4つに分けたとします。
seo-research
article-outline
article-writing
article-review
毎回この4つを同じ順番で使うなら、前工程の成果物や前提条件を、次のSkillへ引き継ぐ必要があります。それぞれのSkillに「想定読者」「媒体ルール」「記事の目的」などを重複して書くと、後から一部だけ更新され、ルールが食い違う可能性もあります。
一連の流れを毎回まとめて使う間は、1つのSkillの方が扱いやすくなります。前工程の判断を、そのまま後工程へ引き継げるためです。
分割した後も、ほぼ毎回すべてのSkillを同じ順番で呼んでいるなら、細かく分けすぎた可能性があります。 分割後に使いやすくなったかを、設計の基準にしてください。
3. 分けるか迷ったときは、4つの違いを確認する
「このモードは別Skillにした方がよさそうだ」と感じたら、依頼内容・入力、作業の流れ、完成条件、評価基準を比べてください。 初版を作る前にすべての工程を分類するためではなく、使っていて見つかった分岐を確認するための観点です。
| 確認すること | 同じSkillへ残しやすい | 別Skillを検討しやすい |
|---|---|---|
| 依頼内容・入力 | 同じ依頼と入力から始まる | 異なる依頼や入力から始まる |
| 作業の流れ | 前後の工程がつながっている | 単独で完結する、または手順が大きく異なる |
| 完成条件 | 同じ最終成果を目指す | 成果物や終了条件が異なる |
| 評価基準 | 同じ観点で良し悪しを判断する | 必要な知識や判断基準が異なる |
4項目の違いが多いほど、1つのSkill内でモードを切り替えるより、別Skillにした方が説明と手順を整理しやすくなります。
記事作成と記事改善を比べる
新規の記事作成と既存記事の改善は、どちらも記事を扱います。しかし、実際の仕事は次のように異なります。
| 記事作成 | 記事改善 | |
|---|---|---|
| 依頼内容・入力 | テーマやキーワードから始める | 既存記事と現在の課題から始める |
| 作業の流れ | 調査して方針・構成を作り、本文を書く | 現状を分析し、問題を特定して必要な箇所を直す |
| 完成条件 | 新しい記事が公開できる | 既存記事の課題に対応した修正版ができる |
| 評価基準 | 検索意図へ答え、必要な論点を扱い、独自性があるか | 既存記事の弱点が解消され、残す内容を損ねていないか |
最初は同じ記事作成Skillの「新規作成モード」「改善モード」として試せます。使うたびに手順の大部分が分岐し、参照する資料やレビュー観点も別になるなら、article-creationとarticle-improvementへ分けた方が扱いやすくなります。
共通Skillにするのは、手順と判断基準が同じ場合
複数のSkillでリサーチ工程が必要になったとき、共通のresearch Skillを作りたくなることがあります。しかし、SEO調査、市場調査、技術調査では、優先する情報源や比較軸、調査を終える条件が異なります。
「調べる」という名前だけを共通化すると、Skillの中に「SEOの場合」「市場調査の場合」「技術調査の場合」というモードが増えるだけです。
用途が変わっても同じ手順と判断基準で進められる部分だけを、共通Skillにしてください。 違う部分が多ければ、それぞれのSkill内に調査工程を残した方が分かりやすくなります。
4. モードや分岐が増えたら、Skillの分割を検討する
モードや分岐が増えて粒度を見直すときは、実際に別の仕事として使われている部分から分けてください。 小さな条件分岐は同じSkillへ残せますが、入力・主要な手順・完成形が分かれた状態では、別Skillにすると各手順を短く説明できます。
次の3つの変化が起きたら、分割を検討してください。
別の仕事として使うようになった
同じ対象を扱っていても、依頼内容や進め方が変わった場合です。 最初は1つのSkillで試し、モードごとに必要な資料、確認事項、完成条件が大きく分かれたら分割を検討してください。
一部だけを単独で使う機会が増えた
「記事は書かなくてよいので、検索意図と競合だけ調べてほしい」「本文は修正せず、レビュー結果だけほしい」といった依頼が増えた場合です。
単独利用が増えると、その仕事に必要な入力と完成形も明確になります。 SEO調査なら、対象キーワードを受け取り、検索意図と上位記事の共通点を整理し、必要な論点を一次情報で確認して、記事方針に使える示唆をまとめるところまでを1つのSkillにできます。
単独利用を繰り返し、独立した仕事として手順を整える価値が出たときに分けてください。
複数のSkillに同じ作業が含まれるようになった
記事作成と記事改善の両方で、同じ記事レビューを行っている場合です。
記事の目的と読者を確認し、内容、根拠、構成、媒体ルールを同じ基準でレビューするなら、article-reviewとして独立させると再利用しやすくなります。外注原稿の確認や入稿前チェックでも同じ手順を使えるかもしれません。
ただし、記事作成では読者への説明不足を確認し、記事改善では検索順位低下の原因分析まで行うなど、名前が同じでも判断内容が異なる場合があります。その場合は、共通部分を無理に1つのSkillへ集めず、それぞれの仕事に残してください。
分割の判断で大切なのは、似た名前があるかではなく、独立させても同じ手順と判断基準で使えるかです。

5. 長くなったときは、別Skill・references・scripts・assetsを使い分ける
SKILL.mdが長くなったら、増えた内容の種類に合わせて整理してください。 別の仕事はSkill、同じ仕事で使う知識・処理・素材はSkill内のファイルへ分けてください。
| 増えたもの | 整理する場所 | 記事作成Skillの例 |
|---|---|---|
| 単独で依頼・完結できる仕事 | 別Skill | 記事改善、記事レビュー、SEO調査 |
| 同じ仕事で参照する詳しい知識やルール | references/ | 媒体の文章ルール、SEOのレビュー観点、引用ルール |
| 同じ入力なら同じ結果にしたい処理 | scripts/ | 見出し抽出、リンク確認、画像パス検査 |
| 出力へ使うテンプレートや素材 | assets/ | 記事テンプレート、図版テンプレート |
Agent Skills公式のSpecificationでは、SKILL.mdに中核となる手順を書き、必要に応じて参照資料、実行コード、テンプレートなどを同じSkillへ含められます。詳しい資料をreferences/へ分け、使う工程をSKILL.mdに書くと、すべてのルールをSKILL.mdへ詰め込まずに済みます。
詳しいルールが増えたらreferencesへ移す
記事作成Skillを使う中で、媒体別の表記、引用方法、タイトルの付け方、レビュー項目が増えることがあります。 これらは記事作成とは別の仕事ではなく、記事を作るときに参照する知識です。
この場合はSkillをarticle-writingやtitle-writingへ細かく分割する前に、詳細をreferences/writing-rules.mdやreferences/review-points.mdへ移してください。SKILL.mdには、どの工程でどのファイルを読むかを書いてください。
媒体Aと媒体Bで文章ルールが違う場合も、記事作成の基本フローが同じなら、references/内の媒体別ファイルを読み分けられます。媒体ごとに企画、承認、完成条件まで大きく異なるなら、別Skill化を検討してください。
決まった処理が増えたらscriptsへ移す
文字数の集計、見出し抽出、必須項目や画像パスの確認など、同じ入力に同じ処理を行いたい部分はscripts/へ移せます。 記事内容の良し悪しを判断する手順はSkillの指示として残してください。
scriptsを使う場面、作り方、SKILL.mdからの実行方法は、Agent Skillsでscriptsを使う方法|使う場面・作り方・使い方で詳しく説明しています。
テンプレートや素材はassetsへ置く
記事の完成フォーマット、図版テンプレート、出力に使用するサンプルファイルなどはassets/へ置けます。
記事の種類ごとに見出しテンプレートが違うだけなら、別Skillを作るより、選んだテンプレートを使う分岐で対応できます。テンプレートの違いに加えて、調査方法や評価基準まで変わるようになったときは、別Skillを検討してください。
仕事の流れは1つのまま、必要な知識・処理・素材だけを別ファイルに整理できます。 ファイルを整理しても、Skillの目的と依頼内容は変わりません。
6. 記事作成Skillは、使いながら必要な部分だけ分ける
記事作成Skillの初版では、記事完成までを一続きの仕事としてまとめられます。 使った結果から、分けた方がよい部分だけを独立させてください。
記事作成Skillの初版フォルダは、たとえば次のように構成できます。
article-creation/
├─ SKILL.md
├─ references/
│ ├─ writing-rules.md
│ └─ review-points.md
├─ scripts/
│ └─ validate-article.py
└─ assets/
└─ article-template.md
SKILL.mdには、テーマ整理、調査、方針と構成の作成、確認、執筆、レビュー、修正という中核フローを書いてください。媒体ルールはreferences/、機械的な検査はscripts/、記事の形式はassets/へ整理してください。
このSkillを実際の記事で使うと、次のような変化が出てきます。
| 実際に起きたこと | 対応 |
|---|---|
| 新規作成と既存記事改善で、大部分の手順が分岐する | article-improvementへの分割を検討する |
| SEO調査だけを頼む機会が増えた | 単独で完結するならseo-researchを検討する |
| 外注記事や既存記事でも同じレビューを使うようになった | 同じ判断基準で使えるならarticle-reviewを検討する |
| 媒体別の細かな文章ルールが増えた | references/へ整理する |
| 毎回同じ検査コードをAIが作っている | scripts/へ固定する |
| 記事タイプごとのテンプレートが増えた | assets/へ整理する |
分割するときは、次の流れで必要な部分だけを見直してください。
- まず、1つの仕事・工程だと思う範囲でSkillを作って使ってください。
- 使う中で増えたモード、条件分岐、単独利用を見つけてください。
- 分割候補の手順、判断基準、成果物が独立しているか確認してください。
- 仕事なら別Skill、知識なら
references/、決まった処理ならscripts/、素材ならassets/へ整理してください。 - 別Skillにした場合は、それぞれのdescriptionで「何をするか」「いつ使うか」を短く示してください。
専用の管理表や細かな点数付けを用意する前に、SKILL.mdの中で大きなモードが並んでいる箇所や、実際の依頼で一部だけを繰り返し使っている箇所を分割候補にしてください。
分割後も毎回すべてのSkillを同じ順番で使うなら、分ける前の方が扱いやすかった可能性があります。 その場合は、再び1つにまとめる選択もできます。Agent Skillsの設計は、最初に固定するものではなく、実際の使い方に合わせて変えていくものです。
Skillの作成方法やSKILL.mdの基本構造は、Agent Skills(SKILL.md)の作り方ガイドを参照してください。実務で見つかった分岐や不足をSkillへ反映する方法は、Agent Skillsをどう改善する?実務のフィードバックからSkillを育てる方法で詳しく説明しています。
まとめ:まず作り、モードや分岐が見えたところから分ける
Agent Skillsの粒度は、実際の仕事で使いながら整えられます。 まず「これは1つの仕事・工程だ」と思う範囲でSkillを作り、実際の仕事で使ってください。
使う中で、手順や判断基準が大きく分かれた場合や、一部だけを単独で使う機会が増えた場合に分割を検討してください。毎回同じ工程を一続きで使うなら、1つのSkillへ残してください。
詳しいルールはreferences/、同じ機械処理はscripts/、テンプレートや素材はassets/へ整理できます。 最初から粒度を考えすぎず、実際に使って見つかった違いから必要な部分だけを分けてください。