海外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が出来上がります。