AIエージェントのスキル設計を思いつきで進めると、似た用途のスキルが増えて発火が割れます。本記事は、何をスキルにするかの線引きとSKILL.mdの構成要素を整理します。あわせて、59本運用(.agents/skills、2026-07-28時点)で固まった命名と分割の型、導入後の棚卸しも、公式ドキュメントと自社実例でまとめます。

01結論:AIエージェントのスキル設計は、線引き→構成→命名/分割→棚卸しの4層で固まる

Agent Skillsは、Anthropicが開発しオープン標準として公開した仕様で、フォルダ1つにSKILL.mdを置く構成です。metadata(nameとdescription)と本文、任意のscripts・references・assetsを持ちます(出典: Agent Skills公式仕様)。この標準は、Claude Code以外にも複数のエージェント製品が採用しています。例としてCursor・GitHub Copilot・Gemini CLIが挙げられます(出典: Agent Skills公式仕様)。

WEBMARKSは.agents/skills配下に2026-07-28時点で59本のスキルを運用しています。本数が増えるほど、勘だけの命名では衝突と誤発火が増えます。結論は3点です。

  1. 何をスキルにするかは、繰り返す手順か、その場限りの事実かで線を引きます。
  2. SKILL.mdの構成要素は、name・description・本文・参照ファイルの4つに分かれ、発火の判断に使われるのはdescriptionだけです。
  3. 命名と分割の型は運用の中で固まるもので、最初に正解を決め切る必要はありません。ただし棚卸しは仕組みとして先に組み込みます。

スキルはAIエージェントに手順を持たせる手段の1つです。エージェントそのものの条件は『AIエージェントとは|そう呼べる3条件と、呼べない境界』で扱っています。本記事は、条件②「手順を自分で組む」を支える設計だけに絞ります。

AIエージェントのスキル設計は、どの4段階を回ると固まるのか AIエージェントのスキル設計が固まるまでの循環図。①何をスキルにするかの線引き→②SKILL.mdの構成要素を決める→③命名と分割の型を選ぶ→④棚卸しで見直すの4段階を時計回りにたどり、④から①へ戻る矢印で輪になる。各箱には運用して初めて分かった気づきを添える。③の命名の段だけは「発火が割れる」という失敗時に外側へそれる分岐線を持ち、その矢印は④の棚卸しへ合流して通常の循環に戻る。 CYCLE スキル設計が固まる4段階サイクル =通常の流れ =発火が割れた時 ①線引き同じ説明を繰り返して気づく ②構成を決める説明文だけで発火が決まる ③命名と分割59本に増え型がずれた ④棚卸し四半期ごとに見直す予定 運用して収束する 発火が割れる 型は最初から決め切れない。気づきを重ねて4段を回し、割れたら棚卸しで拾う。
AIエージェントのスキル設計が固まるまでの循環図

02何をスキルにして、何を書かないのか|スキル設計の最初の線引き

Claude Code公式ドキュメントは、スキルを作るタイミングを2つ挙げています。同じ指示を会話のたびに貼り直しているとき、またはCLAUDE.mdの1セクションが手順に育ったときです(出典: Claude Code公式ドキュメント)。CLAUDE.mdは常時読み込まれる事実の置き場所、スキルは使うときだけ読み込まれる手順の置き場所という役割分担です。詳しい書き方は『AIに最初に読ませるCLAUDE.md|章立てテンプレートつき』にまとめています。

スキル設計のベストプラクティスは、SKILL.mdの中身を2種類に分けます(出典: Claude Code公式ドキュメント)。

  • Reference content:規約・パターン・ドメイン知識。会話に沿って参照させる知識型
  • Task content:デプロイやコミットなど、副作用を伴う具体的な手順のタスク型

タスク型のうち、AIが判断で自動発火してよくない処理はdisable-model-invocation: trueで手動起動限定にします。次の例は、記事の公開作業を人の呼び出しだけに絞る書き方です。

---
name: publish-article
description: 承認済み記事を本番公開する
disable-model-invocation: true
context: fork
---

線引きの判断は、次の4項目のうち2つ以上に当てはまるかで行います。

  • 同じ指示・チェックリスト・手順を、会話をまたいで繰り返し貼っている
  • CLAUDE.mdの1セクションが、事実ではなく手順として育っている
  • 使うたびに前提知識や外部接続の説明をゼロから書き直している
  • 数ステップ以上の順序があり、順番を飛ばすと失敗する

「送信・公開・削除」のような取り消せない操作をタスク型スキルに含めるときは、承認の設計そのものが要ります。線引きの先にある止め方は『AIエージェントの承認ゲート|送信・公開・削除で止める仕組み』で扱っています。

何をスキルにするかを判定する2段階の分岐と、発火の性質の違い 何をスキルにするかを判定する分岐図。起点は「同じ説明を繰り返している」で、まず「繰り返す手順か」を問い、いいえならその場で完結しスキル化しない。はいなら次に「副作用があるか」を問い、なしなら知識型スキルとして自動発火させ、ありならタスク型スキルとしてdisable-model-invocationを付け手動起動限定にする。3つの行き先それぞれに、発火の性質(該当なし・自動・手動限定)を添える。 BRANCH 何をスキルにするかの判定フロー 同じ説明を繰り返している 繰り返す手順か いいえ はい 副作用があるか なし あり スキル化しないその場で完結する 知識型スキルdescriptionで自動発火 タスク型スキル手動起動限定にする 発火の性質 該当なし(完結する) 自動(AIが判断) 手動限定(/名で起動) 副作用の有無で「知識型」と「タスク型」を分け、タスク型だけを手動限定にする
何をスキルにするかを判定する分岐図

03SKILL.mdの構成要素|スキル設計を支えるフロントマターと本文

Agent Skillsの公式仕様は、SKILL.mdにname・descriptionの2フィールドを必須と定めています。nameは64文字以内で小文字・数字・ハイフンのみ、予約語「anthropic」「claude」を含めません。descriptionは1文字以上1,024文字以内です(出典: Agent Skills公式仕様)。

一方、Claude Code側の実装はこの標準より緩やかです。フロントマターの全フィールドは任意で、推奨されるのはdescriptionだけです。nameを省略すると、ディレクトリ名がそのまま表示名になります(出典: Claude Code公式ドキュメント)。

同じ「スキル設計」でも、配布先によって書き方の力点は変わります。claude.aiやAPI経由で配布するならnameとdescriptionを標準の書式で固定し、Claude Code専用ならdescriptionだけを厳密に書きます。

主なフロントマターフィールドは次のとおりです。

フィールド必須効果
name任意(Claude Codeでは省略可。省略時はディレクトリ名)スキル一覧に出る表示名。標準では64文字以内・小文字英数字とハイフンのみ
description推奨(Agent Skills標準では必須)Claudeが自動発火を判断する唯一のフィールド。最大1,024文字
disable-model-invocation任意trueで自動発火を止め、/スキル名の手動起動だけにする
user-invocable任意falseでメニューから消え、Claudeだけが自動で使う知識になる
allowed-tools任意起動したそのターンだけツールを承認なしで使わせる。次の発言で失効する
context: fork任意独立したサブエージェントで実行する。会話履歴を持たずに動く

descriptionの書き方は、三人称で「何をするか」と「いつ使うか」を具体語つきで書くことが公式に推奨されています(出典: Agent Skills公式ドキュメント)。自社のseo-articleスキルは次のように書いています(一部抜粋、2026-07-28時点)。

---
name: seo-article
description: メインKW1個の入力から、Ahrefs調査→構成設計書→本文執筆→図解→品質ゲート→WordPress下書き保存までSEO記事を一気通貫で制作する。「【KW】で記事作って」と言われたとき、またはKWリストが受付フォルダに投入されたときに使う(以下略)。
---

「何をするか」を工程の矢印で具体化し、「いつ使うか」をユーザーが実際に言いそうな文言で書いています。トリガー句が曖昧な一般論だと、Claudeは100以上あるスキルの中から選べません(出典: Agent Skills公式ドキュメント)。

スキルの置き場所は、適用範囲で使い分けます。

置き場所パス適用範囲
Personal~/.claude/skills/<name>/SKILL.md自分の全プロジェクト
Project.claude/skills/<name>/SKILL.mdそのプロジェクトのみ
Plugin<plugin>/skills/<name>/SKILL.mdプラグインが有効な範囲
EnterpriseManaged settings組織の全ユーザー

同名スキルが複数の階層に存在するときは、Enterprise・Personal・Projectの順で上位が優先されます(出典: Claude Code公式ドキュメント)。allowed-toolsの許可も、そのスキルを呼び出したターン限りで消える仕様です。毎ターン使う操作の許可はallowed-toolsではなく、通常の権限設定に置きます。設定の書き方は『Claude Codeの権限設定|allow・ask・denyの配分と設定例』にまとめています。

04AIエージェントのスキル設計|59本運用で固まった命名と分割の型

WEBMARKSは7部署・30体のAI社員体制を2026-06-24に統合し、.agents/skillsが2026-07-28時点で59本まで増えました。数が増える過程で、命名は公式推奨と自社の実態がずれました。

公式のベストプラクティスは、動詞のing形(gerund)での命名を推奨し、processing-pdfsanalyzing-spreadsheetsを例に挙げています。helperutilsのような曖昧な名前は避けるよう明記されています(出典: Agent Skills公式ドキュメント)。実際に運用しているスキル名を見返すと、ing形はほとんど使っていません。代わりに4つの型に収束しています。

パターン実例向く用途
対象+成果物型〈対象〉-〈出力物〉seo-article/data-chart-maker決まった型の成果物を毎回出すスキル
対象+点検型〈対象〉-audit/-healthvault-audit/automation-health定期点検・監査系
役割そのもの型〈役割名〉devils-advocate/diagram-maker人格・専門役を1つ立てるスキル
動詞命令型〈動詞〉-〈目的語〉resume-tasks/promote手動起動が前提のタスク型スキル

命名の型がぶれても、発火精度そのものへの影響は限定的です。Claudeが自動発火を判定する材料はdescriptionだけであり、nameは一覧に出る表示名に過ぎません(出典: Claude Code公式ドキュメント)。命名を整える目的は発火精度ではなく、人がスキル一覧を見たときに探しやすくすることです。

分割の型は、SKILL.md本体を500行以内に収める目安から逆算します(出典: Agent Skills公式ドキュメント)。500行を超えそうな知識は、reference.mdのような参照ファイルに切り出します。参照はSKILL.mdから1階層だけにとどめ、参照ファイルからさらに別ファイルを孫参照させないことが推奨されています。孫参照があると、Claudeがheadコマンドで部分的にしか読まず、情報が欠けたまま処理を進めることがあるためです(出典: Agent Skills公式ドキュメント)。

自社のhtml-diagram-explainerスキルは、この分割型をそのまま実装しています。

.agents/skills/html-diagram-explainer/
├── SKILL.md
├── MASTER_PROMPT.md
├── README.md
├── assets/design-skeleton.html
├── references/html-diagram-patterns.md
└── scripts/
    ├── preflight_diagram_check.py
    └── scaffold_diagram.py

骨格の指示はSKILL.md、素材はassets、判断基準の細部はreferences、実行するコードはscriptsに分けています。1スキル1責務の境界線は、「その処理を別の依頼で単独で呼び出したいか」で引きます。単独で呼びたいなら別スキルに分け、常にセットで使うなら同じスキルの参照ファイルに留めます。

05スキル設計の棚卸し|導入後に何を見直すか

スキルは増やして終わりではありません。スキル一覧のメタデータは、モデルのコンテキストウィンドウの約1%を目安に予算化されています(出典: Claude Code公式ドキュメント)。この予算を超えると、呼び出し頻度が低いスキルから順にdescriptionが短縮されます。結果としてtrigger keywordsが欠けていき、使われないまま放置したスキルは気づかないうちに発火しなくなります(出典: Claude Code公式ドキュメント)。

スキルはどの4段階で気づかれず発火しなくなり、どこまで取り消せるか 横軸はスキル導入からの経過時間。①導入直後は呼び出し頻度が高い、②本数が増えてコンテキストウィンドウ約1%の予算に接近、③予算超過で呼び出し頻度が低いスキルから順にdescriptionが短縮、④trigger keywordsが欠落し発火しなくなる、の4段階を左から右へ並べる。各段階の下にskillOverridesで後から取り消せるかを可逆・不可逆で示し、①〜③は棚卸しが間に合う可逆区間、④は気づかれないまま固定化する不可逆区間として境界線を引く。 TIMELINE スキルはどの4段階を経て、気づかれず発火しなくなるのか 導入からの経過時間 導入直後 呼び出し頻度が高い 本数増加 予算(約1%)に接近 予算超過 頻度が低い順に短縮 keywords欠落 発火しなくなる 1 2 3 4 可逆 可逆 可逆 不可逆 棚卸しが間に合う区間 手遅れになる区間 skillOverridesで防げる 気づかれないまま固定化 止められるのは可逆な3段階だけ。発火しなくなった後は棚卸しに気づく手がかりがない 出典:Claude Code公式ドキュメント(2026-07-28時点)
スキルが「使われなくなり気づかれないまま発火しなくなる」までの時間軸図

棚卸しで見る指標は3つです。

  • 直近で1度も呼ばれていないスキルがないか
  • descriptionの文言が、実際にユーザーが使う言い回しとずれていないか
  • SKILL.md本体が500行の目安を超えていないか

公式ドキュメントは、この予算の見積もりを/doctorコマンドで確認できると案内しています(出典: Claude Code公式ドキュメント)。使わなくなったスキルは、ファイルを消さなくてもskillOverrides設定で切り替えられます。"name-only"は説明文だけ隠し、"off"は一覧からも隠します(出典: Claude Code公式ドキュメント)。削除せずに一時的に外せるため、棚卸しの判断を後から取り消せます。

WEBMARKSは59本まで増えたペースを踏まえ、棚卸しの頻度を上げる運用を検討しています。増えるペースが速い組織ほど、命名や分割の型が古い基準のまま固まっていないかを、早めに見直す必要があります。

06スキルの型が崩れると起きること|つまずきやすい3つの症状

よくある誤解公式ドキュメントの実際スキル設計での対処
nameを工夫すれば発火精度が上がる発火判定に使われるのはdescriptionのみ三人称・具体語・「いつ使うか」をdescriptionに書く
SKILL.mdはコンパクトなほど良い本文500行が目安の上限で、詳細は参照ファイル前提概要はSKILL.md、詳細はreference.mdへ分割する
allowed-toolsは一度許可すれば以後も有効許可はそのスキルを呼び出したターン限定毎ターン使う処理は通常の権限設定側に置く

症状1は「スキルが発火しない」です。公式のトラブルシューティングは、descriptionにユーザーが実際に使う言葉が入っていないことを主な原因に挙げます。対処は、依頼文をそのままdescriptionへ反映することです。What skills are available?と聞いて一覧に出るかを確かめます(出典: Claude Code公式ドキュメント)。

症状2は「スキルが発火しすぎる」です。descriptionが広すぎると、関係ない依頼にも反応します。対処はdescriptionを狭めることです。副作用があるならdisable-model-invocation: trueで手動限定に切り替えます(出典: Claude Code公式ドキュメント)。

症状3は「分割し過ぎて参照が追えなくなる」です。SKILL.mdから2階層以上先のファイルを参照させると、Claudeが全文を読まず断片的にしか情報を得られません。対処は、参照をSKILL.mdから1階層に統一し、100行を超える参照ファイルには目次を置くことです(出典: Agent Skills公式ドキュメント)。

07スキル設計チェックリスト

  • このスキルは「同じ指示を繰り返し貼っている」または「CLAUDE.mdの一部が手順化している」に当てはまるか
  • nameは64文字以内・小文字英数字とハイフンのみで、予約語(anthropic/claude)を含んでいないか
  • descriptionは三人称で「何をするか」と「いつ使うか」を具体語つきで書いているか
  • 副作用のあるタスク型スキルにdisable-model-invocation: trueを付けたか
  • 参照専用の知識型スキルで、allowed-toolsを付けすぎていないか
  • SKILL.md本体は500行を超えていないか。超えるなら参照ファイルへ分割したか
  • 参照ファイルはSKILL.mdから1階層にとどめ、孫参照を作っていないか
  • 命名は自分たちの型(対象+成果物・対象+点検・役割名・動詞命令)に沿っているか
  • 使われなくなったスキルを見直す棚卸しの頻度を決めているか
  • 配布先ごとに必要なフィールド(Claude Codeは任意、公開標準は必須)を確認したか

08FAQ

スキル設計は何行までに収めるべきですか

公式の目安はSKILL.md本体で500行以内です。超える知識はreference.mdのような参照ファイルへ分割し、SKILL.mdには概要と参照先だけを残します。

CLAUDE.mdとスキル設計はどう役割分担しますか

CLAUDE.mdは常時読み込まれる事実の置き場所、スキルは使うときだけ読み込まれる手順の置き場所です。同じ指示を繰り返し貼っている、またはCLAUDE.mdの1セクションが手順化しているなら、スキル設計への切り出しを検討します。

スキルの発火精度を上げるには、nameとdescriptionのどちらが重要ですか

descriptionです。Claudeが自動発火を判断する材料はdescriptionだけで、nameはスキル一覧に出る表示名に過ぎません。命名の型を整えるのは、人がスキルを探しやすくするためです。

個人開発でもスキル設計は必要ですか

必要です。繰り返す手順が3つ以上あれば、1人での利用でもスキルに切り出す価値があります。descriptionを具体的に書けば、自分自身が依頼するときの手間も減ります。

スキルが増えすぎたらどうすればいいですか

削除する前にskillOverrides設定で"name-only""off"に切り替え、一覧から一時的に外します。棚卸しで実際に不要と判断してから、ファイルを整理します。

命名と分割の型は、最初にどこまで決めておくべきですか

すべてを最初に決め切る必要はありません。本記事の4つの命名パターンは、59本を運用する中で後から収束した型です。数本の間は自由に書き、増えてきた段階で型をそろえる順番でも問題ありません。