Claude Code は Anthropic が提供するエージェント型コーディング環境で、単なるチャットボットを超えてファイル読み込み・コマンド実行・自律的なタスク完遂までこなします。しかし強力ゆえに「context window が埋まると性能劣化する」という制約があり、使いこなしには明確なルールが必要です。本記事では Anthropic 公式ドキュメントを基に、現場で効くベストプラクティス7ルールを解説します。
ルール1: CLAUDE.md でプロジェクト文脈を渡す
CLAUDE.md は毎セッション必ず読み込まれる特別ファイルで、ビルドコマンド・コードスタイル・ワークフロールールなど「コードから推測できない情報」を Claude に持続的に渡します。`/init` コマンドでプロジェクト構造を解析した叩き台が自動生成できるので、まずはそこから始めましょう。
注意点は「短く保つ」こと。ファイルが肥大化するとClaudeが重要なルールを無視し始めます。各行ごとに「これを消したらClaudeがミスするか？」を自問し、当てはまらないなら削除。プロジェクトルート（共有用）と `~/.claude/CLAUDE.md`（全プロジェクト共通）に分けて配置でき、`@path/to/file` 構文で他ファイルをimportも可能です。
ルール2: メモリと /clear・/compact で文脈を制御する
Claude Codeの最大の制約はcontext window。長時間セッションでは無関係な会話やファイル内容が溜まり、性能が落ちます。タスクが切り替わったら/clear で完全リセット、限界が近づいたら /compact <instructions> で「APIの変更点を残して要約」など指示付き圧縮が有効です。
同じ指摘を2回以上したらコンテキストが汚染されているサイン。失敗を引きずるより、新しいセッションで学びを盛り込んだプロンプトを書き直す方が早いというのが公式の助言です。Esc + Esc や /rewind によるチェックポイント復元も活用しましょう。
ルール3: サブエージェントで調査を分離する
Subagents は .claude/agents/ に Markdown で定義する専門アシスタントで、独立したcontext windowと独自ツール権限を持ちます。「認証システムのトークン更新を調査して」のように依頼すると、サブエージェントが大量のファイルを読みつつ、メイン会話には要約だけ返してくれます。
典型例は security-reviewer・code-reviewer・researcher など。Writer/Reviewerパターン（実装と別セッションでレビューさせる）と組み合わせれば、レビュー側は実装バイアスを持たないため品質チェックの精度が上がります。「use a subagent to investigate …」と明示的に呼ぶのがコツで、メイン会話のcontextを温存できる点が最大のメリットです。
ルール4: Hooks で「絶対やる」処理を自動化する
CLAUDE.mdの指示が「お願い」レベルなのに対し、Hooksは決定的（deterministic）に必ず実行されるスクリプトです。.claude/settings.json に定義し、ファイル編集後にlintを走らせる、特定ディレクトリへの書き込みをブロックする、コミット前に型チェックを通すといった「例外なく守りたい」運用に最適です。
「eslintを毎回edit後に走らせるhookを書いて」「migrationsフォルダへの書き込みをブロックして」と頼めばClaude自身が設定を生成してくれます。/hooks で現在の設定を確認できるので、まずは小さなフックから導入してみるのが安全。チーム共通のコーディング規約や危険操作の禁止は、CLAUDE.mdに書くよりHooksに落とし込んだ方が確実に守られます。
ルール5: MCP と CLI ツールで外部世界とつなぐ
MCP（Model Context Protocol）サーバを claude mcp add で追加すると、Notion・Figma・データベース・監視ツールなどに直接アクセスできます。issueトラッカーから機能を実装、Figmaデザインから画面を起こす、本番DBを安全にクエリする、といった統合が現実的になります。
同様にCLIツール（gh, aws, gcloud, sentry-cli など）はcontext効率が最も良い外部連携手段。GitHub操作は gh CLIを必ず入れておくと、PR作成・issueコメント取得まで全部Claudeに任せられます。未知のCLIでも「`foo –help`を読んで使い方を学んでからA,B,Cを実行して」と指示すれば自走できるので、社内ツールにも気軽に橋渡しできます。
ルール6: 具体的な指示と Plan Mode で先に設計する
「foo.pyにテスト追加して」より「ログアウト時のedge caseをカバー、モックは使わずfoo.pyのテストを書いて」とスコープ・条件・参照パターンを明示するだけで、修正回数が劇的に減ります。@でファイル参照、画像はドラッグ&ドロップ、ログは cat error.log | claude でパイプ流し込みが可能です。
大きな変更ではPlan Modeを使い「Explore → Plan → Implement → Commit」の4フェーズで進めます。先に計画を立てさせ、Ctrl+Gでエディタに開いて修正してから実装させると、誤った方向への暴走を防げます。
ルール7: 検証ループで品質を担保する
公式が「最高レバレッジの一手」と明言しているのが「Claudeに自己検証手段を渡すこと」。テストコード、期待出力、UIなら比較スクショを与えると、Claude自身がループを回して修正します。逆に検証手段がないと「それっぽいが動かないコード」を量産しがちです。
「ビルドが失敗してる、直して」ではなく「このエラー[貼付]を、根本原因を直してビルド成功まで確認して、エラー隠蔽はNG」と伝えるのがコツ。UI変更ならスクショ比較、API実装ならテストケースを先渡し、データ処理なら期待出力を提示する——テストスイート・linter・Bashチェックなど、検証手段への投資は何倍にもなって返ってきます。Auto modeで自動承認する場合も、検証ループが堅牢なら安心して任せられます。
よくある失敗パターン
- キッチンシンク化: 無関係なタスクを混ぜて文脈汚染 →
/clear - 修正の連打: 2回直しても直らない → 学びを盛り込んだ新プロンプトで再開
- CLAUDE.md肥大化: ルールが埋もれて無視される → 容赦なく剪定
- 検証ギャップ: 動くように見えて動かない → 必ず検証手段を渡す
- 無限探索: スコープ無しの調査依頼 → サブエージェントに分離
まとめ
Claude Code を使いこなす本質は「context を大切に扱い、検証ループを必ず作る」という一点に集約されます。CLAUDE.mdで前提を渡し、サブエージェントで調査を分離、Hooksで品質ゲートを固定し、MCPで外部世界をつなぎ、具体的なプロンプトで方向を絞り、最後にテストで自己検証させる。この7ルールを意識するだけで、Claude Codeの出力品質と開発スピードは目に見えて変わります。まずは /init でCLAUDE.mdを生成し、小さな hook を1つ追加するところから始めてみてください。
✍️ この記事を書いた人
チケットナビ編集部
先払い買取・金券売買の最新情報を初心者にもわかりやすくお届けします。業者の比較、買取率、トラブル対策など、安全に現金化するための情報を徹底調査して発信しています。
コメント