Claude CodeのHooks・Skills・スラッシュコマンドを使い分ける:呼び出し方と設定例
同じ手順を繰り返したいならSkillを作り、手動で開始するなら/nameで呼び出します。ツール実行の前後に処理を結びつけたいならHookです。設定例と確認方法から、自分の作業に必要な仕組みを選べます。
目次

Claude Codeで、レビューや文書チェックの手順を繰り返し使いたいなら Skill、編集やツール実行の前後に処理を結びつけたいなら Hook を選びます。Skillを人が開始したいときは、/nameというスラッシュコマンドで呼び出せます。
ここで混同しやすいのが、スラッシュコマンドとSkillの関係です。現在のClaude Codeでは、カスタムコマンドはSkillsに統合されています。「コマンドは手動、Skillは自動」という二分では選べません。Skillの呼び出し方を設定したうえで、イベントに反応するHookが必要かを別に考えます。この記事は2026年10月4日に確認した公式SkillsドキュメントとHooksリファレンスに基づきます。
何を使うかは、今日の作業から決める
| やりたいこと | 最初に選ぶもの | 理由と確認する点 |
|---|---|---|
| ヘルプを表示する、会話を圧縮する | /help、/compactなどの組み込みコマンド | CLIの制御機能。自作の手順を作る必要はありません |
| 同じ観点で文書をチェックする | 自作Skill | 手順や出力形式を再利用できます。必要なら人だけが呼べるようにします |
| 関連する作業で社内の説明資料を読ませる | Claudeも呼べるSkill | descriptionで用途を伝え、本文や補助資料は呼び出し時に読み込ませます |
| Claude APIの実装を進める | バンドルされた/claude-api Skill | 既存のAPI向け手順から始められます |
| Edit/Writeの直前に対象パスを検査する | PreToolUse Hook | そのツール呼び出しより前に検査し、条件に合えば止められます |
| ツールの成功後に整形や記録を行う | PostToolUse Hook | 実行済みの結果を扱います。変更前の阻止には使えません |
スラッシュコマンドは呼び出す入口、SkillはClaudeに渡す作業方法、Hookはイベントに結びつける処理です。手動で呼ぶSkillを作れば、入口と手順を別々のファイルに重複して書く必要はありません。

上の図は役割をつかむための概念図です。実際の呼び出し制御とHookの種類は、以下の設定で判断してください。特に、イベントが決まった時点で起きることと、モデルの判断結果が毎回同じになることは別です。
スラッシュコマンドには「CLIの制御」と「Skillの呼び出し」がある
/から始まる入力が、すべて同じ仕組みで動くわけではありません。大部分の組み込みコマンドはCLIに実装された固定の処理を行います。一方、バンドルされたSkillsはClaudeに指示を渡し、Claudeがツールを使って作業を進めます。自作Skillも後者です。この区別は公式コマンド一覧で確認できます。
たとえば、/helpで操作を調べるのと、/code-reviewでモデルにレビューを依頼するのは、同じ/入力でも仕事が違います。「スラッシュコマンドだからモデルを呼ばない」「すべて無料で実行できる」とは考えないでください。利用できる項目は、バージョン、プラットフォーム、プランや有効な機能によって変わります。まず自分のセッションで/helpと/skillsを確認します。
Claude API向けのSkillはどう呼び出す?
Claude Codeの入力欄に/claude-apiと入力します。既存のAPIコードを新しいモデルへ移行する作業なら、/claude-api migrateのようにサブコマンドを付けられます。公式には、コードがanthropicや@anthropic-ai/sdkをインポートすると自動的に有効になることも説明されています。用途と各サブコマンドの対応バージョンはClaude APIプロジェクト向けSkillを参照してください。
これはAPIの認証設定を済ませるコマンドではありません。Skillを呼び出せることと、プロジェクトがAPIを実行できることを分けて確認します。
既存のカスタムコマンドは移行が必要?
今すぐ全件を移す必要はありません。公式では、.claude/commands/check-doc.mdと.claude/skills/check-doc/SKILL.mdはいずれも/check-docを作り、同じように機能すると説明されています。旧形式も継続して使えます。
これから手順を育てるなら、補助資料やスクリプトを同じディレクトリで管理できるSkill形式が便利です。単純な既存コマンドを残す判断もできます。同じ呼び出し名の定義を複数作ってしまうより、どちらを保守するかを決めておく方が分かりやすくなります。統合に関する公式説明
Skillの呼び出し方を決める二つの設定
既定では、人もClaudeもSkillを呼び出せます。人が/skill-nameと入力する場合と、Claudeが会話の内容に応じて読み込む場合があります。次の二つのフロントマターは、別々の呼び出し主体を制御します。
| 設定 | 人が/nameで呼ぶ | Claudeが自動で呼ぶ | 向く用途 |
|---|---|---|---|
| 両方とも省略 | 可能 | 可能 | 明示的にも使いたい共通の作業手順 |
disable-model-invocation: true | 可能 | 不可 | 人が開始時点を選ぶチェックや、費用・副作用のある手順 |
user-invocable: false | 不可 | 可能 | 関連する作業で参照する背景知識 |
user-invocable: falseはメニューから隠すだけではなく、直接/nameを入力しても実行させません。disable-model-invocation: trueでは、Skillの説明もモデル向け一覧に入りません。詳細は呼び出しを制御する公式表で確認できます。
公開やデプロイなどは人だけが開始する設定にすると、開始の意図が明確になります。ただし、手動呼び出しを許したことだけで、その後の全操作や外部書き込みまで承認したことにはなりません。手順とツール権限はそれぞれ確認が必要です。
allowed-toolsは「それ以外を禁止する」設定ではない
allowed-tools: Readを付けても、Read以外のツールが消えるわけではありません。これはSkillを呼び出したターンで、指定ツールの使用を事前に許可する設定です。それ以外のツールには通常の権限設定が適用されます。次のユーザーメッセージで許可は切れますが、読み込まれたSkill本文は会話に残ります。
ツール自体を利用候補から外すフィールドはdisallowed-toolsです。こちらも次のユーザーメッセージで制限が切れます。タスク全体にわたる禁止が必要なら、Skill本文の依頼だけに頼らず、権限設定のdenyルールを検討します。
組織がallowManagedPermissionRulesOnlyを設定している場合、対象となる個人・プロジェクトSkillsなどのallowed-toolsは無視されます。この動作にはv2.1.282以降が必要です。ツールの事前許可と管理ポリシー
最小のSkill例:指定した文書を手動でチェックする
最初のSkillは、外部アクセスも公開操作も必要ない小さな作業にすると確認しやすくなります。ここでは、プロジェクトのdocs/guide.mdをチェックして問題を報告するSkillを作ります。前提は、Claude Codeを使えるプロジェクトと、読み取り可能な対象文書があることです。
プロジェクト内に.claude/skills/check-doc/ディレクトリを作成し、SKILL.mdに次の内容を保存します。入口の名前は大文字の単数形 SKILL.md です。先頭行を---にし、YAMLの後にMarkdown本文を書きます。フロントマターのフィールドは任意ですが、用途を伝えるdescriptionが推奨されています。形式とフィールドの仕様
---
name: check-doc
description: 指定された文書の手順と用語を確認し、修正候補を報告します。
argument-hint: 文書の相対パス
disable-model-invocation: true
---
対象文書: $ARGUMENTS
1. 引数が空なら、対象ファイルのパスを質問して止まってください。
2. 指定されたファイルを読み、存在しなければその旨を報告してください。
3. 手順の順序、未定義の用語、読者が完了を判断できる説明を確認してください。
4. 問題ごとに、該当箇所・困る理由・修正案を日本語で報告してください。
5. ファイルの編集、外部アクセス、コミットは行わないでください。
問題が見つからなければ「確認した範囲では問題は見つかりませんでした」と報告してください。対象文書がまだなければ、docs/guide.mdを作って、たとえば次の短い内容で試せます。
# 文書の確認手順
1. guide.mdを開きます。
2. 文書の先頭に見出しがあることを確認します。
3. 見出しがあれば、この確認は完了です。Claude Codeの入力欄で、次のように呼び出します。
/check-doc docs/guide.md$ARGUMENTSにはdocs/guide.mdが入ります。成功の目安は、指定文書に沿った確認結果が返り、編集差分が増えていないことです。対象パスを変えた場合も、その文書を読んだ内容になっているかを確認してください。これはモデルへの手順の指定なので、文書内容の理解や指摘が正しいかは人が確かめます。また、「編集しない」という本文は権限による書き込み禁止そのものではありません。
うまく呼び出せないときは、最初にファイル名、先頭行、YAMLの構文、user-invocable: falseが付いていないかを確認します。認識されないフィールドや壊れたYAMLでは、期待した呼び出し制御が適用されない場合があります。
チェック観点が増えたら、同じディレクトリにreference.mdやexamples.mdを置き、SKILL.mdから「どのときに読むか」を案内します。最初から大量の資料を本文へ詰め込む必要はありません。補助ファイルの使い方
Hookは「イベント・条件・処理」で考える
Hookには、いつ動くかを決めるイベント、何に反応するかを絞るmatcher、何を実行するかを決めるハンドラーがあります。PreToolUseでEdit|Writeに一致する処理を登録すると、対象のツールが実行される直前に呼ばれます。PostToolUseなら成功後です。
現在のハンドラーは次の5種類です。イベントごとに対応する種類が違うため、任意の組み合わせで使えるわけではありません。Hookの種類とイベント仕様
| type | 実行するもの | 選ぶときの確認点 |
|---|---|---|
command | シェルコマンドやスクリプト | 実行環境、入力JSON、終了コード、処理時間 |
http | 指定URLへのPOST | 送る情報、宛先、失敗時の扱い |
mcp_tool | 設定済みMCPサーバーのツール | 利用できるツールと、その操作の副作用 |
prompt | 単発のモデル評価 | 判断基準、評価の費用と待ち時間 |
agent | ツールを使う複数ターンの検証 | 検証範囲と実行時間。実験的な機能です |
Hookのイベントは、Claudeが「今は必要そうだ」と考えて選ぶSkillの自動呼び出しとは違います。しかしpromptやagentの結論はモデルの判断です。イベントに結びつけたからといって、レビュー品質や判定結果が確定的になるわけではありません。
たとえば「ファイル名が一致したら止める」は短いスクリプトで表せます。「要求を十分に満たしたか」は判断を要するため、明示的なレビューSkillから始める方が結果を見直しやすくなります。モデル評価Hookも使えますが、Stopの失敗判定で作業を続けさせる場合は、終了できない繰り返しや追加評価を避ける設計が必要です。prompt型Hookの動作
最小のHook例:Edit/Writeによるlockfile変更を止める
この例は、プロジェクト直下のpackage-lock.jsonに対する EditとWriteの呼び出しだけ を止めます。依存関係の変更を禁止する完全な仕組みではありません。Bashからの書き込み、別ツール、別ファイルの更新は対象外です。まず範囲の狭いHookを理解するための例として使ってください。
前提はPython 3が使えることです。プロジェクトにscripts/ディレクトリを用意し、scripts/protect-lockfile.pyに次のスクリプトを保存します。外部パッケージは不要です。
import json
import os
import sys
from pathlib import Path
try:
event = json.load(sys.stdin)
project = Path(os.environ["CLAUDE_PROJECT_DIR"]).resolve()
tool_input = event.get("tool_input", {})
file_path = tool_input.get("file_path")
if event.get("tool_name") not in {"Edit", "Write"} or not file_path:
sys.exit(0)
target = Path(file_path)
if not target.is_absolute():
target = project / target
if target.resolve() == project / "package-lock.json":
print("package-lock.jsonの変更は依存関係の更新手順で行ってください。", file=sys.stderr)
sys.exit(2)
except (json.JSONDecodeError, KeyError, TypeError, AttributeError, OSError) as error:
print(f"入力または実行環境を確認してください: {error}", file=sys.stderr)
sys.exit(1)
sys.exit(0)プロジェクトの.claude/settings.jsonには、以下のhooks設定を追加します。既に設定がある場合は、既存のhooksや他のイベントを残して統合してください。ファイル全体を置き換える必要はありません。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "python3 \"$CLAUDE_PROJECT_DIR/scripts/protect-lockfile.py\""
}
]
}
]
}
}CLAUDE_PROJECT_DIRはClaude CodeがHookへ渡すプロジェクトのパスです。引用符を付けているため、パスに空白があっても一つの引数として扱えます。Pythonから起動するので、スクリプトへの実行権限の付与は不要です。
まずローカル入力で、止める条件を確認する
プロジェクトのルートにいるターミナルで、環境変数を設定してJSONを渡します。この実行はClaudeを呼び出さず、実際のファイルも編集しません。
export CLAUDE_PROJECT_DIR="$PWD"
printf '%s\n' '{"hook_event_name":"PreToolUse","tool_name":"Edit","tool_input":{"file_path":"package-lock.json"}}' | python3 scripts/protect-lockfile.py
echo $?理由が標準エラーへ出て、終了コード2になれば、対象パスの分岐が動いています。次にfile_pathをdocs/guide.mdに変えます。同じスクリプトが何も出力せず0で終われば、対象外のファイルを止めていません。
| 渡す入力 | 期待する終了コード | 確認できること |
|---|---|---|
Editでpackage-lock.jsonを指定 | 2 | この対象を止める分岐 |
Writeでpackage-lock.jsonを指定 | 2 | Writeも同じ検査対象 |
Editでdocs/guide.mdを指定 | 0 | 対象外のファイルを通す分岐 |
Bashでpackage-lock.jsonへの操作を指定 | 0 | この例がBashを保護しないこと |
| JSONでない入力 | 1 | 入力エラーの報告。ブロック成功ではありません |
この記事の例は、JSONとSkillのYAML、および上のスクリプトへサンプル入力を渡すオフラインチェックを行いました。Claude Codeでの登録・発火、Skillによる文書の評価、モデル呼び出しは検証していません。
Claude Codeへ登録した後は、何を見ればよい?
/hooksでPreToolUseに登録されていることを確認します。設定ファイルの変更は通常、監視機能によって取り込まれます。数秒待っても見えなければ、JSONの構文と保存場所を確認し、セッションを再起動して読み込み直します。組織の設定で管理済みHookだけを許可している場合は、個人・プロジェクト設定のHookは動きません。Hookが表示されない場合の確認
次に、破棄できる練習用プロジェクトでEdit/Writeによる対象ファイルの変更を依頼します。Claudeが実際にそのツールを選んだ場合、呼び出しが止まり、理由が返ることが成功の目安です。Bashを選んだ場合に変更が通っても、上のスクリプトの対象範囲外です。ローカル入力の成功だけで、実際のHook登録まで済んだとは判断しないでください。
終了コードと実行後の処理を混同しない
上の例は、PreToolUseの終了コードだけを使います。2と標準エラーの理由で、そのツール呼び出しを止めます。0でJSONも出さなければ「異議なし」であり、ツールを事前承認する意味ではありません。通常の権限確認は残ります。
すべての非ゼロ終了コードが阻止を意味するわけでもありません。多くのイベントでは、空の標準出力と終了コード1はブロックしないエラーとして扱われます。また、有効な構造化JSONを返した場合や特定イベントには別の規則があります。終了コード方式と構造化JSON方式は混ぜず、使うイベントの終了コード仕様を確認します。
PostToolUseはツールが成功した後に動くため、そこで失敗を報告しても、既に行われた変更を取り消せません。変更前に止める要件にはPreToolUseを選び、実行後の整形や記録にはPostToolUseを選びます。非同期処理の完了も、過去のツール実行を遡って止める仕組みにはなりません。
同じイベントに一致する複数のHookは並列に動き、すべての結果を待ってから判定がまとめられます。一つがdenyを返しても、別のHookの処理や副作用は止まりません。PreToolUseの権限判定は、より制限の強いdeny、defer、ask、allowの順で優先されます。阻止Hookと外部送信Hookを並べても、「阻止された操作は送信されない」とは保証できません。複数Hookの結果の統合
設定する場所と、効き続ける時間も確認する
個人設定の~/.claude/settings.jsonは自分の複数プロジェクトに適用されます。共有するプロジェクト設定は.claude/settings.json、そのプロジェクトで自分だけが使う設定は.claude/settings.local.jsonです。プラグインや管理ポリシーにもHookを定義できます。ローカルの個人設定が、そのままクラウドセッションへ届くとは限りません。Hookの配置場所と適用範囲
SkillのフロントマターにもHookを定義できますが、寿命の違いに注意してください。
| 対象 | 現在の動作 |
|---|---|
| 呼び出されたSkill本文 | 会話に残り、後続ターンにも引き継がれます |
Skillのallowed-toolsとdisallowed-tools | 次のユーザーメッセージで許可・制限が切れます |
| Skillに定義したHook | Skill呼び出し時に登録され、そのセッションの残りの間も動きます |
once: trueのHook | 最初の成功後に解除されます |
| サブエージェントに定義したHook | そのサブエージェントが動いている間だけ適用されます |
「Skillの手順が終われば、そのHookも終わる」とは考えないでください。この違いはSkill本文の寿命とSkills・サブエージェント内のHooksに説明されています。
組み合わせは、別の仕事が必要になってから

まず文書チェックを毎回同じ観点で行いたいなら、/check-docのようなSkillだけで始められます。さらに「チェック中でも、特定ファイルへのEdit/Writeは止めたい」という別の要件があるなら、狭いHookを足します。Skillは確認方法を伝え、Hookは一致するイベントの入力を検査します。
リリース作業も同じです。人が手動Skillで開始し、Skillにはテストやロールバック確認の手順を持たせます。Hookを足すなら、どのイベントで何を検査し、どの操作まで止めるのかを具体的に決めます。承認の有無や環境の正しさを、ファイル名だけの簡単な検査で保証することはできません。
足りないものがGitHubやデータベースへのアクセスなら、Skillを長くするより接続と権限を確認します。外部連携を選ぶ観点はClaude CodeのMCPを作業別に選ぶガイドで扱っています。Hookのmcp_tool型も、設定済みのMCPツールを呼ぶ仕組みです。接続を新たに作る機能ではありません。
設定を追加したときは、目的、適用するプロジェクト、失敗の見方、解除する方法をチームに残します。「このSkillは文書の確認手順を渡す」「このHookはEdit/Writeの特定パスを止める」と説明できれば、後から直す場所も見つけやすくなります。
よくある質問
Skillsは自動、スラッシュコマンドは手動ですか?
その区分ではありません。Skillは既定で人もClaudeも呼べ、人は/nameから開始できます。人だけにするならdisable-model-invocation: true、Claudeだけにするならuser-invocable: falseを使います。組み込みコマンドの大部分はCLIの固定処理で、カスタムコマンドは現在Skillsに統合されています。公式Skills説明
SKILLS.mdとSKILL.mdはどちらが正しいですか?
Claude CodeのSkill入口はSKILL.mdです。複数形のSKILLS.mdや小文字のskill.mdを使う記事を見かけても、現在の公式ファイル形式に合わせてください。
allowed-toolsをReadだけにすると、読み取り専用になりますか?
いいえ。allowed-toolsは指定ツールの事前許可で、他のツールを禁止しません。読み取り専用にしたい場合は、本文の依頼と実際の権限設定を分けて確認してください。disallowed-toolsはツールを利用候補から外せますが、次のユーザーメッセージで制限が切れます。事前許可の仕様
Hookなら毎回同じ判断になりますか?
イベントへの反応と判断結果は別です。固定条件を検査するcommand型でも、入力や実行環境が変われば結果は変わります。prompt型・agent型はモデルの評価を使うため、確定的な判定の保証にはなりません。まず必要な条件を絞り、止める入力と通す入力の両方で確認します。Hookの仕組み
Hookが終了コード2を返せば、何でも止められますか?
いいえ。上のPreToolUse例では対象のツール呼び出しを止めますが、終了コード2の効果はイベントによって異なります。SessionStartなど停止できないイベントもあり、PostToolUseでは実行済みの変更を取り消せません。イベント別の終了コードを確認してください。
参考資料4
本文で参照している外部ページを、登場順に並べています。最終更新日:2026年10月5日。
参考資料4
本文で参照している外部ページを、登場順に並べています。最終更新日:2026年10月5日。





