Claude Code Rules System完全ガイド——.claude/rules/でプロジェクト横断のコーディング規約を統一する

はじめに

Claude Codeをチームで運用していると、こんな問題に直面します。

CLAUDE.mdはプロジェクト単位の指示書として強力ですが、「すべてのプロジェクトで守るべき共通規約」や「言語ごとのイディオム」を管理するにはスコープが合いません。毎回同じルールをコピペするのも現実的ではありません。

そこで登場するのがRules Systemです。~/.claude/rules/（ユーザーレベル）や.claude/rules/（プロジェクトレベル）にルールファイルを配置し、共通ルールと言語別ルールを階層的に管理できます。

この記事を読み終わると、以下ができるようになります：

• Rules SystemとCLAUDE.md・Auto Memoryの違いを理解できる
• 共通ルールと言語別ルールの階層設計ができる
• YAMLフロントマターで対象ファイルを絞り込める
• 言語別ルールによるオーバーライドの仕組みを使いこなせる
• install.shスクリプトでチームにルールを展開できる

Rules Systemの全体像

CLAUDE.md・Auto Memory・Rulesの棲み分け

Claude Codeには3つのコンテキスト供給手段があります。Rules Systemはその中で「プロジェクトを横断して再利用できるルール集」という位置づけです。

アーキテクチャ

ポイント： ユーザーレベル（~/.claude/rules/）のルールは全プロジェクトに適用され、プロジェクトレベル（.claude/rules/）のルールはそのリポジトリ内でのみ適用されます。

ハンズオン 1: ディレクトリ構造を設計する

Step 1: 基本構造を作る

Rules Systemの推奨ディレクトリ構造は、common/（言語非依存）と言語別ディレクトリの2層です。

mkdir -p ~/.claude/rules/{common,typescript,python,golang}

~/.claude/rules/
├── common/              # 言語非依存の原則（常にインストール）
│   ├── coding-style.md  # コーディングスタイル
│   ├── git-workflow.md   # Gitワークフロー
│   ├── testing.md        # テスト要件
│   ├── security.md       # セキュリティガイドライン
│   └── patterns.md       # デザインパターン
├── typescript/           # TypeScript固有
│   ├── coding-style.md
│   └── testing.md
├── python/               # Python固有
│   ├── coding-style.md
│   └── testing.md
└── golang/               # Go固有
    ├── coding-style.md
    └── testing.md

common/にはすべての言語に共通する原則（イミュータビリティ、エラーハンドリング、テストカバレッジ80%以上など）を書き、言語別ディレクトリにはその言語固有のイディオムやツールを書きます。

Step 2: 共通ルールを書く

common/coding-style.mdの例です。言語固有のコード例は含めず、原則だけを記述します。

<!-- ~/.claude/rules/common/coding-style.md -->

# Coding Style

## イミュータビリティ（必須）

既存のオブジェクトを変更せず、常に新しいオブジェクトを生成する。

## ファイル構成

- 高凝集・低結合
- 1ファイル200〜400行が目安、800行が上限
- 機能/ドメインごとに整理（型別に分けない）

## エラーハンドリング

- すべてのレベルでエラーを明示的にハンドリング
- UIにはユーザーフレンドリーなメッセージを表示
- サーバー側では詳細なエラーコンテキストをログに記録
- エラーを握りつぶさない

重要： Rulesファイルはセッション開始時にコンテキストに読み込まれるため、簡潔に保つことが鉄則です。長文の解説よりも、箇条書きや表で「何をすべきか」を明確に示しましょう。

Step 3: 言語別ルールを書く

言語別ファイルは対応する共通ルールを拡張する形で書きます。冒頭に共通ルールへの参照を入れるのがベストプラクティスです。

<!-- ~/.claude/rules/typescript/coding-style.md -->
---
paths:
  - "**/*.ts"
  - "**/*.tsx"
  - "**/*.js"
  - "**/*.jsx"
---
# TypeScript/JavaScript Coding Style

> This file extends [common/coding-style.md](../common/coding-style.md)
> with TypeScript specific content.

## 型定義

- エクスポートされる関数には引数型・戻り値型を明示
- ローカル変数は型推論に任せる
- 繰り返し現れるオブジェクト型は interface で定義

## interface vs type

- オブジェクト型: interface を使用
- ユニオン・交差・マップ型: type を使用
- Props定義: interface を使用

注目すべきはYAMLフロントマターです。paths:にglobパターンを指定すると、そのパターンにマッチするファイルを編集しているときだけルールが読み込まれます。TypeScriptのルールがPythonファイルの編集時に混入することを防げます。

ハンズオン 2: オーバーライドの仕組みを理解する

言語別ルールは共通ルールより優先される

Rules Systemでは言語別ルールが共通ルールをオーバーライドします。CSSの詳細度（specificity）と同じ考え方です。

たとえば、common/coding-style.mdで「イミュータビリティを常に守る」と定義していても、golang/coding-style.mdで「ポインタレシーバによるstruct変更はGo流として推奨」と書けば、Goファイルの編集時にはGo固有のルールが優先されます。

オーバーライドの明示

言語別ルールでオーバーライドする箇所には、共通ルールへの参照と理由を書いておくのが良い慣習です。

<!-- ~/.claude/rules/golang/coding-style.md -->
---
paths:
  - "**/*.go"
---

# Go Coding Style

> This file extends [common/coding-style.md](../common/coding-style.md)
> with Go specific content.

## ミュータビリティ

Goではポインタレシーバによるstruct変更がイディオマティック。
common/coding-style.md のイミュータビリティ原則よりも
Go流のmutationパターンを優先する。

こうしておくと、ルールの読み手（人間にもClaudeにも）が「なぜ共通ルールと違うのか」を理解できます。

ハンズオン 3: プロジェクトレベルのRulesを活用する

ユーザーレベル（~/.claude/rules/）の他に、プロジェクトレベル（.claude/rules/）でもRulesを定義できます。こちらはリポジトリにコミットしてチームで共有するのに適しています。

ファイルパターンで適用範囲を絞る

<!-- .claude/rules/api-conventions.md -->
---
paths:
  - "src/app/api/**/*.ts"
  - "src/lib/api/**/*.ts"
---

# API実装ルール

- レスポンスは ApiResponse<T> 型でラップ
- エラーハンドリングは AppError クラスを使用
- バリデーションは zod スキーマで実装
- 認証が必要なエンドポイントは authMiddleware を適用

<!-- .claude/rules/component-rules.md -->
---
paths:
  - "src/components/**/*.tsx"
---

# コンポーネント実装ルール

- Props型は interface で定義
- デフォルトエクスポート禁止（named export のみ）
- Tailwind CSSのみ使用（CSS Modules禁止）
- aria属性を適切に設定（WCAG 2.1準拠）

paths:を指定すると、該当ファイルを編集しているときだけルールがコンテキストに注入されます。APIファイルを触っているときにコンポーネントルールが混ざることがなくなり、コンテキストを効率的に使えます。

CLAUDE.mdからの参照

CLAUDE.mdに@構文を使ってRulesファイルを参照することもできます。

<!-- CLAUDE.md -->
## 詳細ルール
@.claude/rules/api-conventions.md
@.claude/rules/component-rules.md

こうすると、パスマッチに加えてCLAUDE.md経由でも参照でき、ルールの存在を明示的にチームへ伝えられます。

チームへの展開

install.shスクリプトで配布する

ユーザーレベルのルールをチームメンバーに配布するには、installスクリプトが便利です。

#!/bin/bash
# install.sh — Claude Code Rules インストーラー
set -euo pipefail

RULES_DIR="$HOME/.claude/rules"

# 引数チェック
if [ $# -eq 0 ]; then
  echo "Usage: ./install.sh <language> [<language> ...]"
  echo "Available: typescript python golang swift php"
  exit 1
fi

# common/は常にインストール
echo "Installing common rules..."
mkdir -p "$RULES_DIR"
cp -r rules/common "$RULES_DIR/common"
echo "  -> $RULES_DIR/common/"

# 言語別ルールをインストール
for lang in "$@"; do
  if [ -d "rules/$lang" ]; then
    echo "Installing $lang rules..."
    cp -r "rules/$lang" "$RULES_DIR/$lang"
    echo "  -> $RULES_DIR/$lang/"
  else
    echo "Warning: rules/$lang not found, skipping."
  fi
done

echo "Done! Rules installed to $RULES_DIR"

使い方はシンプルです。

# TypeScriptプロジェクト用
./install.sh typescript

# 複数言語を一括インストール
./install.sh typescript python golang

ディレクトリ構造を保つ（重要）

cp -r rules/common のようにディレクトリごとコピーしてください。cp rules/common/*のようにフラットに展開すると、commonとtypescriptに同名ファイル（coding-style.md）があるため上書きされてしまいます。また、言語別ファイルの../common/への相対パス参照も壊れます。

Gitリポジトリで管理する

ルールセット自体をGitリポジトリとして管理すれば、バージョン管理とチームへの展開を両立できます。

# ルールリポジトリを作成
mkdir claude-code-rules && cd claude-code-rules
git init

# ルールを配置
mkdir -p rules/{common,typescript,python,golang}
# ... ルールファイルを作成 ...

# チームメンバーは clone → install
git clone git@github.com:your-org/claude-code-rules.git
cd claude-code-rules
./install.sh typescript

PRベースでルール変更のレビューを行えるため、チーム全体のコーディング規約を安全にアップデートできます。

まとめ

次のアクションとしておすすめ：

1. ~/.claude/rules/common/にコーディング規約を1ファイル作る — まずは小さく始める
2. メインの開発言語のルールを追加する — typescript/やpython/など
3. プロジェクトの.claude/rules/にpath-specificルールを作る — API、コンポーネントなど
4. install.shを用意してチームに展開する — GitリポジトリでPRレビュー運用
5. ルールの簡潔さを定期的にチェックする — 長くなりすぎるとコンテキスト効率が低下

Rules Systemを活用することで、「プロジェクトが変わるたびにCLAUDE.mdを書き直す」「チームメンバーごとにClaude Codeの出力が違う」といった問題から解放されます。共通原則は一箇所で管理し、言語ごとの差異はオーバーライドで吸収する——この階層設計が、AI駆動開発のスケーリングを支えてくれます。

---

参考リンク：

• Claude Code公式ドキュメント — Memory
• Claude Code公式ドキュメント — Settings

---

関連記事：

• Claude Code メモリシステム徹底解説——CLAUDE.md・auto memory・コンテキスト最適化の実践テクニック
• Claude Code Hooks完全ガイド——pre/postフックでAI開発ワークフローを自在にカスタマイズ