Claude Code は、自分の開発スタイルに合わせて挙動をカスタマイズできる。Anthropic の公式ブログでは、Claude の振る舞いを指示する方法として7つの手段が整理されている。CLAUDE.md ファイル、ルール、スキル、サブエージェント、フック、出力スタイル、そしてシステムプロンプトへの追記だ。
重要なのは、これらが単なる「指示の書き場所」の違いではないという点だ。それぞれの手段は、いつコンテキストに読み込まれるか、長いセッション（コンパクション）を越えて持続するか、どれだけの権威（指示への追従度）を持つかという3つの軸で性質が異なる。同じ指示でも、置く場所を間違えるとトークンを無駄に消費したり、肝心なときに守られなかったりする。
7つの手段の早見表
まず全体像を一枚で押さえておく。読み込みタイミング・コンパクション挙動・コンテキストコスト・適した用途を並べると、各手段の住み分けが見えてくる。
| 手段 | 読み込みタイミング | コンテキストコスト | 適した用途 |
|---|---|---|---|
| CLAUDE.md（ルート） | セッション開始時。以降ずっと保持 | 高。関係なくても毎行トークンを消費 | ビルドコマンド、ディレクトリ構成、コーディング規約、チームの慣習 |
| CLAUDE.md（サブディレクトリ） | そのディレクトリ配下のファイルを読んだとき | 低。作業中のディレクトリ分だけ | 特定ディレクトリ固有の規約 |
| ルール | セッション開始時、またはパス一致時のみ | 中。パススコープしない限り常時 | 個別の制約（例: 全 API ハンドラは Zod で入力検証） |
| スキル | 名前と説明は開始時、本体は呼び出し時 | 低。本体は呼び出し時のみ・共有予算内 | 手続き的なワークフロー（デプロイ・リリース手順） |
| サブエージェント | 名前・説明・ツール一覧は開始時、本体は呼び出し時 | 低。呼ばれるまでメインは消費ゼロ | 分離して動かしたい並列作業・サイドタスク |
| フック | ライフサイクルイベントで発火 | 低。設定はメインコンテキスト外 | 決定論的な自動化（lint、Slack 通知、コマンドブロック） |
| 出力スタイル | セッション開始時。システムプロンプトに注入 | 高。ただしデフォルトを上書き | 大きな役割変更（コード支援→汎用アシスタント） |
| システムプロンプト追記 | セッション開始時。CLI フラグで渡す | 中。初回リクエスト後はキャッシュ | トーン、応答の長さ、フォーマットの好み |
各手段の中身
CLAUDE.md ファイル
プロジェクトルートに置く Markdown ファイル。セッション開始時に読み込まれ、セッション中ずっとコンテキストに残る。ビルドコマンド、ディレクトリ構成、モノレポ構造、コーディング規約、チームの慣習などが自然に収まる。
2種類あり、挙動が異なる。ルート CLAUDE.md は常時ロードされ、コンパクション時にも再読み込みされるため長いセッションでも失われない。一方、サブディレクトリの CLAUDE.md はオンデマンドで、たとえば app/api/CLAUDE.md は app/api 配下のファイルを読んだときだけ読み込まれる。
共有リポジトリでは、CLAUDE.md は所有者のいない設定ファイルと同じように肥大化していく。各チームが自分の指示を追記し、何も削除されない。全行がすべてのエンジニアの全セッションに読み込まれるため、コストは規模に応じて膨らみ、本当に重要な指示への追従が薄まる。200行以内に保ち、オーナーを決め、コードと同じようにレビューするのが推奨されている。
ルール（Rules）
.claude/rules/ に置く Markdown ファイルで、Claude に個別の制約や規約を与える。スコープなしのルールは CLAUDE.md と同様に常時ロードされ、関係ないタスクでもトークンを消費してしまう。
そこで パススコープルールを使う。paths フィールドを追加すると、関連するファイルを触ったときだけ読み込まれる。たとえば src/api/** にスコープしたルールは、ドキュメントだけを編集するセッションではコンテキストに入らない。
「migrations は追記のみ」のようなファイル固有の制約は、paths frontmatter を付けたルールが最適。複数の箇所（ただし全体ではない）に現れる横断的な関心事には、ネストした CLAUDE.md よりパススコープルールを選ぶとよい。
スキル（Skills）
.claude/skills/ にフォルダとして置く、指示・スクリプト・リソースの集合。各スキルには名前・説明・本体を持つ SKILL.md がある。開始時に読み込まれるのは名前と説明だけで、本体はスキルが呼び出されたときに読み込まれる。発動はスラッシュコマンド（/code-review など）かタスクの自動マッチングによる。
コンパクション時には、呼び出されたスキルが共有予算の範囲内で再注入される。多くのスキルを使ったセッションでは、古いものから順に落ちていく。
デプロイ手順・リリースチェックリスト・レビュープロセスのような手続き的な指示は、CLAUDE.md ではなくスキルに置くのが鉄則だ。
サブエージェント（Subagents）
.claude/agents/ に置く Markdown ファイルで、特定のサイドタスク用の分離されたアシスタントを定義する。スキルと同様、名前・説明・ツール一覧は開始時に読み込まれるが、本体は自動発動しない。Claude が Agent ツール経由でプロンプト文字列を渡して呼び出す。
サブエージェントの本体は親の会話に一切入らない。独立した新しいコンテキストウィンドウで実行され、メインセッションに戻るのは最終メッセージ（多くは多数のサブタスクを集約した結果）とメタデータだけだ。サブエージェントは最大5階層までネストでき、動的ワークフローを使えば数十〜数百のバックグラウンドエージェントを編成できる。
この分離こそが、スキルではなくサブエージェントを選ぶ主な理由だ。深い検索・ログ解析・依存関係の監査など、後で参照しない中間結果でメイン会話を散らかしたくないときに使う。逆に、各ステップを見て操縦したいなら、メインスレッド内で展開されるスキルを選ぶ。
フック（Hooks）
ファイル編集・ツール呼び出し・セッション開始といった Claude のライフサイクル上の特定イベントで発火する、ユーザー定義のコマンド・HTTP エンドポイント・LLM プロンプト。settings.json、管理ポリシー設定、あるいはスキル/エージェントの frontmatter に登録する。
種類は command、HTTP、mcp_tool、prompt、agent の5つ。前者3つは決定論的に実行され、後者2つ（prompt・agent）はルールではなく Claude の判断を使って出力を決める。
設定や指示がメインコンテキスト外にあるためコンテキストコストは低い。ただしブロックフックの標準エラーのように、一部の出力はコンテキストに保存される（Claude が拒否理由を知るため）。これがフックを CLAUDE.md・ルール・スキルと根本的に異なるものにしている。「決定論的に必ず起きてほしいこと」——編集後の lint 実行、完了時の Slack 通知、特定コマンドのブロック——にフックを使う。
出力スタイル（Output styles）
.claude/output-styles/ に置くファイルで、システムプロンプトに指示を注入する。コンパクションされず、毎セッション開始時にロードされ、初回リクエスト後はキャッシュされる。システムプロンプトに座るため、ここまでの手段の中で最も指示追従の重みが大きい——だからこそ慎重に使う必要がある。
注意すべきは、出力スタイルの変更がデフォルトの出力スタイルを置き換えてしまう点だ（frontmatter で keep-coding-instructions: true を設定しない限り）。これにより、変更の範囲・コメントの付け方・セキュリティへの対応・テスト実行などの習慣といった、ソフトウェアエンジニアリング向けの重要なデフォルト指示が外れ、Claude Code は汎用アシスタント寄りになる。
カスタム出力スタイルを書く前に、組み込みの Proactive・Explanatory・Learning を確認するとよい。自律性・教育モード・協調的コーディングといった一般的なニーズは、スタイルファイルを保守せずともこれらでカバーできる。
システムプロンプトへの追記
出力スタイルの変更が大きく意図しない影響を及ぼしうるのに対し、append-system-prompt フラグは元のシステムプロンプトに加算的に働く。Claude の役割は変えず、デフォルトの役割に指示を追加するだけだ。呼び出し時に渡され、その呼び出しにのみ適用される。
コンテキストコストは中程度。入力トークンは増えるが、初回リクエスト後はプロンプトキャッシュで軽減される。トーン・出力フォーマット・ドメイン固有の知識を足すのに向く。ただし追従には逓減がある——この方法で渡す指示が多いほど、特に矛盾があると、Claude は厳密には守らなくなる。
置き場所を見直すサイン
次のような書き方をしている場合は、指示の置き場所を変えたほうがいい。
CLAUDE.md のアンチパターン
- 「毎回 X したら必ず Y」 → 確実に起きてほしいならフックへ。モデルがフォーマッタを「選んで実行する」のと、フォーマッタが「自動で走る」のは別物。
- 「絶対にこれをするな」 → 指示は誤った道具。長いセッション・曖昧な状況・プロンプトインジェクションで破られうる。本物のガードレールは決定論的でなければならず、その手段はフックと権限（permissions）。
- 30行の手順 → 手続きはスキルへ。CLAUDE.md は常に保持すべき事実（ビルドコマンド、モノレポ構成、規約）のためのもの。
- paths なしの API 専用ルール →
src/api/**にしか効かないならpaths:でスコープする。スコープなしのルールは CLAUDE.md に書くのと機構的に同じ。 - 個人の好みをプロジェクトの CLAUDE.md に → ファイルベースの全手段にはユーザーレベルの対応物がある。個人設定はローカルファイルへ。
本物のガードレール: 「絶対にするな」を強制したいなら、PreToolUse フックがツール呼び出しを検査し、exit code 2 で拒否できる。さらに管理設定（managed settings）は管理者が配布し、ユーザーのローカル設定では上書きできない——組織全体で決定論的なガードレールを強制する唯一の方法だ。
まとめ
7つの手段は「機能の数」ではなく「指示を置く軸の数」として捉えると整理しやすい。事実は CLAUDE.md、横断的な制約はパススコープルール、手続きはスキル、分離したい作業はサブエージェント、決定論的な強制はフック——という対応がベースラインになる。
特に「コードで強制できるものはコードに」という観点では、CLAUDE.md に「絶対するな」と書くのではなく、フックと権限で機構的に止めるという設計が効いてくる。指示はプレッシャー下で破られうるが、ハーネスが実行するコードは破られない。
動くものがいくつか揃ったら、スキル・サブエージェント・フック・出力スタイルをプラグインとしてまとめ、チームやプロジェクト間で一貫したセットアップを共有できる。自分のハーネス設計を、この7軸に当てはめて棚卸ししてみるとよい。