株式会社BlueAI 代表取締役CEO / ソフトウェアエンジニア / プロダクトエンジニア / Google Cloud Architect / 元AIスタートアップ(Doorkel)
Claude Code ベストプラクティス｜開発効率を最大化する 8 つのコツ
Claude Code を導入したものの、「思ったほど生産性が上がらない」「回答の精度にばらつきがある」「コストが想定以上にかかる」と感じていませんか。Claude Code は強力なツールですが、使い方次第で成果に大きな差が出ます。
本記事では、Claude Code を日常的に使っている開発者の知見をもとに、Claude Code ベストプラクティスを 8 つのカテゴリに分けて解説します。CLAUDE.md の整備からプロンプトの書き方、コンテキスト管理、コスト最適化、Git 連携、セキュリティ、チーム運用、そしてよくある失敗パターンまで網羅しています。この記事を実践すれば、Claude Code の効率化が確実に進むはずです。
1. CLAUDE.md を最初に整備する
Claude Code を使い始めてまず取り組むべきは、CLAUDE.md の整備です。これは Claude Code の効率化における最も重要なステップと言っても過言ではありません。
なぜ CLAUDE.md が重要なのか
Claude Code は毎セッション開始時に CLAUDE.md を自動で読み込みます。つまり、プロジェクトの技術スタック、ディレクトリ構成、コーディング規約といった情報を一度書いておけば、毎回説明し直す必要がなくなります。
CLAUDE.md がない状態で Claude Code を使うと、以下の問題が頻繁に起きます。
- プロジェクトで使っていないライブラリのコードを提案される
- 命名規則やファイル配置のルールが無視される
- 既存のユーティリティ関数があるのに、同じ機能を一から実装しようとする
効果的な CLAUDE.md の書き方
CLAUDE.md には、Claude Code に「毎回必ず知っておいてほしい情報」を簡潔に書きます。ポイントは、長すぎず、かつ必要十分な情報を含めることです。
# CLAUDE.md
## プロジェクト概要
- React + TypeScript の SaaS アプリケーション
- パッケージマネージャ: pnpm
- フレームワーク: React Router v7（SSR）
## ディレクトリ構成
- app/routes/ — ルーティング
- app/components/ — 共通コンポーネント
- app/lib/ — ユーティリティ
## コーディング規約
- コンポーネントは関数コンポーネントで書く
- CSS は Tailwind CSS を使用する
- テストは Vitest + Testing Library
## 開発コマンド
- pnpm dev: 開発サーバー起動
- pnpm test: テスト実行
- pnpm lint: リント実行
特に「開発コマンド」のセクションは見落とされがちですが、Claude Code がビルドやテストを実行する際に正しいコマンドを使ってくれるようになるため、記載しておくことを強く推奨します。
/init コマンドで始める
ゼロから書くのが面倒な場合は、/init コマンドを使いましょう。Claude Code がプロジェクトの構造を分析し、CLAUDE.md のひな形を自動生成してくれます。生成されたファイルをベースにカスタマイズすると効率的です。
CLAUDE.md の詳しい設定方法については、以下の記事で解説しています。
2. プロンプトの書き方を工夫する
Claude Code の出力品質は、プロンプトの書き方に大きく左右されます。ここでは、精度の高い回答を引き出すための Claude Code コツを紹介します。
具体的に指示する
曖昧な指示は曖昧な結果を生みます。ファイル名、関数名、変数名など、対象を明確に指定しましょう。
悪い例:
ログイン機能を修正して
良い例:
app/routes/login.tsx の handleSubmit 関数で、
バリデーションエラー時に setError ではなく
useSnackbar のエラー表示を使うように修正して
良い例のように、対象ファイル、対象関数、現在の動作、期待する動作の 4 つを明示すると、Claude Code は迷いなく正しい修正を行えます。
段階的に指示する
大きなタスクを一度に依頼すると、Claude Code が途中で方向を見失ったり、コンテキストウィンドウを使い切ったりすることがあります。タスクを分割して段階的に進めるのがベストプラクティスです。
まず app/lib/api.ts の fetchUsers 関数を調査して、
現在のエラーハンドリングの実装を教えて
調査結果を確認してから、次のステップに進みます。
では、fetchUsers にリトライロジックを追加して。
最大 3 回、指数バックオフで再試行する実装にして
「まず調査 → 次に実装」のように順序を明示することで、Claude Code はステップごとに集中して作業できます。
制約を明示する
「既存のコードスタイルに合わせて」「新しい依存を追加せずに」「型安全性を維持して」のような制約を伝えると、期待に沿った出力が得られやすくなります。特に、やってほしくないことを明示するのは効果的です。
utils/date.ts に formatRelativeTime 関数を追加して。
dayjs は使わず、Intl.RelativeTimeFormat を使うこと。
既存の formatDate 関数のスタイルに合わせて書いて
3. コンテキストウィンドウを管理する
Claude Code の性能はコンテキストウィンドウの状態に直結します。コンテキストが溢れると回答の質が下がり、過去の指示を忘れることもあります。意識的に管理しましょう。
/compact の活用タイミング
/compact コマンドは、会話履歴を要約してコンテキストウィンドウを圧縮します。以下のタイミングで使うと効果的です。
- 長い調査や議論を経て、これから実装に入るとき
- 「コンテキストウィンドウが 80% を超えました」という警告が表示されたとき
- 話題が大きく変わるとき（バグ修正の議論から新機能の実装に切り替えるなど）
/compact を実行すると、それまでの会話が要約され、重要なポイントだけが保持されます。コンテキストの空きが増えるため、続きの作業の精度が回復します。
.claudeignore で不要なファイルを除外する
プロジェクト内に Claude Code が読む必要のないファイルがある場合は、.claudeignore に追加しましょう。.gitignore と同じ構文で記述できます。
# .claudeignore
node_modules/
dist/
.next/
coverage/
*.min.js
*.lock
data/fixtures/
これにより、Claude Code がファイルを検索・読み取る際に不要なファイルがスキップされ、コンテキストの無駄遣いを防げます。
新しいセッションを開始するタイミング
以下のような状況では、/clear で会話をリセットするか、新しいターミナルセッションを開始するほうが効率的です。
- 完全に異なるタスクに取りかかるとき
- Claude Code が以前の誤った方針を引きずっているとき
- コンテキストウィンドウが限界に近く、
/compactでも十分な空きが確保できないとき
新しいセッションでは CLAUDE.md が再読み込みされるため、プロジェクトのルールは維持されたまま、クリーンな状態から作業を再開できます。
コマンドの詳細は以下の記事を参照してください。
4. コストを管理する
Claude Code は API トークンに基づく従量課金です。無計画に使うとコストが膨らむため、定期的な確認と使い分けの意識が重要です。
/cost で定期的に確認する
/cost コマンドを実行すると、現在のセッションで消費したトークン数と推定コストが表示されます。作業の区切りごとに確認する習慣をつけましょう。
特にファイルの一括読み取りや大量のコード生成を行った後は、想定以上にトークンを消費していることがあります。/cost で現状を把握しておけば、コスト超過を未然に防げます。
Sonnet と Opus の使い分け
Claude Code では /model コマンドでモデルを切り替えられます。すべてのタスクに最上位モデル（Opus）を使う必要はありません。
Sonnet で十分なタスク:
- 定型的なコード生成（CRUD、テストの追加など）
- 簡単なリファクタリング
- ドキュメントの作成・修正
- コードの説明やレビュー
Opus が効果的なタスク:
- 複雑なアーキテクチャ設計
- 難しいバグの原因調査
- 複数ファイルにまたがる大規模な変更
- パフォーマンス最適化の提案
日常的な作業は Sonnet、頭を使う作業は Opus という使い分けを意識するだけで、コストを大幅に抑えられます。
月額上限の設定
Anthropic のダッシュボードでは、月額の使用上限を設定できます。チームで利用する場合は、メンバーごとの上限を設定しておくと予算管理がしやすくなります。
コストの詳細については以下の記事で解説しています。
5. Git との連携ベストプラクティス
Claude Code は Git との連携が得意です。適切に活用することで、変更の追跡と巻き戻しが容易になります。
こまめにコミットさせる
Claude Code に作業を依頼する際は、機能単位でこまめにコミットさせましょう。
handleSubmit のバリデーションを修正したら、
変更内容を説明するコミットメッセージ付きでコミットして
こまめにコミットしておけば、Claude Code が意図しない変更を行った場合でも git revert で簡単に巻き戻せます。「動く状態」をこまめにセーブポイントとして記録するイメージです。
ブランチ戦略
Claude Code に大きな変更を依頼するときは、必ず作業ブランチを切ってから始めましょう。
feature/add-retry-logic というブランチを作成して、
そこで作業を進めて
main ブランチで直接作業すると、問題が起きたときの復旧が困難になります。ブランチを切っておけば、最悪の場合でもブランチを削除するだけで元に戻れます。
大きな変更前に git stash
Claude Code に既存コードの大幅な書き換えを依頼する前に、現在の作業内容を退避しておくと安心です。
まず現在の変更を git stash して、
クリーンな状態にしてから作業を始めて
これは保険のようなものです。Claude Code の変更が期待どおりでなかった場合に、git stash pop で元の状態に戻せます。
6. セキュリティ対策
Claude Code はファイルシステムに直接アクセスできるツールです。セキュリティを意識した運用は必須です。
.claudeignore で機密ファイルを除外する
環境変数ファイルや認証情報など、Claude Code に読ませたくないファイルは .claudeignore に必ず追加しましょう。
# .claudeignore（セキュリティ関連）
.env
.env.*
*.pem
*.key
credentials.json
secrets/
.claudeignore に追加したファイルは、Claude Code のファイル検索や読み取りの対象外になります。万が一、プロンプトで「.env を見せて」と指示しても、Claude Code はアクセスできません。
permissions の適切な設定
.claude/settings.json で許可するコマンドを明示的に制限しましょう。特に、以下のコマンドは拒否リストに入れておくことを推奨します。
{
"permissions": {
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force)",
"Bash(curl*)",
"Bash(wget*)"
]
}
}
必要なコマンドだけを許可し、危険なコマンドは明示的にブロックする「ホワイトリスト方式」が最も安全です。
本番環境での注意点
Claude Code を本番環境に接続されたマシンで使う場合は、特に注意が必要です。
- 本番データベースへの直接アクセスを禁止する
- デプロイコマンドの実行を権限で制限する
- 本番の API キーを含む
.envは必ず.claudeignoreに追加する
Claude Code はあくまで開発支援ツールです。本番環境への操作は CI/CD パイプラインを通じて行い、Claude Code から直接実行しない運用を徹底しましょう。
セキュリティの詳細については以下の記事を参照してください。
7. チーム開発での活用
Claude Code はチームで使うとさらに効果を発揮します。設定やナレッジを共有することで、チーム全体の開発効率が向上します。
CLAUDE.md をリポジトリにコミットする
プロジェクトルートの CLAUDE.md を Git にコミットすれば、チーム全員が同じルールのもとで Claude Code を利用できます。新しいメンバーが参加しても、CLAUDE.md を読むだけでプロジェクトの規約やアーキテクチャを把握できるという副次的なメリットもあります。
CLAUDE.md を作成・更新したら、
必ず Git にコミットしてチームと共有する
Skills の共有
Claude Code の Skills（カスタムスラッシュコマンド）は、.claude/skills/ ディレクトリに Markdown ファイルとして配置します。これを Git にコミットすることで、チーム全員が同じ Skills を利用できます。
たとえば、コードレビューの手順や PR 作成のテンプレートを Skills として定義しておけば、チーム全体で作業の品質と効率を標準化できます。
Skills の詳しい作成方法は以下の記事で解説しています。
コーディング規約の統一
CLAUDE.md にコーディング規約を明記しておくと、Claude Code が生成するコードが自動的に規約に従います。ESLint や Prettier のルールだけではカバーしきれないプロジェクト固有の慣習（命名パターン、ファイル分割の粒度、コメントの書き方など）を記述しておくと特に有効です。
## コーディング規約
- API クライアントの関数名は use + リソース名（例: useUsers, useInvoices）
- エラーハンドリングは try-catch ではなく Result 型で行う
- コンポーネントファイルは 200 行以内に収める
チーム全員が同じ CLAUDE.md を使うことで、Claude Code の出力がレビューしやすくなり、コードの一貫性も保たれます。
8. よくある失敗パターンと回避法
最後に、Claude Code を使う際に陥りやすい失敗パターンとその回避法をまとめます。
一度に大きすぎるタスクを依頼する
Claude Code に「アプリ全体をリファクタリングして」のような巨大なタスクを一度に投げると、コンテキストウィンドウを使い切り、途中で品質が低下します。
回避法: タスクをファイル単位、関数単位に分割して段階的に進める。1 回のプロンプトで扱う範囲は「1 つのファイルの 1 つの関心事」が目安です。
出力を確認せずに次の指示を出す
Claude Code の変更内容を確認しないまま次の指示を出すと、誤りが積み重なって手戻りが大きくなります。
回避法: 各ステップの出力を必ず確認する。特にファイルの変更後は git diff で差分を確認し、意図どおりの変更であることを確かめてから次に進む。
CLAUDE.md を更新しない
プロジェクトの構成やルールが変わっても CLAUDE.md を更新しないと、Claude Code が古い情報に基づいて作業してしまいます。
回避法: 技術スタックの追加・変更、ディレクトリ構成の変更、コーディング規約の更新時に CLAUDE.md も合わせて更新する。PR のチェックリストに「CLAUDE.md の更新が必要か」を含めておくと忘れにくくなります。
コンテキストの肥大化を放置する
長時間同じセッションで作業を続けると、コンテキストウィンドウが膨張して回答の質が低下します。
回避法: 30 分以上の連続作業では /compact を実行する。タスクが完全に切り替わるタイミングでは新しいセッションを開始する。
すべてを Opus モデルで実行する
Opus はすべてのタスクで最高の結果を出すわけではありません。単純なタスクに Opus を使うのはコストの無駄です。
回避法: 前述の「Sonnet と Opus の使い分け」を参考に、タスクの複雑さに応じてモデルを切り替える。
Git のセーブポイントを作らない
Claude Code に連続で複数の変更を行わせた後に問題が見つかると、どの変更が原因か特定しにくくなります。
回避法: 機能単位でコミットさせる習慣をつける。「この変更をコミットしてから、次のタスクに進んで」と明示的に指示する。
まとめ
本記事では、Claude Code ベストプラクティスとして 8 つのカテゴリに分けてコツを紹介しました。ポイントを振り返ります。
- CLAUDE.md を最初に整備する ことで、毎回の指示量を減らし、出力の一貫性を高める
- プロンプトは具体的に、段階的に 書くことで、精度の高い回答を引き出す
- コンテキストウィンドウを管理する ことで、長時間の作業でも品質を維持する
- コストを意識し、モデルを使い分ける ことで、予算内で最大の成果を得る
- Git と連携し、こまめにコミットする ことで、安全に変更を進められる
- セキュリティ設定を怠らない ことで、機密情報の漏洩を防ぐ
- チームで設定を共有する ことで、組織全体の開発効率を底上げする
- 失敗パターンを知り、事前に回避する ことで、手戻りのない効率的な開発ができる
Claude Code は「使いこなすほど強くなるツール」です。最初から完璧を目指す必要はありません。まずは CLAUDE.md の整備とプロンプトの改善から始めて、徐々にベストプラクティスを取り入れていきましょう。
より体系的に Claude Code の活用方法を学びたい方は、以下のレッスンも参考にしてください。
