Claude Code を動かす7手段、公式の使い分け

要約
性質ごとに7手段へ散らし、いつ読まれるか・圧縮後に残るか・コスト・強制力の4軸で選ぶ。絶対やめさせたい操作は指示でなく Hook と permissions で機械的に止める
意見はこのエリアに表示されます
アイキャッチ画像

Anthropic 公式が「指示の届け方は7手段あって、用途で使い分けろ」という整理を出してたのが、めっちゃ実用的（いつも長いけど）だったので、7手段それぞれの選びどころを雑に書いた

体感が微妙なとき、モデルを疑う前に指示の置き方を見直すと変わることがあるかもね

X で毎日 Claude Code情報を配信してるコムテです

7手段

それぞれ「いつ Claude に読まれるか」「コンテキスト圧縮の後も残るか」が違う

  1. CLAUDE.md
  2. Rules
  3. Skills
  4. Subagents
  5. Hooks
  6. Output styles
  7. システムプロンプト追記

同じ指示でも置き場所で変わるってのがポイント

結論。指示は CLAUDE .md に全部書くんじゃなくて、性質ごとに7手段へ散らせって言ってるな

公式ブログが挙げてる用途、長いから圧縮

手段使い分けのコツ
CLAUDE.md200行以内に保つ
Rules横断ルールは paths でスコープ
Skills30行超の手順はここに逃がす
Subagents重い調査は別コンテキストへ
Hooks「毎回」「絶対するな」は Hook で
Output styles自作する前に組み込みを見る
システムプロンプト追記役割は変えず規約や出力形式を足す

「絶対するな」系は指示（文章）で頼むのでなくて

  • Hook
  • permissions

で機械的に止める

思ったのだが、こうも面倒な使い分けが増えてくると、AI成果物の差がどんどん開いていくよね

やっぱ、ちゃんと整理して覚えておいたほうがいいな

7手段を4軸で早見する

公式は7手段を4つの軸で比べろと言ってる

  • (a) いつ読まれるか
  • (b) compaction（長い会話を要約して圧縮する処理）の後も残るか
  • (c) コンテキストコスト
  • (d) authority（強制力）

いつ読まれて、圧縮後に残るか。まずここを表で見る

手段いつ読まれるか圧縮後に残るか
CLAUDE.md（ルート）常時ロード圧縮後に再読込される
CLAUDE.md（サブディレクトリ）そのフォルダを触ったとき再び触るまで消える
Rulespaths 対象を触ったとき圧縮時に再注入される
Skills名前と説明は最初、本体は呼ばれたとき呼ばれたときだけ
Subagents親が起動したとき隔離されて別枠
Hooksイベントで確定発火圧縮対象外
Output stylesシステムプロンプトに注入圧縮されない
システムプロンプト追記その起動だけ圧縮されない

軸のポイントだけ補足

  • ルートの CLAUDE.md は常時ロードで圧縮後も再読込。強いがコストが高い
  • Rules は paths にマッチしたファイルを触ったときだけ読まれる。paths なしは常時ロード
  • Skills は名前と説明だけ先に見えて、本体は呼ばれたとき開く
  • Hooks と Output styles は強制力の質が違う

棲み分け

  • 読んでほしいだけ → CLAUDE.md や Rules
  • 絶対やってほしい・やめてほしい → Hook か permissions

「毎回かならず X しろ」「絶対に Y するな」を指示文で書くと、Claude は守らないことがある。Hook や permissions で機械的に縛るべし

各手段の選びどころ

CLAUDE.md は薄いインデックスに保つ

公式の勧めは「200行以内に保って、所有者を決めて、コードと同じくレビューしろ」

CLAUDE.md をレビューしたことなんてないんだが？？

まぁでも、行数どーだこーだよりも、コンテキストをスッキリさせるのが先かな？

ビルドコマンドやディレクトリ構成みたいな全体の前提だけ置く。詳しい手順やルールは別のファイルに逃がして、CLAUDE.md はそこを指す索引にする

Rules は paths でスコープする

特定のパスにだけの制約は Rules に置いて paths で絞る

公式の例だと「API ハンドラは Zod で入力検証しろ」みたいなファイル単位の決まり。paths を付けないと CLAUDE.md と同じで常時ロード。関係ない作業でもコンテキストを食う

Skills は長い手順を置く

デプロイ手順やリリースのチェックリストみたいな手続きは Skills へ

公式いわく「30行を超える手順は CLAUDE.md でなく Skills に切り出せ」。名前と説明だけ先に見えて、本体は呼ばれたとき開くから、常時のコストがかからない

そういえば、最近は、ブラッシュアップした内容をスキルとして保存して再利用するってことも増えたなあ

それくらいは、皆やってそうやね

Subagents は隔離して回す

深い検索・ログ解析・依存監査みたいなサイド作業は Subagents

隔離コンテキストで動いて、親には最終結果だけ返る

中間結果で本筋を汚さず、結果だけ受け取れるのが強み

Hooks は確定的に走らせたい処理に

リンタ実行・完了時の通知・コマンド遮断みたいに「毎回かならず」やりたい処理は Hook

イベントで確定発火して、コンテキストの外で動く

Hookの情報って、X で見かけないのよ。勝手なイメージだが、活用できてる人いない気がするね

公式によると PreToolUse なら exit code 2 でツール呼び出し自体を止められる

Output styles は組み込みを先に見る

役割を大きく変えるとき向き。システムプロンプトに注入されて圧縮されない、authority が最強

authority = 強制力（その指示がどれだけ強く守られるか）ってことかな

指示文（CLAUDE.md/Rules）はモデルの判断で破られうる＝弱い

Hook/permissions や Output stylesはシステム側で確定的にいける＝強い

公式の勧めは「自作する前に組み込みの Proactive・Explanatory・Learning を見ろ」

システムプロンプト追記はトーンの微調整に

CLI のフラグで、その起動だけ・追記のみの一時的な手段

指示を足すほど遵守度は下がるから、常設のルールには向かない

authority の使い分け

7手段の本質は「読ませる」と「強制する」の違い

  • 読んでほしい情報 → CLAUDE.md・Rules・Skills（指示）
  • 絶対やる・やめさせる → Hook・permissions（機械的）

「絶対するな」を指示文で書いても、長いセッションや曖昧な状況、ファイル経由のプロンプトインジェクションで破られることがある

決定的なガードレールが要るなら、指示でなく Hook か permissions で縛る

置いたルールやフックは動作するか検証する

ルールやフックは、置いただけだとちゃんと動作してるかよく分からない

指示の置き場所を変えたら、狙いどおり読まれてる・発火してるか一度検証する

落とし穴が1つ。CLAUDE.md や常時ロードのルールは、セッション開始時に読み込まれる

だから変更が反映されるのは次に立ち上げたセッションから。同じセッションの中で直しても、その場では反映されない

ルールやフックをいじったら、新しいセッションで確かめる

今日できる最初の一歩

  1. CLAUDE.md を数えて、肥大化してたら他ファイルへ参照を飛ばすインデックス構造にする
  2. 特定フォルダ専用のルールは Rules に出して paths でスコープする
  3. 「絶対するな」「毎回かならず」系を1つ選んで、Hook か permissions に移す

まぁでも、7手段ぜんぶ完璧に使い分ける必要は全然ないかな

まずは CLAUDE.md ダイエットと「絶対するな系を機械化」をやるといいね

Explore More
関連記事はありません。
Trends