海外5M viewバズ投稿「Claudeレート制限回避Tips」——全部すでに実装してた話：CLAUDE.md駆動開発のすすめ
はじめに
先日、海外のX（旧Twitter）で「Claudeのレート制限を回避するためのTips」という投稿が5M viewを超えてバズりました。内容をざっくりまとめると：
- タスクを細かく分割して1リクエストあたりのトークンを減らす
- キャッシュを活用してコンテキストを節約する
- モデルを用途によって使い分ける（Opus vs Sonnet vs Haiku）
- 毎回同じ指示を繰り返さないようにする
- コンパクトなプロンプトを書く
「なるほど、参考になる」と思いながら読んでいたのですが、気づきました。
これ、全部CLAUDE.mdに書いてある。
CLAUDE.md駆動開発を実践している人にとっては、これらは「あえて意識する必要のない、自動的に守られるルール」になっています。この記事では、CLAUDE.mdとは何か、どう書けばよいかを実践的に解説します。
CLAUDE.mdとは何か
CLAUDE.mdはClaude Codeがプロジェクト（またはグローバル）の文脈を把握するための設定ファイルです。
~/.claude/CLAUDE.md # グローバル設定（全プロジェクト共通）
<project-root>/CLAUDE.md # プロジェクト固有の設定
Claude Codeはセッション開始時にこれらのファイルを自動的に読み込みます。つまり、毎回同じ指示をプロンプトに書かなくても、常にそのルールに従って動作するようになります。
これがバズったTipsの「毎回同じ指示を繰り返さないようにする」を自然に実現しています。
CLAUDE.mdで実現できる主なパターン
1. モデル使い分けルールを明示する
## モデルポリシー
- **デフォルト**: Sonnet（日常的なコーディング・分析タスク）
- **Opus明示**: `/model claude-opus-4-6` で明示切替（複雑な設計・レビュー）
- **自動昇格禁止**: 明示指示なしにモデルを自動変更しない
このように書いておくと、Claudeは「難しそうなタスクだからOpusを使おう」という自律的な判断でモデルをアップグレードしなくなります。Sonnetで解ける問題はSonnetで解く、というコスト最適化が自動化されます。
Haikuを使いたいタスク（単純な変換・フォーマット）についても明示できます：
- **Haiku用途**: 単純なフォーマット変換・ファイル名整理・コメント生成
→ `claude --model claude-haiku-4-5` で実行
2. コンテキスト節約ルールを組み込む
バズったTipsの「タスクを細かく分割する」「キャッシュを活用する」は、CLAUDE.mdのルールとして書いておくと自然に守られます：
## コア原則
- **小さく正確な変更**を好む。影響範囲は常に最小限
- 隣接コード・コメント・フォーマットを"ついでに改善"しない
- 既存スタイルが好みと違っても**そのスタイルに合わせる**
- **strategic compact**: コンテキストが70%超になったら `/compact` を使う
「ついでに改善しない」というルールは、1タスクあたりのトークン使用量を劇的に減らします。Claudeが「ここもリファクタしておきました！」と余計な変更を加えると、コンテキストが膨らんでレート制限に近づきます。
3. 再利用可能な指示を「ルール」として書く
## Bash / ファイル調査
- **自問ルール**: Bashコマンドを打つ前に「Read/Grep/Globで代替できないか？」を確認
- `cat` → Read / 情報取得目的なら Grep / `find` → Glob
- ファイル調査は特定サブパスを仮定せず `du -sh` → `find -maxdepth 3 -type d` で全体把握
これを書いておくと、毎回「catじゃなくてReadを使って」と言わなくて済みます。プロンプトに書くべき指示がゼロになります。
4. レート制限に直結する「禁止パターン」を明示する
## [I] Agent Team起動ゲート
- 起動前に必ず1回以上の確認（トークン大量消費）
- Agentデプロイ前チェック：並列3つ未満はAgent不使用
- 同じファイル群参照なら分割しない
Agent（サブエージェント）は便利ですが、トークン消費が非常に大きいです。「3タスク未満ならAgentを使わない」というルールをCLAUDE.mdに書くだけで、不必要なトークン消費を防げます。
実践的なCLAUDE.md構成例
以下は筆者が実際に運用しているCLAUDE.mdの骨格です（匿名化済み）：
# CLAUDE.md - myproject
## Purpose
このプロジェクトは〇〇SaaS。バックエンドはPython/FastAPI、フロントはNext.js 15。
## 絶対ルール（[I]タグ）
### [I] 外部API課金ゲート
外部LLM APIを呼ぶ前に必ず確認。「やって」だけでは実行しない。
### [I] データ変更ゲート
DB schemaの変更・本番へのデプロイは実装前にspec.mdを作成する。
## 推奨指針（[G]タグ）
### [G] モデルポリシー
- デフォルト: Sonnet
- Opus: 設計レビュー・複雑なバグ調査のみ（明示指定）
### [G] コーディング原則
- 影響範囲は最小限。"ついでの改善"はしない
- 実装前に仮定とトレードオフを明示する
- 3ステップ以上のタスクは計画を先に提示する
タグ設計のポイント
[I] Instruction（絶対ルール）と [G] Guidance（推奨指針）を明確に区別するのがポイントです。
- [I]タグ: 違反したら即停止・報告。セキュリティ・課金・データ損失に関わるもの
- [G]タグ: 状況判断OK。コーディングスタイル・工数判断など
これを曖昧にすると、Claudeが「これは厳密なルールなのか、それとも目安なのか」を判断できず、期待と違う行動をとることがあります。
CLAUDE.mdを育てる方法
最初から完璧なCLAUDE.mdを書く必要はありません。フィードバックループで育てるのが現実的です：
Claudeが期待と違う動作をした
↓
「なぜそうしたか」を確認
↓
CLAUDE.mdにルールを追記
↓
次回から同じ問題が発生しなくなる
実際、筆者のCLAUDE.mdは最初は20行程度でしたが、3ヶ月の運用で160行になりました。ただしファイルを太らせすぎないことも重要です（公式推奨は400行以下）。詳細なルールは docs/ サブディレクトリに分けて、CLAUDE.mdからは参照だけします：
## フォルダ構造
詳細: → `docs/folder-structure.md`
## ワークフロー
詳細: → `docs/workflow.md`
こうすることで、CLAUDE.mdはすっきりと保ちながら、詳細情報は必要に応じて参照できます。
まとめ
バズったTipsを改めて整理すると：
-
タスクを細かく分割する →
[G] 小さく正確な変更を好むで自動化 -
キャッシュを活用する →
[I] strategic compactでコンテキスト管理 -
モデルを使い分ける →
[G] モデルポリシーで明示化 - 同じ指示を繰り返さない → CLAUDE.md自体がその解決策
- コンパクトなプロンプトを書く → ルール化により毎回書く必要なし
CLAUDE.md駆動開発を実践すれば、これらのTipsを意識せずとも自然に守られるようになります。レート制限に悩んでいる方は、まずCLAUDE.mdを整備するところから始めてみてください。
少しずつルールを追加して育てていくことで、あなた専用のClaudeが出来上がります。