【2026年版】Claude CodeのSkillsとHooksを徹底解説 ― SuperClaudeとの機能重複を理解する

この記事の要約(忙しい人向け)

• Skills: SKILL.mdという指示書を置くだけで、Claude Codeの「引き出し」を増やせる仕組み。会話にずっと乗せておくCLAUDE.mdと違い、使われた時だけ読み込まれるのでトークンを消費しない
• Hooks: ツール実行の前後やセッションの節目など、決まったタイミングで自動的にシェルコマンド等を実行する仕組み。「危険なコマンドを機械的にブロックする」「編集後に自動でLintを走らせる」といった、AIの判断に頼らない確実な制御ができる
• 2026年現在、.claude/commands/のカスタムコマンドはSkillsに統合されており、両者はほぼ同じ働きをする。Skillsはさらにサポートファイル・呼び出し制御・動的コンテキスト注入などの機能を追加で持つ上位互換

1. Skillsとは何か

SKILL.mdというファイルに指示を書いて配置すると、Claude Codeがそれを「道具箱」に追加してくれる仕組みです。関連する場面でClaudeが自動的に使うか、/スキル名で自分から直接呼び出すこともできます。

同じ指示をチャットに何度も貼り付けている、あるいはCLAUDE.mdの一部が「事実の記述」ではなく「手順書」のように肥大化してきた——そんな時がSkillsを作るタイミングです。
CLAUDE.mdの内容は毎回の会話に乗り続けるのに対し、Skillの本体は実際に使われた時だけ読み込まれるため、長い参考資料を置いておいても普段のトークン消費はほぼゼロで済みます。

カスタムコマンドとの関係

以前からある.claude/commands/deploy.md形式のカスタムコマンドは、Skillに統合されました。.claude/skills/deploy/SKILL.mdを作っても同じく/deployコマンドになり、動作も同じです。
既存の.claude/commands/はそのまま動き続けますが、新規に作るならSkillsの方が、専用フォルダにサポートファイルを同梱できたり、呼び出し方を制御できたりと機能が多い分、推奨されています。

Skillを作ってみる

公式ドキュメントの例をもとに、「gitの未コミット差分を要約するSkill」を作ってみます。

まずディレクトリを作成します(個人用スキルは全プロジェクト共通で使えます)。

mkdir -p ~/.claude/skills/summarize-changes

~/.claude/skills/summarize-changes/SKILL.mdを作成します。

---で挟まれたYAML frontmatterと、実際の指示を書くMarkdown本文の2部構成です。

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullet points, then list any risks you notice such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes.

!`git diff HEAD`の行がポイントです。これは「動的コンテキスト注入」と呼ばれる機能で、Claudeが指示を読む前にこのコマンドが実行され、出力結果がその場に埋め込まれます。
つまりClaudeは常に最新の差分を見た状態で要約を作ります。

使い方は2通りです。「何を変更した?」のように説明文に合う質問をすればClaudeが自動的に読み込みますし、/summarize-changesと直接打っても呼び出せます。

Skillの置き場所

どこに置くかで、誰が使えるかが決まります。

同じ名前のSkillが複数の場所にある場合は、組織管理 > 個人 > プロジェクトの順で優先されます。プロジェクトのSkillをリポジトリにコミットしておけば、チームで共有できます。

誰が呼び出せるかを制御する

デフォルトでは、自分も直接呼び出せて、Claudeも自動判断で呼び出せます。
これを制限する2つのfrontmatterフィールドがあります。

• disable-model-invocation: true
  — 自分だけが呼び出せる。
  /deployや/commitのように、副作用があってタイミングを自分で決めたい処理向け。
  「コードが完成したっぽいから」とClaudeが勝手にデプロイを判断してしまうのを防げる
• user-invocable: false
  — Claudeだけが呼び出せる。
  「レガシーシステムの背景知識」のような、コマンドとして実行する意味はないがClaudeが知っておくべき参考情報向け

---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
---

Deploy $ARGUMENTS to production:

1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

$ARGUMENTSは、Skill呼び出し時に渡した引数がそのまま展開されるプレースホルダーです。/deploy productionと打てば$ARGUMENTSがproductionに置き換わります。個別の引数を指定したい場合は$0・$1のように位置で参照することもできます。

2. Hooksとは何か

Hooksは、Claude Codeのライフサイクル上の決まったポイントで、自動的に実行されるユーザー定義のシェルコマンド・HTTPエンドポイント・LLMプロンプトです。
ターミナルでもIDE拡張でもデスクトップアプリでも、同じイベントが同じように発火します。

Skillsが「Claudeへの指示」であるのに対し、Hooksは「Claudeの判断を介さずに機械的に発火する処理」です。
「危険なコマンドは絶対に実行させない」「ファイル編集のたびに必ずLintを走らせる」のように、AIの気まぐれに任せたくない部分をHooksで固定化できます。

設定ファイルの場所

設定の基本構造

「どのイベントで」→「どのツールにマッチしたら」→「何を実行するか」という3階層のネスト構造になっています。

例として、rm -rfのような破壊的なコマンドを実行前にブロックする設定です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh"
          }
        ]
      }
    ]
  }
}

対応するシェルスクリプト.claude/hooks/block-rm.shはこのようになります。

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive command blocked by hook"
    }
  }'
else
  exit 0
fi

もう1つ、ファイル編集のたびに自動でLintを走らせる例です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/lint-check.sh"
          }
        ]
      }
    ]
  }
}

主なイベント

公式ドキュメントには30種類以上のイベントが定義されていますが、実用上よく使うのは次のあたりです。

matcherの書き方

matcherは主にツール名にマッチさせます。
Bashのような完全一致、Edit|Writeのような複数指定、mcp__.*のような正規表現(MCPツール全体を対象にする場合など)が使えます。
*や空文字、省略はすべてにマッチします。

さらに細かく、Bashコマンドの中身まで見て絞り込みたい場合はifフィールドが使えます。

{
  "matcher": "Bash",
  "hooks": [
    {
      "type": "command",
      "if": "Bash(git push *)",
      "command": "./validate-git-push.sh"
    }
  ]
}

セキュリティ上の注意点

• 信頼できるプロジェクトでのみ実行する:
  .claude/settings.jsonのHooksはプロジェクト内で実行可能な状態にあるため、知らないリポジトリのHooksをそのまま実行しない
• exec form(配列形式)を優先する:
  "command": "node", "args": [...]のように配列で渡すとシェル展開が起きずインジェクションのリスクを避けられる。
  文字列を直接渡すshell formは&&やパイプが使える分、リスクも伴う
• exit code 2はブロッキングエラー:
  Hookが終了コード2を返すと、JSON出力の有無にかかわらずその処理をブロックできる
• HTTP Hooksは許可リストで制御:
  外部エンドポイントを叩くHTTP HookはURLと環境変数それぞれに許可リスト(allowedHttpHookUrls / httpHookAllowedEnvVars)を設定でき、許可されていない環境変数はヘッダーに埋め込んでも空文字列になる

3. SuperClaudeとの関係を整理する

前回の記事で紹介した通り、SuperClaude公式のギャップ分析には次のような記述があります。

Claude Code gap analysis: Full feature mapping identifying skills migration, hooks integration, and plan mode as high-priority alignment opportunities

今回Skills・Hooksの実際の仕様を見た上で、この指摘の意味がより具体的に理解できます。

実務上のヒントとしては、SuperClaudeの「ドキュメント生成」「要件整理」のような比較的シンプルなコマンドは、自分でSKILL.mdを1つ書けば同じことが標準機能だけで再現できるケースが多いです。
「危険なコマンドを防ぎたい」「編集後に必ずテストを走らせたい」といった、確実性が必要な処理はHooksの方が向いています。

4. まとめ

• Skillsは「使う時だけ読み込まれる指示書」。同じ指示を貼り付け続けているなら作る価値がある。disable-model-invocation・user-invocableで誰が呼び出せるかを制御できる
• Hooksは「AIの判断を介さない機械的な自動処理」。危険操作のブロックや後処理の自動実行に向いている
• SuperClaudeのようなサードパーティ拡張を検討する前に、まず標準のSkills・Hooksで代替できないかを確認する方が、今後のClaude Code本体のアップデートとの相性がよい

参考

• Extend Claude with skills(公式ドキュメント)
• Hooks reference(公式ドキュメント)
• SuperClaudeカスタムコマンド完全ガイド(前回記事)