claude rules 公式まとめ

著者: ClaudeMix Team |
claude rules 公式まとめのサムネイル

はじめに

新しい開発者が入るたびに、同じルールを説明していませんか？

「このディレクトリではこのライブラリを使って」「命名規則はこうして」。どれほど口を酸っぱくして伝えても、ヒューマンエラーは必ず発生します。
これはAIであっても同じです。広大なコードベースにおいて、特定の場所だけで守るべき「ローカルルール」をAIに都度教えるのは、非効率の極みです。

この記事をお勧めしない人

  • プロジェクトの規律が、個人の記憶や口伝に頼っていても問題ないと考えている人。
  • ディレクトリごとに異なるルールを適用することを「複雑すぎる管理」だと感じる人。
  • AIに「勝手にいい感じにやってほしい」と願い、制約を与えることを嫌う人。

「ルールなき自由」が招く一貫性の欠如

  • プロジェクト全体への一律な指示は、特定のドメインにおける「例外」や「最適解」をかき消してしまう。
  • ルールが明文化（コード化）されていないと、AIは最も楽な（しかし不適切な）実装を選び、設計の純度が失われていく。
  • 最終的に、コードベースは「誰が書いたか分からない」つぎはぎの集合体となり、保守のコストが指数関数的に増大します。

.claude/rules による「自動適用される規律」

  • この記事を読めば、場所に応じたルールが自動でAIの脳にロードされ、常に正しい選択が行われる明るい未来があります。
  • 具体的には、パスベースの適用範囲設定や、モジュール化されたルール管理の手法を習得できます。
  • この方法は、フロントエンドとバックエンドで厳格な境界を保ちたい大規模プロジェクトにおいて、その実効性を発揮します。
  • この情報は、AI時代の「チーム開発の憲法」をどのように構築し、強制するかという、最先端の運用知です。

このブログもそうでした

筆者も、AIがAPIのディレクトリでReactのコンポーネントを提案し始めたときに、ルールの「地理的な管理」の必要性を痛感しました。
この記事で、AIを「規律あるプロフェッショナル」に変え、あなたの不在時でも品質を守り抜くためのTipsを凝縮しました。
プロジェクトの一貫性を追求する方は、Rulesの活用法を確認できます。

開発の進捗

  • Before: プロジェクト全体のルールが CLAUDE.md に一括記述され、ディレクトリ固有の細かな規律を適用することが困難だった。
  • Current: .claude/rules/ によるモジュール化されたルール管理へ移行し、ディレクトリやファイル単位での規律の強制を実現。
  • Next: 各ドメインの専門知識をさらに詳細なRulesとして定義し、AIがコンテキストを浪費することなく、常に「最適なモード」で作業できる環境を構築する。

具体的なタスク

  • Before: ルールの適用範囲が不明確で、AIが無関係な規約を別の場所で適用してしまう誤作動が発生していた。
  • Current: YAMLフロントマターの paths による適用範囲の精密な制御と、モジュール化されたファイル構造の整備を完了。
  • Next: 外部リポジトリのルールセットをシンボリックリンクで共有する仕組みを導入し、組織横断での品質の標準化を進める。

Rules とは：プロジェクトの「自動適用される憲法」

Claude Codeにおいて、開発効率とコード品質を劇的に向上させる機能が Rules（ルール） です。
これまでの CLAUDE.md による一括管理から、.claude/rules/ ディレクトリを活用した「モジュール化された規律の強制」へと進化しました。

1. Rules の定義：自動ロードされる制約

Rulesは、Claudeが特定のファイルやディレクトリを操作する際、 常に遵守しなければならない制約 を定義する仕組みです。

  • モジュール化 : 巨大な指示ファイルを分割し、トピックごとに管理できます。
  • 自動ロード : 起動時に .claude/rules/ 内の全Markdownファイルが自動的にコンテキストへ読み込まれます。
  • パスベースの適用 : 「特定のディレクトリだけに適用するルール」を精密に設定できます。

2. Rules の階層構造と優先順位

ルールは以下の順序でロードされ、より具体的な（プロジェクトに近い）場所にあるファイルが優先されます。

  1. User Rules (~/.claude/rules/): 自分のPC上の全プロジェクトに一律で適用したい個人設定。
  2. Project Rules (./.claude/rules/): リポジトリに含め、チーム全員で共有するプロジェクト固有の規約。

3. 実践：特定のパスにルールを限定する

YAML Frontmatterの paths フィールドを使用することで、ルールを適用する範囲を限定（スコープ）できます。

---
paths:
  - "src/api//*.ts"
  - "lib/database//*"
---

# API & DB 開発ルール
- すべてのエンドポイントに Zod によるバリデーションを必須とする。
- 直接的な SQL クエリは禁止し、必ず Prisma クライアントを使用すること。
- エラーレスポンスはプロジェクト標準の `APIResponse` 型を継承させること。

サポートされるパターン

パターン 一致するファイル
/*.ts プロジェクト内の全てのTypeScriptファイル
src/components/*.tsx 特定ディレクトリ直下のReactコンポーネント
src//*.{ts,tsx} src 配下の .ts および .tsx ファイル（ブレース展開）

4. ルールの組織化：ディレクトリによる構造化

プロジェクトが大規模な場合は、.claude/rules/ 内にサブディレクトリを作成して整理できます。これらは再帰的にすべて探索・ロードされます。

  • .claude/rules/frontend/react.md
  • .claude/rules/backend/api.md
  • .claude/rules/security/guidelines.md

また、 シンボリックリンク もサポートされているため、社内標準のルールセットを複数のリポジトリで共有することも可能です。

5. Rules 運用のベストプラクティス

  • 関心の分離 : testing.md, style.md のように、一つのファイルには一つのトピックだけを記述すると、AIの理解精度が向上します。
  • 具体性の確保 : 「読みやすいコード」といった曖昧な表現ではなく、「2スペースインデント」「早期リターンを優先」など、定量的・具体的な指示を記述します。
  • 定期的なメンテナンス : プロジェクトのフェーズや技術選定の変化に合わせて /memory コマンドで内容を更新し、常にClaudeの判断基準を最適化してください。

Rulesの実践例として、AIがE2EテストにwaitForTimeoutを追加するのをCLAUDE.mdで禁止した記録では、禁止ルールと代替パターンをセットで記述するベストプラクティスを確認できます。また、StripeエージェントがSSoT違反コードを実装した際の設計書防衛記録も、「AIへの制約設計」の具体例として参照してください。

Tips:
現在どのルールが適用されているかを確認するには、Claude Code内で /memory コマンドを実行してください。適用中のファイル一覧と、適用範囲（パス）を一目で把握できます。

この記事で設計思想を作る →