非エンジニアがClaude CodeのSkills機能を設定した手順
Claude Code公式ドキュメントによると、Skillsは`~/.claude/skills/<name>/SKILL.md`に保存し、YAMLフロントマターの`description`だけでClaudeが自動判断して読み込む仕組みになっている。この記事では、非エンジニアの筆者が実際に14個のSkillを作った際の手順と、公式ドキュメントで確認した仕様の両方を書く。

目次
「claude skills 非エンジニア」で検索する人は、Skills機能を使うと何が変わるのか、コードが書けなくても設定できるのかを知りたいはずだ。結論から言うと、Skillsの実体はYAMLフロントマター付きのMarkdownファイル1枚で、プログラミングの知識は要らない。この記事では、Claude Code公式ドキュメントで確認できる仕様と、筆者が自分の業務向けに実際にSkillを作ってきた手順を、両方書く。
3行まとめ
- Skillの実体は
SKILL.mdというMarkdownファイル1枚。個人用は~/.claude/skills/<skill名>/SKILL.mdに置くだけで、次のセッションから使える- フロントマターの
descriptionにスキルの内容と使いどころを書くと、Claudeが会話の文脈から自動的に読み込むかどうかを判断する。手動でしか呼ばせたくない場合はdisable-model-invocation: trueで止められる- 筆者は自分の業務ジャンルごとに14個のSkillを運用中。作る前に用途を3つ書き出す・半年使われなければ凍結する、というルールを自分で決めて回している
SKILL.mdを1つ作るところまで
Claude Code公式ドキュメントの手順はシンプルだ。フォルダを作り、その中にSKILL.mdを1つ置くだけでよい。
mkdir -p ~/.claude/skills/summarize-changes
SKILL.mdはYAMLフロントマター(---で挟まれた部分)と、その下のMarkdown本文の2部構成になる。フロントマターのdescriptionフィールドが、Claudeが「このスキルをいつ使うか」を判断する材料になる。公式ドキュメントの例では、こう説明されている。
ディレクトリ名はコマンドになり、
descriptionは Claude がスキルを自動的に読み込むかどうかを決定するのに役立ちます。
つまり、ディレクトリ名がそのまま/summarize-changesのようなコマンド名になり、descriptionの書き方次第でClaudeが自動的にスキルを呼び出すかどうかが変わる。保存場所は公式ドキュメントによると4種類あり、どこに置くかで使える範囲が変わる。
| 保存場所 | パス | 適用対象 |
|---|---|---|
| Enterprise | 管理設定で指定 | 組織内のすべてのユーザー |
| Personal | ~/.claude/skills/<skill名>/SKILL.md |
すべてのプロジェクト |
| Project | .claude/skills/<skill名>/SKILL.md |
そのプロジェクトのみ |
| Plugin | <plugin>/skills/<skill名>/SKILL.md |
プラグインが有効な場所 |
同じ名前のスキルが複数レベルに存在する場合はEnterpriseがPersonalを、PersonalがProjectを上書きする優先順位になっている。非エンジニアが個人の業務用に使う分には、基本的に~/.claude/skills/(Personal)だけ覚えておけば十分だ。
公式ドキュメントはもう1点、地味だが実務上重要な仕様変更にも触れている。「カスタムコマンドはスキルにマージされました」という記述で、.claude/commands/deploy.mdというファイルと.claude/skills/deploy/SKILL.mdというスキルは、どちらも同じ/deployコマンドを作り、同じように機能するとされている。既存の.claude/commands/ファイルはそのまま動くが、スキル形式のほうがサポートファイル用のディレクトリや呼び出し制御のフロントマターなど、追加機能を持つ。
フロントマターで設定できる項目──全部で16ある
実際に運用してみて重要だったのが、「誰が呼び出せるか」を制御するフロントマターのフィールドだった。公式ドキュメントの「フロントマターリファレンス」を確認すると、description以外にも合計16のフィールドが定義されている。必須なのは実質descriptionのみで、残りはすべて省略可能だが、非エンジニアが実務で使う可能性が高いものを抜粋すると次の通り。
| フィールド | 必須 | 説明 |
|---|---|---|
description |
推奨 | スキルが何をするか・いつ使うか。省略時は本文の最初の段落が使われる。スキル一覧でのコンテキスト消費を抑えるため、1,536文字で切り詰められる |
disable-model-invocation |
いいえ | trueにするとClaudeが自動で呼び出さなくなり、/スキル名と手動で打った時だけ発動する。デフォルトはfalse |
user-invocable |
いいえ | falseにすると/メニューから非表示になり、ユーザーからは呼び出せない背景知識用になる。デフォルトはtrue |
allowed-tools |
いいえ | このスキルが有効な間、Claudeが許可を求めずに使えるツールを指定する |
disallowed-tools |
いいえ | このスキルが有効な間、Claudeの利用可能なツールプールから除外するツールを指定する |
model |
いいえ | このスキルが有効な間だけ使うモデルを上書きする。次のプロンプトでセッション本来のモデルに戻る |
effort |
いいえ | このスキルが有効な間の努力レベル(low/medium/high/xhigh/max)をセッション設定より優先する |
argument-hint |
いいえ | /スキル名と打つ際にオートコンプリートで表示される引数のヒント |
disable-model-invocationは、副作用のある操作(デプロイや外部送信など)をClaudeの自動判断任せにしたくない場合に使う設定で、user-invocable: falseはその逆に「ユーザーには呼ばせず、Claudeが文脈判断でだけ参照する」設定だ。
筆者が業務用に作っている14個のSkillのほとんどは、この2つのフィールドを設定していないデフォルトの状態で使っている。デフォルトでは、Claude自身がスキルのdescriptionを見て「この会話ではこのスキルが関係あるか」を毎回判断し、関係あると判断した時だけ本文全体を読み込む。SKILL.mdの本文をどれだけ長く書いても、呼び出されない限りコンテキストを消費しないという点は、CLAUDE.mdに同じ内容を書き足していくのとの一番の違いだ。
バンドル済みスキルという「最初から入っているスキル」
公式ドキュメントによれば、Claude CodeにはdisableBundledSkills設定で無効化しない限り、すべてのセッションで最初から使える「バンドル済みスキル」が付属している。/doctor・/code-review・/batch・/debug・/loop・/claude-apiがこれに当たり、固定ロジックを直接実行する組み込みコマンドとは違い、プロンプトベースでClaudeに詳細な指示を与える点は自作のSkillと同じ仕組みだという。つまり、自分でSkillを作らなくても、これらは/の後に名前を打てばすぐ試せる。
また公式ドキュメントは、Skillと似て非なる仕組みとして「プラグイン」にも触れている。プラグインはSkill・エージェント・hooksなどをひとまとめにして配布できる単位で、Anthropicはclaude-plugins-official(Anthropicがキュレーションする公式マーケットプレイス)とclaude-community(レビュー後にサードパーティが登録できる公開コミュニティマーケットプレイス)という2つの公開マーケットプレイスを運営していると説明されている。個人用のSkillを試してみて「他人が作ったものも使ってみたい」と思った場合の次のステップとして存在は知っておく価値がある(本記事では実際にマーケットプレイスからプラグインを導入するところまでは試していない)。
作る前に「使いどころ」を3つ書き出す
Skillを作ること自体は数分で終わるが、運用していて一番効いたのは技術的な設定ではなく、作る前のルールだった。筆者は新しいSkillを作る前に、必ず「どんな場面で使うか」の具体例を3つ書き出してから着手するようにしている。これは、作ったものの一度も呼び出されない「死蔵スキル」を防ぐための自分ルールで、Claude Codeの公式仕様ではない。
実際に作ったSkillは、コピーライティング・心理学・マーケティング・YouTube戦略・ストーリーテリング・批判的思考・データ分析・SEO・法務税務・コーディング・動画編集といった、自分の業務でくり返し発生するジャンルごとに1つずつ。1つあたり半日から1日ほどかけ、ジャンルの一次情報を調べるAIエージェントを複数並列で走らせてから、SKILL.md本体と参照用の章立てファイルにまとめる、という作り方をしている。公式ドキュメントにも次の目安が書かれている。
SKILL.mdを 500 行以下に保ちます。詳細なリファレンス資料を別のファイルに移動します。
この助言はそのまま実務でも役に立った。1つのSKILL.mdに全部書き込もうとすると読み込みが重くなるため、概要と目次だけをSKILL.md本体に置き、詳細は別ファイルに分けて「必要な時だけ参照させる」構成にしている。
作った直後は、必ず動作を2通りで確かめる。1つは、Skillのdescriptionに該当しそうな質問をClaudeに投げて、自動的に呼び出されるかを見る方法。もう1つは/スキル名と直接打って手動で呼び出す方法だ。公式ドキュメントにも、Skillディレクトリの変更はセッションを再起動しなくてもその場で反映されると書かれており、SKILL.mdを書き直すたびに毎回Claude Codeを再起動する必要はない。この即時反映のおかげで、descriptionの書き方を少しずつ変えては呼び出され方を試す、という調整がやりやすかった。
半年使われなければ凍結する
もう1つ、非エンジニアだからこそ意識しているのが「作ったから使う」に引っ張られない仕組みだ。Skillを14個も持っていると、目の前の作業と関係の薄いSkillにまで判断が寄ってしまうことがある。対策として、構築から半年間呼び出された形跡がないSkillは凍結・削除の対象にする、という棚卸しルールを自分で決めて運用している。これも公式機能ではなく、非エンジニアが自分の判断で作った運用ルールだ。
Skillと近い機能に、特定のツール呼び出し時にコマンドを強制実行する「hooks」がある。Skillが「Claudeに何を教えるか」の仕組みなのに対し、hooksは「Claudeの動作をルール違反ごと機械的にブロックする」仕組みで、役割が違う。公式ドキュメント「hooks でアクションを自動化する」を確認すると、hooksはSkillのフロントマターのhooksフィールドからスキル単位でスコープすることもできると説明されており、両者は完全に独立した機能ではなく組み合わせて使える設計になっている。hooksを使った具体的な実装手順はAIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み(hooks)の作り方に書いているので、Skillだけでは足りないと感じた場合はあわせて読んでほしい。Skillsを含むClaude Codeの基本機能全体についてはClaude Codeとはで整理している。
バージョンが変われば仕様も変わる、という前提で読んでほしい
- 本記事はClaude Code公式ドキュメント(スキル・サブエージェント・プラグイン・hooksの4ページ)を実際にcurlで取得した内容と、筆者が自分の業務用に実際にSkillを運用してきた経験の両方にもとづいている。どちらの記述かは本文中でできる限り区別したが、フロントマターの表のように公式仕様として書いた部分は公式ドキュメントの記載、「半年使われなければ凍結する」のような運用ルールは筆者独自の判断であり公式仕様ではない
- 公式ドキュメントには
Claude Code v2.1.205以降のように特定バージョン以降でのみ有効な仕様が複数明記されている。本記事は取得時点のドキュメント内容をそのまま紹介しており、読者の手元のClaude Codeのバージョンによっては挙動が異なる可能性がある - フロントマターの全16フィールドのうち、本記事で表にしたのは非エンジニアが使う可能性が高いものを筆者が選んだ8つ。
hooks・paths・context・agent・shellなど、より高度な設定は公式ドキュメント本文を直接あたってほしい - プラグインマーケットプレイスについては、存在と2つの公式マーケットプレイス名を公式ドキュメントで確認したのみで、実際にインストールして動かす検証は本記事では行っていない
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。