Claude Codeのスキルとは｜繰り返す業務をSkillsへ分ける方法

2026年7月21日時点のClaude Code公式ドキュメントでは、SkillsはSKILL.mdに書いた指示をClaudeの道具として追加する機能と説明されています。Claude Codeは関連すると判断した場面でスキルを読み込み、ユーザーも /skill-name の形で直接呼び出せます。全文を常に会話へ入れる形と異なり、使うときに本体が読み込まれる点が、CLAUDE.mdとの大きな違いです。

この仕組みは、AI駆動開発で起きやすい小さな反復に向いています。レビュー観点を貼る。リリース前の確認手順を貼る。API設計の注意点を貼る。何度も同じ指示を使っているなら、それはその場のプロンプトというより、作業資産として扱えます。Claude Codeの全体像を押さえると、常に共有すべき前提と、必要なときだけ読む手順を分けやすくなります。

Claude Codeのスキルは、Claudeを自動的に万能にする設定ではありません。人が暗黙に持っていた作業の型を、用途、手順、参照ファイル、権限の境界と一緒に固定するものです。読み込む条件が曖昧なスキルは、再利用部品として機能せず、いつ混ざるかわからない長い指示になります。

スキル化の候補は、繰り返し発生し、手順に分解でき、結果を文章やコマンドで確認できる作業です。公式ドキュメントも、同じ指示、チェックリスト、複数ステップの手順を何度も貼っている場合や、CLAUDE.mdの一部が事実説明から手順へ育った場合を作成の目安にしています。

差分レビュー、コミット前確認、特定フレームワークでのテスト追加、API仕様に沿った実装、社内文体に合わせたドキュメント修正は候補になります。プロダクトの基本方針、用語集、リポジトリの恒久的な説明は、プロジェクトの常設メモリに置くほうが自然な場合があります。判断に迷う作業ほど、対象と完了条件を書けるかを先に見ます。

Claude Codeのスキルは、スキル用ディレクトリの中にSKILL.mdを置いて作ります。SKILL.mdはYAMLフロントマターと本文で構成されます。フロントマターはClaude Codeが用途や呼び出し方を判断する領域、本文はスキルが読み込まれたあとClaudeが従う作業指示です。

公式ドキュメントでは、フロントマターの各項目は任意ですが、descriptionは推奨されています。Claudeが自動で使うか判断する材料になるためです。説明文には、何をするスキルかに加えて、どんな依頼や状況で使うのかを先に書きます。名前の見栄えより、誤って呼ばれにくい説明のほうが実務では効きます。

最小構成は、用途がわかるdescriptionと、作業手順です。複雑な仕様書、サンプル出力、テンプレート、検証スクリプトまで必要なら、SKILL.mdへ詰め込まず、同じディレクトリのサポートファイルとして置きます。公式ドキュメントはSKILL.mdを500行未満に保ち、詳細な参照資料を別ファイルへ移す考え方を示しています。スキル本文は読み込まれたあと会話コンテキストに残るため、行数の管理は読みやすさだけの問題ではありません。

作る順番は、対象業務を一つに絞ることから始まります。Claudeが使うべき場面をdescriptionへ書き、本文に手順、禁止事項、確認方法、参照ファイルを置く。複数の業務を一つのスキルに入れると、呼び出し条件も成果物もぼやけます。

スキルは置き場所によって適用範囲が変わります。公式ドキュメントでは、Personalは ~/.claude/skills/skill-name/SKILL.md、Projectは .claude/skills/skill-name/SKILL.md、Pluginは plugin/skills/skill-name/SKILL.md に置く形です。ここでskill-nameとpluginは、それぞれ実際のディレクトリ名を表します。Enterpriseスキルは管理設定側で扱われ、組織内のユーザーへ適用されます。

Personalスキルは、どのプロジェクトでも同じ癖で使いたい作業に向きます。自分用の差分要約、メモ整理、汎用的な調査手順などです。Projectスキルは、リポジトリ固有のビルド、検証、設計ルールに向きます。チームで共有する手順なら、プロジェクト内に置くほうがレビューと再現性を説明しやすくなります。

同名のスキルが複数階層にある場合、公式ドキュメントではEnterpriseがPersonalを、PersonalがProjectを上書きするとされています。Project配下のネストした .claude/skills/ は、対象ファイルに応じて発見され、同名の場合はディレクトリ名を含む呼び出し名も使われます。モノレポでは、ルートの共通スキルと各パッケージの固有スキルを分けられますが、名前の衝突と適用範囲を見ておかないと、想定と違う指示が効いたように見えます。

既存の .claude/commands/ は引き続き機能します。公式ドキュメントでは、サポートファイルなどを扱えるSkillsが推奨されています。カスタムコマンドが増えているチームでは、全面移行を急ぐより、参照資料や検証スクリプトを持つものからSkillsへ移すほうが現実的です。Claude Codeの基本的な使い方と合わせて、どの単位をプロジェクト資産にするかを決めます。

安全に再利用したいなら、スキルの中身を書く前に呼び出し方を決めます。通常はユーザーもClaudeもスキルを呼び出せます。disable-model-invocation: true を設定すると、Claudeの自動読み込みを止め、ユーザーが明示的に /skill-name で呼ぶ運用にできます。

レビュー観点や命名規則のような知識は、自動呼び出しと相性がよい場面があります。デプロイ、外部送信、破壊的な変更、権限を伴う作業は、明示的な呼び出しに寄せるべきです。公式ドキュメントも、deployやsend-slack-messageのような副作用を持つワークフローでは、ユーザーだけが呼び出す例を示しています。

allowed-toolsは、そのスキルを呼んだターンだけ指定ツールを事前許可する項目です。指定していないツールは通常のpermission settingsに従います。disallowed-toolsは、スキルが有効な間に使わせたくないツールを外すための項目です。便利なショートカット扱いにせず、スキル単位の権限棚卸しとして扱うほうが、運用上の説明が通ります。

Claude Codeのsettingsにも階層があります。公式設定ドキュメントでは、Managed settingsが最上位で、ユーザーやプロジェクト、コマンドラインから上書きできません。組織導入では、個々のスキルだけで境界を作ろうとせず、Managed settingsで許可・禁止の線を補強します。スキルは手順の再利用、settingsは実行環境の統制と分けると、責任範囲が崩れにくくなります。

チームでClaude Code Skillsを使うときは、小さな作業を一つ選びます。全社標準を先に作ると、対象が広くなり、呼び出し条件も権限も曖昧になります。プルリクエスト前のセルフレビュー、特定ディレクトリだけのテスト確認、ドキュメント更新漏れの確認など、影響範囲が小さく成果物をレビューできる作業から始めます。

スキルの責任範囲も文書化します。何を入力として扱うか。どのファイルを読むか。実行してよいコマンドは何か。人が確認する前に変更してはいけないものは何か。ここが薄いままだと、スキルは手順書から離れ、「よしなに進める」依頼になります。

更新方法も運用に含めます。Claude Codeは既存のスキルディレクトリ内のSKILL.mdの追加・編集・削除を監視し、現在のセッションに反映します。セッション開始時に存在しなかったトップレベルのskillsディレクトリを作った場合は、再起動が必要と説明されています。スキルが効かないときは、指示の品質だけでなく、置き場所と反映タイミングも確認します。

Claude Codeのスキルは、繰り返す業務を小さな作業資産に変える仕組みです。役割は長いプロンプトの保存にとどまらず、使う場面、手順、参照資料、権限の境界をまとめることにあります。繰り返し発生し、対象を限定でき、確認方法を書ける作業だけをSkillsへ分けます。

安全に再利用する鍵は、呼び出し方と権限設計にあります。知識やレビュー観点は自動呼び出しでも扱いやすい。デプロイ、送信、破壊的変更のような副作用を持つ作業は、disable-model-invocation: true で人が明示的に呼ぶ形へ寄せる。さらに、Managed settingsで組織の禁止事項を補強する。ここまで決めると、毎回貼る指示はチームで扱える手順に変わります。

Cotomuは、AI駆動開発の研修、導入支援、技術顧問として、Claude CodeやCodexを公開仕様に基づいて扱います。特定ベンダーの公式パートナーや認定は示しません。生産性や品質向上の保証も行いません。研修は30万円から、導入パッケージは50万円から、技術顧問は15万円/月から、初回60分相談は無料です。既存の開発フロー、権限設計、レビュー文化に合わせて、どの作業をスキル化し、どこを人が判断するかを整理することが出発点になります。