Claude Codeをインストールしたものの、「結局どう使えばいいのか」「コマンドが多すぎて覚えられない」と感じていませんか。
Claude Codeは自然言語で指示するだけで動作するシンプルなツールですが、使い方のコツを知っているかどうかで、開発効率に大きな差が出ます。本記事では、基本コマンドからCLAUDE.md設定、日本語対応、実務でのワークフローまで、Claude Codeを実践的に使いこなすための知識を体系的にまとめます。
筆者自身、agentic coding（AIに主導権を渡す開発スタイル）を標準の開発手法として日常的にClaude Codeを使っています。その実務経験に基づいたノウハウを具体例とともに紹介します。
Claude Codeの概要やインストール方法については「Claude Codeとは？完全ガイド」をご覧ください。
Claude Codeの基本コマンド一覧
起動・終了
# プロジェクトのルートディレクトリで起動
cd my-project
claude
# 直前の会話を再開
claude --continue
# 過去の会話から選択して再開
claude --resume
# 非インタラクティブモード（スクリプトやCI/CD向け）
claude -p "このプロジェクトの構造を説明して"Claude Codeはカレントディレクトリをプロジェクトのルートとして認識します。必ずプロジェクトのルートで起動してください。サブディレクトリで起動すると、プロジェクト全体の構造を把握できません。
スラッシュコマンド一覧
起動後に使えるスラッシュコマンドを機能別に整理します。
セッション管理
| コマンド | 機能 | 使用頻度 |
|---|---|---|
/clear | 会話をリセットして新しいセッションを開始 | 高 |
/compact | 会話を要約してコンテキストを圧縮 | 高 |
/compact <指示> | 指定した内容に焦点を当てて圧縮 | 中 |
/rewind | 任意の時点まで会話とコードを巻き戻し | 中 |
/btw <質問> | サイドクエスチョン（コンテキストに残らない） | 中 |
情報・設定
| コマンド | 機能 | 使用頻度 |
|---|---|---|
/help | ヘルプを表示 | 低 |
/config | 設定画面を開く | 低 |
/cost | 現在のセッションのトークン使用量を表示 | 中 |
/doctor | 環境設定の問題を検出 | 低 |
/model | 使用するモデルを切り替え | 中 |
/permissions | 許可設定を管理 | 低 |
ワークフロー
| コマンド | 機能 | 使用頻度 |
|---|---|---|
/exit | Claude Codeを終了（Ctrl+Cでも可） | 高 |
/rename <名前> | セッションに名前を付ける | 中 |
/init | CLAUDE.mdを自動生成 | 低 |
/hooks | 設定済みHooksを一覧表示 | 低 |
/sandbox | サンドボックス（隔離環境）を設定 | 低 |
モデル切り替えの具体例:
/model sonnet → Sonnet 4.6に切り替え（日常的なコーディング向け）
/model opus → Opus 4.6に切り替え（複雑な推論・設計判断向け）
/model haiku → Haiku 4.5に切り替え（単純作業・高速処理向け）筆者の使い分け: 通常の実装作業はSonnet、アーキテクチャの設計判断やセキュリティレビューはOpus、大量ファイルのフォーマット修正などの機械的な作業はHaikuを使っています。
キーボードショートカット
| ショートカット | 動作 |
|---|---|
Esc | Claudeの実行を中断（コンテキストは保持） |
Esc × 2 | リワインドメニューを開く |
Ctrl+C | Claude Codeを終了 |
Ctrl+G | Plan Modeのプランをエディタで開く |
Escキーは最も重要なショートカットです。Claudeが明らかに間違った方向に進んでいるとき、即座に中断してフィードバックを与えることで、コンテキストの無駄遣いを防げます。
CLAUDE.mdで開発ルールを設定する
CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込む設定ファイルです。プロジェクト固有のルールをここに書いておくと、毎回説明し直す必要がなくなります。
CLAUDE.mdの配置場所
| 場所 | 適用範囲 | 用途 |
|---|---|---|
~/.claude/CLAUDE.md | 全プロジェクト共通 | 言語設定、共通のコーディングルール |
./CLAUDE.md | 現在のプロジェクト（git管理推奨） | プロジェクト固有のルール |
./CLAUDE.local.md | 現在のプロジェクト（.gitignore推奨） | 個人的なメモ・設定 |
| 親ディレクトリ | モノレポの共通ルール | root/CLAUDE.mdとroot/app/CLAUDE.mdの両方が適用される |
効果的なCLAUDE.mdの書き方
良い例（具体的で、Claudeが推論できないことを書く）:
# CLAUDE.md
## ビルド・テスト
- テスト実行: npm test（Vitest）
- 型チェック: npx tsc --noEmit
- リンター: npm run lint
## コーディングルール
- 日本語で応答する
- Conventional Commits形式でコミット
- テストはVitestで書く。Jestは使わない
- CSSはTailwind CSS。インラインstyleは使わない
## 禁止事項
- next build を実行しない（開発確認はnext devを使う）
- .envファイルの内容を読まない
- supabase db reset を実行しない悪い例（自明なこと、Claudeが既に知っていることを書く）:
# こういうのは不要
- きれいなコードを書くこと（← 自明）
- 変数名は意味のある名前にすること（← 言語の標準慣習）
- エラーハンドリングを忘れないこと（← 一般論すぎる）
- src/components/Header.tsx はヘッダーコンポーネント（← コードを読めばわかる）重要なルール: CLAUDE.mdが長すぎると、Claudeが重要なルールを見落とします。各行について「これを書かなかったらClaudeは間違えるか？」と自問し、Noなら削除してください。
/initで自動生成する
既存プロジェクトに初めてCLAUDE.mdを導入する場合、/initコマンドが便利です。
> /init
プロジェクトのpackage.json、設定ファイル、ディレクトリ構成を分析して、ビルドコマンド、テストフレームワーク、コーディングパターンを自動検出したCLAUDE.mdを生成してくれます。これをベースに、不足する情報を追加・不要な行を削除するのが最も効率的です。
グローバルCLAUDE.mdの活用方法は「グローバルCLAUDE.mdで開発体験を統一する方法」で詳しく解説しています。
スラッシュコマンドの使い方
/clear — 最も重要なコマンド
/clearはClaude Codeを使いこなす上で最も重要なコマンドです。
Claude Codeのパフォーマンスはコンテキストウィンドウの残量に比例します。長い会話を続けると、古いファイル内容や失敗したアプローチがコンテキストに蓄積し、応答の質が低下します。
タスクが変わるたびに/clearする——これだけで体験が劇的に変わります。
> バグ修正が完了。次はテストを書こう。
> /clear
> src/auth.ts のlogin関数のテストを書いて。エッジケースも含めて。/compact — 長いセッションの救世主
1つのタスクに集中して長い会話が続いた場合、/compactで会話を要約してコンテキストを解放できます。
> /compact API変更の部分に焦点を当てて
指示を添えると、何を残すかを制御できます。筆者はCLAUDE.mdに「コンパクト時は変更したファイルの一覧とテストコマンドを必ず保持すること」と書いています。
/rewind — やり直しの切り札
Claudeが実装を進めたものの、方向性が間違っていた場合、/rewindでコードと会話の両方を巻き戻せます。
> /rewind
# → チェックポイントの一覧が表示される
# → 戻りたい時点を選択
# → 会話のみ / コードのみ / 両方 を選択Escキーを2回押しても同じメニューが開きます。「ダメだったら戻せる」という安心感があるので、大胆なアプローチを試しやすくなります。
/btw — コンテキストを汚さないサイドクエスチョン
作業中にちょっとした疑問が浮かんだとき、通常のプロンプトで聞くとコンテキストに残ります。/btwを使えば、回答がオーバーレイで表示されて会話履歴に残りません。
> /btw TypeScriptのRecord型とMap型の違いは？
Claude Codeを日本語で使う方法
Claude Codeは日本語のプロンプトに対応しています。ただし、いくつかの設定をしておくとより快適に使えます。
グローバルCLAUDE.mdに日本語設定を追加
# ~/.claude/CLAUDE.md
## レスポンス
- 日本語で応答する
## コミットメッセージ
- 日本語で記述するこの設定をしないと、Claudeは英語で応答したり、英語と日本語が混在した出力をすることがあります。
日本語プロンプトのコツ
Claude Codeへの指示は日本語で問題ありませんが、以下のポイントを意識すると精度が上がります。
技術用語は英語のまま使う:
○ 「src/auth.ts のlogin関数にrate limitingを追加して」
× 「src/auth.ts のログイン関数にレート制限を追加して」ファイルパス、関数名、技術概念は英語のまま指示した方が、Claudeが正確にコードベースを検索・理解できます。
曖昧な表現を避ける:
○ 「UserServiceクラスのcreateUserメソッドに、メールアドレスの重複チェックを追加して。
重複時はConflictError(409)をthrowする。テストも書いて。」
× 「ユーザー登録のところをいい感じにして」段階的に指示する:
大きなタスクを一度に投げるより、設計→実装→テスト→レビューと段階的に進めた方が精度が高くなります。
> このプロジェクトのauth関連のコードを読んで、現状を説明して（Plan Mode）
> OAuth2のGoogleログインを追加する計画を立てて（Plan Mode）
> 計画に沿って実装して。テストも書いて。（Normal Mode）
> テストを実行して、失敗したら修正して。効率的なプロンプトの書き方
検証手段をセットで伝える
Claude Codeの出力品質を最も高めるテクニックは、検証手段を指示に含めることです。
○ 「validateEmail関数を実装して。テストケース:
user@example.com→true、invalid→false、user@.com→false。
実装後にテストを実行して確認して。」
× 「メールアドレスのバリデーション関数を書いて」Claudeが自分で正しさを検証できる手段（テスト、スクリーンショット、ビルドコマンド）を渡すと、自律的にフィードバックループを回して品質を高めてくれます。
既存パターンを参照させる
コードベースに既にあるパターンを指し示すと、一貫した実装が得られます。
> HotDogWidget.phpの実装パターンに倣って、CalendarWidgetを新規作成して。
> 月の選択とページネーション（前月/翌月）を実装して。
> 外部ライブラリは追加しない。既存の依存だけで作って。Plan Modeで調査と実装を分離する
Plan Mode（Ctrl+G でプランをエディタで開ける）を使うと、Claudeはファイルの読み込みと計画の作成だけを行い、コードの変更は行いません。
# Plan Mode
> src/auth/ 配下のコードを読んで、セッション管理の仕組みを説明して。
> Google OAuthを追加するには何を変更すればいい？計画を立てて。
# Normal Mode（Ctrl+G で切り替え）
> さっきの計画に沿って実装して。テストも書いて。Plan Modeが有効なケース:
- 不慣れなコードベースでの作業
- 複数ファイルにまたがる変更
- アプローチが不確実なとき
Plan Modeが不要なケース:
- 修正内容が明確（typo修正、ログ追加など）
- diffを一文で説明できる単純な変更
サブエージェントで調査を委任する
コードベースの調査はコンテキストを大量に消費します。サブエージェントに委任すると、別のコンテキストウィンドウで調査が行われ、メインの会話を汚しません。
> サブエージェントを使って、認証システムのトークンリフレッシュの仕組みと、
> 既存のOAuthユーティリティがあるかを調べて。実務でのワークフロー例
ワークフロー1: バグ修正（15分）
cd my-project
claude> 本番でこのエラーが出ている:
> [エラーログを貼り付け]
> 原因を特定して修正して。修正を検証するテストも書いて。Claudeがエラーログを分析 → 関連コードを探索 → 原因を特定 → 修正 → テスト作成 → テスト実行まで自律的に進めます。
> /cost
# → トークン使用量を確認
> 変更をコミットして。コミットメッセージはConventional Commits形式で。ワークフロー2: 新機能実装（1-2時間）
# 調査フェーズ（Plan Mode）
> Issue #42 の仕様を確認して。gh issue view 42 を使って。
> 既存のコードを読んで、実装計画を立てて。
# 実装フェーズ（Normal Mode）
> 計画に沿って実装して。テストも書いて。
# 検証フェーズ
> テストを全て実行して。失敗したら修正して。
> リンターと型チェックも通して。
# コミット
> 変更をコミットしてPRを作成して。ワークフロー3: 大規模リファクタリング（半日）
# セッション1: 調査
> src/legacy/ 配下のJavaScriptファイルをリストアップして。
> TypeScript化の優先順位を提案して。依存関係が少ないものから。
> /clear
# セッション2〜N: ファイルごとに実装
> src/legacy/utils.js をTypeScriptに変換して。strict modeで。
> テストがあれば更新して、なければ作成して。
> /clear
# 最終セッション: 統合確認
> TypeScript化した全ファイルの型チェックを実行して。
> テストを全て実行して。大規模な作業では/clearでセッションを細かく区切るのがコツです。1セッション1タスクの原則を守ると、コンテキストの肥大化を防げます。
ワークフロー4: コードレビュー
> git diff main...HEAD を確認して、以下の観点でレビューして:
> - ロジックの正確性
> - エッジケースの考慮
> - セキュリティ上の懸念
> - パフォーマンスへの影響
> - 既存コードとの一貫性Writer/Reviewerパターンとして、実装したセッションとは別のセッションでレビューすると、実装時のバイアスがなく客観的なレビューが得られます。
ワークフロー5: 非インタラクティブモード（CI/CD）
# PR に自動コードレビューコメント
claude -p "git diff main...HEAD をレビューして。問題があればリストアップ。" \
--output-format json
# 大量ファイルの一括処理
for file in $(cat migration-list.txt); do
claude -p "$file をReactからVueに変換して。" \
--allowedTools "Edit,Bash(git commit *)"
done-pフラグで非インタラクティブモードが有効になり、スクリプトやCI/CDパイプラインに組み込めます。
よくある失敗パターンと対策
コンテキストの使い過ぎ
症状: 長いセッションの後半でClaudeの応答品質が低下する、指示を忘れる
対策: タスクが変わるたびに/clear。1セッションで2回以上修正を繰り返したら/clearして最初から。
漠然とした指示
症状: Claudeが見当違いの実装をする
対策: ファイルパス、関数名、期待する動作を具体的に指示。既存のパターンを@で参照。
CLAUDE.mdの肥大化
症状: CLAUDE.mdに書いたルールをClaudeが無視する
対策: CLAUDE.mdを定期的に見直し、不要な行を削除。重要なルールには「IMPORTANT」を付けて強調。
検証なしの実装
症状: 一見正しそうだがエッジケースで壊れるコード
対策: テストの実行、ビルドの確認、スクリーンショットの比較など、検証手段を必ず指示に含める。
まとめ
Claude Codeの使い方で最も重要なポイントを整理します。
| カテゴリ | 最重要ポイント |
|---|---|
| コンテキスト管理 | /clearをタスクごとに実行。コンテキストの清潔さが品質を決める |
| CLAUDE.md | 「なければClaudeが間違えること」だけを書く。短く保つ |
| プロンプト | 検証手段をセットで伝える。既存パターンを参照させる |
| 日本語 | グローバルCLAUDE.mdに「日本語で応答する」を設定 |
| ワークフロー | Plan Mode → 実装 → テスト → コミットの流れを基本形にする |
| 失敗対策 | 2回修正して直らなければ/clearして最初から書き直す |
Claude Codeは「ツールの使い方」よりも「AIとの協業の仕方」を学ぶことが大切です。指示の出し方、コンテキストの管理、検証の仕組みを整えることで、Claude Codeは開発効率を何倍にも高めるパートナーになります。
より高度な活用として、VSCodeとの連携、MCP連携、Skillsによる開発ワークフロー自動化も参考にしてください。
aduce株式会社では、Claude Codeの使い方研修から、agentic codingを活用した開発プロセスの構築まで、IT顧問サービスとして包括的にご支援しています。「チームにClaude Codeを導入したいが、使い方の定着に不安がある」という方は、ぜひお問い合わせからお気軽にご相談ください。