【Claude Code】Skillsの運用に正解を出してみる

2026年7月16日2026年8月10日

はじめに：CLAUDE.mdの肥大化とコマンドの置き場に悩んでいませんか

「CLAUDE.mdにルールを書き足し続けた結果、毎回のやり取りでコンテキストを圧迫している」
「2026年1月にカスタムスラッシュコマンドがSkillsへ統合されたと聞いたが、既存の .claude/commands/ はどうすればいいのか分からない」
「便利な手順書を個人で作ったものの、チームへ配る方法と統制のやり方が決まっていない」

Claude Codeを数か月使ったチームは、だいたいこの3つの課題に行き着きます。結論から言うと、この3つはすべて Agent Skills（以下、Skills）で解決できます。Skillsは、作業ごとの手順書をファイルとしてClaude Codeに持たせておき、必要なときだけ読み込ませる公式機能です。CLAUDE.mdは書いた内容の全文が毎回読み込まれますが、Skillsはコンテキスト（Claudeが一度に読み込める情報の枠）をほとんど使いません。そのため、手順書を何十個でも持たせられます。

本記事では、スラッシュコマンド統合後の「新常識」を整理したうえで、コピペで動く自作スキルのレシピとチームへの配布・統制までを解説します。仕様の説明はすべてAnthropic公式ドキュメント（Claude Code Skills リファレンス）に、動作の説明はすべて実機検証に根拠を置いています（検証環境は記事末尾に記載）。

なお、Claude Code自体をこれから導入する段階の方は、先に全体像から入ると本記事を読み進めやすくなります。Claude Codeの導入から実務活用までを体系的に押さえたい方はこちらもご参考ください。

あわせて読みたい

Claude Code完全入門：インストールから実務活用まで、AIコーディングの新常識を徹底解説はじめにターミナルに常駐し、コードベース全体を読み、ファイルを編集し、シェルを叩き、Gitを操作する。「AIエンジニアと一緒に開発する」感覚に最も近いツール、そ…

この記事を読むことで得られること:

Skillsの仕組み（3段階の読み込み）と、CLAUDE.md・Hooks・サブエージェントとの使い分け
スラッシュコマンド統合で変わったこと・既存 .claude/commands/ の扱い
コミットメッセージ規約・文体チェック・読み取り専用監査など、そのまま使えるスキルのレシピ
サブエージェント分離実行（context: fork）・発動範囲の限定（paths）など、2026年に追加された新機能の使いどころ
Git共有・組織設定によるチーム配布と、外部製スキルを導入するときの監査観点

基礎知識：Agent Skillsとは何か

CLAUDE.mdの限界と「段階的読み込み」

Skillsの実体は、SKILL.md という名前のMarkdownファイルを入れたフォルダです。ここに手順書を書いておくと、Claudeが必要と判断したときだけ読み込みます。2025年10月16日にclaude.ai・Claude Code・Claude APIの3つで同時にリリースされ、2025年12月にはオープン標準（agentskills.io）になりました。オープン標準とは、どの会社のツールでも使える共通の書き方のことです。現在はVS CodeやCodex CLIなどAnthropic以外のツールも同じ SKILL.md を読めるため、一度書いた手順書は長く使える資産になります。

CLAUDE.mdとの最大の違いは、コンテキストの使い方です。Skillsは、必要になるまで詳細を読み込まない段階的読み込み（公式ドキュメントでは progressive disclosure）という3段階の設計になっています。

段階	読み込まれるもの	タイミング	コンテキスト消費
レベル1	name と description（スキル名と説明文）	セッション中は常時	約100トークン/スキル
レベル2	SKILL.md 本文	スキル発動時のみ	5,000トークン未満を推奨
レベル3	補助ファイル・スクリプト	本文から必要になったときのみ	スクリプトは実行結果の出力のみ

補足: トークン目安は公式ドキュメント（Agent Skills Overview）の記載に基づきます。トークンは、Claudeが読み書きする文章量の単位です（日本語ではおおむね1〜2文字で1トークン）。たとえば手順書10本・合計2万トークン相当をCLAUDE.mdに直書きすると、毎回2万トークンが読み込まれます。Skills化すれば、普段読み込まれるのは1本あたり約100トークン（名前と説明文）だけで、合計でもおよそ1,000トークンで済む計算です。

CLAUDE.mdの書き方そのものを見直したい方はこちらもご参考ください。

あわせて読みたい

CLAUDE.md 【完全実装ガイド】Claude Code 業務テンプレ10選 Claude Code を業務で使い始めたものの、毎セッションごとに「ですます調で」「専門用語は避けて」「勝手にリファクタしないで」と説明し直している……そんな摩擦が積み…

スラッシュコマンド統合の新常識（2026年1月〜）

Claude Codeでは長らく .claude/commands/*.md にカスタムスラッシュコマンドを置く方式が使われてきましたが、2026年1月末（v2.1.3）に、カスタムスラッシュコマンドはSkillsへ統合されました。押さえるべき事実は4つです。

既存の .claude/commands/ は今も動きます。 移行は必須ではありません。
.claude/commands/review.md と .claude/skills/review/SKILL.md は、どちらも同じ /review コマンドを作ります。同名で共存した場合はSkills側が優先されます。
旧commandsも「自動発動」するようになりました。 統合前は、基本的に自分で /名前 と打ったときだけ動くものでした。統合後は、スキルの説明文＝description（説明文が無いファイルでは本文1行目が説明文の扱い）に会話の内容が合うと、頼んでいなくてもClaudeが自動で実行します。
補助ファイルの同梱・発動制御・サブエージェント連携などの新機能はSkills側にしか追加されません。新しく作るものはSkillsで書いてください。

3.が実務上いちばんの注意点です。デプロイやファイル生成のように、勝手に実行されると困る手順には、frontmatter（ファイル冒頭を --- で囲んで書く、スキルの設定欄）に disable-model-invocation: true を付けてください。これで、自分で呼んだときだけ動く状態に戻せます（書き方は2章で説明します）。

なお、Web版Claude（claude.ai）にもWordやExcelを扱う「Skills」があります。仕様は同じ標準に基づきますが、プラットフォーム間でスキルは同期されません。claude.ai側の活用はこちらの別記事で紹介しているため、本記事はClaude Codeで自作するスキルに絞ります。

あわせて読みたい

Claude Skillsの使い方【7事例】業務自動化を徹底解説｜現場担当の時短を実現 Claude Skillsは、Claudeに自社の手順書を持たせておく仕組みです。実体はSKILL.mdという1枚のMarkdownファイルで、そこに「何をするスキルか」と「どういう手順・判断…

CLAUDE.md・Hooks・サブエージェントとの使い分け

Skillsの役割は「必要時だけ読む手順書」です。似た機能が他にもあるので、使い分けを整理します。サブエージェントは、メインの会話とは別に立ち上がるもう1つのClaudeのことです。

機能	役割	読み込み	向いている用途
CLAUDE.md	常に適用するルール	毎回全文	コーディング規約の要点、プロジェクト概要
Skills	必要時だけ読む手順書	発動時のみ本文	定型作業の手順、業務ノウハウ
Hooks	決めた処理を必ず実行する仕組み	LLMを経由しない	危険コマンド遮断、品質ゲート
サブエージェント	別の作業スペースへの分担	呼び出し時	大規模調査、並列作業

補足: SkillsはあくまでLLMへの指示であり、確実な強制はできません。確実に止めたい処理はHooksと組み合わせます（3-5のレシピで実演します）。Claude CodeのHooksによる処理制御についてはこちらもご参考ください。

あわせて読みたい

Hooksを活用してClaude Codeの処理制御に正解を出してみるはじめに：Hooks の重要性「開発チームに Claude Code を配布したが、AIが勝手に .env を読み取らないか心配だ」「コーディング規約を CLAUDE.md に書いても、AIが守っ…

実装のステップ：最初のスキルを10分で作る

スキルの作り方は「ファイルを置く → 発動を設計する → 補助ファイルを足す」の3ステップです。例として、コミットメッセージ規約のスキルを作ります。

どんなスキルかを先に説明します。コミット前に /commit-msg と打つと、Claudeがステージ済みの変更（git add した変更）の内容を読み、チームの書式規約（1行目は 種別: 要約、本文に変更の理由を1〜2行）に沿ったコミットメッセージの案を返します。人間は返ってきた案を確認して、そのままコミットに使うだけです。コミットメッセージの書式は人によってブレやすく、規約を毎回思い出すのも面倒なので、手順書にしておく価値があります。

まず2-1でこのスキルを完成させます。続く2-2と2-3では、残りの2ステップ（発動の設計・補助ファイルの同梱）の考え方を説明します。

最小のSKILL.mdを置く

プロジェクト直下に次のフォルダとファイルを作るだけで、/commit-msg コマンドが使えるようになります。

---
name: commit-msg                                  # 一覧に表示される表示名（コマンド名はフォルダ名で決まる）
description: ステージ済みの変更からコミットメッセージ案を作成する   # スキルの説明文（自動発動のスキルでは発動判定に使われる）
disable-model-invocation: true                    # 自動発動を禁止し /commit-msg 専用にする
argument-hint: "[補足したい変更の意図(任意)]"        # /commit-msg を選んだとき入力欄に出る記入例
---

## 参照情報

- ステージ済みの差分の概要: !`git diff --staged --stat`

## タスク

上の差分をもとに、次の規約でコミットメッセージを1つ提案してください。
変更内容の詳細が必要な場合は `git diff --staged` で確認してください。

- 1行目: `種別: 要約`（種別は feat / fix / docs / refactor のいずれか。1行目は50字以内）
- 本文: なぜその変更をしたのかを1〜2行で書く
- ユーザーからの補足: $ARGUMENTS

ファイルの構造は2部構成です。冒頭の --- で囲まれた部分がfrontmatter（スキルの動かし方を決める設定欄）、その下がスキル発動時にClaudeへ渡される指示本文です。frontmatterの各フィールドの意味はコード内のコメントのとおりで、以降のレシピもすべてこの構造で書きます。

このレシピには、スキルの基本要素が4つ入っています。

!`コマンド` によるコマンド出力の埋め込み: 本文がClaudeへ送られる直前にシェルコマンドが実行され、書いた場所が実行結果に置き換わります。差分やブランチ名など「いまの状態」を手順書に自動で差し込めます。
$ARGUMENTS: /commit-msg チケット番号を入れて のように打ったとき、コマンド名の後ろに書いた文字（＝引数）がそのまま入る場所です。引数を1つずつ取り出したいときは $0 $1 と書きます。番号は0から数えるので、/commit-msg 123 修正 なら $0 が 123、$1 が 修正 です。frontmatterの arguments で引数に名前を付ける方式もあります（arguments: [issue, branch] と定義すると、本文で $issue $branch と書けます）。
argument-hint: 入力欄で /commit-msg を選んだとき、後ろに何を書けばよいかの記入例として薄く表示される文字列です。スキルの動作は変えず、使う人への案内だけをします。
disable-model-invocation: true: コミットメッセージ作成は求めていないタイミングで自動実行されると邪魔なので、明示呼び出し専用にしています。

自動発動を設計する（descriptionの書き方）

自動発動させたいスキルでは、逆に disable-model-invocation を付けず、descriptionの書き方を作り込みます。Claudeは各スキルのdescriptionだけを見て「今この手順書が必要か」を判断するためです。

「何をするスキルか」に加えて「いつ使うか」を書く（例:「〜のとき使う」）。補足フィールド when_to_use も併用できます
スキル一覧上では description と when_to_use の合計が1,536字で切り詰められるため、重要な使いどころを先頭に書く

また、disable-model-invocation: true を付けたスキルはdescriptionすら常駐しなくなるため、コンテキスト節約の観点でも「自動発動が不要なものには必ず付ける」が新常識です。

補助ファイルとスクリプトを同梱する

スキルフォルダには SKILL.md 以外のファイルも置けます。公式が推奨する構成は次のとおりです。

ポイントは、参照ファイルはClaudeが必要と判断して読んだときだけコンテキストに入り、スクリプトは実行結果の出力だけが入ることです。毎回同じ手順で済む処理はスクリプトにしておくと、コンテキストを使わず、結果も毎回同じになります。この使い方は3章のレシピで実演します。

読みながら「自社だとどうなるか」が気になった方へ

Claude Codeを企業で使うときの進め方と、社内に定着させるまでの流れをセミナー資料にまとめました。無料で公開しています。

Claude Codeと企業DXの資料をダウンロード

Claude Codeを組織で使える状態にするところは、AI人材研修でご支援しています。

応用・発展：実用レシピ集とチーム運用

ここからが本記事の中心です。用途別のレシピを紹介します。いずれも、実際に動かして動作を確認済みです（検証環境は記事末尾に記載）。

レシピ1：文体チェック `/review-style`（参照ファイル同梱）

社内の文章規約をreferences/に持たせ、ドキュメント執筆時に自動発動させるスキルです。

---
name: review-style                # 一覧に表示される表示名
description: ブログ記事や社外向けドキュメントの文体をチェックする。文章のレビュー・推敲を頼まれたとき使う   # 「何をするか＋いつ使うか」で自動発動させる
---

対象の文章を references/style-guide.md の規約に照らしてレビューし、
違反箇所を「原文 → 修正案 → 根拠となる規約番号」の形式で列挙してください。

規約全文（数千字あっても可）は references/style-guide.md に置きます。この参照ファイルは、1-1の表で示した段階的読み込みのレベル3（補助ファイル）にあたり、必要になったときしか読まれません。そのため、CLAUDE.mdに書くのと違い、コーディング作業中のコンテキストを一切消費しません。実際に、/review-style と打たなくても、「この文章を推敲してください」と頼むだけでこのスキルが自動発動し、規約番号つきの指摘が返ってきます。descriptionに「いつ使うか」を書いた効果です（2-2参照）。

レシピ2：読み取り専用のセキュリティ監査 `/security-audit`（書き込み・実行系ツールの除外）

disallowed-tools を使うと、スキル実行中にClaudeが使えるツール（ファイル編集・コマンド実行などの操作手段）を減らせます。書き込み・実行系のツールを外しておけば、「調査はするが変更はしない」を仕組みとして保証できます。

---
name: security-audit                # 一覧に表示される表示名
description: リポジトリ内の機密情報の混入や危険な設定を点検する   # 説明文
disable-model-invocation: true      # 監査は明示的に実行する
disallowed-tools: Edit, Write, NotebookEdit, Bash, PowerShell   # このスキル実行中は書き込み・実行系ツールを使えなくする
---

リポジトリを次の観点で点検し、リスクの高い順に報告してください。修正はしないでください。

1. APIキーやパスワードらしき文字列が、ハードコード（コード内に直接記述）されていないか
2. .env などの機密ファイルが .gitignore から漏れていないか
3. 設定ファイルで、必要以上に広い権限が許可されていないか

プロンプトに「修正するな」と書くだけでは、Claudeが指示を読み違えたときに防げません。ツールを使えない状態にしておけば、読み違えても書き込みようがありません。実際に、このスキルの実行中にWriteツールでの書き込みを試みさせても、権限エラーで拒否されてファイルは作られません。なお、外すツールは環境に合わせて選びます。Windowsには、Bash とは別に PowerShell ツール（PowerShellのコマンドを直接実行するツール）が有効になっている環境があります（公式ツールリファレンスに一覧があります）。この環境で Bash だけを外すと、PowerShell経由のシェル実行という抜け道が残ります。上の例に PowerShell を含めてあるのはこのためです。

1つ注意があります。似た名前の allowed-tools は、「並べたツールを確認なしで使えるようにあらかじめ許可しておく」ためのフィールドで、それ以外のツールを使えなくする効果はありません。ツールを使えなくするのは disallowed-tools です。ここを取り違えると、読み取り専用のつもりの監査スキルが、実際には書き込みできる状態のまま動きます。

レシピ3：週報ドラフト `/weekly-report`（スクリプト同梱）

集計はスクリプトに任せ、Claudeには文章化だけをさせる分業型のレシピです。

${CLAUDE_SKILL_DIR} は「このスキルのフォルダ」を指す変数です。これを使っておけば、スキルをどこに置いてもスクリプトを正しく見つけられます。スクリプト本体のコードはコンテキストに入らないので、集計処理がどれだけ長くなってもコンテキスト消費は増えません。

レシピ4：調査をサブエージェントへ分離 `/deep-research`（context: fork）

2026年に追加された context: fork を使うと、スキルをサブエージェント（メイン会話とは別のClaude）として実行できます。調査で大量のファイルを読んでも、読んだ内容はサブエージェント側に積まれるので、メイン会話のコンテキストを消費しません。

agent には Explore のほか Plan・general-purpose・自作サブエージェント名を指定できます。途中経過は要らず結論だけ欲しい調査に向いています。

レシピ5：Hooksと組み合わせたガードレール付きデプロイ

手順書（スキル本文）はClaudeへのお願いなので、読み違いや例外で破られる可能性が残ります。破られたら事故になる禁止事項は、1-3で整理したとおりHooks（決めた処理を必ず実行する仕組み）に持たせます。このレシピでは「デプロイの手順」をスキルに、「mainブランチ以外からのデプロイ禁止」をHooksに分担させます。

まず、スキル本体は手順書に専念させます。

次に、ブランチ検証のフックスクリプトを .claude/hooks/check-branch.sh に置きます。

ブランチ検証のフックスクリプトを .claude/hooks/check-branch.shに置く

最後に、このスクリプトを .claude/settings.json のHooksに登録します。

解説用（コメント付き。JSONはコメント不可のため、このままでは使えません）:

{
  "hooks": {
    "PreToolUse": [            // ツール実行の直前に割り込むイベント
      {
        "matcher": "Bash",     // Bashツールの実行だけを対象にする
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/check-branch.sh" }   // exit 2 なら遮断
        ]
      }
    ]
  }
}

貼り付け用（.claude/settings.json にそのまま使えます）:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/check-branch.sh" }
        ]
      }
    ]
  }
}

実際に、developブランチで /deploy-staging を実行すると、手順1のテスト実行に入る前にHooksが遮断し、「ブロック: main ブランチ以外からはデプロイできません（現在: develop）」と表示されます。mainブランチではそのまま通ります。スキルだけでは「お願い」止まりだった禁止事項が、Hooksとの組み合わせで確実な強制になります。

なお、この例のmatcherは Bash 全体を対象にしているため、main以外のブランチではデプロイと無関係なコマンド実行も止まります。デプロイ専用のリポジトリ以外で使う場合は、フックスクリプト側で「コマンドに deploy.sh を含むときだけ遮断する」のように条件を絞ってください。また、3-2で説明した PowerShell ツールが有効な環境では、matcherが Bash だけだとPowerShell経由のコマンド実行を遮断できません。両方を対象にするには "matcher": "Bash|PowerShell" と書きます。

補足: 公式ドキュメントには、スキルのfrontmatterに hooks を書いて「そのスキルの実行中だけ有効なHooks」を同梱する方式（スキル限定Hooks）も記載されています。検証環境（記事末尾）で切り分けたところ、この方式でも登録したコマンド自体は実行されるものの、終了コード2による遮断は効きませんでした（まったく同じ内容をsettings.jsonに書けば遮断されます）。一方、コマンドの出力をJSON形式の判定（permissionDecision: "deny"）に変えると、スキル限定Hooksでも遮断できることを確認しています。ただし、環境によってはスキル限定Hooks自体が動かないという報告も公式リポジトリに複数あるため（例: anthropics/claude-code Issue #39468）、確実に止めたい用途では本レシピのようにsettings.json側へ置くのが安全です。

レシピ6：`paths` で発動範囲をディレクトリ限定

モノレポ（1つのリポジトリに複数のアプリやサービスをまとめた構成）では、フロントエンドの規約スキルがバックエンドの作業中にも発動候補に挙がってしまいます。paths を指定すると、条件に合うファイルを扱っているときだけスキルが自動発動の対象になり、この無駄をなくせます。

---
name: component-conventions   # 一覧に表示される表示名
description: Reactコンポーネントの実装規約。コンポーネントの新規作成・修正のとき使う   # 説明文
user-invocable: false        # ユーザーが / で呼ぶ必要のない背景知識型スキル
paths:                       # 合致するパスを列挙（自動発動の範囲を限定）
  - "src/components/**"      # このパス配下を扱うときだけ発動候補になる
---

コンポーネントを作成・修正するときは次の規約に従ってください。

- 1つのファイルには1つのコンポーネントだけを書く
- 色や余白などのスタイルは専用のCSSファイルに書き、コンポーネントの中に直接書かない

user-invocable: false を足すと、/ の一覧から消え、人間からは呼べなくなります。Claudeが該当フォルダのファイルを扱うときだけ自動で参照される、裏方の規約スキルになります。実際に、src/components/ 配下のファイルの修正を相談すると、Claudeがこのスキルの規約2点を自分から挙げます。無関係なファイルの相談では発動しません。

既存 `.claude/commands/` の棚卸しと移行判断

統合後の挙動変化（1-2）を踏まえると、手元にある既存のcommandsファイルは、次の基準で1つずつ確認していくのが効率的です。

既存ファイルの状態	リスク	対応
frontmatterなし	本文1行目がdescription扱いになり誤発動しやすい	最優先でSkills化
副作用あり（生成・デプロイ等）	相談しただけで自動実行される恐れ	`disable-model-invocation: true` を付与
補助ファイルが欲しい	commands形式では同梱できない	Skills化して references/scripts を追加
単純なプロンプト定型文	低	そのままでも可（新機能が欲しくなったら移行）

移行作業自体は .claude/commands/review.md を .claude/skills/review/SKILL.md へ移すだけです。同名共存中はSkills側が優先されるため、移行期間中に二重実行される心配はありません。

3-8. チーム配布と統制

個人で作り込んだスキルをチームに広げる経路は3つあります。

Projectスキル（.claude/skills/）をGitにコミットする: リポジトリをcloneした全員に同じスキルが配られます。まずはこれで十分です
Pluginとして配布する: 複数リポジトリで共通利用するスキル群は、プラグイン化してマーケットプレイス経由で配ります
managed settings（組織の管理者設定）で配布する: 全社必須のスキルを管理者が一括配布します。同名スキルの優先順位は「Enterprise ＞ Personal ＞ Project」です

managed settingsを使うには組織プランの導入が前提になります。Claude Teamの法人導入を検討されている方はこちらもご参考ください。

あわせて読みたい

【情シス向け】Claude Team の法人導入で失敗しない完全ガイド「Claudeを全社で使いたい」と言われたとき、最初に決めるべきこと「Claudeを全社で使えるようにしてほしい」という相談が、情シス・DX推進部門に持ち込まれるケースが…

配るだけでなく、絞る側の機能もあります。自作スキルなら、frontmatterに disable-model-invocation: true を書けば自動発動を止められます。しかし、管理者やプラグインから配られたスキルは、SKILL.mdを自分で編集できません（編集しても配布元の更新で戻ります）。そこで使うのが、settings.jsonの skillOverrides です。スキル本体を触らずに、受け取る側でスキルごとの見え方を4段階（on＝通常 / name-only＝名前のみ / user-invocable-only＝人間だけが呼べる / off＝無効）に変えられます。さらに強く止めたい場合は、Permissionルールの Skill(名前) を使うと、実行そのものを許可・拒否できます。skillOverrides が「どう見せるか」、Permissionルールが「実行させるか」の担当です。

解説用（コメント付き。JSONはコメント不可のため、このままでは使えません）:

{
  "skillOverrides": {                         // キーにスキル名を書き、そのスキルだけに適用する
    "deploy-staging": "user-invocable-only",  // 自動発動を禁止し、人間だけが / で呼べる状態にする
    "legacy-notes": "off"                     // スキルを完全に無効化する
  }
}

貼り付け用（.claude/settings.json にそのまま使えます）:

補足: スキル本文の !`コマンド` 実行自体を組織として禁止したい場合は、managed settingsで disableSkillShellExecution: true を設定します。

3-9. セキュリティ：外部製スキルは「ソフトウェアのインストール」として扱う

スキルはシェル実行とファイルアクセスを伴うため、Anthropic公式も「信頼できるソース（自作またはAnthropic提供）のスキルだけを使うこと」と明確に注意喚起しています。GitHubで公開されているスキル集を導入する場合は、最低限次を監査してください。

SKILL.md本文・スクリプトに、外部URLへデータを送る処理が含まれていないか
!`コマンド` や scripts/ が、スキルの目的と無関係なファイル（認証情報など）へアクセスしていないか
descriptionが実際の処理内容と一致しているか（目的を偽装したスキルはツールの目的外利用につながります）

スキルは機密情報を含むリポジトリでも動きます。

外部から取得したデータに悪意ある指示が混ざる問題は、スキルに限らずAIエージェント全般に共通する課題です。Claude Codeを企業で安全に運用するためのセキュリティ設計についてはこちらもご参考ください。

あわせて読みたい

Claude Codeのセキュリティリスクと設定｜社内導入の判断基準はじめに Claude Codeは「AIがリポジトリを読み、ファイルを編集し、シェルを叩く」ツールです。便利な反面、コードベースへの自律的アクセス・シェル実行・外部API通信…

まとめと結論

Skillsは「必要時だけ読まれる手順書」。 常駐は約100トークン/スキルのメタデータのみで、CLAUDE.mdの肥大化問題を構造的に解決します
スラッシュコマンド統合後の新常識は2つ。 新しく作るものはSkillsで統一し、副作用のある手順には disable-model-invocation: true を必ず付けます（旧commandsも自動発動するようになったため）
2026年の拡張機能で用途が広がりました。 context: fork で調査を分離し、paths で発動範囲を絞り、disallowed-tools で書き込み・実行系ツールを外した読み取り専用の監査も作れます。破られたら困る禁止事項は、Hooksと組み合わせて強制します
チーム展開はGitコミット→Plugin→managed settingsの3段階。 skillOverrides とPermissionルールで統制し、外部製スキルは導入前に必ず監査します

導入前チェックリスト:

Claude Codeを2026年1月末（v2.1.3）以降のバージョンに更新した
既存の .claude/commands/ を棚卸しし、副作用のあるものに disable-model-invocation: true を付けた
自動発動させたいスキルのdescriptionに「何をするか＋いつ使うか」を書いた
長い規約・参考資料はSKILL.md本文ではなく references/ に分離した
監査系スキルは disallowed-tools で書き込み・実行系ツールを外した
チーム共有するスキルを .claude/skills/ に置いてGitにコミットした
外部製スキルを導入する前に、スクリプトと外部通信の有無を監査した

検証環境: 本文の動作説明は、いずれも次の環境での実機検証に基づいています。原則として特定の環境に依存する挙動ではありませんが（環境により差がある事項は3-2の本文と3-5の補足に明記しています）、事実として今回検証した環境を記載します。

Claude Code v2.1.204
OS: Windows 11
検証日: 2026年7月8日〜10日

Skillsは仕様の更新が速い機能のため（frontmatterフィールドにはバージョン依存のものがあります）、最新の仕様は公式ドキュメントで確認してください。

なお、作成したスキルはClaude Codeの外でも活かせます。スキルをDifyワークフローへ変換する手法についてはこちらもご参考ください。

あわせて読みたい

Claude CodeのAIスキルをDifyワークフローへ自動変換する【Workflow as Code実践ガイド】 1. AI開発の限界を突破する「Workflow as Code」の全貌はじめに：AI開発の「属人化」という壁 AIエージェントやワークフローの活用が広がる中、新たな課題が浮き彫りに…

最後に

私たちは、単にシステムを組むだけの開発会社ではありません。低コストで高品質なAIツールの構築から、ROI（投資対効果）を最大化する導入ロードマップの策定、社内スタッフが自らAIを運用・改善できる体制の構築まで、AI導入の成功に必要なすべてを最初から最後まで丸ごと支援いたします。

実は、ご相談いただく方のほとんどが「何が分からないかも分からない」という状態からのスタートです。構想段階でも、ただのアイデアベースでも構いません。
まずは、あなたのお困りごとをそのまま聞かせていただけませんか？貴社のビジネスを加速させるパートナーとして伴走いたします。

AI導入のご相談・資料のダウンロードはこちら

構想段階のご相談から、サービス資料・実務で使えるお役立ち資料まで。目的に合わせてお選びください。

お問い合わせサービス資料DL お役立ち資料DL

参考文献

Anthropic・Claude Code Docs「Extend Claude with skills」（2026年7月6日参照）
Anthropic・Claude Platform Docs「Agent Skills Overview」（2026年7月6日参照）
Anthropic Engineering「Equipping agents for the real world with Agent Skills」（2026年7月6日参照）
Agent Skills「Agent Skills 仕様（オープン標準）」（2026年7月6日参照）
inukai-masanori・Qiita「Claude Code、Skills 統合後のスラッシュコマンドの罠」（2026年7月6日参照）
kazuhira-r・CLOVER「Claude Codeの（カスタム）スラッシュコマンドがスキルに統合されたという話」（2026年7月6日参照）
CureApp・Zenn「カスタムスラッシュコマンドはスキルに置き換えるべき」（2026年7月6日参照）
Anthropic・GitHub「anthropics/skills」（2026年7月6日参照）
anthropics/claude-code・GitHub「Skill and agent frontmatter hooks silently not firing (Issue #39468)」（2026年7月8日参照）
Anthropic・Claude Code Docs「Tools reference」（2026年7月10日参照）