Claude Code Hooks・Slash Commands・Skills の使い分け：誰が起動するかで選ぶ

Claude Code の hooks、slash commands、skills は、機能名ではなく「誰がその動作を起動するか」で分けると判断しやすくなります。人が明示的に開始したいなら slash command か user-invoked skill、Claude が作業内容に応じて再利用する手順や資料を読み込むなら skill、特定のライフサイクルイベントで毎回必ず実行したいなら hook です。

2026 年 6 月 1 日時点の公式ドキュメントでは、custom commands は skills に統合された一方で、既存の .claude/commands/ ファイルは引き続き動きます。したがって実務上の問いは「古い commands フォルダを使うか」ではなく、「この作業は人が開始すべきか、Claude が方法として読み込むべきか、runtime event が強制的に走らせるべきか」です。

まず見るルートボード

短く言えば、slash command は timing、skill は method、hook は certainty を担当します。slash command は人が押すボタンに近く、skill は Claude が使える作業方法のパッケージで、hook はイベントに結びついた確定的な実行です。

三つとも「自動化」と呼べますが、壊れ方が違います。command は呼び忘れます。skill は広すぎる場面で読み込まれたり、必要なときに読まれなかったりします。hook は自動で走るため、設計を間違えると毎回遅くなり、正しい作業まで止めます。だから新しいファイルを作る前に、まず失敗の形を決めます。

Slash Commands は人の開始タイミングを守る

Slash command は、人が開始の瞬間を選ぶべきときに使います。メッセージの先頭で / を入力し、必要なら引数を渡します。セッション制御、レビュー開始、リリースチェック、状態の要約、計画だけ作って実行しない操作などに向いています。

副作用がある作業では、この明示性が安全策です。deploy、delete、publish、billing、外部サービス呼び出し、大量ファイル編集、branch state の変更を伴うなら、起動を人に残す価値があります。裏側の手順は skill に置けますが、開始ボタンは見えるままにします。

custom commands が skills に統合されたことは、slash command の意味が消えたということではありません。むしろ、複雑な custom workflow は skill として richer packaging し、必要な場合は /skill-name で人が呼び出す、という形が自然です。既存の .claude/commands/*.md は、小さく安定した用途ならそのままで構いません。

判断の目安は簡単です。セッション制御は組み込み command。繰り返す手順は user-invoked skill。古い command file は、補助ファイルや metadata が不要な場合だけ残す。人が開始する理由を説明できないなら、それは command ではなく skill か hook の候補です。

Skills は再利用する方法を持つ

Skill は、Claude に同じ作業方法を何度も使わせたいときの表面です。必要なのは「好きな prompt」ではなく、手順、参照、例、テンプレート、スクリプト、境界がまとまった作業単位です。SKILL.md が入口になり、補助ファイルが方法を支えます。

PR review の観点、移行監査、API ドキュメント作成、ローカライズ、ブラウザ QA、リリース確認など、毎回同じ説明を繰り返すと漏れやすい作業は skill に向いています。逆に一度しか使わない短い指示なら、まだ skill にしない方が保守しやすいです。

Skill には呼び出し方の設計もあります。Claude が文脈に応じて読み込んでよい skill と、人が明示的に呼ぶべき skill は分けます。production、課金、外部システム、大量編集、削除を含む skill は user-invoked に寄せ、開始の責任を人に残します。

Skill を増やす段階に来たら /ja/posts/claude-code-best-skills を見てもよいですが、外部アクセスの不足を skill で解決しようとしないでください。Skill は方法を教えます。GitHub、browser、database、deploy system への access は MCP や tool permission の問題です。

Hooks はイベント上の確定的な制約を実行する

Hook は、イベントが起きたら毎回走るべき処理に使います。tool use の前後、session start、notification、context compaction などの lifecycle event に結びつき、command、HTTP request、prompt、agent handler を呼び出します。

よい hook は狭く、説明しやすいものです。編集後に formatter を走らせる、危険な shell command の前に protected path を検査する、セッション開始時に小さな context を挿入する、通知を送る、終了時に短い記録を残す。これらは deterministic に近い確認です。

一方で、広い判断を hook に入れるのは危険です。「この review は十分か」「この設計は妥当か」は skill、subagent、明示的な review workflow に置くべきです。「この command は保護ディレクトリを消そうとしているか」なら hook で扱えます。

Hook は自動で走るため、最初は observe と log に寄せます。信号が安定してから block にします。悪い skill は文脈を浪費するだけで済むことがありますが、悪い hook は全セッションに介入し、速度を落とし、正しい作業を止めることがあります。

組み合わせるなら各層に別の仕事を持たせる

強いセットアップでは、command、skill、hook を組み合わせることがあります。ただし層が多いから良いのではありません。各層が違う曖昧さを取り除く場合だけ有効です。

悪い組み合わせは、command が skill を繰り返し、skill が policy enforcement を担い、hook が主観判断をします。よい組み合わせは、command が開始時点、skill が方法、hook が一つの invariant を担当します。一文で説明できない層は削除します。

Stop rules：自動化を増やす前に止まる

主観的な判断を hook に置かない。Hook は path、command pattern、event payload のような狭い条件を扱います。レビューの質や設計判断は skill または明示的な review に置きます。

破壊的な skill を自動起動しない。publish、deploy、delete、billing、production change、大規模 rewrite は人の invocation を残します。方法は skill に入れてよくても、開始は見えるべきです。

一度だけ使う prompt を skill にしない。Skill は references、examples、scripts、templates によって繰り返し価値を持つときに作ります。

command list を戦略にしない。/help、/skills、/hooks、/context を確認することは大切ですが、設計は timing、method、enforcement、access、runtime ownership のどれが欠けているかで決まります。外部アクセスなら /ja/posts/claude-code-best-mcp-servers、定期実行なら /ja/posts/routines-in-claude-code に寄せます。

Hook を memory にしない。作業開始前から見えるべきルールは、project instructions や memory surface に置きます。Hook はイベント処理であり、隠れた policy document ではありません。

実装前チェックリスト

実装前に順番に確認します。誰が起動するのか。単発か、再利用する方法か。自動で走る必要があるか。deterministic に判定できるか。副作用、費用、production 変更があるか。外部アクセスが足りないのか。チームメイトがその層の理由を理解できるか。

答えが explicit timing なら slash command か user-invoked skill。答えが method なら skill。答えが deterministic event handling なら hook。答えが external access なら MCP。答えが unattended runtime なら、拡張ファイルを増やす前に実行場所を決めます。

保守しやすい Claude Code 設定は短く説明できます。「この command が開始し、この skill が方法を持ち、この hook が一つの invariant を守る」。この説明が崩れたら、拡張ではなく複雑さが増えています。

チームに引き継げる形で決定を残す

設定が壊れやすくなるのは、最初に作った日ではなく、数週間後に別の人が .claude を見たときです。新しい slash command、skill、hook を追加するたびに、誰が起動するのか、失敗したら誰が見るのか、どの副作用まで許すのか、いつ削除するのかを残します。場所は SKILL.md、project rules、runbook、PR description のどれでもよいですが、ファイル名だけで意図が伝わるとは考えない方が安全です。

Slash command の記録では、人がその瞬間を選ぶ理由を書きます。/release-check は release が重要だから存在するのではなく、対象 branch、approval state、rollback window、告知タイミングを人が確認する必要があるから存在します。入力がすべて機械的に判定できるなら、その一部は hook や CI check です。判断手順、例外、report format が必要なら、それは skill に分けます。

Skill の記録では、再利用する方法を書きます。よい skill は目的、証拠、手順、出力形式、禁止する操作、失敗時の扱いを持ちます。一度だけ使う prompt を包んでも、チームの資産にはなりません。逆に、毎回必ず実行しなければならない規則を skill に置くと、Claude が忘れる可能性が残ります。その場合は hook、CI、または別の runtime owner を検討します。

Hook の記録では、自動で守る invariant を書きます。Hook に向くのは、tool use の logging、危険な path の blocking、formatter、missing test の notification、audit endpoint への送信など、狭く検査できる動作です。Product judgment、設計判断、レビュー品質、例外処理の説明が必要な場合は、hook ではなく skill や明示的な review に戻します。Hook の強みは予測可能性であり、議論の代替ではありません。

既存設定を棚卸しするときは、owner のない hook、支援資料のない skill、skill 名を呼ぶだけの command から削ります。成熟した Claude Code 設定は、追加した数ではなく、各層の trigger、owner、failure path、rollback が説明できることで判断します。

よくある質問

Slash commands と skills は同じですか？

同じではありません。custom commands は skills に統合され、skill は /skill-name で呼べます。ただし slash command は明示的な invocation surface です。Command は timing、skill は packaging と考えます。

すべての .claude/commands を skill に移すべきですか？

必要ありません。補助ファイル、metadata、dynamic context、tool control、discoverability が必要なときだけ移行します。小さく安定した command は残せます。

Hooks は skills より信頼できますか？

より deterministic ですが、常に上位ではありません。Hook は configured event に反応するので、log、formatter、notification、narrow guard に向いています。Skill は method、context、examples、checklist に向いています。

追加前に何を見ればよいですか？

/help または commands reference、/skills、/hooks、/context を確認します。それでも不足層を言えないなら、まだ新しい surface を追加しない方が安全です。

プロジェクト全体のルールはどこに置くべきですか？

常に見える広いルールは CLAUDE.md や memory surface。繰り返す手順は skill。イベントで必ず実行する狭い制約は hook。Hook にプロジェクトポリシー全体を隠さないでください。

短い結論

起動主体で選びます。Slash command は人の明示的なタイミング、skill は再利用する方法、hook は deterministic lifecycle event。組み合わせるなら各層に別の仕事を持たせます。外部アクセスや定期実行の問題を、skills や hooks だけで解決しようとしないことが、Claude Code 設定を長く保つ一番の近道です。