CLAUDE.mdに指示を足し続けて半年が過ぎた頃、ファイルを開いて愕然とした。禁止事項、日時のルール、外部ツール連携の注意点、チーム運用の方針が1ファイルにぎっしり詰まっていて、私でも「あのルールどこに書いたっけ」と探し回る始末だった。Claude Codeの応答にも変化が出ていて、後半に書いたルールを無視されることが目に見えて増えてきていた。

書いておいたルールが無視される。同じ指摘を何度も繰り返す。その頻度が増え始めたのが、変化を決断した一番の理由だった。分離という手法を知ったきっかけは、ハーネスエンジニアリングについての記事を読んだことだ。「AIへの指示を構造的に設計する」という発想に触れて、1ファイルに詰め込むやり方の限界がはっきり見えた。

この記事では、CLAUDE.mdの肥大化問題と、.claude/rules/ディレクトリを使った分離で状況がどう変わったかを書いていく。

CLAUDE.mdが肥大化する構造的な問題

CLAUDE.mdは「とりあえずここに書いておこう」の場所になりやすい。Claude Codeに何かミスされたら禁止事項を追加する。外部ツール連携でハマったら手順を書き足す。曜日ごとのタスクが増えれば曜日別ルールを書く。使い込むほどルールが増えるのは、むしろ自然な成長の証でもある。

問題は量そのものではなく、整理しないまま膨らませることにある。200行を超えたあたりから、書いた本人でもどのルールがどこにあるか把握できなくなった。CLAUDE.mdの書き方について詳しくは「CLAUDE.mdの育て方」を参照してほしい。もう1つ厄介なのが、指示の優先度が曖昧になること。ファイルの前半に書いた「基本姿勢」と後半に書いた「禁止事項」のどちらが優先されるのか、人間が読めば文脈で判断できるが、AIには伝わりにくい。結果として、後半に追加したルールほど無視されやすくなる。これは実際に何度も経験した。

ルールが増えること自体は悪くない。失敗するたびに学んで、それをルール化していくのは正しい成長のプロセスだ。ただし1ファイルに全部押し込めるのは限界がある。

.claude/rules/ の仕組みと基本

Claude Codeには .claude/rules/ というディレクトリにルールを分離する機能が用意されている。やることは単純で、.claude/rules/フォルダの中にマークダウンファイルを置くだけ。セッション開始時にClaude Codeがこのディレクトリ内のファイルを自動で読み込んでくれる。

CLAUDE.mdとの使い分けはこう考えると整理しやすい。CLAUDE.mdは「メインの指示書」で、役割定義、基本姿勢、ディレクトリ構造の案内など骨格だけを担当する役割だ。一方のrulesは「補助ルール集」で、具体的な手順や禁止事項を個別ファイルとして保管する。

CLAUDE.md本体から @ファイル名 の記法でrulesを参照する方法も用意されている。私の場合は @AGENTS.md という形でエージェント定義を別ファイルに切り出した。この記法を使えば、CLAUDE.md本体は薄いまま必要な情報をリンクで辿れる。

分離の設計パターン -- 実例で見る

実際に運用しているルールファイルの構成を紹介したい。全部で6ファイルあるが、設計の考え方が伝わる3つに絞った。

パターン1: ドメイン別分離

最も基本的な分離方法。1つのドメイン（テーマ）に1ファイルを対応させる。

ファイル名	ドメイン	内容の例
prohibited-actions.md	禁止事項	フォルダ作成禁止、ファイル削除禁止、force push禁止
datetime-handling.md	日時管理	JST基準の強制、曜日確認の手順、表記フォーマット

ファイル名だけで中身が推測できる命名が大切だ。「rule01.md」のような連番は半年後に困る。「prohibited-actions.md」なら開かなくても内容が想像できる。

パターン2: 失敗からの昇格

日時管理ルール（datetime-handling.md）が生まれた経緯を具体的に書く。最初はmemory（Claude Codeのセッション間記憶）に「曜日計算はJST基準で」と1行記録しただけだった。しかし数週間後にまた同じミスが起きる。システム時刻がUTC基準のため、日本時間の曜日をAIが間違えるという構造的な問題だった。

2回目の再発で「これはmemoryの1行メモでは足りない」と判断し、専用のルールファイルに昇格させた。ファイルには「なぜこのルールが必要か」「具体的にどうすればいいか」「過去の失敗事例」を記載している。昇格後、同じミスはぴたりと止まった。

この経験から「同じミスが2回起きたらルールファイル化する」という基準ができた。1回目はmemoryに記録、2回目で専用ルールに昇格、という段階的なアプローチが結果としてうまく回っている。

パターン3: ルールファイルの統一構造

6ファイル全てに同じ構造を採用した。

# [ルール名]

## ルール（1行で明確に）
✅ やるべきこと / ❌ やってはいけないこと

## 理由（過去の失敗事例）

## 具体的な手順

## 関連ドキュメント

構造が統一されていると、AIがルールを正確に解釈できる。人間にとってもメンテが楽だ。新しいルールファイルを作るときも、この構造をコピーして中身だけ書き換えればいいので迷わない。

分離の判断基準 -- 何をrulesに切り出すか

全てのルールをrulesに移す必要はない。判断の軸は2つある。

軸1: 「複数のタスクに共通するルールか？」 Yesなら切り出し対象になる。禁止事項、日時ルール、外部ツール連携の手順は、どんなタスクでも適用されるからrulesに置く。逆に、特定の役割やプロジェクトにしか関係しないものはCLAUDE.md側に残すか、プロジェクト固有の設定ファイルに書けばいい。

切り出すもの（rules向き）	残すもの（CLAUDE.md向き）
禁止事項全般	役割定義・基本姿勢
日時・書式のルール	ナビゲーション（フォルダ構造案内）
外部ツール連携の手順	プロジェクト固有の方針
チーム運用ルール	基本的な応答スタイル

軸2: 「頻繁に更新するか？」 rulesに分離しておくと、CLAUDE.md本体を触らずにルールだけを更新できる。禁止事項は新しい失敗が起きるたびに追記するので、CLAUDE.mdに埋め込んでいると毎回本体を編集することになる。更新頻度が高いルールほど、分離のメリットが大きい。

分離して最も変わったのは、ルールの管理しやすさだ。1つのワークスペースに複数のプロジェクト、組織運営、プライベートの作業、リサーチまでが混在する環境で、CLAUDE.md1ファイルに全部押し込めていた頃はコンテキストの汚染が深刻だった。ルールをドメイン別に分離してからは、各領域が独立して管理できるようになり、「あのルールどこに書いたっけ」と探し回ることがなくなった。結果として、CLAUDE.md本体の見通しも劇的に良くなっている。

よくある失敗と対処

rulesの運用で私がハマった失敗を3つ共有する。

失敗1: 分離しすぎた。 一時期、ルールファイルが10個を超えた。ファイルの数が多いとどこに何を書いたか結局把握できなくなり、CLAUDE.md肥大化と同じ問題が形を変えて再発する。試行錯誤の末、6ファイルで安定している。ドメインを大きめに括るのがコツだった。

失敗2: 重複ルールを作ってしまった。 CLAUDE.mdに「日本語で応答」と書き、rulesにも似た記述を入れてしまった。矛盾が生じた場合、Claude Codeはどちらを優先すべきか判断できず、応答が不安定になる。原則として、ある情報の置き場所は1箇所にする。

失敗3: 書いたまま放置した。 ルールファイルを作ったものの、業務の変化に合わせて更新しなかったことがある。実態と乖離したルールはAIにとってノイズになる。月1回、ルールファイルを見直す時間を取るようにしてからこの問題は減った。

CLAUDE.mdが肥大化するのはClaude Codeを使い込んだ証拠でもある。問題は膨らむこと自体ではなく、整理しないまま放置することだ。.claude/rules/を使ってドメイン別にルールを分離し、CLAUDE.md本体は骨格だけに保てばいい。「失敗が起きる→memoryに記録→2回目の再発→ルールファイルに昇格」というサイクルを回していけば、ルールは自然に育っていく。

禁止事項の具体的な設計パターンについては、今後の記事で詳しく解説する予定だ。