第7章：ベストプラクティス ── コミュニティが実証した7つの鉄則
Claude Codeと向き合ってきた世界中の開発者たちが、試行錯誤の末にたどり着いた実践知がある。それは「Claude Codeの仕様書」には書かれていない、使い込んでようやく見えてくるものだ。本章では、コミュニティが実証した7つの鉄則を、その背景にある理由とともに深く掘り下げる。単なる「コツ集」ではなく、なぜそれが機能するのかを理解することで、あなた自身が新しい状況に応用できるようになることを目指す。
鉄則1：ネガティブルールをポジティブルールに変える
「〜しないでください」という否定形の指示は、直感的に見えて実は罠だ。
LLMの処理特性に関する複数の研究が示しているのは、否定形の命令はモデルが遵守しにくいという事実だ。「赤い象を想像しないでください」と言われれば脳が赤い象を想像してしまうように、「コメントを書かないでください」という指示はClaudeのコンテキストに「コメント」という概念を強く打ち込んでしまう。コミュニティの報告では、ネガティブルールをポジティブ表現に書き換えるだけでルール遵守率が約50%向上したという事例も存在する。
具体的にどう変換するか。CLAUDE.mdの例を見てみよう。
Before（否定形）：
## コーディングルール
- varを使わないこと
- any型を使わないこと
- コンソールログを残さないこと
- マジックナンバーを使わないことAfter（肯定形）：
## コーディングルール
- 変数宣言にはconstまたはletを使う
- 型は明示的に定義する（unknown/neverを活用する）
- ログ出力はloggerモジュール経由で行う
- 数値は名前付き定数として定義する同じルールを伝えているが、後者はClaudeが「何をすべきか」を直接理解できる。禁止事項を並べるのではなく、あるべき状態を描写する。これが最初の鉄則だ。
鉄則2：探索・計画・実装を分離する（3ステップ法）
多くの開発者が犯す最大のミスは、「実装して」という一言でセッションを始めることだ。Claudeは要求を受け取ったその瞬間からコードを書き始める。計画なし、確認なし、ただ実行あるのみ。これが混乱の始まりだ。
Claude Codeには Plan Mode（Shift+Tabを2回押す）が存在する。このモードに入ると、Claudeは「観察・分析・計画のみを行い、実際のコードは書かない」状態になる。承認なしにファイルを変更しないため、計画を安全に議論できる。
しかしPlan Modeを使わなくても、魔法の呪文がある：
「計画を立ててください。コードは書かないでください。」
この一言で、Claudeは実装に走る前に思考を整理し、アプローチを提示するモードに切り替わる。実際の会話フローはこうなる：
[ユーザー]
認証システムをJWT + Redisセッションで実装したい。
まず計画を立ててください。コードは書かないでください。
[Claude]
はい、以下の計画を提案します：
1. 依存関係の確認（jsonwebtoken, ioredis）
2. authMiddleware.ts の新規作成
3. /auth/login エンドポイントの修正
4. セッション有効期限を環境変数で管理
5. 既存テストへの影響確認
懸念点：現在 /api/user で直接DBアクセスしているため、
セッション経由に切り替える際に3ファイルへの変更が必要です。
進めてよいですか？
[ユーザー]
5のテスト影響を先に調べてから進めて。計画を先に見ることで、方向性のズレを早期に発見できる。実装を始めてから「それは意図が違う」と気づくコストは、計画段階で発見するコストの何十倍もかかる。
鉄則3：フィードバックループを設計する
Claude Codeに最大のレバレッジをもたらす一言がある：
「テストも書いて、テストが通ることを確認してください。」
この指示が強力な理由は、Claudeが「自分の実装が正しいかどうか」を自律的に検証できる環境を作り出すからだ。テストなしで実装するClaudeは、いわば目を閉じたまま歩いている。テストという検証手段を与えることで、Claudeは自分の足元を確認しながら前進できるようになる。
フィードバックループの設計は、指示の内容だけでなく出力の形にも及ぶ。スクリーンショットやテスト出力をClaudeに渡すと、実際の動作と期待値のギャップをClaudeが自力で分析できる：
[ユーザー]
このスクリーンショットを見てください。ボタンを押しても
レスポンスが返ってきていません。期待値は200 OKです。
[スクリーンショット添付]
[Claude]
ネットワークタブを確認すると、CORS preflight が失敗しています。
cors ミドルウェアが POST を許可していない可能性があります。
server.ts の cors 設定を確認します...対して、フィードバックループのない開発はどうなるか：
Before（ループなし）：
実装完了 → ユーザーが動作確認 → 「動かない」→ Claudeに報告
→ 推測で修正 → また確認 → また「動かない」（無限ループ）After（ループあり）：
実装 → テスト実行 → 失敗を検知 → 自動修正 → テスト通過 → ユーザーへ報告後者では、Claudeがデバッグサイクルを自律的に回す。ユーザーは結果だけを受け取ればいい。
鉄則4：/clearを習慣化する
シンプルだが、守れている人は少ない。ルールはこうだ：
タスクが変わったら
/clearを打つ。
なぜこれが重要か。Claude Codeのコンテキストウィンドウには限りがある。バグ修正の会話、アーキテクチャの相談、新機能の実装が同じセッションに混在していると、Claudeは「今何をしているセッションなのか」の判断にコンテキストを消費してしまう。前のタスクで使ったコードスニペットや「一時的な方針」が、新しいタスクの判断に影響することもある。
/clearのタイミングを判断するチェックリストはこうなる：
- 話題が別機能・別ファイルに移った
- 「ちょっとこっちも見てほしい」という欲求が生じた
- エラー修正を3回以上繰り返している
- 「なんか前と違う挙動をしている気がする」という感覚がある
- セッション開始から1時間以上経過した
1つでも当てはまれば /clear のサインだ。コンテキストをリセットするのは「諦め」ではなく「リフレッシュ」だと認識しよう。クリアなコンテキストでClaudeは最高の仕事をする。
鉄則5：Plan Modeで大きなタスクを承認してから実行する
鉄則2と関連するが、特に大規模なリファクタリング・複数ファイルにまたがる変更・破壊的変更においては、Plan Modeの使用は必須と言っていい。
Shift+Tabを2回押すとPlan Modeに入る。このモードでClaudeは：
- コードベースを読み解き（観察）
- 変更箇所を特定し（分析）
- 実装計画を提示する（計画）
ファイルには一切触れない。
計画を受け取ったユーザーは、内容を確認・修正した上で「進めて」と承認する。その瞬間からClaudeは実装モードに移行する。
[Plan Mode]
変更が必要なファイル：
1. src/models/User.ts - roleフィールドの追加
2. src/middleware/auth.ts - ロール検証ロジックの追加
3. src/routes/admin.ts - 管理者ルートの追加
4. tests/auth.test.ts - テストケースの追加
影響範囲の懸念：
- 既存ユーザーのroleがnullになる可能性 → マイグレーションが必要
進めてよいですか？このひと手間が、後戻りのきかない大規模変更の事故を防ぐ。
鉄則6：CLAUDE.mdのPrimacy/Recency Bias活用
認知心理学に「系列位置効果」という概念がある。リストの最初（初頭効果）と最後（新近効果）にある項目は記憶に残りやすく、中間の項目は忘れられやすい。
これはClaude CodeがCLAUDE.mdを読む際にも同様の傾向が見られる。つまり、ファイルの先頭と末尾に書かれたルールの遵守率は高く、中間に埋もれたルールは見落とされやすい。
この特性を意識してCLAUDE.mdを構成するのが鉄則6だ：
CLAUDE.md の最適な構成
━━━━━━━━━━━━━━━━━━━━━━━━
先頭（高優先度・高遵守率）
→ 絶対に守ってほしいルール
→ よく違反するルール
→ 最重要のコーディング規約
中間（通常優先度）
→ プロジェクト構成の説明
→ 使用ライブラリの注意点
→ 一般的なガイドライン
末尾（高優先度・高遵守率）
→ 再び：絶対に守ってほしいルール
→ セキュリティ・本番環境への注意
━━━━━━━━━━━━━━━━━━━━━━━━graph TD
A["CLAUDE.md の先頭"] -->|初頭効果| B["最重要ルール<br/>（よく違反するもの）"]
C["中間部"] -->|記憶に残りにくい| D["一般ガイドライン<br/>プロジェクト説明"]
E["CLAUDE.md の末尾"] -->|新近効果| F["絶対ルール再掲<br/>セキュリティ注意"]
B --> G["Claude の遵守率 HIGH"]
D --> H["Claude の遵守率 LOW"]
F --> G
style B fill:#2d6a4f,color:#fff
style F fill:#2d6a4f,color:#fff
style D fill:#6b4423,color:#fff
style G fill:#1b4332,color:#fff
style H fill:#7b3f00,color:#fff例えば「テストを必ず書く」というルールがよく破られるなら、先頭と末尾の両方に配置する。「TypeScriptの設定について」のような説明的な内容は中間に置く。
鉄則7：Perplexity MCPを最初に入れる
MCPの設定で、何よりも先にやることが1つある。それがPerplexity MCPの導入だ。
理由はシンプルだ。Claude Codeのトレーニングデータには必ず「カットオフ日」が存在する。特にNode.jsのメジャーアップデート、React 19の新API、最新ライブラリのbreaking changeなど、クイックに動くエコシステムの情報は古くなりやすい。Perplexity MCPを導入すると、ClaudeがライブWeb検索を実行できるようになり、「今このライブラリのAPIはどうなっているか」をリアルタイムで参照しながらコーディングできる。
設定は ~/.claude/mcp_settings.json に以下を追加するだけだ：
{
"mcpServers": {
"perplexity": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-perplexity-ask"],
"env": {
"PERPLEXITY_API_KEY": "your-api-key-here"
}
}
}
}導入後の会話はこう変わる：
[ユーザー]
Prisma v6 で enum を追加するマイグレーションを書いて
[Claude - Perplexity MCP経由でWeb検索]
Perplexityで確認したところ、Prisma v6.2 から
enum の追加方法が変わっています。
`prisma migrate dev` の前に以下の手順が必要です...
（最新ドキュメントに基づいた正確な情報を提示）MCPは数多く存在するが、Perplexityは「知識の鮮度問題」というLLMの根本的な弱点を補う。他のMCPはプロジェクト固有の統合だが、Perplexityは全タスクに横断的に効く。だから「最初に入れる1つ」として鉄則に値する。
7つの鉄則の相互関係
これら7つの鉄則は独立したテクニックではなく、相互に補強し合うシステムだ。
flowchart TB
P1["鉄則1\nポジティブルール化"] --> CM["CLAUDE.md\n最適化"]
P6["鉄則6\nPrimacy/Recency配置"] --> CM
CM --> |"明確な指示"| EXEC
P7["鉄則7\nPerplexity MCP"] --> |"最新情報"| EXEC
P2["鉄則2\n3ステップ法"] --> |"計画フェーズ"| PLAN
P5["鉄則5\nPlan Mode承認"] --> PLAN
PLAN["計画の承認"] --> EXEC["実装フェーズ"]
EXEC --> |"テスト・検証"| P3["鉄則3\nフィードバックループ"]
P3 --> |"問題なければ完了"| DONE["タスク完了"]
P3 --> |"問題あり"| FIX["自律修正"]
FIX --> P3
DONE --> P4["鉄則4\n/clearで次タスクへ"]
P4 --> |"クリーンな状態"| P2
style CM fill:#1a1a2e,color:#e0e0ff
style PLAN fill:#16213e,color:#e0e0ff
style EXEC fill:#0f3460,color:#e0e0ff
style DONE fill:#533483,color:#fff
style P3 fill:#2d6a4f,color:#fff
style P4 fill:#1b4332,color:#fff鉄則1と6がCLAUDE.mdを最適化し、鉄則7が最新情報を供給する。鉄則2と5が無計画な実装を防ぎ、鉄則3が自律検証ループを作る。タスクが終われば鉄則4でリセットして次のサイクルへ。この7つを意識的に実践するだけで、Claude Codeとの協働品質は段違いに上がる。
ただし、鉄則はルールではなく習慣だ。最初から全部やろうとするのではなく、まず「鉄則4の/clear」と「鉄則2の計画先行」の2つから始めることを推奨する。この2つだけで、大半のストレスは激減する。