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つある。

@import と paths の違い。@import で分けても起動時に全部読み込まれるが、.claude/rules/ に paths を付けると一致するファイルを読んだときだけ読み込まれる

.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 のあとルールが守られなくなる理由

長いセッションで、さっきまで守られていたルールが急に無視され始める事がある。これも仕様を知ると理由が分かる。

/compact のあとの扱い。ルートの CLAUDE.md は再注入されて残り、サブディレクトリの CLAUDE.md と paths 付きのルールは次にそのファイルを読むまで戻らず、会話だけで伝えた指示は消える

対策としては、会話の中で伝えた大事なルールは、その場でCLAUDE.mdに書いておく事。同じ指摘を2回したら、それはファイルに書いておくべき内容だと思う。

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

考え方として、いちばん大事なのはここだと思う。

CLAUDE.mdはあくまで文脈として渡されるもので、強制する仕組みではない。コミット前に必ずlintを走らせる、保存したら必ずフォーマッタをかける、といった必ずやってほしい事は、CLAUDE.mdではなく hooks に書く。hooksは決まったタイミングでシェルコマンドとして実行されるので、Claudeの判断に関係なく動いてくれる。

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

使い分けとしては、破られたら困る事はhooks、破られても直せる事はCLAUDE.md、と考えている。

どこに何を書くか。CLAUDE.md・.claude/rules/・Skills は文脈として渡り、守るかはモデルの判断。hooks と permissions.deny は仕組みで効く

よくある質問

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

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

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

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

まとめ

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

まずは自分のCLAUDE.mdが何行あるか、数えてみるところから始めてみてください。

関連記事

書いた人

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

参考・出典