Rules・Output Styles・システムプロンプト追記
重要キーワード (6 語)
Rules
(ルール)
— .claude/rules/ に置く制約。paths で対象ファイルにスコープできる
paths (frontmatter)
(パスのスコープ)
— Rule をどのファイルに効かせるか限定する frontmatter 項目
Output Styles
(出力スタイル)
— .claude/output-styles/ の指示。既定のシステムプロンプトを置き換える
keep-coding-instructions
(既定指示の保持)
— 出力スタイルの frontmatter に付けると既定のコーディング指示を残せるオプション
--append-system-prompt
(システムプロンプト追記)
— 起動時に既定プロンプトへ指示を足すだけのフラグ。役割は書き換えない
Prompt Cache
(プロンプトキャッシュ)
— 同じ前置きを再利用してコストを下げる仕組み。追記は初回以降が安い
このレッスンのゴール
第6章ではこれまで Slash Commands・Hooks・Skills・MCP・Subagents と、Claude Code を操る手法を見てきました。今回は まだ扱っていない残り3つ を学びます。
- (A) Rules —
.claude/rules/に置く「制約(やってはいけない/必ずこうする)」 - (B) Output Styles —
.claude/output-styles/に置く「役割そのものを変える指示」 - (C)
--append-system-prompt— 起動時に「指示を足すだけ」のフラグ
特に (B) と (C) は超混同しやすい(置き換える vs 足すだけ)ので、対比で腹落ちさせます。最後に「7つの操縦法をどう使い分けるか」の地図は次の 操縦法の地図(ch6-l10) でまとめます。
原典: Anthropic ブログ「Steering Claude Code — Skills, Hooks, Rules, Subagents, and More」。Claude Code のカスタマイズ手法は7種類あり、それぞれ「いつ読み込まれるか/コンパクション(文脈の圧縮)で消えるか/コスト/強制力」が違うので、何でも CLAUDE.md に書くのではなく目的に合った手法を選ぶのが肝、という話です。
(A) Rules — ファイル単位の「制約」
Rules は .claude/rules/ に置く Markdown ファイル です。役割は「特定の制約(constraint)を効かせる」こと。例えば「マイグレーションは追記のみ(append-only)」「API ハンドラは必ず入力検証する」のような、ファイル単位で守らせたいルールにピッタリです。
最小例(frontmatter + 本文)
frontmatter の paths で、どのファイルに効かせるかをスコープできます。
---
paths:
- "src/api/**"
- "**/*.handler.ts"
---
すべての API ハンドラは、処理を始める前に Zod で入力を検証すること。
検証に失敗した場合は 400 を返し、内部の例外メッセージはそのまま外に出さない。
これで「src/api/ 配下や *.handler.ts を Claude が触ったときだけ」このルールが効きます。フロントエンドのコンポーネントを編集している間は読み込まれず、トークンを消費しません。
paths を付けないと「常に」トークンを消費する
paths を省くと、その Rule は 常時ロード(unscoped) になり、ルート CLAUDE.md と同じく セッション開始時から常にロード されます。常に効いてほしい全体ルールならそれでもよいですが、API 専用ルールのように対象が限られているものは、必ず paths でスコープしてください。スコープしないと、関係ないファイルを触っている間もずっとトークンを食い続けます。
CLAUDE.md との違い(なぜ Rules を使うのか)
CLAUDE.md にも規約は書けますが、CLAUDE.md は「プロジェクト全体の説明・規約」を書く場所。一方 Rules は「特定パスに効く強めの制約」を分離して管理できるのが利点です。「絶対これをするな」という本当のガードレールが必要なら、Rules よりさらに強い Hooks(ch6-l2) のブロック機能(exit code 2 で拒否)や managed settings を使う、という棲み分けになります。
あなたは Claude Code のルール設計者です。「DB マイグレーションファイル(migrations/ 配下)は追記のみで、既存の up/down を書き換えてはいけない」という制約を、.claude/rules/ に置く Markdown として書いてください。frontmatter の paths でスコープし、本文は日本語で。完成したファイルの全文を返してください。(B) Output Styles — 「役割そのもの」を変える
Output Styles は .claude/output-styles/ に置くファイルで、指示を システムプロンプトに注入します。性質が独特です。
- 決してコンパクションされない(会話が長くなって圧縮されても消えない)
- 毎セッションの開始時に必ずロードされる(常に効く)
- 組み込みスタイルが3つある: Proactive(先回り) / Explanatory(解説重視) / Learning(学習向け)
ここまでだと「常に効く便利な指示」に聞こえますが、重要な落とし穴があります。
警告: デフォルトの出力スタイルを「置き換える」
出力スタイルを変更すると、Claude のデフォルトの出力スタイルが置き換え(replace)られます。デフォルトには、表に出ていないだけで次のような既定の指示が含まれています。
- 変更範囲をむやみに広げず、最小限に絞る指示
- コードコメントを 付ける/省く基準
- セキュリティ上の懸念への対処
出力スタイルを差し替えると、こうした既定の振る舞いが まとめて外れてしまうのが基本動作です。だから Output Styles は「役割そのものを大きく変えたいときだけ、慎重に」使うものです。まずは組み込みの Learning や Explanatory を選ぶところから始め、いきなり自作で全置換しないのが安全です。
既定のコーディング指示を残したいとき
原典ブログによれば、出力スタイルの frontmatter に keep-coding-instructions: true を付けると、既定のコーディング指示(絞り込み・コメント基準・セキュリティ配慮など)を残したまま、自分のスタイルを足せます。「役割は変えたいが、Claude らしい安全な振る舞いは消したくない」ときの保険として覚えておくとよいです。
---
keep-coding-instructions: true
---
あなたは新人エンジニアに教える先生です。回答は手順を1ステップずつ説明し…
(C) --append-system-prompt — 「足すだけ」
--append-system-prompt は Claude Code 起動時に渡すフラグで、元のシステムプロンプトに指示を 足すだけ(additive) です。
claude --append-system-prompt "出力するコードは必ず日本語コメント付き。変数名はスネークケース。回答末尾に参照したファイル名を列挙すること。"
ここが Output Styles との 決定的な違いです。
- Output Styles = 既定を 置き換える(役割を変える/既定指示が外れる ※
keep-coding-instructionsで保持も可) --append-system-prompt= 既定に 足すだけ(役割は書き換えない/既定指示は常に残る)
つまり「Claude らしさ(変更範囲を絞る・セキュリティ配慮など)はそのままに、自社のコーディング規約・出力フォーマット・ドメイン知識だけ上乗せしたい」ときは 追記 が一番素直です。
コスト
追記した内容は プロンプトキャッシュ に乗るため、セッション内の 初回リクエスト以降はコストが下がります。毎回フルで課金されるわけではないので、規約や定型フォーマットを足す用途に向いています。
私はチーム共通のコーディング規約を Claude Code に常に守らせたいです。(1) Output Styles で書くべきケースと (2) --append-system-prompt で書くべきケースを、それぞれ具体例つきで3つずつ挙げ、なぜそちらが適切かを一言で説明してください。3つを並べて比較
| 手法 | 置き場所 / 渡し方 | 何をする | いつ使う | 注意点 |
|---|---|---|---|---|
| Rules | .claude/rules/*.md |
ファイル単位の制約 | 「マイグレは追記のみ」等 | paths なしだと常時トークン消費 |
| Output Styles | .claude/output-styles/ |
役割を置き換える | 役割を大きく変える時だけ | 既定の絞り込み/セキュリティ配慮が外れる(keep-coding-instructions で保持可) |
| 追記 | --append-system-prompt |
既定に足すだけ | 規約/フォーマット/知識を上乗せ | 初回以降はキャッシュで安い |
ブログ準拠の「読み込まれるタイミング / コンパクション時 / コスト」でも整理しておきます。
| 手法 | 読み込み | コンパクション時 | コスト |
|---|---|---|---|
| Rules | セッション/パスでスコープ | 再注入される | 中(paths スコープで減) |
| Output Styles | セッション開始 | 決して圧縮されない | 高 |
| システムプロンプト追記 | 起動時 | 初回以降キャッシュ | 中 |
Hooks・Skills とは「役割が違う」
混同しないように一言。今回の3つは「Claude に 何を守らせ・どんな役割にし・何を足すか」という 指示・制約 の話です。一方:
- Hooks(ch6-l2) は「イベント発火で 決定論的にコマンドを実行する自動化」(linter を走らせる/危険コマンドをブロック)
- Skills(ch6-l3) は「手続き(workflow) を呼び出し時に読み込ませる」(デプロイ手順・レビュー手順)
似ているようで担当が違います。「毎回必ず実行したい」なら Rules ではなく Hooks、「長い手順」なら Output Styles ではなく Skills、という具合です。7種類の全体像と使い分けの地図は次の 操縦法の地図(ch6-l10) でまとめます。
まとめ
- Rules =
.claude/rules/の制約。pathsで対象を絞らないと常にトークンを食う。 - Output Styles =
.claude/output-styles/。置き換えるので既定指示が外れる(keep-coding-instructions: trueで残せる)。役割を大きく変える時だけ慎重に。 --append-system-prompt= 足すだけ。役割は変えず、規約・フォーマット・知識を上乗せ。初回以降はキャッシュで安い。- 「置き換える vs 足すだけ」を取り違えないことが、このレッスンで一番大事。