CLAUDE.mdにルールを書いた。なのに守られたり守られなかったりする。しかも、長く書くほど効かなくなっている気がする。

僕はずっとこれで悩んでいました。で、公式ドキュメントを読み直したら、原因は書き方じゃなくてファイルの置き方でした。しかも全部ちゃんと書いてある。読んでいなかっただけです。

この記事では、その仕様を整理して、そのまま使える構成にまとめます。

検証環境: Claude Code（デスクトップアプリ）／2026年8月時点の公式ドキュメントに準拠。このあたりは更新が速いので、細かい部分は末尾の出典で最新を確認してください。

先に結論

こんな人向けです

僕は制作会社でデザインとコードの両方を担当していて、案件ごとの仕様をClaude Codeに渡して作っています。最初は思いついたルールを片っ端からCLAUDE.mdに足していました。丁寧に書けば書くほど精度が上がると思っていたからです。

実際に起きたのは逆でした。足すほど守られなくなる。しかも、どのルールが無視されるかも読めない。原因はこのあと書く3つでした。

誤解1：長く書くほど正確になる

これが逆です。公式ドキュメントには、1ファイル200行未満を目標にすること、長いファイルはコンテキストを消費して追従性を下げることがはっきり書かれています。

もうひとつ大事なのが、CLAUDE.mdの届き方です。中身はシステムプロンプトの一部じゃなくて、その後ろにユーザーメッセージとして注入されます。つまり設定による強制じゃなくて、ただの文脈。守るかどうかは最終的にモデルの判断に委ねられます。

だから、この2つは書いても意味がありません。

書くときの基準はひとつだけで、確認できる粒度まで具体的にすることです。

効かない書き方

効く書き方

コードを綺麗にフォーマットして

インデントは半角スペース2つ

ちゃんとテストして

コミット前に npm test を実行する

ファイルを整理して

APIハンドラは src/api/handlers/ に置く

パフォーマンスに配慮して

画像は <picture> でAVIFを第一候補にする

あと、コードを読めば分かることは書かない。ディレクトリ構成、依存パッケージ一覧、アーキテクチャの説明。このへんは書いた分だけ他の指示から注意を奪うだけです。残すべきなのは、落とし穴と、なぜそうするのかの理由と、一般的なやり方と違う部分。ここだけです。

誤解2：@importで分ければ軽くなる

僕が一番勘違いしていたのがここです。

CLAUDE.mdは @path/to/file で他のファイルを読み込めます。ただし読み込まれたファイルは起動時に展開されてコンテキストに入るので、消費するトークンは減りません。分割は整理のためで、軽量化のためじゃないんです。

# CLAUDE.md

@docs/design-system.md   ← 起動時に全文がコンテキストへ
@docs/coding-rules.md    ← これも全文がコンテキストへ

ついでに、知っておくと地味に助かる挙動が3つあります。

じゃあどうするか：.claude/rules とpathsスコープ

本当にコンテキストを節約できるのはこっちです。.claude/rules/ に置いたルールに paths を書くと、そのパターンに一致するファイルをClaudeが読んだときだけルールが読み込まれます。

your-project/
├── .claude/
│   ├── CLAUDE.md          # 常に読み込まれる（200行以内に抑える）
│   └── rules/
│       ├── css.md         # CSSを触るときだけ
│       ├── html.md        # HTMLを触るときだけ
│       └── deploy.md      # 常に読み込まれる（paths なし）
---
paths:
  - "**/*.{css,scss}"
---

# CSSルール

- カスタムプロパティは `:root` にまとめる。値の直書きは禁止
- メディアクエリはコンポーネントごとに書く。末尾にまとめない
- z-indexは定義済みの変数以外を使わない

paths を書かないルールは常に読み込まれます。glob記法なので、まとめ書きもできます。

---
paths:
  - "src/**/*.{ts,tsx}"
  - "tests/**/*.test.ts"
---

複数の案件で同じルールを使いたいなら、シンボリックリンクが効きます。案件ごとに同じ規約をコピペしている人は、ここで一気に楽になります。

ln -s ~/shared-claude-rules .claude/rules/shared

どこに何を書くか

やりたいこと

置き場所

全体に効かせたい方針・規約

CLAUDE.md

特定のファイルだけの規約

.claude/rules/（paths 付き）

絶対にやらせたい処理

hooks

ツールやコマンドごと禁止したい

権限設定（permissions.deny）

手順の長い定型作業

Skills（必要なときだけ読み込まれる）

コピペ用テンプレート（Web制作向け）

使い回せるのは、中身ではなく見出しの骨組みのほうです。案件が変われば絶対ルールも品質基準も変わりますが、この5つの枠は変わりません。

# プロジェクト概要
（1〜2行。コードを読んでも分からない前提だけ）

## コマンド
（毎回使うものだけ。開発・確認・デプロイ）

## 絶対ルール
（破られると作り直しになるもの。「〜しない」で書けると強い）

## 品質基準
（数値で書く。守れたか判定できるもの）

## 迷ったとき
（勝手に進めてほしくない場面の指示）

埋め方の例として、僕が静的サイトの案件で使っている中身も置いておきます。Claudeがコードから読み取れないことだけを書くと、だいたい30行くらいに収まります。

# プロジェクト概要

静的なコーポレートサイト。バンドラは使わず、素のHTML/CSS/JSで作る（npm scriptsは画像最適化などに使う）。

## コマンド

- ローカル確認: `npx serve public`
- 画像最適化: `npm run img`

## 絶対ルール

- CSSフレームワークを入れない
- JavaScriptライブラリを追加しない（jQuery含む）
- 画像はAVIFを主、WebPをフォールバックにして `<picture>` で出す
- すべての `<img>` に width / height を書く
- 色とフォントサイズは `tokens.css` の変数以外を使わない

## 品質基準

- LCP 2.5秒以内 / INP 200ミリ秒未満 / CLS 0.1以下
- WCAG 2.2 AA（コントラスト比・キーボード操作・フォーカス可視化）

## 迷ったとき

- 実装せずに選択肢を出す
- 既存のコンポーネントで代替できないか先に確認する

これ以外は全部 .claude/rules/ に逃がします。常に読ませるものは短く、細かい話は条件付きで。方針はこれだけです。

ちゃんと読み込まれているか確認する

書いて満足するのが一番危ないので、確認する手段も覚えておきます。

指示が効かないと感じたら、書き直す前にまず /context を見てください。そもそも読み込まれていなかったというオチが普通にあります。僕はこれでした。

auto memoryにも上限がある

CLAUDE.mdが人間の書く指示なのに対して、auto memoryはClaudeが自分で書く学習メモです。保存先はプロジェクトごとの ~/.claude/projects/<プロジェクト>/memory/。

CLAUDE.md

auto memory

書く人

自分

Claude

中身

指示・ルール

気づき・パターン

読み込み

毎回全文

毎回（先頭200行 または 25KBまで）

ここに罠があります。起動時に読まれるのは MEMORY.md の先頭200行、または25KBのどちらか先に来たところまで。それを超えた分は読まれません。トピック別のファイル（debugging.md など）は起動時には読まれず、必要になったときにClaudeが自分で開きに行きます。

なので MEMORY.md は索引として短く保つのが正解です。放っておくと、保存されているのに一度も読まれない部分が静かに増えていきます。たまに /memory で中を見て、間違った学習は消してください。古い間違いは、メモが無い状態より害があります。

/compactのあと急にルールを破り出す件

長いセッションで、さっきまで守っていたルールを突然無視し始める。あれも仕様を知ると納得できます。

対策は単純で、会話で伝えた大事なルールは、その場でCLAUDE.mdに書くこと。同じ指摘を2回した時点で、それはもうファイルに書くべき内容です。

絶対にやらせたいならhooksに書く

考え方として一番大事なのがこれです。

CLAUDE.mdはあくまで文脈で、強制する仕組みじゃありません。コミット前に必ずlintを走らせる、保存したら必ずフォーマッタをかける。この手の「絶対」は、指示文じゃなくて hooks に書きます。hooksは決まったタイミングでシェルコマンドとして実行されるので、Claudeがどう判断しようが動きます。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $CLAUDE_FILE_PATHS"
          }
        ]
      }
    ]
  }
}

線引きはシンプルです。破られたら困ることはhooks、破られても直せることはCLAUDE.md。

よくある質問

Q. 200行を超えたら動かなくなりますか。
いいえ、読み込みはされます。ただ長いほどコンテキストを食って、守られにくくなります。200行は実用的な目安です。

Q. 分割したのにコンテキストが減りません。
@import は起動時に全文展開されるので減りません。減らしたいなら .claude/rules/ の paths を使ってください。

Q. /init で自動生成するのはアリですか。
出発点としてはアリです。ただ生成されたものにはコードから読み取れる情報が多く入るので、そこから削る作業が本番になります。

Q. Web制作でも意味ありますか。
むしろ相性がいいです。デザイントークン、命名規則、アクセシビリティ要件みたいに、毎回同じことを言い直している内容ほど効果が出ます。

まとめ

AIに書かせる前提の制作だと、生産性を決めるのはプロンプトの上手さより指示ファイルの設計でした。ここを直しただけで、同じモデルなのに出力の安定感がはっきり変わります。

まずは自分のCLAUDE.mdが何行あるか、数えるところからどうぞ。

関連記事

書いた人

NIGO / 制作会社のデザイナー兼エンジニア。デザインとコードの両方を担当していて、コーポレートサイトや店舗サイトを作っています。制作のご相談はお問い合わせからどうぞ。

参考・出典