この記事を読むとわかること

• Claude Code の「スラッシュコマンド・スキル・フック」の役割と使い分け
• 「100%守らせたいルール」をどこに書くべきか
• 実際に Zenn 投稿用リポジトリでこの 3 つを組み合わせた具体例

課題：CLAUDE.md だけでは指示が守られない

Claude Code を使い始めて最初に感じたのは、「CLAUDE.md にルールを書いても、たまに無視される」という問題でした。

たとえば:

• 「push の前に必ず確認して」と書いてもいきなり push される
• 「機密情報を記事に書かない」と書いてもチェック漏れがありそうで怖い
• 同じ手順を毎回プロンプトで書くのが面倒

『実践 Claude Code入門』を読んだら、これは CLAUDE.md（プロンプトベース）の限界 で、解決には 3 つの異なる仕組み を使い分ければよい、と書かれていました。

解決策：3 つの仕組みの役割整理

書籍を読んでまとめた整理がこちらです。

実装方法が違うだけでなく、何を守らせるか という観点で書く場所を変えるのがコツです。

スラッシュコマンド — 暗黙的な手順を明示化

「ワークフロー」をファイル化したもの。.claude/commands/<name>.md に置くと /<name> で発動します。

書籍では効果的な作り方として以下 3 点が強調されていました。

• 単一責任：1 つのコマンドは 1 つの目的に集中する
• 適切な粒度：1 回の作業セッションで完了する一連の手順をまとめる
• 明確な実行フロー：各ステップで何をするか・どのツールを使うかを具体的に定義する

実例として、Zenn記事を公開する /publish を書いてみました（抜粋）。

description: Zenn記事を git add → commit → push で公開する

「push 前に確認」という暗黙のお作法を コマンドの手順として明文化 したことで、Claude が毎回同じ流れで動いてくれます。

スキル — ツールの使い方を教える

スラッシュコマンドが「流れ」なら、スキルは「やり方」。

プロジェクト全体に関わるものは CLAUDE.md に、細かいものはスキルに書くとコンテキストの節約になる。

スキルの肝は description フィールドの 具体的なトリガーワード（例：「Zenn記事の作成時」）を書くこと。Claude Codeが必要な時だけスキル本体を読み込んでくれるので、CLAUDE.md にすべてを詰め込んでコンテキストを圧迫する状況を避けられます。

書籍によれば、規約系（言語ごとのコーディングルールなど）はスキルに切り出すのが特に有効とのこと。

フック — 100%守らせたいルールはここに

CLAUDE.md やスラッシュコマンドはあくまでプロンプトベースなので、たまに守られないことがあります。

絶対に守らせたいルールは フック に書きます。代表的なものは以下。

実例として、Zenn記事に機密情報が混入しないよう、git commit git push 直前に staged 変更をスキャンする hook を作りました。

.claude/settings.json で hook を登録します。

{
"hooks": {
"PreToolUse": [
...

スクリプト側は、標準入力で渡される tool_input.command を読んで git commit か git push なら git diff --cached の 追加行のみ をパターンマッチング、検出したら exit 2 で停止する、という単純な作り。

input=$(cat)
command_str=$(echo "$input" | jq -r '.tool_input.command // "")'
if echo "$command_str" | grep -qE 'git[[:space:]]+commit'; then
...

これが効くのは「Claude が忘れても、shell は忘れない」から。プロンプトをいくら工夫するより確実です。

3 つを組み合わせた所感

実際にこの Zenn 投稿用リポジトリで以下を組み合わせてみました。

• スラッシュコマンド: /publish /article-from-memo /article-from-error など 5 本
• スキル: 今回は規模が小さいので使わず、CLAUDE.md に集約
• フック: 機密情報スキャン（PreToolUse on Bash）

結果として「/publish

公開フロー → push 前に 사용자 확인 → hook 에서 기밀 체크