結論：Claude Code の Skills（スキル）は、繰り返す手順・チェックリスト・専門知識を .claude/skills/<name>/SKILL.md という 1 ファイルにまとめておく仕組みです。CLAUDE.md と違って本文は呼び出されたときだけ読み込まれるため、長い参照資料を抱えても普段はトークンをほぼ消費しません。/skill-name で自分から起動するか、description をもとに Claude が関連時に自動で読み込みます。
この記事の要点（2026 年 6 月時点・公式仕様で確認）
- スキルの実体は ディレクトリ +
SKILL.md。置き場所はプロジェクト.claude/skills/と個人~/.claude/skills/の 2 種類で、補助ファイルやスクリプトを同梱できる - frontmatter（
name/description/allowed-toolsなど）で挙動を制御。必須キーはなく、descriptionのみ推奨 - カスタムコマンドは Skills に統合された。既存の
.claude/commands/*.mdはそのまま動作し、同じ frontmatter をサポートする
対象読者：Claude Code を日常的に使っていて、同じ指示や手順書を毎回コピペしているのが面倒な開発者・エンジニア・PM。
今日やること：手元のリポジトリに SKILL.md を 1 枚作り、/ メニューから呼び出せる状態にする。
Claude Code を使い込むと、「このリポジトリの API はこういう規約で書いて」「リリース前にこのチェックリストを順番に実行して」みたいな指示を、毎回ほぼ同じ文面で打ち込んでいることに気づきます。私も最初はその手の手順書をメモアプリに溜めておいて、必要なときに貼り付けていました。動くことは動くんですが、チームに共有できないし、CLAUDE.md に全部書くと「いつも読み込まれる固定コスト」になってコンテキストを圧迫する。正直、ここが地味に悩ましかった。
そこで使うのが Skills（スキル）です。Claude Code 公式ドキュメントは「同じ指示・チェックリスト・複数ステップの手順をチャットに貼り続けているとき、あるいは CLAUDE.md の一節が『事実』ではなく『手順』に育ってしまったとき」がスキルの出番だと明言しています。CLAUDE.md と決定的に違うのは、スキルの本文は使われたときだけ読み込まれる点です。だから長い参照資料を抱えても、呼び出すまではコストがほぼゼロ。この記事では、現行版（2026 年 6 月時点）の仕様を公式ドキュメントで裏取りしながら、実際に動く SKILL.md を例ベースで作っていきます。
Claude Code Skills とは何か（CLAUDE.md・コマンドとの違い）
まず立ち位置を整理します。Claude Code には「Claude に何かを覚えさせる/させる」手段がいくつかあり、用途で使い分けます。
| 仕組み | 読み込みタイミング | 向いている用途 |
|---|---|---|
| CLAUDE.md | 常時（毎ターン文脈に乗る） | 変わらない事実・前提（技術スタック、命名規約の根幹など） |
| Skills（SKILL.md） | オンデマンド（呼び出し時のみ） | 手順・チェックリスト・専門知識・定型作業 |
| カスタムコマンド | 呼び出し時のみ | 1 枚で完結する定型コマンド（※現在は Skills に統合） |
公式ドキュメントの表現を借りると、スキルは「SKILL.md ファイルを作ると Claude がそれを自分の道具箱に加える」もので、「関連するときに Claude が使うか、/skill-name で直接起動する」ものです。ポイントは オンデマンド読み込み。CLAUDE.md の内容は毎ターン文脈に乗りますが、スキルの本文は使われるまで読み込まれません。だから「滅多に使わないが長い手順書」はスキルにしておくのが正解で、これが CLAUDE.md との最大の違いです。
そしてもう 1 つ、2026 年版の重要な変更点。公式ドキュメントには次のように明記されています。
Custom commands have been merged into skills. A file at
.claude/commands/deploy.mdand a skill at.claude/skills/deploy/SKILL.mdboth create/deployand work the same way. Your existing.claude/commands/files keep working.
（出典：Claude Code 公式ドキュメント「Extend Claude with skills」）
つまり カスタムコマンドは Skills という仕組みに統合されましたが、従来の .claude/commands/*.md 方式は引き続き有効で、同じ frontmatter をサポートします。「これまで commands で書いてきたものを今すぐ書き直す必要はない」というのが結論です。スキル方式（SKILL.md + 専用ディレクトリ）は補助ファイルを同梱できたり、Claude が自動で読み込めたりといった追加機能があるため、複雑なものはスキル、1 枚で済む定型コマンドは .claude/commands/、という使い分けになります。なお Claude Code のスキルは Agent Skills というオープン標準に準拠しており、Claude Code はこれに呼び出し制御・サブエージェント実行・動的コンテキスト注入といった拡張を加えている、という位置づけです。
![Claude Code Skills の構造とオンデマンド読み込み。.claude/skills/<name>/SKILL.md は frontmatter（name/description）＋本文（手順・知識）＋補助ファイルで構成され、関連する時だけ読み込まれる（CLAUDE.mdは常時・スキルは必要時）。”><figcaption>SKILL.md の構造とオンデマンド読み込み（frontmatter＋本文＋補助ファイル／必要時のみロード）</figcaption></figure>
<h2>SKILL.md の書き方（frontmatter と本文）</h2>
<p>スキルの最小単位は「ディレクトリ + <code>SKILL.md</code>」です。<code>SKILL.md</code> は 2 つのパートでできています。1 つは <code>---</code> で囲んだ <strong>YAML frontmatter</strong>（このスキルが何で、いつ使うかを Claude に伝える）、もう 1 つは <strong>本文の Markdown</strong>（スキルが起動したときに Claude が従う指示）です。ディレクトリ名がそのまま入力するコマンド名になり、<code>description</code> が「いつ自動で読み込むか」の判断材料になります。</p>
<p>まずは公式の最小例。「未コミットの変更を要約してリスクを指摘する」スキルです。<code>~/.claude/skills/summarize-changes/SKILL.md</code> に保存します。</p>
<pre><code>---
description: 未コミットの変更を要約し、危なそうな点を指摘する。何が変わったか聞かれたとき、コミットメッセージが欲しいとき、diffをレビューしたいときに使う。
---
## 現在の変更
!`git diff HEAD`
## 指示
上の変更を2〜3個の箇条書きで要約し、続けて気づいたリスク（エラーハンドリング漏れ・ハードコードされた値・更新が必要なテストなど）を列挙してください。diffが空なら「未コミットの変更はありません」と返します。
</code></pre>
<p><code>description</code> しか frontmatter に書いていない点に注目してください。公式仕様では <strong>frontmatter のフィールドはすべて任意</strong>で、<strong>推奨されているのは <code>description</code> だけ</strong>です。本文に出てくる <code>!`git diff HEAD`</code> は<strong>動的コンテキスト注入</strong>の記法で、Claude が本文を読む<em>前</em>に Claude Code 側がそのコマンドを実行し、出力でこの行を置き換えます。つまり Claude は「git diff を実行して」という指示ではなく、<strong>実際の差分テキストそのもの</strong>を受け取ります。これにより、開いているファイルから推測するのではなく、実際の作業ツリーに基づいた応答になります。</p>
<p>本文には何を書いてもよいのですが、内容は大きく 2 タイプに分けて考えると整理しやすいです。</p>
<ul>
<li><strong>リファレンス型</strong>：規約・パターン・スタイルガイド・ドメイン知識など、Claude が今の作業に<em>適用</em>する知識。会話のコンテキストと並んでインラインで効く（例：「この API はこう書く」）</li>
<li><strong>タスク型</strong>：デプロイ・コミット・コード生成など、特定の<em>アクション</em>の手順書。<code>/skill-name</code> で自分から起動したいことが多く、Claude に勝手に実行されたくない場合は <code>disable-model-invocation: true</code> を付ける</li>
</ul>
<p>本文を書くときの鉄則は <strong>簡潔に保つ</strong>こと。公式ドキュメントによれば、いったんスキルが読み込まれるとその内容は<strong>そのセッションの間ずっとコンテキストに残り続ける</strong>（毎ターン再読込はされない）ため、1 行ごとが繰り返しのトークンコストになります。「なぜ・どうやって」を長々と説明するより「何をするか」を述べる――CLAUDE.md と同じ簡潔さの基準を当てはめます。本文が長くなりそうなら、後述の補助ファイルに切り出すのが定石です（公式の目安は <code>SKILL.md</code> を 500 行以内に）。</p>
<h3>主な frontmatter キー（2026 年 6 月時点）</h3>
<p>本文の前に置く YAML で、スキルの挙動を細かく制御できます。よく使うキーは次のとおりです（すべて任意。<code>description</code> のみ推奨）。</p>
<table>
<thead>
<tr>
<th>キー</th>
<th>役割</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>name</code></td>
<td>スキル一覧での表示名。省略時はディレクトリ名。<strong>入力するコマンド名はディレクトリ名で決まり、<code>name</code> では基本変わらない</strong></td>
</tr>
<tr>
<td><code>description</code></td>
<td>何をする/いつ使うスキルか。Claude が自動起動の判断に使う。最重要キー。省略時は本文の最初の段落が使われる</td>
</tr>
<tr>
<td><code>when_to_use</code></td>
<td>起動トリガーとなる言い回しや例。<code>description</code> に追記される形で一覧に出る</td>
</tr>
<tr>
<td><code>argument-hint</code></td>
<td>オートコンプリート時に表示する引数ヒント（例：<code>[issue-number]</code>）</td>
</tr>
<tr>
<td><code>arguments</code></td>
<td><code>$name</code> 置換用の名前付き位置引数。スペース区切り文字列か YAML リスト</td>
</tr>
<tr>
<td><code>disable-model-invocation</code></td>
<td><code>true</code> で Claude による自動起動を禁止。手動 <code>/name</code> 専用にしたいワークフロー向け（デプロイ等）</td>
</tr>
<tr>
<td><code>user-invocable</code></td>
<td><code>false</code> で <code>/</code> メニューから隠す。ユーザーが直接叩く意味のない背景知識向け</td>
</tr>
<tr>
<td><code>allowed-tools</code></td>
<td>このスキルが有効な間、許可なしで使えるツール。スペース/カンマ区切りか YAML リスト</td>
</tr>
<tr>
<td><code>model</code> / <code>effort</code></td>
<td>このスキルが有効な間に使うモデル/Effort レベルを上書き（その手番のみ。設定には保存されない）</td>
</tr>
<tr>
<td><code>context</code> / <code>agent</code></td>
<td><code>context: fork</code> でサブエージェントの分離コンテキストで実行。<code>agent</code> でその種類を指定</td>
</tr>
<tr>
<td><code>paths</code></td>
<td>glob パターンで、該当ファイルを扱うときだけ自動起動するよう限定</td>
</tr>
</tbody>
</table>
<p>引数を受け取りたいときは本文で <code>$ARGUMENTS</code>（全引数）や <code>$ARGUMENTS[0]</code>・<code>$0</code>（0 始まりの位置引数）を使います。たとえば <code>Fix GitHub issue $ARGUMENTS ...</code> と書いておけば、<code>/fix-issue 123</code> の実行時に <code>$ARGUMENTS</code> が <code>123</code> に置き換わります。スキルに <code>$ARGUMENTS</code> が無い状態で引数付き起動すると、Claude Code が本文末尾に <code>ARGUMENTS: <入力></code> を追記するので、入力自体は必ず Claude に届きます。</p>
<h2>スキルの配置（プロジェクトと個人、その読み込みスコープ）</h2>
<p>スキルをどこに置くかで「誰が使えるか」が決まります。公式の対応表は次のとおりです。</p>
<table>
<thead>
<tr>
<th>場所</th>
<th>パス</th>
<th>適用範囲</th>
</tr>
</thead>
<tbody>
<tr>
<td>個人</td>
<td><code>~/.claude/skills/<skill-name>/SKILL.md</code></td>
<td>自分の全プロジェクト</td>
</tr>
<tr>
<td>プロジェクト</td>
<td><code>.claude/skills/<skill-name>/SKILL.md</code></td>
<td>そのプロジェクトのみ（コミットで共有）</td>
</tr>
<tr>
<td>エンタープライズ</td>
<td>managed settings 参照</td>
<td>組織内の全ユーザー</td>
</tr>
<tr>
<td>プラグイン</td>
<td><code><plugin>/skills/<skill-name>/SKILL.md</code></td>
<td>プラグイン有効時</td>
</tr>
</tbody>
</table>
<p>名前が衝突した場合の<strong>優先順位</strong>は、公式の表現で「<strong>enterprise が personal を、personal が project を上書きする</strong>」です（プラグインスキルは <code>plugin-name:skill-name</code> の名前空間を持つので衝突しません）。また、<code>.claude/commands/</code> にあるファイルも同じように動きますが、<strong>スキルとコマンドが同名なら<u>スキル</u>が優先</strong>されます。チームで配布したいスキルはプロジェクトの <code>.claude/skills/</code> に置いてコミットする、というのが基本運用です。</p>
<p>ディレクトリ構成は、<code>SKILL.md</code> をエントリポイントに、必要なら補助ファイルを並べる形です。</p>
<pre><code>.claude/
└── skills/
└── release-checklist/
├── SKILL.md # メイン手順（必須・/release-checklist で起動）
├── reference.md # 詳細なリリース基準（必要時のみ読み込み）
└── scripts/
└── check.sh # Claudeが実行するスクリプト
</code></pre>
<p>実用上の注意点も押さえておきます。Claude Code はスキルディレクトリのファイル変更を監視していて、<code>~/.claude/skills/</code> やプロジェクトの <code>.claude/skills/</code> 配下の <strong>スキルの追加・編集・削除はセッション中に再起動なしで反映</strong>されます（公式の Live change detection）。ただし、セッション開始時に存在しなかった「トップレベルの skills ディレクトリ自体」を新規作成した場合だけは、監視対象に入れるため Claude Code の再起動が必要です。最初の 1 個を作るときは、ディレクトリを作った直後に一度 Claude Code を立ち上げ直すと確実です。</p>
<h2>呼び出し制御（自分が呼ぶ／Claude が自動で使う）</h2>
<p>デフォルトでは、あなたも Claude もどちらもスキルを起動できます。<code>/skill-name</code> と打てば自分で直接起動できますし、会話の内容が <code>description</code> に合致すれば Claude が自動でそのスキルを読み込みます。この 2 方向を、frontmatter の 2 つのフィールドで制限できます。</p>
<ul>
<li><strong><code>disable-model-invocation: true</code></strong>：<strong>あなただけ</strong>が起動できる。<code>/commit</code> / <code>/deploy</code> / <code>/send-slack-message</code> のように、副作用があったりタイミングを自分で握りたいワークフローに使う。「コードが完成して見えるから」と Claude に勝手にデプロイされては困るからです</li>
<li><strong><code>user-invocable: false</code></strong>：<strong>Claude だけ</strong>が起動できる。<code>legacy-system-context</code> のような「古いシステムの仕組みを説明する背景知識」向け。Claude は必要なときに知っておくべきだが、ユーザーが <code>/legacy-system-context</code> と叩く意味はないからです</li>
</ul>
<p>この 2 フィールドが「誰が起動できるか」と「いつコンテキストに読み込まれるか」にどう効くかを、公式の表でまとめます。</p>
<table>
<thead>
<tr>
<th>frontmatter</th>
<th>自分で起動</th>
<th>Claude が起動</th>
<th>コンテキストへの読み込み</th>
</tr>
</thead>
<tbody>
<tr>
<td>（デフォルト）</td>
<td>可</td>
<td>可</td>
<td><code>description</code> は常時／本文は起動時に読み込み</td>
</tr>
<tr>
<td><code>disable-model-invocation: true</code></td>
<td>可</td>
<td>不可</td>
<td><code>description</code> は文脈に乗らない／本文は自分が起動したとき読み込み</td>
</tr>
<tr>
<td><code>user-invocable: false</code></td>
<td>不可</td>
<td>可</td>
<td><code>description</code> は常時／本文は起動時に読み込み</td>
</tr>
</tbody>
</table>
<p>つまり通常セッションでは、<strong>スキルの <code>description</code> だけが常にコンテキストに載っていて</strong>（Claude が「何が使えるか」を把握するため）、<strong>本文は起動されて初めて読み込まれます</strong>。これがオンデマンド読み込みの実体です。なお Claude が思ったように起動してくれないときは、<code>description</code> にユーザーが自然に言いそうなキーワードを含めるのが効きます。逆に起動しすぎるなら <code>description</code> をより具体的にするか、<code>disable-model-invocation: true</code> で手動専用にします。</p>
<p>もう 1 つ実務で効くのが <code>allowed-tools</code> です。これは「このスキルが有効な間、列挙したツールを許可確認なしで使ってよい」という<strong>事前承認</strong>で、ツールを<em>制限</em>するものではありません（許可リストに無いツールは通常どおりあなたの permission 設定に従います）。たとえばコミット用スキルなら次のように書いておくと、起動するたびに git コマンドの承認を求められずに済みます。</p>
<pre><code>---
name: commit
description: 現在の変更をステージしてコミットする
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---
現在の変更をConventional Commits形式でコミットしてください。
1. `git status` で変更を確認
2. 関連する変更をステージ
3. 適切な型（feat/fix/docs等）でコミットメッセージを作成
</code></pre>
<p>ただしプロジェクトの <code>.claude/skills/</code> に入れたスキルの <code>allowed-tools</code> は、そのフォルダの<strong>workspace trust（信頼）ダイアログを承認してから</strong>有効になります。スキルは自分自身に広いツール権限を与えられるので、知らないリポジトリを信頼する前にプロジェクトスキルの中身は必ず確認してください。</p>
<h2>サブエージェント実行と補助ファイルの同梱</h2>
<p>スキルを<strong>分離したコンテキスト（サブエージェント）で走らせたい</strong>ときは、frontmatter に <code>context: fork</code> を付けます。スキルの本文がそのままサブエージェントを駆動するプロンプトになり、メイン会話の履歴にはアクセスしません。重い調査やコード生成を本流のコンテキストから切り離せるので、トークン管理の面で効きます。</p>
<p>公式の例は、リサーチを <code>Explore</code> エージェントで走らせるスキルです。</p>
<pre><code>---
name: deep-research
description: トピックを徹底的に調査する
context: fork
agent: Explore
---
$ARGUMENTS について徹底的に調査してください。
1. Glob と Grep で関連ファイルを探す
2. コードを読んで分析する
3. 具体的なファイル参照付きで所見をまとめる
</code></pre>
<p>このスキルを起動すると、(1) 新しい分離コンテキストが作られ、(2) サブエージェントが本文をプロンプトとして受け取り、(3) <code>agent</code> フィールドが実行環境（モデル・ツール・権限）を決め、(4) 結果が要約されてメイン会話に返ります。<code>agent</code> には <code>Explore</code> / <code>Plan</code> / <code>general-purpose</code> といった組み込みエージェントや、<code>.claude/agents/</code> の自作サブエージェントを指定できます（省略時は <code>general-purpose</code>）。注意点として、<code>context: fork</code> は「実行すべきタスク」が明示されたスキル向けです。「この API 規約を使って」のような<em>指針だけ</em>のスキルを fork するとサブエージェントが動かす対象を持たないので、リファレンス型はインラインのまま使うのが正解です。</p>
<p>最後に<strong>補助ファイルの同梱</strong>。スキルはディレクトリに複数ファイルを含められるので、<code>SKILL.md</code> を要点に絞り、詳細な参照資料は別ファイルに逃がせます。大きな API 仕様や例集を毎回コンテキストに載せずに済むのが利点です。</p>
<pre><code>my-skill/
├── SKILL.md # 必須・概要とナビゲーション
├── reference.md # 詳細なAPIドキュメント（必要時のみ読み込み）
├── examples.md # 使用例（必要時のみ読み込み）
└── scripts/
└── helper.py # ユーティリティ（実行されるだけで読み込まれない）
</code></pre>
<p>補助ファイルは、<code>SKILL.md</code> から「何が書いてあって、いつ読むべきか」を参照しておくのがコツです。こう書いておけば、Claude は中身を読む必要が出たときだけ該当ファイルを開きます。</p>
<pre><code>## 追加リソース
- API の詳細は [reference.md](reference.md) を参照
- 使用例は [examples.md](examples.md) を参照
</code></pre>
<p>スクリプトを同梱して実行させる場合、本文では <code>${CLAUDE_SKILL_DIR}</code>（その <code>SKILL.md</code> があるディレクトリ）を使ってパスを書くと、個人・プロジェクト・プラグインのどこにインストールされても正しく解決されます。たとえば <code>python3 ${CLAUDE_SKILL_DIR}/scripts/visualize.py .</code> のように書けば、カレントディレクトリに依存せず同梱スクリプトを呼べます。重い処理はスクリプトに任せ、Claude はオーケストレーションに専念する――これが「単一プロンプトを超える」スキルの基本パターンです。</p>
<h2>最初の 1 個を作る手順とハマりどころ</h2>
<p>ここまでの内容を踏まえて、実際に手を動かす最短手順をまとめます。個人スキル（全プロジェクトで使える）として「リリース前チェックリスト」を作る想定です。</p>
<ol>
<li>個人スキル用ディレクトリを作る：<code>mkdir -p ~/.claude/skills/release-checklist</code></li>
<li><code>~/.claude/skills/release-checklist/SKILL.md</code> を新規作成する</li>
<li>先頭に <code>---</code> で囲んだ frontmatter を書き、<code>description</code> に「いつ使うか」をユーザーが言いそうな言葉で記述する</li>
<li>本文に、Claude に踏ませたいチェック手順を Markdown の番号付きリストで書く</li>
<li>必要なら <code>!`git log --oneline -10`</code> のように動的コンテキスト注入で直近のコミットを差し込む</li>
<li>ファイルを保存する（既存セッションなら変更は再起動なしで反映。トップレベルの skills ディレクトリを新規作成した場合だけ Claude Code を起動し直す）</li>
<li><code>claude</code> を起動し、<code>/</code> を入力して <code>/release-checklist</code> が一覧に出ることを確認する</li>
<li><code>/release-checklist</code> を実行し、想定どおり手順が走るか確認する。出なければ <code>「どんなスキルが使える?」</code>と聞いて登録状況を確認する</li>
</ol>
<p>つまずきやすいポイントを 3 つ、失敗例と正しい形で示しておきます。</p>
<ul>
<li>❌ <strong>SKILL.md にだらだら背景を書く</strong>：本文はセッション中ずっとコンテキストに残るので、長文は毎ターンのトークンコストになる。⭕ 要点は <code>SKILL.md</code> に、詳細は <code>reference.md</code> 等の補助ファイルへ逃がす（目安 500 行以内）</li>
<li>❌ <strong>デプロイ系スキルに <code>description</code> だけ書いて放置</strong>：Claude が「準備できてそう」と判断して自動起動するリスクがある。⭕ 副作用のあるスキルには <code>disable-model-invocation: true</code> を付けて手動専用にする</li>
<li>❌ <strong>frontmatter の <code>name</code> でコマンド名を変えようとする</strong>：入力するコマンド名は<strong>ディレクトリ名</strong>で決まる（<code>name</code> は一覧の表示名）。⭕ <code>/deploy-staging</code> にしたければディレクトリ名を <code>deploy-staging</code> にする</li>
</ul>
<p>「自分が繰り返している手順をスキルにする」――これだけで、毎回のコピペが <code>/コマンド</code> 一発になり、チームにもコミットで配れます。まずは普段いちばん貼り付けている指示文を 1 つ、<code>SKILL.md</code> に移してみてください。</p>
<h2>Skills を起点に Claude Code 運用を仕組み化する</h2>
<p>スキルは単体でも便利ですが、Claude Code の他の仕組みと組み合わせると効きます。<strong>CLAUDE.md</strong> は「変わらない事実」を、<strong>Skills</strong> は「手順・専門知識」を担当し、<strong>カスタムコマンド</strong>は 1 枚で済む定型作業を引き受ける――この役割分担を意識すると、コンテキストを無駄に膨らませずに運用を仕組み化できます。各テーマの実装ガイドは以下も参考にしてください。</p>
<ul>
<li><a href=](https://claudecode-cases.com/wp-content/uploads/2026/06/fig_skills.png)
Claude Code カスタムスラッシュコマンド作成ガイド（Skills に統合された .claude/commands/ 方式の詳解）
context: fork でスキルをサブエージェント実行する応用）FAQ
Q. Skills と CLAUDE.md、どちらに書くべき?
変わらない「事実」（技術スタック、命名規約の根幹）は CLAUDE.md、繰り返す「手順」やチェックリスト・専門知識は Skills です。CLAUDE.md の一節が事実ではなく手順に育ってきたら、スキルに切り出すサイン。スキル本文は呼び出し時しか読み込まれないので、長い参照資料を持ってもコストになりません。
Q. これまで作った .claude/commands/ は捨てる必要がある?
ありません。カスタムコマンドは Skills に統合されましたが、既存の .claude/commands/*.md はそのまま動作し、同じ frontmatter をサポートします。補助ファイルの同梱や自動ロードが欲しくなったらスキルへ移行する、で十分です。
Q. スキルを Claude に勝手に使われたくない。
frontmatter に disable-model-invocation: true を付けると、あなたが /name で起動したときだけ動き、Claude による自動起動を止められます。逆に / メニューから隠して背景知識として Claude にだけ使わせたいなら user-invocable: false を使います。
Q. チームで共有するには?
プロジェクトの .claude/skills/ に置いてバージョン管理にコミットすれば、リポジトリを開いた全員が同じスキルを使えます。組織全体に配るなら managed settings（エンタープライズ）、他の拡張とまとめて配布するならプラグインの skills/ ディレクトリという選択肢もあります。
まとめ
Claude Code の Skills は、「毎回コピペしている手順書」を SKILL.md 1 ファイルに移すだけで作れます。CLAUDE.md と違って本文はオンデマンド読み込みなので、長い手順や専門知識を抱えてもコンテキストを圧迫しません。description を丁寧に書けば Claude が自動で使い、/skill-name で自分からも呼べる。disable-model-invocation や allowed-tools、context: fork、補助ファイルの同梱まで使いこなせば、個人の作業効率化からチームの運用標準化まで一気に広がります。
今日のアクション
- いちばん頻繁に貼り付けている指示文を 1 つ選び、
~/.claude/skills/<name>/SKILL.mdにdescription+ 手順として書き写す /skill-nameで起動できることを確認し、副作用のあるものにはdisable-model-invocation: trueを付ける- チームで使うものはプロジェクトの
.claude/skills/に移してコミットし、全員で共有する
Uravation では、Claude Code を業務で使いこなすための個別指導・導入支援を行っています。スキルやサブエージェントを含む実践的なワークフロー設計に関心がある方は、業務導入完全ガイドもあわせてご覧ください。
著者：佐藤傑（さとう・すぐる）。株式会社Uravation 代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
出典
- Claude Code 公式ドキュメント「Extend Claude with skills」（SKILL.md・frontmatter・呼び出し制御・補助ファイル・サブエージェント実行の一次情報。2026年6月時点）
- Claude Code 公式ドキュメント「Subagents」（context: fork とサブエージェントへのスキル事前読み込みの仕様）
- Claude Code 公式ドキュメント「Commands」（組み込みコマンドとバンドルスキルの一覧・位置づけ）
- Agent Skills（オープン標準）（Claude Code のスキルが準拠する標準仕様）
