Claude Code の skills/hooks/rules の使い分けを、公式記事の"ある軸"で整理してみた
こんにちは、データ事業本部のまっきーです。
私は普段、Claude Code を業務で日常的に使っています。自分用の skill を作ったり、CLAUDE.md にルールを書いたり、hook で定型作業を自動化したりと、それなりにカスタマイズして運用してきました。
ただ正直なところ、skills / hooks / rules の違いを「なんとなく」で使い分けていて、体系的に理解できているとは言えませんでした。手順を CLAUDE.md にベタ書きすることもあれば、skill に切り出すこともあり、その境界は感覚頼りだったのが本音です。
そんな中、SNS で「Claude Code を体系的に理解するのに最適」と紹介されていた Anthropic 公式記事を見つけました。
Steering Claude Code: skills, hooks, rules, subagents and more（2026年6月18日公開）
読んでみると確かに整理されていて、これは自分の運用環境に当てはめて確かめながら腹落ちさせたい、と思ったのが今回のきっかけです。
結論を先に書くと、Claude Code への指示を届ける手段は7つあり、「いつコンテキストに読み込まれるか」を基準に選ぶのが肝でした。さらにこの軸で自分の環境を点検してみたら、もう動いていないのに毎セッション読み込まれ続けていたルールを1個見つけて撤去でき、常時読み込み量を 387行 → 318行に減らせました。この軸は置き場所を決めるだけでなく、不要な設定を炙り出す健康診断にもなる、というのが今回の一番の収穫です。
Claude Code への指示は7つの手段で届けられる
公式記事では、Claude Code に指示を届ける方法が7つに整理されています。まずはそれぞれが何なのか、一行で押さえます。
| 手段 | ざっくり何のためか | 例 |
|---|---|---|
| CLAUDE.md（ルート） | ビルドコマンド・ディレクトリ構成・チーム規範など、常に参照する基本情報 | ビルド手順、フォルダ構成の説明 |
| CLAUDE.md（サブディレクトリ） | 特定フォルダ限定の規約 | テストフォルダのコーディング規約 |
| Rules | パススコープなどで効かせる条件付きの制約 | 特定の拡張子ファイルにだけ適用するルール |
| Skills | デプロイ手順・チェックリストなど、必要なときに手動で呼び出す手続き | 日報作成、デプロイ手順 |
| Subagents | ログ分析・依存関係監査など、本会話とは切り離して動かしたいタスク | コードレビュー、大量ログの分析 |
| Hooks | リンター実行・通知・コマンド遮断など、自動で確実に動かしたい処理 | ファイル編集後のリンター、禁止コマンドのブロック |
| Output Styles | 役割そのものを大きく変える（コーディング助手から別用途へ） | カスタマーサポート担当に切り替える |
聞き慣れない言葉もあるので、本記事で中心に扱う3つだけ補足します。
Skill は
SKILL.mdというマークダウンに手順を書いておき、/コマンドで呼び出すと Claude がその手順に従ってくれる仕組みです。普段は読み込まれず、呼んだときだけコンテキストに乗ります。
Hook は、Claude が操作をするタイミングに合わせて自動でスクリプトを走らせる仕組みです。「Claude がファイルを書き換えるたびにリンターを実行する」「Claude が特定のコマンドを実行しようとした瞬間に止める」のような使い方ができます。Claude に言葉で頼むのではなく、設定した処理が確実・機械的に動くのが特徴です。
Rule は、常に（あるいは特定の条件下で）Claude に効かせたい決まりごとを書いておくマークダウンです。CLAUDE.md と同じく毎セッション読み込まれますが、ファイル単位で分けて管理できます。今回点検した「11個のルール」はこれを指します。
選ぶ基準は「いつコンテキストに読み込まれるか」
7つを並べて分かったのは、選び分けの軸が 「いつコンテキストに読み込まれるか」 だということです。下の図のように、手段は「常に読み込まれる」「呼んだときだけ」「コンテキスト外で自動発火」の3つに分けられます。
- CLAUDE.md は常に読み込まれる。だから基本情報は向くが、書きすぎると毎回トークンを消費する。
- Skill は呼んだときだけ読み込まれる。重い手順を置くのに向く。
- Hook は Claude のコンテキストを使わず、設定どおりに自動発火する。守らせたい決まりごとを確実に効かせられる。
つまり「常に効かせたいのか / オンデマンドでよいのか / 確実に自動で効かせたいのか」で置き場所が決まる、という整理です。
公式が挙げる「3つのアンチパターン」
公式記事で特に実践的だと感じたのが、やりがちな3つのアンチパターンの指摘です。原文の主旨を引用します。
- 「毎回 X したら必ず Y せよ」という指示を CLAUDE.md に書くのではなく、Hook で自動化する
- 「絶対に X するな」という禁止を指示文で書くのではなく、PreToolUse フック（ツール実行の直前に割り込むスクリプト）で物理的に遮断する
- 「30行の手順」を CLAUDE.md に置くのではなく、Skill に移してオンデマンドで読み込ませる
出典: Steering Claude Code: skills, hooks, rules, subagents and more（Anthropic）
根っこにあるのは「指示を盛りすぎると、毎セッションで全部読み込まれてトークンを浪費する」という課題です。スコープを絞る・自動化する・手順を独立させる、で効率化できる、という主張になっています。
この考え方で、自分の運用環境を実際に点検してみました。
自分の運用環境で当てはめてみた
前半で整理した「いつ読み込まれるか」の軸を、実際に自分の Claude Code 環境に当てはめて点検してみました。私の環境には、毎セッション必ず読み込まれる Rule が11個ありました。
1. まず7分類に当てはめて棚卸しした
自分の Rule・Skill・Hook が、それぞれどの分類で、置き場所として妥当かを一通り確認しました。役割と判定で整理した一覧です。
| 運用していた指示（役割で表現） | 手段 | 点検結果 |
|---|---|---|
| 呼び出し式の定型ワークフロー（朝・夜のルーティンなど） | Skill | 適所 |
| 会話中いつでも反応させたい検知系（メモの自動保存・関連情報の提示など） | Rule | 適所（毎回必要） |
| セッション開始時・応答終了時に自動で走らせたい処理 | Hook | 適所 |
| ツール実行のたびに必ず効かせたいチェック | Hook | 適所 |
| プロジェクトの基本情報（構成・コマンド） | CLAUDE.md | 適所 |
| 特定条件でだけ発火する定型アナウンス（1個） | Rule | 要見直し |
点検してみると、11個のうち10個は「毎回読み込まれるのが正しい」と確認できました。会話中いつでも反応してほしい検知系や、セッション開始時に自動で動いてほしい処理は、その性質上、常時読み込まれている必要があります。つまり、当てはめてみた結果の大半は「今のままで妥当」でした。
2. 点検で見つかった「もう動いていないルール」を撤去した
問題は残りの1個でした。これは「特定の条件に当てはまる日だけ、定型のアナウンスを出す」というルールでした。
このルール自体は条件付きで動く設計でしたが、よく見ると その条件が起きなくなっていました。発火の判断材料にしていた参照ファイルの更新が止まっていて、結果として何も出力していなかったのです。それでも Rule である以上、毎セッション必ず読み込まれ続けていました。
状態: 条件に当てはまる日がもう来ない（参照データが古いまま）
→ 実際の出力: ゼロ
→ なのに毎セッション読み込まれる行数: 約70行
「いつ読み込まれるか」の軸で見たことで、効果ゼロなのに常時読み込まれている死蔵ルールだと気づけました。機能ごと不要だったので、撤去しました。
3. 撤去前後で読み込み量を測ってみた
撤去の効果を、毎セッション必ず読み込まれる行数（CLAUDE.md ＋ 全 Rule の合計行数）で測りました。
| 項目 | Before | After |
|---|---|---|
| Rule ファイル数 | 11個 | 10個 |
| 毎セッション読み込まれる行数 | 387行 | 318行 |
差し引き 69行、毎セッションのコンテキストが軽くなりました。
ここで出した行数は、私の手元の環境（この記事執筆時点の Rule 構成）で数えた実測値です。環境によって変わります。
ちなみに「毎回やる定型処理は指示文ではなく Hook で自動化する」という公式アンチパターンは、私の環境では別の処理ですでに実践していました（特定のファイルを編集したら、次の手順を促すチェックが自動で走るようにしてあります）。指示文に「忘れずにやること」と書いていた頃は効き方が曖昧でしたが、Hook はツール実行のたびに確実に発火するので、守られ方の確実性がまったく違いました。
確かめてわかったこと
実際に手を動かして点検してみて、一番の収穫はこれでした。
7分類の「いつ読み込まれるか」という軸は、置き場所を決めるだけでなく、「もう要らない設定」を炙り出す健康診断にもなる。
正直に言うと、最初は「ごちゃごちゃした指示を整理して移し替えよう」くらいのつもりでした。ところが軸に沿って点検したら、移し替える以前に 動いていないルールが居座って毎回読み込まれていた ことに気づけた。これは感覚で運用していたら、おそらくずっと見逃していました。
「常に効かせたいのか・呼んだときだけでよいのか・確実に自動で効かせたいのか」。この問いを一つずつの指示に当てるだけで、置き場所の判断も、不要な設定の発見も、両方できるようになりました。
おわりに
今回は公式記事を出発点に、自分の運用環境へ当てはめて点検してみました。とはいえ、今回見つかった「死蔵ルール」は、私が設定を作りっぱなしにしていたからこそ生まれたものでもあります。最初からこまめに棚卸ししていれば、69行ぶんの無駄は出なかったかもしれません。
それでも、7つの手段と「いつ読み込まれるか」という軸を一度通して理解しておくと、今後カスタマイズするときの置き場所の判断も、定期的な棚卸しも、同じ物差しでできるようになると感じました。
次は、この棚卸しを一度きりで終わらせず、設定を増やしたときに定期的に見直す習慣にしていきたいと思います。
