なんでもかんでもCLAUDE.mdに書かない方がいい。かわりに.claude/rules/に書こう。

ブログ

Claude Code

CLAUDE.mdが肥大化すると起きること

Claude Codeを使っていると、プロジェクトのルールやコーディング規約、注意事項などをつい全部CLAUDE.mdに書き込みたくなります。しかし、これをやりすぎると次のような問題が起きます。

関係ない作業をしているときにも、常に全ルールがコンテキストに載ってしまいトークンを消費する
ルールの数が増えるほど、タスクに関係ない指示までモデルに読み込まれ、指示がブレる
「このルールっていつ使うんだっけ」というルール自体の見通しも悪くなる

つまり、CLAUDE.mdは常時ロードされる場所である以上、そこに書くものは本当に「いつでも必要な情報」だけに絞るべきです。

`.claude/rules/` で「そのとき初めて読み込むルール」を作る

より良い方法は.claude/rules/というディレクトリを用意し、特定のファイルやディレクトリを操作するタイミングになって初めて読み込まれるルールを定義するというやり方です。

イメージとしては、常時ロードのCLAUDE.mdとは別に、以下のような粒度でルールファイルを分割します。

.claude/
  rules/
    frontend.md      # src/components/ 以下を触るときのルール
    api.md           # api/ 以下を触るときのルール
    migration.md     # db/migrations/ を触るときのルール
    testing.md       # *.test.ts を書くときのルール

具体例1: バックエンドAPI用ルール

src/components/配下を編集するときだけ、コンポーネント設計の方針や命名規則、状態管理の方針を読み込む。

./claude/rules/api.md

---
paths:
"api/**/*.go"
---

# API 開発ルール

- すべての API エンドポイントは入力検証を含める必要があります
- 標準エラー応答形式を使用します
- OpenAPI ドキュメンテーションコメントを含めます

具体例2: フロントエンド用ルール

src/components/配下を編集するときだけ、コンポーネント設計の方針や命名規則、状態管理の方針を読み込む。

./claude/rules/frontend.md

---
paths:
"frontend_app/src/components/*.{ts,tsx}"
"frontend_app/src/common/*.{ts,tsx}"
---

# フロントエンド開発ルール

- 関数型で記述する
- propsの型は必ずinterfaceで定義する
- スタイルはCSS Modulesを使用し、インラインstyleは禁止
- 状態管理は複雑な場合はカスタムフックに切り出す

具体例3: DBマイグレーション用ルール

db/migrations/を触るときだけ、破壊的変更の手順や命名規則を読み込む。

# .claude/rules/migration.md
- カラム削除は2段階リリース(まず参照を切ってから削除)を必須とする
- マイグレーションファイル名は `YYYYMMDDHHMMSS_description.rb` 形式
- 本番反映前にdry-runの結果を必ず提示すること

具体例4: 機密ファイルへのアクセス制御

これはルールの読み込みというより権限周りの話ですが、.env*や*.key、.aws/、.ssh/などへのアクセスをpermissions.deny側で塞いでおくのも、CLAUDE.mdに「これらのファイルは触るな」と書き連ねるより確実で軽量です。ルールとして「読ませない」より、そもそも「触れなくする」方が事故が起きにくいという発想です。

具体的には、.claude/settings.json(ユーザー全体なら~/.claude/settings.json)に、permissions.denyの配列でTool(パターン)形式で指定します。

{
  "permissions": {
    "deny": [
      "Read(**/.env*)",
      "Edit(**/.env*)",
      "Write(**/.env*)",
      "Read(**/*.pem)",
    ]
  }
}

ポイントは、Read/Edit/Writeをそれぞれ個別に指定する必要があることです。Readだけ塞いでもEditやWriteは素通りしてしまうので、機密ファイルに関しては3つとも塞ぐのが安全です。

なお、バージョンによっては「設定していても実際にはブロックされない」という不具合がGitHub Issue側で複数報告されています。設定して満足するのではなく、ダミーファイルで実際に読ませてみて弾かれるかを検証しておくと安心です。

運用してみて感じているメリット

CLAUDE.md自体がスリムになり、どんな作業でも見通しが良い
特定領域の作業に入った瞬間だけ詳細ルールが効くので、無関係な作業への指示の混線が減る
ルールをファイル単位で管理できるので、レビューや更新もしやすい

まだ「どのタイミングで.claude/rules/配下を読み込ませるか」の仕組み自体は各自の運用に依存する部分ですが、CLAUDE.mdに全部書き込むよりも、関心事ごとにルールを分割して必要な時だけ参照させる方が、コンテキストの無駄遣いも指示のブレも減らせると感じています。

一覧へ戻る2026-06-11